HostWinBootDrv is the easiest to explain: it has to do with disk compression, i.e. DoubleSpace/DriveSpace. What DriveSpace does is create a file with a name like DRVSPACE.nnn (with nnn being a three-digit number) that contains the compressed contents of the disk. The compressed file system is assigned the drive letter of the partition containing the file, and the latter (called the host drive in this context) is assigned another drive letter, or sometimes hidden entirely. If the partition from which Windows starts is compressed, HostWinBootDrv points to the host drive of that partition, which by default is H, while the other settings point to the compressed file system.
As for WinDir and WinBootDir, what they do is relatively easy to discover. Some experimentation reveals the following:
WinDir points to the directory in which Windows is installed. The presence of WinDir in MSDOS.SYS is what instructed IO.SYS (before Windows Me) that there was a Windows installation present that it should be prepared to launch (as opposed to just booting to a command prompt, like on an emergency boot floppy). If WinDir is set, the real-mode kernel will do the following:
- Put two entries in the
PATH environment variable: the directory pointed to by WinDir and its subdirectory COMMAND;
- Create a subdirectory
TEMP under this directory and point the environment variables TEMP and TMP to it;
- Clear a flag, returned by interrupt
0x2f service 0x1611 in BL register bit 5, which COMMAND.COM checks to decide whether to launch WIN.COM after processing AUTOEXEC.BAT;
- Start the device configuration manager before processing
CONFIG.SYS (this can be suppressed by the SystemReg=0 setting in the [Options] section)
- Look for certain critical files in this directory, including
SYSTEM.DAT (the Registry), COMMAND.COM (which will fall back to the root directory if absent) and real-mode drivers like HIMEM.SYS and IFSHLP.SYS (which can be suppressed by setting DOS=NOAUTO in CONFIG.SYS);
- Store the directory itself in the
winbootdir environment variable (all-lowercase!).
The last two of these is what can be overridden by setting WinBootDir: if that setting is present as well, those files will be looked up in WinBootDir instead, and of course it’s that directory which will end up in the winbootdir environment variable.
There are some wrinkles here however, for example with respect to WIN.COM. When the AUTOEXEC.BAT file is absent, empty or being skipped (like e.g. in Safe Mode), COMMAND.COM is not loaded and the real-mode kernel will instead directly execute WIN.COM from WinBootDir. However, if AUTOEXEC.BAT is present, COMMAND.COM will be launched to process it, after which it will in turn execute the command WIN, launching WIN.COM… by looking it up in PATH, which by default points to WinDir.
Well, great, but why are WinDir and WinBootDir separate settings at all? It is still not entirely clear to me, but from what little I can gather, it was probably meant to support booting Windows over a LAN. In such a configuration, DOS would first be loaded from a normal file system (or even itself from a disk image downloaded over the network), load essential drivers like HIMEM.SYS from WinBootDir located on the same file system, then load DOS network drivers, map a share (containing WinDir) to its drive letter, and then continue booting from there. If that’s the intended scenario, then even the WIN.COM oddity starts making sense now: there could be a ‘main’ Windows copy started when booting normally from WinDir, and another minimal ‘emergency’ copy booted in Safe Mode from WinBootDir, when network boot fails.
In any case, the requirements of this scenario could easily require those two settings to have different values. Here’s a short fragment from a document describing just such a configuration:
D-2. MSDOS.SYS Sample File for DM9102 :
=======================================
[Paths]
WinDir=g:\client1
WinBootDir=d:\winboot <== According to RAMDRIVE.SYS assign
HostWinBootDrv=c Virtual Drive (D: or E:)
There is also a paper and a series of articles by Micho Durdevich (part 1, 2, 3, 4, 5 and 6) that describe how to achieve network boot with Windows 9x.
They are somewhat scant on the details of how this all worked, but both those sources mention a SETMDIR utility, which is distributed as part of Windows 95. This implies that network booting was probably a use case intended by Microsoft.
