The Challenges of Integrating the Unix and Mac OS Environments (2000) • Hacker News Board

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#21

Post by tobr » Wed, Mar 10, 2021, 5:42 PM UTC

m463 wrote: post #18

pwinnski wrote: post #2

I still remember being in awe that they pulled this off at all, clumsy as some of the compromises were. Newer filesystems and application designs have eliminated many of the differences, although I still miss resource forks.

I think resource forks suck. That said, I think metadata about a file outside of the file has always been problematic. I don't know if there's ever been a clean solution to timestamps, r/w/x, ACLs and more.

I’m curious, could you expand a little bit on why you think resource forks suck?

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#22

Post by jonjacky » Wed, Mar 10, 2021, 5:44 PM UTC

bluejekyll wrote: post #20

jonjacky wrote: post #17

Earlier quoted context omitted.

Yes, I do. I recall they had ads where they showed the amazing things you could do with one-line commands at the shell - they had examples of pipelines including grep and awk etc. I remember being amused that these familiar idioms that had been used in the Unix/Linux world for ages were being presented as amazing new capabilities.

For Mac users, this was a new capability. Before that, I was always using remote X sessions to get onto shared Unix systems.

What I found amusing at the time was, after years of touting the Mac point-and-click interface as a great improvement over the old-fashioned hard-to-learn obscure command line, they switched to touting the unprecedented power and versatility of ... the command line!

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#23

Post by geraldcombs » Wed, Mar 10, 2021, 5:47 PM UTC

asveikau wrote: post #7

klodolph wrote: post #4

Earlier quoted context omitted.

I feel the modern approach takes the main strengths of resource forks and builds on them—instead of needing to use ResEdit, all of your application resources are just ordinary files stored in a directory. Images are stored in standard formats like PNG, data is often stored in plist or text formats.

Maybe somebody who knows classic Mac well can correct me here if I'm wrong, but I feel like resource forks were also solving a "constrained memory and an OS that didn't do paging" problem. So the library deciding how to load and possibly when to evict sounds like it was kind of the point. Simulating what might be the job of mmap() on a modern system.

It made applications portable in the "move it anywhere on the system" sense. I dimly recall dragging commonly-used applications to my desktop, particularly before support for aliases (similar to Windows shortcuts) was added.

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#24

Post by rvense » Wed, Mar 10, 2021, 5:48 PM UTC

asveikau wrote: post #7

klodolph wrote: post #4

Earlier quoted context omitted.

I feel the modern approach takes the main strengths of resource forks and builds on them—instead of needing to use ResEdit, all of your application resources are just ordinary files stored in a directory. Images are stored in standard formats like PNG, data is often stored in plist or text formats.

Maybe somebody who knows classic Mac well can correct me here if I'm wrong, but I feel like resource forks were also solving a "constrained memory and an OS that didn't do paging" problem. So the library deciding how to load and possibly when to evict sounds like it was kind of the point. Simulating what might be the job of mmap() on a modern system.

The first Mac filesystem didn't even have folders! So either every little thing would be visible to the user, or they'd have to hide files somehow. But really you wanted to just have one thing that you could copy around, double click, etc.

Resources also provided the programmer with a way of working with the data in a structured way. Unix is of course remarkably primitive here, you'll get bytes and like it.

It's always a little funny to see the scorn Unix minimalists have for the old Mac OS. It seems very hard for some people to understand that rather than technical purity or whatever, the Mac developers were working from the interface on in, and the interface was meant to make the computer approachable for people who'd never touched one before and weren't interested in computers for their own sake.

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#25

Post by tempodox » Wed, Mar 10, 2021, 5:51 PM UTC

asveikau wrote: post #7

klodolph wrote: post #4

Earlier quoted context omitted.

I feel the modern approach takes the main strengths of resource forks and builds on them—instead of needing to use ResEdit, all of your application resources are just ordinary files stored in a directory. Images are stored in standard formats like PNG, data is often stored in plist or text formats.

Maybe somebody who knows classic Mac well can correct me here if I'm wrong, but I feel like resource forks were also solving a "constrained memory and an OS that didn't do paging" problem. So the library deciding how to load and possibly when to evict sounds like it was kind of the point. Simulating what might be the job of mmap() on a modern system.

You are correct. Resource objects had a `purgeable` bit that would allow the block to be evicted from RAM if memory became scarce. Also, the memory blocks for resources were allocated as `Handles` (essentially, `void **` instead of `void *`, as C malloc() would return). That made the blocks holding the data moveable in memory, for reducing heap fragmentation. If your Handle pointed to a NULL pointer, that meant the block was purged and needed to be reloaded from disk. Manual allocation could also be done as a Handle, further reducing the risk of heap fragmentation.

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#26

Post by eschaton » Wed, Mar 10, 2021, 5:55 PM UTC

bad_username wrote: post #13

> some of the user interface features pioneered by Mac OS such the desktop That is not true. The desktop metaphor, for example, was first introduced at Xerox PARC in 1970, and used commercially in the Xerox Star workstation in 1981.

