Windows 95 - Architecture

Architecture

Windows 95 was designed to be maximally compatible with existing MS-DOS and 16-bit Windows applications and device drivers, while under this constraint offering a more stable and better performing system. Architecturally, Windows 95 can be considered an evolution of Windows for Workgroups' 386 enhanced mode. The lowest level of the operating system is formed by a large number of virtual device drivers (VxDs) running in 32-bit protected mode and one or more virtual DOS machines running in virtual 8086 mode. The virtual device drivers can be responsible for handling physical devices (such as video and network cards), emulating virtual devices used by the virtual machines, or providing various system services. The three most important virtual device drivers are:

Virtual Machine Manager

The Virtual Machine Manager (VMM32.VXD) can be considered the kernel of Windows 95 and is responsible for tasks such as memory management, event and interrupt handling, loading and initialization of virtual device drivers, the creation of new virtual machines, and scheduling of threads.

Configuration Manager

The Configuration Manager (CONFIGMG) is responsible for implementing Plug and Play functionality. It detects devices in the system using several bus enumerators, monitors the system for changes to the hardware configuration. It is responsible for assigning various resources (I/O ports, IRQs, DMA channels, and memory) to the devices in a conflict free fashion.

Installable File System Manager (Input/Output Subsystem)

The Installable File System Manager coordinates the access to various file systems. Windows 95 ships with support for FAT16, and in later releases FAT32, file systems (VFAT), ISO 9660 (CDFS), and several network redirectors. A dynamically sized disk buffer is provided by VCACHE. In the Block I/O Subsystem, requests are scheduled by the Input/Output Supervisor. Access to the disk is performed by a port driver, or in the case of a SCSI device, by a miniport driver working atop the SCSI layer.

Like Windows for Workgroups running with 32-bit file (based on IFSHLP.SYS) and disk access enabled, I/O operations can be handled entirely in 32-bit protected mode, bypassing MS-DOS and the BIOS, giving a significant performance improvement. In case there is no native Windows driver for a certain storage device, or if a device is forced to run in compatibility mode, the Real Mode Mapper port driver can access it through MS-DOS.

32-bit Windows applications are each assigned their own memory segment, which can be adjusted to any size the user wishes and memory outside the segment cannot be accessed by an application. This eliminated the use of fixed 64k segments, which were a serious handicap in DOS and Windows 3.x and also caused stability issues in the latter because of applications sometimes overwriting others' segments. If a Windows 3.x application crashes, it can knock out surrounding processes, but 32-bit apps will not harm anything else if they crash.

The Win32 API is implemented by three modules, each consisting of a 16-bit and a 32-bit component:

Kernel

Kernel (KRNL386.EXE, KERNEL32.DLL, and VWIN32.VXD) provides high level access to functions such as memory and process management, and access to the file system.

User

User (USER.EXE and USER32.DLL) is responsible for managing and drawing the various user interface components, such as windows, menus, and buttons.

GDI

The Graphics Device Interface (GDI.EXE and GDI32.DLL) is responsible for drawing graphics in a device-independent way.