Don’t forget that other “power user” feature: MacsBug. I used it to disassemble and figure out how Finder worked. You could do some amazing stuff with MacsBug. Someone wrote a book on it. I used to have that book, but that was a long time ago.
Basically, you could drop a stock Mac into MacsBug, and figure out how the running app was working.
I still remember the machine code for 2 important instructions to use in Macsbug: 0xA9FF for a breakpoint and 0x4E75 for returning from the current stackframe.
We'd debug and insert breakpoints by directly overwriting the program code in RAM.
This one has pretty heavy nostalgia for me. Resedit is a big part of why I'm in software development today. My first forays into "hacking" were to use Resedit to modify some nagware to skip the pay screen. It was a definite peek behind the curtain moment that made me much more curious about computing.
Same for me, my first foray was making changes to the game Escape Velocity using ResEdit, then I used it on anything and everything, then as soon as official modding support came out for games like Myth, Doom, Marathon, etc, I starting making mods, and then it was coding and so on. :)
Same! Escape Velocity and its sequels were at a very important point of learning software development for me. I didn’t get in to game dev, but being on the ambrosia software IRC server taught me a lot of things.
It’s significant to my dev roots too. I had both the OS itself as well as several apps customized, with the most extensively modded being a totally rebranded Netscape Communicator with custom iconography. I also used it to mod games, doing things like changing sounds something silly or replacing 2D characters with pixel-versions of my siblings.
It was always a bit disappointing to come across the odd program (usually cross platform stuff) that had little or nothing that could be edited in ResEdit.
Does anyone remember Servant by Andy Hertzfeld? Which kind of blended the Finder with ResEdit, showing the resources just like it shows folders and files. Allowing to manipulate them the same way, for example copying via drag'n'drop etc.
PalmOS borrowed a lot from Mac OS - not surprisingly, given that two out of three of the Palm founders were Apple alums. Both Mac OS and PalmOS were designed for 68k processors, used A-traps for system calls, named those calls with CamelCase, organized them into subsystems called "Managers"...
Surely you will have read it, but for anybody else "Piloting Palm: The Inside Story of Palm, Handspring, and the Birth of the Billion-Dollar Handheld Industry" is a fascinating read https://www.goodreads.com/book/show/2746630-piloting-palm
This is what desktop computing should look like. We've all gone down the wrong path due to our obsession/actual need to stay networked all the time and constantly run unaudited code.
The fact that you could take any compiled, commercial app (or game) and thanks to the magic of the "resource fork" (a separate structured-data stream that every Mac file had), you could edit all its visual assets in this tool... it was just godlike fun education for teen nerds like me
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.
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.
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.
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.
I'm not talking about cross-platform compatibility. It just seemed over-complicated.
Yes, on Windows it is part of the PE file, which is based on UNIX System V's COFF. These files have a list of sections used to distinguish between code, read only static data, read/write static data, optional debugging information, etc. The resources are just another section with the data in a particular format (probably not dissimilar in format to the Mac resource fork) and Windows has APIs to conveniently access the data.
But one thing this can't do is attach resources to arbitrary file formats. Thank you, that's a use case I was unaware of.
> 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)
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
1994 would put it at about System 7.2 or 7.3 if I'm not mistaken
Very nice flashback. Spent a lot of time making numeral only fonts for the clock with fontographer, old (or younger) me was a little scared of ResEdit's powers
I don't quite get why resource forks would be less secure. The problem of classic macOS was that there was no authorization/protection mechanism at all. Adding an MDEF to an application is just as dangerous as altering a binary under Linux. It is true that the nature of resource forks makes it a bit easier to write a generic hack, but if Linux would allow everyone and every process to edit all files, malware could latch onto some C or X11 library.
I wondered a bit about that comment too. It's something of a tangent, but that the OS would load custom WDEFs (window definitions), CDEFs (control definitions), etc., and these had executable code in them, well that was how Mac got viruses.
And there was a kind of hierarchy as I recall — where you could install a custom WDEF/CDEF/MDEF at the System level and it would be loaded/executed for all apps.
With that line of reasoning though, as you're saying, it was not the resources themselves that were a problem but the way the OS naively loaded and ran them.
Sandboxes were for kids.
We definitely lived in a trusting time ... where the person computer really was for the one individual.
Except for the 100+ InsideMac tomes costing an arm and a leg; wasnt a cheap barrier accessing the only decent source of truth then on how the various *Managers worked. Still despise Apple to this day for that.
No, this author has just been blogging about low-level Mac details for a long time. And I feel like it's readily apparent from the quality of the posts that they're written by an expert and not by AI.
https://news.ycombinator.com/from?site=eclecticlight.co
I miss having a world where the threat model of having your computer compromised wasn't "your entire life ends". Where a device wasn't assumed to be online all the time, and where every device didn't contain the keys to your bank account.
You can meaningfully recreate this world today for a personal, non-work environment. For a PC, what do you really need a persistent internet connection for? If you have a Mac, create a couple of network locations, one "Offline" (all internet-connected network adaptors disabled) and another "Online." Keep a habit of leaving it at the "Offline" unless you really need to go online for something. This is what we did thirty years ago with dial-up.
You can, but what does it help? Modern OSes are architected assuming an always-online, the-world-ends threat model. Thus causes them to be heavily locked down, eliminating a lot of the customizability and hackability that older systems had.
And that’s not to mention applications. It used to be common for GUI applications to be scriptable and to support plugins!
It's worth experimenting with. Some things won't work at all, others will break in Fun And Interesting Ways. Some things will get much slicker though because they suddenly don't have network I/O anywhere near the UI, or because ads aren't sucking CPU any more. It's worth at least understanding where your common workflows are on that spectrum.
It might help your focus, if you're the type who is easily distracted with the web or by notifications. That extra bit of friction to switch locations to enable the network might be enough to get you to second guess whether or not you really need to look at that thing online.
I remember in the early 2000's getting a virus that made multiple long distance calls to Japan with my dial up modem and having to try to explain the charges to my parents.
Many of those dialers were programs that offered access to porn. Had a friend that used one extensively for a month, until his parents received a fat invoice from the phone company!
Don’t forget that other “power user” feature: MacsBug. I used it to disassemble and figure out how Finder worked. You could do some amazing stuff with MacsBug. Someone wrote a book on it. I used to have that book, but that was a long time ago.
Basically, you could drop a stock Mac into MacsBug, and figure out how the running app was working.