China DOS Union

Since the release of WIN 95, Microsoft has insisted on keeping the kernel technology of the WIN 9X system secret, making it difficult for users to obtain lower-level technical materials on the WIN 9X boot process. It has always been a black-box process. Mastering the system boot process is the key to fully controlling and optimizing the system. Now, based on public technical materials and practical experience, this article will comprehensively reveal the boot process of WIN 9X (including 95, 96 (95OSR1), 97 (95 OSR2.X), 98, 98SE) purely from the application angle, and give necessary explanations of the technical details.

　　The WIN 9X family mainly consists of four version series. Among them, WINDOWS 95 was the first version, and it was precisely this one that opened a new era in the PC world and pushed Bill Gates onto the throne of the world's richest man. This version was not perfect, had the most bugs, and Microsoft began providing patch packages a little over a month after its release.

　　WIN 96 is the OSR1 edition of WIN 95 (calling it 96 is because it was released in 1996; 97 is the same), and this version almost completely rewrote the WIN 95 kernel, correcting all kinds of problems WIN 95 had in actual use. Because it was released too soon after WIN 95, it did not spread widely.

　　WIN 97 is WIN 95 OSR2.X. This version made a qualitative leap. Its biggest changes were the introduction of the new FAT 32 disk format and integration of the Internet browser IE 3.0, which showed that Microsoft's system development strategy had begun shifting toward the Internet. OSR2.X has three versions: OSR2.0, OSR2.1, and OSR2.5. Among them, OSR2.1 supports USB and AGP graphics cards, while OSR2.5 provides IE4.0. Because FAT 32 made OSR2.X incompatible with WIN 95 and DOS, Microsoft only made it available as an OEM product and did not provide a retail edition, so WIN 97 became the most popular version after WIN 95.

　　WIN 98 was the last glory of the WINDOWS series built on DOS as its foundation. It tightly combined Internet technology with the operating system, and at the same time provided IE4.0 and DirectX5.0, but offered nothing more exciting, making it more like the retail edition of WIN 97.

　　WIN 98 SE is the second edition of WIN 98. Compared with WIN 98, it only added IE5.0 and DirectX6.1a, with nothing else new.

　　WINDOWS 2000 is a network operating system based on WINDOWS NT, already a completely different product from WIN9X, while the newly released WINDOWS Me is a replacement product for WINDOWS 9X, but aside from borrowing the WINDOWS 2000 interface, no newer discoveries have yet been found.

　　The evolution of WIN 9X versions is relatively complicated, but its core remained relatively stable, with no fundamental changes, and the boot process is also almost entirely the same. This is the basis for the existence of this article.


　　I. Overview of WIN 9X Booting

　　The boot process of WIN 9X inherits DOS tradition and makes necessary extensions. It mainly consists of two stages: extended DOS real-mode startup and GUI (that is, graphical interface) 32-bit protected-mode startup. The technical core of WIN 9X is concentrated in the latter stage.

　　This boot process is completed in sequence by the boot record, IO.SYS, MSDOS.SYS, COMMAND.COM, CONFIG.SYS, AUTOEXEC.BAT, the GUI startup command WIN.COM, and other necessary related files. Among them, the files that have exactly the same names as DOS system files have actually undergone qualitative changes.

　　WIN 95/96 provide a complete dual-boot function, meaning users can boot the system either with WIN 95/96 or with DOS (below 6.22), without interfering with each other, solving the compatibility problem between new and old systems and protecting users' interests to the greatest extent. But in order to gradually shake off the influence of outdated DOS on the PC world, beginning with WIN 97 Microsoft tried to restrict the dual-boot function, so the startup system of WIN 97/98 must be modified to achieve dual booting. At present, the actual need for dual booting has indeed become less and less.

　　II. Boot Record

　　The purpose of the boot record is to load the core files of the operating system into memory in order to start the system.

　　The boot records of all systems are located at the starting position of the disk. When a microcomputer is powered on, it directly loads the boot record from a fixed position into memory and boots the system. Naturally, the boot records of different versions of systems are different.

　　The DOS boot record version mark is MSDOS5.0. It supports FAT 12 (used by all versions for floppy disks or hard disks smaller than 16M) and FAT 16 disk formats, and the specified system boot files are IO.SYS and MSDOS.SYS.

　　The boot record of WIN 95/96 is fully compatible with DOS (standalone versions before 6.22), with the version mark MSWIN4.0. It supports FAT 12 and FAT 16 disk formats, supports dual booting, and specifies WINBOOT.SYS (the filename of IO.SYS when used under older DOS) and IO.SYS, MSDOS.SYS as the boot files.

