[maybewhenthesun]

Amen to that!

I think I remember there was some communication between ID and Charles Sandmann about CWSDPMI, so even though it's worded a bit strange for an open source project there's probably some thruth in it?

Also a bit strange how the author is surprised about Quake running in a 'VM', apparently they don't really know about VM86 mode in x86 processors...

[db48x]

Is the author surprised by that, or did you just misread it? The only relevant quote on that page that I see is “It is impressive to see Quake run at full speed knowing that Windows 95 runs DOS executable in a virtual machine.”

He is perhaps surprised that it runs _at speed_ in the VM, not that it runs in the VM which he already knows about.

[maybewhenthesun]

I mean VM86 is not really a VM in the modern sense of the word. And the author doesn't seem to know.

[rasz]

That and the fact Quake doesnt run in VM85 mode, it explicitly runs in _protected_.

[maybewhenthesun]

That as well, yes.

[zoeysmithe]

I think if you're relatively young is hard to know computing history. Its oddly older than one thinks, even concepts that are seen as new. Its sometimes interesting to see people learn about BBS's which flourished 40 years ago.

[bombcar]

It's a bit surprising because this is the author of the DooM Black Book and they know the underpinnings pretty well.

However, the difference between a DOS VM under Windows 9x and a Windows command prompt and a w32 program started from DOS is all very esoteric and complicated (even Raymond Chen has been confused about implementation details at times).

[trollbridge]

DPMI clients don’t run in a VM, though. They’re just a normal task like any other task / process in Windows.

[toast0]

So... Win32 runs in virtual mode. In 2025, we don't think of that as a Virtual Machine, but it totally is. Hardware access is trapped by the CPU and processed by the OS/DPMI server.

[trollbridge]

It's not a virtual machine. There is no hardware machine that presents itself to function like a protected-mode ring 3 task on an 80286 or an 80386 functions. And the 286 and 386 both lacked a "virtual 286" and "virtual 386" mode (although it would have been almost-trivial for them to support it; Intel just decided not to, probably figuring it wasn't important).

Virtual 8086 mode, on the other hand, does behave exactly like a real 8086, which otherwise would have been very slow to implement on a real 386, and was either very slow on a 286 or impossible due to the 286 having some errata that prevented normal virtualisation techniques (the 286 had some non-restartable exceptions).

[fredoralive]

No, in 386 mode 3.x and 9x the System VM and other DPMI clients runs in protected mode.

Virtual 8086 mode, as its name somewhat suggests, only runs real mode code.

[oso2k]

Only if they never call DOS or the BIOS or execute a Real Mode Software Interrupt. When they do, they ask the DPMI server (which could be an OS like Windows 9x or CWSDPIM) to make the call on their behalf. In doing so, the DPMI server will temporarily enter into a VM86 Virtual Machine to do execute the Real Mode code being requested.

http://www.delorie.com/djgpp//doc/libc-2.02/libc_220.html

[trollbridge]

But that's not the DPMI client running in a VM. That's the host ending up running in a VM.

Note that in a machine with EMM386, the machine is normally running DOS inside an 8086 VM... and the only reason it would switch out of that VM is when you fire up a DPMI client.

[VogonPoetry]

VM in this usage means Virtual Memory - i.e. with page tables enabled. Two "processes" can use the same memory addresses and they will point to different physical memory. In Real Address mode every program has to use different memory addresses. The VM86 mode lets you to have several Real Mode programs running, but using Virtual Memory.

[oso2k]

VM does not mean Virtual Memory in this context. VM does mean Virtual Machine. When an OS/DPMI Server/Supervisor/Monitor provides an OS or program a virtual interface to HW interrupts, IO ports, SW interrupts, we say that OS or program is being executed in a Virtual Machine.

For things like Windows 3.x, 9x, OS/2, CWSDPMI, DOS/4G (DPMI & VCPI), Paging & Virtual Memory was an optional feature. In fact, CWSDPMI/djgpp programs had flags (using `CWSDPR0` or `CWSDPMI -s-` or programmatic calls) to disable Paging & Virtual Memory. Also, djgpp’s first DPMI server (a DOS extender called `go32`) didn’t support Virtual Memory either but could sub-execute Real Mode DOS programs in VM86 mode.

http://www.delorie.com/djgpp/v2faq/faq15_2.html

[VogonPoetry]

I agree that my comment about VM was imprecise and inaccurate.

I do dispute your assertion that virtual memory was "disabled". It isn't possible to use V86 mode (what the Intel Docs called it) without having a TSS, GDT, LDT and IDT set up. Being in protected mode is required. Mappings of virtual to real memory have to be present. Switching in and out of V86 mode happens from protected mode. Something has to manage the mappings or have set it up.

Intel's use of "virtual" for V86 mode was cursory - it could fail to work for actual 8086 code. This impacted Digital Research. And I admit my experiences are mostly from that side of the OS isle.

I did go back and re-read some of [0] to refresh some of my memory bitrot.

[0] https://www.ardent-tool.com/CPU/docs/Intel/386/manuals/23098...

[trollbridge]

Slight nitpick: you could run fire up V86 mode without any LDT entries.

It's also possible to run Virtual 8086 mode without paging enabled, and when in Virtual 8086 mode, the 386 doesn't care about what's in the LDT/GDT (unless an interrupt happens). In practice this is never done because the Virtual 8086 task would only be able to use the bottom 1MB of physical memory.

[trollbridge]

Slight nitpick: OS/2 2.x+ did not have a way to disable paging, although you could disable virtual memory in any version of OS/2 by simply setting MEMMAN=NOSWAP.

On Windows 3.x, paging and swapping was optional - if you started it in 286 ("standard") mode. On Windows 95, paging is not optional, and it's not optional in Windows 3.11 for Workgroups either.