Purpose of MS-DOS in Windows 95...

[WinPC]

I'm going to start a discussion here, so that we can properly determine the purpose of the inclusion of MS-DOS in Windows 95. Since we are an OS history site, this topic would be quite useful here, especially when several people have expressed interest in this subject.

And please, no junk posts, one-line "opinions", etc... this topic is intended for serious research and discussion among true collectors.

Anyway, I have noticed that there is a great deal of debate on the purpose of MS-DOS in Windows 95, especially about its role, but even about its inclusion. Some people claim that it was intended to supersede the original MS-DOS product, while others claim that it was simply an elaborate cover-up for removing competing operating systems from the market.

Of course, I have opened this discussion for the sole purpose of proper research here. I will also see to it that we can gain enough information from the antitrust documents and other sources, with enough information from both sides of the debate.

I understand that some of you may conclude either side with facts such as the "WinBolt" program for running Windows 95 and Windows 98 on unsupported DOS operating systems. However, while I agree that those findings are obviously quite significant, you have to remember that there may be much more to it than just that, and the issue is often much more complicated.

--------------------------------
Personally, my own opinion is that there were clearly advantages and disadvantages to the marketing of MS-DOS as a separate product as well as the inclusion of MS-DOS in Windows 95. For one, Windows 3.1, Windows for Workgroups 3.1, and Windows for Workgroups 3.11 could be used on different versions of MS-DOS as well as different DOS operating systems (in this case, DR-DOS). However, this created a great deal of confusion, since it led people to believe that Windows was nothing more than a simple DOS program. Also, users were required to obtain separate copies of MS-DOS and Windows, and even to install each one separately, which was undoubtedly found to be rather inconvenient for many users.

On the other hand, Windows 95 included MS-DOS 7.0 within the same product, and while Windows 95 was not permitted to run on other versions of MS-DOS or other DOS operating systems, it still had the advantage of being able to install MS-DOS and Windows automatically, and also removed the requirement of manually placing "WIN" at the end of AUTOEXEC.BAT, both of which made it more convenient for most users. It also helped remove the idea that Windows was nothing more than a "DOS program".

[The Distractor]

I believe there was a (unreleased) version of DR-DOS that could be used with Windows 9x. I'd have to google it.

[JustZisGuy]

Anyone that was there in the day would tell you that Microsoft was looking kind of foolish requiring two different packages for DOS and Windows 3.x in order to create a "usable" system. With Apple Macintosh, and OS/2, you got everything you needed in one single package.

By the time of Windows 3.11 for Workgroups, they were providing 386 protected mode drivers for almost everything except CD-ROMs. Application programs increasingly required Windows 3.x instead of just DOS, and users (especially coming from Macs) increasingly expected a nice GUI.

So from a business perspective, it made sense to bundle the two in the next version of Windows (Chicago/Win95).

From a functional point of view, they were stuck with the DOS/Windows architecture for a while. Despite some of misinformed discussions I have seen here, DOS does *NOT* act like just a boot loader under Windows 9x. The Windows portion still runs on top of DOS the same as Windows 2/386 or Windows 3.x Enhanced mode.

It is possible to launch Linux, via Loadlin from DOS, and probably similar utilities exist to launch NT or other OSes from DOS, but in these cases the entire DOS environment is "jettisoned" and replaced by the other OS. In contrast, Windows 9x not only preserves the environment, but uses it to provide base functionality.

If you don't believe me, try loading some TSR in the Windows 9x autoexec.bat, or load a DOS networking stack, or a DOS CD-ROM driver for an otherwise unsupported CD drive. That will all work inside Windows 9x, just as it would previously in 3.x or earlier. - such functionality is impossible from a mere "boot loader".

It is pretty well documented that the Windows 3.x/9x series was intended to be a holdover until Microsoft could get people to switch to NT (or originally OS/2). But due to compatiblity and performance, that goal stretched out longer than they wanted. They did not reach that goal until Windows XP (NT 5.1).

From a competition standpoint, this caused problems for DR-DOS users, or users that wanted to stick to PC-DOS or MS-DOS 6.22. It was arguably "impractical" for Microsoft to support running Windows 95 on other DOS versions, although not technically impossible. In the end, Microsoft simply did not support other versions of DOS, permitting Windows 95, Windows 98, or Windows ME to fully represent a complete OS baseline.

