[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: __NSCF** classes and libobjc2 dependency on C++ runtime

From: Maxthon Chan
Subject: Fwd: __NSCF** classes and libobjc2 dependency on C++ runtime
Date: Wed, 05 Jun 2013 01:27:56 +0800


发件人: Maxthon Chan <address@hidden>
主题: 回复: __NSCF** classes and libobjc2 dependency on C++ runtime
日期: 2013年6月5日 GMT+0800上午1时20分19秒
收件人: David Chisnall <address@hidden>

My reason on saying that you may not be clear what Apple is doing:

It seemed to me that you have totally ignored what happened in the Apple land in the recent years. What you did matched 10.6 behavior (I still have a 10.6.7 disk with Xcode 3.x lying around somewhere and I have hacked my VMware Fusion installation) but in 10.7 and 10.8 Apple changed a lot. Did you notice that in 10.8 CoreFoundation is linked against libobjc on both i386 and amd64, in 10.7 only amd64, but in 10.6 it was not?

Well before you ban me for "legal reasons":

1) Apple exposed and documented all the interfaces I used to learn its internals (Actually Apple are never good at hiding them.). The poking-around code can even be accepted to iOS App Store, as someone on StackOverflow have previously did, multiple times. (And you know that Apple rejects any code that violates their T&C from App Store.)
2) All conclusion is based on what I fed into the public API and what it spit out, like NSLog("%@", NSStringFromClass([(__bridge id)CFSTR("foo") class])); - I dumped whatever it spit out from NSStringFromClass() function given I fed it a class from a toll-free bridged CoreFoundation object. This is at most like writing test cases around it.
3) No Apple code is used. I don't even have access to them, and I am not interested in reverse engineering it. And whatever code I may commit is at most mimicking Apple's behavior, based on whatever the previous experiments tell me. That is, after I captured what Apple code emit from my experiments, I write code to make GNUstep (my own fork) libraries do the same. (well, maybe __NSCF* became GSCF*) with the same parameters.

Just an interesting side note about this, there is a tool called classdump that will dump framework header files from Objective-C binaries, its sole purpose is to reverse engineering, but it faced zero issue from Apple. And what I did does not even involve that.

And if Apple intend to sue anyone, let them sue me, in the US Calif. laws. (I am currently a citizen of P.R. China, and fighting a copyright lawsuit is not exactly easy here for Apple - laws are steered in a way that it may protect natives when foreigners sue natives.)

在 2013-6-5,上午12:49,David Chisnall <address@hidden> 写道:

On 4 Jun 2013, at 15:45, Chan Maxthon <address@hidden> wrote:

Indeed I am not that sure about how GNUstep currently handles exceptions but I am giving you ideas from some crash reports with symbols from an Apple system.

You are not giving me ideas.  We already have an implementation of this that works better than the Apple implementation.  Why would you:

1) Think I didn't know how the Apple implementation works?  I talk fairly often to the developers of Apple's compiler and runtime?
2) Think that I would need you to explain how to implement something that I already have working?

And the conclusion on toll-free bridging is about the latest Apple implementation. You should really get a Mac and poke around. Just for your information, what I poked around with is OS X 10.8.3 and iOS 6.1.3, both.

I have a Mac, but reverse engineering at this level of detail is of dubious legality.  By posting this kind of thing, you potentially open GNUstep developers up to legal problems.  And, for this, we should thank you?

With non-fragile ABI it is almost impossible to construct a C struct that can perfectly mirror Objective-C objects' memory layout, especially under some corner circumstances.

That's what the non-fragile ABI means and why @defs() is not permitted with the non-fragile ABI.  

If you want to poke around in the internals of OS X, then that's fine.  Have fun, learn things.  But please be advised that:

1) You are most likely breaking Apple's T&Cs.
2) As a result, we most likely can't accept any code from you.
3) If you are going to post the results of anything other than the input-output semantics of Apple's functions, then we will need to ban you from the lists to avoid legal complications.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]