The architecture of Windows 9x

[Nomen]

Is the following true?

----------

The architecture of Windows 9x series OS kernel is monolithic. The basic code is considered similar in function to MS-DOS - as a 16/32 bit hybrid, it requires MS-DOS support to operate.

-----------

That's from here: http://en.wikipedia.org/wiki/Architecture_of_Windows_9x

After being invoked from a transient 16-bit DOS state, does Win-9x _really_ require some form of DOS running at some level? Even if most of what Win-9x does is via 32-bit API functions and hardware drivers?

[dencorso]

Yes. 9x/ME actually is monolithic. And, BTW, BSD and Linux are monolithic, too. OTOH, the NT-OSes are hybrid.

Yes: you can envisage 9x/ME running over DOS as a form of assimilation (in the Borg sense), but one that can be reversed more easily, so that after 9x/ME finishes and relinquishes DOS, it still behaves as fully as DOS as it did before starting 9x/ME (differently from, say, 7 of 9).

[jaclaz]

(differently from, say, 7 of 9).

Yes and no.

Windows 9x/Me wraps around Dos much in the same way as 7 of 9's suit wraps around her body, though the final results is IMHO much better looking in the latter case .

 

jaclaz

[Nomen]

In terms of providing core functions (such as screen, disk/file-system, network and keyboard I/O) to the user shell or Win32 applications, how does Win-9x/me rely on some DOS code or layer to provide those functions?

[submix8c]

http://en.wikipedia.org/wiki/IO.SYS

And that's limited to the "basics".

Networking is an entirely independent function, since that hardware *may* not exist on the Motherboard. Any "driver" needed to access other than "basic" hardware will depend on the OS environment. (DOS, Win9X, NT-something).

Fun topic (re: Networking) -

http://www.msfn.org/board/topic/173062-intel-ethernet-connection-driver-for-windows-98se/

IOW, (e.g.) Sound Cards have absolutely nothing to do with "essential to boot" functions.

[Glenn9999]

In terms of providing core functions (such as screen, disk/file-system, network and keyboard I/O) to the user shell or Win32 applications, how does Win-9x/me rely on some DOS code or layer to provide those functions?

 

It's best to think of Windows as a desktop program, more than an OS when it comes to this era.  In that sense, Windows itself is just a program that runs on top of DOS.  Anything earlier than Windows 95 actually ran this way, where you had to boot DOS and then type "Win" to get the Windows desktop program (of course you could always do this with AUTOEXEC.BAT, but that's neither here nor there).  Of course, there were APIs that programs could hook into while Windows was active, and that was what constituted "Windows programs".  95, 98, and ME blurred this line, mainly by hard code booting into the desktop.  But DOS was always there in any of these cases, to the point that you could construct a real "DOS" boot disk out of the files that existed in these Windows installs.

Edited December 5, 2014 by Glenn9999

[rloew]

Windows 9x is not hard coded into the Desktop. Add COMMAND to your AUTOEXEC.BAT and you will see.

You can still run WIN to go to Desktop. The difference is that exiting the Initial COMMAND.COM runs WIN automatically.

Windows uses DOS to Bootstrap. Once running it does not depend upon DOS except for Compatability Mode Functions.

Edited December 6, 2014 by rloew

[dencorso]

Once running it does not depend upon DOS except for Compatability Mode Functions.

 

Once running it does not depend upon DOS code, except for Compatability Mode Functions. 9x/ME uses many data tables and variables it inherits from DOS, that is, most of the DOS data, which remains in use while 9x/ME is running, and which is returned to DOS control when 9x/ME terminates. Although, in the case of ME, that's somewhat better hidden than before. The assimilation metaphor holds very well.

[Nomen]

http://en.wikipedia.org/wiki/IO.SYS

That link provides not a single piece of information explaining how or why IO.sys plays any role in win-9x operation.

Once you get past the hangup that win-9x is invoked from a transient DOS state, all these various attempts to explain how DOS code remains a necessary foundation for win-9x to operate simply falls apart.

[Nomen]

Windows uses DOS to Bootstrap. Once running it does not depend upon DOS except for Compatability Mode Functions.

