---
So all the code in dlls/dmime/tool.c was unused because nothing was calling DMUSIC_CreateDirectMusicTool8Impl(). Apparently the intent was to call it from a class factory so I looked around and came up with the following patch that implements a class factory for DirectMusicTool8. However I have never implemented a class factory before and don't know much about them.
So does this patch make sense?
Does the fact that we have an IID_IDirectMusicTool8 instead of a CLSID_XXX hint at something I'm missing?
How come this was not done when the file was first added?
That said IDirectMusicTool8Impl looks like one big stub. So if it makes more sense to remove it entirely I can do that too.
dlls/dmime/dmime_main.c | 56 +++++++++++++++++++++++++++++++++++++++++++- dlls/dmime/dmime_private.h | 2 +- dlls/dmime/tool.c | 2 +- 3 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/dlls/dmime/dmime_main.c b/dlls/dmime/dmime_main.c index f4abddd..8bd95a9 100644 --- a/dlls/dmime/dmime_main.c +++ b/dlls/dmime/dmime_main.c @@ -729,6 +729,56 @@ static const IClassFactoryVtbl WaveTrackCF_Vtbl = { static IClassFactoryImpl WaveTrack_CF = {&WaveTrackCF_Vtbl};
/****************************************************************** + * DirectMusicTool8 ClassFactory + */ +static HRESULT WINAPI Tool8CF_QueryInterface(LPCLASSFACTORY iface,REFIID riid,LPVOID *ppobj) { + FIXME("- no interface\n\tIID:\t%s\n", debugstr_guid(riid)); + + if (ppobj == NULL) return E_POINTER; + + return E_NOINTERFACE; +} + +static ULONG WINAPI Tool8CF_AddRef(LPCLASSFACTORY iface) { + DMIME_LockModule(); + + return 2; /* non-heap based object */ +} + +static ULONG WINAPI Tool8CF_Release(LPCLASSFACTORY iface) { + DMIME_UnlockModule(); + + return 1; /* non-heap based object */ +} + +static HRESULT WINAPI Tool8CF_CreateInstance(LPCLASSFACTORY iface, LPUNKNOWN pOuter, REFIID riid, LPVOID *ppobj) { + TRACE ("(%p, %s, %p)\n", pOuter, debugstr_dmguid(riid), ppobj); + + return DMUSIC_CreateDirectMusicTool8Impl (riid, ppobj, pOuter); +} + +static HRESULT WINAPI Tool8CF_LockServer(LPCLASSFACTORY iface,BOOL dolock) { + TRACE("(%d)\n", dolock); + + if (dolock) + DMIME_LockModule(); + else + DMIME_UnlockModule(); + + return S_OK; +} + +static const IClassFactoryVtbl Tool8CF_Vtbl = { + Tool8CF_QueryInterface, + Tool8CF_AddRef, + Tool8CF_Release, + Tool8CF_CreateInstance, + Tool8CF_LockServer +}; + +static IClassFactoryImpl Tool8_CF = {&Tool8CF_Vtbl}; + +/****************************************************************** * DllMain * * @@ -821,7 +871,11 @@ HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, LPVOID *ppv) *ppv = &WaveTrack_CF; IClassFactory_AddRef((IClassFactory*)*ppv); return S_OK; - } + } else if (IsEqualCLSID (rclsid, &IID_IDirectMusicTool8) && IsEqualIID (riid, &IID_IClassFactory)) { + *ppv = &Tool8_CF; + IClassFactory_AddRef((IClassFactory*)*ppv); + return S_OK; + } WARN("(%s, %s, %p): no interface found.\n", debugstr_dmguid(rclsid), debugstr_dmguid(riid), ppv); return CLASS_E_CLASSNOTAVAILABLE; diff --git a/dlls/dmime/dmime_private.h b/dlls/dmime/dmime_private.h index 308c2c8..d21061d 100644 --- a/dlls/dmime/dmime_private.h +++ b/dlls/dmime/dmime_private.h @@ -72,7 +72,7 @@ extern HRESULT WINAPI DMUSIC_CreateDirectMusicSegmentImpl (LPCGUID lpcGUID, LPVO extern HRESULT WINAPI DMUSIC_CreateDirectMusicSegmentStateImpl (LPCGUID lpcGUID, LPVOID *ppobj, LPUNKNOWN pUnkOuter); extern HRESULT WINAPI DMUSIC_CreateDirectMusicGraphImpl (LPCGUID lpcGUID, LPVOID *ppobj, LPUNKNOWN pUnkOuter); extern HRESULT WINAPI DMUSIC_CreateDirectMusicAudioPathImpl (LPCGUID lpcGUID, LPVOID *ppobj, LPUNKNOWN pUnkOuter); -extern HRESULT WINAPI DMUSIC_CreateDirectMusicToolImpl (LPCGUID lpcGUID, LPVOID *ppobj, LPUNKNOWN pUnkOuter); +extern HRESULT WINAPI DMUSIC_CreateDirectMusicTool8Impl (LPCGUID lpcGUID, LPVOID *ppobj, LPUNKNOWN pUnkOuter); extern HRESULT WINAPI DMUSIC_CreateDirectMusicPatternTrackImpl (LPCGUID lpcGUID, LPVOID *ppobj, LPUNKNOWN pUnkOuter);
extern HRESULT WINAPI DMUSIC_CreateDirectMusicLyricsTrack (LPCGUID lpcGUID, LPVOID* ppobj, LPUNKNOWN pUnkOuter); diff --git a/dlls/dmime/tool.c b/dlls/dmime/tool.c index 1654bb8..81f4bca 100644 --- a/dlls/dmime/tool.c +++ b/dlls/dmime/tool.c @@ -119,7 +119,7 @@ static const IDirectMusicTool8Vtbl DirectMusicTool8_Vtbl = { };
/* for ClassFactory */ -HRESULT WINAPI DMUSIC_CreateDirectMusicobjImpl (LPCGUID lpcGUID, LPVOID *ppobj, LPUNKNOWN pUnkOuter) { +HRESULT WINAPI DMUSIC_CreateDirectMusicTool8Impl(LPCGUID lpcGUID, LPVOID *ppobj, LPUNKNOWN pUnkOuter) { IDirectMusicTool8Impl* obj; obj = HeapAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectMusicTool8Impl));
On 16. 06. 2009 12:33, Francois Gouget wrote:
So all the code in dlls/dmime/tool.c was unused because nothing was calling DMUSIC_CreateDirectMusicTool8Impl(). Apparently the intent was to call it from a class factory so I looked around and came up with the following patch that implements a class factory for DirectMusicTool8. However I have never implemented a class factory before and don't know much about them.
So does this patch make sense?
Does the fact that we have an IID_IDirectMusicTool8 instead of a CLSID_XXX hint at something I'm missing?
How come this was not done when the file was first added?
That said IDirectMusicTool8Impl looks like one big stub. So if it makes more sense to remove it entirely I can do that too.
The honest answer would be that because back in the day when I was working on it, I didn't fully understand how COM works, particularly the difference between class object and interface. As a result, there's bunch of .c files containing stubbed code for interfaces as if they were class objects, when they really aren't. And as such, they should be removed...
Regards, Rok
On Tue, 16 Jun 2009, Rok Mandeljc wrote: [...]
The honest answer would be that because back in the day when I was working on it, I didn't fully understand how COM works, particularly the difference between class object and interface. As a result, there's bunch of .c files containing stubbed code for interfaces as if they were class objects, when they really aren't. And as such, they should be removed...
Ah! That's interesting.
So you're essentially saying that the right thing to do would be to remove dlls/dmime/tool.c and dlls/dmime/patterntrack.c ? That sounds like something I can do<g>.
On 17. 06. 2009 00:19, Francois Gouget wrote:
On Tue, 16 Jun 2009, Rok Mandeljc wrote: [...]
The honest answer would be that because back in the day when I was working on it, I didn't fully understand how COM works, particularly the difference between class object and interface. As a result, there's bunch of .c files containing stubbed code for interfaces as if they were class objects, when they really aren't. And as such, they should be removed...
Ah! That's interesting.
So you're essentially saying that the right thing to do would be to remove dlls/dmime/tool.c and dlls/dmime/patterntrack.c ? That sounds like something I can do<g>.
Indeed. While you're at it, you can also remove dmusic32. It's where emulated ports code was kept back in DX8 Win98/Me version; nowadays that functionality is part of dmusic.dll.
Regards, Rok
-
Francois Gouget -
Rok Mandeljc