China DOS Union

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, with nothing newer to speak of.

　　But IO.SYS has made a fundamental change in how COMMAND.COM is handled. When WIN 9X loads the EMM386.EXE driver in CONFIG.SYS to provide UMB, the resident part of COMMAND.COM is loaded into HMA, and the transient part is loaded into UMB (in DOS 6.22, COMMAND.COM could only load the resident part into HMA). This provides more conventional memory for DOS programs and also avoids repeatedly restoring the transient part from disk, effectively improving system performance. Of course, if EMM386.EXE is not loaded and the system does not provide UMB, then the transient part of COMMAND.COM can only remain at the high end of conventional memory, just like in DOS 6.22.


VI. CONFIG.SYS and AUTOEXEC.BAT

　　CONFIG.SYS and AUTOEXEC.BAT in WIN 9X have the same function as in DOS: they are used 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, while AUTOEXEC.BAT is mainly used for software configuration. Their use in the boot process can be seen in the IO.SYS section.

　　After WIN 9X starts, the configuration in these two files remains as a global setting at the bottom level of the system, determining the DOS and WIN 16 application environment under WIN 9X. Without a global DOS setting, DOS applications in WINDOWS windows will use the default WIN 9X settings, though users can also configure them separately. Note that environment settings such as PATH and SET needed by DOS software can be configured 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 adds quite a few configuration commands, making the real-mode DOS environment more convenient to optimize. For the various configuration commands, see the CONFIG.TXT documentation in the system directory \WINDOWS; no more will be said here. WIN 9X uses protected-mode drivers such as VXD (virtual device drivers) and DLL (dynamic link libraries) to manage and use system software and hardware resources in a unified way, 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 further damaging system stability, so loading real-mode programs at startup should be avoided as much as possible.

　　The default DOS environment settings of WIN 9X can satisfy the needs of most DOS software. After completing the WIN 9X installation, trying to delete the contents of these two files is very necessary. Deleting the real-mode programs in them and implementing protected-mode drivers for WIN 9X as much as possible can put WIN 9X into an optimized operating 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 perform even better. In WIN 9X they are mainly retained to support old DOS software and ancient devices. At present, many newspapers and magazines recommend deleting these two files completely, but this is actually quite problematic. For a specific analysis, see the October 1999 issue of 《Computer World · Computer Expert》.

VII. WIN.COM

　　WIN.COM is the GUI startup command of 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. It is 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 in 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 Disable 32-bit disk access mode, 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 to start

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

: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 at startup are handled by ROM routines
Equivalent to setting in the section of SYSTEM.INI: VirtualHDIRQ=FALSE.

:X Prevent WINDOWS from using all upper memory (from A000-FFFF), solving 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 it is a core secret of Microsoft, unknown to outsiders. For ordinary users, however, there is no need to fully master this complex and ever-changing mechanism. Here I will only give a rough explanation of the overall GUI startup mechanism.

　　1. GUI configuration files

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

　　There are mainly 5 core configuration files of the GUI system, namely: WIN.INI, SYSTEM.INI, SYSTEM.DAT, USER.DAT, and POLICES.DAT.

　　WIN.INI and SYSTEM.INI are said to be 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 configuration through the system registry and do not need the support of these two files. This approach standardizes the development and use of application programs, eliminates the chaos of arbitrarily setting INI files, facilitates unified management of the system by WIN 9X, and increases system stability. But if these two files are deleted, WIN 9X cannot start and will prompt “Cannot find SYSTEM.INI file,” which shows that the startup of WIN 9X still cannot do without these two files.

　　WIN.INI provides all kinds of information needed by WIN 16 programs, such as font settings and file associations, mainly completing the corresponding environment configuration under the GUI. It does not have much impact on WIN 9X applications. If this file does not exist, WIN 9X will automatically generate a simplest WIN.INI containing only a few configuration lines.

