SDL_dll.h?

Just curious about the lack of this module. Win32 and UNIX have similar DLL
open/close and (function) symbol retrieval syntax. It would be nice to have
this abstraction included in an OS abstraction toolkit such as SDL rather
than coding it for one’s own projects.

I’m not sure how easy this would actually be, given that I know nothing
about the large number of other OS flavors this beastie runs on, but thought
I’d ask if this had been previously considered and discarded.

Thanks,
– Jeff

it is plan for SDL 1.3 (i have heard…)
anyway a quick fix could be:

void * SDL_LoadLibrary(char * name)
{
#ifdef WIN32
return LoadLibrary(name);
#else
return dlopen(name, 0);
#endif
}

void SDL_CloseLibrary(void * handle)
{
#ifdef WIN32
return FreeLibrary(handle);
#else
return dlclose(handle);
#endif
}

void SDL_FindSymbol(void * handle, char * sym)
{
#ifdef WIN32
return GetProcAddress(handle, sym);
#else
return dlsym(handle, sym);
#endif
}

Just curious about the lack of this module. Win32 and UNIX have similar DLL
open/close and (function) symbol retrieval syntax. It would be nice to have
this abstraction included in an OS abstraction toolkit such as SDL rather
than coding it for one’s own projects.

There are actually a whole host of hidden issues with this that I might
as well expound upon since I’m thinking of it.

As somebody else mentioned, the basic interface is very simple:

  1. open library handle
  2. retrieve pointer to function
  3. call function
  4. close library handle

Here are the issues that may bite you, depending on the platform(s)
you want your code to work on:

  1. Calling convention, ABI issues:
    Do the functions in the library you’re linking with use the same
    calling convention as the application code? If not, does the
    application code know what the proper calling convention is?

    Do they use the same ABI? If the function names are mangled
    (a-la C++), does the compiler that mangled them use the same
    convention as the compiler that built the application?

    To keep things simple, and avoid these kinds of issues, you can
    use only C functions with the stdcall calling convention and most
    code that can load shared objects will be able to deal with it.

  2. Runtime environment:
    Do the functions in the library use the same runtime as your
    application? If they don’t, your application may load a runtime
    environment that may clash with the one (possibly separately
    loaded) by the shared object. The simplest example of this is
    where the application and the shared object are linked with
    different version of the C library - they may conflict.

  3. Namespace collisions and other issues:
    A shared object isn’t usually self contained. Especially when
    writing a driver module, the code will call functions that are
    not wholly contained within the shared object. Even if they are,
    it’s not always defined which symbol is used by your code if the
    same symbol is included in both the shared object and the main
    application, or even another separately loaded shared object.

    The safest way to avoid namespace collisions is to use a unique
    prefix for all symbols in a shared object, and then pass in a
    versioned context to the library that contains pointers to all
    the external functions that will be referenced by the code. This
    is the method used by the quake engine, BTW. It works, but can
    get very cumbersome for general purpose object code.

These are all hidden pitfalls in using general purpose object loading
code, and they should be considered by anyone using it. It’s not to
say that you shouldn’t dynamically loaded code, but be very careful
about the conditions under which you do.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Just wanted to thank you for the post identifying issues in DLL design. I
now know more about namespace collision issues than I did before -
particularly the nasty shared symbol resolution issue, which I think I’ve
seen symptoms of in a previous iteration of my graphics engine. I’ll be
better equipped to handle this with the new revision…

Thanks!
– Jeff

Hello,

I am just wondering if it is possible to make more then once screen when
using SDL? So you can have a main screen and loop, then spawn a smaller
screen(like a dialog). Is this possible?–
Jordan Wilberding <@Jordan_Wilberding>
Diginux.net Sys Admin

<wod.sourceforge.net>
<aztec.sourceforge.net>

“Fight war, not wars,
destroy power, not people”
-Crass

The SDL is an abstraction of a frame buffer … it is not a windowing
system. But as you have complete control of the frame buffer there is
nothing stopping you from drawing a dialog box onto it.

Shane
At 12:04 PM 11/19/2001 -0600, you wrote:>Hello,

I am just wondering if it is possible to make more then once screen when
using SDL? So you can have a main screen and loop, then spawn a smaller
screen(like a dialog). Is this possible?


Jordan Wilberding
Diginux.net Sys Admin

<wod.sourceforge.net>
<aztec.sourceforge.net>

“Fight war, not wars,
destroy power, not people”
-Crass


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

No. Calling SDL_SetVideoMode would destroy the old display and create a new one.
This is a way to switch from windowed mode to fullscreen (or the other way round),
to change resolutions, the color depth, and to enable OpenGL or the evil OPENGLBLIT
at runtime.On Mon, Nov 19, 2001 at 12:04:30PM -0600, Jordan Wilberding wrote:

Hello,

I am just wondering if it is possible to make more then once screen when
using SDL? So you can have a main screen and loop, then spawn a smaller
screen(like a dialog). Is this possible?