DOS ain't dead

Since that thread has grown too large and this is certainly off-topic anyhow, I'll reply in this new thread to what Rugxulo said here in the KBFR thread:
> Just for the record (though it doesn't majorly matter), to change the
> currently selected "display" codepage:
>
> MS-DOS, DR-DOS: int 21h 440Ch 6Ah
> MS-DOS, FreeDOS: int 2Fh, 0AD02h
>
> Yes, int 2Fh 0AD02h is "documented" in RBIL, but it's the low-level
> (hidden) interface, I think. FreeDOS doesn't support the other way because
> that's IOCTL and their DISPLAY is an .EXE, not a TSR (and Aitor is strict
> about that separation).

"An .EXE, not a TSR"? What kind of distinction is this? Do you mean it's a command-line executable that doesn't leave anything resident? (How does it support 2F.AD02 then?)

If you meant "a TSR, not a device driver" then I would understand what you mean here, given that the IOCtl interface uses character devices. However, TSRs can create (and remove) device driver headers on sufficiently compatible DOSes. All necessary handling for that is of course implemented in DEVLOAD, but only (un)installing a character device driver header on your own is much simpler than what DEVLOAD does.

---
l

> If you meant "a TSR, not a device driver" then I would understand what you
> mean here, given that the IOCtl interface uses character devices.

Yes, sorry, temporary brain melt. I meant it's not DISPLAY.SYS (like in other DOSes) but instead an incomplete TSR / .EXE combo. Hence Aitor doesn't even pretend to support IOCTL calls via int 21h 440Ch and only instead relies upon "standard" (undocumented) int 2Fh AD02h from MS-DOS until (if?) he finishes it.

EDIT: Oops, almost made another mistake, heh.