[RentedMule]

Windows 95 not only required DOS to operate (there were still multitudes of DOS interrupts used in the system), but it was also a backward compatibility thing, something MS had a hard on for. If you remember using Windows 3 in its day, half of the applications/games were still DOS. They wouldn't want to flat out cut off that compatibility for the people moving/upgrading to Windows 95. Even hardware drivers ran from DOS mode (looking at you Sound Blaster Live SB16 compatibility driver and MPEG hardware decoder cards)

[WinPC]

Anyone that was there in the day would tell you that Microsoft was looking kind of foolish requiring two different packages for DOS and Windows 3.x in order to create a "usable" system. With Apple Macintosh, and OS/2, you got everything you needed in one single package.

Well that was certainly another argument for merging MS-DOS and Windows together, since it also helped it to compete with other GUI-based operating systems (including OS/2 and even Windows NT).

By the time of Windows 3.11 for Workgroups, they were providing 386 protected mode drivers for almost everything except CD-ROMs. Application programs increasingly required Windows 3.x instead of just DOS, and users (especially coming from Macs) increasingly expected a nice GUI.

So from a business perspective, it made sense to bundle the two in the next version of Windows (Chicago/Win95).

From what I can see, most people used Windows 3.1, Windows for Workgroups 3.1, and Windows for Workgroups 3.11 while at the same time running almost all of their MS-DOS programs within Windows itself, and even many system manufacturers configured systems to load Windows automatically. And even for systems that were not configured in this way, I remember that most people just typed "WIN" at the command prompt anyway.

From a functional point of view, they were stuck with the DOS/Windows architecture for a while. Despite some of misinformed discussions I have seen here, DOS does *NOT* act like just a boot loader under Windows 9x. The Windows portion still runs on top of DOS the same as Windows 2/386 or Windows 3.x Enhanced mode.

There is quite a lot of discussion about this in Andrew Schulman's book, Unauthorized Windows 95 (which is about the relationship of MS-DOS and Windows in Windows 3.1, Windows for Workgroups 3.11, and Windows 95). Andrew Schulman himself disagreed with Microsoft on several issues also, so it isn't like he was being biased towards Microsoft either.

It is possible to launch Linux, via Loadlin from DOS, and probably similar utilities exist to launch NT or other OSes from DOS, but in these cases the entire DOS environment is "jettisoned" and replaced by the other OS. In contrast, Windows 9x not only preserves the environment, but uses it to provide base functionality.

If you don't believe me, try loading some TSR in the Windows 9x autoexec.bat, or load a DOS networking stack, or a DOS CD-ROM driver for an otherwise unsupported CD drive. That will all work inside Windows 9x, just as it would previously in 3.x or earlier. - such functionality is impossible from a mere "boot loader".

Windows 95 not only required DOS to operate (there were still multitudes of DOS interrupts used in the system), but it was also a backward compatibility thing, something MS had a hard on for. If you remember using Windows 3 in its day, half of the applications/games were still DOS. They wouldn't want to flat out cut off that compatibility for the people moving/upgrading to Windows 95. Even hardware drivers ran from DOS mode (looking at you Sound Blaster Live SB16 compatibility driver and MPEG hardware decoder cards)

From what I read of the above-mentioned book, MS-DOS essentially acts as a device driver to Windows; basically providing certain levels of functionality (such as setting "Program Segment Prefixes" for each running task) while Windows takes over the rest, not to mention also providing virtualization of "virtual DOS machines", similar to Desqview/X which was based on the Desqview/386 kernel.

Also, while this topic is mainly a historical debate as to whether MS-DOS and Windows 95 should have been merged or instead shipped separately, at the same time, it is quite important to know that either way, Windows 95 provided a great deal of backward compatibility with existing MS-DOS applications, something which its counterparts Windows NT 3.51 and Windows NT 4.0 had trouble with, and as also explained in the old, Windows 9x thread, it also helped to fix the operating system in the event of a problem (again, something that was also a major problem in Windows NT Workstation).

