Editing Windows 95 (section)

==Architecture==
[[File:Microsoft Windows 95 architecture.svg|thumb|upright=1.5|Architectural diagram]]
Windows 95 was designed to be maximally compatible with existing [[MS-DOS]] and 16-bit Windows programs and [[device drivers]] while offering a more stable and better performing system.<ref name="pre-multi">{{cite web|url=http://support.microsoft.com/kb/117567|title=How 16-Bit and 32-Bit Programs Multitask in Windows 95|date=November 15, 2006|website=Microsoft Support|publisher=[[Microsoft]]|archive-url=https://web.archive.org/web/20080117085655/http://support.microsoft.com/kb/117567|archive-date=January 17, 2008|access-date=April 9, 2010}}</ref><ref name="w95-archi">{{cite web|url=https://docs.microsoft.com/en-us/previous-versions//cc751120(v=technet.10)|title=Windows 95 Architecture Components|date=February 20, 2014|work=Microsoft Docs|publisher=Microsoft|access-date=May 9, 2019|archive-date=July 4, 2021|archive-url=https://web.archive.org/web/20210704050156/https://docs.microsoft.com/en-us/previous-versions//cc751120%28v=technet.10%29|url-status=live}}</ref> The development team purchased a copy of every PC software at a local [[Egghead Software]] and tested them on the operating system.<ref name="chen20050824">{{Cite web |last=Chen |first=Raymond |date=2005-08-24 |title=Buying an entire Egghead Software store |url=https://devblogs.microsoft.com/oldnewthing/20050824-11/?p=34463 |access-date=2025-04-27 |website=The Old New Thing |language=en-US}}</ref> The Windows 95 architecture is an evolution of [[Windows for Workgroups]]' 386 enhanced mode.
;Configuration Manager (CONFIGMG):Responsible for implementing [[Legacy Plug and Play|Plug and Play]] functionality; monitoring hardware configuration changes; detecting devices using ''bus enumerators''; and allocating [[I/O port]]s, [[Interrupt request (PC architecture)|IRQs]], [[DMA channel]]s and [[memory-mapped I/O|memory]] in a conflict-free fashion.<ref>{{Cite web|last=aczechowski|title=What is Configuration Manager? - Configuration Manager|url=https://docs.microsoft.com/en-us/mem/configmgr/core/understand/introduction|access-date=August 25, 2020|website=docs.microsoft.com|language=en-us|archive-date=September 4, 2020|archive-url=https://web.archive.org/web/20200904125405/https://docs.microsoft.com/en-us/mem/configmgr/core/understand/introduction|url-status=live}}</ref>
;Installable File System Manager (Input/Output Subsystem):Coordinates access to supported file systems. Windows 95 initially shipped with support for [[FAT12]], [[FAT16]], the [[VFAT]] extension, [[ISO 9660]] (CDFS), [[Joliet (file system)|Joliet]] and [[network redirector]]s, with later releases supporting [[FAT32]].<ref>{{Cite web|last=lorihollasch|title=Filter Manager Concepts - Windows drivers|url=https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/filter-manager-concepts|access-date=August 25, 2020|website=docs.microsoft.com|language=en-us|archive-date=July 4, 2021|archive-url=https://web.archive.org/web/20210704050049/https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/filter-manager-concepts|url-status=live}}</ref>

Access requests to physical media are sent to ''Input/Output Supervisor'', a component responsible for scheduling the requests. Each physical media has its device driver: access to the disk is performed by a ''port driver'', while access to a [[SCSI]] device is handled by a ''[[miniport]]'' driver working atop the SCSI layer. Port and Miniport drivers perform I/O operations in 32-bit protected mode, bypassing MS-DOS and [[BIOS]], significantly improving performance. 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'' can access it through MS-DOS.<ref name="oldnewthing2007">{{Cite web|date=December 24, 2007|title=What was the role of MS-DOS in Windows 95?|url=https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063|website=The Old New Thing|archive-url=https://web.archive.org/web/20110128011858/http://blogs.msdn.com/b/oldnewthing/archive/2007/12/24/6849530.aspx|archive-date=January 28, 2011|author-first=Raymond|author-last=Chen}}</ref>

32-bit Windows programs are assigned protected memory segments, which can be adjusted to any desired size, and memory areas outside the segment cannot be accessed by a program, that limited harm to other programs and the system when a program crashed. Before this, programs used fixed non-exclusive 64 KB segments. While the 64 KB size was a serious handicap in DOS and Windows 3.x, lack of guarantee of exclusiveness was the cause of stability issues because programs sometimes overwrote each other's segments, a crashing Windows 3.x program could knock out surrounding processes.{{Citation needed|date=October 2021}} Unfortunately for compatibility reasons some parts of the 32-bit Windows program memory was non-exclusive and shared among the whole system (most famously the first 1MiB of the address space),<ref name="oldnewthing2014">{{Cite web|date=October 3, 2014|title=Why is 0x00400000 the default base address for an executable?|url=https://blogs.msdn.microsoft.com/oldnewthing/20141003-00/?p=43923|website=The Old New Thing|archive-url=https://web.archive.org/web/20180107111456/https://blogs.msdn.microsoft.com/oldnewthing/20141003-00/?p=43923|archive-date=January 7, 2018 }}</ref> this meant that in Windows 95 a crash which incorrectly modified this shared memory could still cause harm to other programs or the system (full memory protection only came to consumer Windows systems with the launch of Windows XP).

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

;Kernel:Provides high-level access to [[memory management|memory]] and [[process management (computing)|process management]], and access to the file system. Consists of KRNL386.EXE, [[KERNEL32.DLL]], and VWIN32.VXD.
;User:Responsible for managing and drawing the various [[user interface]] components, such as [[window (computing)|windows]], [[menu (computing)|menus]] and [[button (computing)|buttons]]. Consists of USER.EXE and [[USER32.DLL]].
;[[Graphics Device Interface]] (GDI): Responsible for drawing graphics in a device-independent way. Consists of GDI.EXE and GDI32.DLL.

===Dependence on MS-DOS===
{{Main|MS-DOS 7}}
[[File:Microsoft Windows 95 Version 4.00.1111 command.com MS-DOS Prompt 492x259.png|thumb|250px|[[command.com]] running in a [[Windows console]] on Windows 95 (MS-DOS Prompt)]]
To end-users, MS-DOS appears as an underlying component of Windows 95. For example, it is possible to prevent the loading of the graphical user interface and boot the system into a real-mode MS-DOS environment. This was done by inserting [[command.com]] into the autoexec.bat file or changing the BootGUI variable in the MSDOS.SYS file to 0. This sparked debate amongst users and professionals regarding the extent to which Windows 95 is an operating system or merely a graphical shell running on top of MS-DOS.<ref name="oldnewthing2007" /><ref name="Schulman_1994_UnauthorizedWin95">{{cite book
 |title=Unauthorized Windows 95 - Developer's Resource Kit
 |last=Schulman
 |first=Andrew
 |date=October 1994
 |publisher=[[International Data Group|International Data Group Company]]
 |location=[[Foster City, California]]
 |isbn=1-56884-305-4<!-- 9781568841694 -->
 |oclc=300092018
}}</ref><ref name="Lea_1998_Cebit">{{cite web
 |title=Caldera shows Windows on DR-DOS, denying Microsoft claims
 |author-last=Lea
 |author-first=Graham
 |author-link=Graham Lea (journalist)
 |date=March 23, 1998
 |series=[[CeBIT]] news
 |location=Hanover, Germany
 |url=http://www.v3.co.uk/v3-uk/news/1996865/cebit-caldera-windows-dr-dos-denying-ms-claims
 |access-date=March 15, 2012
 |url-status=dead
 |archive-url=https://web.archive.org/web/20120315080721/http://www.v3.co.uk/v3-uk/news/1996865/cebit-caldera-windows-dr-dos-denying-ms-claims
 |archive-date=March 15, 2012
}}</ref>

When the graphical user interface is started, the virtual machine manager takes over the filesystem-related and disk-related functionality. MS-DOS itself is demoted to a compatibility layer for 16-bit device drivers.<ref name="oldnewthing2007"/> This contrasts with earlier versions of Windows which rely on MS-DOS to perform file and disk access (Windows for Workgroups 3.11 could also largely bypass MS-DOS when [[32-bit file access]] and [[32-bit disk access]] were enabled). Keeping MS-DOS in memory allows Windows 95 to use DOS device drivers when suitable Windows drivers are unavailable. Windows 95 is capable of using all 16-bit Windows 3.x drivers.

Unlike Windows 3.x, DOS programs running in Windows 95 do not need DOS drivers for the mouse, CD-ROM and sound card; Windows drivers are used instead. [[HIMEM.SYS]] is still required to boot Windows 95. [[EMM386]] and other memory managers, however, are only used by DOS programs. In addition, [[CONFIG.SYS]] and [[AUTOEXEC.BAT]] settings (aside from HIMEM.SYS) do not affect Windows programs. DOS games, which could not be executed on Windows 3.x, can run inside Windows 95 (games tended to lock up Windows 3.x or cause other problems). As with Windows 3.x, DOS programs that use [[Enhanced Graphics Adapter|EGA]] or [[Video Graphics Array|VGA]] graphics modes run in windowed mode ([[Color Graphics Adapter|CGA]] and [[text mode]] programs can continue to run).<ref name="oldnewthing2007" />

On startup, the MS-DOS component in Windows 95 responds to a pressed {{key press|F8}} key by temporarily pausing the default boot process and presenting the DOS boot options menu, allowing the user to continue starting Windows normally, start Windows in [[safe mode]] or exit to the DOS prompt.<ref name=" Schulman_1994_UnauthorizedWin95"/><!-- NB. The book discusses this for a beta version of Windows 95 with minor (non-significant) differences to how it works in the released versions. --> As in previous versions of [[MS-DOS]], there is no 32-bit support and DOS drivers must be loaded for mice and other hardware.

As a consequence of DOS compatibility, Windows 95 has to keep internal DOS data structures synchronized with those of Windows 95. When starting a program, even a native 32-bit Windows program, MS-DOS momentarily executes to create a data structure known as the [[Program Segment Prefix]]. It is even possible for MS-DOS to run out of [[conventional memory]] while doing so, preventing the program from launching.<ref name="Schulman_1994_UnauthorizedWin95"/> Windows 3.x allocated ''fixed'' segments in conventional memory first. Since the segments were allocated as fixed, Windows could not move them, which would prevent any more programs from launching.

Microsoft partially removed support for [[File Control Block]]s (an API hold-over of DOS 1.x and [[CP/M]]) in Windows 95 OSR2 ([[OEM]] Service Release 2). FCB functions can read [[FAT32]] volumes, but not write to them.

With merging Windows together with MS-DOS, Microsoft had effectively [[Vendor lock-in|locked-in]] users who may have been using a different non-Microsoft DOS, like [[PC DOS]] and [[DR DOS]], who could previously make use of Windows 3.x without requiring Microsoft's MS-DOS. [[Caldera (company)|Caldera]] demostrated that Windows 95 could in fact run on top of its DR DOS operating system, and argued that Microsoft was being anti-competitive, which would prove useful in a later [[Caldera v. Microsoft|court case]] between Caldera and Microsoft.<ref name="Romano_1998_Winbolt">{{cite journal |author-first=Mike |author-last=Romano |title=The mouse that roared. Forget the feds. It's up to an obscure Utah company to prove what we already know: that Microsoft is a monopoly. |journal=[[Seattle Weekly]] |date=1998-09-17 |orig-date=1998-09-16 |url=http://www.seattleweekly.com/1998-09-16/news/the-mouse-that-roared/ |access-date=2017-06-24 |url-status=dead |archive-url=https://web.archive.org/web/20170624231746/http://archive.seattleweekly.com/1998-09-16/news/the-mouse-that-roared/ |archive-date=2017-06-24 |quote=Furthermore, Caldera claims that Microsoft's flagship product, Windows 95, is nothing more than an "[[artificial tie]]" between its MS-DOS operating system and [[Microsoft Windows|Windows]] graphic interface with no business justification other than to keep competing underlying operating systems—like Caldera's DR-DOS—off the market. To prove its point, Caldera will soon release a piece of demonstration software called "[[WinBolt]]," which, it says, will allow users to install the Windows 95 interface atop DR-DOS. The demo will show, Caldera says, that there is no significant technological advancement, or justified business efficiency, to the combination of MS-DOS with Windows in Windows 95.}} [https://web.archive.org/web/20010211085804/http://www.seattleweekly.com/features/9837/features-romano.shtml]</ref><ref name="Schulman_2000_Dossier">{{cite web |title=The Caldera v. Microsoft Dossier |author-first=Andrew |author-last=Schulman |date=2000-02-07 |work=[[O'Reilly Network]] |publisher=[[O'Reilly and Associates, Inc.]] |url=http://www.oreillynet.com/pub/a/network/2000/02/07/schulman.html |url-status=dead |archive-url=https://web.archive.org/web/20000819023434/http://www.oreillynet.com/pub/a/network/2000/02/07/schulman.html |archive-date=2000-08-19}}</ref>