Architecture of Windows 9x

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages) This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. See Wikipedia's guide to writing better articles for suggestions. (January 2018) (Learn how and when to remove this template message) This article may be confusing or unclear to readers. Please help clarify the article. There might be a discussion about this on the talk page. (January 2018) (Learn how and when to remove this template message) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Architecture of Windows 9x" – news · newspapers · books · scholar · JSTOR (January 2018) (Learn how and when to remove this template message) (Learn how and when to remove this template message)

The Windows 9x series of operating systems refers to the monolithic kernel which powers these operating systems. The basic code is similar in function to MS-DOS. As a 16-/32-bit hybrid, it requires support from MS-DOS to operate.

Critical files

Windows 95 boots using the following set of files:^[1]

32-bit shell and command line interpreter:

• SHELL.DLL and SHELL32.DLL - Shell API
• EXPLORER.EXE
  - Windows shell and file manager
• COMMAND.COM - Command line shell executable

Windows 95 core:

• KERNEL32.DLL and KRNL386.EXE
  – Windows API for Windows resources
• ADVAPI32.DLL
  - Functionality additional to the kernel with included functions for the Windows registry and shutdown and restart functions
• GDI32.DLL and GDI.EXE - Graphic device interface
• USER32.DLL and USER.EXE
  - GUI implementation
• COMCTL32.DLL
  - Common controls (user interface)
• DDEML.DLL Dynamic Data Exchange Management Library (DDEML) - Provides an interface that simplifies the task of adding DDE capability to an application
• MSGSRV32.EXE - Acts as a 32-bit message server and will never appear in the Windows task list
• WIN.COM - Responsible for loading the GUI and the Windows portion of the system

Registry and other configuration files:

• USER.DAT - Contains the Windows Registry
• GUI
  logo
• WIN.INI and SYSTEM.INI - Configuration files from Windows 3.1 which are processed in Windows 9x also

Virtual Machine Manager and configuration manager:

• VMM32.VXD
  - Virtual machine manager and default drivers. It takes over from io.sys as kernel

Installable file System Manager:

• IFSHLP.SYS
  - Enables Windows to make direct file system calls; bypassing MS-DOS methods
• IFSMGR.VXD - 32-bit driver for the installable file system
• IOS.VXD - I/O supervisor that controls and manages all protected-mode file system and block device drivers
• MPREXE.EXE, MPRSERV.DLL and MPR.DLL - Multiple Provider Router for network authentication and user profiles
• MSPWL32.DLL - Password list management library

Device drivers:

• I/O
  routines and also serves as kernel until vmm32.vxd takes over
• HIMEM.SYS - DOS device driver which allows DOS programs to store data in extended memory via the Extended Memory Specification
• SYSTEM.DRV, MMSOUND.DRV, COMM.DRV , VGA.DRV, MOUSE.DRV, BIGMEM.DRV, KEYBOARD.DRV - 16-bit drivers
• CP 1252.NLS, CP 437.NLS, UNICODE.NLS, LOCALE.NLS - Keyboard layouts
• RMM.PDR - Real Mode Mapper Virtual Device

The system may also use

may be used as a splash screen.

Boot sequence

The Windows 9x startup process consists of 6 phases. The first two of these steps are common to any

Master Boot Record

.

Phase 1 - The ROM BIOS bootstrap process

The

Plug and Play

devices, disables found devices, creates maps of used and unused resources and re-enables devices.

Phase 2 - The master boot record and boot sector

The

BIOS Parameter Block

table which searches for the location of the root directory and IO.SYS file, which then loads the IO.SYS file into memory.

Phase 3 - IO.SYS file initialisation

file exists, it also loads drivers for compressed disks. Windows then attempts to open the registry file SYSTEM.DAT. If that fails, it attempts to open SYSTEM.DA0. If configured in MSDOS.SYS or in the registry, double buffering is also enabled.

Phase 4 - CONFIG.SYS and real mode configuration

Windows 95 and Windows 98 now analyse CONFIG.SYS and load MS-DOS real mode drivers. Windows ME ignores this. If the CONFIG.SYS file does not exist, the IO.SYS file loads the drivers

. Windows 95 and 98 execute

terminate and stay resident

programs into memory. Windows ME ignores this step, as Real Mode DOS support is disabled and TSRs being loaded can compromise system stability.

Phase 5 - Initialise drivers

IO.SYS now runs

VMM32.VXD

file into memory or accesses it from the hard disk. This file contains the most important drivers and the 9x kernel. The real-mode virtual device driver loader checks for duplicate virtual device drivers that exist both in the Windows\System\Vmm32 folder and the VMM32.VXD file. In a case of duplicates, the driver in the Windows\System\Vmm32 directory will be loaded.

Windows 95 to 98 now query real mode drivers calling INT 2Fh and search for drivers in registry entry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD marked to be loaded as an external file. Vmm32 then analyzes the [386 Enh] section of the Windows\System.ini file and loads drivers listed there. Some important drivers are loaded even if they are not listed in the Windows Registry, SYSTEM.INI or in the Windows\System\Vmm32 directory.

Once the real-mode virtual device drivers are loaded, driver initialisation on Windows 95 and 98 occurs. Vmm32 then switches the CPU from real mode to protected mode. The next step is the initialisation of protected mode drivers, executed in three phases for each device: a critical part of initialisation (while interrupts are disabled), device initialisation (when file I/O is allowed) and InitComplete phase. After initialisation of the display driver, Windows switches to graphical mode.

Phase 6 - Win32 initialisation

Once all of the drivers are loaded, the

and programs defined in registry keys Run, RunOnce, RunServices and RunServicesOnce inside the branches HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion and HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\. After each program in the RunOnce registry key is started, the program is removed from the key.

Kernel

