antoineL

Thanks, this is useful.

Surprise! Yesterday (2009-08-07) I spotted this download as available on Microsoft servers (in English, French, German etc.) The page (http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=60A07E71-0ACB-453A-8035-D30EAD27EF72) is widely advertised all over the web. But today, all the links are 404 (including direct downloads). Is it possible that MS shall upgrade the WAIK to the RTM release in the next few days?

Thanks to Strel (and TC76 and all the people involved) for this useful tool. I was trying to use only the .NET 1.1 part, and I got small pitfalls. First, while my targets include Win2000 and Vista stations, I was building on XP64, which is seen as NT5.2 i.e. 2003 server (they share the same kernel). Even if I use WIN2K=YES in the .ini, the logic which discovers WIN2K3 according to the VER command operates, and then prevents the 1.1 installer to be built. The fix is obviously to check about the version only if there are no explicit settings in the .ini. See attached patch to this effect VerCheck.patch.txt (GNU unidiff, against the version 20090316b.) I am guessing the setting WINXP=YES will do the job to build a 1.1 installer for Vista, but I do not have checked it yet. Second, for bare bones W2k targets (SP4 w/o IE6, which only have 2.0 Windows Installer), the /passive and /quiet and /norestart switches are not acceptable. It took me quite more time to come with a acceptable patch , which doubles the %VERBOSITY% stuff with a %QSWITCH% (either qb or qn). It is still not perfect , since for example it enables the Cancel button (and I do not know what /passive does, but I guess it doesn't). Also I broadly replaced throughout the script, but an educated guess is taht .NET 2.0 might require Installer 3.x at least, thus making it moot. Anyway I attach it in case anyone is interested. VerbosityMSI2.patch.txt Much more complex was the aim to have several 1.1 language packs (of course I am thinking about servers here, or MUI-enabled workstations). I succeded at manually building an installer which does that (by manually renaming the langpack.msi after their adminstrative installation), but I did not even try to enhance the script this way. Is there any interest?

This is news to me. Care to expand on this? Windows Server 2003 products may use a boot loader file named "Osloader.ntd" (NTLDR and NTDETECT.COM may still exist). I am uncertain between the relationship between the different boot loaders of Windows Server 2003. Well, Osloader.ntd is ONLY used when booting from ADS: http://support.microsoft.com/kb/843536/en-us Probably just like SETUPLDR.EX_ is used instead of SETUPLDR.BIN for PXE/RIS installs/PE's. Close. In fact, you should compare it with OSLOADER.EXE, which is (as Jaclaz already knows is the second part of NTLDR (the first one being the StartUp module which brings the computer into 32-bit mode). So if you compare them, you'll find they are extremely similar, they even have the same .PDB referenced; the only differences are in the PE header: there is a supplementary section, named .detect the ImageSize is bigger the checksum are different (better have to, since they are checked ) Now, if you consider the extra baggage at the end of OSLOADER.NTD, it is around 46 KB, and it is... NTDETECT.COM So I believe it works this way: PXE ROM, STARTROM.xxx sent with TFTP, asks for "NTLDR" but expects a .EXE (this is standard behaviour of Microsoft's PXE infrastructure), the server sends this OSLOADER.NTD packaged as a single file and the OsLoader works alone, without need to download a further NTDETECT.COM later. What I do not understand yet is how OsLoader does to "know" it should either load_from_disk/ask_via_tftp for NTDETECT.COM (normal case), or just have a look in memory behind itself (osloader.ntd case). The evident way to do it (just inspect the COFF header) is not that evident, since I did not see any reference to ".detect" in the binary; perhaps it does that by direct inspection to entry #12, without checking the name? OK, next stage is to build some frankenboot, i.e. paste StartUp and OsLoader.ntd as NTLDR, removing NTDETECT.COM and see if it works... Another try is to "append" ntdetect.com to setupldr.bin (or renamed version of it, like cmldr ) and see if Setup is able to boot without needing the ntdetect.com extra baggage... PS: I am a newbie here, so if this should be redirected to another thread (or a new one), please do; also I'd appreciate pointers to similar researches already done about OsLoader.NTD.