Welcome to Rocksolid Light

mail files register newsreader groups login

Message-ID:

"Let us condemn to hellfire all those who disagree with us." -- militant religionists everywhere

Re: loader

Subject	Author
loader	Paul Edwards
Re: loader	Peter Flass
Re: loader	Paul Edwards
Re: loader	Paul Edwards
Re: loader	Paul Edwards
Re: loader	Paul Edwards
Re: loader	Paul Edwards
Re: loader	Paul Edwards
Re: loader	Paul Edwards
Re: loader	Paul Edwards
Re: loader	Paul Edwards
Re: loader	Peter Flass
Re: loader	Paul Edwards
Re: loader	Dave Yeo
Re: loader	Paul Edwards
Re: loader	Dave Yeo
Re: loader	Paul Edwards
Re: loader	Dave Yeo
Re: loader	Paul Edwards
Re: loader	Dave Yeo
Re: loader	Dave Yeo
Re: loader	Peter Flass

loader

<ur1mqi$2ddfu$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=78&group=comp.os.os2.programmer.misc#78

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: loader
Date: Tue, 20 Feb 2024 16:10:55 +0800
Organization: A noiseless patient Spider
Lines: 222
Message-ID: <ur1mqi$2ddfu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 20 Feb 2024 08:10:59 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5a42e109a14e96f3471bdcf90f68f77e";
logging-data="2536958"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Uxmjk3wrE9jiIni1X+5ku7nX1vrjTd/M="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:EuD/zUoCev1aeVIgE3SIMWOdx8k=
X-Mozilla-News-Host: news://news.eternal-september.org:119

by: Paul Edwards - Tue, 20 Feb 2024 08:10 UTC

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:

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:

before the ordinal number.

I can't match that to anything currently.

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

BFN. Paul.

Re: loader

<1547033795.730168788.014321.peter_flass-yahoo.com@news.eternal-september.org>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=80&group=comp.os.os2.programmer.misc#80

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!usenet.network!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: peter_flass@yahoo.com (Peter Flass)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Tue, 20 Feb 2024 17:45:37 -0700
Organization: A noiseless patient Spider
Lines: 229
Message-ID: <1547033795.730168788.014321.peter_flass-yahoo.com@news.eternal-september.org>
References: <ur1mqi$2ddfu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Info: dont-email.me; posting-host="a5bd0e41f76a7f741edcc4ff9ebb28a8";
logging-data="2916651"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18JIi1DnBs/QNs489kJ/SGx"
User-Agent: NewsTap/5.3.1 (iPad)
Cancel-Lock: sha1:cGpH6nS/srpQA6UFgU3KuOWvTOQ=
sha1:JzKgMGczNWpoXq1LsGJUNt39xxw=

by: Peter Flass - Wed, 21 Feb 2024 00:45 UTC

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.
>

Click here to read the complete article

Re: loader

<ur3ofk$2q523$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=83&group=comp.os.os2.programmer.misc#83

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!news.samoylyk.net!nntp.terraraq.uk!news.gegeweb.eu!gegeweb.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Wed, 21 Feb 2024 10:51:32 +0800
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <ur3ofk$2q523$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me>
<1547033795.730168788.014321.peter_flass-yahoo.com@news.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 21 Feb 2024 02:51:32 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="ddc99c20dba38873cfbfcc79cf1ee053";
logging-data="2954307"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18452ef6BpSkrDfdNzbdTBbZynqodyXOWA="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:cmk1g8S63QIZIcZBHeQXNpBCnQI=
In-Reply-To: <1547033795.730168788.014321.peter_flass-yahoo.com@news.eternal-september.org>

by: Paul Edwards - Wed, 21 Feb 2024 02:51 UTC

On 21/02/24 08:45, Peter Flass wrote:
> Paul Edwards <mutazilah@gmail.com> wrote:

>> So I'll try to match that to some documentation.
>>
>> Ok, 2.12 Fixup Record Table appears to have the answer.

>> So the x'08' means:
>>
>> 08h = 32-bit Self-relative offset fixup (32-bits).
>>
>> whatever that means.
>>
>> 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
>>
>> before the ordinal number.

> do you have the LX documentation?

Yes, I quoted some of the IBM documentation above.

BFN. Paul.

Re: loader

<urb5bb$p95e$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=87&group=comp.os.os2.programmer.misc#87

copy link Newsgroups: comp.os.os2.programmer.misc

by: Paul Edwards - Fri, 23 Feb 2024 22:14 UTC

On 20/02/24 16:10, Paul Edwards wrote:

> 0001C0 EA08444F 5343414C 4C530000 83EC0489 ..DOSCALLS......

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

Ok, I know what it is now. It's a 1-byte length
field of the name "DOSCALLS", which, as per
2.13 Import Module Name Table, is not NUL-terminated.

So those two extra x'00' before the actual code
starts at x'1cc' are likely padding bytes.

BFN. Paul.

Re: loader

<urbocg$10hfb$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=88&group=comp.os.os2.programmer.misc#88

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Sat, 24 Feb 2024 11:38:54 +0800
Organization: A noiseless patient Spider
Lines: 121
Message-ID: <urbocg$10hfb$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urb5bb$p95e$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 24 Feb 2024 03:38:57 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5038794090326e503ea09e790ce08079";
logging-data="1066475"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Y3Opwc5t0/pa3dbl9mKGvA72kdu9//NY="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:I1aCKcz9DTDIDe9vmvrmpdpFzsE=
In-Reply-To: <urb5bb$p95e$1@dont-email.me>

by: Paul Edwards - Sat, 24 Feb 2024 03:38 UTC

On 24/02/24 06:14, Paul Edwards wrote:
> On 20/02/24 16:10, Paul Edwards wrote:
>
>> 0001C0 EA08444F 5343414C 4C530000 83EC0489 ..DOSCALLS......
>
>> although I have no idea then what the trailing x'08'
>> would be before DOSCALLS.
>
> Ok, I know what it is now. It's a 1-byte length
> field of the name "DOSCALLS", which, as per
> 2.13 Import Module Name Table, is not NUL-terminated.
>
> So those two extra x'00' before the actual code
> starts at x'1cc' are likely padding bytes.