SYSTEM.INI is different. It is the system hardware configuration file of WIN 16, and WIN 9X has added some new settings to it in order to ensure coordination between WIN 16 and WIN 32, so that WIN 16 can call VXD drivers; this has already been fully reflected in the system debugging parameters provided by WIN.COM. In addition, the GUI shell program (SHELL, that is, the interface program), drivers for the mouse, display, etc. 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 system of WIN 16 and WIN 32, and also reveals the fundamental reason for the congenital fragility of the WIN 9X system.

　　For the settings in WIN.INI and SYSTEM.INI, see 《New Trend Electronics Essence Vol. 1》.

　　SYSTEM.DAT and USER.DAT are the so-called system registry files, the core files of WIN 9X, through which WINDOWS manages the whole system. SYSTEM.DAT stores hardware configuration and software installation information, while USER.DAT stores information related to the user's personal settings. There can only be one of the former, while there can be multiple of the latter. These two files work together and contain all 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, beyond rescue. Unfortunately, the system registry is very fragile and lacks a mechanism for self-organization and maintenance. 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 backups of the registry are SYSTEM.DA0 and USER.DA0, stored under \WINDOWS; in WIN 98, the four files WIN.INI, SYSTEM.INI, SYSTEM.DAT, and USER.DAT are merged and backed up into one file RB00?.CAB, stored under \WINDOWS\SYSBCKUP, with 5 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 disturbed by incorrect information; in most cases the backup files are little more than decorations.

　　Regrettably, aside from the manual registry editing tool 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 an improvement, but it can only handle physical faults of the registry and cannot solve structural problems. And how reliable is it really?

　　The vast registry fully deserves a dedicated book for analysis. There is also a brief introduction in 《New Trend Electronics Essence Vol. 1》, so I will not go into deeper explanation here.

　　POLICES.DAT is Microsoft's MSN (Microsoft Network) registration support file. Few domestic users use that network, so this file is also seldom used.

　　Although there is no more direct material introducing it, there is ample reason to prove that during the startup process of WIN 9X, the various INF files stored in the \WINDOWS\INF directory are the most powerful supporting files in the WIN 9X system. During the process of starting the system, WIN 9X calls these files at the proper time in order to load the corresponding drivers. Without these files, WIN 9X also cannot start. In addition, the PNP technology of WIN 9X mainly implements driver installation through INF files.


2. The 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 begins to run, it first calls WININIT.EXE under \WINDOWS. This command looks for WININIT.INI in the same directory, and if it exists, it readjusts or upgrades system files according to that file's configuration, ensuring that the drivers of the whole system can be updated in time. This is the main path by which the WINDOWS system supports PNP technology and implements system driver upgrades. Naturally, this process is completed in DOS state.

　　⑵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, according to the configuration in SYSTEM.INI and the registry, begins starting the 16-bit protected mode of the GUI system. This ensures that the system supports WIN16 software, and more importantly, the PNP BIOS (Plug and Play BIOS) specification provides only a 16-bit protected-mode interface. WIN 9X, with PNP as the core of its hardware technology, must directly obtain hardware device information provided by the BIOS through 16-bit mode in order to configure the system and improve startup performance; otherwise, hardware configuration would have to start all over again in real mode.

　　GUI startup first loads the WIN 9X system drivers, then obtains hardware device information from the PNP BIOS, successively loads PNP device driver VXDs and all 16-bit virtual protected-mode driver VXDs required to support non-PNP hardware, allocates system resources, avoids device conflicts, and then initializes all drivers (including system drivers and device drivers), completing system hardware configuration. Finally, it loads 16-bit shell components such as USER.EXE, GUI.EXE, KRNL386.EXE, forming the WIN16 API and completing 16-bit protected-mode startup. At this point, every system component already exists, but there is still no usable interface.

　　⑶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 to the 32-bit kernel, beginning 32-bit protected-mode startup. At this time the system loads and initializes all 32-bit drivers; 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, defaulting to Explorer), completing GUI startup.

