From: "Matthias Paul" <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
Organization:  Rechenzentrum RWTH Aachen
To: opendos AT delorie DOT com
Date:          Thu, 21 Sep 2000 17:14:48 +0100
Subject:       Re: About Micro$quash DOS 7 (hiding in Win98).
X-mailer: Pegasus Mail v3.22
Message-ID: <24894A4722F@reze-1.rz.rwth-aachen.de>
Reply-To: opendos AT delorie DOT com

On Sat, 16 Sep 2000 "David A. Cobb" wrote:

> Actually, my question was intended more as "why can't a (Other-Than-MS)
> DOS-alike run Win98 as a "client?"  Are there secret services, like memory
> management, that Win still doesn't do for itself?  

While Windows replaces some of the DOS functionality (mainly in the 
VxD layer), it still uses large portions of the underlaying DOS even 
when the GUI is up and running. You can think of the Windows core
(not the GUI itself, which is nothing more than a Windows shell 
application named "Explorer") as of a multitasking DOS extender. 
When it starts up, it issues special broadcasts to inform about this 
situation. DOS will than slightly change its behaviour on various 
functions, and will report back a list of special data areas which 
must be instanced in a multitasking environment. Furthermore, Windows 
dynamically patches around in DOS to trap some of its inner 
functions so that to gets called back by DOS. This is very version 
dependent and Windows adapts to the various MS/PC DOS issues
by checking some signatures and using a number of other "interesting"
tricks (like the famous "AARD" code).

This works with MS-DOS/PC DOS, but also with Novell DOS 7+ 
(DR DOS 6.0 and earlier did not implement the DOSMGR interface,
hence they had to stick at the DOS 3.31 API level, because Windows 
uses different, less invasive methods to work with these old issues).
BTW. The model of startup/exit broadcast and reporting instance
data etc. is almost identical for the DR-DOS EMM386 /MULTI + TASKMGR.

Regarding the question of services used by Windows: The actual amount 
of functions passed down to the DOS kernel varies between the many 
issues from Windows 3.xx to Windows ME, but it is a significant 
number and Windows would probably not run a millisecond without 
the DOS kernel underneath servicing requests from Windows. Of course
other functions, like those to the memory manager are also passed
down to the DOS memory manager. If you do not load HIMEM.SYS etc.
in CONFIG.SYS, the DOS 7 IO.SYS will automatically load HIMEM.SYS
and a number of other drivers required by Windows.

At this layer Windows 95+ (that is MS-DOS 7.00+ plus Windows 4.00+) 
is not much different from DOS + Windows 3.xx. The differences are 
mainly that the previous files IO.SYS and MSDOS.SYS have been 
combined into IO.SYS (MSDOS.SYS is only a ASCII configuration file 
now). 
COMMAND.COM (the DOS shell), BTW, is only loaded, when AUTOEXEC.BAT 
exist or a SHELL= statement is found in CONFIG.SYS. It is not needed 
for Windows 95+ to run, because the auto-start of WIN.COM (the Windows 
launcher - which is NOT the Windows kernel by any means) is hardwired 
into IO.SYS and does not require a batch processor to interpret an 
AUTOEXEC.BAT file or display a prompt where WIN.COM would be entered. 
Not loading COMMAND.COM is one of the few advantages of this 
incarnation of this hybrid, because it saves ca. 5-8 Kb compared 
to previous issues. 
IO.SYS also has more or less trivial code added for boot logo 
support, the dual-boot facility menu and to log some data about
the system (Plug and Play stuff) and the drivers loaded in CONFIG.SYS 
(and optionally AUTOEXEC.BAT). In simple words, this is intended to 
improve the auto-detection of configuration changes, improver shut-
downs and the "compatibility mode" detection, however, Windows does 
not make much use of this.

> If I had an open source "mini-kernel" machine manager that ran in 
> 32-bit protected, segmented mode then what if it tries to start 
>"WIN.COM?" 
WIN.COM will try to defend this by various means... ;-) 
But it can be worked around.

> This whole S**T of tying the core management functions in with the 
> graphics and other service functions just gets me!
Well, the basic architecture is quite modular, but most of it is
not documented, and there are a number of IMHO artificial ties
that keep people from too easily "plug-and-play" replace some 
components by other (better) components... I agree with you.

 Matthias