It is pretty well documented that the Windows 3.x/9x series was intended to be a holdover until Microsoft could get people to switch to NT (or originally OS/2). But due to compatiblity and performance, that goal stretched out longer than they wanted. They did not reach that goal until Windows XP (NT 5.1).

Well, already, Microsoft was implementing a significant level of cross-platform compatibility between the two different Windows operating systems, starting with Win32s which brought the Win32 API to Windows 3.1, Windows for Workgroups 3.1, and Windows for Workgroups 3.11 and continuing even further with Windows 95, Windows 98, and Windows Me (and also Windows NT 4.0 and Windows 2000 for the NT line).[/quote]

From a competition standpoint, this caused problems for DR-DOS users, or users that wanted to stick to PC-DOS or MS-DOS 6.22. It was arguably "impractical" for Microsoft to support running Windows 95 on other DOS versions, although not technically impossible. In the end, Microsoft simply did not support other versions of DOS, permitting Windows 95, Windows 98, or Windows ME to fully represent a complete OS baseline.

Theoretically, Microsoft could have shipped Windows 95 with MS-DOS, while at the same time providing the ability to install another version of MS-DOS or even to install a similar operating system from another company such as DR-DOS/Novell DOS 7.

Apparently, according to Andrew Schulman (Unauthorized Windows 95), MS-DOS 7.0 was optimized for Plug and Play support with the CONFIGMG function, though MS-DOS 7.0 could have been shipped as a separate product also. It would also be important to see how well Plug and Play support works in Windows 95, Windows 98, and Windows Me when using the WinBolt program to run it on an unsupported version of DOS.

[Battler]

Well, that Microsoft was trying to drive competition out of the DOS market is already evident from the AARD trickery used in Windows 3.1 Beta's against Digital Research and their DR-DOS. That did affect DR-DOS sales, and DR-DOS pretty much went down in the years following that. That left only Microsoft and IBM on the DOS market. Now, in order to drive IBM out of the DOS market, AARD trickery was useless (PC DOS was, as far as AARD is concerned, byte to byte identical to MS-DOS), so Microsoft took a step further and bundled DOS and Windows together.
The integration actually started with MS-DOS 5.00 which provided special API calls for Windows to report to DOS whether it's running or not, then MS-DOS 6.x added Windows versions of some of its applications, and there was the Jastro project which was to have a Setup that could install DOS and Windows at the same time. Jastro was then used for Chicago too, until by mid-1993, Microsoft had decided to switch to a new Setup program, written from scratch. According to the files in 58s, the transition happened in July 1993, so 58s in August 1993 was one of the earliest Builds to use new Setup (which explains why it's so incomplete).
Now of course, there was the convenience reason, too. After all, with the two operating systems bundled into one, Microsoft could then claim that "DOS is no longer there" even though it's false. Also, let's remember that Windows 9x was there only as a transitional OS on the way from DOS+Windows 3.x to a planned consumer edition of Windows NT (the original plan was that Cairo would succeed both DOS+Windows 3.x and Windows NT 3.x but then they instead create Windows 95).
So in the end, the consumers benefited (only one product to install, and no longer two), and Microsoft benefited as well (no more competition on the DOS market). The only ones that did not benefit from the bundling were the competitors on the DOS market (DR/Novell, IBM, etc.), but they would not have benefited if the Cairo project had gone into fruition, either.

[WinPC]

Well, that Microsoft was trying to drive competition out of the DOS market is already evident from the AARD trickery used in Windows 3.1 Beta's against Digital Research and their DR-DOS. That did affect DR-DOS sales, and DR-DOS pretty much went down in the years following that. That left only Microsoft and IBM on the DOS market. Now, in order to drive IBM out of the DOS market, AARD trickery was useless (PC DOS was, as far as AARD is concerned, byte to byte identical to MS-DOS), so Microsoft took a step further and bundled DOS and Windows together.

The problem that I see is that just because Microsoft may have originally planned it as a competition move doesn't necessarily mean that they had the same motives behind the final shipping product.

You see, it may seem simple to us if we saw an original draft of something that was written in 1993, one that may appear to make the motives and intentions quite clear. However, that doesn't mean that the motives and intentions were the same in 1995 or even 1994, since as release plans change, the targeted markets can also change.