3. Troubleshooting during the GUI startup process

　　The GUI system is fairly complicated, yet the related technical materials are extremely scarce. This determines that users cannot troubleshoot according to 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 in the startup process and is the only basis for solving system problems. According to this record, one can comprehensively understand the various problems that occur during the GUI startup process.

　　When faced with startup failure, there are mainly two ways to handle it. One is to overwrite the problematic program with a good source copy, but the difficulty lies in how to find those good source programs in various software packages. Note that directly debugging and repairing the problematic program is nearly unimaginable under WIN 9X. The other is to delete, 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 that appear when some software fails to uninstall.

　　When solving system problems under graphical mode GUI, one is often subject to all kinds of 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 theme).

　　The complexity of the WINDOWS system determines how difficult it is to eliminate those baffling faults. If a problem still cannot be solved after adjusting the system several times, the safest and quickest method is to reinstall the system. Perhaps this is the only useful advice Microsoft has for users.

　　When reinstalling the system under WINDOWS, the product serial number must be kept the same, 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 system structure, so here is a simple summary of the entire boot process, enabling readers to make a relatively accurate judgment of the boot process according to what they observe during startup, and to better handle problems that arise during system startup.

　　⑴The system is powered on and starts, successively loading the BIOS programs of expansion cards (including the graphics card, etc.) and the motherboard (this is unrelated to all operating systems, such as WIN 9X, LINUX, UNIX, OS/2, etc.), completing the self-test process

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

　　⑶IO.SYS reads the MSDOS.SYS configuration, determines the boot 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 and interprets and executes AUTOEXEC.BAT to carry out 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 of SYSTEM.INI

　　⑽According to SYSTEM.INI, WIN.INI, and the system registry, combine and configure the system. The VXD files mainly called at startup are mostly stored under VMM32 and IOSUBSYS in C:\WINDOWS\SYSTEM

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

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

　　⒀After the user completes logon, the system executes the application programs contained 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 words

　　At last, the introduction to the WIN 9X boot process is finished. Because of the limitations of the author's knowledge and perspective, there are still many blanks left here for instruction from all you experts.

　　Admittedly, this process is itself quite an old topic, but most introductions are limited to partial tricks, and there are quite a few erroneous rumors, while comparatively systematic and complete ones are very rare. This has caused great confusion for the broad mass of computer enthusiasts. Here I have rashly made a fool of myself, really in order to correct some widespread misunderstandings, so that computer enthusiasts can have a relatively complete and clear grasp of the WINDOWS 9X boot process.

It was too long, I couldn't even finish reposting it in one go. ：）
I think whether you're studying windows or dos, this is a very good article.

There's one mistake in the OP: Win96 refers to Windows codename Nashville Build 999(4.10.999)

Also, WinVer refers to the Windows version number

That makes sense. For example, WinVer=3.2 means the Windows version number is 3.2, not WinVer=1995.8.24.

Support! Keep posting!

ok! Support!

It really is a good article

Where was this reposted from?

The following is a quote from Roy posted on 2003-3-10 22:22:45:
There's one mistake in the OP: Win96 refers to Windows codename Nashville Build 999(4.10.999)

Could you point out which line the mistake is on, so I can revise it?

The following is a quote from 红色狂想 posted on 2003-5-2 18:39:42:

The following is a quote from Roy posted on 2003-3-10 22:22:45:
There's one mistake in the OP: Win96 refers to Windows codename Nashville Build 999(4.10.999)

Could you point out which line the mistake is on, so I can revise it?

.
.
.
　　WIN 96 means the OSR1 edition of WIN 95 (it is called 96 because it was released in 1996; the same applies to 97). This version almost rewrote the WIN 95 kernel and corrected all kinds of problems WIN 95 had in practical use. Because its release time was too close to WIN 95, it was not widely circulated.
.
.
.

Sorry, could you post an example for me after the correction?