　　The boot record of WIN 97/98 is fundamentally different from DOS, with the version mark MSWIN4.1. It uses 32-bit instruction code, supports FAT 12, FAT 16, and FAT 32 disk formats, and always boots IO.SYS, which means that without modification WIN 97/98 cannot directly support dual booting.

　　The brand-new FAT 32 disk format of WIN 97/98 can support large-capacity hard disks, removes the capacity limit of FAT 16, and is completely incompatible with traditional FAT 16, so of course DOS and WINDOWS 95/96 cannot recognize it. Under this disk format, most original DOS and WINDOWS 95/96 software can still run normally, but software related to disk format, such as disk tools, can no longer be used. Since mainstream hard disk capacities are now exceeding 8.4G, FAT 32 is being used more and more widely.

III. IO.SYS

　　1. The internal boot menu of IO.SYS

　　The IO.SYS of WIN 9X is formed by merging the original DOS system files IO.SYS and MSDOS.SYS. It provides input/output interfaces for standard hardware and DOS interrupt calls, with greatly enhanced functions. It basically controls the entire boot process of WIN 9X and is the core file of WINDOWS in DOS real mode. But it needs the settings in MSDOS.SYS in order to carry out a normal boot process.

　　IO.SYS can use startup function keys to change the boot process. These function keys correspond to the options on the boot menu:
Function key Corresponding boot menu item
F4： Previous MS-DOS version
F5： Safe mode
Shift+F5： Command prompt only
F6： Safe mode with network support
F8： Call up the boot menu during startup
Shift+F8： Step-by-step confirmation
Press the above function keys when “Starting Windows 95...” appears during system startup
IO.SYS provides a startup selection menu, convenient for users to choose the boot method they need:

　　⑴Normal
　　Normal startup mode (the default boot method)
　　When BootWin=0 in MSDOS.SYS, choosing this item will boot the old DOS

　　⑵Logged(BOOTLOG.TXT)
　　Normal startup mode, while also creating BOOTLOG.TXT in the root directory
　　BOOTLOG.TXT records everything that happened during the startup process. It is the only complete diagnostic record of the WIN 9X system boot process and can be used by users to check problems during startup

⑶Safe mode
　　The GUI of safe mode, with “Safe Mode” shown in the four corners of the screen. It does not load CONFIG.SYS or AUTOEXEC.BAT, nor any programs in the startup program group. It only loads the most basic hardware configuration (standard VGA mode, no sound card, CD-ROM drive, etc.), that is, the simplest GUI startup, used to correct GUI startup problems caused by hardware configuration and the like. When the system has problems and cannot start normally, in most cases it will enter this boot mode, but the problems this mode can solve are very limited. It is mostly used for display and other configuration issues. Major system configuration is mainly adjusted in Control Panel. To enter the normal GUI, a restart is required

　　⑷Step-by-step confirmation
　　Execute WINDOWS startup step by step
　　Used to determine startup failures caused by damaged system files. This method can only determine system problems during the DOS startup process, mainly to fix problems in Config.sys and Autoexec.bat. To determine problems during the GUI startup process, one can only rely on the BOOTLOG.TXT file

　　⑸Command prompt only
　　Execute only the complete real-mode DOS startup process, entering pure DOS status and loading all DOS drivers that support WIN startup. This is mainly used for application software that can only run in pure DOS mode or for solving serious system problems. The normal GUI can be started with the WIN command

　　⑹Safe mode command prompt only
The simplest DOS startup, executing only the three most basic system files IO.SYS, MSDOS.SYS, and COMMAND.COM, without loading the default drivers (HIMEM.SYS, IFSHLP.EXE, and SETVER.EXE), CONFIG.SYS, or AUTOEXEC.BAT. The other environment default values are the same as WIN 9X settings. Under this mode, normal or safe-mode GUI startup cannot continue. It is mainly used for handling the most serious system failures.

　　⑺Previous MS-DOS version
　　Boot the old DOS. To execute dual booting, the root directory should contain five original DOS system files saved with the .DOS extension. Whether this option appears is controlled by the “BootMulti” parameter in MSDOS.SYS. Note: when BootWin=0 in MSDOS.SYS, choosing this item will boot the normal WIN 9X system

⑻Safe mode with network support
Safe mode with real-mode network access. Whether this option appears is controlled by the “NetWork” parameter in MSDOS.SYS. It is used to eliminate PC faults in network systems, and through the real-mode network system, greater system support can be obtained

2. The extended DOS default configuration provided by IO.SYS

　　The biggest difference between IO.SYS and DOS during startup is that it provides a default CONFIG.SYS configuration that can satisfy most DOS applications, and can automatically load necessary drivers to ensure normal WIN 9X startup. The specific contents are as follows:

