> That doesn't make sense. A VM is a hardware emulator. It doesn't > get to choose to relocate the InDOS flag. DOSBox can do whatever > it wants when it is emulating DOS, but a hardware emulator doesn't > get to do those things. > > What VMs are you seeing this behavior in?
I was wondering if someone was going to ask that question. I use the term "Virtual Machine" to talk about five different kinds of DOS emulators. Some people will try and distinguish between them by saying something like, 'That's a Hypervisor and not a Virtual Machine". I call them all Virtual Machines since they provide a Virtual Environment in which DOS runs. The first type of VM is what MS did with DOS-based versions of Windows (like Windows 9x). You would boot to DOS and then start Windows (which you could usually do just by typing "WIN"). From Windows you could then start a DOS Window which gave you something like the DOS that was running before Windows started (but it wasn't exactly the same). You can actually have several of these DOS Windows running at the same time, and Microsoft called them Virtual Machines. You could make calls to Windows to tell you which VMID (Virtual Machine ID) you were in. E.g., with my SLOWDOWN program, if you installed SLOWDOWN before Windows started, you could use it to slow down Windows itself (which has VMID 0) which also affected all Windows-native applications. You could also slow down the different DOS VMIDs underneath Windows individually and each VMID could be slowed down to a different speed. SLOWDOWN would continually ask Windows which VMID was running so it knew the correct amount to slow things down. The next type of VM was what MS did with Windows NT, and MS called those NTVDM's (NT Virtual DOS Machines). Those were pretty poor imitations of DOS, but you could run some DOS applications there. The next three types of VM's are the "modern" Virtual Machines that people usually mean nowadays when they say "VM". The first type, which includes PCem and 86Box, simply provide a virtual hardware environment (usually a specific type of CPU, and they can even virtualize a 4.77 MHz 8088 CPU pretty accurately). For the BIOS, they use real ROM images from real computers that existed a long time ago. Though the BIOS is virtualized, it is a real BIOS that existed in a real computer at one time. You install a real version of DOS in these types of VM's -- they don't include a DOS. So if the DOS you install would have worked on the original hardware it has a _really_ good chance of working in this type of VM. The next type of VM is one that virtualizes both the hardware and the BIOS (a few of these are VMware, VirtualBox, QEMU, and Bochs). The BIOS is of the VMs own making and never existed in a real machine. Some of them are based on SeaBIOS, but every VM I've experimented with seems to have their own "tweaks" both to the virtualized hardware and the BIOS capabilities. Like the previous type of VM, you need to install your own version of DOS and they usually work pretty well. The last type of VM is one that virtualizes all three elements: hardware, BIOS, and DOS itself. The ones I've seen that do this are DOSBox and it's forks (which includes vDOS). The DOS provided by these VM's is designed to be "good enough" to run some (and even many) DOS applications, but really isn't a very good version of DOS. The "virtual DOS" that comes with DOSBox (and vDOS) does not have an InDOS flag or Critical Error flag and does not issue INT 28's (DOS Idle). As a result, TSR's can't tell when "DOS" is "busy" and consequently can't avoid potential reentracy issues when the TSR wants/needs to call DOS functions. Basically, DOSBox and its cohorts provide a "good enough DOS" to do some things but at least some TSR's will have problems. Those VM's also have other things that are "missing" that can cause compatibility problems in certain areas (especially with TSRs), but they do work pretty well for certain applications. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