Not really, the basis for the desktop metaphor came from research done at IBM, and it was very extensively revised at Apple for Lisa. (See “Inventing the Lisa User Interface” from ACM Interactions in 1995.)

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#27

Post by tempodox » Wed, Mar 10, 2021, 6:12 PM UTC

rvense wrote: post #24

asveikau wrote: post #7

Earlier quoted context omitted.

Maybe somebody who knows classic Mac well can correct me here if I'm wrong, but I feel like resource forks were also solving a "constrained memory and an OS that didn't do paging" problem. So the library deciding how to load and possibly when to evict sounds like it was kind of the point. Simulating what might be the job of mmap() on a modern system.

The first Mac filesystem didn't even have folders! So either every little thing would be visible to the user, or they'd have to hide files somehow. But really you wanted to just have one thing that you could copy around, double click, etc. Resources also provided the programmer with a way of working with the data in a structured way. Unix is of course remarkably primitive here, you'll get bytes and like it. It's alwa…

Those were the times. ResEdit, with disassembly of CODE resources and editors for structured types, together with MacsBug for inspecting or manipulating runtime state, was a combination that gave you ultimate power over your system.

I remember putting FKEY resources into the System resource file so the user could type Shift-Command- anywhere to automate some common task.

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#28

Post by JohnBooty » Wed, Mar 10, 2021, 6:17 PM UTC

bad_username wrote: post #13

> some of the user interface features pioneered by Mac OS such the desktop That is not true. The desktop metaphor, for example, was first introduced at Xerox PARC in 1970, and used commercially in the Xerox Star workstation in 1981.

Seems a deliberate and acceptable word choice. pioneer != inventor

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#29

Post by dietrichepp » Wed, Mar 10, 2021, 7:16 PM UTC

rvense wrote: post #24

asveikau wrote: post #7

Earlier quoted context omitted.

Maybe somebody who knows classic Mac well can correct me here if I'm wrong, but I feel like resource forks were also solving a "constrained memory and an OS that didn't do paging" problem. So the library deciding how to load and possibly when to evict sounds like it was kind of the point. Simulating what might be the job of mmap() on a modern system.

The first Mac filesystem didn't even have folders! So either every little thing would be visible to the user, or they'd have to hide files somehow. But really you wanted to just have one thing that you could copy around, double click, etc. Resources also provided the programmer with a way of working with the data in a structured way. Unix is of course remarkably primitive here, you'll get bytes and like it. It's alwa…

It’s true that MFS didn’t have folders—but it was also superseded by HFS all the way back in 1985! From my research, there’s only one generation of Macintosh computers (the original 128K and 512K) that did not ship with HFS. MFS was standard for a very short period of time.

The article hints at how files work. On MFS you would refer to a file as a (volume ID, filename) pair. On HFS, you would refer to a file as a (volume ID, directory ID, filename) triplet. A bunch of toolbox calls (syscalls) got duplicate versions for HFS—but if you were working with legacy code, you could create a fake volume ID called a “working directory” that could be used as if it were a volume ID in a (volume ID, filename) pair. These “working directories” are just awful. The working directory table is global to the entire system and they are not reference-counted—if you open the same working directory twice, you get the same ID both times, and you only have to close it once.

As a funny note—the original filesystem, MFS, had a maximum file name length of 255 characters. HFS, its successor, had a 31-character limit when it first appeared. As a compromise, the new FSSpec file APIs that appeared in System 7 used a 63-character limit filename, because 63 characters was the maximum filename length that the Finder supported.

You could create files with names longer than 63 characters on MFS volumes, it’s just that if you browsed these volumes in the Finder, the Finder would crash!

I’ve got a blog post in the work that is going through some of the wackiness I’ve seen in the old Mac OS filesystem API, and I’ve recently been on the RetroDev Discord helping some people write file handling code for classic Mac OS programs.

Re: The Challenges of Integrating the Unix and Mac OS Environments (2000)

#30

Post by Lammy » Wed, Mar 10, 2021, 8:38 PM UTC

asveikau wrote: post #7

klodolph wrote: post #4

Earlier quoted context omitted.

I feel the modern approach takes the main strengths of resource forks and builds on them—instead of needing to use ResEdit, all of your application resources are just ordinary files stored in a directory. Images are stored in standard formats like PNG, data is often stored in plist or text formats.

Maybe somebody who knows classic Mac well can correct me here if I'm wrong, but I feel like resource forks were also solving a "constrained memory and an OS that didn't do paging" problem. So the library deciding how to load and possibly when to evict sounds like it was kind of the point. Simulating what might be the job of mmap() on a modern system.

System 7 makes it even more interesting since they had to implement resource compression to keep the Finder + System suitcase small enough to fit on a single floppy with space leftover for the user to actually use. The decompression routines ship alongside the compressed resources, as 68k machine code in a ‘dcmp’ resource and later as PPC code in a ‘ncmp’ resource, so devs were free to cook up and include any compression algorithm they wanted and weren’t limited to Apple’s ~three or so common ones.