Mail Archives: opendos/2000/09/21/11:20:04
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
- Raw text -