In Forum: Windows 9x, ME
By User: Hyoenmadan86
DOS loaded before Windows, still runs in the same address, and still has its IVT (like all DOS sessions), but the thing is moved into V86 mode. What this means, is that the memory address etc are served off a page list held by VMM. and the interrupts are transferred from VMM's IDT to the local IVT if needed. In other words, the DOS before windows is running in a DOS Box, but Windows uses the loaded DOS to do things as if it were just another VxD. In other words, the IVT descends into protected mode, and it is the PM operating system that answers *all* of the DOS interrupts, but might forward *some* calls onto some real-mode DOS.
Finally you started to catch the deal. Congratulations! :clap: :clap: :clap:
DOSMGR is the one in control of this special DOS box, and the responsible of make it appear as if it was another VxD in the System VM. If you really have Schulmann's "Undocumented DOS" book, read Chapter.1 Page 22 and the whole Chapter 3. (would be nice if someone could scan this an other similar books, and make them available to BA memebers... unfortunately books aren't abandonware, and them have different copyright rules :-7). There is explained better how all the process is done, at least better than how i would explain it.
Evidently a number of people fell for it. Reading microsoft documents, be it the resource kit or the SDK, or any of the glossies or megos, is fraught with the danger that MS is presenting Windows 9x as something different to Windows 4 on DOS 7.
I never said that Win9x isn't Win4 on DOS. I'm saying that, once Win9x (and Win3x 386 mode btw) VMM get loaded, it behaves as any authentic OS, like NT, Linux, Netware or any other [censored]. There's no such magic thing as DOS with a nice Windows shell, at least no in the sense of the DOSSHELL app that you mentioned before, while Windows is running in 386 mode.
Btw, did you know that when you run DOSSHELL with the Task Switcher applet enabled, it behaves like Windows standard mode and makes use of all the DOSX facilities built with the program? Dosshell isn't a simple [censored] like Norton commander or such file managers. It can do some advanced things with DOS sessions like any windows standard mode could and is pretty explained in Windows 3.0 DDK and some bits in the DOS6 OAK. Is only that such functionality was never advertized as MS wanted you to buy windows.
Schulmann identified the erratic behaviour with the win9x win.com, not with loading and unloading the dos32 or windows layers. In short, win.com is a badly written TSR. If you avoid win.com, windows exits cleanly to a proper DOS prompt.
WIN.com isn't a TSR, but just a loader, with a fixed and well defined task. That is load Windows based in the command line parameters that you choosed. Once its assigned task ends, it gets erased from the memory completely. Do you know LOADLIN.com? That's what WIN.com is for Win1,2,3.. and 9x.
Unload windows task belongs to VMM or DOSX, depending if you're using Windows in Standard mode, or Windows 386 mode/Win9x.
So it's not in Microsoft's interest to pretend that 'restart to DOS' is just plain ordinary 'exit window', even though the exit windows calls are made as windows restarts to DOS. Calling it a VMM gives the impression that Windows is still present. Schulmann showed that Windows exits to win.com, and it's win.com that is broken. Window 3.1 exits perfectly, so the offered reasons why Exit to DOS is broken should apply to Windows 3.1 too.
There's a reason why VMM can't restore DOS state as how was done in Win3.x
When Win3x existed, there where almost no Windows protected mode drivers to manage the hardware, and ofc anything like plug and play. All the PC configuration was fixed once the machine was ON, and almost all was managed entirely by BIOS and DOS, even in 386 mode (Yeah, though the Dos Box "VxD" that you mentioned before, and other VxD known as BIOSXLAT). That's why the real mode machine state was kept almost fixed during all the windows session and was possible for windows restore such state easily and almost without any change.
Windows 9x had protected mode drivers for almost all thing in the PC. VxD drivers do things that machine bios and DOS VM aren't aware, like reset and reconfigure device IRQs, change device parameters and such. Is the task of the VxD driver restore the state of the device once it gets unloaded. In some cases, a bad written VxD will not let the device in a state that can be used by the Dos real mode session. In other cases, like BIOS USB emulation mode for storage and input devices, is just not possible, since that state belongs to BIOS, and restoring such state involves to execute BIOS POST routines again. Some programs like my DOOM example doesn't like how windows CONFIGMG.vxd restores the machine IRQ state. If your drivers are WDM almost all them, is possible that your "Restart to DOS" session will not behave as expected, and this is one of the reasons why it was disabled in WinMe, since this windows version was expected to run almost all the hardware with WDM drivers.
But.... in windows 3.x there's one exception that shows how it can't restore a perfect real mode DOS session as you claim. If you used protected mode 386 drivers to access the hard disk controller, like ONTRACKW.386, WDCTRL.386 or any VxD that came with those older SCSI controllers, you would find how the first bogus versions of those drivers wouldn't restore the HDD controller device and BIOS state completely, making Win3x crash while quitting to DOS, or what was worse, restoring a DOS session in a state that would lead to data corruption. That's why, even when the drivers got fixed, almost no one wanted to use them, even if that would lead to a faster IO performance, since those drivers where 32bit protected mode modules, just like any VXD driver found in Win9x.
This is exactly what you would expect a program that expects to be loaded is the sole control of the computer would do. It is running in background because the video calls are handled in windows, and there's nothing to control it, because to run DOS apps in windows, you need a windows host, because the DOS app is simply a WOA data file. Rather like running a rexx script under winrexx.
The same happens if you kill the VMware.exe GUI and let the VMWare-VMX running all your VMs alone. Then, VMware-VMX.exe is the real host, not the Vmware.exe fancy GUI, even if the GUI is the one that provides all the screen, keyboard and mouse IO, and all the integration services, like shared folders and clipboard integration.
WOA is not a fancy program like console2.exe. It is basically a shield to make a DOS program think it's running alone, but handles all sorts of calls and passes them onto windows. DOS programs are not multitasking, and unless the call is jagged higher up in the interrupt chain, the program thinks that all calls are intended for it. WOA does the necessary filtering.
Everyone knows that WOA is better integrated in Windows services than any cheap [censored] as Console2.exe, but that doesn't make it different than any other VM frontend. If you want to, you can call a WOA a pretty nice "manager" for DOS box sessions, but definitely it isn't the host of the DOS boxes, just like VMware.exe isn't the host of the Vmware VMs in my anterior example. DOS Box host is the VMM itself, which uses the DOS copy that was present when VMM was loaded, to spawn them all.
woa in standard mode can only run windows in full screen mode. This is because in 286 mode, memory is swapped, rather than paged, and you can't run std-mode woa in a windows, because the video table is out of memory too.
Yes, this process is called DOS screen grabbing, which uses special drivers with the 3gr extension, and is better explained in the Win3.0 DDK QuickHelp books, available in BA.