And haven't I been saying exactly that?

Haven't I been saying that win-9x is invoked from a transient DOS state?

How on earth can DOS-era code or functionality be of any use (let alone be REQUIRED) for win-9x to perform it's core functions of supporting Win32 software and 32-bit hardware drivers?

You want to run 16-bit DOS-era programs? No problem - Win-9x will create a virtual DOS environment for them - just like most NT versions of windows will.

You have only 16-bit drivers for some ancient hardware components? No problem - win-9x might (or will) make use of them (in a way that NT won't or can't) via some sort of DOS layer. That doesn't mean Win-9x is dependant on a dos layer. It means you're running 9x on pathetic hardware.

> 9x/ME uses many data tables and variables it inherits from DOS, that is, most

> of the DOS data, which remains in use while 9x/ME is running, and which is

> returned to DOS control when 9x/ME terminates.

The idea or ability to return to the original DOS state after 9x/me terminates is somewhat bogus, because the vast majority of 9x/me use-case situations does not involve returning to this DOS state. When a typical 9x/me computer is turned on, the user expects to go straight into Windows, and when the use-session is ended, the computer is shut down - there is no desire to re-enter the DOS state to perform any tasks or to use the computer in that state. The fact that 9x/me can "remember" the original DOS state and can return to it after terminating windows is hardly something to point to as an indication that DOS forms some sort of crucial layer or foundation *while* 9x is operating.

Edited December 6, 2014 by Nomen

[jaclaz]

I am failing to see why you are asking questions when you already know all the answers to them.

 

jaclaz

[ZortMcGort11]

When I hear people saying that Windows runs on "top" of DOS, I imagine something like this....

File Manager (WINFILE.EXE in your C:\WINDOWS\ directory), whenever it needs to do something it makes calls, passes arguments, or transfers control over to, say, MOVE.EXE or COMMAND.COM, because, you know, THOSE files do all the ACTUAL work of copying things. File Manager is just a SHELL. File manager is just the middle man between the user and DOS. It's purpose is mysterious... will it function without DOS??

For example, go into File Manager and highlight a bunch of random files in a directory, like 100 files. Holding down the CTRL key, click away on a bunch of things. Then go up to the File Menu and click on copy... it will ask you where to copy the files to.

Now, I'm wondering, is it FILE MANAGER that copies those files, or is it COMMAND.COM? Seems like DOS wouldn't be able to handle such a huge amount of files to copy. Probably overflow the buffer or stack or something. Fill up the memory pretty quickly.

Either way, I'd rather use File Manager, except in the simplest cases of duplicating files, or copying/deleting/moving a single file at a time at the dos prompt. Either way, File Manager offers superior FILE MANAGEMENT over DOS. So you must wonder if they are really the "same" program, except one is just a graphical shell with fancy menus.

But, is it a DOS program that copies those files, or is it a Windows Program?

Anyways, that's the thought that comes to mind whenver this discussion of DOS "running" windows comes up.

It's like the QBasic "Chain" command. Control of a program is transferred to another program. Is that what Windows does, simply dumps all it's problems onto poor old DOS? Of course, using a BASIC command is a terrible example, but it's all I could think of. I'm sure there is a better command in C++ or Assembly or whatever they used to write Windows and DOS.

It's like a zen riddle.... I really don't know who to believe. But this topic has never been answered to my understanding in the last 20 years...

Edited December 6, 2014 by LostInSpace2012

[dencorso]

Let me put it in a different light for you: when Win 95 starts, it Isolates that 1088 KiB (which is where Real Mode DOS booted) in Machine #0.

Then, it *takes possession* of the machine in the fullest extent possible and provides each new Virtual-86 DOS machine created it's own "booted DOS" image, which consists of some instanced parts of what is in Machine #0 (and these instanced parts are discardable) and of other parts of that memory are actually shared (and which, if modified in a wrong way, can crash the machine). Some data structures created by DOS and HIMEM are used by Win 95 as inherited from DOS. No, or almost no, code, from DOS is ever executed for Win 95 normal functioning. The underlying DOS is in "suspended animation" until Win 95 terminates. Exactly 0% of the CPU time it is running in Real-Mode, after Win 95 has sucessfully started.

