1998 – Okay, 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 Mac OS 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 (later named Mac OS X) would not support 68k.

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 PowerPC (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 operating system with Mac OS 7.6, was still dependent on 68k code within the System file to operate all of the Apple machines. Starting with Mac OS 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 it only works if certain functions aren’t used.

Here’s the quick list of non-native 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 68k emulator in every cycle.

Mac OS Extensions That Still Use 68k Code

• Appearance – 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 Appearance extension).
• 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 QT 3.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, etc. 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 while the developers have responded, Apple has decided to no longer update its 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 040s, and also the lockout of 030s. By installing a certain extention that makes an 030 machine appear to be an 040 machine (Pseud040 or Wish I Were), 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 Mac IIsi with 64 MB of memory running Mac OS 8.1, running four 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 are running slowly because of the bloat of 68k code its forced to run on each processor cycle.

It made sense when Apple was supporting two chips, but 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 to 8 times faster), but intending to lock out the 68k machines entirely.

I’m still waiting for the release of Mac OS 8.2 so I can try something out. I suspect that I can change the Gestalt ID of a 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

Scott L. Barber first posted this to Quadlist, the listserv for users of 68040-based Macs. It is reprinted with his permission.

These footnotes were not part of the original article. It’s interesting to see how Apple went 100% PowerPC with the migration to Mac OS X, and then in 2006 went back to an OS supporting two chip families – PowerPC and Intel x86. Mac OS X 10.5 Leopard had full support for both platforms until it was replaced by Intel-only OS X 10.6 Snow Leopard in August 2009.

As I write this at the end of September 2016, rumors are rampant that Apple will make yet another processor transition, this time from Intel x86 to Apple’s own ARM processors. After all, today’s iPhone 7 models are nearly powerful as the current MacBook Air, according to Geekbench 4 multi-core scores (5708 for the iPhone 7, 6543 for the 2.2 GHz Early 2015 MacBook Air). Could we be in for yet another CPU transition and another emulator?

1. Apple first supported PowerPC Macs with System 7.1.2 in March 1994, dropped support for 68000-based Macs and Macs without 32-bit clean ROMs with Mac OS 7.6 in January 1997, and claimed Mac OS 8.0 (July 1997) required a 68040 CPU, even though many 68030 Macs can run it with helper apps. Mac OS 8.5, released in October 1998 (a half-year after this article was published), was the first PPC-only version of the Mac OS, but even it continued to rely on the 68k emulator to run many system components – 4-1/2 years after the first PPC Macs had shipped.
2. The 68k emulator was developed by Eric Traut and has been part of the Classic Mac OS ever since System 7.1.2 shipped. It emulates the 68040 CPU and runs most 68k software. The emulator was completely invisible to the user. The original emulator was not particularly efficient. Because the 68k emulator is part of Mac OS 9.x, Classic Mode in Mac OS X (version 10.4.11 Tiger and earlier) can run most Classic Mac software. Connectix Speed Doubler included a much more efficient 68k emulator, along with other features to speed up the Classic Mac OS.
3. At Low End Mac, we are huge proponents of using MenuChoice instead of Apple Menu Options. It if much faster and far more flexible – and it runs on System 7.0.

Keywords: #68kemulator

Short link: https://goo.gl/RDvjmf