When you turn on a PC running MS-DOS 6, possibly with the intention of running Windows 3.1, one of the first things you see on the screen is the message "Starting MS-DOS."
If you install Windows 95 (aka "Chicago") on this PC, the message that greets you the next time you turn it on will be "Starting Windows."
This is a dramatic demonstration (well, as dramatic as a PC sign-on message can get) that Microsoft wants you to view Windows, not MS-DOS, as the operating system: You turn on your PC, and it tells you you're starting Windows. All that's missing, it seems, are an icon with a smiling computer and the words, "Welcome to Macintosh"--I mean, "Welcome to Windows."
The overall goal behind Windows 95 is to turn the PC into a machine which no longer makes you wonder why you're not using a Macintosh, especially now that Apple's prices have come down far enough that the Mac competes in the same market as the PC. Microsoft's Brad Silverberg, quoted in an important Fortune article, "What's Driving the New PC Shakeout" (September 19, 1994), sums up the goal: "A PC should be like an appliance. Using one should be as easy as toasting a bagel."
After Windows 95 ships, Bill Gates reportedly said in a leaked memo, "there will be no reason to buy an Apple Macintosh" (Computer Reseller News, March 21, 1994). Many reviewers have been impressed with how close Windows 95 comes to this goal of turning the PC into a high-volume, low-price Windows appliance. For example, here's another use of the Windows-as-toaster metaphor:
Starting a Chicago PC is like turning on a toaster: Just hit the button. Sure, you'll still see BIOS information and other machine-specific hieroglyphics scroll by, but far fewer than under Windows 3.1. And then, instead of pausing at the nasty old C> prompt, your PC will charge directly into Chicago's Desktop. (PC World, August 1994)
Indeed, the ability to boot, seemingly seamlessly, into Windows is impressive. But what does it tell us about the architecture of Windows 95?
The old "Starting MS-DOS" message is produced by a hidden MS-DOS file called IO.SYS. IO.SYS and a second file called MSDOS.SYS form the kernel of the real-mode MS-DOS operating system. With MS-DOS, what Microsoft calls the "startup record" (books on the DOS file and disk system usually it call the "boot record"), occupying the first sector of the DOS bootable disk partition, contains code to load IO.SYS, as seen in the hex dump from the DOS DEBUG utility in Figure 1.
In Windows 95, the "Starting Windows" message is produced by a file called WINBOOT.SYS, which plays the same role in Windows 95 that IO.SYS and MSDOS.SYS did in earlier versions of MS-DOS. As seen in Figure 2, the startup/boot record in Windows 95 looks for WINBOOT.SYS rather than for IO.SYS and MSDOS.SYS. Notice that, not only has WINBOOT.SYS replaced the hidden kernel files IO.SYS and MSDOS.SYS, but what Microsoft calls the "OEM name" in the boot record has changed too, from "MSDOS5.0" to "MSWIN4.0."
Everywhere you look in Windows 95, the name "DOS" has been crossed off and the name "Windows" written in. This has impressed the computer trade press, as seen in its reaction to Beta-1 (May 1994) of Chicago:
Chicago bypasses DOS and runs completely in protected mode, although on startup it can stop briefly in real mode to process the now-optional CONFIG.SYS and AUTO-EXEC.BAT for loading TSRs and old device drivers. (PC/Computing, July 1994)
First of all, there is no DOS hiding under Windows anymore. For the sake of compatibility with legacy applications, Chicago will read and respect CONFIG.SYS and AUTOEXEC.BAT files, but it doesn't require them. (InfoWorld, July 4, 1994)
Whereas previous versions of Windows merely hid real-mode DOS, Windows 95 appears to have abolished it. As the statements above indicate, in Windows 95 you don't need CONFIG.SYS or AUTOEXEC.BAT to run Windows. Windows 95 can automatically load the files necessary to run Windows--not only WIN.COM, but also two DOS device drivers, HIMEM.SYS and IFSHLP.SYS--without any instruction from CONFIG.SYS or AUTOEXEC.BAT.
This is analogous to the introduction in MS-DOS 6.0 of the ability to silently and automatically "preload" DoubleSpace disk compression. All previous disk compression such as Stacker required assistance (sometimes a lot of assistance) from DOS initialization files. Likewise until Windows 95, CONFIG.SYS and AUTOEXEC.BAT were needed to get Windows up and running. And just as DOS 6's undocumented preload interface (over which Microsoft and Stac Electronics got into an interesting court battle; see "Undocumented Corner," DDJ, May 1994) made disk compression transparent, likewise Windows 95's ability to autoload HIMEM.SYS, IFS-HLP.SYS, and WIN.COM makes Windows transparent. You turn on the PC, and it boots into Windows.
If you have Chicago, you can try out its ability to transparently boot Windows, even if you normally use a CONFIG.SYS or AUTOEXEC.BAT file, simply by pressing F5 for a moment when the machine starts. F5 initiates a so-called "fail safe" mode, in which WINBOOT.SYS ignores CONFIG.SYS and AUTOEXEC.BAT, and loads HIMEM.SYS, IFSHLP.SYS and, if needed, SETVER.EXE and EMM386.EXE. WINBOOT.SYS then loads WIN.COM which, in Windows 95 just as in previous versions of Windows, will load the Windows Virtual Machine Manager (VMM) and Virtual Device Driver (VxD) layer, which in turn will load the Windows graphical user interface.
In all the files loaded by WINBOOT.SYS, notice that one well-known file hasn't been mentioned: the DOS command interpreter, COMMAND.COM. Indeed, WINBOOT.SYS only requires COMMAND.COM in order to process AUTOEXEC.BAT, so if you boot Windows 95 without an AUTO-EXEC.BAT, WINBOOT.SYS will directly load Windows--without a copy of the DOS command interpreter sitting under it.
The WINPSP program in my upcoming book, Unauthorized Windows 95 (IDG Programmer Press, 1995) shows this. The PSP (Program Segment Prefix) is a real-mode DOS data structure; every running real-mode DOS program has a PSP, and the real-mode address of a program's PSP acts as its process identifier. WINPSP is a protected-mode Windows program that prints out some information about each PSP, such as its real-mode address and the name of its owner. When Windows 95 has been booted with an AUTOEXEC.BAT file, COMMAND is plainly visible in the WINPSP output: 1293 COMMAND 0140.
But as seen in Figure 3, when there's no AUTOEXEC.BAT--WINPSP shows that COMMAND.COM is gone. The Windows loader, WIN.COM, has replaced the DOS command interpreter, COMMAND.COM: whereas COMMAND was loading at address 1293h, WIN is now loading at the nearly identical address 1292h. This is great!
Windows 95's ability to dispense with COMMAND.COM has been the source of much confusion. For example, one particularly ill-informed writer claimed, before Windows 95 was even in beta (and long before Microsoft decided that it would not give this new version the name "Windows 4.0"), that:
If no real-mode DOS device drivers or TSRs have been loaded in CONFIG.SYS or AUTOEXEC.BAT, Windows 4 should be able to remove itself entirely from real-mode DOS, relying on the VMM/VxD operating system. ("Undocumented Corner," DDJ, February 1994)
Leaving aside the curiously inelegant phrase, "remove itself entirely from," and the way he hedged his bets with that word "should," this writer was obviously deeply confused. COMMAND.COM is not MS-DOS; it is merely the DOS command interpreter. If there's no AUTOEXEC.BAT file, Windows 95 can dispense with COMMAND.COM, but this hardly means that Windows 95 can dispense with DOS.
Even though it is well known that COMMAND.COM and the C:\> prompt are not synonymous with MS-DOS--you can replace them by naming some other program in the CONFIG.SYS SHELL= statement--many people who do know the difference between MS-DOS and COMMAND.COM nonetheless persist in viewing Windows 95's ability to bypass COMMAND.COM as somehow synonymous with bypassing real-mode DOS code. For example, responding to a reader's letter that took exception to his July 1994 assertion that Windows 95 is "a complete operating system in its own right," a writer for Windows Magazine (October 1994) offered the following substantiation for this assertion:
Here's a test anyone with a Chicago beta system can perform: Rename your AUTOEXEC.BAT and CONFIG.SYS to AUTOEXEC.OLD and CONFIG.OLD; then shut down and restart Chicago. It will boot back up--into Windows. You will see no command prompt_. That looks to me like a full-up operating system, not an "environment" that runs on top of such a system.
As we've seen, Windows 95's ability to boot right into Windows is indeed impressive, but because the C:\> prompt is not part of the real-mode DOS kernel, this impressive feat tells us nothing about Windows 95's status as a "full-up operating system." Yet, Windows 95's ability to bypass COMMAND.COM must in part lie behind the widespread notion that, in the absence of any real-mode TSRs or device drivers, Windows 95 can "push" real-mode DOS off the machine. Certainly it's great not having Windows resting on top of COMMAND.COM. And booting Windows right out of WINBOOT.SYS makes a big difference to a user's perception of their PC. But the idea that Windows 95 "pushes the real-mode code aside," "bypasses DOS and runs completely in protected mode," or "should be able to remove itself entirely from real-mode DOS" (what that ugly expression was supposed to mean), simply has no foundation in any version of Chicago that has shipped to date, and is extremely unlikely to have any foundation in the final shipping Windows 95 retail.
COMMAND.COM is not MS-DOS. It is merely the MS-DOS user interface, the provider of the familiar but contemptible C:\> prompt. Windows 95 makes it possible to run Windows without ever seeing a C:\> prompt. Great! But does this mean, as Adrian King puts it in Inside Windows 95 (Microsoft Press, 1994) that in Windows 95 "if you run only Windows applications, you'll never execute any MS-DOS code," and that "Windows 95 finally breaks all ties with the real mode MS-DOS code"? No, it doesn't.
The "if you run only Windows applications, you'll never execute any MS-DOS code" statement is false: In Windows 95, even if you run only Windows applications, and only Win32 applications at that, you'll still execute some important pieces of MS-DOS code. As just one example, the IFSMgr (Installable File System manager) VxD, which is the basis for both 32-bit file access (32BFA) and long filenames, requires a real-mode DOS device-driver "helper," IFSHLP.SYS.
But equally important, the statement appears to assume that, if you do run non-Windows (that is, DOS) applications, it necessarily follows that you'll execute some MS-DOS code. This doesn't follow at all. Support for the DOS INT 21h interface tells you absolutely nothing about whether the real-mode DOS code is present or not.
If you've ever run Windows NT or OS/2, you know that you can have a DOS box and the DOS INT 21h programming interface, without having real-mode DOS. These operating systems emulate DOS; the presence of a DOS box really tells you nothing about the presence or absence of real-mode DOS itself. So there's no particular reason why opening a DOS box would by itself make Windows 95 more dependent on real-mode DOS than if you only ran Windows applications.
In fact, Windows 95 does emulate DOS to a large extent. But this emulation is neither complete nor new. To the large but incomplete extent that Windows 95 emulates (rather than relies upon) the real-mode DOS code, Windows for Workgroups (WfW) 3.11 with 32BFA does as well.
Even more significant than the strong similarities between Windows 95 and WfW 3.11 is the fact that all the technology behind Windows 95's impressive, albeit partial, emulation of DOS goes back to Windows 3.0 Enhanced mode, introduced in 1990 (we might as well call it "Windows 90"). In particular, the seeds for Windows 95 were sown in a well-documented but little-known VMM service named Hook_V86_Int_Chain. Over the past few years, Microsoft has been using Hook_V86_Int_Chain, together with other VMM services such as Begin_Nest_V86_Mode, Exec_Int, Set_PM_Int_Vector, Allocate_V86_Call_Back, Install_V86_Break_Point, and Call_Priority_VM_Event, to turn MS-DOS into a 32-bit, protected-mode operating system. And this has been going on, under our noses, since the debut of Windows 90.
Meanwhile, we still need to see whether or not Windows 95 rests upon real-mode DOS. Let's close the DOS box and return to the WINPSP program shown earlier. This is a Win16 program. If "Windows 95 bypasses DOS" and "there is no DOS hiding under Windows anymore," then this ought to be reflected in WINPSP's output. It's not. I didn't say anything about it at the time, but when we used WINPSP to show that Windows 95 can run without COMMAND.COM, it also happened to show that all Windows programs running under Windows 95 have real-mode DOS PSPs.
It is particularly revealing that both a Win32 program like the Windows 95 Cabinet/Explorer (CAB32), and the Win32 kernel (KERNEL32) should have real-mode DOS PSPs. Microsoft says, "if you run only Windows applications, you'll never execute any MS-DOS code"--well, here we are, running only Windows applications, but what do you think is creating those PSPs? DOS is creating them, and the Win16 KERNEL is asking DOS to create them by calling an undocumented DOS function, INT 21h function 55h (Create PSP).
This finding, though surprising at first, actually follows logically from other well-known aspects of the Windows 95 architecture:
One point does not necessarily follow, however: Making an INT 21h call does not necessarily mean calling the real-mode DOS code. You must get used to the fact that in Windows, an INT 21h call--even one coming from a real-mode DOS program, device driver, or TSR--is not always handled by the real-mode DOS code. There are two reasons why INT 21h ain't necessarily real-mode DOS:
First, Windows runs the real-mode DOS code in Virtual-8086 (V86) mode. This is not a pedantic point. V86 mode is hardly at all like real mode, and more closely resembles a one-megabyte protected mode. The best way to wrap your mind around Windows' relationship to DOS is to keep telling yourself that Windows runs the real-mode DOS code in protected mode.
Second, Windows avoids sending most INT 21h calls down to the real-mode DOS code (which, as just mentioned, Windows is effectively running in protected mode), because these calls--whether coming from a DOS program running in a DOS box, or from some piece of DOS software loaded before Windows, or from a Windows application--are handled by VxDs. As noted earlier, the Hook_V86_Int_Chain service provided by VMM and used by VxDs such as IFSMgr is the basis for 32-bit protected-mode emulation of the DOS interface.
Still, the DOS PSP management services, including functions 50h (Set PSP), 51h and 62h (Get PSP), and 55h (Create PSP), are not among those INT 21h services that the Windows 95 VxDs currently emulate in protected mode. Every time you start up an application in Windows, be it a DOS program, Win16 program, or even the newest Win32 application, Windows will ask DOS to create a PSP.
What we're left with, then, is that Windows 95 can dispense with COMMAND.COM, purveyor of the nasty C:\> prompt. This is terrific. A Windows 95 machine can boot right into Windows without a CONFIG.SYS or AUTOEXEC.BAT. Fantastic! But is this what everyone means when they say that Windows 95 "doesn't require DOS"? It would appear so.
WINBOOT.SYS contains the old real-mode DOS code, and Windows 95 calls down to this code quite frequently (albeit in V86 mode which, you need to keep telling yourself, is really protected mode). Now, the VxD layer in Windows 95 does handle most INT 21h calls entirely in 32-bit protected mode, without calling DOS. This, too, deserves two and possibly even three cheers. But 32BFA in WfW 3.11 did the exact same thing, and met with considerably less fanfare than Windows 95, and in fact the trade press generally complained that WfW 3.11's "bypassing DOS" was some sort of bug that caused all sorts of DOS-compatibility problems.
So what could the "Windows 95-bypasses-DOS" claim possibly mean?
Perhaps it simply refers to the packaging of Windows 95. For example, the Microsoft Windows "Chicago" Reviewer's Guide says "Chicago will be a complete, integrated protect-mode operating system that does not require or use a separate version of MS-DOS." Note Microsoft doesn't say that Windows 95 will not require or use DOS. Microsoft says Windows 95 won't require or use a separate version of MS-DOS. Perhaps Microsoft is simply telling us that all the functionality formerly associated with MS-DOS will now be brought out under the Windows 95 brand name. If everything formerly thought to be part of MS-DOS is by executive fiat now part of Windows, then the "you'll never execute any MS-DOS code" claim makes sense, I suppose.
If I had to explain how Windows 95 relates to DOS in 25 words or less, then, I'd say this: Windows 95 relates to DOS the same way that WfW 3.11 does. Windows 95 provides 32BFA. For nonfile calls, it calls (in V86 mode) the real-mode DOS code in WINBOOT.SYS. Windows 95 is a genuine operating system; so were WfW 3.11, Windows 3.1 Enhanced mode, and Windows 3.0 Enhanced mode. Windows 95 is nothing more, but also nothing less, than Windows 90+5.
Figure 3 Output from WINPSP in a Windows 95 system booted without an AUTOEXEC.BAT file; notice that COMMAND.COM is not present in memory. But also notice that even Win32 tasks such as CAB32 (the Windows 95 shell), KERNEL32 (the Win32 kernel), and WINBEZMT (a multithreaded Bézier demo) have DOS PSPs.
Copyright © 1995, Dr. Dobb's JournalBypassing COMMAND.COM_
But Bypassing DOS Too?
Thus, it makes perfect sense that Windows 95 depends on the DOS INT 21h interface for PSP management if for nothing else, and that this has nothing to do, one way or the other, with whether or not you run any DOS programs.Figure 1: The MS-DOS boot record looks for IO.SYS and MSDOS.SYS.
C:\WINDOWS>debug
-L 100 2 0 1 ;;; load drive C: sector 1 into address 100h
-d 100 300 ;;; now dump out address 100h
7431:0100 EB 3C 90 4D 53 44 4F 53-35 2E 30 00 02 10 01 00 .<.MSDOS5.0.....
7431:02E0 61 64 79 0D 0A 00 49 4F-20 20 20 20 20 20 53 59 ady...IO SY
7431:02F0 53 4D 53 44 4F 53 20 20-20 53 59 53 00 00 55 AA SMSDOS SYS..U.
C:\WINDOWS>dir \*.sys /a:h
IO SYS 40,566 09-30-93 6:20a
MSDOS SYS 38,138 09-30-93 6:20a
Figure 2: The Windows 95 boot record looks for WINBOOT.SYS.
C:\Windows>debug
-l 100 2 0 1
-d 100 300
77AB:0100 EB 3C 90 4D 53 57 49 4E-34 2E 30 00 02 08 01 00 .<.MSWIN4.0.....
77AB:02F0 00 57 49 4E 42 4F 4F 54-20 53 59 53 00 00 55 AA .WINBOOT SYS..U.
C:\Windows>dir \*.sys /a:h
WINBOOT SYS 288,030 06-10-94 4:22a