[GTALUG] [GW-C] Re: Anyone on the list know what I need to read ancient Apple disks?

[D. Hugh Redelmeier]

| From: Lennart Sorensen <lsorense at csclub.uwaterloo.ca>

| > What MacOS could do on a machine with 128k of RAM (including the video
| > frame buffer) puts all mainstream GUI systems to shame.  Part of this
| > was accomplished by using shared representations, some of which lived
| > in the resource fork.
| 
| Also putting the entire OS in ROM saves an awful lot of RAM.

Lots of it was not in ROM, especially as the OS advanced and the ROM
did not.  And the ROM wasn't too large: 64K in original 128k and Fat
Macs.

(The Atari ST was a lot faster booting because more of its OS was in
ROM.  On the other hand, the OS didn't advance very quickly or very
much.  The original Amiga had almost all the OS in RAM because they
knew it wasn't yet mature.)

| > That being said, I wish Linux didn't support forks.  They make the
| > file abstraction more complicated with very little benefit or use.
| > The main benefit, as I understand it, is to embrace and extend NTFS.
| 
| Linux supports resource forks in filesystems?

I was wrong.  I was mixing up Extended Attributes (an odd thing) with
Alternate Data Streams (a different odd thing).

ADS is an NTFS feature to embrace and extend MacOS resource forks.
Apparently there is no public API for it except for backing up.  Many
google hits point out that ADS is a great way to hide things (malware,
contraband, porn) on NTFS.

Samba and Reiser support ADS to some degree (Samba: optional, Reiser
is fading away).  I don't know what API they use.