Re: [hatari-devel] TOS use of PRG_ssize vs Hatari's

[Troed Sångberg <troed@xxxxxxxxxxx>]

Hi Thorsten,

You might be right in that the value is always negative if seen as a signed 32 bit int. At least that's true for the values that are already in the original programs as distributed - but they will then change depending on the system parameters when first run on a user's system.

DXTX/DX7.DAT/DX7.BIT:

b0fe83ca

D10_MT32/D10.DAT/D10.BIT:

fe1b1ef6

WAVSTN/WS.DAT/WS.BIT:

b0fe7b50

D50/D50.DAT/D50_B.BIT:

b0fe80e7

K1/K1.DAT/K1_B.BIT:

b0fe747e

M1/M1.DAT/M1.BIT:

b0f96a8e

These are the original values of PRG_ssize from the six Synthworks applications that all use this technique.

I haven't verified if lseek throws an error or whether it just seeks to EOF. I have however verified that the relocation table seems to be where you end up with a zeroed out PRG_ssize, so the intended behavior matches that.

regards,

Troed

------- Original Message -------
On Saturday, October 21st, 2023 at 2:20 PM, Thorsten Otto <admin@xxxxxxxxxxx> wrote:

On Samstag, 21. Oktober 2023 12:26:08 CEST Troed Sångberg wrote:

> So, this seems to be an extremely unknown (ab)use of TOS specific behavior

> than nonetheless is part of released commercial software.

Yes, it only works by chance, because the offset passed to lseek is invalid, but the error code is ignored in Pexec. But the emulation fails because it calculates an invalid memory address.

Of course you could easily fix the emulation, by checking the symbol table length either for that specific value (if it is always the same), or for being negative, and ignore it in that case.