下面是被转发的邮件：
> 发件人: Maxthon Chan <[email protected]> > 主题: 回复： __NSCF** classes and libobjc2 dependency on C++ runtime > 日期: 2013年6月5日 GMT+0800上午1时20分19秒 > 收件人: David Chisnall <[email protected]> > > 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 <[email protected]> 写道： > >> On 4 Jun 2013, at 15:45, Chan Maxthon <[email protected]> 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. >> >> David >> >
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
