Paul Edwards <mutazilah@gmail.com> wrote:

Ok, so here is the "hello world" program I am starting with:

D:\devel\pdos\xxx>hexdump os2test.exe
000000 4D5A7C00 01000000 04004100 FFFF0400 MZ|.......A.....
000010 00040000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80000000 ................
000040 0E1FB409 BA1000CD 21B001B4 4CCD2100 ........!...L.!.
000050 54686973 2070726F 6772616D 206E6565 This program nee
000060 6473204F 532F3220 322E3020 6F722065 ds OS/2 2.0 or e
000070 71756976 616C656E 740D0A24 00000000 quivalent..$....
000080 4C580000 00000000 02000100 00000000 LX..............
000090 00020000 02000000 01000000 00000000 ................
0000A0 03000000 00080000 00100000 00000000 ................
0000B0 23000000 00000000 64000000 00000000 #.......d.......
0000C0 C4000000 03000000 0C010000 00000000 ................
0000D0 1C010000 00000000 1C010000 27010000 ............'...
0000E0 00000000 00000000 28010000 34010000 ........(...4...
0000F0 41010000 01000000 4A010000 00000000 A.......J.......
000100 CC010000 00000000 00000000 00000000 ................
000110 00000000 02000000 00000000 00000000 ................
000120 00000000 00000000 00000000 00080000 ................
000130 00000000 00000000 00000000 00000000 ................
000140 00000000 28000000 00000100 05200000 ....(........ ..
000150 01000000 01000000 00000000 0C000000 ................
000160 00000200 03200000 02000000 01000000 ..... ..........
000170 00000000 00080000 00000300 03200000 ............. ..
000180 03000000 00000000 00000000 00000000 ................
000190 27000000 27000000 0A000000 076F7332 '...'........os2
0001A0 74657374 00000000 00000000 0D000000 test............
0001B0 0D000000 08011000 011A0108 811C0001 ................
0001C0 EA08444F 5343414C 4C530000 83EC0489 ..DOSCALLS......
0001D0 E0506A09 68000002 006A01E8 00000000 .Pj.h....j......
0001E0 83C4106A 006A01E8 00000000 83C40883 ...j.j..........
0001F0 C404C368 690D0A61 62630D0A 00 ...hi..abc...

D:\devel\pdos\xxx>

Looking at it and the LX documentation I have:

000000 4D5A7C00 01000000 04004100 FFFF0400 MZ|.......A.....
000010 00040000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80000000 ................
000040 0E1FB409 BA1000CD 21B001B4 4CCD2100 ........!...L.!.
000050 54686973 2070726F 6772616D 206E6565 This program nee
000060 6473204F 532F3220 322E3020 6F722065 ds OS/2 2.0 or e
000070 71756976 616C656E 740D0A24 00000000 quivalent..$....

MSDOS header (optional) ends here.

That x'40' at 0x18 is apparently important,
and the x'80' at 0x3c, which I think is
referenced as 0x1c from 0x20 means that the
extension starts at 0x80.

000080 4C580000 00000000 02000100 00000000 LX..............
000090 00020000 02000000 01000000 00000000 ................
0000A0 03000000 00080000 00100000 00000000 ................
0000B0 23000000 00000000 64000000 00000000 #.......d.......
0000C0 C4000000 03000000 0C010000 00000000 ................
0000D0 1C010000 00000000 1C010000 27010000 ............'...
0000E0 00000000 00000000 28010000 34010000 ........(...4...
0000F0 41010000 01000000 4A010000 00000000 A.......J.......
000100 CC010000 00000000 00000000 00000000 ................
000110 00000000 02000000 00000000 00000000 ................
000120 00000000 00000000 00000000 00080000 ................

And this is the end of the LX header. The last
field is x'0800' which is the stack size.

Which is indeed what I put:

.stack 800h

000130 00000000 00000000 00000000 00000000 ................
000140 00000000 28000000 00000100 05200000 ....(........ ..
000150 01000000 01000000 00000000 0C000000 ................
000160 00000200 03200000 02000000 01000000 ..... ..........
000170 00000000 00080000 00000300 03200000 ............. ..
000180 03000000 00000000 00000000 00000000 ................
000190 27000000 27000000 0A000000 076F7332 '...'........os2
0001A0 74657374 00000000 00000000 0D000000 test............
0001B0 0D000000 08011000 011A0108 811C0001 ................

My code:

Segment: _TEXT PARA USE32 00000027 bytes
0000 _os2test:
0000 83 EC 04 sub esp,0x00000004
0003 89 E0 mov eax,esp
0005 50 push eax
0006 6A 09 push 0x00000009
0008 68 00 00 00 00 push offset L$1
000D 6A 01 push 0x00000001
000F E8 00 00 00 00 call DosWrite
0014 83 C4 10 add esp,0x00000010
0017 6A 00 push 0x00000000
0019 6A 01 push 0x00000001
001B E8 00 00 00 00 call DosExit
0020 83 C4 08 add esp,0x00000008
0023 83 C4 04 add esp,0x00000004
0026 C3 ret

starts at 0x1cc

0001C0 EA08444F 5343414C 4C530000 83EC0489 ..DOSCALLS......
0001D0 E0506A09 68000002 006A01E8 00000000 .Pj.h....j......
0001E0 83C4106A 006A01E8 00000000 83C40883 ...j.j..........
0001F0 C404C368 690D0A61 62630D0A 00 ...hi..abc...

and the last byte is at 0x1f2. And then this starts immediately:

Segment: CONST DWORD USE32 0000000A bytes
0000 L$1:
0000 68 69 0D 0A 61 62 63 0D 0A 00 hi..abc...

and the executable terminates with no further ado.

So that means I am missing an interpretation of this:

000130 00000000 00000000 00000000 00000000 ................
000140 00000000 28000000 00000100 05200000 ....(........ ..
000150 01000000 01000000 00000000 0C000000 ................
000160 00000200 03200000 02000000 01000000 ..... ..........
000170 00000000 00080000 00000300 03200000 ............. ..
000180 03000000 00000000 00000000 00000000 ................
000190 27000000 27000000 0A000000 076F7332 '...'........os2
0001A0 74657374 00000000 00000000 0D000000 test............
0001B0 0D000000 08011000 011A0108 811C0001 ................
0001C0 EA08444F 5343414C 4C530000 ..DOSCALLS..

And I can see the DLL "doscalls" being referenced,
and there should be two accesses to it.

++DosWrite.DOSCALLS.DosWrite.282
++DosExit.DOSCALLS.DosExit.234

282 is x'11a'
234 is x'ea'

I can see that first at 0x1b9.

And the second is at 0x1c0, but it is followed by
x'08' which I wouldn't have expected. Maybe
the x'08' is a terminator, allowing a variable
length of DLL ordinal. I would have instead
expected a 2-byte fixed size for the DLL ordinal.

Given that DOSCALLS immediately follows the
ordinals, we need to go back to offset 0x1bc to
find something interesting, which would be
811C0001

And that should be related to DosExit.

That is here:

001B E8 00 00 00 00 call DosExit

and offset 1C needs to be zapped.

So this:

811C0001

is probably split into x'81' having some meaning,
then x'1c00' = 0x001c being an offset, and x'01'
being some section number.

So I'll try to match that to some documentation.

Ok, 2.12 Fixup Record Table appears to have the answer.

And for starters, I'm out by one.

I need to start with:

08811C0001

although I have no idea then what the trailing x'08'
would be before DOSCALLS.

So the x'08' means:

08h = 32-bit Self-relative offset fixup (32-bits).

whatever that means.

Maybe it means that the call is a relative call, so
you need to get the address of DosExit and then
put in a value relative to that.

The x'81' is then broken into:

80h = 8-bit Ordinal Flag.
When set, the ordinal number is 8-bits, otherwise it is 16-bits.

which makes sense, and:

01h = Imported reference by ordinal.

which also makes sense.

1C00 - my offset - matches this:

SRCOFF = DW

which leaves:

01

before the ordinal number.

I can't match that to anything currently.

I'll have another attempt when I'm sober.

BFN. Paul.

do you have the LX documentation?

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Edwards <mutazilah@gmail.com> wrote:

On 24/02/24 23:28, Paul Edwards wrote:

It is strictly part of proof of concept - I have
hardcoded some values and made other assumptions
just to prove that it works at all, and to allow
pdld development to proceed.

The author of pdld has started adding support for LX:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdld/src/lx.c

and also removed some hardcoding from the loader:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/bios/exeload.c

but it's still not usable for anything other than
limited testing.

With a bit of luck, that will change within 24 hours.

BFN. Paul.

Thank you, this is very interesting. I’m wondering if it’s possible to run OS/2 executables on Linux, with suitable work.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dave Yeo <dave.r.yeo@gmail.com> wrote:

Peter Flass wrote:

Thank you, this is very interesting. I’m wondering if it’s possible to run
OS/2 executables on Linux, with suitable work.

There's 2ine, needs more work of course. Couple of links, https://virtuallyfun.com/2018/02/23/2ine-the-os-2-emulator/ https://virtuallyfun.com/2018/06/11/2ine-updated-to-have-preliminary-16-bit-exe-support/
Dave

What a coincidence. I was thinking “twine”.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)