From: alongton@clark.net (Andy Longton)
Newsgroups: comp.os.ms-windows.advocacy,comp.os.os2.advocacy
Subject: Re: MS: Revising history again...
Date: 10 Feb 1995 05:23:30 GMT
Message-ID: <3het8i$n0s@clarknet.clark.net>
References: <3hes5r$k0e@clarknet.clark.net> <3heskg$n0s@clarknet.clark.net>


The following are comments from Andrew Schulman, discussing the doccument 
from Microsoft found in the previous message.


------------------


>>> 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.

They seem in this first part of the document not to be
saying, "This is where Andrew's book is wrong," but rather,
"Hey, industry gossips, you didn't understand Andrew's
book."  Interesting.

>>> 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.

I'm sure this wasn't conscious, but note that "in this
fashion" refers to "it is said that Windows 95 is no
different": in other words, Microsoft is saying, "Yes, this
is what Win95 is, but here are the good reasons we did it
that way." Well, heck, in my book I constantly point out
they had good reasons.

>>> 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....
    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).

Again, notice that this part of the MS statement is just
pointing the reader to specific parts in my book.  Hey, this
is great!

"While it is true that these functions are handled by MS-DOS
code": interesting how they just slip in this fairly major
confession.  It's a 180 degree about-face from what they've
been saying up to now. Microsoft has suddenly and quietly
changed the party line.  It's now, "Oh yeah, Win95 does call
down to DOS, but it's okay."  Not at all what they were
telling journalists (and not at all what the journalists
were in turn telling their readers) up to now.

>>> 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.

Well, I don't think this is quite true.  The distinction
between what Win95 (like Workgroups 3.11) passes down to DOS
and what it doesn't pass down to DOS is a bit simpler: file
I/O calls don't get passed down, non-file calls do.

Given that a host of DOS programs are "broken" by not seeing
file I/O calls (this includes some of Microsoft's own sample
apps, like the COUNTDOS example I give on p. 137 of the
book), and given that Microsoft was apparently willing to
break such apps in order to provide 32-bit file access (see
"Global and Local INT 21h Hookers" on pp. 242-244 of my
book), then compatibility isn't a very good explanation for
why the non-file calls are passed down to DOS.  In fact,
Windows 95 relates to DOS in the same way that Workgroups
3.11 does when you have 32-bit file access enabled.  What
kind of brand-new operating system is this?

Whoever wrote this part of Microsoft's response hasn't
really thought through this issue very carefully; they
should check out pp.  242-244 of my book.

>>> 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.

No, the book doesn't ignore this.  It points out the
tradeoffs: if you want a purer 32-bit system like NT, you're
going to lose compatibility.  Meanwhile, Microsoft should
stop trying to give the impression that Win95 is some sort
of "NT Lite."

>>> 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

Actually, right on p. 60 I say that, when a Microsoft VP
told me that Win95 "pushes real-mode drivers aside," I bet
he just meant that "the Windows 95 setup program removes
DEVICE= lines from CONFIG.SYS."

So Microsoft is confirming then that this is all that
"pushes real-mode drivers aside" means (with the small
difference that the setup program comments-out rather than
removes the DEVICE= line).  I say as much in the book.

The point, however, is that this is *not* how most computer
journalists have interpreted the phrase.  And until this
statement, Microsoft has let them go on thinking that Win95
could actually remove real-mode drivers from memory.  Which
it won't.  Were some old setup program to come along and put
MSCDEX.EXE in your AUTOEXEC.BAT after you've set up Win95,
would Win95 "push it aside"?

>>> 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.

This is hardly a major point of the book, but I would note
that on p. 62 I point out that "some thought [at Microsoft]
did go into bypassing WIN.COM.  But WIN.COM plays an
important role in Windows 95."  Now, I'm not sure that my
description of this important role ("prevents you from
exiting back to DOS") is actually accurate.  But at any rate
I wasn't making a big deal out of whether they use WIN.COM
or not.  I could see that they had early on attempted to
bypass it, but that they don't bypass it.

The "there are real-mode drivers out there which insert
themselves at various places in the Windows 3.1 boot
process" is very vague. What's this have to do with WIN.COM? 
Are there real-mode drivers that rely on the presence of
WIN.COM?  I think a better reason is that WIN.COM (as
explained in Matt Pietrek's book *Windows Internals*)
provides some APIs that are used by the protected-mode
portion of Windows.  At any rate, this is hardly a major
point of my book, and I'm surprised that whoever wrote the
response seemed to think it was.

In essence, with their reply to my book Microsoft has
confessed that, contrary to their earlier claims, Windows 95
still uses DOS.

Andrew Schulman