The role of MS-DOS in Windows 95
Mark Kent
and its role on Win95 systems. Here, I extract some material from an MS
developer's blog which describes, in fine detail, the role MS-DOS
actually played in providing a 16-bit driver layer which Win95 used
through all of its run-time, both for itself and for any running
applications. I provide the URL so you can look for yourself.
The article is very clear indeed.
<quote>
http://blogs.msdn.com/oldnewthing/archive/2007/12/24/6849530.aspx
What was the role of MS-DOS in Windows 95?
<snip>
Here goes. Remember, what I write here may not be 100% true, but it is
"true enough." (In other words, it gets the point across without getting
bogged down in nitpicky details.)
MS-DOS served two purposes in Windows 95.
* It served as the boot loader.
* It acted as the 16-bit legacy device driver layer.
When Windows 95 started up, a customized version of MS-DOS was loaded,
and it's that customized version that processed your CONFIG.SYS file,
launched COMMAND.COM, which ran your AUTOEXEC.BAT and which eventually
ran WIN.COM, which began the process of booting up the VMM, or the 32-bit
virtual machine manager.
The customized version of MS-DOS was fully functional as far as the phrase
"fully functional" can be applied to MS-DOS in the first place. It had
to be, since it was all that was running when you ran Windows 95 in
"single MS-DOS application mode."
The WIN.COM program started booting what most people think of as "Windows"
proper. It used the copy of MS-DOS to load the virtual machine manager,
read the SYSTEM.INI file, load the virtual device drivers, and then
it turned off any running copy of EMM386 and switched into protected
mode. It's protected mode that is what most people think of as "the
real Windows."
Once in protected mode, the virtual device drivers did their magic. Among
other things those drivers did was "suck the brains out of MS-DOS,"
transfer all that state to the 32-bit file system manager, and then
shut off MS-DOS. All future file system operations would get routed
to the 32-bit file system manager. If a program issued an int 21h,
the 32-bit file system manager would be responsible for handling it.
And that's where the second role of MS-DOS comes into play. For you see,
MS-DOS programs and device drivers loved to mess with the operating
system itself. They would replace the int 21h service vector, they
would patch the operating system, they would patch the low-level disk
I/O services int 25h and int 26h. They would also do crazy things to
the BIOS interrupts such as int 13h, the low-level disk I/O interrupt.
When a program issued an int 21h call to access MS-DOS, the call
would go first to the 32-bit file system manager, who would do some
preliminary munging and then, if it detected that somebody had hooked
the int 21h vector, it would jump back into the 16-bit code to let the
hook run. Replacing the int 21h service vector is logically analogous to
subclassing a window. You get the old vector and set your new vector. When
your replacement handler is called, you do some stuff, and then call
the original vector to do "whatever would normally happen." After the
original vector returned, you might do some more work before returning
to the original caller.
One of the 16-bit drivers loaded by CONFIG.SYS was called IFSMGR.SYS. The
job of this 16-bit driver was to hook MS-DOS first before the other
drivers and programs got a chance! This driver was in cahoots with the
32-bit file system manager, for its job was to jump from 16-bit code back
into 32-bit code to let the 32-bit file system manager continue its work.
In other words, MS-DOS was just an extremely elaborate decoy. Any 16-bit
drivers and programs would patch or hook what they thought was the
real MS-DOS, but which was in reality just a decoy. If the 32-bit file
system manager detected that somebody bought the decoy, it told the
decoy to quack.
Let's start with a system that didn't contain any "evil" drivers or
programs that patched or hooked MS-DOS.
Program calls int 21h
32-bit file system manager
checks that nobody has patched or hooked MS-DOS
performs the requested operation
updates the state variables inside MS-DOS
returns to caller
Program gets result
This was paradise. The 32-bit file system manager was able to do all
the work without having to deal with pesky drivers that did bizarro
things. Note the extra step of updating the state variables inside
MS-DOS. Even though we extracted the state variables from MS-DOS during
the boot process, we keep those state variables in sync because drivers
and programs frequently "knew" how those state variables worked and
bypassed the operating system and accessed them directly. Therefore, the
file system manager had to maintain the charade that MS-DOS was running
the show (even though it wasn't) so that those drivers and programs saw
what they wanted.
Note also that those state variables were per-VM. (I.e., each MS-DOS
"box" you opened got its own copy of those state variables.) After all,
each MS-DOS box had its idea of what the current directory was, what was
in the file tables, that sort of thing. This was all an act, however,
because the real list of open files was kept in by the 32-bit file system
manager. It had to be, because disk caches had to be kept coherent,
and file sharing need to be enforced globally. If one MS-DOS box opened
a file for exclusive access, then an attempt by a program running in
another MS-DOS box to open the file should fail with a sharing violation.
Okay, that was the easy case. The hard case is if you had a driver that
hooked int 21h. I don't know what the driver does, let's say that it's a
network driver that intercepts I/O to network drives and handles them in
some special way. Let's suppose also that there's some TSR running in the
MS-DOS box which has hooked int 21h so it can print a 1 to the screen
when the int 21h is active and a 2 when the int 21h completes. Let's
follow a call to a local device (not a network device, so the network
driver doesn't do anything): Program calls int 21h
32-bit file system manager notices that somebody has patched or hooked
MS-DOS jumps to the hook (which is the 16-bit TSR)
16-bit TSR (front end) prints a 1 to the screen calls previous handler
(which is the 16-bit network driver)
16-bit network driver (front end) decides that this isn't a network I/O
request calls previous handler (which is the 16-bit IFSMGR hook)
16-bit IFSMGR hook tells 32-bit file system manager that it's time to
make the donuts
32-bit file system manager regains control performs the requested
operation updates the state variables inside MS-DOS returns to caller
16-bit network driver (back end) returns to caller
16-bit TSR (back end) prints a 2 to the screen returns to caller Program
gets result
Notice that all the work is still being done by the 32-bit file system
manager. It's just that the call gets routed through all the 16-bit stuff
to maintain the charade that 16-bit MS-DOS is still running the show.
The only 16-bit code that actually ran (in red) is the stuff that the
TSR and network driver installed, plus a tiny bit of glue in the 16-bit
IFSMGR hook. Notice that no 16-bit MS-DOS code ran. The 32-bit file
manager took over for MS-DOS.
A similar sort of "take over but let the crazy stuff happen if somebody
is doing crazy stuff" dance took place when the I/O subsystem took over
control of your hard drive from 16-bit device drivers. If it recognized
the drivers, it would "suck their brains out" and take over all the
operations, in the same way that the 32-bit file system manager took
over operations from 16-bit MS-DOS. On the other hand, if the driver
wasn't one that the I/O subsystem recognized, it let the driver be the
one in charge of the drive. If this happened, it was said that you
were going through the "real-mode mapper" since "real mode" was name
for the CPU mode when protected mode was not running; in other words,
the mapper was letting the 16-bit drivers do the work.
</quote>
Ie., MS-DOS was still resident, and still doing 16-bit driver work,
exactly, and precisely as I stated.
--
| mark at ellandroad dot demon dot co dot uk |
| Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
| Cola trolls: http://colatrolls.blogspot.com/ |
| Open platforms prevent vendor lock-in. Own your Own services! |
Peter Köhlmann
< snip completely mis-understood reference >
> Ie., MS-DOS was still resident, and still doing 16-bit driver work,
> exactly, and precisely as I stated.
>
Again, Mark, please tell Andrew Schulman. He will be very surprised that
large portions of his book have just been totally "invalidated" by
your "discovery". And that all the people he worked with to research that
book had no clue (as they obviously failed to ask you in the first place)
You are obviously unable to admit to be wrong. Hence your need to totally
misinterpret (Snot Glasser like) every reference you find and can't really
understand
--
FLASH! Intelligence of mankind decreasing. Details at ... uh, when
the little hand is on the ....
Moshe Goldfarb.
> There's been some significantly ill-informed discussion regarding MS-DOS
> and its role on Win95 systems.
Apparently coming only from you Mark Kent.
Seeing as most people have you filtered, it probably won't do too much
damage.
--
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
Mark Kent
> Mark Kent wrote:
>
>
>< snip completely mis-understood reference >
>
>> Ie., MS-DOS was still resident, and still doing 16-bit driver work,
>> exactly, and precisely as I stated.
>>
>
> Again, Mark, please tell Andrew Schulman. He will be very surprised that
> large portions of his book have just been totally "invalidated" by
> your "discovery". And that all the people he worked with to research that
> book had no clue (as they obviously failed to ask you in the first place)
>
> You are obviously unable to admit to be wrong. Hence your need to totally
> misinterpret (Snot Glasser like) every reference you find and can't really
> understand
The posting I presented was written by one of the authors of Win95.
You are confusing two quite separate issues.
Clearly, you are unable to admit to your error.
Peter Köhlmann
> Peter Köhlmann <peter.k...@arcor.de> espoused:
>> Mark Kent wrote:
>>
>>
>>< snip completely mis-understood reference >
>>
>>> Ie., MS-DOS was still resident, and still doing 16-bit driver work,
>>> exactly, and precisely as I stated.
>>>
>>
>> Again, Mark, please tell Andrew Schulman. He will be very surprised that
>> large portions of his book have just been totally "invalidated" by
>> your "discovery". And that all the people he worked with to research that
>> book had no clue (as they obviously failed to ask you in the first place)
>>
>> You are obviously unable to admit to be wrong. Hence your need to totally
>> misinterpret (Snot Glasser like) every reference you find and can't
>> really understand
>
> The posting I presented was written by one of the authors of Win95.
Certainly, Mark, certainly. Did I mention that I am one of the authors of
the bible, as well of the Popol Vuh and several other prominent books?
Do you actually believe yourself that bullshit you are telling here?
> You are confusing two quite separate issues.
You are not smart enough to confuse anything at all
> Clearly, you are unable to admit to your error.
>
You are just simply an idiot.
--
Meddle not in the affairs of Dragons, For thou art crunchy, and good
with ketchup!
Moshe Goldfarb.
Looks like Peter Kohlmann has Mark Kent in the old "rope a dope" position.
Get ready for Mark Kent to slink....
Mark Kent
> Mark Kent wrote:
>
>> Peter Köhlmann <peter.k...@arcor.de> espoused:
>>> Mark Kent wrote:
>>>
>>>
>>>< snip completely mis-understood reference >
>>>
>>>> Ie., MS-DOS was still resident, and still doing 16-bit driver work,
>>>> exactly, and precisely as I stated.
>>>>
>>>
>>> Again, Mark, please tell Andrew Schulman. He will be very surprised that
>>> large portions of his book have just been totally "invalidated" by
>>> your "discovery". And that all the people he worked with to research that
>>> book had no clue (as they obviously failed to ask you in the first place)
>>>
>>> You are obviously unable to admit to be wrong. Hence your need to totally
>>> misinterpret (Snot Glasser like) every reference you find and can't
>>> really understand
>>
>> The posting I presented was written by one of the authors of Win95.
>
> Certainly, Mark, certainly.
<snip irrelevent bit>
I've authored some books too. That too is not relevant.
You are confusing two quite separate issues, they being what happens to
the initial instance of DOS versus how Win95 offers subsequent DOS
instances. They use completely different processes.
You are confused.
Moshe Goldfarb.
> Peter Köhlmann <peter.k...@arcor.de> espoused:
>> Mark Kent wrote:
>>
>>> Peter Köhlmann <peter.k...@arcor.de> espoused:
>>>> Mark Kent wrote:
>>>>
>>>>
>>>>< snip completely mis-understood reference >
>>>>
>>>>> Ie., MS-DOS was still resident, and still doing 16-bit driver work,
>>>>> exactly, and precisely as I stated.
>>>>>
>>>>
>>>> Again, Mark, please tell Andrew Schulman. He will be very surprised that
>>>> large portions of his book have just been totally "invalidated" by
>>>> your "discovery". And that all the people he worked with to research that
>>>> book had no clue (as they obviously failed to ask you in the first place)
>>>>
>>>> You are obviously unable to admit to be wrong. Hence your need to totally
>>>> misinterpret (Snot Glasser like) every reference you find and can't
>>>> really understand
>>>
>>> The posting I presented was written by one of the authors of Win95.
>>
>> Certainly, Mark, certainly.
>
> <snip irrelevent bit>
>
> I've authored some books too. That too is not relevant.
So where can we download them for free?
Phil Da Lick!
> On Mon, 11 Aug 2008 10:43:12 +0100, Mark Kent wrote:
>
>> Peter Köhlmann <peter.k...@arcor.de> espoused:
>>> Mark Kent wrote:
>>>
>>>> Peter Köhlmann <peter.k...@arcor.de> espoused:
>>>>> Mark Kent wrote:
>>>>>
>>>>>
>>>>> < snip completely mis-understood reference >
>>>>>
>>>>>> Ie., MS-DOS was still resident, and still doing 16-bit driver work,
>>>>>> exactly, and precisely as I stated.
>>>>>>
>>>>> Again, Mark, please tell Andrew Schulman. He will be very surprised that
>>>>> large portions of his book have just been totally "invalidated" by
>>>>> your "discovery". And that all the people he worked with to research that
>>>>> book had no clue (as they obviously failed to ask you in the first place)
>>>>>
>>>>> You are obviously unable to admit to be wrong. Hence your need to totally
>>>>> misinterpret (Snot Glasser like) every reference you find and can't
>>>>> really understand
>>>> The posting I presented was written by one of the authors of Win95.
>>> Certainly, Mark, certainly.
>> <snip irrelevent bit>
>>
>> I've authored some books too. That too is not relevant.
>
> So where can we download them for free?
>
>
And why do you think you should be able to? He didn't qualify whether he
was writing for himself, or as part of his job. He also didn't qualify
what the books were about, or whether they were intended to be freely
available. If he'd stated that he wrote them on behalf of himself and
made them available for free download then perhaps your question would
have some validity.
Tim Smith
Yes, it is. It is a testament to your astonishing intellect that you
still managed to misunderstand it.
> <quote>
>
> http://blogs.msdn.com/oldnewthing/archive/2007/12/24/6849530.aspx
>
...
> Once in protected mode, the virtual device drivers did their magic. Among
> other things those drivers did was "suck the brains out of MS-DOS,"
> transfer all that state to the 32-bit file system manager, and then
> shut off MS-DOS. All future file system operations would get routed
> to the 32-bit file system manager. If a program issued an int 21h,
> the 32-bit file system manager would be responsible for handling it.
>
> And that's where the second role of MS-DOS comes into play. For you see,
> MS-DOS programs and device drivers loved to mess with the operating
> system itself. They would replace the int 21h service vector, they
> would patch the operating system, they would patch the low-level disk
> I/O services int 25h and int 26h. They would also do crazy things to
> the BIOS interrupts such as int 13h, the low-level disk I/O interrupt.
>
> When a program issued an int 21h call to access MS-DOS, the call
> would go first to the 32-bit file system manager, who would do some
> preliminary munging and then, if it detected that somebody had hooked
> the int 21h vector, it would jump back into the 16-bit code to let the
> hook run. Replacing the int 21h service vector is logically analogous to
And how do you think it does that "jump back into the 16-bit code"? It
does it by sending a virtual interrupt into the copy of DOS that is
running in a V86 virtual machine.
...
> </quote>
>
> Ie., MS-DOS was still resident, and still doing 16-bit driver work,
> exactly, and precisely as I stated.
No, that is NOT precisely what you stated. You went farther, and
asserted that it is running in actual real mode, on the bare hardware,
rather than in a V86 virtual machine under the control of the 32-bit
protected mode Windows code.
--
--Tim Smith
Mark Kent
Bizarre view of the world Gary has, isn't it? Well, if you want
something for free, you can read the howto I wrote a looong time ago,
in fact, 2003, according to the date on it:
http://www.elug.co.za/index.php?page=streaming.php
So Gary can download just as many copies of this as he likes, and he can
even listen to talk radio 702 from jo'burg if he wishes...