3 ms·

In the days when there was Classic Mac OS malware, it often came in resource forks, and took advantage of their features. That reminds me of Windows' NTFS "alt

In the days when there was Classic Mac OS malware, it often came in resource forks, and took advantage of their features. That reminds me of Windows' NTFS "alternate data streams", which also got a lot of use by malware in an attempt to disguise its existence, and as a way to bypass access controls on web servers. IMHO these "hidden features" are at the wrong level of abstraction and cause a lot of problems, information interchange among others. A file should be a single stream of bytes with a name. If you need another stream of bytes, create another file. If you need to group them together, that's what directories are for. Windows has a resource format too --- it's just part of the program binary. There are likewise resource editors, one of which is also called ResEdit.

rtpg 2y ago
> A file should be a single stream of bytes with a name. If you need another stream of bytes, create another file. If you need to group them together, that's what directories are for. While I understand the appeal of this, the world would have been a lot simpler for a lot of stuff if (for example) every text file had tagged its encoding. I wonder about if we could have moved forward as society a touch faster if Unix wasn't "all byte streams", and had a touch of metadata. I feel like HTTP and friends shows we can just organically end up with a certain kind of structure that "works" (and at one point you have a spec, and then you can yell at programs that don't follow the spec)
- userbinator 2y ago
  I wonder about if we could have moved forward as society a touch faster if Unix wasn't "all byte streams", and had a touch of metadata We would've "moved forward" faster into authoritarian proprietary walled-garden dystopia, yes.
  - rtpg 2y ago
    I mean I'm just saying labeling text files with their encoding at the front would have been nice for decade or two where text readme files would be routinely garbled if you were in Europe or Asia and using machines that weren't configured properly
rvense 2y ago
The implementation proved out to be unfortunate for compatibility reasons, and in hindsight it might be obvious, but the Mac was conceived and implemented when absolutely everything about every platform was proprietary/NIHd: keyboard layouts, connectors, expansion slots, mass storage connectors, operating systems and also file systems. Much of what became PC standards weren't conceived as that, but rather proprietary connectors for a platform that just happened to be easily cloned. There was really no expectation of compatibility between different models of computer from the same manufacturer. I think it does a great disservice to the Macintosh Resource Manager to focus on its implementation using a dual fork file system. What it allowed was a nice high-level interface to work with small pieces of data that hid away a lot of memory and disk management from the programmer - you just ask for a type and ID, and if it's in memory you get it right away, else it gets fetched, including asking the user to swap in the right floppy if they'd swapped it in. Afair it even purges things out of memory when they were no longer needed with no action on the programmers part - this is a big deal in 128k RAM. There were some bad things about the implementation: it's easy to corrupt the resources of a file, for instance, and there's a fairly small limit to the size and number of resources. But having a way to access structured data that's a core part of the platform can be a great thing. If anything, the Mac didn't take this far enough.
- masfuerte 2y ago
  Sure, but you can do all of these things with the resources stored in a section of the binary, like Windows does. You don't need a special file system feature. I have never understood the rationale for this design.
  - rvense 2y ago
    But when you're (basically) one person designing both the filesystem and all the APIs together, and the idea of crossplatform compatibility hasn't really been invented yet, I can see how it looks like something that belongs in the filesystem layer rathr than as a convention above it. I don't know how it works on Windows, but when you say "section" of the binary, that implies the files have some sort of structure? Is it part of the PE format or how does it work? With the resource manager, any file can have resources, which means some file formats can be implemented using very simple OS APIs.

rtpg 2y ago

> A file should be a single stream of bytes with a name. If you need another stream of bytes, create another file. If you need to group them together, that's what directories are for. While I understand the appeal of this, the world would have been a lot simpler for a lot of stuff if (for example) every text file had tagged its encoding. I wonder about if we could have moved forward as society a touch faster if Unix wasn't "all byte streams", and had a touch of metadata. I feel like HTTP and friends shows we can just organically end up with a certain kind of structure that "works" (and at one point you have a spec, and then you can yell at programs that don't follow the spec)

userbinator 2y ago
I wonder about if we could have moved forward as society a touch faster if Unix wasn't "all byte streams", and had a touch of metadata We would've "moved forward" faster into authoritarian proprietary walled-garden dystopia, yes.
- rtpg 2y ago
  I mean I'm just saying labeling text files with their encoding at the front would have been nice for decade or two where text readme files would be routinely garbled if you were in Europe or Asia and using machines that weren't configured properly

rvense 2y ago

The implementation proved out to be unfortunate for compatibility reasons, and in hindsight it might be obvious, but the Mac was conceived and implemented when absolutely everything about every platform was proprietary/NIHd: keyboard layouts, connectors, expansion slots, mass storage connectors, operating systems and also file systems. Much of what became PC standards weren't conceived as that, but rather proprietary connectors for a platform that just happened to be easily cloned. There was really no expectation of compatibility between different models of computer from the same manufacturer. I think it does a great disservice to the Macintosh Resource Manager to focus on its implementation using a dual fork file system. What it allowed was a nice high-level interface to work with small pieces of data that hid away a lot of memory and disk management from the programmer - you just ask for a type and ID, and if it's in memory you get it right away, else it gets fetched, including asking the user to swap in the right floppy if they'd swapped it in. Afair it even purges things out of memory when they were no longer needed with no action on the programmers part - this is a big deal in 128k RAM. There were some bad things about the implementation: it's easy to corrupt the resources of a file, for instance, and there's a fairly small limit to the size and number of resources. But having a way to access structured data that's a core part of the platform can be a great thing. If anything, the Mac didn't take this far enough.

masfuerte 2y ago
Sure, but you can do all of these things with the resources stored in a section of the binary, like Windows does. You don't need a special file system feature. I have never understood the rationale for this design.
- rvense 2y ago
  But when you're (basically) one person designing both the filesystem and all the APIs together, and the idea of crossplatform compatibility hasn't really been invented yet, I can see how it looks like something that belongs in the filesystem layer rathr than as a convention above it. I don't know how it works on Windows, but when you say "section" of the binary, that implies the files have some sort of structure? Is it part of the PE format or how does it work? With the resource manager, any file can have resources, which means some file formats can be implemented using very simple OS APIs.