Paul Edwards
2023-11-22 11:33:47 UTC
Hi rugxulo
It will be interesting to see what happens with
this reply. I still use google groups to read,
and I don't seem to be able to get the headers
like I used to, which means I can't attempt to
put in a proper reply thing. Also I am using
X-Comment-To in order to eventually support the
Fidonet software that comes with PDOS/386.
All Win 3.1 programs do, as far as I know.
memory in an appropriate environment, sort of
maybe. E.g. if it was tiny memory model and did
a malloc of 3.9 GB and the OS being used returned
a far pointer, and then the executable used the
segment registers to read/write that data, then
that should work.
The big problem is resolving relocation information,
but that's not a problem with tiny memory model.
Another problem is finding a processor with
enough selectors to get to 4 GiB. That's why I
mentioned 512 MiB.
The relocation information in the NE is more
sensible, instead of having an implied 4-bit
segment shift.
There is no reason why MSDOS 2.0 couldn't have
used that NE format right from the start though,
and in that theoretical situation, you break
the 8086 limitation and move on the 80286,
then 80386 (still PM16) with no change to your
executable.
Are you talking about .res files? I'm not interested
in that. Just C90 console mode applications.
Try using OpenWatcom to build one.
OS/2 1.x uses a new API. I was talking about
getting INT 21H to work.
But yes, that's basically what I'm talking
about beyond that - putting (cut down) OS/2 1.x
or similar onto an 8086. As well as on the
original 80286.
The 1996 DOS + OS/2 build of mawk is one example.
Yes, but I'm not aware of what they did.
Did it require an 80286 processor, even though
it ran under MSDOS?
Or did they keep it in RM16 and get a stub to
get the DLL references resolved? I'm planning
on just getting rid of that stub and moving it
to the 8086 OS. The 8086 OS would then recognize
the pure NE OS/2 1.x.
had 2 MB of real EMS (not emulated).
I looked up those terms. EMS involves paging,
which is not what I want to do. I just want
simple 8086 code to work. Also, my goal is not
to get more than 640k on an 8088 at all.
XMS is also obtaining memory above 1 MiB - not
my goal for an 8086.
although HXDEV16 would also be fine if it stayed
in RM16 and used only 8086 instructions. Do you
know if it can run on an 8088?
That would then be conceptually the same as what
I want, and the only change is that I don't like
DLLs and intend to provide a new API (PDOS-generic).
BFN. Paul.
It will be interesting to see what happens with
this reply. I still use google groups to read,
and I don't seem to be able to get the headers
like I used to, which means I can't attempt to
put in a proper reply thing. Also I am using
X-Comment-To in order to eventually support the
Fidonet software that comes with PDOS/386.
Hi, glad to hear from you again.
Thanks.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).
Didn't the 16-bit pmode stuff from Borland Pascal use NE?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).
Anyways, EMX (a.out) and DJGPP (COFF) have
no problems with 100+ MB of RAM.
That's using PM32, not PM16.no problems with 100+ MB of RAM.
Or did you mean a pure 16-bit MZ .EXE
was limited by default?
(In other words, MZ by itself doesn't stop
anyone, but I guess we're splitting hairs.)
Certain unchanged MZ could indeed access 4 GiB ofwas limited by default?
(In other words, MZ by itself doesn't stop
anyone, but I guess we're splitting hairs.)
memory in an appropriate environment, sort of
maybe. E.g. if it was tiny memory model and did
a malloc of 3.9 GB and the OS being used returned
a far pointer, and then the executable used the
segment registers to read/write that data, then
that should work.
The big problem is resolving relocation information,
but that's not a problem with tiny memory model.
Another problem is finding a processor with
enough selectors to get to 4 GiB. That's why I
mentioned 512 MiB.
The relocation information in the NE is more
sensible, instead of having an implied 4-bit
segment shift.
There is no reason why MSDOS 2.0 couldn't have
used that NE format right from the start though,
and in that theoretical situation, you break
the 8086 limitation and move on the 80286,
then 80386 (still PM16) with no change to your
executable.
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.
I hear it's a complicated format (e.g. resources).So probably when PDOS/286 exists one day, I will
probably create a flavor of PDOS/86 that uses the
exact same NE executables.
in that. Just C90 console mode applications.
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.
Wasn't Win2k the last to support OS/2 1.x textmode apps?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.
Try using OpenWatcom to build one.
getting INT 21H to work.
But yes, that's basically what I'm talking
about beyond that - putting (cut down) OS/2 1.x
or similar onto an 8086. As well as on the
original 80286.
On PDOS/86 you get the printf too.
Surely you're aware of OS/2 family/bound apps too, right?The 1996 DOS + OS/2 build of mawk is one example.
Did it require an 80286 processor, even though
it ran under MSDOS?
Or did they keep it in RM16 and get a stub to
get the DLL references resolved? I'm planning
on just getting rid of that stub and moving it
to the 8086 OS. The 8086 OS would then recognize
the pure NE OS/2 1.x.
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.
They already could with EMS or XMS. Jim Leonard (Trixter)'s 80888086 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.
had 2 MB of real EMS (not emulated).
which is not what I want to do. I just want
simple 8086 code to work. Also, my goal is not
to get more than 640k on an 8088 at all.
XMS is also obtaining memory above 1 MiB - not
my goal for an 8086.
The HX extender's HXDEV16 should have some OS/2 emulation.
So hdpmi16 and NE and DOSCALLS or whatever. (I don't know much.)
Again, OpenWatcom is your friend.
The support I want would need to go into Freedos,So hdpmi16 and NE and DOSCALLS or whatever. (I don't know much.)
Again, OpenWatcom is your friend.
although HXDEV16 would also be fine if it stayed
in RM16 and used only 8086 instructions. Do you
know if it can run on an 8088?
That would then be conceptually the same as what
I want, and the only change is that I don't like
DLLs and intend to provide a new API (PDOS-generic).
BFN. Paul.