Groups | Search | Server Info | Login | Register
Groups > comp.os.os2.programmer.misc > #1840
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Newsgroups | comp.os.os2.programmer.misc |
| Subject | loader |
| Date | 2024-02-20 16:10 +0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <ur1mqi$2ddfu$1@dont-email.me> (permalink) |
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.
Back to comp.os.os2.programmer.misc | Previous | Next — Next in thread | Find similar
loader Paul Edwards <mutazilah@gmail.com> - 2024-02-20 16:10 +0800
Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-20 17:45 -0700
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-21 10:51 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 06:14 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 11:38 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 15:24 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 15:46 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 16:30 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 23:30 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 23:28 +0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-26 06:56 +0800
Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-27 15:41 -0700
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-28 12:50 +0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 14:04 -0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-29 06:56 +0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 19:11 -0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-29 11:46 +0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 23:02 -0800
Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-03-01 07:15 +0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 14:20 -0800
Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 13:52 -0800
Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-28 17:43 -0700
csiph-web