Atari800XL

"/nt5" has changed to "nt5" (without the slash) in version 3. So you should use: WinNTSetup.exe nt5 /configfile:"WinNTSetup.ini"

Congratulations on 3.0 Final!!! Thanks for your continued work on this, you made installing Windows a breeze!

JFX, just to wrap this up: I saw the extra animation on some test .wim I made, maybe the one that had the "pending updates" inside (injected with DISM). However, I don't use that system anymore, I'm back to updating a "live" system, then capturing that. In the last case, I haven't seen the animation anymore, so just forget about it. We wouldn't want to hold back WinNTSetup 3.0 RTM!!

A few days ago I was going to mention that there was a "new" (unwanted) 8.1 install animation on one of my tests, even though I had the WinNTSetup option "win8noanimation" set. Then on another test there was no animation after all. I was a bit confused, so I removed that message. Now I think it might be like this: - On a 8.1 wim that has the latest updates "injected" with DISM (offline), there is a new animation (because the injected updates are "pending" updates, and are executed at install time, and the new animation is presented). - On a 8.1 wim that has the updates applied in Audit mode, the animation does not occur. Actually, applying updates in audit mode is no longer possible in 8.1, you need to update in user mode, then enter audit mode, then generalize/shutdown etc, then capture the new .wim. (The best way I found is to use autounattend.xml to create a user with admin rights, and set autologin for that user). These are my findings so far, I would be interested to know if any of the experts can confirm or deny this. WinNTSetup related: I guess there's no way for WinNTSetup to prevent the animation I mentioned. It's not very important either, because it can be prevented if you use "the other" method. [EDIT: Upon more testing with 8.1ProWMC-with a free MS key from 11/2012-, I'm not so sure anymore. Looks like there's some kind of new animation, no matter which method you use. As you might have guessed, I hate this animation, it looks so childish, reminds me of the Atari800XL "attract" screen].

Sorry, removed (need more testing).

