dsound: Runtime link to advapi32 RegDeleteTree
msclrhd at googlemail.com
Mon Sep 3 16:27:54 CDT 2007
On 03/09/07, Maarten Lankhorst <m.b.lankhorst at gmail.com> wrote:
> Reece Dunn schreef:
> > Correct me if I am wrong on this, but I have a few questions. And I
> > apologise if I ask some stupid questions, as I don't understand how
> > the Wine loader works.
> > On 01/09/07, Maarten Lankhorst <m.b.lankhorst at gmail.com> wrote:
> >> Makes the dsound dll work in windows xp and older versions of windows
> >> again.
> > By this, do you mean running the Wine dsound.dll on _native_ Windows?
> Yes, what other windows is there? Wine dsound works fine under windows.
I was wondering if you meant Wine running as Windows XP. Thanks for
> >> It is the least of all evils as far as I could see. It's either
> >> this or adding RegDeleteTree to libwine, unless someone has a third option.
> > If the intent is to get this working on native, adding RegDeleteTree
> > to libwine will not help. Unless you mean running Wine in Windows XP
> > or earlier compatibility mode? If so, I was under the assumption that
> > all the API were available to Wine, it was just the reported OS
> > version that differed. I say this, because none of the Windows headers
> > vary on OS version like the Windows SDK does.
> Running a mingw compiled dsound in windows xp or earlier. In wine it
> will work correctly even in xp mode. It may not be a bad idea to add a
> function to libwine that can be used in case RegDeleteTree is
> unavailable in advapi32.
IIUC, libwine is a DLL that provides additional Wine-based helpers. If
that is correct, then a RegDeleteTree could be implemented there. The
question is how that is done.
If the idea is that all Wine DLLs can be run on native Windows (most
notably the DirectX DLLs), then this fallback mechanism applies to
these as well. Therefore, it may be better to directly call a Wine
equivalent of this API, such as the originally named
RegDeleteTreeWine, in libwine to simplify the logic (i.e. no need to
call GetProcAddress). Then, the advapi32 RegDeleteTree can forward to
the libwine version, preventing code duplication.
> > Even so, since the RegDeleteTree API are queried for by
> > GetProcAddress, this means that they will not be found on WinXP and
> > earlier, so DllUnregisterServer will fail on those platforms, leaving
> > behind the dsound GUIDs on those platforms. This is bad practice, but
> > I don't see how else this will work (assuming that these are run on
> > native).
> I am aware of that, however you can still use the native dsound to
> unregister in those cases, which may not be ideal but should work.
> >> +static typeof(RegDeleteTreeW) * pRegDeleteTreeW;
> > Is it common practice in Wine to use typeof? I was under the
> > assumption that this was limited to the gcc C++ compiler. Even if it
> > is available in the C compiler, it is not portable to compilers that
> > don't support that, such as pre-typeof gcc compilers.
> If you check in the wine tree, other places use typeof too, so I didn't
> think it would be that big an issue.
If other places are using it then that is ok.
More information about the wine-devel