This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these messages)
|
The Windows 9x series of operating systems refers to a series of Microsoft Windows operating systems produced from 1995 to 2000. They are based on the Windows 95 kernel which is a monolithic kernel. The basic code is similar in function to MS-DOS. They are 16-/32-bit hybrids and require support from MS-DOS to operate.
To start up or boot, Windows 95 and other Windows 9x operating systems require the following set of files: [1]
32-bit shell and command line interpreter:
Windows 95 core:
Registry and other configuration files:
Virtual Machine Manager and configuration manager:
Installable file System Manager:
Device drivers:
The system may also use CONFIG.SYS, which contains settings and commands executed before loading the command interpreter and AUTOEXEC.BAT, which is a batch file automatically executed after loading COMMAND.COM. However, these two files are not critical to the boot process, as IO.SYS contains a default setting for both, in case of absence from the system. In Windows ME, CONFIG.SYS and AUTOEXEC.BAT are not processed and LOGO.SYS may be used as a splash screen.
The Windows 9x startup process consists of 6 phases. The first two of these steps are common to any operating system booting using the traditional combination of BIOS and Master Boot Record.
The ROM BIOS starts the execution at the physical memory address 000FFFF0h. During this phase, BIOS first executes the Power-on self-test, then checks for the existence of a boot disk on drive A. If it is not found in drive A, the ROM BIOS checks for a hard disk. If the computer has a Plug and Play BIOS, in addition, BIOS checks the RAM for I/O port addresses, interrupt lines and DMA channels for Plug and Play devices, disables found devices, creates maps of used and unused resources and re-enables devices.
The Master boot record is loaded at address 7C00h and loads the boot sector of the Windows Disk partition. The boot sector contains the disk boot program and 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.
IO.SYS initialises the minimal File Allocation Table driver and loads MSDOS.SYS into memory. It then displays "Starting Windows" depending on the Boot-Delay line in the MSDOS.SYS file. It then loads the LOGO.SYS file and displays a startup image on the screen. If the DRVSPACE.INI or DBLSPACE.INI 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.
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 IFSHLP.SYS, HIMEM.SYS and SETVER.EXE. Windows reserves all upper memory blocks for Windows 95 operating system use or for expanded memory. Windows 95 and 98 execute COMMAND.COM to process AUTOEXEC.BAT. It loads 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.
IO.SYS now runs WIN.COM. WIN.COM loads the 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.
Once all of the drivers are loaded, the kernel32.dll, krnl386.exe, gdi32.dll, gdi.exe, user32.dll, user.exe, shell32.dll and explorer.exe files are loaded. The next step in the startup process is to load the network environment. The user is prompted to log on to the network that is configured. When a user logs on, their desktop settings are loaded from the registry, or the desktop configuration uses a default desktop. Windows then starts programs defined in the StartUp folder, WIN.INI 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.
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.
VxD is the device driver model used in Microsoft Windows/386 2.x, the 386 enhanced mode of Windows 3.x, Windows 9x, and to some extent also by the Novell DOS 7, OpenDOS 7.01, and DR-DOS 7.02 multitasker (TASKMGR
). VxDs have access to the memory of the kernel and all running processes, as well as raw access to the hardware. Starting with Windows 98, Windows Driver Model was the recommended driver model to write drivers for, with the VxD driver model still being supported for backward compatibility, until Windows Me.
NTLDR is the boot loader for all releases of Windows NT operating system from 1993 with the release of Windows NT 3.1 up until Windows XP and Windows Server 2003. From Windows Vista onwards it was replaced by the BOOTMGR bootloader. NTLDR is typically run from the primary storage device, but it can also run from portable storage devices such as a CD-ROM, USB flash drive, or floppy disk. NTLDR can also load a non NT-based operating system given the appropriate boot sector in a file.
Windows 9x is a generic term referring to a line of discontinued Microsoft Windows operating systems from 1995 to 2000, which were based on the Windows 95 kernel and its underlying foundation of MS-DOS, both of which were updated in subsequent versions. The first version in the 9x series was Windows 95, which was succeeded by Windows 98 and then Windows Me, which was the third and last version of Windows on the 9x line, until the series was superseded by Windows XP.
For Microsoft Windows, OS/2, and DOS, .exe is the filename extension that denotes a file as being executable – a computer program – containing an entry point.
CONFIG.SYS is the primary configuration file for the DOS and OS/2 operating systems. It is a special ASCII text file that contains user-accessible setup or configuration directives evaluated by the operating system's DOS BIOS during boot. CONFIG.SYS was introduced with DOS 2.0.
The Installable File System (IFS) is a filesystem API in MS-DOS/PC DOS 4.x, IBM OS/2 and Microsoft Windows that enables the operating system to recognize and load drivers for file systems.
Quarterdeck Expanded Memory Manager (QEMM) is a memory manager produced by Quarterdeck Office Systems in the late 1980s through the late 1990s. It was the most popular third-party memory manager for the MS-DOS and other DOS operating systems.
AUTOEXEC.BAT
is a system file that was originally on DOS-type operating systems. It is a plain-text batch file in the root directory of the boot device. The name of the file is an abbreviation of "automatic execution", which describes its function in automatically executing commands on system startup; the filename was coined in response to the 8.3 filename limitations of the FAT file system family.
The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager, and user interfaces can all use the registry. The registry also allows access to counters for profiling system performance.
IO.SYS is an essential part of MS-DOS and Windows 9x. It contains the default MS-DOS device drivers and the DOS initialization program.
ntoskrnl.exe, also known as the kernel image, contains the kernel and executive layers of the Microsoft Windows NT kernel, and is responsible for hardware abstraction, process handling, and memory management. In addition to the kernel and executive layers, it contains the cache manager, security reference monitor, memory manager, scheduler (Dispatcher), and blue screen of death.
The Session Manager Subsystem, or smss.exe
, is a component of the Microsoft Windows NT family of operating systems, starting in Windows NT 3.1. It is executed during the startup process of those operating systems.
HIMEM.SYS is a DOS device driver which allows DOS programs to store data in extended memory according to the Extended Memory Specification (XMS). The memory beyond the first 1 MB of address space is required by Windows 9x/Me in order to load; therefore, these versions of Microsoft Windows require HIMEM.SYS
to be loaded to be able to run.
.sys is a filename extension used in MS-DOS applications and Microsoft Windows operating systems. They are system files that contain device drivers or hardware configurations for the system.
SYSTEM.INI
is an initialization used in early versions of Microsoft Windows to load device drivers and the default Windows shell, among other system settings. Many of these settings were honored in Windows 9x, although the INI files had begun to be phased out in favor of the Windows Registry. Windows NT 4.0, 2000, XP and Server 2003 still acknowledge some SYSTEM.INI
entries in order to provide backwards compatibility with older 16-bit applications. Windows Vista and beyond also have SYSTEM.INI
as well. However, when a fresh install of XP/Server 2003 is performed, the SYSTEM.INI
file created contains by default only these lines:
The booting process of Microsoft Windows varies between different releases.
SmartDrive is a disk caching program shipped with MS-DOS versions 4.01 through 6.22 and Windows 3.0 through Windows 3.11. It improves data transfer rates by storing frequently accessed data in random-access memory (RAM).
MSCDEX or Microsoft CD-ROM Extensions is a software program produced by Microsoft and included with MS-DOS 6.x and certain versions of Windows to provide CD-ROM support. Earlier versions of MSCDEX since 1986 were installable add-ons for MS-DOS 3.1 and higher.
DOS is a family of disk-based operating systems for IBM PC compatible computers. The DOS family primarily consists of IBM PC DOS and a rebranded version, Microsoft's MS-DOS, both of which were introduced in 1981. Later compatible systems from other manufacturers include DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1998). MS-DOS dominated the IBM PC compatible market between 1981 and 1995.
MS-DOS 7 is a real mode operating system for IBM PC compatibles. Unlike earlier versions of MS-DOS, it was not released separately by Microsoft, but included in the Windows 9x family of operating systems. Windows 95 RTM reports it as MS-DOS 7.0, and Windows 95 OSR 2.x and Windows 98 report as 7.1. The real-mode MS-DOS 7.x is contained in the IO.SYS file.
[...] 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 [...]
[…] 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. […]
[...] 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 [...]
{{cite book}}
: |work=
ignored (help){{cite book}}
: |work=
ignored (help){{cite book}}
: |work=
ignored (help)