I'm already quite certain which documents you are referring to, and I can certainly understand why you thought that about MS-DOS's inclusion in Windows Chicago (later Windows 95). However, you also have to remember that at that time, Microsoft was still officially marketing MS-DOS and Windows under two separate brand names.

The problem is that we are dealing with pre-release software, and while it could certainly have originally been intended to discourage use of DR-DOS, that alone could also have changed just as easily. Therefore, there is nothing that says that Microsoft couldn't have turned around and simply used the existing Windows 95 inclusion of MS-DOS to instead help move people to Windows 95 itself and to Win32 since all future versions of MS-DOS would be shipped with Windows 95 anyway.

Also, I don't actually remember seeing anything about Microsoft regarding PC-DOS as being a "separate" operating system (let alone discouraging use with Windows); only DR-DOS (later Novell DOS 7). Would it be possible for you to post any sources here, if you have any?

The integration actually started with MS-DOS 5.00 which provided special API calls for Windows to report to DOS whether it's running or not, then MS-DOS 6.x added Windows versions of some of its applications, and there was the Jastro project which was to have a Setup that could install DOS and Windows at the same time. Jastro was then used for Chicago too, until by mid-1993, Microsoft had decided to switch to a new Setup program, written from scratch. According to the files in 58s, the transition happened in July 1993, so 58s in August 1993 was one of the earliest Builds to use new Setup (which explains why it's so incomplete).

From reading Andrew Schulman's book, Unauthorized Windows 95, one of the reasons why this system was put in place was to allow MS-DOS to load and unload VXDs (virtual device drivers) that may be required by Windows (with WINA20.386 being cited as an example).

Now of course, there was the convenience reason, too. After all, with the two operating systems bundled into one, Microsoft could then claim that "DOS is no longer there" even though it's false. Also, let's remember that Windows 9x was there only as a transitional OS on the way from DOS+Windows 3.x to a planned consumer edition of Windows NT (the original plan was that Cairo would succeed both DOS+Windows 3.x and Windows NT 3.x but then they instead create Windows 95).
So in the end, the consumers benefited (only one product to install, and no longer two), and Microsoft benefited as well (no more competition on the DOS market). The only ones that did not benefit from the bundling were the competitors on the DOS market (DR/Novell, IBM, etc.), but they would not have benefited if the Cairo project had gone into fruition, either.

From what I have read over the past many years, a lot of this was also to do with the fact that Microsoft obviously wanted to move people up to the Windows platform, especially to Win32. This would certainly help them a great deal, since users of MS-DOS were now required to also purchase Windows when upgrading to the newest version of MS-DOS available.

[skywalker06]

What do you guy's think of this topic about the relationship between 95 and dos
http://oreilly.com/centers/windows/brochure/isnot.html

[os2fan2]

It is useful to position Win95 in the marketplace.

The IBM-Microsoft agreement fully lapsed in 1993.12.31, which meant that IBM and Microsoft were largely free to go their ways with their DOS and Windows stuff. IBM had been free to market their DOS on the upgrade market at this stage, DOS 5.00.02 was the first, but 5.02, 6.10 and 6.30 were fairly successful. 7.00 had hit the market. OS/2 for Windows was doing a pretty good job at running Windows for DOS, so there was not dual royalties coming in for Win-OS2 and Windows. But in essence, IBM and DR-DOS were begining to take share from MSFT.

In order to kill the DOS upgrade market, it is necessary to demonstrate that the new windows is not a DOS application, but runs on its own bootsector, dos emulation, etc. Of course, it also needs to be compatible with the bulk of the DOS/Windows stuff out there. So, they built a DOS that allowed you to keep a 'real' dos (ie one bought in a box with DOS on the label), as well as have their 'dos emulation', (ie the MS-DOS 7 with the funny boot block).

Let's be blunt about this. Win95 is MS-DOS 7.0 + Windows 3.95 + Win32s, with enough comingling of code that you can't plug in DR-DOS 7.0 or PC-DOS 7.0, but not enough to prevent MS-DOS 7.0 running as a fully fledged OS on its own. Because it uses a different boot-sector to DOS, and is presented as a different OS, the WINBOOT.SYS proggie had to have the smarts to swap the boot to a pre-existing IBMBIO / IBMDOS or IO / MSDOS. They found out there were bugs in some apps that expected to see IBMBIO or IO in memory, and an IBMDOS/MSDOS > 1K. So they had to fiddle that too.