　　HIMEM.SYS　　　　　　　：supports memory above 1M, provides extended memory (XMS) management, and is a necessary file for WIN startup
　　DBLBUFF.SYS　　　　　　：double-buffer driver, loaded only when needed, mostly used to support SCSI cards
　　IFSHLP.EXE　　　　　　 ：enhanced file management driver, supports the VFAT system of WIN
A necessary file for WIN startup
　　SETVER.EXE　　　　　　 ：version reporting service, removes version restrictions, used only under DOS
　　Dblspace.bin　　　　　 ：DOS 6.0 disk compression driver, loaded only when the hard disk is compressed
　　Drvspace.bin　　　　　 ：disk compression driver for DOS 6.22 and later, same as above
　　DOS＝HIGH,UMB　　　　　：moves the DOS system into HMA to leave more conventional memory, while UMB has no effect on the system at all and is really just for show
　　FILES＝30　　　　　　　：maximum number of files that can be opened, enough for most applications, used only under DOS, WIN 9X does not need it
　　BUFFERS＝30　　　　　　：sets the maximum number of disk buffers, enough for most applications
used only by DOS, WIN 9X does not need it
　　FCBS＝4　　　　　　　　：number of file control blocks, now rarely used, used only by DOS
　　LASTDRIVE＝Z　　　　　 ：maximum drive-letter setting; if this value is set too small, the CD-ROM drive cannot be loaded
　　STACKS＝9,256　　　　　：sets the number and size of stacks; this setting is for old programs, WIN 9X does not need it
　　SHELL＝COMMAND.COM/P　 ：specifies the WIN 9X command-line interpreter

The system environment settings provided by IO.SYS are as follows:

Command search path ： PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
DOS prompt ： PROMPT=$P$G
Temporary file directory ： TEMP=TMP=C:\WINDOWS\TEMP
Command-line interpreter location：COMSEPC=C:\WINDOWS\COMMAND\COMMAND.COM

　　IO.SYS provides fairly complete system configuration, making it possible to remove CONFIG.SYS and AUTOEXEC.BAT. For compatibility reasons, IO.SYS does not load the EMM386.EXE driver and does not provide expanded memory EMS or upper memory UMB. EMM386.EXE may cause the system to hang when the system searches for new hardware, but there will be no problem in daily use.



　　3. The boot process under IO.SYS control

　　⑴When the system starts, IO.SYS displays “Starting Windows 95...”, and at this time the startup function keys can be used to choose the boot method.

　　⑵IO.SYS determines the boot mode according to the boot menu choice and the MSDOS.SYS configuration.

　　⑶If the original DOS system is used, IO.SYS automatically swaps the DOS and WIN 9X system boot files, after which the original DOS controls the boot process. (That is, the dual-boot process of WIN 9X is ultimately controlled and completed by IO.SYS, and has nothing to do with the boot record and the like.)

　　⑷According to the boot mode, IO.SYS first performs system hardware configuration through CONFIG.SYS. If CONFIG.SYS does not load the files required for WIN 9X startup (such as HIMEM.SYS, IFSHLP.EXE, etc.), the system will automatically load them according to default settings. (If drivers that use extended memory are to be loaded, such as EMM386.EXE, HIMEM.SYS must be added on the first line of CONFIG.SYS, otherwise because the system has not yet provided extended memory at this point, programs such as EMM386.EXE will not be able to run.)

　　⑸After completing hardware configuration such as CONFIG.SYS, IO.SYS calls AUTOEXEC.BAT through COMMAND.COM for software configuration.

　　⑹BOOTLOG.TXT in the root directory is completed under IO.SYS control; some other log files were mostly created when the system was installed.

　　⑺After completing the DOS startup process, WIN.COM is automatically called to begin GUI startup.

IV. MSDOS.SYS

　　1. The role of MSDOS.SYS

　　In WIN 9X, MSDOS.SYS became a plain-text system configuration file used to control the WIN boot method. Its special attributes (read-only, hidden, system) can be removed under DOS mode and it can be configured by the user as needed. MSDOS.SYS can be an empty file, and can even be deleted, though in that case the system can only boot in pure DOS mode and cannot enter the GUI system.

　　The default contents of MSDOS.SYS differ depending on how it is created. There are mainly four types. In the first three methods, the MSDOS.SYS file contains no configuration commands at all and is almost an empty file, retaining only one comment line explaining how the file was created. Such files are mostly seen on system floppy disks. The contents of the different MSDOS.SYS files are as follows:

1) System disk created during WIN installation : ;WIN95EBO
2) System disk created by FORMAT /S : ;FORMAT
3) System disk created by SYS A：transfer : ;SYS
4) MSDOS.SYS created on the hard disk when the system is established

