HUGE!!!

[muta...@gmail.com]

I have finally proven the technology.

Watcom huge memory model produces code that
allows me to write an 8086 OS cleanly.

There are 4 major things that even a basic OS needs
to be able to do:

1. Manage a file system.

2. Manage memory.

3. Load executables.

4. Accept API requests.

I was able to do number 1 above in C90 code, so it
works fine, unkludged, on both 8086 and 80386.

Number 3 I expect to be different between 8086 and
80386, so since it needs to be written anyway, there's
no particular need for portability.

Number 4 I have a common API already, although
interestingly I was forced to change PosWriteFile
and read to use unsigned int instead of size_t about
1 day ago.

But number 2, the jury has been out for quite a long time.

I already wrote memory management routines (for the
MVS C library - no longer used on MVS, but still used
on CMS and VSE), and I wrote them in what I thought
was portable C90.

But when I tried to use them on the 8086 they only let
me access 64k. Rather than kludge up my pristine C90
code, I instead kludged up PDOS/86.

I never actually knew what "huge" was until a few years
ago. And then there was further confusion about whether
any C compiler actually supported it. For a time I was
under the impression that only Smaller C supported it,
but then I was forced to use an 80386 instead of an
8086.

As of a few minutes ago I have released a new version
of PDOS/86 at http://pdos.org where I have switched
to using the huge memory model with Watcom C, and
with pure 8086 code, my memory management
routines work, completely unchanged.

I'm running under Bochs, and even though that is
emulated, I didn't notice any particular difference in
speed.

And given that the computer should be focused on
running application code, not OS code, I don't
particularly care if it is a bit slower, even if I could
detect that, which I can't.

Next challenge is to get SubC to do the same.

Oh, size_t is 32 bits in my 8086 C library used for
PDOS/86, even though Watcom only seem to use
16 bits in their library.

Note that applications can be any memory model
and still work fine on PDOS/86. com files work too.

PDPCLIB doesn't support malloc for the tiny/small/medium
memory models, or parameters, so you can't use
PDPCLIB, you'll have to use some other C compiler/library
if you need those memory models for some reason.

Also if you need all the DOS-specific stuff. I only support
C90 in PDPCLIB.

Although you can link against the Pos* interface for
DOS-specific stuff if you want, but that's basically
shipped with the OS (ie "src") not the C library
(ie "pdpclib"). I think OS/2 was the same, providing
a library with the OS, not only the C compiler.

BFN. Paul.

[muta...@gmail.com]

I have now made my bootloader huge memory model too.

Both for loading PDOS/86 and loading PDOS/386.

And I am no longer constrained to 58 sectors by the
7C00h location of the BPB. The bootloader relocates
that in the startup code.

Which is just as well, because switching to huge memory
model made my executable (actually, binary image),
about 32k in size.

I'm currently trying to get pdos.sys to be a flat binary so
that the bootloader doesn't need to have the logic in it
to interpret and relocate an executable.

BFN. Paul.