Hacker News Reader

Comment by kmeisthax | Hacker News Reader

Yes. The idea wasn't to get away with not having an MMU, though - it was to get away with shipping the Mac with an ungodly low amount of RAM for a machine with a GUI. I believe the original idea was to ship with like 64k or something?

Obviously, with the state of mobile hardware back then relocatable blocks were also similarly necessary in order to save RAM.

For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking. The MMU is necessary to keep applications from writing other apps' heaps, not to do memory defragmentation. You can do some cool software-transparent defragmentation tricks with MMUs, but if you're deciding what the ABI looks like ahead of time, then you can just make everyone carry double-pointers to everything.

View on HN

Well, there's also the fact that the MC68000 in the original Mac didn't have an MMU, and it was difficult to add an external MMU to a 68000 system [1]. You could use an MMU sanely starting with the MC68010, and it wasn't until I think the MC68030 that the CPU came with an integrated MMU.

[1] Because exceptions on the 68000 didn't save enough information to restart the faulting instruction. You could get around this, but it involved using two 68000s as insane hack ...

Just to muddy the waters some more there was also an EC variant¹ of the 030 without the MMU.

The EC variant was available right through to the 060, and I'd be curious to know how prevalent the line was. I suspect the EC versions far outnumbered the "full" chips, because they appeared in all kinds of industrial systems. I'm basing that entirely on working for a company that was still shipping products with MMU-less 68k and coldfire this century, not any real data.

¹ https://en.wikipedia.org/wiki/Motorola_68030#Variants

And there's more mud to be found! The 'EC' version of the 68040 & 68060 was "no MMU, no FPU", and there was an 'LC' variant of the 68040 & 68060 that was "MMU, no FPU".

There were huge numbers of embedded 68k family chips shipped, although I've never seen the actual numbers. Folks went from 68000 to 68ec020 to 68ec060 as a (sorta) easy upgrade path. They're still made if you count the 68sec000, and the 68300 line is the spiritual successor.

You could use an MMU sanely starting with the MC68010

Whether the Motorola MMU for the 68010 (the 68451) was sane or not is a matter of some debate. The 68451 was definitely slow and limited (segments, not pages); in the end, most vendors rolled their own MMU out of static RAM and PALs.

I actually installed an aftermarket MMU in my Macintosh II, since it's required for A/UX.

https://retrocomputing.stackexchange.com/questions/10931/wha...

https://aux-penelope.com

> I believe the original idea was to ship with like 64k or something?

Yes. Both the 6809 based design and the first 68k one targeted 64k. See https://folklore.org/Five_Different_Macs.html

I believe the original idea was to ship with like 64k or something?

I believe the original original idea was 64K and a 6809 instead of the 68000. Quickly became clear that wasn't going to live up to expectations.

> For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking

Yeah, the way to port classic MacOS apps to native OS X apps was called Carbon, and it was basically 80% of the classic MacOS toolbox just ported to OS X, Handles and QuickDraw and all. Classic MacOS apps written to CarbonLib would "just run" natively in OS X (and the same binary in Classic MacOS). Carbon even kept working on Intel MacOS, but they finally killed it with the 32-bit deprecation a year or two before Apple Silicon was released.

Apple could have worked in multitasking in classic MacOS if they really wanted to, but their management was totally dysfunctional in the 90's where there was no point seen in investing in boring old MacOS since there was always a revolution just around the corner in the form of Pink, Taligent, Copland etc, projects which due to the aforementioned management never went anywhere.

> Apple could have worked in multitasking in classic MacOS if they really wanted to

They did, and they couldn’t. Most users had some code running that patched system calls locally or globally or that peeked into various system data structures, and all applications assumed the system used cooperative multitasking. Going from there to a system with preemptive multitasking would mean breaking a lot of code, or a Herculean effort to (try to) hack around all issues that it caused with existing applications. I think that would have slowed down the system so much that it wasn’t worthwhile making the effort.

Having said that, MacOS 9 had a preemptive multitasking kernel. It ran all ‘normal’ Mac applications cooperatively in a single address space, though. Applications could run ’tasks’ preemptively, but those tasks couldn’t do GUI stuff (https://developer.apple.com/library/archive/documentation/Ca...)

Microsoft actually sort of did that with Windows 9x.

There was a lot of Windows 3.1 and DOS software and drivers that they wanted to remain compatible, and those relied on DOS quirks. So, they had a copy (copies) of DOS always resident in RAM, mostly unused. All DOS syscalls (interrupts) were hooked so that they would call Windows instead. If a program added its own hooks, Windows would detect that and switch to 16-bit mode for the relevant operation. When the custom hook completed, it would call the next hook in the chain, which was the one that went back to Windows. Of course, this relied on Windows understanding DOS's internal data structures and keeping them in sync with what Windows was doing. A similar technique was used for drivers, if Windows found a driver it didn't understand, it would let that driver run in 16-bit mode.

Raymond Chen (of Microsoft fame) explains this much better than I ever could https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

> classic MacOS toolbox just ported to OS X

There was a company that re-implemented the macos toolbox on various Unixes. I hope somebody on HN worked there and can fill in more details.

Tldr; from [0]

The company was orignally Quorum Software Systems, Inc. which transformed into -> Latitude Group in 1994, and which got bought by Metrowerks in 1996-7?.

The original product was called Equal, and allowed Microsoft Word 5.1a and Excel 4.0 (the macos versions) to run on UNIX, with native [Motif?] look and feel and good performance without source code.

they later made a library called 'Latitude' so macos App developers could easily port their apps to Unix, which was how the Adobe Apps - Photoshop / Illustrator etc. got made available for Unix. .. and Latitude also apparently implemented a lot of QuickDraw.

"At the heart of Latitude is our own Portable Toolbox Implementation Layer. This layer is completely platform independent. It presents the Mac Toolbox API to the application, answers these calls through a trap table mechanism, and relies on other toolbox calls within the layer whenever possible. When a native system facility is needed, such as the display of a window or control, or some graphical rendering, this layer calls out to one of Latitude's platform dependent modules through an internal, well defined API. The toolbox layer doesn't know what kind of system lies underneath, only that calling this function will display a window or that function will draw a line, etc.

.. Because we've mapped native system facilities to Mac calls, the running application is an equal citizen on the desktop. The application's windows, menus, and control items are native system objects. Cutting and pasting between apps is facilitated by the native system's clipboard mechanism. Fonts come from the system font server -- including the default system font, which means the dialogs come up in something other than Chicago! Application windows are native windows -- not some rendering of a window inside of another. The performance hit is minimal. Latitude is merely mapping the Mac calls to the native system. There is very little processing going on in between. "

[0] http://preserve.mactech.com/articles/mactech/Vol.13/13.06/Ju...

That's amazing!

neat

Reply on news.ycombinator.com