Re: [Cocoadev] Problem becoming a good citizen and backwards compatible [solved]
Re: [Cocoadev] Problem becoming a good citizen and backwards compatible [solved]
- Subject: Re: [Cocoadev] Problem becoming a good citizen and backwards compatible [solved]
- From: Alexander Griekspoor <email@hidden>
- Date: Mon, 15 Aug 2005 09:15:44 +0200
Hi Brian and Aaron,
Indeed the solution Brian suggested is probably the most appropriate,
and was suggested at the WWDC when I brought up the problem. In the
end I solved the problem in a far simpler way, sure not the most
elegant way, but sure the most simplest. What apple did when moving
the DiskArbitration framework from the PrivateFrameworks to
Frameworks folder was to create a symbolic link in the
PrivateFrameworks folder for backwards compatibility. Old apps are
simply redirected to the new location when looking for the
DiskArbitration framework. Now this is where the problem is with
XCode, everytime you add the framework to your project, it resolves
the link to the public Frameworks folder and your app won't run on
Panther. At WWDC the XCode people told me you can only prevent this
by editing the xcode project file by hand, ouch. But the solution is
far simpler as my friend Phil came up with a brilliant idea:
- I just copied the Tiger framework from the (public) Frameworks
folder (make sure you set privileges properly) and used it to replace
the symbolic link in the PrivateFrameworks folder. So on my dev
machine I have to real copies of the framework (not a clue if this
will ever lead to problems, but haven't seen a sign of it yet).
- Now I could simply add this framework in the PrivateFrameworks
folder to the project without XCode resolving the symbolic link
- Then I set the SDK of the project to 10.3.9 and the target OS to 10.3
- This gives another problem you have to solve, as the framework is
private on 10.3 the headers are not available in the SDK and you get
compiler errors. To resolve this I simply copied the 4 public Tiger
headers of the DiskArbitration framework to my project and replaced
in those files all occurrences of style <Diskarbitration/Disk.h> with
"Disk.h" (so referencing to these project specific files instead of
the framework headers).
- Finally, also in my app's code I now reference to these project
specific headers instead of the framework: <Diskarbitration/
Diskarbitration.h>.
Compiler happy, everyone happy.
Voila, works like a charm on both Tiger and Panther! Again, I might
have been lucky and this may be a specific solution for the
DiskArbitration framework.
Cheers,
Alex
Ps1. To answer my own question raised earlier, the SDKs do list all
the private frameworks as well, checked it out in the Developer/SDKs
folder...
Ps2. One thing that hasn't worked till date is the use of the private
methods in the DiskArbitration framework I used to make use of, I was
forced to only use the (now) public APIs, but I guess that's a good
thing anyway ;-) Anyone a clue why that stopped working?
On 15-aug-2005, at 8:24, Brian Smith wrote:
As another suggestion that I haven't tried, bundles seem to be more
flexible than frameworks and they are easy to load at run time with
NSBundle. You may want to factor out the code that calls the
DiskArbitration framework into a facade class that you put into
the bundle then compile the bundle into two versions-one for
panther and one for tiger. The advantage of a facade would be you
can handle any renaming, missing functionality, or additions you
want. In the main program you would check for the public version
of the DiskArbitration framework, and load the bundle that is
linked to the correct version of the framework. (Check using the
normal way to check weak linked frameworks and functionality.)
Regards,
Brian
On Aug 15, 2005, at 9:04 AM, Aaron Burghardt wrote:
Here are a couple ideas I haven't tried:
1. Do your own custom linking. Add the flag "-v" to Other Linker
Flags and you will see in the build details the actual command
that libtool uses to invoke ld. You might be able to delete the
executable that Xcode produces and link the product with a custom
ld to get the PrivateFrameworks path.
2. Factor out your DiskArbitration code to a framework and build
just that framework on Panther. Hopefully you can keep that code
small so you don't need to recompile often.
3. Edit the executable with a hex editor to change the path to the
PrivateFrameworks.
On Aug 13, 2005, at 3:59 AM, Alexander Griekspoor wrote:
Hi all!
I have the following problem: under Panther our program disctop
made use of private APIs from the Diskarbitration framework,
ouch. However, these have becoming public under Tiger, hooray!
The problem is that the framework thus moved from /System/Library/
PrivateFrameworks under Panther to /System/Library/Frameworks
under Tiger. For compatibility reasons there's still a symbolic
link in the private frameworks folder to the new location.
The problem is that I can't get my app to work under Panther
while building it on my Tiger machine using the current OS SDK.
The console reports that it can't find the framework. If I have
it build using the 10.3.9 SDK it starts to complain that it can't
find the framework already during compile time. Does anyone have
experience with this kind of situation? Should it normally work
to link to private frameworks and target previous OS's?
Any suggestions are more than welcome, the last option is always
to ship a Tiger and Panther version of my app, but I would like
to avoid at all costs, plus at this moment I can't any Panther
version at all on my Tiger machine...
Alex
*********************************************************
** Alexander Griekspoor **
*********************************************************
The Netherlands Cancer Institute
Department of Tumorbiology (H4)
Plesmanlaan 121, 1066 CX, Amsterdam
Tel: + 31 20 - 512 2023
Fax: + 31 20 - 512 2029
AIM: email@hidden
E-mail: email@hidden
Web: http://www.mekentosj.com
Windows is a 32-bit patch to a 16-bit shell for an 8-bit
operating system, written for a 4-bit processor by a 2-
bit company without 1 bit of sense.
*********************************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden