DOS ain't dead

I would like my MSDOS executables to be able to accept an
override of callback functions to use instead of executing
an INT 21H.

So I need a way of detecting that I am in a non-MSDOS
environment that provides a callback facility on the stack
(or possibly in a pair of registers - I'm open to opinions).

One way I could do that is by making ES different from DS,
instead of having both of them pointing to the PSP.

I could make ES equal to FFFF, which is an indicator that
this is a PDOS-generic environment, so look on the stack etc.

I believe MSDOS 4 multitasking already changes either DS
or ES or both on entry, perhaps to support DLLs or something.
So that's why I would have the further ES setting, to distinguish
from that.

Since we have the normal non-MT source code, I was just
wondering how definite it is that DS and ES match. ie will
they always be set the same, or are there some special
conditions? Is there a deliberate attempt to make them
the same (seems a bit odd actually, but that's ok).

Thanks. Paul.

> Since we have the normal non-MT source code, I was just
> wondering how definite it is that DS and ES match. ie will
> they always be set the same, or are there some special
> conditions? Is there a deliberate attempt to make them
> the same (seems a bit odd actually, but that's ok).

https://hg.pushbx.org/ecm/msdos4/file/51ad27d225a8/src/DOS/EXEC.ASM#l796

They're always pointing to the PSP upon application entry. I believe this is documented, as well.

However, for an extension I would suggest adding a new entrypoint at an offset within the executable's image, perhaps with a new signature. This would allow to load old executables in a compatible way with ds = es => PSP and new executables with the new entrypoint.

---
l

> > Since we have the normal non-MT source code, I was just
> > wondering how definite it is that DS and ES match. ie will
> > they always be set the same, or are there some special
> > conditions? Is there a deliberate attempt to make them
> > the same (seems a bit odd actually, but that's ok).
>
> https://hg.pushbx.org/ecm/msdos4/file/51ad27d225a8/src/DOS/EXEC.ASM#l796

Thanks for the reference!

This comment threw me for a moment:

; DX has PDB pointer

Not sure what that is, but I know it as PSP.

> They're always pointing to the PSP upon application entry. I believe this
> is documented, as well.

What is the official Microsoft documentation for this stuff?
I have read books and read RBIL. I've never referred to
something from Microsoft themselves. But I did buy some
old software - masm 6.0, microsoft c 6.0, and there are
manuals with some of the stuff, and some softcopy help
as well, so I can probably look up things now.

> However, for an extension I would suggest adding a new entrypoint at an
> offset within the executable's image, perhaps with a new signature. This
> would allow to load old executables in a compatible way with ds = es => PSP
> and new executables with the new entrypoint.

I don't have this problem - old executables aren't expected to run
under PDOS-generic, as they will do a non-existent INT 21H.

It's true I could change that one day, and at that point I could have
a more complicated signature etc.

But my goal is to write RM16 programs "properly" (TM).

And then run them in both RM16 and PM16 - completely unchanged,
and when running in PM16, there won't even be an INT 21H available.

In fact, I just realized that I can run under PDOS/386 this way.

I switch in PM16 page tables, switch to PM16, run my "properly
written (TM)" MSDOS program, it does a callback (not much
different from doing an OS/2 1.0 DLL call), and I switch back
to PM32 and service the DLL-like callback.

Currently PDOS/386 doesn't support running 16-bit programs
at all. I'm not happy to create a V8086, but I am happy to
switch to PM16.

And my Properly Written (TM) MSDOS program, that obeys all
of Intel's rules:

https://en.wikipedia.org/wiki/Protected_mode#Real_mode_application_compatibility

Segment arithmetic
Privileged instructions
Direct hardware access
Writing to a code segment
Executing data
Overlapping segments
Use of BIOS functions, due to the BIOS interrupts being reserved by Intel[

And I don't want to do this:

the 80286 remains upwardly compatible with most 8086 and 80186 application programs. Most 8086 application programs can be re-compiled or re-assembled and executed on the 80286 in Protected Mode.

ie I don't want to recompile/reassemble. I want my binary to work
in PM16 because I followed all the rules.

You can consider that I am just starting RM16 programming now.
I still haven't finished writing dosstart.asm. After more than 30
years I'm still trying to figure out what to do. I made more
changes today. I'm thinking I can have more than 64k BSS if I
write my code Properly (TM). pdld (the source code in sourceforge -
I haven't published a new executable yet) is able to produce an a.out
executable produced from Watcom OMF16 object code.

It (a.out) is all flat.

But using the a.out executable, plus the map, I believe I can convert
the result into a valid MSDOS executable that also works in PM16.

This will be a Watcom-produced executable though - no AHINCR,
AHSHIFT, as that would require extensions to the MZ format, which
I want to avoid at the moment.

I want to start by just guessing that the executable was Properly
Produced (TM), which means that individual object code - both
code and data - do not cross a 64k boundary, and there is NUL
padding to make that happen. And also the first relocation in
the text is to the DGROUP, so the PM16 loader can guess where
the data is (an alternative would be to pad even the last text
block to 64k, but I want to avoid that) (and another alternative
would be to see what the highest relocation is in terms of
fixup value, rather than location of the fixup, but that won't
allow me to expand the data to more than 64k).

Basically the idea is to have no overt extensions to the standard
MZ format, and just write code in a manner that a loader could
detect it one day in the future. And "the future" happens soon
after I've written my first Properly Written (TM) MSDOS program.
That obeys Intel's rules, even though Microsoft didn't explain
how to obey those rules within the framework of the MZ
executable - including huge memory model.

I hope that makes sense. The explanation is convoluted because
the subject matter is convoluted - segmented memory.

BFN. Paul.

> > > Since we have the normal non-MT source code, I was just
> > > wondering how definite it is that DS and ES match. ie will
> > > they always be set the same, or are there some special
> > > conditions? Is there a deliberate attempt to make them
> > > the same (seems a bit odd actually, but that's ok).
> >
> > https://hg.pushbx.org/ecm/msdos4/file/51ad27d225a8/src/DOS/EXEC.ASM#l796
>
> Thanks for the reference!
>
> This comment threw me for a moment:
>
> ; DX has PDB pointer
>
> Not sure what that is, but I know it as PSP.

https://hg.pushbx.org/ecm/msdos4/file/51ad27d225a8/src/DOS/MISC.ASM#l357

Process Data Block. It means the same as the Process Segment Prefix, yes.

---
l

> https://hg.pushbx.org/ecm/msdos4/file/51ad27d225a8/src/DOS/MISC.ASM#l357
>
> Process Data Block. It means the same as the Process Segment Prefix, yes.

Thanks. I didn't check what "hell" is, in Microsoft's professional opinion.

invoke DOSINIT ; go to hell


BTW, I think the DOS 4 MT we have is quite old. I went through the documentation,
and so far I haven't seen a reference to what the segment registers are on entry.

Thinking back, it was someone else's analysis online, about a more modern
multitasking version, that mentioned what system call you need to invoke
to retrieve the PSP.

But I haven't been able to find that so far. I tried the links at Wikipedia,
and some weren't working for me. Still looking.

> > https://hg.pushbx.org/ecm/msdos4/file/51ad27d225a8/src/DOS/MISC.ASM#l357
> >
> > Process Data Block. It means the same as the Process Segment Prefix,
> yes.
>
> Thanks. I didn't check what "hell" is, in Microsoft's professional opinion.
>
>
> invoke DOSINIT ; go to hell

It's a branch that's intended to crash. It used to do this by running the DOSINIT code, which is code that is no longer resident at this point: https://hg.pushbx.org/ecm/msdos4/file/51ad27d225a8/src/DOS/MSINIT.ASM#l180 IIRC it's overwritten by parts of the SDA later.

I changed it so it branches to a dedicated function: https://hg.pushbx.org/ecm/msdos4/file/28de3823a0fd/src/DOS/misc.nas#l552

This function is defined here (technically in the "msbio" part but both "msdos" and "msbio" are linked to one binary now): https://hg.pushbx.org/ecm/msdos4/file/28de3823a0fd/src/BIOS/code.asm#l333

The old DOSINIT is now called NEARDOSINIT and lives in the SYSINIT segment (hence it is called "near") rather than in the (what used to be) combined DOSDATA + DOSCODE: https://hg.pushbx.org/ecm/msdos4/file/28de3823a0fd/src/DOS/dosinit.nas#l570

---
l

> BTW, I think the DOS 4 MT we have is quite old. I went through the
> documentation,
> and so far I haven't seen a reference to what the segment registers are on
> entry.

This looks like what I remembered:

https://pcdosretro.gitlab.io/multitaskingmsdos4.htm

and the lack of PSP is just for NE executables.

Still - that is of interest too.

Assuming NE executables could do INT 21H - which I believe they
can, then I expect my MSDOS code to work after being processed
through a "reformat" tool to convert from MSDOS format to NE
format, and I expect it to continue working on MSDOS 4 MT.

In fact, I can even allow for the AHINCR and AHSHIFT to be accepted
and used for the huge algorithm in that situation, by placing them in
a known spot, like after the first relocation, which is a DGROUP
reference.

So some sort of informal/hidden markup.

So that no-one can say it is a non-standard MSDOS executable.
Because it totally is.

> Assuming NE executables could do INT 21H - which I believe they
> can, then I expect my MSDOS code to work after being processed
> through a "reformat" tool to convert from MSDOS format to NE
> format, and I expect it to continue working on MSDOS 4 MT.

Including a future MSDOS 4 MT, that actually has the AHINCR
and AHSHIFT support, and is running in PM16.

> I could make ES equal to FFFF, which is an indicator that
> this is a PDOS-generic environment, so look on the stack etc.

Probably ES=1 would be better. As a segment, it would trash
the interrupt vectors. And it's not a valid selector either. So
it will hopefully be distinct from DOS 4 MT NE running in
either RM16 or PM16 - present or theoretical future.

This is all based around INT 21H calls though. I'm not really
expecting to dynamically detect that I'm in an OS/2 1.0
DLL environment and I should be calling DOSCALLS routines
instead. But I guess that would be a technical possibility.

But regardless - just like binutils has an "objcopy" utility, I'm
basically expecting to have a "execopy" facility that copies
my a.out 8086 code (plus the map file from the linker so that
I know where the individual object modules start and end),
and convert it into MSDOS MZ or MSDOS NE and in both
cases it works in both RM16 and PM16 given a suitable OS
that can load MZ into PM16 and either cope with or request
override (to int21() callback function) of INT 21H calls.

BFN. Paul.