680x0 v. PPC Native Code

Scott L. Barber first posted this to Quadlist. It is reprinted with his permission.

OK . . . kind of a flame, but really specialized. I disagree that Apple should dump the 68k code simply because they want to isolate the 68040 machines from modern use. Two points.

Two years ago Steve Jobs stated that the old 8.x line would support 68k machines through the year 2000, providing updates ad infinitum as long as Apple chose to support an OS with an 8.x number. The idea was that releases would continue until 2000. And that the deal was that Rhapsody would not support 68k, and as people migrated away from Mac OS to Rhapsody, the customer base would take care of the need for higher Mac OS versions. The emphasis was on running two OSes for a while, and letting the customers jump ship to the PPC chip instead of the phase out that took place exactly like this years ago with the Apple II series.

Second. If Apple is going to dump the 68k processors, they need to dump the 68k code altogether. I'm still very upset that there is a bulk of system code that requires the 68k emulator just to run the system software. Apple, while first claiming a native OS with 7.6, was still dependent on 68k code within the System file to operate all of the Apple machines. Starting with 8.0, Apple again stated they were making their first native OS (deja vu), finally made the finder completely clean from 68k code, so that all kinds of finder operations including copy and search were now performed in pure native code. Unfortunately this only works in the Finder, and only works if certain functions aren't used.

Here's the quick list of nonnative extensions from Apple - extensions that actually overwrite PPC code with 68k code on every bootup and affect a variety of actions. Think about what these extensions do, and think about how much OS code is still running through the emulator in every cycle.

Appearance extension - this extension was originally written almost entirely in 68k code. In 8.1, this hasn't changed at all. A primary and necessary part of the system software under 8.x, requires the 68k emulator in order to do any of the myriad QuickDraw functions that it patches (Some of which are PPC codes, repatched with 68k code by the AE).

Apple Guide - expect slow help. This standard help dialog, including the menu bar, is written entirely in 68k code.

AppleScript

AppleShare/File Sharing Extensions

Contextual Menu Extension - Pop up menus are all in 68k

QuickTime 3.0, supposedly only good for PPCs, is written almost entirely in 68k code. So why doesn't it work on 68k machines with no FPU? (Because the emulator doesn't have an FPU either - but we'll still execute the bulk of the QuickTime code under it anyway). QuickTime 3.0 is a lockout of the older machines - out of convenience and the desire to push people to a new processor, not because the machine cannot perform the tasks. QuickTime 3.0 actually patches core native QuickDraw routines with 68k code.

Sound Manager (the version installed with QT3.0), patches QuickDraw. Don't know why, but it's replacing PPC code with a 68k patch as well.

Video Startup: Have an AV machine? Watch TV via the Video Startup extension? The system task is patched from PPC to 68k. This is a considerable slowdown on any machine that has the Video Startup extension. If you're not using your Video in or out, you should disable this puppy - it will help stabilize your machine.

Apple Menu Options: I cannot in good faith install this on anyone's machine, because it completely patches all of the menu routines to 68k code. So much for a fast finder when any menu bar must first be routed through the emulator just to display. For those of you crashing when editing HTML files in Communicator, simply because you're tapping your mouse around a menu - this is the culprit.

Control Strip and Date & Time have never been updated . . . they're completely 68k code. Date & Time patches the INitWindows string from a dual PPP & 68K code to a 68k code.

Now, with that said, almost every font utility from Adobe - Type Manager, Type Reunion . . . are all written in native code. Adobe extensions repatch nearly all of the font handling routines in the OS to native PPC - the ones that are patched are 68k code. It seems that Apple has screamed to developers to write everything native, and when the developers have responded Apple has decided to no longer update their system software simply because it would be useless - why do this if third party software groups will do it for us. . . .

I resent the lockout of non-FPU 040's, and also the lockout of 030's. By installing a certain extenuation that makes an 030 machine appear to be an 040 machine, Mac OS 8.1 can be installed on some 68030 Macs and all 68k programs that could normally be run on an 040 are capable on this machine. Apple is locking out machines by gestalt ID, not by capability. I have a IIsi with 64 MB of memory running system 8.1, running 4 MacHTTP domains, doing DNS, and handling mail through SIMS. No crashes, no instability.

Instead of being more forgiving about Apple's situation, I'd be questioning the internal programming costs that Apple is incurring by forcing 68k chips to not run 68k code.

I'm not flaming Doug, or Eric, just Apple. This standard that Apple takes is very familiar to me, and I'm bitter about it, even though I'm not under the 68k chip anymore. I feel like my PPC machines is running slowly because of the bloat of 68k code its forced to run on each processor cycle, but it made sense when Apple was supporting two chips. Now Apple is planning on keeping 68k code rampantly within the OS, making the OS require a G3 just to double the speed of the Pentium II (when it could be running 6 or 8 times faster), but intending to lock out the 68k machines entirely. I'm still waiting for the release of 8.2 so I can try something out. I suspect that I can change the gestalt ID of an Centris 610 (w/no FPU) to a Power Mac 6100/60, and still install and run 8.2. I mean, I have done this before. . . .

And yes, I'm still *issed.

Scott L. Barber <serker@earthling.net>

Pres/CEO, SERKER Worldwide, Inc.

Providing Hardware/Networking/Telecomm for 13 years

Quadlist, the listserv for users of 68040-based Macs. FAQ at <http://lowendmac.com/lists/quadlist.shtml>