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: Sat, 09 Nov 2002 13:38:27 -0500
on 02-11-09 10:02 AM, Dan Wood at email@hidden wrote:
>
Ah, but that's circular reasoning! :-) If I knew how to conditionally
>
load a framework if you were in 10.2, then I could apply the same logic
>
and only load the Address Book framework if I was in 10.2 or newer!
>
>
Dan
>
>
On Friday, November 8, 2002, at 02:17 AM, Bill Cheeseman wrote:
>
>
> I haven't tried this, but it occurs to me that you could try isolating
>
> your
>
> Address Book code in a separate framework, and have your application
>
> load it
>
> only if you're running under 10.2 or newer.
I don't think it's circular, although I do tend to run in circles a lot. And
as Ondra points out, I should have said "bundle."
Your application code calls one or more external constants in
AddresssBook.framework, which is new in Mac OS X 10.2. Right?
It isn't the loading of the non-existent AddressBook.framework that is the
problem when you try to run your app under 10.0 or 10.1. Your code could
branch around AddressBook.framwork calls to deal with that issue. The
problem I'm talking about applies even to frameworks that do exist in 10.0
and/or 10.1, but which declare a new external constant in 10.2. Branching
around the calls doesn't help.
It is not the calling of the new external constant that causes your app to
fail to launch. Instead, the problem is the mere presence of the reference
to the constant in your code, no matter how thoroughly you hide it behind
logical branches. The dynamic loader apparently gathers together all of the
symbols for external constants at the beginning of the launch. When it finds
a new 10.2 symbol while running under 10.0 or 10.1, it refuses to finish
loading your code. Attempting to branch around the new constant doesn't
help. The dynamic loader in 10.0 and 10.1 doesn't know anything about
weak-linked symbols, and it ignores your code logic while it is processing
the symbols while loading. (It would do this even if AddressBook.framework
implemented the availability macros, which it doesn't.)
So I propose putting your code that contains the call to a new constant into
a separate bundle. Make sure none of the headers in your main app code
refers directly or indirectly to the headers in the separate bundle, and
don't load the bundle when your application launches. After your main code
path tests for 10.2 and finds it running, use one of the NSBundle methods --
load, I guess -- to load your separate framework.
Why isn't that feasible? Like I said, I haven't tried it. But it seems like
it should work.
I'm currently working on an assistive application that uses the new
NSAccessibility.h constants. I haven't gotten to the point of testing under
10.0 and 10.1 yet, but when I do, I'll give this bundle idea a try.
Basically, my main application will be very small, consisting only of a test
whether 10.2 or newer is running, and an alert panel to quit if not. If 10.2
or newer is running, I'll lazily load a separate bundle that contains my
entire application code. (I wonder if I'll get two bouncing icons in the
Dock?) If this works, I'll post the code publicly -- unless somebody like
Ondra beats me to it, which I would welcome.
--
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.