[Pythonmac-SIG] EMBEDDED MacPython (Carbon) + OSX - should this work?

Steven Majewski sdm7g@Virginia.EDU
Fri, 14 Dec 2001 17:24:00 -0500 (EST)


On Fri, 14 Dec 2001, Paul Miller wrote:

> >It depends (doesn't it always:-). If your app (or shared library) is
> >CFM-based then MacPython is the best choice, but if it is Mach-O based
> >then unix-Python is better.
>
> Okay, you will have to forgive my ignorance - I'm new to OSX and not much
> of a "Mac guy" in the first place. What is CFM? If this means that the host
> app is OS9/OSX compliant (ie. Carbonized and OSX compatible), then yes.

CFM is short for Code Fragment Manager, although I think PEF (which
stands for Preferred Execution Format, I think.) might be more accurate:
PEF is the object code format which CFM uses for PPC code.
But CFM is usually used for shorthand to refer to the whole classic PPC
runtime architecture: PEF & the API used for loading dynamic libs
( and sometimes things like the Mixed-Mode manager, for supporting
  both 68K and PPC code -- which didn't make it into Carbon. ).

The other choice on OSX is mach-o, which is the native object format used
for OSX's Darwin (BSD+mach) core. Also sometimes used as shorthand for
the whole architecture it drags along with it (especially another
set of API for dynamic libs, and tools like gcc and gdb. )


 Classic apps are always CFM.
 Carbon apps can be CFM based (in which case they can also run on OS9),
or mach-o (in which case they are OSX only.)
Just like you could make Fat binaries for earlier systems, you can
also build apps with both CFM and mach-o code (I think!)
 I think Cocoa apps are always built mach-o format because that the
only format supported for the Cocoa libs (which don't have to be
OS9 compatible.)

 Another orthogonal issue is how apps are packaged: Resource/Data forked
files or Bundles.


-- Steve Majewski