The question of whether the reserved field in the vtable is still required for Mac OS X remains. I believe that if you want to maintain COM compatibility on MacOS X, then you need the reserved void* as the first member of the vtable. For example, from <CFPlugIn/CFPlugInCOM.h> : #define IUNKNOWN_C_GUTS \ void *_reserved; \ HRESULT (STDMETHODCALLTYPE *QueryInterface)(void *thisPointer, REFIID iid, LPVOID *ppv); \ ULONG (STDMETHODCALLTYPE *AddRef)(void *thisPointer); \ ULONG (STDMETHODCALLTYPE *Release)(void *thisPointer) typedef struct IUnknownVTbl { IUNKNOWN_C_GUTS; } IUnknownVTbl; This is Mac OS X's COM vtable layout. If you use System APIs to get use COM objects, the QueryInterface routine needs to be at offset +4 in the vtable. GCC 3.3 on OS X puts QueryInterface at +0 in the vtable (if you use the "toll-free" C++ vtable creation). Unfortunately, there does not seem to be any real documentation on any of this -- just the comments in CFPlugIn/CFPlugInCOM.h. The link to the MacDevCenter article seems to simply punt on the reserved field; it simply uses the Iunknown from CFPlugIn/CFPlugInCOM.h. I do know that the Apple defined COM interfaces (for example the IOKit userclients) use IUNKNOWN_C_GUTS, so they have the _reserved field. Now, it seems like the discussion has evolved to using a COM inspired API as opposed to a strictly COM compatible API. In this case, it is not important to maintain the COM vtable layout in GMPI, but it would be very cool to match the C++ vtable layout (which seems to be first vmethod at +0 for both GCC 3.3 and CW), since that would enable the possibility of toll-free bridging on OS X as well as Win32. Best regards, B.J. Buchalter Metric Halo 5 Donovan Drive Hopewell Junction, NY 12533 USA tel +1 845 223-6112 fax +1 603 250-2451 ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe