Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
- Subject: Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
- From: "email@hidden" <email@hidden>
- Date: Tue, 06 Sep 2011 21:55:57 +0100
On 6 Sep 2011, at 19:47, Jens Alfke wrote:
> Linking against the 10.6 libraries is the correct behavior if the app hasn’t been fully updated to use 10.7 features/behaviors. There are a lot of cases where a system framework will change its behavior based on which version the app linked against, as a backward-compatibility measure. For this reason, changing the SDK setting in Xcode can often set you up for a lot more work than you’d intended, as it can break your app until you update your code accordingly.
>
> (If you want an example: starting in 10.5, AppKit started tracking ref-counts of NSFont objects. Before that there was a bug in which they were never dealloced. Unfortunately there were apps that kept NSFont instances around without retaining them. To keep these apps from crashing on 10.5, NSFont would keep the old always-retained behavior for apps linked against the 10.4 SDK, but not the 10.5 SDK. This was called out in the release notes, but who reads every line of the release notes? So some developers found out by seeing their apps start to crash after they innocently changed the SDK setting from 10.4 to 10.5.)
Surely the choice of SDK normally only has an effect at build time.
My understanding is that the SDK frameworks are there to provide feedback during the linking that is performed as part of the build.
When the app is actually run the dynamic linker links to the specified versions (A, B, C, etc) of the system frameworks as specified in the binary (see otool -l).
The binary knows nothing about the SDK (correct me on this if I am wrong).
Behaviour that arises as the result of switching the SDK normally only effects execution if it results in the app linking to a different system framework version (A, B, C etc).
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/cross_development/Overview/overview.html#//apple_ref/doc/uid/20002001-BABEBGCF
The fact that most of the system frameworks only seem to contain a single version (appkit is at C) suggests that the runtime effect of compiling with different SDKs is normally minimal.
Of course, running on a new release often sees applications break but this is mainly as a result of framework bug fixes, subtle changes in behaviour or unjustified assumptions about black boxes.
In most cases I don't think that linking against an older SDK will prevent the need to port apps to new OS versions.
However the above link states:
"As a backward-compatibility mechanism, Apple frameworks sometimes check for the version of the SDK an application is built against, and, if it is an older SDK, modify the behavior for compatibility. This is done in cases where Apple predicts or discovers compatibility problems.Typically, frameworks detect how an application is built by looking at the version of the system frameworks the application is linked against. Thus, when relinking your application using a newer SDK, you might notice different behaviors—some of which might cause incompatibilities. In these cases, because your application is being rebuilt, you should address these issues at the same time. For this reason, if you are doing a small update of your application, to address a few bugs, for example, it's usually best to continue building with the same build environment and libraries used originally; that is, against the original SDK."
To me this means that a framework will make its judgement of whether to modify its internal behaviour based on introspecting the application linkage.
This behaviour though seems to be rare and implementation details scare on the ground.
Regards
Jonathan Mitchell
Developer
Mugginsoft LLP
http://www.mugginsoft.com_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden