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.