OK jaclaz, thanks for that. I use 32bit mostly, it's just when some pesky "outsiders" come in with their new PC's and laptops, that I need to worry about 64bit stuff. It's mostly laptops lately, for those I also needed a 64bit win8PESE usb, what with Secure boot, uefi etc. On other peoples' systems, I can't fool around too much, so I need those tools in 64bit. So to have some experience I need to have some 64bit test stuff around for myself as well... But once again, to be clear on the subject: I don't mind 32bit at all, this was just about the WinNTSetup v3 warning "Your processor is not 8.1 64bit ready". To my taste, this warning can be shown when setting up either version... (besides, look at my username, if it was up to me, we would still be using 8bit Atari's)

Just now, I was installing w8.1 32bit on an older PC, and noticed the "This processor does not support w8.1 64bit" warning (in the WinNTSetup v3 "Ready?" screen).. At first, my reaction was that this warning should be removed (as it doesn't concern the 32bit install), but after a bit of thinking I guess it's actually a good warning, something like "You're about to install the 32bit version, and that's just as well, because this old piece of crap PC doesn't support 64bit anyways". So please leave the warning in (looking forward to 3.0.20131101!)

I do remember I saw 3 product keys mentioned in the list at one time (remember I asked about saving all lines in that list), but I guess that must have been on an occasion when all primary partition were visible (I'm still not 100% sure though...). Thanks for checking, I was just asking because the beta stage seems to be coming to an end. EDIT: Wait, I did this test: (1) On testlaptop: Boot from USB (Win8PESE), start WinNTSetup 3beta (latest), press ctrl-sh-o: Only product key from active partition is shown. No "Y:" or "Z:" drives are mounted (2) On "live" Windows XP on different (work) PC: p1 is hidden (w7), p2 is hidden (w8), p3 is unhidden and active: Start WinNTSetup, press ctrl-sh-o: 3 product keys are found, p1 is mounted as Y:, p2 is mounted as Z: EDIT2: OK, now this is interesting: - From XP, ctrl-sh-O shows productkeys from all primary partitions, even when they were hidden before (it mounts them as Y: and Z: in my case) - From w7 or w8, starting WinNTSetup, then pressing the key, shows only the productkey from the active partition, the one that was not hidden. This also explains why Win8PESE shows only 1 productkey.

Is it me, or has something changed in the last few versions? Before (until some time last week?), hitting ctrl-sh-0 (from Win8PESE) found all (3) Product Keys in all primary partitions (also hidden ones), but now it only shows the Product Key of the active partition of the HD. Any ideas?

Just for fun (and testing) I built a new Windows 8.1 wim a few minutes ago. I usually add NetFX3 and remove most Appx packages with DISM. Today I got the (official) update rollup ("Rollup A") which contains all updates that should have been in the RTM version in the first place (KB2894179, KB2883200, KB2894029) and added them to the wim as well. ...well, just wanted to let you know that this new .wim also installs fine with WinNTSetup v3. It shows the updated .wim as "6.3.9600.16408" (instead of the previous 16384 [edit, sorry]). Nice!

Thanks for the new version. Nice to see it's a the Beta stage now. What exactly do you mean by "supported to install a NT5 OS after a NT6 one"?

Thanks, the new and improved x64 W8.1 cpu check is great, along with the "save all productkeys"!!!

Thank you very much for the new version. Of course I already saw your message two days ago, but I wanted to wait for other reactions first. Well, there aren't any (yet). Now there must surely be (a lot?) more users of WinNTSetup, right? With every new version, I'm amazed by this wonderful tool, and of course the fact that you want to share it with us, for free! Thanks x1000 I like the new "Product keys" feature! It finds all keys on all my OS partitions. When multiple keys are found, only one is saved, is it possible change that, or to add "Save all"? The new WinNTSetup cpu check on the P4 (mentioned a few posts up) says it is W8.1x64 ready (but it's not). But never mind for now...

On a test of two systems, these were the differences in the CoreInfo ouput: Intel® Pentium® 4 CPU 3.00GHz Intel64 Family 15 Model 4 Stepping 3, GenuineIntel SSSE3 - Supports Supplemental SIMD Extensions 3LAHF-SAHF - Supports LAHF/SAHF instructions in 64-bit modePDCM - Supports Performance Capabilities MSRTM2 - Implements Thermal Monitor 2 controlCNXT-ID * L1 data cache mode adaptive or BIOSPREFETCHW - Supports PREFETCHW instructionIntel® Core2 Duo CPU E4500 @ 2.20GHz x86 Family 6 Model 15 Stepping 13, GenuineIntel SSSE3 * Supports Supplemental SIMD Extensions 3LAHF-SAHF * Supports LAHF/SAHF instructions in 64-bit modePDCM * Supports Performance Capabilities MSRTM2 * Implements Thermal Monitor 2 controlCNXT-ID - L1 data cache mode adaptive or BIOSPREFETCHW * Supports PREFETCHW instructionSo I concluded that it had to be Prefetch and LAHF/SAHF, as they were mentioned in the Windows 8.1 x64 requirements. Also, Windows 8.1 installs on the Core2, but not on the P4-630. But I guess everything might be a bit more complicated.

Intel® Core2 Duo CPU E4500 @ 2.20GHz Your console app reports: Windows 8 Support:+ PAE+ SSE2+ NXWindows 8.1 x64 Support:+ CMPXCHG16B+ LAHF/SAHF- PREFETCHW (AMD)But Sysinternals' Coreinfo says (Asterisk means: supported): CX16 * Supports CMPXCHG16B instructionLAHF-SAHF * Supports LAHF/SAHF instructions in 64-bit modePREFETCHW * Supports PREFETCHW instructionAnd Windows 8.1 x64 installs OK. ..so it looks your console app doesn't report PREFETCHW correctly (yet?). Thanks for picking this up anyway, after some more thinking about this, I do believe it would be pretty cool if WinNTSetup would report this info beforehand. Thanks!!

Would it be possible to let WinNTSetup check for the new Windows 8.1 processor requirements? As luck has it, I was testing on a p4-630 (which runs Windows 8.0 just fine), this system can't install 8.1 x64 because it lacks CMPXCHG16b, prefetchW, LAHF/SAHF. I used Sysinternals' Coreinfo.exe to check for these requirements. Of course the apply stage goes without problems, but on reset the system errors out. I think it would look really professional if WinNTSetup could check for this. Just an idea, please put it on the "maybe next year" list... Now I'm on to checking 8.1 x64 on more systems... EDIT: Hmm, never mind, forget about that, not worth the trouble, besides: easier to check in my own program prior to calling WinNTSetup. Thanks for listening, anyway...

Well, no bad luck for you on friday the 13th. I tested (my usual) triple setup W7/W8/XP on one PC, everything A-OK!!! Beautiful!!!! So now we're back to cosmetics-only remarks, because the only thing I noticed was the "ready?" screen timer counts down from 10 to 1 with XP (nt5) , while with W7/W8 (nt6) it doesn't count down, but mentions "30 seconds". Sorry, once a nitpicker... On to 3.0 alpha!

Can I test it please? (It's friday the 13th? Besides, you wanted a full week off...)

hexoxssaa, can you be a little more specific? What is going on, did you use WinNTSetup, and then your system driveletter was D: instead of C:? Is that your problem?

JFX, have a happy holiday, thanks for quickly fixing the last issue I mentioned in my last message. (I noticed you changed 20130907 to 20130907rev1 after I had written it). You didn't mention it, but I had a feeling I should check it out once more.,, The only driver you have to worry about now is the one driving you to the nightclubs

I didn't expect a new version so soon from what you said, but was very curious, so here we go again. (Just saw your message again from 28 aug, :"Please report any Bugs you find.", until you say otherwise, I will keep on testing and replying). A little Q and A: - Driverpath now modified with existing driverpackpaths?: YES (path is added, not replaced). - Driverpath takes *all* paths from supplied winnt.sif: NO (but that's OK, as long as we know the behaviour, we can work around that). - Winnt.sif looking good prior to reboot?: Hmmm, it has shrunken considerably, only a few lines left, not sure what that's about (lines like Productkey, Resolution, Adminpassword, etc are gone. Not sure about the consequences of that). - XP installs OK anyway? NO, this is what I get after reboot (after loading textmode drivers, translated): "Please insert the cdrom named 'Windows XP professional edition sp3' in the drive" Just reporting... I'm back to the previous version 20130904rev1 for now (and, of course, version 2.x). Too bad we can't just take the existing winnt.sif and only add the path of the newly added drivers from the "-drivers" switch. I know why this is, you explained that, but still, too bad to see that things have become a bit more complicated in this respect. Take your time please...

I was going to be quiet for a change, but I decided to modify my previous message with an updated and tested script, with comments, for people who are trying to figure out what all the fuss is about... But a funny thing happened that I had to share: - The "runafter" command doesn't seem to work (yet?) with version 3 and XP (nt5). Sigh... :-) just when I thought I had a clever way of working around the drivers thingy... Never mind, just thought I'd mention it. I will execute the command manually for now (it *does* work!), and try (again) to wait patiently...

I think the "one supplied by user" should naturally *replace* the winnt.sif in the xp source. The same goes for the first one in your list. The others look like they could/should be appended. I'll patiently await your best decision... Edit: Something like this might tie me over until a new WIP version (take your time!) (sorry, Autohotkey is about as fancy as I get) Untested Tested and working ; I use an XP source (iso) with already integrated DPbase mass storage; drivers, the paths to these drivers are located in winnt.sif, in; the variale OemPnpDriversPath; This winnt.sif file is located in the WinNTSetup folder, for easy; maintenance: when a change is made, there's no need to rebuild the iso.; When I use WinNTSetup (version 2.x), more drivers are added using; its "Add Drivers" option, this time from an ISO file (determined by PC; type, eg. video, sound, etc.). ; WinNTSetup 2.x **APPENDS** the paths; to these drivers in the OemPnpDriversPath.; The new 3.x version of WinNTSetup **REPLACES** the OemPnpDriversPath; when it adds drivers. In my case this means the MassStoragedrivers path; is gone, and XP won't boot from a SATA drive.; To solve this, I need to replicate the 2.x behaviour, and **APPEND**; the MassStorage to the OemPnpDriversPath.; Luckily, this can be done after WinNTSetup finishes, and prior to the; final reboot (that starts the XP setup) by using the "-RunAfter" parameter.; This script should be compiled with Autohotkey to ModifyDriverPath.exe.; Then the following switch can be added to the WinNTSetup 3.x commandline:; -runafter:"ModifyDriverPath.exe"; ===================================; This script starts execution after WinNTSetup has written all XP install; files to c:\; We now have to append the path in our original winnt.sif (from the; WinNTSetup program folder) to the modified (replaced) path which now; resides on the c: driveoriginalfile=%a_scriptdir%\winnt.sifmodifiedfile=c:\$WIN_NT$.~BT\winnt.sifIniRead, ExistingPath, %originalfile%, Unattended, OemPnpDriversPathIniRead, ModifiedPath, %modifiedfile%, Unattended, OemPnpDriversPath; Now we join the original path with the new path (using ";") and; write it (in textquotes) to the winnt.sif file on c:IniWrite, "%ExistingPath%;%ModifiedPath%", c:\$WIN_NT$.~BT\winnt.sif, Unattended, OemPnpDriversPath

Thanks. Good enough for me, take your time. I was just thinking: In V2, it could hardly be an "accident" that the path was appended instead of replaced. Isn't this the normal way of treating driverspaths?

Thanks guys. No, I did not know you were *not* the original developer. Sorry about that... Very strange about the driver line. It seemed so natural to me to just "add" the new path, instead of replace. So your advice would be to "take care" of that line myself, prior to reboot? If so, I'm still glad we figured this one out... Or maybe still a chance that WinNTSetup can use "add" instead of "replace" like in v2? I would really like that!