June 2006 - Wine-Devel - list.winehq.org

Prospects of an OpenAL audio driver...
by Nick Burns June 8, 2006

June 8, 2006

I have started work on an openal driver for wine... So far I have playback and recording working (with minor issues) (for some reason the DSound HEL is unhappy with my driver) OpenAL seems to have enough functionality to do the job. Are there any problems with using OpenAL for such a purpose? - Nick

3 7

Feedback requested for Mac OSX x86 stack patch
by Nick Burns June 8, 2006

June 8, 2006

(notes are at the top of the patch) I would like some feedback on my stack fix patch I do not know how it interacts with linux -- no access to a linux box This has been confirmed to fix numerous app issues (due to stack alignment) I am starting to think it would be better to have these options configured at config time -- e.g. If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer Any ideas/thoughts? - Nick

3 12

Feedback requested for Mac OSX x86 stack patch -- #2
by Nick Burns June 8, 2006

June 8, 2006

Ok I have fixed up my Mac OSX stack patch a bit as per the feedback -- thanks much This only patches windef.h There still needs to be some solution for msvcrt AND any other api entry points that are not denoted with __stdcall or __cdecl or WINAPI or WINAPIV.... This means that Morrowwind (uses msvcrt:pow just cause) will crash on OSX atm (bad alignment) - Nick

2 2

Feedback requested on an OpenAL audio driver patch -- #2
by Nick Burns June 8, 2006

June 8, 2006

Ok I fixed up my OpenAL driver as per the suggestions (thanks much) I am not sure how to use or test pkg-config (does that exist on Mac OSX?) The differences with the OpenAL driver patch... 1. It has a perty ChangeLog diff 2. configure.ac now checks for AL/al.h (which is where OpenAL should be) 3. dlls/Makefile.in should patch correctly now (I did not hand edit it this time -- still crossing fingers) 4. FIXME's -> ERR's for the legit OpenAL errs 5. alcCloseDevice in OpenAL 1.0 (no return value) in 1.1 it returns a boolean -- .: I dont check the boolean anymore -- meaning this error is now slient - Nick

2 2

Re: Linux noob
by Molle Bestefich June 8, 2006

June 8, 2006

Peter Beutner wrote: > Because it is the defacto standard to store settings > under ~/.<appname>. Only for stuff that's thought to be generally uninteresting. Your KDE desktop, for example, resides under ~/Desktop. > And with enough applications installed that use this "standard" > you probably will be glad that these directories are hidden so that > you don't have to scroll through them every time you open > your filemanager ;). I'm annoyed that .wine is inaccessible through KDE and Gnome apps. Not through the file manager, but often in various applications. It's not wine's fault per se that those apps lack a "show hidden folders" option, but it would be nice to make wine visible, as it contains useful stuff that you'll often mangle with. (I personally have a symlink from "wine" to ".wine"...) I do agree that there's too many applications dumping various .xxxxxx folders in my home directory. The least they could do is to put those files somewhere where they don't interfere with my user data, someplace sane like ~/Application Data/xxxxxx, or a more unixy ~/appdata/xxxxx... (Never cared much for hidden folders - they're a symptom that you're being too careless with your directory structure.)

6 13

Re: [MAPI32 2/3] interface IProfAdmin & its 12 methods, function MAPIAdminProfiles implemented
by Alexandre Julliard June 8, 2006

June 8, 2006

argentum(a)office.etersoft.ru writes: > +/************************************************************************** > + * IProfAdmin_GetLastError > + * > + * PARAMS > + * hResult [I] HRESULT data type containing the error value > + * generated in the previous method call. > + * lppMAPIError [O] Pointer to a pointer to the MAPIERROR structure > + * containing version, component, and context information > + * for the error. The lppMAPIError parameter can be set > + * to NULL if there is no MAPIERROR structure to return. > + * ulFlags [I] Bitmask of flags that controls the type of the string > + * pointed to by lpszProfileName. The following flag can be set: > + * 0 The strings in the structure returned in the pointer parameter > + * are in ANSI format > + * MAPI_UNICODE The structure's strings are in Unicode format. > + * RETURNS > + * S_OK The call succeeded and has returned the expected value or values. > + * MAPI_E_BAD_CHARWIDTH Either the MAPI_UNICODE flag was set and the implementation > + * does not support Unicode, or MAPI_UNICODE was not set and the > + * implementation only supports Unicode. > + */ Copying text from MSDN is not acceptable. If you are going to write documentation you have to do it in your own words, without looking at MSDN. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: Feedback requested on an OpenAL audio driver patch -- #2
by Nick Burns June 8, 2006

June 8, 2006

(the elusive attachment) It helps when I hit the attach button (sorry) - Nick

1 0

Re: Feedback requested on an OpenAL audio driver patch
by Leon Freitag June 8, 2006

June 8, 2006

P.S. Isn't it better to use pkg-config to check where the libs are located anyway? Leon

3 2

Re: Feedback requested on an OpenAL audio driver patch
by Leon Freitag June 8, 2006

June 8, 2006

> AC_CHECK_HEADERS(\ >+ OpenAL/al.h \ >+ al/al.h \ > AudioUnit/AudioUnit.h \ > CoreAudio/CoreAudio.h \ > IOKit/IOKitLib.h \ Your patch checks for OpenAL headers only in these places. However my distro (Suse 10.1) puts openal headers to AL/ instead of al/ and so configure with the patch as-is doesn't find files on my system. Also patching dlls/makefile.in fails. Had to patch it manually. Leon

2 1

Re: Feedback requested on an OpenAL audio driver patch
by Leon Freitag June 8, 2006

June 8, 2006

My first impressions: 1) Doesn't compile here: audio.c: In function ‘OpenAL_WaveClose’: audio.c:636: error: void value not ignored as it ought to be because alcCloseDevice() is declared here as void (my openal version is 1.0.20051129) 2) It'd be better to convert ALC errors from FIXMEs to ERRs. 3) You don't link the driver to openal somewhy (there's no -lopenal switch passed to gcc). Perhaps it's related to the configure.in hack I made, but I had to modify dlls/winmm/wineopenal/Makefile.in and add openal there too. 4) You check for al/al.h and OpenAL/al.h within the configure script but you include AL/al.h and OpenAL/al.h. This doesn't work on Linux, since Linux filesystems are case sensitive. Leon

2 1