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

Default background erase code does not respect WM_CLIPSIBLINGS
by Troy Rollo Aug. 23, 2006

Aug. 23, 2006

The attached program demonstrates a bug in the default background-erase code in send_erase (dlls/user/painting.c). The code includes a top level window with WS_CLIPCHILDREN | WS_CLIPSIBLINGS, and two overlapping child windows - one that draws nothing and has a white background (first child), and the other being a standard drop-down list (second child). When the window is first created the second child is completely visible, having drawn over the first child. Click anywhere in the grey area of the window and the second child disappears. Click again and only half of it reappears (you may see the other half reappear briefly but be overwritten by the first child). The second child is correctly redrawn if you cover the window and expose it again. Under Windows, the same code results in the second window (being at the top of the Z order) appearing intact on the second click. This looks like one of those cases where there are probably a lot of wrong ways to fix it and only one right way, and so needs to be fixed by somebody familiar with the code involved. -- Troy Rollo - wine(a)troy.rollo.name

1 0

Re: msi: Add an initial implementation of the PathEdit control
by Mike McCormack Aug. 23, 2006

Aug. 23, 2006

James Hawkins wrote: > @@ -65,6 +65,7 @@ struct msi_control_tag > float progress_current; > float progress_max; > WCHAR name[1]; > + DWORD attributes; You shouldn't add members after name[1], as the string in name[] will overwrite them. > + sz = 0x20; > + buf = msi_alloc( sz*sizeof(WCHAR) ); > + while( buf ) > + { > + r = GetWindowTextW( control->hwnd, buf, sz ); > + if( r < (sz-1) ) > + break; > + sz *= 2; > + buf = msi_realloc( buf, sz*sizeof(WCHAR) ); > + } There's already code to get the window text in msi_dialog_edit_handler(), so please factor it out into a new function rather than copying it. (maybe LPWSTR msi_get_window_text(HWND)?) > + LPCWSTR prop; > + prop = (LPWSTR)MSI_RecordGetString( rec, 9 ); You shouldn't need a cast here... Mike

2 1

Re: msi: Add Set/GetLastError to the property tests
by Alexandre Julliard Aug. 23, 2006

Aug. 23, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > @@ -2087,33 +2087,44 @@ static void test_getproperty(void) > ok( hPackage != 0, " Failed to create package\n"); > > /* set the property */ > + SetLastError(0xdeadbeef); > r = MsiSetProperty(hPackage, "Name", "Value"); > ok( r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", r); > + ok( GetLastError() == 0xdeadbeef, "Expected 0xdeadbeef, got %ld\n", GetLastError()); In general, testing that last error isn't set on success is not useful, unless you really have an app that depends on it. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: comdlg: Send missing CDN_FOLDERCHANGE (resend 2)
by Alexandre Julliard Aug. 23, 2006

Aug. 23, 2006

"Renu Rajput" <renu.rajput(a)gmail.com> writes: > diff -urN OldDir/dlls/comdlg32/filedlg.c NewDir/dlls/comdlg32/filedlg.c > --- OldDir/dlls/comdlg32/filedlg.c 2006-08-10 18:45:12.000000000 +0530 > +++ NewDir/dlls/comdlg32/filedlg.c 2006-08-11 16:09:32.000000000 +0530 > @@ -2011,7 +2011,10 @@ > IPersistFolder2_Release(ppf2); > if( ! COMDLG32_PIDL_ILIsEqual(pidlCurrent, fodInfos->ShellInfos.pidlAbsCurrent)) > { > - IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, > pidlCurrent, SBSP_ABSOLUTE); > + if (SUCCEEDED(IShellBrowser_BrowseObject(fodInfos->Shell.FOIShellBrowser, > pidlCurrent, SBSP_ABSOLUTE))) > + { > + SendCustomDlgNotificationMessage(hwnd, CDN_FOLDERCHANGE); > + } > } > else if( nOpenAction == ONOPEN_SEARCH ) There's no point in sending a (corrupted) inline version of the patch plus another one as attachment, all it does is prevent the patch from being applied. Please send only one instance of the patch, in a non-corrupted format. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi: remove limit on number of handles
by Michael Stefaniuc Aug. 23, 2006

Aug. 23, 2006

