DGROUP

[[e-mail]]

I have been mulling over the possibility of a minimal
change to PDOS/386 to support 16-bit-only programs,
starting with command.exe.

The interrupt I am using to determine available memory
only allows me to get a total of 64 MB of memory, and
that is what real hardware I have used always returns.
(I am aware that older machines had some holes).

By using 16-bit segment shifts I can basically get a
flat address space, which will potentially simplify
things. Having nearly 1000 64k mallocs should be
sufficient for what I am doing, although it will play
havoc with any editor that allocates a line at a time.

However, I will have difficulty getting my memory
management routines to align on a 64k boundary.

I probably need to switch to huge-memory-model-only,
and use an extended DOS call that returns offset, not
just segment.

And then I realized I have another problem. I previously
thought that I just needed to ensure a single object file
didn't cross a 64k boundary, but now I realize that when
ds is loaded with DGROUP, that DGROUP variable is not
known to the executable (and thus OS), and that needs
to be aligned on a separate 64k boundary.

So I would need to either pad the executable to a 64k
boundary or mark up the executable to the location
of DGROUP.

Actually, I don't suppose DGROUP can be identified by
some other mechanism, since it will be located sort of
last.

There may be a general problem that I need to identify
places that need to reside on a segment boundary.
So if I had a 640k executable I could potentially have
10 places marked as segment-aligned, and not need to
pad the executable with NULs to align them.

BFN. Paul.

[[e-mail]]

There are 28 reserved bytes in the MZ header if I want
to extend the format.

Any suggestions (for what I want to do)?

Thanks. Paul.

[[e-mail]]

Post by ***@gmail.com
Actually, I don't suppose DGROUP can be identified by
some other mechanism, since it will be located sort of
last.

Actually, maybe it can be identified by the FIRST relocation
done at the entry point address, and I just make a rule that
DGROUP needs to be loaded before any other external
reference, and only once.

That way I can continue to use Watcom as my linker, and
only need a special linker if I have an executable that is
bigger than 64k, so code alignment becomes a factor.

I do have executables with more than 64k of code though,
so I'll have to use a special linker regardless. But padding
to a 64k boundary in code is a lot different to padding to
the DGROUP.

BFN. Paul.