[SDL] Dynamically loading SDL dlls

[Ryan C. Gordon]

> its a specific problem, yes, but it is rather a problem of bad support by the 
> operating system. afaik windows seems to know only one way of dynamically 
> loading a library (LoadLibrary from a file) - and thats very limited. what about 
> loading dlls from a resource? what about loading dlls over the internet to a 
> memory buffer and starting the dll from that place? why is such basic stuff not 
> supported directly by some standard system library?

I suspect this isn't the specific problem...I suspect LoadLibrary() 
would work for him if he wanted to expend the tedious effort to load all 
the symbols he needs, but mostly he wants the OS to find the DLL so it 
can handle symbol resolution for him. That being said...

Having a need to load .dlls in a .zip file, I couldn't find a way to 
load a .dll from a memory buffer on any OS.

dlopen() wants a filename; you can sort of get around this by writing to 
a temp dir (extra credit if it's a ramdisk like /dev/shm), loading the 
library, then unlinking the inode immediately, but it still requires a 
write to the filesystem if not a physical disk, and if your system 
crashes at the wrong moment, it may leave a file there...but once it 
runs, it's more or less working from a memory-only copy of the library.

A similar tapdance works on Windows; you can't delete the file before 
the library handle is closed, but you can open it with CreateFile()'s 
FILE_FLAG_DELETE_ON_CLOSE flag to clean up. Probably also leaves a file 
if there's a bluescreen before your application ends. The dlopen() 
window is much smaller at fractions of a second, but same problem. 
Google around Dr. Dobbs Journal for the code to do this...you have to do 
a few delicate things to make sure it works across all Windows variants.

Mac OS X and BeOS all fared similarly with their system-specific APIs.

If these systems could use a memory buffer, then I could feed it from an 
.exe resource or a .zip file entry or whatever. None of them do.

I _have_ seen userland code for Windows that parses a DLL in memory, 
basically replicating LoadLibrary()...more or less, this is what Wine 
does on Linux...but I bet that'll break someday when the compiler or the 
OS changes slightly, so I wouldn't trust my app to include that code.

--ryan.