Running legacy game

Hey there,

I am trying to to run Hopkins FBI, an old (1999) closed source adventure game
[1], but without much success. Surprisingly, I can’t find any website that
mentions any problems (they are all old info)… The static binary uses some
SDL version that errors when calling some X call. The dynamic binary
complains of stuff like:
?Could not initialize SDL: Failed loading
_SDL_Flip: /usr/lib/libSDLx11.so.0.9: undefined symbol: _SDL_Flip?
(I did a sym link from 1.2.10 to that file)

So, I have added a wrapper from _SDL_Flip to SDL_Flip and the same for a lot
more calls the linker complained about, to the latest SDL source. (Had to
disable the gcc visibility flag on that file I added them to, of course.) Do
you know why the hack they have used a _SDL prefix?

Anyway, there are some calls that no longer exist (it seems it uses SDL
0.9.9)… I can’t wrapper them because the linker just tells me the function
name, so I can’t know their parameters. Where can I get such an old version?
Btw, those obsolete functions are: SDL_LockSO, SDL_FPLoadWAV,
SDL_CalculateEndian, SDL_SymToASCII, SDL_CreateColorCursor, SDL_FPLoadBMP,
SDL_FPSaveBMP, and SDL_SetClipping.

Btw, it makes me angry that they didn’t comply with the SDL library. They
don’t ship the object code of the game, which I believe to be against of the
LGPL and will make it harder to make a patch for others to use:
?If you link other code with the library, you must provide complete object
files to the recipients, so that they can relink them with the library after
making changes to the library and recompiling it.?
Can you guys do something about it?

Thanks you so much,
Ricardo

[1] http://hopkinsfbi.com/

disable the gcc visibility flag on that file I added them to, of course.) Do
you know why the hack they have used a _SDL prefix?

Is it an a.out format binary and not ELF?

–ryan.

[…]

Do you know why the hack they have used a _SDL prefix?

This is standard name mangling for exported symbols in shared
libraries on some versions of some platforms - and I believe it’s the
standard on Linux as well. You wouldn’t be able to tell normally, as
the name mangling should be done automatically, one way or another,
as long as you’re linking rather than loading “manually”.

You can have a look at the SDL_LoadFunction() implementations (at
least in SDL 1.3) for various platforms to get an idea of the
differences. SDL_LoadFunction() does name mangling on the fly so you
can just use the base names regardless of platform.

Where can I get such an old version?

Can’t seem to find it, and libsdl.org is practically dead ATM, so it’s
kind of hard to take a quick look around there…

Btw, those obsolete functions are: SDL_LockSO, SDL_FPLoadWAV,
SDL_CalculateEndian, SDL_SymToASCII, SDL_CreateColorCursor,
SDL_FPLoadBMP, SDL_FPSaveBMP, and SDL_SetClipping.

Most links are dead, but there seems to be some SDL 0.9 API
documentation here:
http://kiev.travel.ch/doc/packages/sdldev/docs/index.html

Btw, it makes me angry that they didn’t comply with the SDL
library. They don’t ship the object code of the game, which I
believe to be against of the LGPL and will make it harder to make a
patch for others to use:
?If you link other code with the library, you must provide complete
object files to the recipients, so that they can relink them with
the library after making changes to the library and recompiling it.?
Can you guys do something about it?

AFAICT, it’s perfectly ok. They’re obviously linking dynamically, or
SDL 0.9 would have been physically included in the executable, and
you wouldn’t have any chance at all to do anything about it. (Well,
there is always the option of disassembling the executable and
hacking away at the asm code… However, that’s usually both hard and
supposedly illegal.)

The object code would have made no difference here. You’d need the
source to do anything about it using the SDL 0.9 API - and the LGPL
doesn’t require that the source of dynamically linked code is
released.

I don’t see what the problem is here. It’s using the SDL 0.9 API, and
it’s dynamically linked, so you can provide a custom implementation
of that API, or a different version of SDL. APIs change, and there’s
no trivial way around the resulting incompatibilities, even if you
have the full source code of everything.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Saturday 13 January 2007 23:32, Ricardo Cruz wrote:

Ryan C. Gordon wrote (@ Saturday, 13 de January de 2007 23:05):

disable the gcc visibility flag on that file I added them to, of course.)
Do you know why the hack they have used a _SDL prefix?

Is it an a.out format binary and not ELF?

No idea. =) How can I check that?

