| Date: | June 29, 2005 / year-entry #168 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050629-11/?p=35163 |
| Comments: | 21 |
| Summary: | Why can't all the registry key needed by Windows Setup be precomputed and splorted at one go? One reason is that Windows Setup can be customized via a so-called "unattend file", which means that a lot of the work cannot be precalculated. Some settings also have cascade effects on other settings. Also, the model for... |
Why can't all the registry key needed by Windows Setup be precomputed and splorted at one go? One reason is that Windows Setup can be customized via a so-called "unattend file", which means that a lot of the work cannot be precalculated. Some settings also have cascade effects on other settings. Also, the model for component registration is to make each component responsible for its own registration, which can in turn be context-sensitive: "If the system has configuration x, then do y else z". Internet Explorer's component registration for example contains many conditional sections based on the installation configuration specified in the unattend file and the even fancier Winbom.ini file used by Sysprep-based deployment (which is used by computer manufacturers and large corporations). Making each component responsible for its own registration reduces entanglements between components but also means that "global optimizations" such as precalculating the registry cannot be done. Engineering is about tradeoffs and this is one of them: Maintainability vs. speed. (Of course, there are sections of the registry that are not context-sensitive, and those to some degree have already been gathered together for block copying onto the machine during Windows Setup. Look at the That said, it appears that Longhorn setup is moving towards the "disk image" model. I wish them luck. |
Comments (21)
Comments are closed. |
I would be very disappointed, if Longhorn setup would not based on Windows-Installer:-)
The Windows Installer team has been trying to avoid the use of the DllSelfRegister as far I understand. From http://msdn.microsoft.com/library/en-us/msi/setup/selfreg_table.asp, "Installation package authors are strongly advised against using self registration."
Longhorn setup CANNOT be based on the windows installer, frankly, OS setup is too complicated for the windows installer. As a simple example, how do you repartition a disk using the windows installer?
And it’s my understanding that self registration is out for Longhorn.
Ah, but that is easy to handle: Write a custom extension for MSI which starts diskpart.exe and let the user figure out the rest :P
Yes, but in order for Windows Installer to run, Windows must be running.
Setup contains just the bare essentials of Windows; probably not a robust enough environment for Windows Installer. (Although it does present a rather amusing chicken and the egg problem.)
Guys, I think he was joking about the windows installer. Hence the smiley face at the end.
While I can’t find a url, I recall in early 2004 that somebody at MS saying they planned on using an image to install Longhorn and applying specific drivers & settings after the fact. I also remember them claiming Longhorn would install in "15mins or less" because of this fact.
Although there hasn’t been any evidence of this fact yet, I sure hope MS sticks with their original idea/plan.
and why is the winsupersite.com written using ASP?
Nice, now I’ve heard the first time for Winbom.ini, but there is actually a page in technet that mentions it:
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/factorymode.mspx
Matt: Windows *can* boot fully-featured (well, enough-featured – no swap file) from a CD-ROM. There’s even an OEM tool based on it, called Windows Preinstallation Environment, but since in Windows XP and later it’s a native kernel feature (/minint kernel switch), anyone can make their own with just the original Windows files and a lot of patience (or more likely a tool such as BartPE – or even more likely by downloading one of the illegal pre-made images). Great as recovery disks too, I’m surprised the emergency repair console isn’t based on that
Anyway. Windows Installer could well be used to build *the image*, since almost all (minus custom actions) of the setup process is under its full control, so it can "install" the files to a log of operations
Raymond has asked me to post about this in the past and maybe I’ll do a series on LH OS installation technology after I’m done my series on the DLL loader.
First thing to note is that when you purchase a system from a large OEM, you generally get a box where you plug it in, it shows you some "friendly" UI to get you going and then you’re done. The *VAST* majority of coppies of Windows are deployed using this technique.
The technical challenges are issues around data that really has to be machine specific. e.g. the machine SID, local account SIDs (since they’re derived from the machine SID) and network connectoid GUIDs (these are just the standard examples we use for points of reference). There’s a tool in the OPK (OEM preinstall kit I believe) call sysprep which removes all the system specific data ("genericize") so that OEMs can make disk images (or even send the disk images off to disk manufactures who then deliver pallets of drives with the images already on them). When the system boots for the first time, sysprep "specialization" occurs which fixes up all the per-machine stuff, runs the happy UI and then you’re all set.
I won’t go on further and instead will take this as a refcount on blogging more about all this stuff and what we’re doing here for Longhorn.
KJK::Hyperion:
"Great as recovery disks too, I’m surprised the emergency repair console isn’t based on that"
Chicken and egg. The Recovery Console (AKA Command Console) isn’t based upon WinPE because, well, it predates it by an entire version of Windows. The CMDCONS was a new feature of Windows 2000. WinPE was totally new for Windows XP – and rewriting the Recovery Console was never in the cards for Whistler (Windows XP/Windows Server 2003).
BTW, the /MiniNT flag means that it is in WinPE mode. WinPE was known as MiniNT during development. BartPE is simply a reverse engineered version of WinPE (with admittedly a more extensible builder.
Also of note, MSIExec (the Windows Installer) has never been a component of WinPE. While it would conceptually have been possible to install Windows via an MSI, IMHO it would have made a very complicated task even more complicated, and still really not have met the needs of OEMs and customers.
KJK::Hyperion:
Since ERD 2002, ERD has used WinPE as it’s infrastructure. Previous to that, the versions that supported booting from CD basically used the same boot code path that setup would have when you el-torito booted a Windows CD.
FWIW, the MiniNT flag passed in at boot time is used pervasively through Windows… Lots of things were special cased to be able to run Win32 from CD
I should also add there is no fake page file used for ERD (or WinPE. The only time a pagefile is ever created with WinPE is on a hard-disk boot with low memory… and no RAM-disk driver was used for pre-WinPE versions of ERD, nor is one used for WinPE (unless you manually create one for scratch space using a non-included driver, or boot to one, using the latest version of WinPE).
Wes: Russinovich has made live CDs out of Windows 2000 for years (see his ERD Commander product)
The trick appeared to be using the setup CD boot loader to detect boot devices, pre-load their drivers and build a volatile SYSTEM hive, and probably (but I’m speculating, I didn’t check) a RAM disk driver to 1) make NtInitializeRegistry succeed despite no writable media (setup CD and repair console have no Win32 in them, so they only need the SYSTEM hive – but Win32 support is what makes WinPE *usable*) and 2) make the silly memory manager happy with a fake swap file
It seems to me this is, on the long run, way less painful than rewriting an user environment from scratch (broken, at it)
I wonder how much faster the current setup process would run if NT had an option to agressively cache disk and registry I/O? Let’s say I don’t care about disk/registry integrity if the power goes out or the system bugchecks, since I’ll just restart the install from the beginning.
Wes:
WinPE (or booting an NT based Windows completely from CD-ROM) was NOT totally new with XP.
Embedded NT exists far longer, and I’ve setup CDs (called Server Start) for Siemens Primergy’s which boot into NT4 and start a GUI where you can prepare the installation. The oldest are about 7 years old!
Stefan
Sunday, July 03, 2005 1:46 PM by John
> Let’s say I don’t care about disk/registry
> integrity if the power goes out or the
> system bugchecks, since I’ll just restart
> the install from the beginning.
And your restarted install will bugcheck at the same place.
And your restarted install will bugcheck at the same place.
And your restarted install will bugcheck at the same place.
Sometimes you DO want a reinstall to be able to detect which detection attempt to avoid repeating.
Though you do have a point. In Linux installers that I’ve used during the past 3 years or so, if an automated install fails, then you can choose to restart a manual install and you can decide which risky detections to try and which to skip. (Of course manual installs pretty much always had this kind of capability with some degree or other of cumbersomeness, but automated installers sometimes optimistically forgot to say how to access the manual installer. This has improved.)
True enough, NT 4 Embedded did indeed exist first. But an important aspect that differentiates WinPE (which itself was new for XP) from either NT Embedded or Windows XP Embedded when booted from CD is that the CD is exactly that, a CD. No write filter to cache writes and fib to the OS that writes happened. In the case of XP and NT Embedded, you must use a write filter when running from CD.