　　The MSDOS.SYS on the system hard disk has relatively complete contents, including necessary startup configuration commands. The file length must be greater than 1024 bytes, that is, occupy more than two disk sectors. This requirement is explained within the file as being for compatibility, but no deeper explanation has ever been seen. In fact, if the file is smaller than 1024 bytes, there is no obvious effect on the system. This requirement is probably intended to ensure compatibility with older DOS and WIN 3.X, but I still hope experts can offer guidance on this point.

　　When using SYS to transfer the system to the hard disk to repair startup files, the boot record, IO.SYS, and COMMAND.COM will be overwritten, but the content of MSDOS.SYS remains unchanged, ensuring that after the boot portion is repaired the entire system can still start normally. This is a very clever approach.

2. The configuration parameters of MSDOS.SYS

　　MSDOS.SYS consists of three sections. Its configuration parameters have no required order. The contents are as follows:
　　　　　specifies the paths of WINDOWS system files
　　　WinDir＝　　　　　specifies the directory where all WIN 9X system files and their subdirectories are located
　　　　　　　　　　　　this path must include the registry file SYSTEM.DAT and the drivers required for WIN 9X startup, such as HIMEM.SYS
　　　WinBootDir＝　　　specifies the directory where the WIN 9X GUI startup program WIN.COM is located
　　　HostWinBootDrv＝　specifies the drive where WIN.COM is located, without a colon (
　　　UninstallDir＝　　specifies the directory where the original system is saved, for restoring the original system when uninstalling itself
　　　　　　　　　　　　this parameter appears in upgrade editions of WIN
　　　 specifies the startup method of WINDOWS; the value before / is the default value
　　　LOGO＝1/0　　　　allow/disallow displaying the WIN 9X logo (LOGO) during startup
　　　　　　　　　　　hiding this screen can sometimes solve conflicts caused by third-party memory managers 　　　　　　　　　　　it also lets you see prompt messages that appear during system startup, and makes the system start a little faster
　　　　　　　　　　　during startup, the ESC key can be used to clear the WIN 9X logo and view real-mode startup information
　　　BootKeys＝1/0　 allow/disallow using startup keys to change the startup mode
　　　　　　　　　　　when set to 0, it directly enters the default startup mode and startup hotkeys cannot be used to switch
　　　BootGUI＝1/0　　boot the graphical interface GUI / boot only DOS 7.X and enter the DOS character interface
　　　　　　　　　　　when 0, it can make DOS 7.X multi-booting more convenient, and the graphical interface can still be started further
　　　BootWin＝1/0　　boot WIN 9X / boot the previous version of DOS; system files can be swapped as required
　　　　　　　　　　　when BootWin＝0, the default is to boot the old DOS. If at this time the startup menu item
　　　　　　　　　　　“Previous MS-DOS version” is selected, WIN 9X will be started
　　　　　　　　　　　note: BootWin has a higher priority than BootGUI; when the two conflict, the former prevails
　　　BootMulti＝0/1　disallow/allow dual booting
　　　　　　　　　　　that is, whether the “Previous vertion of MS DOS” item appears on the startup menu
　　　　　　　　　　　when upgrading from old DOS to WIN 9X this item will appear automatically and be set to　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　1, but for WIN 97/98, if the boot system is not modified, selecting this item will cause the system to fail to boot next time
BootMenu＝0/1　 whether the startup selection menu is automatically displayed when the system starts
　　　　　　　　　　　when this value is 1, the startup selection menu will pop up directly during startup
　　　Network＝0/1　　whether the “Safe mode with network support” item appears on the startup menu
　　　　　　　　　　　that is, the “Safe mode with network support” item
　　　BootDelay＝n　　the time for displaying “Starting WINDOWS 95...” before system boot, default 2 seconds, for using startup keys to change the startup mode. When this value is 0, no prompt appears and it directly enters the default startup process, which can speed up startup, but startup hotkeys can still be used to choose the startup method

　　　BootMenuDefault＝　the default option used by the startup menu, default value 1
　　　BootMenuDelay＝　the delay before the startup menu boots by default, default 30, unit: seconds
　　　BootSafe＝0/1　　whether the system starts in safe mode; when 1 the system directly starts in safe mode
　　　BootWarn＝1/0　　whether warning information is displayed during startup
　　　　　　　　　　　when the system is restarted after an abnormal shutdown, whether it prompts “should enter safe mode” In fact, safe mode has very limited ability to solve problems; real system problems cannot be solved in this mode, so not entering it is no great loss
　　　BootConfig＝1/0　 whether step-by-step configuration mode can be used; its purpose is unclear
　　　DisableLog＝0/1　 whether BOOTLOG.TXT is created during “Step-by-step config”
　　　　　　　　　　　1：if “Logged” is not selected, it neither asks nor creates Bootlog.txt
　　　　　　　　　　　0：asks whether to create the log file Bootlog.txt
　　　SystemReg＝1/0　　whether to run the WINDOWS 9X registry checker when the system starts
　　　　　　　　　　　1：under “Step-by-step config” it asks whether to run the registry checker
　　　　　　　　　　　　in other modes it runs the registry checker automatically
　　　　　　　　　　　　0：does not run it and does not ask whether to run the WINDOWS 9X registry checker
　　　　　　　　　　　　this registry checker runs first before the entire system starts, but whether it runs has no obvious effect on the system, and its purpose is unclear
LoadTop＝1/0　　　whether to load COMMAND.COM, Drvspace.bin, Dblspace.bin, etc. into upper memory; if a memory address conflict occurs during startup, this value can be set to 0
　　　　　　　　　　　　such conflicts are mostly caused by programs loaded by CONFIG.SYS and AUTOEXEC.BAT Autoscan＝1/0
　　　　　　　　　　　　when restarting after an abnormal shutdown (such as power failure), whether to automatically execute SCANDISK
　　　　　　　　　　　　(valid only in WIN 97/98)
　　　　　　　　　　　　although disabling automatic hard disk checking can spare some trouble, it really does bring hidden dangers to the system, so it is better not to turn it off

　　　DoubleBuffers＝1/2/0 　whether to load BDLBUFF.SYS and provide double-buffer support
　　　　　　　　　　　　　　0：do not provide it; 1：provide it when needed, such as when there is a SCSI card;
　　　　　　　　　　　　　　2：always provide double buffering
　　　DblSpace＝1/0　　　allow automatic loading of the DblSpace.bin compression driver when needed (DOS6.0, 6.2)
　　　DrvSpace＝1/0　　 allow automatic loading of the DrvSpace.bin compressed-disk driver (DOS6.22, WIN 9X)
　　　　　　　　　　　　compressed hard disks lower overall system performance and also increase the danger to data
　　　　　　　　　　　　now that hard disk capacity is no longer much of a problem, it is better not to use compression
　　　　　　　　　　　　note that FAT32 does not support any disk compression software
　　　WinVer＝　　　　　indicates the official release date of the WINDOWS version

The third section consists of several lines of arbitrary characters beginning with a semicolon “;”. In MSDOS.SYS these are comment lines and have no configuration effect on the system. Their main purpose is to ensure the length of the MSDOS.SYS file exceeds 1024 bytes.

　　Most of the parameters provided by MSDOS.SYS are used for adjusting the system. For ordinary users, the commonly used ones mainly include the several parameters before NetWork.


V. COMMAND.COM

　　COMMAND.COM is the DOS shell program (SHELL) in WINDOWS 9X. Compared with DOS 6.22, it only adds some internal commands and has nothing newer.

　　But IO.SYS handles COMMAND.COM in a fundamentally changed way. When WIN 9X loads the EMM386.EXE driver in CONFIG.SYS to provide UMB, the resident portion of COMMAND.COM is loaded into HMA and the transient portion into UMB (in DOS6.22, COMMAND.COM can only load the resident portion into HMA). This gives DOS programs more conventional memory and also eliminates the need to repeatedly restore the transient portion from disk, effectively improving system performance. Of course, if EMM386.EXE is not loaded and the system does not provide UMB, then the transient portion of COMMAND.COM can only be placed in the upper area of conventional memory just as in DOS6.22.

（To be continued in the next post: because of the post size limit, it has been split into two posts）。

Continued from the previous post:

VI. CONFIG.SYS and AUTOEXEC.BAT

　　In WIN 9X, CONFIG.SYS and AUTOEXEC.BAT serve the same purpose as in DOS: to load all DOS real-mode drivers and application programs, or to modify the default configuration of IO.SYS. Among them, CONFIG.SYS is mainly used for hardware configuration, and AUTOEXEC.BAT mainly for software configuration. For their use in the boot process, see the IO.SYS section.

　　After WIN 9X starts, the configurations in these two files are retained at the bottom level of the system as global settings, determining the environments for all DOS and WIN 16 applications under WIN 9X. If there are no DOS global settings, DOS application programs under WINDOWS windows will use the default settings of WIN 9X, though of course users can also configure them separately. Note that environment settings such as PATH and SET needed by DOS software can be set separately in the properties of each window; environment settings such as PATH and SET needed by 16-bit WIN 3.X software can only be set in AUTOEXEC.BAT.

　　WIN 9X added quite a few configuration commands, making the real-mode DOS environment easier to optimize. For these configuration commands, see the explanation in CONFIG.TXT under the \WINDOWS system directory; there is no need to say more here. WIN 9X uses protected-mode drivers such as VXD (virtual device drivers) and DLL (dynamic link libraries) to uniformly manage and use system software and hardware resources, and basically does not need real-mode program support. Real-mode programs are mainly retained to support some old devices. The existence of real-mode programs forces WIN 9X to switch frequently between protected mode and real mode, greatly reducing system performance and also harming system stability, so real-mode programs should be avoided as much as possible during startup.

　　WIN 9X's default DOS environment settings can satisfy most DOS software. After completing WIN 9X installation, it is very necessary to try deleting the contents of these two files. Deleting the real-mode programs in them and implementing WIN 9X protected-mode drivers as much as possible can put WIN 9X into an optimized running state of high performance and high stability.

　　A DOS system without CONFIG.SYS and AUTOEXEC.BAT can do almost nothing, while a WIN 9X without them may actually perform better. In WIN 9X they are mainly retained to support original DOS software and ancient devices. At present, many newspapers and magazines recommend deleting these two files completely, but this is actually very problematic. For a specific analysis, see Computer World · Computer Expert, October 1999.

VII. WIN.COM

　　WIN.COM is the GUI startup command for WINDOWS. From the filename it can be seen that this is a pure DOS command, and it is also the only COM file in the GUI system. This command is the interface command between DOS and GUI, mainly used to load the protected-mode virtual device driver VMM32.VXD (this program is composed of multiple subprograms and makes the CPU run in protected mode), while also handling various problems during GUI startup. It controls the entire loading process of the system.

The various startup switches provided by WIN.COM are mainly used to determine system faults, and will reduce system performance:
WIN

/D Used to find the cause of faults when WINDOWS cannot start normally

:F Turn off 32-bit disk access mode, used for hard disks that do not support 32-bit access
Equivalent to setting in the section of SYSTEM.INI: 32BitDiskAccess=FALSE.

:M Start in safe mode, equivalent to using the function key F5 at startup

:N Start in safe mode with real-mode network support, equivalent to using the function key F6 at startup

:S Prevent Windows from using the ROM address space between F000:0000 and 1 MB as a breakpoint
Equivalent to setting in the section of SYSTEM.INI: SystemROMBreakPoint=FALSE.

:V Specify that hard disk controller interrupts are handled by ROM routines during startup
Equivalent to setting in the section of SYSTEM.INI: VirtualHDIRQ=FALSE.

:X Prevent WINDOWS from using all upper memory (from A000-FFFF), to solve memory conflict problems
Equivalent to setting in the section of SYSTEM.INI: EMMExclude=A000-FFFF.

VIII. GUI Startup

　　The GUI startup process of WIN 9X is extremely complicated, and even more so is it a core Microsoft secret unknown to outsiders. But for ordinary users, it is unnecessary to completely master this complex and changeable mechanism. Here only a rough explanation of the entire GUI startup mechanism will be given.

　　1. GUI configuration files

　　Like all complex systems, WIN 9X mainly combines the system and ensures its normal operation by calling various types of programs according to system configuration files. The GUI system configuration files of WIN 9X are centered on the system registry, with INI files under various system directories as auxiliary configuration. Once you grasp the system configuration files, you grasp the core of the system.

　　The main core configuration files of the GUI system are five in total: WIN.INI, SYSTEM.INI, SYSTEM.DAT, USER.DAT, and POLICES.DAT.

　　WIN.INI and SYSTEM.INI are said to have been retained for WIN 16 protected-mode programs under WIN 3.X. Most settings in these two files for WIN 3.X have already been moved into the system registry in WIN 9X. WIN 32 protected-mode programs under WIN 9X mainly complete their configuration through the system registry and do not need the support of these two files. This approach standardized the development and use of applications, eliminated the chaos of arbitrary INI file settings, made it easier for WIN 9X to manage the system uniformly, and increased system stability. But if these two files are deleted, the WIN 9X system cannot start and will prompt “Cannot find SYSTEM.INI”, which shows that WIN 9X startup still cannot do without these two files.

　　WIN.INI provides font settings, file associations, and various other information needed by WIN 16 programs, mainly completing the corresponding environment configuration under the GUI. It has little effect on WIN 9X applications. If this file does not exist, WIN 9X will automatically generate a simplest WIN.INI with only a few configuration lines.

SYSTEM.INI is different. It is the WIN 16 system hardware configuration file, and WIN 9X has added some new settings to it to ensure coordination between WIN 16 and WIN 32, allowing WIN 16 to call VXD driver programs. This is already fully reflected in the system debugging parameters provided by WIN.COM. In addition, the GUI shell program (SHELL, that is, the interface program), mouse, display, and other drivers must be loaded and used through SYSTEM.INI settings. These determine that SYSTEM.INI absolutely cannot be deleted. This fully proves that WIN 9X is a mixed WIN 16 and WIN 32 system, and also reveals the fundamental reason why WIN 9X is inherently fragile.

　　For the settings in WIN.INI and SYSTEM.INI, see New Trend Electronics Digest 1.

　　SYSTEM.DAT and USER.DAT are the so-called system registry files, the core files of WIN 9X, and WINDOWS manages the entire system through them. SYSTEM.DAT stores hardware configuration and software installation information, while USER.DAT stores information related to the user's personal settings. The former can only have one copy, while the latter can have multiple copies. These two files work together and contain all the information of the system. When using registry editing software (such as REGEDIT.EXE), these two files are modified together and cannot be separated. Damage to them will cause the system to collapse completely and be beyond rescue. Unfortunately, the system registry is very fragile and lacks self-organizing and maintenance mechanisms. After the system has run for some time, users often can only embark on the painful road of rebuilding the system.

　　In WIN 95/96/97, the registry backups are SYSTEM.DA0 and USER.DA0, stored under \WINDOWS; in WIN 98, WIN.INI, SYSTEM.INI, SYSTEM.DAT, and USER.DAT are merged and backed up into a single file RB00?.CAB, stored under \WINDOWS\SYSBCKUP, with 5 copies retained by default.

　　Each time the GUI starts, the system automatically updates the backup files. This handling lacks a safety management mechanism and can hardly ensure that the backup files are not affected by bad information. In most cases the backup files are useless in practice.

　　Regrettably, aside from the manual registry editor REGEDIT.EXE, WIN 9X provides no more effective registry maintenance tool. WIN 98 provides the registry checking software ScanReg.exe and ScanRegw.exe, which is a step forward, but it can only handle physical faults in the registry and cannot solve structural problems. And how reliable is it really?

　　The vast registry fully deserves a monograph of its own for analysis. There is also a simple introduction in New Trend Electronics Digest 1, so no deeper explanation will be given here.

　　POLICES.DAT is Microsoft's MSN (Microsoft Network) registration support file. Since there are few domestic users of this network, this file is rarely used as well.

　　Although there is no more direct information introducing this, there are sufficient reasons to prove that during the WIN 9X startup process, the various INF files stored under \WINDOWS\INF are the most powerful supporting files in the WIN 9X system. During system startup, WIN 9X will call these files at appropriate times to load the corresponding drivers. Without these files, WIN 9X also cannot start. In addition, WIN 9X's PNP technology mainly implements driver installation through INF files.


2. GUI startup process

　　The GUI startup process mainly consists of three stages: the WININIT.EXE stage, 16-bit protected-mode startup, and 32-bit protected-mode startup.

　　⑴WININIT.EXE stage After WIN.COM starts running, it first calls WININIT.EXE under \WINDOWS. This command looks for WININIT.INI in the same directory. If it exists, it readjusts or upgrades system files according to the configuration of that file, ensuring that the drivers of the entire system can be updated in time. This is the main way the WINDOWS system supports PNP technology and performs system driver upgrades. Naturally, this process is completed under DOS.

　　⑵16-bit protected-mode startup

　　After WIN.COM begins execution, it loads VMM32.VXD under \WINDOWS\SYSTEM. VMM32.VXD puts the processor into protected mode and begins starting the 16-bit protected mode of the GUI system according to the configuration in SYSTEM.INI and the registry. This ensures support for WIN16 software, and more importantly, the PNP BIOS (Plug and Play BIOS) specification only provides a 16-bit protected-mode interface. WIN 9X, with PNP as the hardware technology core, must directly obtain hardware device information provided by the BIOS through 16-bit mode to configure the system and improve startup performance; otherwise hardware configuration would have to begin again from scratch in real mode.

　　GUI startup first loads the WIN 9X system drivers, then obtains hardware device information from the PNP BIOS, then successively loads PNP device-driver VXD files and all 16-bit virtual protected-mode driver VXD files needed to support non-PNP hardware, allocates system resources to avoid device conflicts, and then initializes all drivers (including system drivers and device drivers) to complete system hardware configuration. Finally it loads 16-bit shell components USER.EXE, GUI.EXE, KRNL386.EXE, etc., forming the WIN16 API and completing 16-bit protected-mode startup. At this point every system component already exists, but the user interface is not yet usable.

　　⑶32-bit protected-mode startup

　　After 16-bit mode startup is completed, the system calls the 32-bit shell program Explorer. As soon as the 16-bit kernel sees this call, it first automatically loads VWIN32.386, which in turn loads three 32-bit DLL library files: USER32.DLL, GDI32.DLL, and KERNEL32.DLL, forming the WIN32 API (this is the core of WIN 9X). After VWIN32.386 completes this task, it returns control to the 16-bit kernel, which then hands control over to the 32-bit kernel and begins 32-bit protected-mode startup. At this point the system loads and initializes all 32-bit drivers, and this process is the same as in 16-bit mode.

　　Finally, it runs the GUI shell program (this shell program is set by “SHELL=” in the section of SYSTEM.INI, and by default is Explorer), completing GUI startup.

3. Troubleshooting faults during GUI startup

　　The GUI system is fairly complex, yet there is very little related technical material. This determines that users cannot troubleshoot faults from the startup process the way they can in DOS.

　　WIN 9X has never provided a detailed explanation of the GUI startup process, only a startup log file BOOTLOG.TXT in the root directory. This file records the loading status of all program modules used during the startup process and is the only basis for solving system problems. From this record one can fully understand the various problems that occurred during GUI startup.

　　When facing startup failure, there are mainly two methods of handling it. One is to overwrite the problematic program with a good original program, but the difficulty lies in how to find those good original programs among various software packages. Note that directly debugging or repairing the problematic program is almost unimaginable under WIN 9X. The other is to remove from the startup configuration files (CONFIG.SYS, AUTOEXEC.BAT, WIN.INI, SYSTEM.INI, and the registry) the commands that call the problematic module. The latter is mainly used to solve problems caused by failed software uninstallation.

　　When solving system problems under graphical GUI mode, one is often subject to various restrictions, while pure DOS mode is not constrained by the system and is the final gate of the system (for computer experts, DOS remains an eternal topic).

　　The complexity of the WINDOWS system determines how difficult it is to eliminate those baffling faults. If the problem still has not been solved after several rounds of system adjustment, the safest and quickest method is to reinstall the system. Perhaps this is the only useful advice Microsoft gives users.

　　When reinstalling the system under WINDOWS, the product serial number must be kept consistent, otherwise the system may refuse installation.

　　IX. Summary of the WIN 9X boot sequence

　　This article has discussed the WIN 9X boot process in detail. The complicated parameters and technical analysis have blurred its clear architecture, so now the entire boot process will be summarized briefly, so that readers can make relatively accurate judgments about the boot process based on the phenomena seen during startup, and handle problems in the system startup process better.

　　⑴When the system is powered on, it successively loads the BIOS programs of expansion cards (including the graphics card, etc.) and the motherboard (this has nothing to do with any operating system, such as WIN 9X, LINUX, UNIX, OS/2, etc.), and completes the self-test process

　　⑵Read in the hard disk master boot record and partition boot record, then automatically load IO.SYS

　　⑶IO.SYS reads the MSDOS.SYS configuration, determines the startup method, and performs hardware configuration according to CONFIG.SYS

　　⑷According to WIN 9X startup requirements, IO.SYS automatically loads the necessary default drivers (HIMEM.SYS, SETVER.EXE, IFSHLP.SYS, etc.)

　　⑸IO.SYS loads COMMAND.COM, interprets and executes AUTOEXEC.BAT, and performs software configuration


⑹IO.SYS performs the necessary default environment settings

　　⑺Automatically execute WIN.COM and enter the GUI startup stage

　　⑻Execute WININIT.EXE to upgrade system drivers

　　⑼Load the drivers specified in sections such as , , and in SYSTEM.INI

　　⑽Combine and configure the system according to SYSTEM.INI, WIN.INI, and the system registry. The various VXD files called during startup are mainly stored in VMM32 and IOSUBSYS under C:\WINDOWS\SYSTEM

　　⑾Load the shell program specified by “SHELL=” in SYSTEM.INI

　　⑿Execute the application programs included in Run and RunOnce under HKEY_LOCAL_MACHINE→Software→Microsoft→Windows→CurrentVersion in the system registry (programs included in RUNONCE are automatically deleted after running once; this key is mainly used for software installation). Usually it loads Internat.exe (input method), Systray.exe (volume control), and ScanRegw.exe/autorun in WIN 98 by default.

　　⒀After the user completes logon, the system executes the application programs included in Run and RunOnce under HKEY_CURRENT_USER→Software→Microsoft→Windows→CurrentVersion

　　⒁Execute the application programs loaded by LOAD= and RUN= in WIN.INI

　　⒂Execute the application programs included in the group in the Start Menu

　　X. Closing remarks

　　The introduction to the WIN 9X boot process has finally been completed. Because of the limitations in the author's knowledge and perspective, there are still many blanks left here for the experts to instruct me on.

　　To be sure, this process is itself quite an old topic, but most introductions are limited to partial tricks, and there are many false reports, while relatively systematic and complete ones are very rare. This has brought great confusion to the broad body of computer enthusiasts. Here I have rashly made a display of my poor skill, really in order to correct some circulating misunderstandings, so that computer enthusiasts may have a relatively complete and clear grasp of the WINDOWS 9X boot process.