David Olofson wrote (@ Sunday, 14 de January de 2007 00:50):

[…]

Do you know why the hack they have used a _SDL prefix?

This is standard name mangling for exported symbols in shared
libraries on some versions of some platforms - and I believe it’s the
standard on Linux as well. You wouldn’t be able to tell normally, as
the name mangling should be done automatically, one way or another,
as long as you’re linking rather than loading “manually”.

You can have a look at the SDL_LoadFunction() implementations (at
least in SDL 1.3) for various platforms to get an idea of the
differences. SDL_LoadFunction() does name mangling on the fly so you
can just use the base names regardless of platform.

I had already noticed that call because the error message is identical. But
it didn’t seem to get called from my test… I might have missed something
though, so thanks for the info.

Where can I get such an old version?

Can’t seem to find it, and libsdl.org is practically dead ATM, so it’s
kind of hard to take a quick look around there…

Btw, those obsolete functions are: SDL_LockSO, SDL_FPLoadWAV,
SDL_CalculateEndian, SDL_SymToASCII, SDL_CreateColorCursor,
SDL_FPLoadBMP, SDL_FPSaveBMP, and SDL_SetClipping.

Most links are dead, but there seems to be some SDL 0.9 API
documentation here:
http://kiev.travel.ch/doc/packages/sdldev/docs/index.html

Thanks! Unfortunately, these calls are not documented; SDL_LockSO,
SDL_FPLoad/Save* and SDL_CalculateEndian :(. Doesn’t anyone please have a SDL
~0.9.9 copy around that could provide me?

Thank you,
Ricardo> On Saturday 13 January 2007 23:32, Ricardo Cruz wrote:


A candidate is a person who gets money from the rich and votes from the
poor to protect them from each other.

disable the gcc visibility flag on that file I added them to, of course.)
Do you know why the hack they have used a _SDL prefix?
Is it an a.out format binary and not ELF?

No idea. =) How can I check that?

Probably the “file” command will tell you.

file /path/to/binary

a.out format prefixed every symbol with an underscore…it’s not that
they added it themselves, but everything that passed through the
compiler got it added.

I’m not sure if you can mix ELF libraries and a.out binaries…maybe you
can, but you might need to do more than just build SDL 0.99 to run that
thing.

If you can find someone to contact over there, send them to me and I’ll
be happy to update the Hopkins FBI binaries for modern distros if they
like. But last I heard, no one reads the email addresses posted on their
website, though.

–ryan.

Ryan C. Gordon wrote (@ Tuesday, 16 de January de 2007 19:16):

disable the gcc visibility flag on that file I added them to, of
course.) Do you know why the hack they have used a _SDL prefix?

Is it an a.out format binary and not ELF?

No idea. =) How can I check that?

Probably the “file” command will tell you.

file /path/to/binary

Ok. It is an ELF it seems:

rick2 at docelar:~> file /usr/local/hopkinsfbi/Hopkins.bin
/usr/local/hopkinsfbi/Hopkins.bin: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), not stripped

It seems they are loading stuff via dlopen().

[…]

I’m not sure if you can mix ELF libraries and a.out binaries…maybe you
can, but you might need to do more than just build SDL 0.99 to run that
thing.

Well, I don’t know the signature of the obsolete SDL function, but by filling
them with garbage I managed that SDL_Init is called and all. The game even
opens the window before it crashes (when an obsolete function is called I
presume).

If you can find someone to contact over there, send them to me and I’ll
be happy to update the Hopkins FBI binaries for modern distros if they
like. But last I heard, no one reads the email addresses posted on their
website, though.

I mailed their support address. It bounced. :frowning:

Thanks for the help; I think I can get this solved if I get my hands on a
copy of SDL 0.9.9. (Please, check if you have it in your hard disk or
something. :))

See ya,
Ricardo> --ryan.


God is not dead! He’s alive and autographing bibles at Cody’s

El Jueves, 18 de Enero de 2007 20:31, Ricardo Cruz escribi?:

rick2 at docelar:~> file /usr/local/hopkinsfbi/Hopkins.bin
/usr/local/hopkinsfbi/Hopkins.bin: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), not stripped

?It seems they are loading stuff via dlopen().

Beware that “dynamically linked” doesn’t mean that the program necessarily
uses dlopen().

Maybe you also get help from the output of this command:

ldd /usr/local/hopkinsfbi/Hopkins.bin

it lists the dynamic libraries an executable is linked to.

Alberto