The architecture of Windows 9x

[jaclaz]

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.

To be picky (as I am ) there is also the fact about the drive lettering algorithm being slightly different "by design" in DOS and NT, just for the record:

http://www.msfn.org/board/topic/35329-ever-wondered-why-xp-setup-changes-drive-letters/?p=243053

DOS:

https://web.archive.org/web/20100820162832/http://support.microsoft.com/kb/51978

NT:

http://support.microsoft.com/kb/93373/en-us

http://support.microsoft.com/kb/234048/en-us

 

and if you add to this the different volume ID's that the DOS and the NT can recognize, it is fairly easy on multi-hard disk systems or when there is any "non-floppy" or "non-harddisk" device connected (or even those connected through an interface that needs a driver in CONFIG.SYS) to have mismatching drive letter assignments.

 

jaclaz

[rloew]

To be even pickier, the Drive Letter Assignments in NT Systems can be changed by the user.

My point was that Windows 9x needs to match the DOS Drive Letter assignments so the DOS Drive Letter Table needs to be carried over to Windows. Windows cannot determine the Letter Assignments on it's own because they are affected by BIOS settings that are not visible to 32-Bit Code.

[jaclaz]

To be even pickier, the Drive Letter Assignments in NT Systems can be changed by the user.

And to be even pickier  this can be also done in DOS/Windows9x/Me, using LetterAssigner, and this makes a nice loopback to:

http://www.msfn.org/board/topic/118119-patched-iosys-for-9xme/

 

My point was that Windows 9x needs to match the DOS Drive Letter assignments so the DOS Drive Letter Table needs to be carried over to Windows. Windows cannot determine the Letter Assignments on it's own because they are affected by BIOS settings that are not visible to 32-Bit Code.

Sure , but while doing so, you named in vain the NT .

 

jaclaz

[submix8c]

(Thinking Nomen delights in starting threads so everyone will start "debating" and could care less about what's being said.)

[dencorso]

(Thinking Nomen delights in starting threads so everyone will start "debating" and could care less about what's being said.)

 

Not necessarily... last time, he had a quite pragmatic (although maybe questionable) reason for doing it, remember?

 

I'm trying to get more detailed answers than Yes/No, otherwise I can't put forward an argument (in another forum) to counter those claims. Not looking for pages and pages of explanations - a few sentences would do it... It looks like I won't get those answer here.

[rloew]

To be even pickier, the Drive Letter Assignments in NT Systems can be changed by the user.

And to be even pickier this can be also done in DOS/Windows9x/Me, using LetterAssigner, and this makes a nice loopback to:

http://www.msfn.org/board/topic/118119-patched-iosys-for-9xme/

Taking down the pickiness a bit. you can always break this relationship with third party software but it was not intended by Microsoft.

My point was that Windows 9x needs to match the DOS Drive Letter assignments so the DOS Drive Letter Table needs to be carried over to Windows. Windows cannot determine the Letter Assignments on it's own because they are affected by BIOS settings that are not visible to 32-Bit Code.

Sure , but while doing so, you named in vain the NT .

jaclaz

In vain?

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.

No. Normally the DOS Interrupts calls are not used. Windows replaces them with Protected Mode equivalents. When you copy a file, the following occurs:

1. File Manager calls the Windows API (KERNEL32.DLL).

2. KERNEL32.DLL reformats the call and invokes INT 30H.

3. VWIN32.VXD handles the INT 30H call and converts it into an INT 21H call.

4. The INT 21H handler passes the requests to IFSMGR.VXD.

5. IFSMGR.VXD passes the request to VFAT.VXD.

6. VFAT.VXD converts the requests into raw Disk commands and passes them to IOS.VXD.

7. IOS.VXD passes ther requests to ESDI_506.PDR.

8. ESDI_506.PDR sends the requests to the Hard Drive Controller.

DOS is not involved unless the drive is in compatability mode in which case the DOS code is run in Virtual Mode instead of using ESDI_506.PDR.

[jaclaz]

In vain?

Oww, come on, I was kidding, like "Thou shalt not take the name of ..." 

 

jaclaz

[Tripredacus]

I seem to recall that Windows 95 could be installed in two ways. One, which I never did as the software available to me in my early computing days was the result of hand-me-downs and stuff found in the trash. So my way of installing Windows 98 is to install Toshiba DOS 5, then installing Windows 95, then Windows 98FE Upgrade.

 

I had always heard that it was preferrable to install DOS prior to installing Windows 95, as it is possible to install Windows 95 on a blank disk. Is there any sort of different working in the DOS/95 relationship if DOS was installed first? Or is that just an old-wives tale?

[CamTron]

I think Raymond Chen described this pretty thoroughly in his blog. http://blogs.msdn.com/b/oldnewthing/archive/2007/12/24/6849530.aspx