Dynamic loading of SDL.dll in another dll

SDL Development
1

Hi everyone.

First a quick question: Is the [SDL] part of the subject insertet by
the mailinglist system, or should I do this myself? I inserted it
manually in this mail.

Now to the real problem.

I am building a dll for use on windows, which uses SDL throgh a dll.
My dll is also using a 3rd party library (dll), which in turn also
uses SDL through a dll. This 3rd party dll is dynamicly linked to SDL
through SDL.lib version 1.2.4 and is not open source.
The idea is that the user of the 3rd party library should do some SDL
stuff, and then the library does the rest. In the specific application
(programming psychological experiments which uses control of
eyetracker-equipment) this actually makes sense.

My dll is intended to automate the rest of the SDL stuff and some
other eyetracker stuff.
It is a plugin for a generel psychological experiment tool called
Eprime, which loads the plugins dll with a LoadLibrary call.

Everything works fine, except that there is a bug in SDL 1.2.4 which
is suupplied with the 3rd party library. So I would like to upgrade
SDL to 1.2.8.

But when programs loads my dll it fails after the SDL upgrade, with a
error of not finding a SDL function entrypoint:
“The procedure entry point SDL_SetVideoModeEx could not be located in
the dynamic link library SDL.dll.”

In the errorreport, the module failing is the Main program. So if this
errorreport is worth anything, one would think that it is the
mainprogram that cant figure out the sdl.dll.

I tried to reproduce the problem, through my own test dlls, however I
recognize that the reconstruction is not excact. The reconstruction
did not have this problem.

I cannot figure out why this loading error occurs. Can you?
Any ideas on how to fight this problem?

I use VC6 updated with latest servicepacks (sp3).

Thanks in advance
-Martin

Below is a schematic of the three situations: My way, third party way
and my test way.
I can use any combinations of SDL.dll and SDL.lib in any version, in
all the situations, except the second. (This schematic should be seen
with a monotype font).
The second only works when SDL 1.2.4 is installed on the system,
nomatter what version of SDL.lib is used.

  1. The way My dll is meant to be used
    Working with sdl 1.2.4 on system but not with 1.2.8-----------------
    | Main program |
    | |
   |

LoadLibrary(My_dll)
|

| My_dll |___________
| | |
----------------- |
| |
3rd_party.lib sdl_1.2.8/4.lib
| |

| 3rd party dll | |SDL 1.2.8/4 dll|
| | | |

   |

sdl_1.2.4.lib
(done by 3rd party)
|

|SDL 1.2.8/4 dll|
  1. The way 3rd party dll is meant to be used
    Working with both sdl 1.2.4 and 1.2.8 on system

| Main program |___________
| | |
----------------- |
| |
3rd_party.lib sdl_1.2.8/4.lib
| |

| 3rd party dll | |SDL 1.2.8/4 dll|
| | | |

   |

sdl_1.2.4.lib
(done by 3rd party)
|

|SDL 1.2.8/4 dll|

3 .Attempt to reconstruct problem
Working with both sdl 1.2.4 and 1.2.8 on system

| Main program |

 
   |

LoadLibrary(My_test_dll)
|

| My test dll |___________
| | |
----------------- |
| |
sdl_1.2.4.lib sdl_1.2.8/4.lib
(Done by me) |

|SDL 1.2.8/4 dll| |SDL 1.2.8/4 dll|
| | | |

2

Hi everyone.

First a quick question: Is the [SDL] part of the subject insertet by
the mailinglist system, or should I do this myself? I inserted it
manually in this mail.

The server will insert it automatically, if it isn’t already there.

[…]

Everything works fine, except that there is a bug in SDL 1.2.4 which
is suupplied with the 3rd party library. So I would like to upgrade
SDL to 1.2.8.

There; that’s a perfect, real world example of what the (sometimes
annoying) linking/object files clause in the LGPL is about. :slight_smile:

But when programs loads my dll it fails after the SDL upgrade, with
a error of not finding a SDL function entrypoint:
“The procedure entry point SDL_SetVideoModeEx could not be located
in the dynamic link library SDL.dll.”

Uh oh… Sounds like they’re using a modified version of SDL. AFAIK,
no official version has a call named SDL_SetVideoModeEx.

Now, unless someone is violating the LGPL, you should be able to get
the source code for that modified version of SDL 1.2.4, so you can
port the modifications and build a custom SDL 1.2.8 DLL that should
work.

I tried to reproduce the problem, through my own test dlls, however
I recognize that the reconstruction is not excact. The
reconstruction did not have this problem.

Of course not. :slight_smile: (I assume you didn’t call any function that are not
available in the official SDL.)

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 02 February 2005 17.26, Martin Lange wrote:

3

Hi again

Sorry about the direct mail to you David. This mailsystem cheated me.

Hi everyone.

First a quick question: Is the [SDL] part of the subject insertet by
the mailinglist system, or should I do this myself? I inserted it
manually in this mail.

The server will insert it automatically, if it isn’t already there.
ok.

[…]

Everything works fine, except that there is a bug in SDL 1.2.4 which
is suupplied with the 3rd party library. So I would like to upgrade
SDL to 1.2.8.

There; that’s a perfect, real world example of what the (sometimes
annoying) linking/object files clause in the LGPL is about. :slight_smile:

But when programs loads my dll it fails after the SDL upgrade, with
a error of not finding a SDL function entrypoint:
“The procedure entry point SDL_SetVideoModeEx could not be located
in the dynamic link library SDL.dll.”

Uh oh… Sounds like they’re using a modified version of SDL. AFAIK,
no official version has a call named SDL_SetVideoModeEx.

Thats an interresting point. A quicksearch in the SDL code proves you
right. That “Ex” also sounded very MS-like to me.
I actually suspected something like this a while ago, but the
exampleprograms supplied with the 3rd. party dll works fine after an
upgrade, so I thought my suspecion was wrong.
Now its back again for sure!
After a quick thinking, I think that I actually uses the
SDL_SetVideoMode different than they do in their examples. Could be
why mine does not work when their does.
Actually its simple to test if they use a modified version. If I
exchange the supplied SDL 1.2.4 with an original 1.2.4 the same
problem shoul occur, right?

More on that tomorrow.On Wed, 2 Feb 2005 17:45:12 +0100, David Olofson wrote:

On Wednesday 02 February 2005 17.26, Martin Lange wrote:

Now, unless someone is violating the LGPL, you should be able to get
the source code for that modified version of SDL 1.2.4, so you can
port the modifications and build a custom SDL 1.2.8 DLL that should
work.

I tried to reproduce the problem, through my own test dlls, however
I recognize that the reconstruction is not excact. The
reconstruction did not have this problem.

Of course not. :slight_smile: (I assume you didn’t call any function that are not
available in the official SDL.)

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

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

4

Martin Lange wrote:
[…]

But when programs loads my dll it fails after the SDL upgrade, with
a error of not finding a SDL function entrypoint:
“The procedure entry point SDL_SetVideoModeEx could not be located
in the dynamic link library SDL.dll.”

Uh oh… Sounds like they’re using a modified version of SDL. AFAIK,
no official version has a call named SDL_SetVideoModeEx.

[…] If I
exchange the supplied SDL 1.2.4 with an original 1.2.4 the same
problem shoul occur, right?

More on that tomorrow.

Two possibilites:

  1. There was an internally used SDL_SetVideoModeEx in 1.2.4 which was
    not intended for use as part of the API, and was removed in a later version.

  2. They’re using a modified version of 1.2.4, in which case yes the same
    problem should occur.