DOS ain't dead

I previously proposed an extension to the MZ format for eventual use in PM16:

https://forum.osdev.org/viewtopic.php?t=57259

I'm getting closer to having CM16 working (it is currently working with kludges and limits as POC).

And I was rethinking this.

If an MSDOS program was to use compact or large (to get large data), and linked with a linker that creates nice segments, then the code relocations should be very obvious - ie multiples of 4000.

If I get a linker (ld86/slink) to pad the code segments other than the last out to 64k with NULs, I will have the segment boundaries. And the DGROUP relocation will be obvious because it is the highest value.

Microsoft C 6.0A has an "Aw" option - SS != DS and DS is not reloaded. (Au would reload DS).

So if I accept the stack that MSDOS gives me, and set DS once (or indeed, I probably don't even need that restriction), then the program will work under MSDOS, and also be something that I can run in CM16.

And don't attempt to resize the executable either - instead rely on maxalloc being set sensibly in the EXE header. Although even that request is something that could be simply ignored by the PM16/CM16 OS.

I'm not trying to get things to work in EVERY case - I'm trying to get them to work in ANY case AT ALL - or rather, a class.

Basically I need to know how - in hindsight - to properly write MSDOS programs, to future-proof them.

Huge memory model would still require some sort of change to the executable format though - and NE would be good enough for that, and try to work within the limits of Euro MSDOS 4.

Note that in my original timeline I never used huge. I was using Borland C anyway, where huge wasn't useful for my (current) purposes anyway. So getting compact and large working would be cool, now that I can see a purpose for splitting DS and SS.

Actually, it occurs to me that I don't even need 64k padding.

I can just have an array of 16 segments, and the OS can scan all the references and sort them to know where the boundaries are.

Actually, I should be able to do huge too, by using
Watcom instead of Microsoft C, and using an extended
API to get the required AHINCR equivalent, and if that
extended API doesn't exist, then assume 8086 values.

Another case of not being able to see the forest for
the trees.

BFN. Paul.

> Microsoft C 6.0A has an "Aw" option - SS != DS and DS is not reloaded. (Au
> would reload DS).

Watcom appears to have that same functionality split as:

-zu SS != DGROUP
-zd{f,p} DS floats vs DS pegged to DGROUP


And regarding huge - I believe Intel created some rules saying that you shouldn't second-guess anything about segments. So adjusting ss to equal ds and allowing near data is basically a violation of the rules. So C-generated tiny/small/medium is basically all incorrect. And Microsoft's use of AHINCR/AHSHIFT is another violation, so that basically shouldn't have been used either.

BFN. Paul.