3 ms·
It's a miracle emm386 managed to squeeze out more memory as UMBs than it needed to do its job. Consider: It scans for holes in the memory map. It switches to
by hyperman1 3y ago
It's a miracle emm386 managed to squeeze out more memory as UMBs than it needed to do its job.
Consider: It scans for holes in the memory map. It switches to protected mode, then v86 mode, sets up page tables, and is basically more of an OS than DOS, if you look at the CPU. It monitors IO ports and rewrites DMA access from random programs to translate the UMBs to their physical addresses. It implements VCPI to cooperate with e.g. windows and dos4gw. It switches A20 on and off when translation needs to happen.
And all that to gain memory from segments C000,D000,E000, if nothing else sits there. So 192K max.
Looking back, it's insane what contortions we went to, just to keep dos alive.
- userbinator 3y agoIt's more like a hypervisor than a true OS, and VM86 mode was the first hardware virtualisation feature of the x86 line. Windows/386 and the DOS-based Windows up to Me were similarly hypervisors for DOS.
- EvanAnderson 3y agoIt's a shame that VM86 mode wasn't able to be nested. I don't remember the specifics, but as I recall there are instructions that don't trap and prevent nesting VM86 within itself. I know Intel rectified this in later CPUs-- I believe that's the VT extensions.
- userbinator 3y agoThe VT extensions also unfortunately didn't "fit in" with the VM86 model either, needing their own special instructions and data structures (and AMD and Intel also did slightly different things, further complicating the situation.)
- hyperman1 3y agosgdt/sidt/sldt are some of these instructions. Don't know if there are others. They give linear adresses of the processor's descriptor tables. Code running with paging enabled can't even read these locations, so they are pretty useless for user mode. But they allow user mode to get forbidden info from the kernel, and virtualizing lgdt/lidt/lldt becomes impossible because non-privileged code can see the values given to the cpu changed, and a save state/restore state is impossible under virtualization. Under newer processors, flag CR4.umip makes them trap, so virtualization becomes possible.
- lproven 3y ago> It's more like a hypervisor than a true OS True. This is why I've suggested an inverse EMM386 to the FreeDOS team: a 32-bit app that has a single purpose -- start 1 DOS VM. That is the only way I can imagine to create a form of DOS that could be booted on UEFI computers, and without that, soon FreeDOS will be confined to VMs and old kit. The idea is, start a very very simple 32-bit binary that creates 1 V86-mode VM, maps some DOS resources into it (disk, screen, keyboard, mouse, etc.), then loads the DOS kernel into it. In DOS a stub EMM386.EXE could create some UMBs and LIM EMS if you want it. I doubt it will ever be possible to support sound cards, network cards, etc. this way but most modern ones don't work on DOS anyway so nothing of importance is lost.
- mycall 3y agoDoubleDOS [0] did this before VM86 mode was a thing and worked on 8086 CPUs. [0] https://en.wikipedia.org/wiki/DoubleDOS https://en.wikipedia.org/wiki/DoubleDOS
- lproven 3y agoYou know that there were loads of such things, right? DESQview, IBM TopView which inspired it, Windows 2 itself, Windows 3 in real mode, DR Concurrent DOS and CDOS 286...