C.W. Betts wrote: > Is is just because of the Objective-C code? Would it be safe to make C > functions that would call Objective-C? Such as: > cheader.h: > typedef struct struct1 struct1; > cfuncCreate(struct1 *s); > cfunc1(); > cfunc2(); > cfuncDestroy (struct1 *s); > > cfile.m: > @interface WHQFunc > { > > } > -(id)init; > -(void)dealloc; > @end > struct > { > WHQFunc *ObjC; > int ids; > }struct1; > @implementation WHQFunc > > -(id)init > { > return [super init]; > } > -(void)dealloc > { > [super dealloc]; > } > @end > > cfunc1() > { > > } > cfunc2() > { > > } > cfuncCreate(struct1 *s) > { > s = malloc(sizeof(struct1)); > [[s->ObjC alloc] init]; > } > cfuncDestroy (struct1 *s) > { > [s->ObjC release]; > free(s); > } > Working on it.
The problem is that there can't be any Objective-C code in Wine. At all. Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any language other than pure, procedural C. I wanted to wait until it was finished, but I may as well announce it now. I'm working on a new tool to create pure C bindings to Objective-C frameworks. That way, you can use an Objective-C framework (like the Cocoa Foundation and AppKit frameworks) from C. There is a even a companion framework that lets you define your own classes and create instances of them--without writing a single line of Objective-C. If you'll be patient, I'll be finishing it soon, and I'll post the source and binaries somewhere so you can use it. My intent is precisely, among other things, to use this to create a Quartz driver that will work in 64-bit (because the Carbon UI stuff doesn't work in 64-bit). Chip