JFX

You now can install WinXP to an already existing Windows 7 using the same boot partition. WinNTSetup will add a legacy entry to the BCD store for WinXP and change the boot sector on end of XP install, to the bootmgr loader.

WinNTSetup v3 Beta1 (10/08/2013) - fixed OEMPreinstall wasn't always set for NT5 installs - fixed user creation not working correctly - new added Disk space check for NT5 - new logging full stdout of used tools - new it's supported to install a NT5 OS after a NT6 one

This perfect sounds like the usually mistake to also capture the boot files. Mount your wim file rw and remove the \Boot folder and the \bootmgr file in the root. They aren't supposed to be there. And always use bcdboot after apply an image.

WinNTSetup v3 Alpha2 (10/02/2013) - changed format button refreshing boot and install drive if both are the same selection - changed ini file will be saved in WinNTSetup folder - fixed ISO mount option doesn't search for winnt.sif - fixed boot drive icons now refresh after updating boot code - fixed new created VHD will be set as install drive - updated bootice.exe to v1.2.0.1 - changed x64 exe compression from mpress to experimental UPX v3.91

Thanks for reporting all these gui glitches For VHD, you mean after attach or creating a VHD(X) it should be set as Install drive for NT6? Good idea! I don't know about that previous version every did this, at least there never was any code written to do so. v2 was made in Autoit3, but this became more and more a problem. I had to use several work arounds to keep the GUI responding quick enough with all these disk and wim file checks. As more WIMGAPI functions go multi threading, AU3 was no option any more. v3 is written to 100% in PureBasic

Ohh, fixing 1 bug and introduce 2 now Well I don't really understand why your Win 8 doesn't have these files in system32 folder and why my checks tells their are there A newer Alpha 1 is up! - all Win8 download conditions removed - updated bootice to 1.2.0 - fixed VHDX check on Win7 installs

WinNTSetup v3 Alpha1 (30/09/2013) - fixed Product key save button now save all recovered key - fixed CPU check return OK, if none of the requirements are fulfilled - fixed ADK files not downloaded on Win8 - fixed 'Disable Hibernate' show wrong tool tip - fixed winnt.sif not found in source - fixed CMPNENTS folder copied to root instead into the $WIN_NT$.~LS folder - fixed drive details not refresh on initial selection - fixed format button could be used with no drive selected - fixed drive details now refresh after using Format button - fixed NT6 Setup button accepts invalid sources - added MSDN key is now received

Depends if we mean the same, if we use bold, italic and underlined word. Actually, i think is smarter to use XPx64 than Vista or Win8

click-click, yes it crash on WinXP, have again forgot that there are still XP users. Anyway I can't compile a NOD32 friendly version, so use this great tool by woot32: Windows-8-Product-Key-Viewer

Wow 8 bugs at once, thanks a lot wimb Also a good idea to disable the GUI options during setup phase Although, for the setup button, it's the easiest solution to have it available all the time. So a button click can always tells the user what's wrong with the chosen options.

So do you trust NOD32 ? Anyway does it display the key?

Should be easy to get the key form the MSDM table, try this: MSDM-Key.zip

Hmm, yeah for the download count there is very few respond on the forum. The save button was thought to save all and will do so with next version. The CPU check has a small bug I just found. Seams that would occur if neither CMPXCHG16B nor LAHF/SAHF instructions are supported.

WinNTSetup v3 Alpha0 - fixed WinNTSetup_iso.cmd wasn't found in some cases - fixed shutdown countdown timer - fixed password reset could not remove the used service - added Product key decoding support for Office 2013 - added CPU check for Winowd 8.1 x64* *) if CPU is not supported, hotkey will be removed and warning icon set on OK Button

Actually I think it reports it right. You don't have an AMD CPU. No sure why coreinfo lies here, but you should not have the prefetchw feature with this CPU. I found this amd-only-prefetchw-instruction-is-generated-in-x64-optimized-code Well if I understand this right, than an x64 Windows simply ignore a prefetchw instruction if the CPU don't support it. So it doesn't make much sense that it is a system requirement for x64 Win8.1

Should be possible to add these checks, thought I wonder about prefetchW, Coreinfo.exe tells me I have it, but on this 4 years old Intel CPU it's have be kidding me. EDIT: Here's small console app, please check out if is display correct data cpu.zip

Thanks for all your testing Atari800XL! I guess it sometimes doesn't find the right windows to update the text. I'll try to fix it.

It's a special friday the 13th edition , so I couldn't wait until tomorrow

WIP 09/13/2013 is up! It fixes a lot of bugs and should be closed to an alpha version. Driver integration should now work in all cases. - it should not matter how driver in the XP source were integrated (dpase all methods or nlite) - no need to use winnt.sif ini from dpbase method 1 - OemPnPDriversPathUpdate is cleaned form possible duplicates http://sdrv.ms/13YWwCY

Okay fixed driver stuff and runafter switch for nt5. Current version WinNTSetup v3 (WIP 07/09/2013) Rev 1 PS: I'm away for the next week

Yes, that should help until next WIP comes. After checking a bit more about driver packs, I tend more to scan the \$WIN_NT$.~LS\$OEM$\$1\D folder so no need to rely on winnt.sif. But this biggest part should be logging what's happen

Yep, but it has to check all winnt.sif files, - one created by driverpacks before winntsetup -.one create by the MSSTMake integration - one create by the driverpacks integration - the one in the root of the XP source - and the one supplied by user

Sure it will be done in next version, but there is much more I have to change here. Next version have to wait a bit longer (holidays are over ....)

Well that I'm not the one how wrote it, should be clear by now. Nonetheless I'm the one behind the development for over a year now. Technically v2 does only work in your case by mistake, it's not designed to accept 2 different driver integrations on one source,

Okay, that great these missing entries in OemPnpDriversPath could explain the BSOD after last reboot. We will know if you fix the line in winnt.sif after running v3, with the correct data one form v2. BTW: In v2 doe you have selected an winnt.sif file?