Hi all,
This message is mostly aimed towards package maintainers, since one of the discussions at wineconf last year was that package maintainers would like to hear in advance about changing dependencies.
Wine's DirectSound implementation will, in the next release or the release after that, rely on OpenAL, the recommended library for linux or bsd's is openal-soft, and preferably a recent version, as old versions might miss certain experimental extensions that dsound will need. Mac users shouldn't need an external openal library, since it has its own openal implementation.
Without openal at compile-time, dsound will still build, but report no sound devices found. Some games or other applications may refuse to run if no dsound devices are found, so its recommended that you build with openal. If openal is compiled in, but missing at runtime, dsound.dll will refuse to load, which probably means most games will not run either.
Cheers, Maarten
Maarten Lankhorst m.b.lankhorst@gmail.com writes:
Without openal at compile-time, dsound will still build, but report no sound devices found. Some games or other applications may refuse to run if no dsound devices are found, so its recommended that you build with openal. If openal is compiled in, but missing at runtime, dsound.dll will refuse to load, which probably means most games will not run either.
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.
Hello Alexandre,
Alexandre Julliard schreef:
Maarten Lankhorst m.b.lankhorst@gmail.com writes:
Without openal at compile-time, dsound will still build, but report no sound devices found. Some games or other applications may refuse to run if no dsound devices are found, so its recommended that you build with openal. If openal is compiled in, but missing at runtime, dsound.dll will refuse to load, which probably means most games will not run either.
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.
Cheers, Maarten
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, but in any case my point still stands, the failure mode should be the same for compile time vs. run time. Failing to load completely on Mac OS would be acceptable if there's no alternative, but we can do better on other platforms.
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
Charles Davis cdavis@mymail.mines.edu writes:
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.
The point is to be able to use the same code on all platforms. If we have to replicate the loader implementation by hand then we don't gain anything, it will still be a mess of MacOS-specific ifdefs.
-
Alexandre Julliard -
Charles Davis -
Maarten Lankhorst