Well, the previous time Nomen took us for a similar dance, half again a year ago, I gave him the above answer, which think it's pretty comprehensive. However, on re-reading it, I've decided to add some extra words and punctuation (in red, to highlight they are later additions), to make it even clearer.

 

In any case, I then recommended the thorough reading of Andrew Schulman's Unauthorized Windows 95 (ISBN 1-56884-169-8, nowadays it is really cheap, as an obsolete used tech book), for further information (a wealth of it, BTW), and I continue to stand by that recommendation.

[rloew]

Since Windows 9x provides a functional Pre-Windows DOS environment, think CONFIG.SYS and AUTOEXEC.BAT, it needs to provide the same environment while in Windows. This requires it to retrieve some information from DOS. There is very little, if any, DOS Code actually run by Windows, except for Setup, unless you have unrecognized TSRs or missing 32-Bit Drivers.

There is a significant amount of 16-Bit Code carried over from Windows 3 but it runs in Protected Mode, not Real or Virtual Mode.

Non-UEFI Windows NT Software has to use 16-Bit Code to Boot itself and tries to switch to Protected mode as fast as possible. There are a number of consequences to this. If you run File Manager or Virtual DOS, the Drive Letters will often not be in the same order as in DOS. If yoiu do not have a Driver for something, you will have no functionality at all, rather than the limited Functionality of Compatability Mode. Also many changes to the Boot Hard Drive, that Windows 9x can handle, will make Windows NT unbootable.

[Glenn9999]

 File manager is just the middle man between the user and DOS. It's purpose is mysterious... will it function without DOS??

For example, go into File Manager and highlight a bunch of random files in a directory, like 100 files. Holding down the CTRL key, click away on a bunch of things. Then go up to the File Menu and click on copy... it will ask you where to copy the files to.

Now, I'm wondering, is it FILE MANAGER that copies those files, or is it COMMAND.COM? Seems like DOS wouldn't be able to handle such a huge amount of files to copy. Probably overflow the buffer or stack or something. Fill up the memory pretty quickly.

 

Okay, let's see if I can remember it all.

 

Like I mentioned before, Windows exposes certain APIs to programs designed to run under the Desktop.  Some of those are your File Manager functions.  Basically, it calls the API with the files and the action is accomplished.  This is what the Windows developer sees and what File Manager calls.

 

Behind those API calls are your linkages to DOS.  The main purpose of DOS is to expose certain hardware functions, along with some basic OS functions.  This is done via interrupts.  Most high-level DOS compilers have similar API functions to the Windows ones to do certain functions like copy or delete files, so nine times out of ten the programmer doesn't see these unless specifically desired.  But behind those is the interrupt calls.  There's a huge list of those, to the point that you can fill a floppy disk or two with it and accompanying documentation (not big now, but big back then).  In ASM and low-level you'd have to call these to get anything done - put text on the screen, load programs to run, read input from the keyboard, turn pixels on and off on the monitor, read from memory.  Basically put: Everything.   As I mentioned before, along with hardware functions, DOS has a huge catalog of interrupt functions (specifically INT 21).  To copy a file in ASM or low-level, it would involve hitting the proper INT functions in the right order (Access File, Read Buffer, Create File, Write Buffer, etc) to accomplish the copy.

 

As you might imagine by this description, programming is an exercise of taking simple blocks of functions and organizing them to do more complex things.   Code the low-level machinations to copy a file into a procedure call.  Modularize it.  Then use that to process the whole list as presented by file manager, the complexity is increased.  This idea exists with everything, including code to draw windows in standardized manners - the main basis behind things such as Windows or DESQview or basically anything you can think of. 

 

So to answer your question, File Manager is copying the files by calling a Windows API call which in turn triggers certain DOS interrupt calls.  It really isn't File Manager or COMMAND.COM or any other specific file command that's doing the job.  But File manager can't function without the API calls exposed by the Windows DLLs, or the Interrupt calls exposed by DOS.

 

(and I realize that certain drivers in Windows might change this model around, but it's a basic sketch of how things worked in the 3.1/9X world)

Edited December 7, 2014 by Glenn9999