OpenAL32 dll thunk test - wine-devel

14 May 2007


      After the previous attempt by Nick Burns was more or less abandoned, I decided 
to try making an acceptable version myself. This is the current result.
I used the original version Nick had and got rid a lot of the macro abuse. It 
still uses macros to declare/define and load the functions, but it isn't 
nearly as bad as it was. I know AJ isn't very thrilled with macro use, but I 
believe the current method is a nice balance between flexibility and clarity.
Note that this IS NOT FINISHED. It should be good enough to work, however. The 
main reason for this is to get some testing to make sure it works as expected 
on other machines (especially OSX). The things I still need to work on are:
a) Skip building the DLL if OpenAL headers aren't found on the system 
durring ./configure (any autotools experts want to help?)
b) Properly handle the autotools stuff (any autotools experts want to help?)
c) Fix up extension handling to use al[c]GetProcAddress instead of dlsym (for 
the sake of being proper; I don't believe this would pose a problem 
currently)
The OpenAL lib is dynamicly loaded, so the lib doesn't need to be present when 
building. If the lib is not present when the DLL is loaded however, then the 
DLL will fail to load. Because of this, it might be a good idea to include 
OpenAL headers with Wine, so they will always be available to build the DLL 
with (the headers are LGPL licensed, AFAIK). Won't have to worry about 
skipping building or configure checking that way.
On my Linux machine, the OpenAL 1.1 SDK demos work*. I'm curious about how 
they work for other people on other machines, and for other apps.
* Not quite true. EnumerateWin32.exe doesn't wait for a key press before 
exiting, and OpenALDemo.exe won't wait for key presses when trying to pick a 
test (it loops endlessly on the "main menu"). These problems are not related 
to OpenAL. PlayStaticWin32.exe and PlayStreamWin32.exe both work perfectly, 
and EnumerateWin32.exe does do what it's supposed to, with the exception of 
the wait-for-key-before-exit problem.
Note that if you're using the Sample Implementation, you must get a recent (as 
in today/yesterday) SVN checkout of it. It was missing a couple somewhat 
obscure 1.1 functions I sent in a patch for and got applied.
After patching, you'll need to run autoconf (or autogen if you use that 
script) to generate a new configure. Reconfigure, then rebuild Wine.
PS. I did get permission from Nick before posting this as I used 
his "un-licensed" patch as a starting point. It's all okay with him.
PPS. I know not everyone likes the idea of this thunk, because the native 
implementations aren't "up to par" with the Windows version that backends on 
DSound. However, the only way they'll get better is with use (they've already 
got several patches from me because of this thunk, with more pending, and 
more in planning), and if worse comes to worse, you can use a DLL override to 
use the Windows native OpenAL. Creative is planning on releasing hardware 
OpenAL Linux drivers for some of their cards later this year, and this would 
be the best way to take advantage of them.