Alexandre Julliard wrote:
Maarten Lankhorst m.b.lankhorst@gmail.com writes:
Hello Alexandre,
Alexandre Julliard schreef:
Openal missing at compile time or at runtime should be handled the same way, i.e. by reporting no sound devices. It doesn't make sense to have two different failure modes.
Mac OSX can only link directly to openal with -framework OpenAL, so dynamic linking is impossible. As a result dsound will fail to load if libopenal is missing. I don't think there is a better way to handle this without ugliness, I'm confident that all distributions are shipping a version of openal these days, even the 64-bits ones.
I don't see why you couldn't dynamically load a framework,
You can. The "proper" way to do this is to use the CFBundle API. First you need to find the framework. Typically, it's in /System/Library/Frameworks, but the user might have a custom OpenAL in /Library/Frameworks or in $HOME/Library/Frameworks. Then we tack on the name of the framework we want, and create a CFURL object with the finished path. We can pass this to CFBundleCreate() to get a bundle object back. Then, we can use CFBundleLoadExecutable() to load the bundle into memory. You can use CFBundleGetFunctionPointerForName() and CFBundleGetFunctionPointersForNames() to extract function pointers from the bundle, and when you're done with it, you can use CFBundleUnloadExecutable(), followed by a CFRelease(), to close the bundle.
The other way to do this is to use wine_dlopen() on the framework executable, which is typically a file with the same name as the framework in the framework directory (so, for OpenAL, it would be a file named "OpenAL" in the "OpenAL.framework" directory). Then we can just use wine_dlsym() to extract function pointers like any other dynamic library. You still have to find the framework, though, which again is usually in one of the standard directories.
If you want, I can write you some functions that will do all this for you.
Chip