Re: Porting MIDI plug-in from CW to Xcode
Re: Porting MIDI plug-in from CW to Xcode
- Subject: Re: Porting MIDI plug-in from CW to Xcode
- From: Pete Gontier <email@hidden>
- Date: Tue, 09 Aug 2005 18:53:32 -0700
Title: Re: Porting MIDI plug-in from CW to Xcode
Right; I’ve seen that code and studied it. But it seems as if the last time I looked at <CoreFoundation/CFPlugInCOM.h>, it was a lot more spare, which suggests somebody’s been working in that area. Then again, maybe my memory is wishful. I will indeed resign myself to maintaining that fiddly pointer arithmetic until the end of time if necessary, but what I have now feels tantalizingly close to working, thus my hope. I wonder if I should cross-post this to the Darwin list, since this seems like CFPlugIn issue.
— Pete Gontier <http://www.m-audio.com/>
From: Doug Wyatt <email@hidden>
Date: Tue, 9 Aug 2005 17:31:42 -0700
To: Pete Gontier <email@hidden>
Cc: CoreAudio API <email@hidden>, Cobey Gatos <email@hidden>
Subject: Re: Porting MIDI plug-in from CW to Xcode
Hmm, CFPlugInCOM.h doesn't look much different from when I last
pondered it at length (possibly 5 years ago).
So you are deriving a C++ object from IUnknown? That header says:
"This class will work only with compilers that can produce COM-
compatible object layouts for C++ classes." I don't believe that to
be true of gcc as of 4.0 (and I hope someone will correct me if I'm
wrong).
You could have a look at the sample driver in the SDK, notably
MIDIDriverClass.h
see especially GetMIDIDriver, which converts from the COM object to your
C++ object. Has commentary on exactly what I suspect is going wrong here.
MIDIDriver.cpp
Implementation of the above
Doug
--
Doug Wyatt
Core Audio, Apple
On Aug 9, 2005, at 16:22, Pete Gontier wrote:
> When this project was last built, CodeWarrior made all that stuff
> unnecessary. I just sub-classed IUnknown. There was a period when Metrowerks
> tools supported COM better than Apple tools did. That may still be the case,
> but my reading of the current version of <CoreFoundation/CFPlugInCOM.h>
> suggests Apple tools have caught up. I would vastly prefer never to code up
> pseudo-vtables, especially given the age and stability of this code, so I am
> presently hoping that fixing this is going to be a matter of a minor tweak.
>
> — Pete Gontier <http://www.m-audio.com/>
>
> From: Doug Wyatt <email@hidden>
> Date: Tue, 9 Aug 2005 14:48:42 -0700
> To: Pete Gontier <email@hidden>
> Cc: CoreAudio API <email@hidden>, Cobey Gatos
> <email@hidden>
> Subject: Re: Porting MIDI plug-in from CW to Xcode
>
> Do you have code that obtains a pointer to a C++ object based on a pointer to
> a pointer to a vtable? Does that code think it knows where in the object the
> vtable sits? I have such code and got bitten by those assumptions when moving
> from gcc 2.95 to 3.3 if I remember correctly.
>
> --
> Doug Wyatt
> Core Audio, Apple
>
> On Aug 8, 2005, at 17:05, Pete Gontier wrote:
>
> > We have a working (shipping) MIDI driver written in C++ and built
> > with CodeWarrior which needs to be converted to Xcode. We’ve got it
> > building but not running on Panther. (The shipping CodeWarrior
> > build runs fine on Panther.)
> >
> > The CFPlugIn factory function is called but then the plug-in
> > interface object it instantiates is being called oddly. It receives
> > two calls to AddRef with the same value of ‘this’ but no call to
> > QueryInterface. The callers of AddRef are somewhat different; the
> > first one is...
> >
> >> 0x8358bf60 in DriverTable::FindDriversInDirectory(short, unsigned
> >> long) ()
> >
> > ...and the second one is...
> >
> >> 0x8358bfec in DriverTable::FindDriversInDirectory(short, unsigned
> >> long) ()
> >
> > Same routine with a higher offset. Or perhaps it is only the
> > closest symbol to an unnamed function in one or both cases.
> >
> > The lack of a call to QueryInterface is of course where the plug-in
> > instantiates the MIDI driver (if necessary).
> >
> > I can’t guess why being built by Xcode would cause such oddness to
> > occur. Ideas?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden