calling conventions, stack structures, and register and data types for the PowerPC and CFM-68K implementations as well as for the classic 68K runtime architecture
It is for compatible S/W developement for 68K, PPC for Classic environment.
In the CFM-based architecture, a fragment is the basic unit of executable code and its associated data. All fragments share fundamental properties such as basic structure and method of addressing code and data. The major advantage of a fragment-based architecture is that a fragment can easily access code or data contained in another fragment. For example, a fragment can import routines or data items from another fragment or export them for another fragment's use. In addition, fragments that export items may be shared among multiple clients.
I think Avie meant PEF binary apps on OS X. Apparently anything invented at Apple is an anathema to the NeXTHeads.
PEF would probably have been better for Apple to use than Mach-O for many reasons (multiple binaries in a single file including alternate hardware versions of the same code).
CFM for PowerPC was doing just fine. Apple already had dev tools to produce the file format as did third-parties. CFM-68k was rather silly and a kludge to fix the niggling problems of the old architecture that CFM/PEF fixed (max 32k code modules loaded en-masse instead of in small chunks).
Mach-O was used because of some lame excuses such as "our open source UNIX derived development tools already support Mach-O" and basically the NeXTHeads are running Apple and simply can't stand any of its technology. NeXT must ultimately prevail or the originators will really feel like failures I guess.
For further clarity Apple had trouble getting Mach-O "native" apps on Mac OS X for several reasons.
The biggest one was waiting on CodeWarrior to make it over with the PowerPlant framework. Without that a lot of big apps were just not going to make it to the party until very late.
The Finder is a PowerPlant app as is Sherlock, notice how badly they sucked at first?
Also the Apple dev tools really sucked at first (and still do) for very large projects or when dealing with C++ code (of which many apps are made these days). Of course moving to a totally different executable binary format and application bundle really threw in a big wrench to the mix. Only Apple tools supported these new conventions at first with CodeWarrior finally catching up many months later.
Lastly the big one was that Carbon simply wasn't very good on Mac OS X until 10.1 (or 10.1.4 depending on what you wanted to do). Ironically Carbon on Mac OS 9 worked better than OS X.
Add that all up and you get fewer apps than Apple and the users wanted with almost all of the blame resting on Apple's blind obsession to ignore a lot of existing Mac technology that on its own was just fine (PEF/CFM, resource forks on HFS+ disks).
Comments
<strong>
5) Building better OS X apps
- Ditch CFM, go native
</strong><hr></blockquote>
What's "CFM"?
calling conventions, stack structures, and register and data types for the PowerPC and CFM-68K implementations as well as for the classic 68K runtime architecture
It is for compatible S/W developement for 68K, PPC for Classic environment.
==================================================
<a href="http://developer.apple.com/techpubs/mac/runtimehtml/RTArch-2.html"; target="_blank">http://developer.apple.com/techpubs/mac/runtimehtml/RTArch-2.html</a>;
------------------------------------------------
In the CFM-based architecture, a fragment is the basic unit of executable code and its associated data. All fragments share fundamental properties such as basic structure and method of addressing code and data. The major advantage of a fragment-based architecture is that a fragment can easily access code or data contained in another fragment. For example, a fragment can import routines or data items from another fragment or export them for another fragment's use. In addition, fragments that export items may be shared among multiple clients.
------------------------------------------------
<strong>Raycer technology can be use with 2D, 3D but Multimedia is differnt.</strong><hr></blockquote>
?? Exactly what do think multimedia is? Hint: 2D and 3D are parts of it.
Do you know what is HTPC is ?
Read this discussion:
<a href="http://www.avsforum.com/avs-vb/showthread.php?s=b2f18ab14dc7bc8abcd347de14329355&; threadid=30817&highlight=mac" target="_blank">http://www.avsforum.com/avs-vb/showthread.php?s=b2f18ab14dc7bc8abcd347de14329355&; threadid=30817&highlight=mac</a>
<a href="http://www.avsforum.com/avs-vb/showthread.php?s=939d6832ba6184c0048fc7e39daab1f8&; threadid=115718&highlight=mac" target="_blank">http://www.avsforum.com/avs-vb/showthread.php?s=939d6832ba6184c0048fc7e39daab1f8&; threadid=115718&highlight=mac</a>
<a href="http://www.avsforum.com/avs-vb/showthread.php?s=98ab516d2c9fa5bf1e12ec66f392f5fb&; threadid=29514&highlight=mac" target="_blank">http://www.avsforum.com/avs-vb/showthread.php?s=98ab516d2c9fa5bf1e12ec66f392f5fb&; threadid=29514&highlight=mac</a>
I think we will see what they have been hoping in near future.
[ 05-09-2002: Message edited by: kormac77 ]</p>
<strong>To me; use of MPEG-1,MPEG-2,MPEG-4 and MPEG-4 in future with Quicktime.</strong><hr></blockquote>
That's video - yet another part of multimedia. Notice a trend here?
PEF would probably have been better for Apple to use than Mach-O for many reasons (multiple binaries in a single file including alternate hardware versions of the same code).
CFM for PowerPC was doing just fine. Apple already had dev tools to produce the file format as did third-parties. CFM-68k was rather silly and a kludge to fix the niggling problems of the old architecture that CFM/PEF fixed (max 32k code modules loaded en-masse instead of in small chunks).
Mach-O was used because of some lame excuses such as "our open source UNIX derived development tools already support Mach-O" and basically the NeXTHeads are running Apple and simply can't stand any of its technology. NeXT must ultimately prevail or the originators will really feel like failures I guess.
The biggest one was waiting on CodeWarrior to make it over with the PowerPlant framework. Without that a lot of big apps were just not going to make it to the party until very late.
The Finder is a PowerPlant app as is Sherlock, notice how badly they sucked at first?
Also the Apple dev tools really sucked at first (and still do) for very large projects or when dealing with C++ code (of which many apps are made these days). Of course moving to a totally different executable binary format and application bundle really threw in a big wrench to the mix. Only Apple tools supported these new conventions at first with CodeWarrior finally catching up many months later.
Lastly the big one was that Carbon simply wasn't very good on Mac OS X until 10.1 (or 10.1.4 depending on what you wanted to do). Ironically Carbon on Mac OS 9 worked better than OS X.
Add that all up and you get fewer apps than Apple and the users wanted with almost all of the blame resting on Apple's blind obsession to ignore a lot of existing Mac technology that on its own was just fine (PEF/CFM, resource forks on HFS+ disks).
Thank you.