MIB-Libraries/MoreCodeFragments/CFMLateImport/CallMachOFramework/Read Me CallMachOFramework.txt

Read Me for CallMachOFramework
 
1.0a2
 
This sample shows two ways of calling a Mach-O framework from a CFM application on Mac OS X.  Both approaches create a CFBundle for the framework and then extract pointers to functions in the framework using CFBundleGetFunctionPointerForName. The simpler approach approach just gets a pointer to the framework function, casts it to appropriate C function pointer type, and calls it. The more complex, but more general, approach uses CFMLateImport technology to bulk import functions from a framework without any messy function pointers.
 
The sample should run on Mac OS X 10.0 and above. I tested it on Mac OS X 10.1.
 
Packing List
 
The sample contains the following items:
 
¥ Read Me for CallMachOFramework Ñ This document.
 
¥ CallMachOFramework.mcp Ñ A CodeWarrior Pro 7 project file. This file has two targets: one implements the function pointer approach and the other implements the CFMLateImport approach.
 
¥ÊCallMachOFramework.c Ñ The sample source code. The same source is used for both approaches. The behaviour is controlled by a compiler variable set using one of the two prefix files.
    ¥ UseFunctionPointers.prefix Ñ Prefix file for the Using FuncPtr target.
    ¥ UseCFMLateImport.prefix Ñ Prefix file for the Using CFMLateImport target.
 
¥ CallMachOFramework.r Ñ A 'carb' resource. A real application should have a 'plst' resource instead, but this simple test doesn't need it.
 
¥ CallMachOFramework Late Ñ A compiled binary of the Using CFMLateImport target.
 
¥ CallMachOFramework FuncPtr Ñ A compiled binary of the Using FuncPtr target.
 
¥ÊSystem Framework Stub Ñ When using the CFMLateImport approach you have to cook up your own CFM stub libraries for the routines you need to import from Mach-O. This folder contains an example of such a library, and instructions on how to build one.
 
¥ÊMoreIsBetter Bits Ñ Components of the DTS sample code library MoreIsBetter that are required to compile the sample.
 
Using the Sample
 
To run the sample, simply double click either ÒCallMachOFramework FuncPtrÓ or ÒCallMachOFramework LateÓ in the Finder. The sample calls the BSD function gethostname (a Mach-O only routine in the System framework) and prints the result.
 
Building the Sample
 
The sample was built using the CodeWarrior Pro 7 environment.  You should be able to just open the project, select the appropriate target, and choose Make from the Project menu.
 
How it Works
 
Both approaches need to start by creating a CFBundleRef for the System framework.  I do this by finding the Frameworks folder using FindFolder and then accessing the System framework by name within that folder.
 
Once I have created a bundle the approaches diverge.  For the function pointer approach I just call CFBundleGetFunctionPointerForName, cast the result to the appropriate function pointer, and call it. For the CFMLateImport approach I call CFMLateImportBundle (part of MoreIsBetter) to fix up the weak linked routines so that I can call them directly without any messing around with function pointers.
 
The approach you choose depends primarily on the number of Mach-O routines you need to call. If you need to call just one or two Mach-O routines, the CFBundle approach is simplest. However, if you need to call lots of them, the CFMLateImport approach pays off big time.
 
Caveats
 
Using CFMLateImport technology is somewhat tricky. Read the comments in "CFMLateImport.h" for details. Some things you have to remember:
 
¥ You must have a fragment initialiser.  Your best bet is to copy the FragmentInit routine from "CallMachOFramework.c"
 
¥ To minimise the late import memory use you should turn off PEF data packing for your application. In CodeWarrior Pro 7 this translates to checking the "Expand Uninitialized Data" checkbox in the PPC PEF panel of your target settings.
 
If you call Mach-O routines that have a callback (for example, the BSD signal function) you must do some extra work for your callback. See the sample CFM_MachO_CFM (part of the CarbonLib SDK) for details on doing this.
 
This sample does not currently support importing data symbols. CFBundle now has an appropriate routine for this (CFBundleGetDataPointerForName) but there hasn't been a high demand for this feature so I haven't implemented it.
 
Credits and Version History
 
If you find any problems with this sample, mail <DTS@apple.com> and we will try to fix them up.
 
1.0d1 (Nov 2000) was a pre-release version distributed to Apple reviewers and a small number of developers.
 
1.0a1 (Nov 2000) was the first shipping version.
 
1.0a2 (Sep 2001) is a maintenance release to sync up with the latest CFMLateImport code and to address some other minor concerns. The code now has more comments!
 
Share and Enjoy.
 
Worldwide Developer Technical Support
 
21 Sep 2000