The version numbers are there to tell programs they're running in DOS 7 and Windows 3.95, and you can't use your DOS 6 or Windows 3.11 to upgrade me. Likewise, i'm not taking your Mouse 8.2 driver off you, but vers 9,0 is ok. The himem.sys happily reports as 3.95 or 3.99 under ME, but the himem services inside Windows is at 2.77.

MS-DOS 7.0 will run a version of Windows 3.11 in 'separate application mode'. This is where you boot out of windows, and start in 'native dos'. This is the main reason, for proggies like mscdex.exe (which have no use in Windows).

As with Windows 3.11, the pre-loaded DOS is actually run as a VxD, the DOS window you see actually comes from a program called 'WINOLDAP.MOD' or 'WINOA386.MOD'. This passes calls down to Windows, which *might* pass them onto DOS. On the other hand, DOS in Win311 or Win9x, sees plenty of calls that start life in Windows, eg clock.exe.

That is, as Schuhmann notes in 'undocumented DOS', Win95 to all purposes and intent, is Windows 4.0 and DOS 7,0, with enough comingling of code to prevent DR-DOS from running. (eg, DR-DOS might not load LFN once windows is loaded).

The DOS emulation is not the same as in say, OS/2 or WinNT (which both use DOS 5)

In WinNT, DOS is a hacked former vm-application (like virtual pc), but the hardware calls (disk, screen, console), are now handled in the OS, rather than in a virtual system. IO.SYS and MSDOS.SYS are hacked to NTIO.SYS and NTDOS.SYS. There is a command.com, but this is not really loaded. Edlin.com, kbd16.com, and a number of other files are straight out of MS-DOS 5.0, and most of the stuff from MS-DOS 5 will run without mods in WinNT. NTDOS runs in a cmd.exe session, and command.com, if loaded, just passes calls down to the win32 command processor.

If you replace the Windows command processor with 4NT, and then load the NT command.com, it will pass all options supplied with internal commands that command.com knows of. So you can use extended 4nt switches for commands in command.com, but not extended commands. That is, 'cd /d ...' works, but 'cdd ...' does not.

In OS/2, DOSKRNL is ibmbio.com and ibmdos.com, in a single binary, which flicks calls out to the underlying OS. Likewise, there is krnlos2.exe for Windows, which does the same thing. Because the console api is not emulated in OS/2, you can run real games like civ1 in an OS/2 window. Because also, OS/2 DOS and OS2 sessions are separate, you don't here OS/2 folk calling the command prompt a 'dos window'. You have a 'dos window' for DOS apps, and an 'os2 window' for OS/2 apps.

OS/2's command.com is a fully blown command.com. You can patch it to disable the version check (vers 14:2D = 20.45), and run it directly under Windows NT. Here is a sample.

Code: Select all

E:\CDROM\COMMAND>dir /w

The volume label in drive E is DOS        .
The Volume Serial Number is 8B63:C8E8.
Directory of E:\CDROM\COMMAND

[.]             [..]            CMDP500.COM     CMDP501.COM     CMDP502.COM
CMDP545.COM     CMDP600.COM     CMDP610.COM     CMDP630.COM     CMDP632.COM
CMDP700.COM     CMDP701.COM     CMDP710.COM     CMDP401.COM     CMDM410.COM
CMDM401.COM     CMDM500.COM     CMDM501.COM     CMDM631.COM     CMDM805.COM
CMDM714.COM     CMDM713.COM     CMDM712.COM     CMDM701.COM     CMDM607.COM
CMDM600.COM     CMDM620.COM     CMDM621.COM     CMDM622.COM     CMDM717.COM
CMDM807.COM     CMDM550.COM     CMD.TXT
      33 file(s)    1833548 bytes used
                  299368448 bytes free

E:\CDROM\COMMAND>ver

The Operating System/2 Version is 4.50

E:\CDROM\COMMAND>