Re: work underway: Dependency on openal incoming
Charles Davis 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 julli...@winehq.org
Re: work underway: Dependency on openal incoming
Alexandre Julliard wrote: > Maarten Lankhorst 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
Re: work underway: Dependency on openal incoming
Maarten Lankhorst 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 julli...@winehq.org
Re: work underway: Dependency on openal incoming
Hello Alexandre, Alexandre Julliard schreef: Maarten Lankhorst 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
Re: work underway: Dependency on openal incoming
Maarten Lankhorst 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. -- Alexandre Julliard julli...@winehq.org
work underway: Dependency on openal incoming
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
