gnustep-dev
[Top][All Lists]
Advanced

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

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


From: Maxthon Chan
Subject: Re: __NSCF** classes and libobjc2 dependency on C++ runtime
Date: Wed, 05 Jun 2013 01:50:54 +0800

If you are worried about legal issues, just see how happily ReactOS project is 
going. Their aim is a *complete Windows clone* that is *binary compatible* and 
Microsoft have no issue with them. If Apple have an issue about this, they 
should have already sued FSF and shut this project down.

在 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.
> 
> David
> 




reply via email to

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