The Windows 9x kernel is a 32-bit kernel with virtual memory. Drivers are provided by .VXD files or, since Windows 98, the newer WDM drivers can be used.^[2] However, the MS-DOS kernel stays resident in memory. Windows will use the old MS-DOS 16-bit drivers if they are installed, except on Windows Me. In Windows Me, DOS is still running, but Windows will ignore any attempt to load its device drivers when parsing the AUTOEXEC.BAT, and will move the environment variables that it still recognizes from the CONFIG.SYS into the Windows Registry.

See also

• Architecture of Windows NT
• Microsoft Windows
• Caldera v. Microsoft
• WinGlue
• FreeWin95

References

Further reading

• Schulman, Andrew (November 1994). Unauthorized Windows 95 - Developer's Resource Kit (1st ed.). Foster City, California, USA:
  ISBN 978-1-56884-305-6
  .
• Schulman, Andrew;
  ISBN 978-0-201-63287-3. (xviii+856+vi pages, 3.5"-floppy) Errata: [1][2]
• Paul, Matthias R. (2002-04-10). "[fd-dev] HMA access from TSR". freedos-dev. Archived from the original on 2017-09-09. Retrieved 2017-09-09. [...]
  MS-DOS 7.0+ [...] introduced a [...] for the most part undocumented RMD data structure usually located in the HMA. The kernel collects and records configuration and Real Mode Driver data during boot (type of driver, interrupts hooked by driver, CONFIG.SYS
  line of invocation, etc.) and stores this information in a [...] complicated [...] growing data structure. Presumably [...] meant to be used by the Windows core to get a better picture of the loaded Real Mode drivers [...] or even attempt to unhook or unload some of them, [...] it is only used to a very limited extent ([...] some of the info reflected in the log files created on [...] startup, and some parts of the [...] configuration manager also make use of it), [...] leaving room [...] beyond the technical side [...] because nothing of the interesting stuff is documented [...]
• Paul, Matthias R. (2002-08-13). "Suche freien Speicherbereich unterhalb von 1 MB, der nicht von OS überschrieben wird" (in German). Newsgroup: de.comp.lang.assembler.x86. Archived from the original on 2017-09-04. Retrieved 2017-09-03. (NB. Also on MS-DOS 7+ HMA usage and \WINDOWS\IOS.LOG.)
• Sweger, Kristofer (2007) [2002-07-15]. "ANSIPLUS and Windows". Archived from the original on 2021-11-28. Retrieved 2021-11-28. […] ANSIPLUS's code cannot be loaded to the HMA under MS-DOS 7 (Windows 9x only) because there apparently is not enough unused HMA memory available. […]
• Paul, Matthias R. (2004-06-17). "Re: Random Lockups with DR-DOS 7.03". [email protected]; FidoNet conference: ALT_DOS. Archived from the original on 2019-04-28. Retrieved 2019-04-28. [...] all MS-DOS versions prior to Windows 95 [...] used a COM style COMMAND.COM file which has a special signature at the start of the file [...] queried by the MS-DOS BIOS before it loads the shell, but not by the DR-DOS BIOS [...] COMMAND.COM would [...] check that it is running on the "correct" DOS version, so if you would load their COMMAND.COM under DR-DOS, you would receive a "Bad version" error message and their COMMAND.COM would exit, so DR-DOS would [...] display an error message "Bad or missing command interpreter" (if DR-DOS was trying to load the SHELL= command processor after having finished CONFIG.SYS processing). In this case, you could enter the path to a valid DR-DOS COMMAND.COM (C:\DRDOS\COMMAND.COM) and everything was fine. Now, things have changed since MS-DOS 7.0 [...] COMMAND.COM has internally become an EXE style file, so there is no magic [...] signature [...] to check [...] thus no way for DR-DOS to rule out an incompatible COMMAND.COM. Further, their COMMAND.COM no longer does any version checks, but [...] does not work under DR-DOS [...] just crashes [...] the PC DOS COMMAND.COM works fine under DR-DOS [...] [3][4]
• King, Adrian (1994). Inside Microsoft Windows 95 (2nd ed.). Redmond, Washington, USA:
  ISBN 978-1-55615-626-7
  .
• Programmer's Guide to Microsoft Windows 95: Key Topics on Programming for Windows from the Microsoft Windows Development Team (1st ed.). Redmond, Washington, USA:
  ISBN 978-1-55615-834-6. Retrieved 2016-05-26. {{cite book}}: |work= ignored (help
  )
• Oney, Walter (1995). Systems Programming for Windows 95 (1st ed.). Redmond, Washington, USA:
  ISBN 978-1-55615-949-7
  .
• ISBN 978-156884-318-6. Retrieved 2016-05-26. {{cite book}}: |work= ignored (help
  )
• Hazzah, Karen (1997). Writing Windows VxDs and Device Drivers - Programming Secrets for Virtual Device Drivers (2nd printing, 2nd ed.). Lawrence, Kansas, USA:
  ISBN 978-0-87930-438-6
  .
• Mitchell, Stan (1997-05-11). Schulman, Andrew (ed.). Inside the Windows 95 File System (1st ed.). Sebastopol, California, USA:
  ISBN 978-1-56592-200-6. Retrieved 2016-05-26. {{cite book}}: |work= ignored (help
  )

External links

• Microsoft. "Windows 95 Architecture Components". Microsoft. Archived from the original on 2014-10-17. Retrieved 2016-05-27.
• Microsoft (2006-11-15). "Description of the Windows 95 Startup Process". 1.1. Microsoft. Q174018. Archived from the original on 2014-02-14. Retrieved 2016-05-27.
• Microsoft (2013-10-26). "Understanding Win16Mutex". 5.0. Microsoft. KB125867. Q125867. Archived from the original on 2014-01-16. Retrieved 2016-05-27.