And that offset 1c1 where the import module name table
starts, can be found, is supposedly at 70H in the header.

Which puts it at F0:

where we can see 0141. I see an interesting 01CC
(ie where my code is) on the next line, which would
be "data pages offset". Not sure what that is.

So back to the 141. I know I need to get to 1C1.
So I'm off by x'80'. So I just need to subtract
the DOS header - cool - the x'141' is the offset
from the LX header.

So trying the x'1cc' again - maybe the data is
loaded at an offset 0x80 from the code, and so
that's the final spot for it? And perhaps the
LX header is expected to be loaded into memory too.

That would require all the other tables to be loaded
too, which would be odd - especially all the relocation
entries which don't serve any purpose once the application
is loaded.

You can always adjust for that though.

Maybe it is set up for a lazy load, and just the data
needs to be memmove'ed to the proper offset if you do
that. Seems odd to be moving it just that small amount
though. ie after accounting for the code, maybe moving
it x'60' bytes. Doesn't sound like a very sensible
alignment.

I see 011c mentioned a couple of times earlier. So
that (likely) corresponds to 019c in the hexdump.
The program name? Someone is interested in that?
Ok, so:

0000D0 1C010000 00000000 1C010000

subtract 80 and you get 50 and 58.

"resource table offset" and "resident
name table offset"? Maybe these are just
dummy pointers, and there is a length
specifier to say the table is empty.

Ok, header x'54' is indeed the number of entries,
and so that (D4 above) is indeed 0, so it's
basically non-existent.

So only the "resident name table offset" is real
perhaps - I don't see a number of entries for it,
so I don't know what that might be.

RESIDENT NAME TBL OFF = DD Resident Name Table offset.
This offset is relative to the beginning of the linear EXE header

Smells correct.

And yes ...

The resident and non-resident name tables define the ASCII names and
ordinal numbers for exported entries
in the module. In addition the first entry in the resident name table
contains the module name.

.... the module name is a special first entry.

And indeed, there is no number of entries because:

LEN = DB String Length.
This defines the length of the string in bytes. A zero length indicates
there are no more entries in
table.

Still more stuff to be fleshed out.

BFN. Paul.

Re: loader

<urc5jb$12sfb$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=89&group=comp.os.os2.programmer.misc#89

copy link Newsgroups: comp.os.os2.programmer.misc

by: Paul Edwards - Sat, 24 Feb 2024 07:24 UTC

On 20/02/24 16:10, Paul Edwards wrote:

Ok, another crack at that data.

> 0008 68 00 00 00 00 push offset L$1

This is the push of the data.

ie this data (L$1):

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

And in the executable, that code is:

> 0001C0 EA08444F 5343414C 4C530000 83EC0489 ..DOSCALLS......
> 0001D0 E0506A09 68000002 006A01E8 00000000 .Pj.h....j......

68 and a value of 00020000

That looks like a common starting point for data -
2 * 64k. And code is typically placed at 1 * 64k.

Unless relocation information is available and
applied, in which case you can correct all these
values.

Which is a good point - I don't use virtual memory
in PDOS/386 so that address can't possibly stand,
unless it is relative. I doubt that it is a relative
address, but I'm not sufficiently familiar with
x86 opcodes.

Regardless, now would be a good time to find out if
I can find a relocation fixup pointing to that address,
ie offset 9 in the code section.

I don't see such a thing:

D:\devel\pdos_minimal\xxx>hexdump os2test.exe | grep 09
000040 0E1FB409 BA1000CD 21B001B4 4CCD2100 ........!...L.!.
000090 00020000 02000000 01000000 00000000 ................
0001D0 E0506A09 68000002 006A01E8 00000000 .Pj.h....j......

D:\devel\pdos_minimal\xxx>

Maybe the reference is to 1cc+9 or more likely, 14c+9 = 155

D:\devel\pdos_minimal\xxx>hexdump os2test.exe | grep 55

D:\devel\pdos_minimal\xxx>

Nope.

Let me see if there is a wlink option to add relocatable
information.

Nothing stands out with "wlink /?".

Windows executables built by Watcom are (now - just
fixed unrelated issues) working fine under PDOS/386
which means they should contain relocations.

Let me see if the documentation gives any hints.

Offsets 30h, 68h and 6ch are the most likely.

> 0000B0 23000000 00000000 64000000 00000000 #.......d.......

23 as a size is an odd number.

