Re: "weak link" framework refs for 10.1 compatibility?
Re: "weak link" framework refs for 10.1 compatibility?
- Subject: Re: "weak link" framework refs for 10.1 compatibility?
- From: Bill Cheeseman <email@hidden>
- Date: Mon, 11 Nov 2002 14:51:56 -0500
on 02-11-11 11:27 AM, Marco Scheurer at email@hidden wrote:
>
> Also, I did never suppose that such an experienced programmer as Marco
>
> is would use such a self-evidently nonsensical example as using a
>
> constant from a header... Sigh.
>
>
Yeah, I did not understand the "C constant" part, reason why I was
>
surprised by a statement such as "an application using C constants that
>
are new in 10.2 will not launch in 10.1.x or earlier".
>
>
The fact that they are constant has nothing to do with the problem, the
>
problem is that they are externally linked C variables, or storage. Or,
>
said differently, in:
>
>
FOUNDATION_EXPORT NSString *const NSFileImmutable;
>
>
the runtime problem on 10.1 is not with "const", the error will be the
>
same with or without it.
It's my fault for giving sloppy descriptions. C is a second language for me.
:-)
The reason why I emphasize external constants is not that the behavior I'm
complaining about is limited to constants, but that there are a lot of them
-- and their behavior is different from that of functions. A 10.2 app that
calls new 10.2 functions will run under 10.0 and 10.1 if you branch around
them using a system version test. The same is not true of a 10.2 app that
refers to any of the new 10.2 external constants, of which there are many in
the new frameworks such as DiscRecording and AddressBook, and in a few other
places). Nor is it true of a 10.2 app that refers to a new 10.2 function by
testing its address against NULL. The dynamic loader treats function calls
and references to symbols differently, and it is usually one of the new
external constants that will be the cause of the problem.
You're all way beyond me on understanding the internals. I only got into
exploring this because I wanted to put up a gracious alert when somebody
tried to launch my application on 10.0 or 10.1 -- and the system refused to
launch my application to let me do even that little bit of a good turn for
my neighbors. I now understand enough of the reason why and the limited
range of workarounds, so I can go back to writing code.
It's a sad fact that, without heroic efforts, many apps that use newer
features will simply crash without warning when run under Mac OS X 10.0 or
10.1. This will be true forever, apparently, and it will be true of more and
more applications as time goes by because more and more new features will be
added to the commonly-used frameworks. Eventually, nobody except my
mother-in-law will be running 10.1, and then it won't matter any more. The
availability macros will work in the future to enable apps compiled on 10.3,
10.4, etc. to launch on 10.2, but never on 10.1 or 10.0. From a
backward-compatibility viewpoint, 10.2 is a significant watershed. It will
always be relatively easy to make future applications backward-compatible
with 10.2, compared to making them backward-compatible with 10.1 or 10.0.
In the interest of good customer experience, I think it would be great if
Apple provided an easy-to-use package of sample code and bundling
instructions so everybody could write their apps to launch and, if
necessary, quit gracefully under 10.0 or 10.1.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.