Paul Edwards
2023-11-20 13:29:07 UTC
(possible double-or-more-post - google groups
stopped working and I have switched to using
eternal september using pdpnntp under PDOS/386)
I think we previously touched on NE executables,
but it wasn't a priority for me to continue at the time.
I also previously discussed limitations I saw on MZ
that would prevent my 16-bit executables suddenly
getting access to 16 MiB (80286) or even 256 MiB
(PM16 on 80386) or 512 MiB (PM32 with D-bit) or
4 GiB (theoretical maximum).
The solution appears to be to use the NE format.
So probably when PDOS/286 exists one day, I will
probably create a flavor of PDOS/86 that uses the
exact same NE executables.
And maybe I will distribute PDOS with 16-bit, 32-bit
and 64-bit versions of all executables, and the loader
detects which system it is on and loads either PDOS/86,
PDOS/286, PDOS/386 or PDOS/x64.
I have committed changes to PDOS to demonstrate a
simple NE executable working. It's crude and only for
demo purposes.
The executable I tested does a printf and then opens a
file and writes to it. When run on Windows 2000 the
executable is treated as a Win16 and the printf goes
nowhere but the file open happens successfully.
On PDOS/86 you get the printf too.
When the program terminates, PDOS/86 freezes
because of current limitations.
Only the NE format was changed - it's still unchanged
8086 code. Doing INT 21H etc. ie this is a DOS program.
So 16-bit DOS programs more-or-less already have access
to more than 640k/1MB.
But the writes to stdout are lost instead of appearing on the
console that launched the application. For no reason I can
see. So an intercept for INT 21H would need to be put in place
to get those writes sent to the console (if you want to use
32-bit Windows instead of 16-bit PDOS/x86).
Not sure what the requirements of the intercept would be,
and whether an existing TSR like ANSIPLUS might do the
trick, and solve the problem of ANSI output at the same time.
I have committed code changes to PDOS, but they aren't
active by default.
BFN. Paul.
P.S. I have since also got support for __AHINCR
(the non-existent kernel.dll will get a 0x1000
offset as required for RM16).
stopped working and I have switched to using
eternal september using pdpnntp under PDOS/386)
I think we previously touched on NE executables,
but it wasn't a priority for me to continue at the time.
I also previously discussed limitations I saw on MZ
that would prevent my 16-bit executables suddenly
getting access to 16 MiB (80286) or even 256 MiB
(PM16 on 80386) or 512 MiB (PM32 with D-bit) or
4 GiB (theoretical maximum).
The solution appears to be to use the NE format.
So probably when PDOS/286 exists one day, I will
probably create a flavor of PDOS/86 that uses the
exact same NE executables.
And maybe I will distribute PDOS with 16-bit, 32-bit
and 64-bit versions of all executables, and the loader
detects which system it is on and loads either PDOS/86,
PDOS/286, PDOS/386 or PDOS/x64.
I have committed changes to PDOS to demonstrate a
simple NE executable working. It's crude and only for
demo purposes.
The executable I tested does a printf and then opens a
file and writes to it. When run on Windows 2000 the
executable is treated as a Win16 and the printf goes
nowhere but the file open happens successfully.
On PDOS/86 you get the printf too.
When the program terminates, PDOS/86 freezes
because of current limitations.
Only the NE format was changed - it's still unchanged
8086 code. Doing INT 21H etc. ie this is a DOS program.
So 16-bit DOS programs more-or-less already have access
to more than 640k/1MB.
But the writes to stdout are lost instead of appearing on the
console that launched the application. For no reason I can
see. So an intercept for INT 21H would need to be put in place
to get those writes sent to the console (if you want to use
32-bit Windows instead of 16-bit PDOS/x86).
Not sure what the requirements of the intercept would be,
and whether an existing TSR like ANSIPLUS might do the
trick, and solve the problem of ANSI output at the same time.
I have committed code changes to PDOS, but they aren't
active by default.
BFN. Paul.
P.S. I have since also got support for __AHINCR
(the non-existent kernel.dll will get a 0x1000
offset as required for RM16).