> 0000E0 00000000 00000000 28010000 34010000 ........(...4...

0128 as an offset to something, 0134 as an
offset to something else. So what's there?

> 000190 27000000 27000000 0A000000 076F7332 '...'........os2
> 0001A0 74657374 00000000 00000000 0D000000 test............
> 0001B0 0D000000 08011000 011A0108 811C0001 ................

So 1A8 (128 + 80) is 0 and a D and another D.

And 1B4 (134 + 80) is looking like that thing
I documented before with the external names.

I hope OS/2 isn't a system that relies on
virtual memory and doesn't have relocation
capability.

The thing I documented before was:

> I can see that first at 0x1b9.

> 0001B0 0D000000 08011000 011A0108 811C0001 ................

And indeed - 1B4 is where a DLL fixup is being done.

Fixing up DLL entries is a different concept to
providing relocation information for a module
that has been relocated.

So first thing I need to know is - do OS/2 modules
have a concept of relocation information?

MSDOS 16-bit had that.

From memory NE executables had it too.

Yes, here is some of the NE code I wrote:

fread(numreloc, sizeof numreloc, 1, fp);

nr = numreloc[0] | (numreloc[1] << 8);

/* printf("nr is %d\n", nr); */
for (x = 0; x < nr; x++)
{ /* 2 is segment, 3 is a far address,
5 is an offset */
fread(reloc, sizeof reloc, 1, fp);
if ((reloc[0] != 2)

Is it known by a different name in LX, or is it
non-existent?

This looks interesting:

2.12.5 - Internal Chaining Fixups

Internal chaining fixups are 32-bit offset fixups (source type 07h) to
internal references (target types 00h and
03h) where the first fixup in the chain is a record in the Fixup Record
Table and the remaining fixups are
located in the page referenced by the first fixup rather than as records
in the Fixup Record Table

Looks exactly what I need.

NE is a chain too.

So - where are these?

And it seems to be associated with this:

2.12.4 Internal Entry Table Fixup Record

And probably this:

2.12.1 - Internal Fixup Record

And:

2.12 - Fixup Record Table

which has something I saw earlier:

07h = 32-bit Offset fixup (32-bits).

So - what points to this "Fixup Record Table"?

That's the x'6c' - where I was before.

And as before - I'm missing something that would
allow me to zap that offset.

Either I'm missing relocations in the executable,
or I'm incorrectly thinking that a fixup is needed
in this situation (ie maybe it is relative and the
distance to the data section needs to remain fixed),
or I'm missing some other concept of some sort.

What are all these other numbers anyway?

> 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

Can I see something in the header that points
to them? That would be offset x'B0' to x'120'.

> 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 ................

I see a x'00c4' in that range. Nothing else.
That's at C0 = 40, ie object table offset.

number of objects being 3. Not sure what that
3 represents. But let's go to offset C4, ie
144 in the hexdump.

Before that is all NULs, so could be padding.

And there should be 3 "objects", whatever that is.

Let's see if I can match it to some documentation.
First bit of data is x'28'.

Looks like each entry is x'18' bytes.

And the x'28' is a length - so presumably the length
of the code. That's very close to correct. It should
be x'27' - unless it is size in memory.

And base address is 010000 - reasonable.

Next we have a length of x'c', and a base address of
020000. I'm only expecting 10 bytes of data - so again,
this could be the size when placed in memory, rounded
to a 4-byte boundary.

All very reasonable. What on earth could the 3rd one be?

A length of x'800' - gotta be the stack. Located at x'30000'.

And that covers all the unknowns except:

> 000190 27000000 27000000 0A000000 076F7332 '...'........os2

The x'27' is the actual length of the code. Not
sure why it would be listed twice. And x'0a' is
the actual length of the data. That is likely
referenced earlier. Maybe page sizes?

Oh, I missed a bit.

> 000180 00000000 ................
> 000190 27000000 27000000 0A000000 076F7332 '...'........os2

So offset 0, length 27, and flags.

Then offset 27, length A, and flags.

That is "2.5 Object Page Table".

And that's everything I think. I'm missing the
"internal fixups". Not sure if I missed a wlink
option or something.

BFN. Paul.

Re: loader

<urc6so$133ut$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=90&group=comp.os.os2.programmer.misc#90

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Sat, 24 Feb 2024 15:46:28 +0800
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <urc6so$133ut$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 24 Feb 2024 07:46:32 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5038794090326e503ea09e790ce08079";
logging-data="1150941"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/GiVnJ7BnkodZCvXfV1UEaSMzefMgRnvM="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:HSXo4Se+79pbmwbZdnjnQcoWmbQ=
In-Reply-To: <urc5jb$12sfb$1@dont-email.me>

by: Paul Edwards - Sat, 24 Feb 2024 07:46 UTC

On 24/02/24 15:24, Paul Edwards wrote:

> 0000E0 00000000 00000000 28010000 34010000 ........(...4...

> 0128 as an offset to something, 0134 as an
> offset to something else. So what's there?
>
>> 000190 27000000 27000000 0A000000 076F7332 '...'........os2
>> 0001A0 74657374 00000000 00000000 0D000000 test............
>> 0001B0 0D000000 08011000 011A0108 811C0001 ................
>> 0001C0 EA08444F 5343414C 4C530000 83EC0489 ..DOSCALLS......
>
> So 1A8 (128 + 80) is 0 and a D and another D.

I didn't document this.

So x'128' as seen at offset E8 = 68 is
"fixup page table offset", which brings us to:

2.11 Fixup Page Table

There were 2 object page table things, so we are
expecting an extra one, ie 3 fixup entries, with
the last being a pointer to the end. And given
that the last two entries are 'D', it means that
the second object code had no fixups (ie data
doesn't point to other data or code), so it just
points to the end, as a dummy.

And what exactly is the x'd' anyway?

That will be from x'1b4' in the hexdump (ie the DLL
fixups) to just before the "08444F 5343414C 4C53"
(DOSCALLS) at x'1c1'.

Still doesn't get me the required internal fixups.

BFN. Paul.

Re: loader

<urc9ed$13job$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=91&group=comp.os.os2.programmer.misc#91

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!news.niel.me!news.gegeweb.eu!gegeweb.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Sat, 24 Feb 2024 16:30:02 +0800
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <urc9ed$13job$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 24 Feb 2024 08:30:05 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5038794090326e503ea09e790ce08079";
logging-data="1167115"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Y2zJSQnHAhXaFy+CE4HD3Ir5r/T8mWo4="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:niHr3njxGTt2UWPQF3y/4VxEJCc=
In-Reply-To: <urc6so$133ut$1@dont-email.me>

by: Paul Edwards - Sat, 24 Feb 2024 08:30 UTC

On 24/02/24 15:46, Paul Edwards wrote:

> Still doesn't get me the required internal fixups.

Got it!

https://open-watcom.github.io/open-watcom-v2-wikidocs/lguide.html

The INTERNALRELOCS Option

Formats: OS/2

The "INTERNALRELOCS" option is used with LX format executables under
32-bit OS/2. By default, OS/2 executables do not contain internal
relocation information and OS/2 Dynamic Link Libraries do contain
internal relocation information. This option causes the Open Watcom
Linker to include internal relocation information in OS/2 LX format
executables.

The format of the "INTERNALRELOCS" option (short form "INT") is as follows.

OPTION INTERNALRELOCS

Not documented here:

D:\devel\pdos_minimal\xxx>wlink /? | grep -i int
export ::=
entryname["."ordinal]["="internal]["RESident"]["PRIVATE"][iopl]
export ::= entryname["."ordinal]["="internal]["RESident"]["PRIVATE"]
export ::= entryname["."ordinal]["="internal]["PRIVATE"]

D:\devel\pdos_minimal\xxx>

But it works:

wlink File os2test.obj,os2test2.obj Name os2test.exe Form os2 flat
PMCompatible Library os2.lib Option
quiet,start=_os2test,stub=needpdos.exe,internalrelocs

And my executable is 8 bytes bigger:

D:\devel\pdos_minimal\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 10020000 02000000 01000000 00000000 ................
0000A0 03000000 00080000 00100000 00000000 ................
0000B0 2A000000 00000000 64000000 00000000 *.......d.......
0000C0 C4000000 03000000 0C010000 00000000 ................
0000D0 1C010000 00000000 1C010000 27010000 ............'...
0000E0 00000000 00000000 28010000 34010000 ........(...4...
0000F0 48010000 01000000 51010000 00000000 H.......Q.......
000100 D4010000 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 14000000 test............
0001B0 14000000 08011000 011A0108 811C0001 ................
0001C0 EA070009 00020000 08444F53 43414C4C .........DOSCALL
0001D0 53000000 83EC0489 E0506A09 68000002 S........Pj.h...
0001E0 006A01E8 00000000 83C4106A 006A01E8 .j.........j.j..
0001F0 00000000 83C40883 C404C368 690D0A61 ...........hi..a
000200 62630D0A 00 bc...

And now I can see both the x'07' and the x'09' here:

0001C0 EA070009 00020000 08444F53 43414C4C .........DOSCALL

So that reads:

07h = 32-bit Offset fixup (32-bits).

00h = Internal reference.

0009 = SRCOFF = DW

02 = object index (apparently data)

0000 = offset in the data - my string starts at offset 0
so you don't get to see a nice value there.

BFN. Paul.

Re: loader

<urd23s$18o8p$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=92&group=comp.os.os2.programmer.misc#92

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Sat, 24 Feb 2024 23:30:59 +0800
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <urd23s$18o8p$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 24 Feb 2024 15:31:09 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5038794090326e503ea09e790ce08079";
logging-data="1335577"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19kSJuDuxhLfQB5m4li/6vsIsd32DKRW9I="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:mmeQ6q30be4m1ivbbtgjO/MSgW0=
In-Reply-To: <urc9ed$13job$1@dont-email.me>

by: Paul Edwards - Sat, 24 Feb 2024 15:30 UTC

I modified my test a little bit.

#include <os2.h>

void os2test(void)
{ ULONG written;

DosWrite(1, "hi\r\n", 4, &written);
DosWrite(1, "abc\r\n", 5, &written);
DosExit(1, 0);
}

..386

..model flat, c

..stack 800h

end

D:\devel\pdos_minimal\xxx>type doit.bat
wcl386 -ecc -D__OS2__ -D__32BIT__ -bt=os2 -l=os2v2 -wx -c -I. -I..\src
-I..\pdpclib -y -fpi87 -s
-zq -3s -zm -zl -oneatblr os2test.c
wasm -zq os2test2.asm
wlink File os2test.obj,os2test2.obj Name os2test.exe Form os2 flat
PMCompatible Library os2.lib
Option quiet,start=_os2test,stub=needpdos.exe,internalrelocs

D:\devel\pdos_minimal\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 10020000 02000000 01000000 00000000 ................
0000A0 03000000 00080000 00100000 00000000 ................
0000B0 38000000 00000000 64000000 00000000 8.......d.......
0000C0 C4000000 03000000 0C010000 00000000 ................
0000D0 1C010000 00000000 1C010000 27010000 ............'...
0000E0 00000000 00000000 28010000 34010000 ........(...4...
0000F0 56010000 01000000 5F010000 00000000 V......._.......
000100 E0010000 00000000 00000000 00000000 ................
000110 00000000 02000000 00000000 00000000 ................
000120 00000000 00000000 00000000 00080000 ................
000130 00000000 00000000 00000000 00000000 ................
000140 00000000 3C000000 00000100 05200000 ....<........ ..
000150 01000000 01000000 00000000 0C000000 ................
000160 00000200 03200000 02000000 01000000 ..... ..........
000170 00000000 00080000 00000300 03200000 ............. ..
000180 03000000 00000000 00000000 00000000 ................
000190 3B000000 3B000000 0B000000 076F7332 ;...;........os2
0001A0 74657374 00000000 00000000 22000000 test........"...
0001B0 22000000 08011000 011A0108 01240001 "............$..
0001C0 1A010881 300001EA 07000900 02000007 ....0...........
0001D0 001D0002 05000844 4F534341 4C4C5300 .......DOSCALLS.
0001E0 83EC0489 E0506A04 68000002 006A01E8 .....Pj.h....j..
0001F0 00000000 83C41089 E0506A05 68050002 .........Pj.h...
000200 006A01E8 00000000 83C4106A 006A01E8 .j.........j.j..
000210 00000000 83C40883 C404C368 690D0A00 ...........hi...
000220 6162630D 0A00 abc...

D:\devel\pdos_minimal\xxx>

And the pdos.zip at http://pdos.org is capable of
loading it.

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.

BFN. Paul.

Re: loader

<urd1vu$18mln$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=93&group=comp.os.os2.programmer.misc#93

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Sat, 24 Feb 2024 23:28:28 +0800
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <urd1vu$18mln$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 24 Feb 2024 15:31:12 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5038794090326e503ea09e790ce08079";
logging-data="1333943"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+LyajxysWK81vlWz/e6ZfqGR2RC89a3Sw="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:t7cJAiHQHANhwjTK8/5vI7vV+Hw=
In-Reply-To: <urc9ed$13job$1@dont-email.me>

by: Paul Edwards - Sat, 24 Feb 2024 15:28 UTC

I modified my test a little bit.

#include <os2.h>

void os2test(void)
{ ULONG written;

DosWrite(1, "hi\r\n", 4, &written);
DosWrite(1, "abc\r\n", 5, &written);
DosExit(1, 0);
}

..386

..model flat, c

..stack 800h

end

D:\devel\pdos_minimal\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 10020000 02000000 01000000 00000000 ................
0000A0 03000000 00080000 00100000 00000000 ................
0000B0 38000000 00000000 64000000 00000000 8.......d.......
0000C0 C4000000 03000000 0C010000 00000000 ................
0000D0 1C010000 00000000 1C010000 27010000 ............'...
0000E0 00000000 00000000 28010000 34010000 ........(...4...
0000F0 56010000 01000000 5F010000 00000000 V......._.......
000100 E0010000 00000000 00000000 00000000 ................
000110 00000000 02000000 00000000 00000000 ................
000120 00000000 00000000 00000000 00080000 ................
000130 00000000 00000000 00000000 00000000 ................
000140 00000000 3C000000 00000100 05200000 ....<........ ..
000150 01000000 01000000 00000000 0C000000 ................
000160 00000200 03200000 02000000 01000000 ..... ..........
000170 00000000 00080000 00000300 03200000 ............. ..
000180 03000000 00000000 00000000 00000000 ................
000190 3B000000 3B000000 0B000000 076F7332 ;...;........os2
0001A0 74657374 00000000 00000000 22000000 test........"...
0001B0 22000000 08011000 011A0108 01240001 "............$..
0001C0 1A010881 300001EA 07000900 02000007 ....0...........
0001D0 001D0002 05000844 4F534341 4C4C5300 .......DOSCALLS.
0001E0 83EC0489 E0506A04 68000002 006A01E8 .....Pj.h....j..
0001F0 00000000 83C41089 E0506A05 68050002 .........Pj.h...
000200 006A01E8 00000000 83C4106A 006A01E8 .j.........j.j..
000210 00000000 83C40883 C404C368 690D0A00 ...........hi...
000220 6162630D 0A00 abc...

D:\devel\pdos_minimal\xxx>

And the pdos.zip at http://pdos.org is capable of
loading it.

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.

BFN. Paul.

Re: loader

<urggi7$24i42$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=94&group=comp.os.os2.programmer.misc#94

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Mon, 26 Feb 2024 06:56:04 +0800
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <urggi7$24i42$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 25 Feb 2024 22:56:08 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="d29ee2a087eb3b232c8dd1d1a83ad8fd";
logging-data="2246786"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19SyFlUpsmEAeExZMrOHp/ZAEofakHPEuI="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:W/x5xwMJtElQ8EXMYNPsfQ6sIqw=
In-Reply-To: <urd1vu$18mln$1@dont-email.me>

by: Paul Edwards - Sun, 25 Feb 2024 22:56 UTC

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.

Re: loader

<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=95&group=comp.os.os2.programmer.misc#95

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: peter_flass@yahoo.com (Peter Flass)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Tue, 27 Feb 2024 15:41:26 -0700
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
References: <ur1mqi$2ddfu$1@dont-email.me>
<urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me>
<urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me>
<urggi7$24i42$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Info: dont-email.me; posting-host="0b7533f9ac44d56b5fdaf79372f5f34c";
logging-data="3632247"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/MFCy+YRDsojGhe7MM5B0C"
User-Agent: NewsTap/5.3.1 (iPad)
Cancel-Lock: sha1:lPc2IeD/uCmOdCSGxbh2WxRSK4I=
sha1:/4ZGw3UOAFg5cAkjF3c3lZIkkJw=

by: Peter Flass - Tue, 27 Feb 2024 22:41 UTC

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

Re: loader

<urme2j$3maq2$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=96&group=comp.os.os2.programmer.misc#96

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Wed, 28 Feb 2024 12:50:24 +0800
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <urme2j$3maq2$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 28 Feb 2024 04:50:28 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="502f8de6b28ef0ddcf3708890a9caeea";
logging-data="3877698"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/C/G4VjkLEBEcqqe4TRkX5MYf4P/V+YU8="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:wv2ZkTOtrto3I2htnrTOksjsPIw=
In-Reply-To: <1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>

by: Paul Edwards - Wed, 28 Feb 2024 04:50 UTC

On 28/02/24 06:41, Peter Flass wrote:

>> 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.

OS/2 didn't move overnight (ie Slovakia daytime)
because focus was switched to supporting Linux ELF,
which has made gigantic strides and I should be
back to that later today.

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

Yes, for a similar reason that certain Win32 programs
can be run under Linux, a similar (but different
because of the intercept at doscalls.dll rather than
msvcrt.dll) technique proved to be possible for OS/2,
and if you go to http://pdos.org and search for the
second occurrence of OS/2, you will see uc386l.zip
which contains a standalone (no dependency even on
libc) 50k bios.exe Linux ELF binary which is capable
of running certain Win32 executables (some provided
in the distribution), and very limited (like the one
I posted here as a hexdump) OS/2 executables.

There is no barrier I know of for this to be further
fleshed out to support any C90 application - and with
limited increase to the 50k size.

The main barrier is the pdld author is grappling with
some OS/2 executable issues and I don't want to outrun
him (and he is the safer pair of hands if he chooses
to modify exeload in tandem).

He seemed annoyed that he couldn't access doscalls
functions by name instead of ordinal and asked me if
there was a reason for that. Anyone know?

He also had issues with "object" (LX) vs "section" (PE)
but it is unclear to me whether they are conceptually
different.

BFN. Paul.

Re: loader

<BWNDN.72066$Wbff.66055@fx37.iad>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=97&group=comp.os.os2.programmer.misc#97

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.iad.POSTED!not-for-mail
Subject: Re: loader
Newsgroups: comp.os.os2.programmer.misc
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
From: dave.r.yeo@gmail.com (Dave Yeo)
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101 Firefox/45.0
SeaMonkey/2.42.9esr
MIME-Version: 1.0
In-Reply-To: <1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 8
Message-ID: <BWNDN.72066$Wbff.66055@fx37.iad>
X-Complaints-To: https://www.astraweb.com/aup
NNTP-Posting-Date: Wed, 28 Feb 2024 21:52:33 UTC
Date: Wed, 28 Feb 2024 13:52:33 -0800
X-Received-Bytes: 1304

by: Dave Yeo - Wed, 28 Feb 2024 21:52 UTC

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

Re: loader

<E5ODN.131351$STLe.52819@fx34.iad>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=98&group=comp.os.os2.programmer.misc#98

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx34.iad.POSTED!not-for-mail
Subject: Re: loader
Newsgroups: comp.os.os2.programmer.misc
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
<urme2j$3maq2$1@dont-email.me>
From: dave.r.yeo@gmail.com (Dave Yeo)
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101 Firefox/45.0
SeaMonkey/2.42.9esr
MIME-Version: 1.0
In-Reply-To: <urme2j$3maq2$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 50
Message-ID: <E5ODN.131351$STLe.52819@fx34.iad>
X-Complaints-To: https://www.astraweb.com/aup
NNTP-Posting-Date: Wed, 28 Feb 2024 22:04:20 UTC
Date: Wed, 28 Feb 2024 14:04:19 -0800
X-Received-Bytes: 2184

by: Dave Yeo - Wed, 28 Feb 2024 22:04 UTC

Paul Edwards wrote:
> He seemed annoyed that he couldn't access doscalls
> functions by name instead of ordinal and asked me if
> there was a reason for that. Anyone know?

Usual use of ordinals was to save memory. Important when running with
4MB's of ram like when I started.
Usually link to doscall1.dll, rather then directly to the kernel, where
doscall1.dll does seem to export by name. Just generated a DEF file from
the SMP version of doscall1.dll,
; ; doscall1.def (created by emximp)
; LIBRARY doscall1 INITINSTANCE TERMGLOBAL
EXPORTS
"DOSTIMERASYNC"
"DOSTIMERSTART"
"DOSTIMERSTOP"
"DOSREAD"
"DOSWRITE"
"DOSERRCLASS"
"DOSSEMREQUEST"
"DOSSEMCLEAR"
"DOSSEMWAIT"
"DOSSEMSET"
"DOSEXECPGM"
"DOSSUBSET"
"DOSSUBALLOC"
"DOSSUBFREE"
"DOSREADASYNC"
"DOSWRITEASYNC"
"DOSSEARCHPATH"
"DOSSCANENV"
"DOSSETCP"
"DOSCALLBACK"
"DOSFSRAMSEMREQUEST"
"DOSFSRAMSEMCLEAR"
"DOSQAPPTYPE"
"DOSSETPROCCP"
"DOSLOGREGISTER"
"DOSLOGREAD"
"DOSCOPY"
"DOSPMSEMWAIT"
"DOSPMMUXSEMWAIT"
"DOSSGQUERYTOPMOST"
"DOSSETEXTLIBPATH"
"DOSQUERYEXTLIBPATH"

Dave

Re: loader

<nkODN.101569$GX69.2827@fx46.iad>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=99&group=comp.os.os2.programmer.misc#99

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!nntp.comgw.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
Subject: Re: loader
Newsgroups: comp.os.os2.programmer.misc
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
<urme2j$3maq2$1@dont-email.me>
From: dave.r.yeo@gmail.com (Dave Yeo)
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101 Firefox/45.0
SeaMonkey/2.42.9esr
MIME-Version: 1.0
In-Reply-To: <urme2j$3maq2$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 58
Message-ID: <nkODN.101569$GX69.2827@fx46.iad>
X-Complaints-To: https://www.astraweb.com/aup
NNTP-Posting-Date: Wed, 28 Feb 2024 22:20:03 UTC
Date: Wed, 28 Feb 2024 14:20:02 -0800
X-Received-Bytes: 2962

by: Dave Yeo - Wed, 28 Feb 2024 22:20 UTC

Paul Edwards wrote:
> He seemed annoyed that he couldn't access doscalls
> functions by name instead of ordinal and asked me if
> there was a reason for that. Anyone know?

There's also the RESIDENTNAME key word. From the toolkits documentation,
Tools Reference. Ignore the pwords stuff, doesn't apply to protected
mode as far as I know.
....
Export-Definition Syntax

entryname [=internalname] [@ord[RESIDENTNAME]] [pwords]

<entryname>
The function name as it is known to other modules.

<internalname>
The actual name of the export function as it appears within the module
itself; by default, this name is the same as <entryname>.

<ord>
The function's ordinal position within the module definition table. If
this field is used, the function's entry point can be invoked by name or
by ordinal. Use of ordinal positions is faster and may save space.

RESIDENTNAME
Indicates that the function's name be kept resident in memory at all
times. This keyword is applicable only if <ord> is used. If <ord> is not
used, OS/2 automatically keeps the names of all exported functions
resident in memory by default.

<pwords>
The total size of the function's parameters, as measured in words (bytes
divided by two). This field is required only if the function executes
with I/O privilege. When a function with I/O privilege is called, OS/2
consults <pwords> to determine how many words to copy from the caller's
stack to the I/O-privileged function's stack.

Example

EXPORTS
SampleRead = read2bin @8
StringIn = str1 @4 RESIDENTNAME
CharTest 6

This example defines three export functions:

SampleRead
StringIn
CharTest

The first two functions can be accessed either by their exported names
or by an ordinal number. Note that in the module's own source code,
these functions are actually defined as read2bin and str1, respectively.
The last function runs with I/O privilege and therefore is given with
the total size of the parameters - six words.
....
Dave

Re: loader

<urodmj$4fom$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=100&group=comp.os.os2.programmer.misc#100

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Thu, 29 Feb 2024 06:56:17 +0800
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <urodmj$4fom$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
<urme2j$3maq2$1@dont-email.me> <E5ODN.131351$STLe.52819@fx34.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 28 Feb 2024 22:56:20 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="502f8de6b28ef0ddcf3708890a9caeea";
logging-data="147222"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19uH2m1YhBPpt514Kh90QAb5uzGzXKXvPs="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:2ZTaag/7W+uEtSj93uwFAiItLx8=
In-Reply-To: <E5ODN.131351$STLe.52819@fx34.iad>

by: Paul Edwards - Wed, 28 Feb 2024 22:56 UTC

Hi Dave.

Thanks for the explanation.

That seems to be missing DOSOPEN as well as others.

Note that I received an enhancement to exeload.c
overnight which should allow for much more robust
loading of executables and I'll see what it is
capable of later (source has been committed
already though, and makebios.lnp has the
instructions).

Also the pdld author's concerns appear to have been
allayed.

I will add the missing function names to exeload.c,
which is trivial, and see what happens when I load
pdptest.exe built by Watcom.

I would still need to flesh out my doscalls.c, but
that shouldn't be an issue to get pdptest.exe to run.

BFN. Paul.

On 29/02/24 06:04, Dave Yeo wrote:
> Paul Edwards wrote:
>> He seemed annoyed that he couldn't access doscalls
>> functions by name instead of ordinal and asked me if
>> there was a reason for that. Anyone know?
>
> Usual use of ordinals was to save memory. Important when running with
> 4MB's of ram like when I started.
> Usually link to doscall1.dll, rather then directly to the kernel, where
> doscall1.dll does seem to export by name. Just generated a DEF file from
> the SMP version of doscall1.dll,
> ;
> ; doscall1.def (created by emximp)
> ;
> LIBRARY doscall1 INITINSTANCE TERMGLOBAL
> EXPORTS
> "DOSTIMERASYNC"
> "DOSTIMERSTART"
> "DOSTIMERSTOP"
> "DOSREAD"
> "DOSWRITE"
> "DOSERRCLASS"
> "DOSSEMREQUEST"
> "DOSSEMCLEAR"
> "DOSSEMWAIT"
> "DOSSEMSET"
> "DOSEXECPGM"
> "DOSSUBSET"
> "DOSSUBALLOC"
> "DOSSUBFREE"
> "DOSREADASYNC"
> "DOSWRITEASYNC"
> "DOSSEARCHPATH"
> "DOSSCANENV"
> "DOSSETCP"
> "DOSCALLBACK"
> "DOSFSRAMSEMREQUEST"
> "DOSFSRAMSEMCLEAR"
> "DOSQAPPTYPE"
> "DOSSETPROCCP"
> "DOSLOGREGISTER"
> "DOSLOGREAD"
> "DOSCOPY"
> "DOSPMSEMWAIT"
> "DOSPMMUXSEMWAIT"
> "DOSSGQUERYTOPMOST"
> "DOSSETEXTLIBPATH"
> "DOSQUERYEXTLIBPATH"
>
> Dave
>

Re: loader

<1613125914.730860071.126016.peter_flass-yahoo.com@news.eternal-september.org>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=101&group=comp.os.os2.programmer.misc#101

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!news.hispagatos.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: peter_flass@yahoo.com (Peter Flass)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Wed, 28 Feb 2024 17:43:10 -0700
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <1613125914.730860071.126016.peter_flass-yahoo.com@news.eternal-september.org>
References: <ur1mqi$2ddfu$1@dont-email.me>
<urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me>
<urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me>
<urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
<BWNDN.72066$Wbff.66055@fx37.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Info: dont-email.me; posting-host="e46ebadc237e00525a998964c8023158";
logging-data="185230"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ke27G1a5+p+TlzyBq7AXw"
User-Agent: NewsTap/5.3.1 (iPad)
Cancel-Lock: sha1:q15Q/6BJUOWucsP4yV7lJDJY3Xg=
sha1:JdOQnUuZZSA8200u/6OMX0FXr8s=

by: Peter Flass - Thu, 29 Feb 2024 00:43 UTC

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

Re: loader

<2CSDN.510315$xHn7.404295@fx14.iad>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=102&group=comp.os.os2.programmer.misc#102

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx14.iad.POSTED!not-for-mail
Subject: Re: loader
Newsgroups: comp.os.os2.programmer.misc
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
<urme2j$3maq2$1@dont-email.me> <E5ODN.131351$STLe.52819@fx34.iad>
<urodmj$4fom$1@dont-email.me>
From: dave.r.yeo@gmail.com (Dave Yeo)
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101 Firefox/45.0
SeaMonkey/2.42.9esr
MIME-Version: 1.0
In-Reply-To: <urodmj$4fom$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 11
Message-ID: <2CSDN.510315$xHn7.404295@fx14.iad>
X-Complaints-To: https://www.astraweb.com/aup
NNTP-Posting-Date: Thu, 29 Feb 2024 03:11:58 UTC
Date: Wed, 28 Feb 2024 19:11:58 -0800
X-Received-Bytes: 1247

by: Dave Yeo - Thu, 29 Feb 2024 03:11 UTC

Paul Edwards wrote:
> Hi Dave.
>
> Thanks for the explanation.
>
> That seems to be missing DOSOPEN as well as others.

Yes it does. Wouldn't be surprised if emximp.exe has problems with
doscall1.dll, perhaps failing with the 16bit exports.
Dave

Re: loader

<uroum2$b500$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=103&group=comp.os.os2.programmer.misc#103

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Thu, 29 Feb 2024 11:46:10 +0800
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <uroum2$b500$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
<urme2j$3maq2$1@dont-email.me> <E5ODN.131351$STLe.52819@fx34.iad>
<urodmj$4fom$1@dont-email.me> <2CSDN.510315$xHn7.404295@fx14.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 29 Feb 2024 03:46:11 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="1e4215355a6b1652a4ea0b1f6d71c2f5";
logging-data="365568"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/iGPV3hAiB3YNcjwUlkW4LxTVtGZLUiGI="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:CiI4e9C+JdfE0rKRR1HP1krsaus=
In-Reply-To: <2CSDN.510315$xHn7.404295@fx14.iad>

by: Paul Edwards - Thu, 29 Feb 2024 03:46 UTC

On 29/02/24 11:11, Dave Yeo wrote:
> Paul Edwards wrote:
>> Hi Dave.
>>
>> Thanks for the explanation.
>>
>> That seems to be missing DOSOPEN as well as others.
>
> Yes it does. Wouldn't be surprised if emximp.exe has problems with
> doscall1.dll, perhaps failing with the 16bit exports.

The string doesn't appear to be in the DLL at
all, unlike e.g. DosWrite().

C:\w2kshare>hexdump DOSCALL1.DLL | grep -i open

C:\w2kshare>hexdump DOSCALL1.DLL | grep -i doso

C:\w2kshare>hexdump DOSCALL1.DLL | grep -i doswr
000410 4F535245 41448900 08444F53 57524954 OSREAD...DOSWRIT

C:\w2kshare>

BFN. Paul.

Re: loader

<7_VDN.355988$vFZa.223110@fx13.iad>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=104&group=comp.os.os2.programmer.misc#104

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.iad.POSTED!not-for-mail
Subject: Re: loader
Newsgroups: comp.os.os2.programmer.misc
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
<urme2j$3maq2$1@dont-email.me> <E5ODN.131351$STLe.52819@fx34.iad>
<urodmj$4fom$1@dont-email.me> <2CSDN.510315$xHn7.404295@fx14.iad>
<uroum2$b500$1@dont-email.me>
From: dave.r.yeo@gmail.com (Dave Yeo)
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101 Firefox/45.0
SeaMonkey/2.42.9esr
MIME-Version: 1.0
In-Reply-To: <uroum2$b500$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <7_VDN.355988$vFZa.223110@fx13.iad>
X-Complaints-To: https://www.astraweb.com/aup
NNTP-Posting-Date: Thu, 29 Feb 2024 07:02:27 UTC
Date: Wed, 28 Feb 2024 23:02:26 -0800
X-Received-Bytes: 1793

by: Dave Yeo - Thu, 29 Feb 2024 07:02 UTC

Paul Edwards wrote:
> On 29/02/24 11:11, Dave Yeo wrote:
>> Paul Edwards wrote:
>>> Hi Dave.
>>>
>>> Thanks for the explanation.
>>>
>>> That seems to be missing DOSOPEN as well as others.
>>
>> Yes it does. Wouldn't be surprised if emximp.exe has problems with
>> doscall1.dll, perhaps failing with the 16bit exports.
>
> The string doesn't appear to be in the DLL at
> all, unlike e.g. DosWrite().

os2386.lib and os2286.lib seem to point it as being in doscalls. I also
see it in the kernel's sym file, on the ISO under \os2\image\debug are
the half strict kernels and corresponding sym etc files. No experience
with them.
It's all learning for me with some stuff I thought I knew being wrong it
seems.
Dave

Re: loader

<urr367$rp2f$1@dont-email.me>

copy mid

https://news.novabbs.org/devel/article-flat.php?id=105&group=comp.os.os2.programmer.misc#105

copy link Newsgroups: comp.os.os2.programmer.misc

Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mutazilah@gmail.com (Paul Edwards)
Newsgroups: comp.os.os2.programmer.misc
Subject: Re: loader
Date: Fri, 1 Mar 2024 07:15:14 +0800
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <urr367$rp2f$1@dont-email.me>
References: <ur1mqi$2ddfu$1@dont-email.me> <urc5jb$12sfb$1@dont-email.me>
<urc6so$133ut$1@dont-email.me> <urc9ed$13job$1@dont-email.me>
<urd1vu$18mln$1@dont-email.me> <urggi7$24i42$1@dont-email.me>
<1555304872.730765612.509768.peter_flass-yahoo.com@news.eternal-september.org>
<urme2j$3maq2$1@dont-email.me> <E5ODN.131351$STLe.52819@fx34.iad>
<urodmj$4fom$1@dont-email.me> <2CSDN.510315$xHn7.404295@fx14.iad>
<uroum2$b500$1@dont-email.me> <7_VDN.355988$vFZa.223110@fx13.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 29 Feb 2024 23:15:19 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="1f04345046046ea4eb841c70e7979180";
logging-data="910415"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1UkFTou3bQ0ZkPKG3m5PzamJVd2FBK0I="
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:5AD8gqf9fbu2FvuAlkMsY/M1onY=
In-Reply-To: <7_VDN.355988$vFZa.223110@fx13.iad>

by: Paul Edwards - Thu, 29 Feb 2024 23:15 UTC

On 29/02/24 15:02, Dave Yeo wrote:
> Paul Edwards wrote:
>> On 29/02/24 11:11, Dave Yeo wrote:
>>> Paul Edwards wrote:
>>>> Hi Dave.
>>>>
>>>> Thanks for the explanation.
>>>>
>>>> That seems to be missing DOSOPEN as well as others.
>>>
>>> Yes it does. Wouldn't be surprised if emximp.exe has problems with
>>> doscall1.dll, perhaps failing with the 16bit exports.
>>
>> The string doesn't appear to be in the DLL at
>> all, unlike e.g. DosWrite().
>
> os2386.lib and os2286.lib seem to point it as being in doscalls.

Sure - that's for linking purposes, where it MUST
get resolved to an ordinal, because the DLL doesn't
have the name information (it seems). Which was the
query.

Regardless, I wasn't able to get to the code yesterday,
but fortunately I received a code change from Slovakia
overnight that should make loading much more robust,
and I will try it out today hopefully and hopefully
fill in the missing functionality to get the pdptest
program (makefile.wat), including parameters, working.

Or find out that I am missing some concept.

> I also
> see it in the kernel's sym file, on the ISO under \os2\image\debug are
> the half strict kernels and corresponding sym etc files. No experience
> with them.
> It's all learning for me with some stuff I thought I knew being wrong it
> seems.

Ok. :-)

BFN. Paul.

devel / comp.os.os2.programmer.misc / Re: loader

server_pubkey.txt

rocksolid light 0.9.81
clearnet tor