Dan Kegel wrote: > Changelog: > msi: remove limit on number of handles > > handle.c | 30 +++++++++++++++++++++++------- > msipriv.h | 1 - > 2 files changed, 23 insertions(+), 8 deletions(-) > > > ------------------------------------------------------------------------ > > diff --git a/dlls/msi/handle.c b/dlls/msi/handle.c > index 1cd82b3..79664f5 100644 > @@ -66,18 +67,29 @@ MSIHANDLE alloc_msihandle( MSIOBJECTHDR > > EnterCriticalSection( &MSI_handle_cs ); > > + if (msihandletable == NULL) > + { > + /* start table off small to avoid hiding resize bugs */ > + msihandletable_size = 1; Isn't this very small start value something to be used only for debugging while one writes the resizing code? For "production" I would use a value that is big enough to handle the common case (handles at least 50% of the real life cases). As the old MSIMAXHANDLES was good enough for a whole lot of programs i would define that as common case to save me work of finding what the common case is. > + msihandletable = msi_alloc_zero(1*sizeof(msi_handle_info)); > + } > + bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 2

Re: msi: increase MSIMAXHANDLES to 2048
by Alexandre Julliard Aug. 23, 2006

Aug. 23, 2006

"Dan Kegel" <dank(a)kegel.com> writes: > This lets http://bugs.winehq.org/show_bug.cgi?id=4227 > get to the next problem. (1024 handles wasn't enough, I checked. > 2048 might not be enough for a truly huge app, but this should > hold us for a while.) Dynamic allocation would be better, it's really not hard to do in this case. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: developers-hints 2 -- second try
by Alexandre Julliard Aug. 23, 2006

Aug. 23, 2006

"Tom Wickline" <twickline(a)gmail.com> writes: > Changelog: add newly implemented dlls and update http links I think the DEVELOPERS-HINTS contents should really be moved to the Wiki, it would be a lot easier to keep up to date there. Does anybody feel like doing that? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: resend add missing glyph code to GetGlyphIndices
by Dmitry Timoshkov Aug. 23, 2006

Aug. 23, 2006

"Jeff L" <lats(a)yless4u.com.au> wrote: > if(dc->gdiFont) > - ret = WineEngGetGlyphIndices(dc->gdiFont, lpstr, count, pgi, flags); > + ret = WineEngGetGlyphIndices(hdc, dc->gdiFont, lpstr, count, pgi, flags); ... > + GetTextMetricsW(hdc, &textm); As an additional optimization, probably it would be better to call WineEngGetTextMetrics instead of GetTextMetricsW to avoid introducing hdc as another parameter of WineEngGetGlyphIndices. -- Dmitry.

2 1

Re: opengl pixel format regression
by Roderick Colenbrander Aug. 23, 2006

Aug. 23, 2006

> Hello > > > Both of you try to remove the following code from > src/winex11.drv/opengl.c: > > /* Aux buffers */ > > pglXGetFBConfigAttrib(gdi_display, cfgs[fmt_index], > GLX_AUX_BUFFERS, > > &value); if (ppfd->cAuxBuffers && !value) { > > goto choose_exit; > > } > > Is this code in current CVS/GIT? I'm currently using 0.9.19 and could not > find > the code in wine sources (gentoo). I have fixed a bug related to the pixel format which should be in cvs now. So your bug might be fixed in cvs. Could you try it and could you also attach a log of glxinfo? I need that log to fix some other opengl issues and I don't have have data from cards like yours. Thanks, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: regedit[1/2]: remove custom filter from open/save dialogs
by Alexandre Julliard Aug. 23, 2006

Aug. 23, 2006

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > --- framewnd_orig.c 2006-08-10 15:15:12.000000000 +0200 > +++ framewnd.c 2006-08-22 22:10:05.000000000 +0200 Please generate diffs from the top-level directory. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi: resend add missing glyph code to GetGlyphIndices
by Alexandre Julliard Aug. 23, 2006

Aug. 23, 2006

Jeff L <lats(a)yless4u.com.au> writes: > for(i = 0; i < count; i++) > + { > pgi[i] = get_glyph_index(font, lpstr[i]); > - > + if (pgi[i] == 0) > + { > + if (flags & GGI_MARK_NONEXISTING_GLYPHS) > + pgi[i] = 0x001f; /* Indicate non existance */ > + else > + { > + /* Note that the call to GetTextMetricsW is made in the loop * > + * because it is less likely to have non existant glyphs * > + * and hence we should have few calls to GetTextMetricsW as * > + * a result */ > + GetTextMetricsW(hdc, &textm); > + pgi[i] = textm.tmDefaultChar; It's a good idea to not call GetTextMetrics unless you need it, but there's no reason to call it multiple times. It isn't hard to call it only the first time you need the default char. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: user: [2/2] Pass hook handle to the destination thread. Call server to get hook information
by Vitaliy Margolen Aug. 22, 2006

Aug. 22, 2006

Thursday, August 17, 2006, 8:46:12 AM, Vitaliy Margolen wrote: > ChangeLog: > user: Pass hook handle to the destination thread. Call server to get hook > information for inter-thread hooks. > Currently Wine has a major problem with LL hooks (low level hooks) when > second hook is installed in a separate thread - the second hook callback is > never called. And while attempting to call it Wine almost locks up in never > ending loop. This happening because instead of calling current thread's > hook callback Wine restarts the whole hook chain from the start. > This patch deals with both sides of this problem. > Fixes Bug [5803], [5712] and possibly others. > dlls/user/hook.c | 41 +++++++++++++++++++++++++++++++++++++---- > dlls/user/message.c | 13 +++++++++---- > dlls/user/user_private.h | 7 +++++++ > server/hook.c | 29 +++++++++++++++++++++++++++++ > server/protocol.def | 13 +++++++++++++ > 5 files changed, 95 insertions(+), 8 deletions(-) Why wasn't this patch accepted? Alexandre on IRC said that there are some race conditions here. I don't see how and where. The only possible place that I can think of is passing handle from one thread to the other thread using internal message. But that is covered. If the hook gets removed, we don't remove it in the server: http://source.winehq.org/source/server/hook.c#L291 When new hook is added, it's being placed ahead of all others, so it's not a problem either - we can't call it anyway after hook-chain has been started. Am I missing something here? Vitaliy Margolen

1 0

Re: msiexec: Add handling for msiexec's regserver option
by Vitaliy Margolen Aug. 22, 2006

Aug. 22, 2006

Tuesday, August 22, 2006, 7:56:00 PM, James Hawkins wrote: > Hi, > More and more installers are expecting the MSI service to exist, or at > least be installable using msiexec /regserver. This patch is the > first step in fixing bug 5540. > + if (!scm) > + { > + fprintf(stderr, "Failed to open the service control manager.\n"); > + return 1; > + } Please use proper WINE_[ERR|WARN|FIXME|TRACE] macros. Vitaliy Margolen

2 1

regression with gothic1/2
by Sebastian Schlingmann Aug. 22, 2006

Aug. 22, 2006

Hi everybody, I noticed yesterday that the gothic 1/2 demos don't work anymore. Console output is the following: ... err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main process heap section" wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bc7ef44 "loader.c: loader_section" wait timed out in thread 0009, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main process heap section" wait timed out in thread 000d, blocked by 0009, retrying (60 sec) ... A regression test came up with the following result: $ git bisect bad 13163349521e50e7039e188a22b6a814dcfcfc37 is first bad commit commit 13163349521e50e7039e188a22b6a814dcfcfc37 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Jul 21 11:53:24 2006 +0200 ntdll: Add a few more free list entries to the heap. :040000 040000 dba2d276a01c6d148826a913f4163e0db0ed4689 eb1abe2301ff4698ac939b7e1b1fa225ceca4338 M dlls I can provide traces and additional info if needed. Bye Sebastian

3 4

Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462
by Matt Finnicum Aug. 22, 2006

Aug. 22, 2006

Hi, Is there something wrong with this patch / a reason it's not being accepted? Sorry if this might have been answered this on IRC last night - X died while I was away, so I'd have missed it. Thanks, --Matt Finnicum On 8/19/06, Matt Finnicum <mattfinn(a)gmail.com> wrote: > Hi, > I've cleaned up / re-diffed this patch from Brian Chang. It fixes bug > 4462 by handling several odd ways in which EM_EXSETSEL can be called. > It also make the message return a proper value, not just zero. > > --Matt Finnicum (Please commit as Brian Chang) > > The last version of this patch can be found here: > http://www.winehq.com/pipermail/wine-patches/2006-March/024976.html > > --- > dlls/riched20/editor.c | 25 +++++++++++++++++--- > dlls/riched20/tests/editor.c | 52 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 73 insertions(+), 4 deletions(-) > > >

2 1

Read to 0x7ffe02c0
by Juan Lang Aug. 22, 2006

Aug. 22, 2006

Hi folks, I'm trying to debug an access (by native userenv.dll in my case, but also by MS Money 2006) to address 0x7ffe02c0. This is my understanding so far: The TEB is at 0x7ffe0000, so, according to winternl.h, offset 0x02c0 within it is in the middle of GDI_TEB_BATCH. That doesn't make any sense to me. Anyone have any idea what's going on? Thanks, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 7

Re: Fwd: RFC: OpenGL x11drv rewrite (WoW fix)
by Raphael Aug. 22, 2006

Aug. 22, 2006

On Monday 14 August 2006 19:57, you wrote: > Hi Raphael, Hi Roderick, sorry for late response i was in holidays (and before that a long moving to my new apartment) > I'm not sure how well you are monitoring the wine-devel lists these days, > so I'm also directing this mail directly to you. I have been trying to fix > various problems in the Wine OpenGL code. See the attached email and the > patch for more info. > > Basicly I changed the opengl code to only advertise the format of wine's > main visual. I think the changes I made are more or less correct to > Alexandre changes like this sounded correct aswell. But as he isn't an > OpenGL expert he wanted to know the opinion of others and especially from > people who know the code well. > > I already asked Lionel but he said that he isn't that familiar with the > current code which you rewrote a while ago. To Lionel the format > advertising change sounded correctly aswell although he hasn't checked the > code. > > Could you comment on the patch? (reply to the wine-devel list) > > Regards, > Roderick Colenbrander > > -------- Original-Message -------- > Datum: Mon, 14 Aug 2006 17:04:52 +0200 > From: "Roderick Colenbrander" <thunderbird2k(a)gmx.net> > To: wine-devel(a)winehq.org > Subject: RFC: OpenGL x11drv rewrite (WoW fix) > > Hi, > <snip> For me your patch seems correct Anyway the problem is you can add regression in cases: - application want a very specific needs that isn't compatible with current selected visual (use of SetPixelFormat before first CreateContext, now you don't care about user wanted PixelFormat) - application wants to create many context with not compatible pixel format (supported on windows) So you may restore many of the original problems but fixed the more problematic problem of BadMatch :) What it'll be interesting to do next is to move all low-level GLW/GLX utilities calls to x11drv to permit better access to x11drv internals (and to permit better portability on non GLX os, and better share with wined3d). This will help a lot for the famous bug of openGL chils windows. And after that, when user use the SetPixelFormat API, find a way to change the default created wine visual (use of SetPixelFormat is only permited once on windows). The problem is that visual is created by default before the application specify it's needs (ie. when the windows is created). We have the same problem for WineD3D, many games create a window and after want to choose a specific frame buffer (and if not compatible with current visual -> problem) I wanted to delay this visual creation (or better dynamically change this on X, if permited) but no chance (same problem for glwShareLists) :( Keep your good job :) Best Regards, Raphael

5 10

Re: [TRY 2] XEmbed System Tray Support
by Alexandre Julliard Aug. 22, 2006

Aug. 22, 2006

James Liggett <jrliggett(a)cox.net> writes: > + /* fall back to he KDE hints if the WM doesn't support XEMBED'ed > + * systrays */ > + > + /* Put the window back within the screen so it will be mapped */ > + SetWindowPos( data->hwnd, NULL, 0, 0, 0, 0, SWP_NOZORDER | SWP_NOSIZE ); It would be nicer to create the window with normal coordinates, and only move it off-screen when needed, instead of having off-screen be the default behavior. It would also avoid having explorer know about internals of the systray implementation. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/9] DDraw: Make IDirectDrawImpl thread safe
by Alexandre Julliard Aug. 22, 2006

Aug. 22, 2006

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > @@ -245,11 +252,12 @@ void > IDirectDrawImpl_Destroy(IDirectDrawImpl *This) > { > IDirectDrawImpl *prev; > + DDOBJ_LOCK(This); You shouldn't need locking in Destroy, if the refcount is zero no one else can be using the object. > for(prev = ddraw_list; prev; prev = prev->next) > + { > if(prev->next == This) break; > + } > > if(prev) > + { > + DDOBJ_LOCK(prev); > prev->next = This->next; > + DDOBJ_UNLOCK(prev); > + } You can't lock just one object, you have the protect the whole list. -- Alexandre Julliard julliard(a)winehq.org

1 0

opengl pixel format regression
by Stefan Dösinger Aug. 22, 2006

Aug. 22, 2006

Hi Roderick, Your pixel format patches caused a regression in half-life 1 for me with the fglrx drivers. It refuses to start in opengl mode and reports "ChoosePixelFormat failed", and then comes up in software(ddraw) mode. The d3d mode still works fine. This problem also does not occur with the open source radeon driver. I tested with fglrx 8.28.8 and fglrx 8.27.10. Other games seem to work fine(appart of a few fglrx bugs) What infos do you need to debug this? This is the format table glxinfo reports: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x2b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x2d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x30 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x32 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 1 0 None

3 2

wine and other xservers
by Vijay Kiran Kamuju Aug. 22, 2006

Aug. 22, 2006

Hi, How does wine work/perform with other opensource X servers, like nano Xserver. Thanks, VJ

1 0

Re: Using winehq to store patches that have not yet got into the wine code
by Tony Lambregts Aug. 21, 2006

Aug. 21, 2006

Nick Law wrote: > Hi Tony / Chris > > Is there someway of storing a patch on the winehq/appdb domain so that > I can put a link on the APPDB page to it, rather than use links to > other places like thehandofagony (which doesn't look like the sort of > place we should be using). I've been using rapid.de (I think it's > called which I can carry on doing, which gives you download stats). > However I thought as we store screenshots it would be nice to store > patches approved by the maintainers (prior to be incorporated into the > code, or the code fixed). > > Regards > Nick Law > There are a number of places that patches can be stored within winehq. The first place that you could store them is in the wiki like http://wiki.winehq.org/InterestingPatches, or if they fix/hack around a bug in the application then you can start a bug report and attach the patch there and link back to it. Finally you can submit a patch to wine-patches(a)winehq.org and link to the archive. http://www.winehq.org/pipermail/wine-patches/ ie: http://www.winehq.org/pipermail/wine-patches/2006-August/029455.html I do not know what the best way is but I tend to favor the wiki.

1 0

Re: crypt32: work around an apparent compiler bug
by Robert Shearman Aug. 21, 2006

Aug. 21, 2006

Juan Lang wrote: >This seems like voodoo to me too, but the combined condition if statement >would always fail for me, while two distinct if statements succeed. > >ChangeLog: >- add a couple traces to make following execution easier >- expand an if condition to work around an apparent gcc bug > > >- if (HIWORD(function->entry.pszOID && >- !strcasecmp(function->entry.pszOID, pszOID))) > > Looks like HIWORD(function->entry.pszOID is just missing a closing bracket to me. -- Rob Shearman

2 1

Re: wined3d: print real unhandled D3DCMPFUNC value
by Jan Zerebecki Aug. 21, 2006

Aug. 21, 2006

On Sun, Aug 20, 2006 at 01:37:04PM -0700, Chris Robinson wrote: > --- dlls/wined3d/device.c 10 Aug 2006 09:43:54 -0000 1.275 > +++ dlls/wined3d/device.c 20 Aug 2006 20:31:10 -0000 > @@ -3666,7 +3666,7 @@ > case D3DCMP_GREATEREQUAL: glParm = GL_GEQUAL; break; > case D3DCMP_ALWAYS: glParm = GL_ALWAYS; break; > default: > - FIXME("Unrecognized/Unhandled D3DCMPFUNC value %ld\n", Value); > + FIXME("Unrecognized/Unhandled D3DCMPFUNC value %ld\n", This->stateBlock->renderState[WINED3DRS_ALPHAFUNC]); (I forgot if I verified this, but) I think that when a state is beeing set This->stateBlock->renderState[State] has the previous value and only Value has the one to be set. From a quick glance it seems the code for this renderstate (and maybe more renderstates) wrongly assumes the contrary. Jan

3 2

KDE wineconfig module & audio
by Yuriy Aug. 20, 2006

Aug. 20, 2006

Hi, I'm creating a KDE guidance module for wine. I'm stuck on something. winecfg tries to open each audio driver to get a list of available drivers. So far, I've just put in the list of all possible drivers, but I want to get a list consistent with winecfg. I don't know how to go about testing which drivers are available. I'm using regedit for settings, so I'm not linking to wine so I can't just use the function(s) provided in wine. Also, I'd like to put in a button to test if sound is working. Is there any software included in wine to play a wav? It needs to be something that would be installed by default when wine is installed, rather than something that's just in the source like the tests in winmm. Thanks for any help ~Yuriy

3 3