Hello Adam,
On Thu, 11 Feb 2021 at 12:41, Adam Nielsen via Freedos-user < freedos-user@lists.sourceforge.net> wrote: > > Well, I tend to disagree with this, but by a semantic question :) > > In my opinion, VMM32 and all the VXDs are DOS, not Windows. They sound > to > > me like the natural evolution of EMM386.EXE. > > For me, Windows starts with KRNL386.EXE, not before (or with WIN.COM). > > I'm not familiar enough with VXDs but do they for example use the DOS > interrupt 21 to open files, or do they call a Windows API? > Windows API is far above this level. Well, this will be a spoiler of the "Unauthorized Windows95" :) Better read the book if you can, but here you go a summary. I write it to try and clarify some misunderstandings on VxDs and why I think they are great. Think of VMM32 as a 32-bit DOS implementation, where there are several DOS VM's, and that allows preemptively multitasking between them. (what's more, from Win95 onwards, it allows preemptive multi-threading inside each VM, whereas Win3.X does not). So it is like a super-powered version of EMM386.EXE (apparently, in some beta versions of Windows, VMM32.VXD was called DOS386.EXE). And think of VxDs as its device drivers. VxDs are 32-bit replacement for DOS and BIOS, providing the same DOS/BIOS interface for the different virtual machines and making sure that the different VMs will not collide with each other when using the same hardware. Simplifying a bit, this "32-bit DOS" has its own "CONFIG.SYS", that is the [386Enh] section of the SYSTEM.INI file (and this file has nothing to do with WIN.INI). There you control (to some extent) aspects of the VMM behaviour, and which VxDs are loaded (or at least some of them). See System.ini Options (archive.org) <http://web.archive.org/web/20060721141937/http://jmfmvps.mvps.org/system_ini_options.htm> Some VxD examples (if I recall correctly): DOSMGR - provides DOS INT 21h API for each VM VFAT - provides FAT/LFN for each VM VREDIR - provides the DOS network redirector for each VM VKD - provides keyboard interrupt management for each VM, and ensures that they do not collide in the use of the keyboard VCOMD - provides serial COM interrupt calls for each VM, and ensures that they do not collide in the use of the serial ports and so on. They also have an additional 32-bit interface, which can be used by applications on the VM. Unfortunately, I don't know of a good documentation of these interfaces. See for example: int 20 (ctyme.com) <http://www.ctyme.com/intr/int-20.htm> the functions are there, but no information of the input/output parameters. Fully 32-bit programs, such as Microsoft Windows, can be written over the VxDs. Thus, on Windows 3.X/9X/ME, KERNEL(KRNL386.EXE) /USER/GDI/... are a VxD-based implementation of the WIn32 API. Windows runs in the VM0, and the Win32 applications use this Win32 API. And from Windows95 on, they preemptively multitask with each other because VMM32 allows preemptive multithreading (each Win32 application is a thread on this VM 0). WIN.COM, or the DOS kernel of Win9X/ME (after processing CONFIG.SYS and running AUTOEXEC.BAT on COMMAND), basically prepare DOS to enter the protected mode, then load the VMM and the VxDs, and after that, once in protected mode with the VxDs loaded, they look for a file called "KRNL386.EXE" and run it. Here is where Windows really starts (and WIN.INI is it's configuration file, until the registry came). Whenever one of the running applications on one of the VM's (such as Microsoft Windows) produces a critical failure, then VMM32 will abort the application and show the Blue Screen of Death (BSOD). The funny thing about this is that (in my view), the BSODs are not Windows: it is DOS (the VMM) complaining that Windows had a bug and had to stop it. :) > > > at least in the beginning, there existed SCSI drives without Win95 > > > drivers where the DOS driver was loaded in CONFIG.SYS. Win95 tried to > > > detect these disks by bouncing protected mode INT13 to real mode > > > INT13. if this came back unchanged, the 32Bit code was used - as > > > intended in the first place. But still 16 Bit drivers had a chance. > > > > > Interesting, I didn't know this. Any other 16bit stuff that Windows was > > forced to use? > > I recall that you could load any DOS driver in CONFIG.SYS and it would > be used by Windows, but Device Manager would report it running in a > slow "compatibility mode" and would urge you to get native Windows > drivers instead. > This means that Windows has to switch to 16-bit to run this software, and you'd better get a 32-bit driver. > I think any DOS drivers would do this - e.g. input drivers, but I only > ever saw it myself with storage ones such as for ZIP drives. Usually > you wouldn't install these as Windows came with native drivers for most > hardware but if you used an old installer for Win3.1 it could > mistakenly install them. > The VxDs (or the native Windows drivers) would do this job on 32-bits, unless they need to control a "non-standard" hardware for which there's no Windows driver or VxD: then it would switch to 16-bit to run this legacy driver, but actually any call to DOS/BIOS (or hardware access) that this manufacturer's driver would do, will be handled by the appropriate VxD. I remember seeing it happen once when I installed a 3.2GB hard drive in > a machine where the BIOS didn't support drives that large. The > manufacturer's installer required me to put a drive overlay on it > (installed in the boot sector) in order to access the disk's full > capacity in DOS. Windows ran it in compatibility mode because of that > overlay and it wasn't until later I realised that as long as I > partitioned it the right way, I could boot off it without the overlay > and Windows would access the full capacity with its native IDE drivers. > Yeah, I have used such a driver from Seagate (IIRC) too :) > > Going back to the original point, I remember finding it interesting how > if you booted Win9x natively it pretty much took over the environment > and DOS all but disappeared, however if you booted into MS-DOS mode and > then ran "win", DOS was still there in the background (just not being > used if you had all native Windows drivers). In that case when you > chose the option to shut down Windows, instead of getting the "It's now > safe to turn off your computer" screen, it would return you back to the > DOS prompt, just the way Win3.1 used to work. > Well DOS never disappears completely. I seem to remember that the VM's timer interrupt will always be triggered from Windows (in case some 16-bit legacy software below would make use of it). If you consider (like me) that the VMM (aka DOS386.EXE) is DOS, then DOS continues to have control of the system and that Microsoft Windows GUI :) It's just that in the second case you mention, COMMAND runs WIndows but stays there, whereas in the "native mode", COMMAND is merely used to process AUTOEXEC, but then "WIN.COM" takes over. I suppose you could use that argument to say it was running on top of > DOS, even if it wasn't using any DOS services. > > By comparison there were DOS programs that would load Linux from a file > and boot it, and once you were in Linux it completely replaced DOS and > you couldn't exit back to it. I would argue that Linux in that case > was not running on top of DOS, even if it was launched from it. > Well, unlike VMM32, Linux and WindowsNT are 32-bit (and above) kernels that you cannot "unload" :) AFAIK they completely replace BIOS, they barely (if any) use it. And they come up with a completely different system API, above which you can write other APIs: - DOS API (NTVDM for WindowsNT or DOSEMU for Linux) - Win32 API (KERNEL32/USER32/GDI32 for WindowsNT or Wine for Linux) Aitor
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
