←back to thread

X and NeWS history

(minnie.tuhs.org)
177 points colinprince | 6 comments | | HN request time: 0s | source | bottom
Show context
wwweston ◴[] No.15325475[source]
> I have a section in the book that I'm writing where I talk about how to design a good API. I pose the question of why none of the original Apple Mac API published in 1985 taking about 1,200 pages is in use today whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is still in use and has been copied by many other systems. I'm sure that everyone on this list knows the answer.

I'm not sure I do. But it does seem like a good question.

Also:

http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...

replies(2): >>15325555 #>>15326484 #
valuearb ◴[] No.15325555[source]
My guess is that the original Mac OS provided a great GUI, but not much of an OS. It loaded a single application at a time that had access to all of memory. That's why it had desk accessories, to give you apps you could use without quitting the main application. It had handle based memory management so the OS could move memory blocks more contagiously to create enough open space for new memory allocations.

Over time they added cooperative multitasking, which meant the foreground app had to consciously give time to let background apps do stuff.

But they could never build a real OS with security and memory protection out of it. So Apple bought NeXT to get industrial strength unix as their core OS, and switched all Apple development to NeXTStep, or at least the modern derivative of it, called Cocoa.

My dust covered Inside Mac volumes were made useless nearly 20 years ago.

replies(3): >>15325585 #>>15326081 #>>15327274 #
1. __david__ ◴[] No.15325585[source]
Except most of the Inside Mac APIs were brought forward in OS X as Carbon. Carbon only went away relatively recently. So the APIs could support a reasonable OS, it's just Apple couldn't accomplish it for some reason (I waited for Copland for a long time).
replies(1): >>15325677 #
2. xenadu02 ◴[] No.15325677[source]
That is not correct. Over a thousand APIs were dropped or substantially modified to be “carbon clean”.

Even Multi-Finder was a lot of work because apps happily poked OS globals.

The original Mac OS was more like an embedded app toolkit than an OS. The original implementations were all ROM!

replies(2): >>15325985 #>>15326369 #
3. digi_owl ◴[] No.15325985[source]
And Woz has mused that this is why it got a reputation for malware resilience.
replies(1): >>15326220 #
4. kabdib ◴[] No.15326220{3}[source]
The early Macs were basically wide open, as I recall.

I was working in a group next to the systems software group at Apple when some of the early malware was discovered. After a few days of secrecy, with people being pulled into labs and conference rooms under spooky circumstances, the software managers sent out word that some malware had been found and that people were working on mitigations. They also said something like "Look guys, we know that writing malware is really easy, so don't do it, because we'll fire you immediately if we find out." I distinctly recall that this was in verbal instruction, not a memo, and that the words "really easy" and "really, don't do it" were used.

Naturally my response was to go back to my desk and write a proof of concept. Half an hour and a hundred lines of code later I had something that would replicate a payload whenever you inserted a floppy disk. It was indeed dead easy to do. I exercised my toy for a little while . . . then deleted every trace. I'm sure I wasn't the only engineer who was curious and did this.

So while you couldn't change the ROM, you could definitely muck with the system software, and that's all that really mattered. Zero thought had been given to MacOS security.

replies(1): >>15326717 #
5. __david__ ◴[] No.15326369[source]
I said most. Having worked on carbon apps, I can say that substantial portions went through with no changes. You could add menus and item to iTunes with AppendMenu() and InsertMenu() from visualization plugins until they rewrote it in Cocoa roughly 5 years ago.

Obviously they dumped a lot of the OS level APIs for stuff like Control Panels and Desk Accessories, but the standard app APIs were largely unchanged.

There's no fundamental reason they couldn't have made their own OS with the same Carbon APIs that made it into Mac OS X (not that I think they should have—the NeXTStep stuff was much better).

6. Someone ◴[] No.15326717{4}[source]
Wide open, indeed. For those who don’t know:

  - no memory protection.
  - system support for patching OS calls.
  - no distinction in privileges between application and OS code.
  - when mounting any disk, the OS opened a resource file on it
    and kept it open. Side effect was that the OS would look for
    code fragments defining windows, menus, and controls in that
    file. That file normally didn’t contain any, but adding a
    malevolent one to that file would mean the OS would run your
    code as soon as any program created a standard window, menu
    or control. 
(That last part was fixed after a virus exploiting it was found)