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.
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:
open library handle
retrieve pointer to function
call function
close library handle
Here are the issues that may bite you, depending on the platform(s)
you want your code to work on:
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.
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.
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…
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
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?
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?