DOS ain't dead - DS and ES matching

DS and ES matching (Developers)

posted by kerravon , Ligao, Free World North, 18.10.2025, 14:43

> > 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.

Post reply

Complete thread:

DS and ES matching - kerravon, 18.10.2025, 11:29 (Developers)
- DS and ES matching - ecm, 18.10.2025, 12:48
  - DS and ES matching - kerravon, 18.10.2025, 14:43
    - DS and ES matching - PDB meaning - ecm, 18.10.2025, 18:32
      - DS and ES matching - PDB meaning - kerravon, 18.10.2025, 19:04
        DS and ES matching - PDB meaning - ecm, 18.10.2025, 19:41
        DS and ES matching - PDB meaning - kerravon, 18.10.2025, 19:59
        DS and ES matching - PDB meaning - kerravon, 18.10.2025, 20:01
- DS and ES matching - kerravon, 19.10.2025, 10:32