I never intend to do what Apple did in their exact way. That is illegal even in
PRC. My intention is to a) write test cases around documented API that both
GNUstep and Apple have and capture what Apple emit from them and b) replicate
this result in a reasonable way using GNUstep, not caring if the implementation
detail is the same. If I ended up doing it the exact way, well lucky me… I have
no idea how Apple did that unless it is something open-sourced (and I guess I
can link LGPL code against APSL code, right?) and I have no intention to clone
it in a full blown way, just the surface behavior.
So before I say anything more, just giving an example, in my implementation of
toll-free bridging the "type ID" is useless, as CoreFoundation objects are
identified by their companion classes. Here is a sneak peek of what my propose
is.
@protocol GSTollFreeBridging <NSCopying, NSObject>
- (CFTypeID)typeID;
// ...
@end
// Here is an example of toll-free bridged object, NSString versus CFString
@interface NSString : NSObject <GSTollFreeBridging>
// …
@end
@interface GSCFString : NSString
@end
typedef struct __CFString
{
Class isa;
// ...
char *buf;
// …
} *CFStringRef;
CFStringRef CFSTR(consr char *str)
{
// Just being quick and dirty
CFStringRef string = malloc(sizeof(struct __CFString));
assert(string);
memset(string, 0, sizeof(struct __CFString));
string->isa = [GSCFString class];
// …
}
CFTypeID CFGetTypeID(CFTypeRef obj)
{
id<GSTollFreeBridge> self = (__bridge id)obj;
return [self typeID];
}
CFTypeRef CFRetain(CFTypeRef obj)
{
return (__bridge CFTypeRef)objc_retain((__bridge id)obj); // Oh yes,
ARC-enabled.
}
void CFRelease(CFTypeRef obj)
{
objc_release((__bridge id)obj);
}
@implementation GSCFString
- (void)dealloc
{
CFStringRef string = (__bridge CFStringRef)self;
if (string->buf)
{
free(string->buf);
string->buf = NULL;
}
// …
}
// …
@end
// Here is an example of non-TFB'd object, CFRunLoop. It will have an isa
pointer of this class.
@interface GSCFRunLoop : NSProxy <GSTollFreeBridge>
// …
@end
在 2013-6-5，上午1:52，Ivan Vučica <[email protected]> 写道：
> Maxton,
>
> On 4. 6. 2013., at 19:27, Maxthon Chan <[email protected]> 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
> [email protected] - http://ivan.vucica.net/
>
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
