[HN Gopher] The Challenges of Integrating the Unix and Mac OS En...
___________________________________________________________________
The Challenges of Integrating the Unix and Mac OS Environments
(2000)
Author : DvdGiessen
Score : 77 points
Date : 2021-03-10 08:37 UTC (14 hours ago)
(HTM) web link (www.usenix.org)
(TXT) w3m dump (www.usenix.org)
| [deleted]
| pwinnski wrote:
| 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.
| klodolph wrote:
| 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.
| pwinnski wrote:
| True, I do like 'Show Package Contents'
| asveikau wrote:
| 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.
| Lammy wrote:
| 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.
| geraldcombs wrote:
| 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.
| rvense wrote:
| 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.
| tempodox wrote:
| 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-<digit> anywhere to automate some common task.
| dietrichepp wrote:
| 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.
| tempodox wrote:
| 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.
| donatj wrote:
| Correct me if I'm wrong here, but macOS still has resource
| forks, right?
|
| My understanding is that's where file tags, file comments and
| custom file icons are stored.
| rvense wrote:
| Maybe, but Mac APIs don't use them, so you can't mod your
| games with ResEdit anymore.
|
| NTFS also has multiple forks, and also has many of the same
| fancy attributes capabilities that made the BeOS filesystem
| (in)famous, but they're not used in the same way, so it's
| kind of moot.
|
| What really what made BeOS and Mac OS good was not so much
| the technical underpinnings, but the way they exposed these
| in the APIs and standard applications.
|
| The power of Unix isn't just from the presence of the
| standard I/O routines, but the fact that most programmes are
| written to adhere to a specific paradigm that allow them to
| work together.
| m463 wrote:
| 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.
| tobr wrote:
| I'm curious, could you expand a little bit on why you think
| resource forks suck?
| m463 wrote:
| Resource forks attract unresolved clutter.
|
| It's like having an attic or a garage where you can put
| stuff while you (do not) decide what to do with it.
|
| Then you carry around this clutter everywhere.
|
| Developers might add something to a resource fork that
| should go in the file.
|
| Utilities have to deal with files AND resource forks.
|
| You have to backup a file, but then you also have to back
| up the resource fork.
|
| If it goes to another filesystem you have to figure out how
| to deal with it if the filesystem deals with only, you
| know, files.
|
| so what if the file and the resource fork are separated?
| Then you have a file that might not work.
|
| this burden is carried by the developers, the
| administrators, the users.
|
| There are plenty of analogous situations to this, like ftp
|
| ftp used to have two connections - a control connection and
| a separate data connection.
|
| Then when you had a firewall, you had to deal with an
| outgoing connection, plus an outgoing or incoming data
| connection.
|
| Then they added passive mode, and you only had to deal with
| two connections in the same direction, but there had to be
| special firewall logic to track them both.
| lordleft wrote:
| Does anyone else remember when MacOS marketing made UNIX a
| significant part of its sales pitch? I remember a giant, titanium
| UNIX logo
| bsharitt wrote:
| That's what got me onto MacOS X for many years.
| pram wrote:
| It worked on me! I bought a PowerBook G4 in 2003, when I heard
| Fink/MacPorts and Jaguar were no longer complete nightmares to
| use. Been Mac only since then.
| mhd wrote:
| Yes, they got it certified with 10.5, I think. Small market
| these days, although I'm always surprised when I hear that both
| AIX and HP-UX are still receiving updates...
| jonjacky wrote:
| 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.
| bluejekyll wrote:
| For Mac users, this was a new capability. Before that, I was
| always using remote X sessions to get onto shared Unix
| systems.
| jonjacky wrote:
| 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!
| kergonath wrote:
| They also had adverts such as this one:
| http://www.brainmapping.org/MarkCohen/UNIXad.pdf [edit] also
| linked by mrpippy below.
|
| There used to be things like this on Apple's website, too:
| https://www.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Us...
|
| I can't find any mention of UNIX in Big Sur's pages, even
| though it is listed as certified on the Open Group's website.
| PascLeRasc wrote:
| Those are so cool, thanks for sharing. Can't believe they got
| celebrity endorsements like Mark Cohen back then.
| bad_username wrote:
| > 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.
| mattl wrote:
| That's not what pioneered means.
| JohnBooty wrote:
| Seems a deliberate and acceptable word choice. pioneer !=
| inventor
| eschaton wrote:
| 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.)
| mrpippy wrote:
| "Sends other UNIX boxes to /dev/null"
|
| https://www.brainmapping.org/MarkCohen/UNIXad.pdf
___________________________________________________________________
(page generated 2021-03-10 23:02 UTC)