From: alongton@clark.net (Andy Longton) Newsgroups: comp.os.ms-windows.advocacy,comp.os.os2.advocacy Subject: Re: MS: Revising history again... Followup-To: comp.os.ms-windows.advocacy,comp.os.os2.advocacy Date: 10 Feb 1995 05:12:48 GMT Message-ID: <3heskg$n0s@clarknet.clark.net> References: <3hes5r$k0e@clarknet.clark.net> The following is from an agency hired by Microsoft for Public Relations. It discusses some of the assertions made by Andres Schulman in Undocumented Windows 95. --------------------- Madeline Cox, Waggener Edstrom Much of the industry gossip surrounding Andrew Schulman's "Unauthorized Windows 95" book has been in the form that Windows 95 contains real-mode MS-DOS code, and therefore, is somehow built on top of MS-DOS. Specifically, it is said that Windows 95 is no different than Windows 3.0 with a few added extra virtual device drivers (VxD's). The purpose of this document is to address some of the misconceptions surrounding this issue, and to explain precisely the compatibility reasons of why Microsoft chose to architect Windows 95 in this fashion. If you look at the system services that Windows 95 supplies, you'd find things like: - process and thread memory management - interprocess communications and synchronization - fully preemptive Win32 subsystem - CDROM and hard disk I/O services - network I/O services - printing services - high level graphics operations - window management - etc. In Windows 95, none of these services are provided by any MS-DOS code. In fact, the crux of Andrew Schulman's statements surrounding the MS-DOS code is listed on page 38 of his book. On that page he lists the standard INT 21h functions which are handled by real-mode MS-DOS code in Windows 95. These functions are: - Set/Get Drive (functions 0Eh and 19h) - Get Date/Time (functions 2Ah and 2Ch) - Get DOS Version (function 30h) - Dup File Handle (function 45h) - Exit (function 4Ch) - Set/Get Program Segment Prefix (functions 50h and 51h) - Create Program Segment Prefix (function 55h) - Create Temp File (function 5Ah) - International (function 65h) - Novell NetWare Get Station Num (function DCh) The majority of the remainder of the book discusses how these functions are handled in more depth. While it is true that these functions are handled by MS-DOS code, the code itself is running in Virtual 8086 mode, not real-mode as some people have misunderstood (Schulman points this out on page 43). The reason why Windows 95 implements these functions in this manner is for backwards compatibility with existing real-mode software such as Novell's NetWare Client. All of these functions require the setting or retrieving of some global data structures, and all of these must be propagated down so that these existing real-mode programs or other device drivers continue to work. Since Windows 95 must run all software that runs on Windows 3.x, it is simply not an option to break this class of programs. A large portion of the book is devoted to the discussion of how Windows 95 makes use of the MS-DOS Program Segment Prefix data structure. This structure is used by Windows 95 as a unique identifier for every process that is executing. This PSP structure is conceptually no different than similar structures in other operating systems, such as the PROC structure in Unix. Schulman also points out, on pages 17-18, that Windows NT does not create or use this PSP structure during the execution of it's Win32 applications. Therefore, the argument goes, Windows NT is not using MS-DOS code. This completely ignores the reality that Windows NT does not support real mode device drivers. If you are running a Win32 application under Windows 95 that is making use of a real-mode network client, you would expect that you would be allowed to do file I/O to a network server through this client software. This is exactly what Windows 95 allows: full compatibility with real-mode drivers, even from new Win32 applications which no knowledge of these real-mode devices. In Chapter 2, Schulman questions some of the statements about "pushing the real-mode code aside." On pages 59-60, he discusses how it would be extremely difficult to reclaim memory from real-mode device drivers such as MSCDEX. Since his book was based upon the Beta 1 release of Windows 95, portions of it are out of date. Starting with Beta 2, Windows 95 does indeed reclaim memory from MSCDEX, but not using any of the "difficult" methods discussed in his book. After the setup program completes the installation of Windows 95, and it then boots from the hard disk for the first time, there is special code which is executed to see if the protect mode CDFS drivers have completely taken over the CDROM drive on the machine. If so, this code is then able to backtrack and match up the real- mode MSCDEX driver in memory to the appropriate lines in CONFIG.SYS. Those lines are then commented out. This method is much safer than any discussed in the book, plus it leaves an excellent audit trail in CONFIG.SYS for a knowledgeable user to understand. Similar methods are employed on other device drivers that Windows 95 knows to be completely safe to remove, such as third party real- mode disk cache utilities and redundant protect-mode VxDs. Also in Chapter 2 are discussions about the boot process. On pages 61-62 he questions why WINBOOT.SYS (now named IO.SYS) needs to load WIN.COM, and why it couldn't just load VMM32.VXD directly. Again, he misses the point of backwards compatibility. Windows 95 takes great pains to boot in precisely the same way that Windows 3.1 did by loading the same components in the same order. This is because there are real-mode drivers out there which insert themselves at various places in the Windows 3.1 boot process. If Windows 95 were to bypass the loading of the WIN.COM stub, any driver which expected to insert itself in that location would never be called. Therefore, the end- user's computer would be broken after a Windows 95 upgrade. Microsoft designed Windows 95 in a very deliberate fashion to maintain a high degree of compatibility with the myriad of existing MS-DOS and Windows applications in the marketplace. The specific INT 21h functions implemented in real- mode were not some accidental leftover code. Each one of those low-level functions were needed for compatibility with at least one major real-mode device driver. Over and over again, careful tradeoffs were made to insure that a user who upgrades an existing MS-DOS/Windows 3.1 installation will continue to have full use of their machine without needing new device drivers or applications.