[cfe-dev] ObjectiveC on Windows using the Apple Obj C runtime
luoyonggang at gmail.com
Fri Jan 22 11:05:43 CST 2010
If we want to migrate ObjectiveC to windows platform, at least need to
support windows api. Considerating mingw to support windows sdk is not
always up to date. If we can direct using windows sdk headers is the
best choice:) and also ms provide the *.lib files, if we can direct
support pecoff files, then we can linkage to these files directly:)
2010/1/22, David Chisnall <theraven at sucs.org>:
> On 22 Jan 2010, at 14:41, Jim Crafton wrote:
>>> Yes, it depends what you mean by minimal.
>>> It should be fine if you don't plan to use Block, Exception, Forwarding ,
>>> synchronize, etc…
>> So are those things part of the Objective C, or just some extension?
>> Are you saying exception handling is fundamentally dependent on the
>> Foundation kit? Oh well, maybe it's just not worth the bother then.
> For the GNU runtime (the same is mostly true for the Apple runtime):
> Throwing and catching exceptions is handled by the personality function in
> the runtime. It just checks the isa pointers of the thrown object. In
> OpenStep code it is common to only throw or catch NSException objects - and
> some code depends on this behaviour - but it's not required by the runtime.
> With the old Apple runtime, and until a few years ago with the GNU runtime,
> exceptions were all implemented in terms of setjmp()/longjmp() in Foundation
> and were completely outside the runtime.
> Blocks are not supported by the old GNU runtime. The GNU objc2 runtime has
> a blocks implementation that has been tested on FreeBSD and Linux and has
> been in use by various people for about a year. The Apple runtime delegates
> this to the blocks runtime (a separate library). The implementation used on
> OS X is in CompilerRT, but I don't know if anyone has used this on
> non-Darwin platforms. Last time I looked it was full of Darwinisms, but it
> might have been tidied up by now.
> Forwarding is mainly done by the Foundation framework. When an object does
> not respond to a message, the runtime calls a function in Foundation which
> constructs an NSInvocation object. With GNUstep, this uses either libffi or
> ffcall. I'm not sure what Apple uses. As NSInvocation is part of
> Foundation, this can't be in the runtime. In 'classic' Objective-C,
> forwarding is done via the forward:: method, which is responsible for
> deconstructing the stack frame itself. I think the GNU runtime falls back
> to doing this if no callback function is registered, but it's so horrible to
> use I don't think anyone does.
> @synchronize() must create a recursive mutex for each object. This calls
> functions that weren't present in the old GNU runtime. They are provided by
> both GNUstep and the GNU objc2 runtime, and I think the ones in Apple's
> libobjc don't depend on Foundation.
> You should be aware, however, that Foundation is usually regarded as the
> Objective-C standard library. It implements all of the core stuff that most
> programs will need, like collections, interfaces with the runtime system,
> and so on. Using Objective-C without Foundation is possible (obviously, as
> that's effectively what the authors of a Foundation implementation had to
> do), but it's a lot of work. You will find that GNUstep-base and
> libFoundation both provide implementations of Foundation that work on
> Windows. Cocotron might too, but they seem better at PR than writing code.
> -- Sent from my Apple II
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev