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

[Ivan Vučica]

Maxton,

On 4. 6. 2013., at 19:27, Maxthon Chan <address@hidden> wrote:

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?

I'm sure most of the GNUstep community is very confident both Apple and David know what they are doing, and that David knows just enough about what Apple is doing without compromising his or GNUstep's legal position :-)

Besides, why is this technical detail about library relationships important? We need to have similar behavior, not exact implementation. If GNUstep does or can do things differently without confusing the end user or breaking expectations, that's better from a legal (and, perhaps more importantly, moral!) standpoint.

I'm all for as much compatibility with Apple implementation as possible. But, I was told enough times on these very lists that GNUstep doesn't need to be a clone of anything. And I agree.

My Core Animation implementation, for example, does not do things "the Apple way". And I mean that on the deepest level. One can accidentally, without digging, see in the backtrace of a crashing program that Apple implemented Core Animation in C++. I didn't. Their implementation will perhaps be faster even when the GNUstep implementation is optimized and reoptimized and reoptimized. My implementation, however, does not really have to differentiate between animatable and non-animatable properties too much. I don't know if theirs internally does; but their docs talk about it as if it does.

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.)

I attended Stallman speeches here in Zagreb, one of them relating to patents.

Let's just say that sometimes you don't even have to study someone's code to be infringing on a patent.

And Apple has DEFINITELY accepted a lot of things that they later pulled; even their own rulebook says that thing happens. For example, recently they let through a full-blown emulator, something they really don't like. That doesn't mean we should take it for granted.

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.

This, I think, is good enough, as long as you don't go out of your way to replicate exact implementations.

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.

Of course you don't have access, that's the 'reverse engineering' part :-)

It's a thin line between reimplementing and outright cloning, though. David is making a very strong point here about GNUstep already having a different implementations of the runtime, with its own strengths and weaknesses compared to Apple's implementation. Do we need to replicate every detail of their implementation? :-)

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.

Sure, the primary purpose of classdump is reverse engineering. At issue is what's done after dumping the headers :-)

Most people do useful stuff on Apple platforms; I'm sure Apple won't object too loudly to, for example, Dropbox hacking into Finder to deliver better experience.

If a different implementation of one of their main products starts poking deep into the system in order to replicate it? Well, you know what happened to Samsung for replicating visual identity.

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.)

Now, now. That's actually not a nice statement from you. Although it might seem selfless, it's in fact selfish.

Imagine the "risky" knowledge you obtained gets used by a company in a commercial product. (Neither GPL nor LGPL object to commercial use within their terms.) Now, this company gets in trouble. You're safe inside P.R.C.; what about this U.S. or U.K. company? What's the legal climate in Japan?

It's good that GNUstep keeps caring about legal issues; this makes it more possible that someday a new midsize or large corporate contributor appears and joins the party.

--

Ivan Vučica

address@hidden - http://ivan.vucica.net/