DOS ain't dead

Hello ecm,

> If this is so, does the extender swap around the PSP field around exec
> calls? If DOS is given a zero in the exec block for the environment source,
> it'll retrieve the environment from the current PSP. But DOS expects a
> segment in that field.

In the case of Devore's CauseWay DOS extender, the extender does not simply pass the parameter block (at es:[bx] or es:[ebx]) verbatim to real/V86 mode DOS.

Instead, it interprets the block as containing protected mode selectors, and rewrites it into a different parameter block suitable for real mode. So the DOS extender has a chance to specially handle a zero selector value.

In fact, CauseWay will actually allocate a conventional memory area for a new copy of the environment (!), and copy out the environment variables from protected mode memory to it.

Thank you!

---
https://codeberg.org/tkchia · https://disroot.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

Hello ecm,

Another interesting tidbit: if CauseWay is running in "DOS/4G" mode -- which happens if the client program does a DOS/4G installation check -- then the environment address field in the parameter block is actually a 48-bit selector:offset address, not just a selector value. Shenanigans.

Thank you!

---
https://codeberg.org/tkchia · https://disroot.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I've heard that for some DOS extenders, the word [PSP:2Ch] may
> be replaced by a selector that points to the environment, rather than a
> segment address.

It's not just what "some DOS extenders" do, but specified in DPMI: https://www.delorie.com/djgpp/doc/dpmi/ch4.1.html

> If this is so, does the extender swap around the PSP field around exec
> calls? If DOS is given a zero in the exec block for the environment source,
> it'll retrieve the environment from the current PSP.

HDPMI emulates int 21h, AX=4B00h and in this case expects a selector. But if a real-mode interrupt is simulated ( int 31h, ax=300h ), HDPMI does nothing.

---
MS-DOS forever!