#135 Hacking the Classic Mac OS

The classic macOS, the operating system that Macintoshes ran on from 1984 to 2001 was radically different than modern operating systems. In this episode, I interview Elliot Nunn, an expert on the inner workings of the classic macOS. We get into his interesting hacking projects, as well as some of the key concepts that underlied this venerable operating system.

Welcome to Kopec Explains Software, the podcast where we make computing intelligible. In this episode, I interview Elliot Nunn. He's a doctor from Australia, but beyond being a doctor, he spent more than a decade hacking on the classic macOS, the operating system that Apple Macintoshes ran on from 1984 to 2001. And there's a vibrant community of people who still want to use these older machines and this older operating system. Maybe they have old software, maybe they have games that they want to play, or maybe they're just interested in vintage computers. In this episode, not only will we get into some of Elliot's hacking projects, we'll also talk about how the operating system worked and and compare and contrast it to modern operating systems. I hope you enjoy my conversation with Elliot. Elliot, let's start by learning just a little bit about yourself. So how did you first get interested in hacking the classic macOS, learning about all of its internals, and if you could just kind of tell us briefly how that's aligned with your life and your career?

Well, big question, David. It all started when my uncle Richard, who's a very generous chap, gave me his old computer that he'd written his PhD thesis on. I was about five, and it was a Mac classic and those sold very well in Australia at the time. But it was a few years old and I was hooked. I just liked putting floppy disks into the drive and typing up silly things in teach text and giving floppy disks to other people and playing a few games on the computer. From there I got a little bit interested in the internals of computers and I preferred to use Macs. I didn't really start doing what I thought were cool things with my collection of Macintosh hardware until I was 10 or 11 or 12 when I learned how to take one apart and put it back together. And I first started really hacking and reverse engineering and coding for these machines when I started medical school. So I was about 22 or 23, and it was a bit of a rude shock to go from my cushy undergraduate bachelor's degree to the Ricky's medical school. It was culturally challenging and so I really needed a hobby and a distraction. And so I started Disassembling the Nanokernel, which is a very obscure, low level, poorly documented piece of software that lives in the ROM of Power Macintosh computers and would be the thing that would need the most work if we ever wanted to run the classic Mac OS on a power Mac G5. That was about 10 years ago that I started doing that. So it's just in the back of my head that I really need to get the macOS working on a power Mac G5.

That's very cool. I mean, everyone knows medical school is incredibly intense. So it sounds like this was almost like a stress release, almost like a hobby that gave you an escape from the intensities of medical school. Is that fair?

Very fair.

And so you started with reverse engineering the Nanokernel. And we can talk more later on about the specifics of what the Nanokernel is. But I know you've done a wide variety of reverse engineering projects and so I was hoping you could just tell us about maybe two or three of your favorite ones, the ones that you're the most passionate about that have been related to reverse engineering the classic macOS.

Well, David, there's breadth and not depth because this is a hobby. I have a bit of a bad habit of leaving projects in an incomplete state with a cryptic forum thread that people have a bit of trouble following. But the thing that I suppose I'm proudest of is I worked with some people on the Mac OS 9 lives forum and it was a team effort for sure, but I was the first person to get that I know of anyway to get Mac OS 9 running on the Mac mini G4. And that was how we got in touch. And that was probably the peak of my disassembling and reverse engineering skills. A lot of power PC code that needed patching and a lot of disassembling that needed to be done to figure out what was going on there. But at the end of the day, The Mac mini G4 was a budget machine that had a motherboard that was pretty closely modeled on a slightly by then out of date iBook G4. So it works really well. I did. I am still working on writing what are called virtio drivers for the macOS so that you can do things when you run Mac OS in a QEMU virtual machine, like move the mouse cursor quickly in and out of the window. Not that I was the first person to get that. Working access disks on your local machine unlocks and display settings. That's been a nice little hobby to work on for a few years. I did some work increasing the amount of RAM that Mac OS 9 can use on a very well equipped Power Mac G4. The RAM limit on some models of Power Mac G4 is 2 gigabytes. Mac OS 9 can only work with about 1 and a half gigabytes of that. And so understanding the reason for that and working on pushing that RAM limit upwards a little bit incrementally was rewarding and a bit of fun.

Yeah. And I've also seen that you've. Sorry, interrupt. I've also seen that you've done all kinds of hacking on the file system on egfs. And so I was curious to ask you about that project a little bit.

So I think I stumbled on that fairly by accident because I was just mucking around with some emulators on my computer and I found that one of the quickest ways to start up an emulator was to use the so called the Disk Tools disk image. So a, I think that if you bought a Mac that ran Mac OS 8.1, you know, in the mid-90s or so, you would get a floppy disk with it that was called the Disk Tools floppy disk. And the Disk Tools Floppy disk would start up and it would look for all the world like System 7, but it would have the ability to mount HFS plus hard disks, which is not an ability that System 7 is supposed to have. And so I scratched my head and I went, you know, through the system file and figured out exactly how they had made the Disk Tools disk image. Even though it shipped with Mac OS 8.1, it was a System 7 disk. And so it was quite a different version of the system that had had that new file system retrofitted onto it. And how that was done, I did some diving, getting the file system getting HFS plus to work on system 7.6 wasn't very hard. System 7.5 was a bit harder. System 7.1 was quite a bit harder. And I think I left it unfinished. But that was a bit of fun.

And to give people context, I mean, system 7.1 is separated from system 8 in terms of release dates by I think like something like five years. Yeah, there's a big gap there in technology.

Yeah. The Mac OS did not get a major version bump for a long time. And that was the time that Apple was trying to develop Copeland, which was to be released as Mac OS 8, which unfortunately didn't work out.

Yeah, and I'd love to get back into that some more. I think you have such a wide variety of different reverse engineering experiences with the classic macOS, you're a great person to kind of give our audience an overview of how the classic macOS. And when we say classic macOS, we mean the operating system from system one all the way to Mac OS 9, which is from like 1984 until 2001. Mac OS 9 comes out in 1999, but the replacement for it, Mac OS X, comes out in 2001. So you're a great person to kind of give an overview of all the technologies that went into the classic macOS and kind of understanding how it differs from a modern operating system today, like the current Mac OS or a version of Windows or Linux. So I wanted to start by just asking you, kind of big picture, given your wide background, what are some of the key differences between that classic Mac OS and a modern macOS or another modern operating system?

So I've thought about how to describe this to people. The first thing when somebody asks me what my hobby is and they're very genuinely interested, one of the things that you can use to jog their memory depending on how old they are. Do you remember when Macintosh computers, the Apple Menu was a multicolored stripy thing? And they remember that. And you say, well, actually the system, the operating system, the software that ran on those computers was very, very different back when they had a multicolored stripy Apple menu compared to the system that runs now. It was. And then because you're a technical person, I can, you know, we can, we can, we can go on and talk about it for a long time. I think the best way I can describe the Mac OS is this. Now, the people who wrote the operating system and who maintain the operating system through their life are mostly still with us and still living. And lots of them have written really good accounts. People like Andy Her Nitin Ganatra did an excellent podcast. And so I can't necessarily do their web justice, but I can put my own spin on it, which is to say that the Mac OS was a scaled up version of a consumer microcomputer operating system like you would find in the very late 70s or the early 80s. It was written with very tight constraints in memory and processing power in mind. And so, especially in its earliest operations, it more closely resembles something that would run on your Apple II or your Commodore 64 or your Amstrad or your ZX Spectrum in the early 80s. Then it did a scale down large Unix or other minicomputer operating system or mainframe operating system.

Yeah, that makes a lot of sense. And to contextualize Kind of the timeline for listeners. The original Macintosh comes out in 1984. The Apple II launched in 1977. So we're only seven years after kind of the eight bit computer revolution of the Commodore Vic 20, the Apple II, the TRS 80. We're not very long after that first wave of these 8 bit computers. And of course the Macintosh had a 16 bit Motorola 68000 and a much more powerful microprocessor. But as you're pointing out, the engineers at Apple, their background was all in programming for kind of these eight bit computers. Although we should say there was the Apple Lisa that came out, you know, a few years before and that inspired a lot of the Macintosh. But the Macintosh was actually running under a lot less RAM and was also running without a disk drive built in on floppy disk. It was actually a more primitive machine than the Lisa. So they were working again in this super constrained environment. Like they were almost. Not quite, but almost on the Apple ii, not quite as bad. But they're coming with that mindset to some degree, I think. Is that part of what you're saying?

I think that's absolutely fair to say. Yeah. One of the things that exemplifies it for me is that they, as the new line character, you know, the ASCII chart set has two different characters that you can, that can conceivably be used as a, to, you know, move the head of your sort of teletype printer down and to the left as the carriage return and the line feed character. And the UNIX tradition is to use the line feed character on its own. But it was more common among, I think for fairly arbitrary cultural reasons, it was more common among the microcomputers, home microcomputers, to use the carriage return character as the new line. And the Macintosh follows the Apple II in using the carriage return character.

It created frustrations for people for decades. And you know, that's a good kind of segue because the, it comes out in 1984 on a machine with an 8 MHz 68,000 and 128 kilobytes of RAM. And it ended up having to evolve through the years all the way up to, as we talked about, you know, around the year 2000, 16 years of evolution while microprocessors, you know, memory controllers, RAM is just exponentially increasing in, you know, power and efficiency. And yet they had to take this old, you know, set of bones that, that was never meant to be the bones of a supercar and keep having it stay current with these incredible evolutions in hardware. And I think that, you know, that as we get into our discussion, we can kind of talk about where that fell short. But we were. Let's go back to talking about other like kind of big differences between the classic macOS and a modern operating system.

Well, one of the deficiencies that it has when compared with what you would call a modern operating system on consumer hardware even as early as the early 1990s, is that it has a form of multitasking, which is to say the ability to use multiple applications open at the same time. That that's relatively unsophisticated and would often fail, leaving the user in a bit of trouble with crashed applications and lost data. So instead of the operating system being in charge of which application is allowed to use a particular time slice of CPU access or disk access, the applications themselves are in charge and they have a sort of round robin or pass the parcel approach to yielding time to each other. It's called cooperative multitasking. So a badly behaved application that might be doing something CPU intensive could get carried away and do that for an unlimited time without the user being able to interrupt it easily, and certainly without other applications being able to do things like update the user interface.

I think that speaks again to what you were saying before about the mindset. Right. They're coming from these eight bit computers where people always just ran one app at a time and then when the Mac comes out, they're assuming that that's the way people are going to kind of use the machines. They're not. And maybe it would have just been also too much work to get preemptive multitasking working in that constrained environment. Whatever it is, they're coming from a very different mindset. And I think you and I growing up with the Mac probably remember how difficult this was for users in, let's say the 1990s, where it was common, of course, to already be running multiple applications at a time. You could be on your web browser and something intense is happening on a web page and now Microsoft Word. You can't type anything in it because so much of the CPU is being used up by the web browser. It was a system wide deficiency that really hobbled the macOS as the 1990s went on.

Yeah, it was really unfortunate. It required a lot of developer time, both by the operating system developers inside Apple and by third party engineers to work around that deficiency in bespoke ways. And there were lots of clever things done. But in some ways because the foundational work hadn't been put into the original Macintosh. And it would have been a waste of time on the original Macintosh because you can't really practically run many applications in 128k of RAM. But because the work hadn't been put in in the first place, you know, it was really hard to make an MP3 player that wouldn't stutter and crash when some other app when it was playing music in the background.

Yeah, that makes total sense. Okay, let's talk about maybe a couple more points on this, and then let's dig into some more specifics on different elements of the macOS. But what are some other things that were big differentiators between the classic macOS and why it ultimately maybe had to get replaced and why it's different from operating systems today?

Well, another famous thing that it didn't have is memory protection. When multiple applications are running on the computer, they're cooperatively sharing time and the CPU amongst each other. They're also quite cooperatively sharing memory. And so the memory of the machine, with a few exceptions in the very later Mac os, there was some clever ways sort of around this. But the memory in the machine is exposed to every application as one big long stretch. And each application is just told when it started, when it starts, that this is your area of memory. You're allowed to use this except in very specific circumstances. You must not touch any memory outside of this area. And there's nothing then enforcing that contract. And so one application can, by accident, overwrite the memory of another application, often in subtle ways that only cause the machine to crash days later.

So that sounds a bit like the Wild West. So one app could go and literally modify the memory of another app, maybe even affecting the current operation of that other app for the user.

Yes, that's right.

Yeah. That's crazy. And people can't imagine that today because we all think about security and safety and how our apps are, like, isolated from each other. And this was just a totally different world where the whole memory system seemed to be basically, you know, this flat area that anything can just reach into.

Yeah, it wouldn't wash today. It was the result of, I think, very sensible incremental decisions made with successive releases of the operating system. And the upsides of those decisions were that application compatibility was maintained. So an application, of course, this was before easy Internet access. And so it was very difficult to applicate to. It was relatively difficult to update applications to newer versions. Application compatibility was maintained, which is really important for an operating system vendor because it doesn't look good and it's Bad for business when releases of your operating system, you know, cause people to lose their investment in other computer programs.

I think that's such an important point that you're making that probably a lot of modern users are. It's hard for them to put themselves back in the shoes of somebody in let's say 1990. They're, they're using a Mac, which at that time I guess would be like System six or something. Right. And they still want to use some app that was developed for like System one or System two. And so that we were talking about earlier, how System 1 was developed for this incredibly constrained environment. Well, Apple now has to maintain compatibility backwards with whatever hacks they had to do to make it fit in, you know, the whole operating system in the rom, which we can talk about in a few minutes. But they had to make the operating system fit for this incredibly constrained machine. And then these apps that ran on this incredibly constrained machine and keep them working with all of the hacks that were involved in getting those to work in the first place so they couldn't just rip everything out or they would lose their user base who'd be like, why can't I still run my apps?

In some ways it took the form of a very slow conversation between the operating system developers in Apple and third party application developers, whereby there would be some sort of a short term hack or quirk in the API in an operating system release and then an application would come to depend on that or to take special action to work around that quirk. And then Apple would want to fix that quirk to improve the quality of the operating system or add some useful user facing feature. But they might break old software in doing that. And so the result of that need for application compatibility over very many years was a pile of clutches both in applications and in the operating system. And that they're especially. There was an especially focus on large, big box expensive applications from, you know, large vendors like Adobe and Microsoft. But there were hacks large and small in the operating system.

And as you're reverse engineering it, I imagine you're coming across some of these hacks and I'm wondering if sometimes you come across one and you're like, wow, having to support this even for, let's say something like Virt IO where you're trying to get compatibility in qemu. I hope I'm pronouncing it right. Qemu right.

Okay.

Nobody does. You must come across these regularly. And is it now for you as a reverse engineer, did these additional kind of hacks that are in the operating system actually create additional problems for you to reverse engineer it because you have to support the hacks too.

Not particularly. They are just historically fascinating. So to give an example, digging through the nanokernel a good few years ago, I just found that the nanokernel was making a very specific check for about whether it's boot like whether it's startup time configuration had changed, particularly the memory configuration of the area of RAM where the pointers start with the hexadecimal character set. So 1/16th of the of the 32 bit address space, the part of it starting with 7 had some kind of special case applied to it. And I had absolutely no idea what that might be doing until years later when I sorted a source code and spoke to someone and it turned out that was a hack for Virtual PC. So Virtual PC, which, you know, the Windows compatible PC emulator that you could run on your Power Mac, an earlier version of it had a hack for an early version of the nanokernel where it would reach inside the nano kernel and change some private structures in a way that you know, was certainly never intended by the NanoKernel developers. And then a second version of the NanoKernel which is entirely rewritten, needed to maintain compatibility with that specific hack so that people could still use Virtual PC on Mac OS 8.6. That was interesting. There is another, there's another one. And I thought this was really fascinating that one of the ways of fixing a bug in the ROM code in later releases of the Mac os, once the bug had been found and its impact had been assessed and it was thought when we need to fix this, was to I suppose change what the C developer would call the vtable. So there's a big table of function pointers that populated at startup in the Mac os. And each API call that an application makes will go through that function table. And the function table will usually point to the ROM code, but it can also point to RAM code. If the ROM code has a problem, operating system when it's starting up will change what happens as a result of making a particular function call. One of the quite clever ways of fixing bugs is in fixing bugs that are found in the ROM that requires only a tiny little bit of ram. But a lot of developer effort to make it work is something called a come from patch. When there's a piece of buggy ROM code that needs to be fixed and that ROM code calls a system API that even if it's unrelated to the bug itself, it's just, it's Nearby the ROM code that system API can be patched to check whether it's being called from the rom. And if it's being called from the rom, it can do some clever things with the state of the processor and changing the program counter and skipping over a bit of code. The bug fix can be inside a function that the ROM calls that when the ROM calls, that function will skip over some of the ROM code and do the right thing instead. It's called a come from patch. And it's a technique that Apple quite jealously reserved for themselves as a way of fixing bugs in the rom. And so there's an interesting come from patch in one of the System 7 releases. I think it's in System 7.1. But it's not meant for fixing ROM code. It's meant for fixing potent. It's meant for fixing old applications that were compatible only with earlier versions of the operating system. What it does is it when some particular function is called, let's you know when, when this application, when an application calls foo, every time that happens, the operating system will check the code that called foo will check six bytes before the function called a foo and six bytes after, and it will hash those six bytes and it will compare that hash against the table of hashes. And if it's one of those, if it's a member of those table of hashes, it will change its behavior.

So we're talking about, as you put it earlier, cludges in different, and we've talked about now, two different parts of the operating system where these exist for specific applications. So this was a ongoing conversation, as you put it, that was going on between developers and Apple about fixing the operating system, but also about continuing to support their apps in very specific ways that were necessary as things went forward. You mentioned earlier Virtual PC, which was an emulator for running Windows on the Mac, very important app, probably sold hundreds of thousands of copies and Apple couldn't have a new version of the macOS come out that broke this software, but it required because it was using some hack to begin with. It sounds like so a hack on Apple's part to continue to support it.

Absolutely right. You could liken it to a chess game, but it wasn't adversarial. Both sides wanted to please their users quite specifically. Neither side wanted to get broken for their software update when the user's workflow stopped working. And so there might have been a little adversarial element of blame shifting there. But on the whole, both sides wanted to please the user and, and so it was, as we say, just this slow motion conversation. One software update met by another software update met by another.

Okay, for our users who are not familiar, I do want to get some definitions in for them. So we've touched on a couple times the rom. What was the ROM and what was its relationship to the operating system?

So ROM is an acronym for Read Only memory, and it means some collection of bits and bytes that are available to your computer which can't be changed by that computer no matter what you do. You restart the computer, you can try to overwrite them, they'll stay the same. And so a CD ROM is a computer CD where the contents of it can't be changed. And that's most CDs. Arom the without qualification usually means a chip. RAM is random access memory, and it's the memory that the computer uses that it needs to change for things like documents that are held in memory and pictures that are held in memory. But ROM was available in the 1980s, specifically when the Macintosh was designed as a much cheaper kind of chip per byte or kilobyte of memory than a RAM chip would be. And so it was worthwhile fitting as much code as possible into the ROM from the factory before the machine shipped, so that as little as possible as a very precious and expensive RAM in the machine needed to be used for the operating system. Software for pictures and graphics and patterns and the kinds of things, the kinds of code that the computer needs to run and run an operating system. So the three options for, well, the two options I suppose, for having code in the original Macintosh are you can ship it on a floppy disk and it will be loaded when the computer starts up into ram. The floppy disk is slow and the RAM is expensive, or you can, but you can ship a new floppy disk to the user fairly easily, or you could ship the code as part of the rom, where it's not at all easy to change without taking apart the computer and shipping out a new chip to the person. But it's much cheaper and it's quite fast. And so the 128ks of Ram, kilobytes of Ram Ram and the original Macintosh was met with was paired with a 64 kilobyte ROM that was really absolutely chock full of very densely tightly coded assembly language that made up the vast majority of the Macintosh operating system at.

That time that is really so different from what we're used to today, where of course, the vast majority, if not all of the operating system in BIOS exist in places that can be changed on a modern computer. So we're dealing with unchangeable code code that then I guess is becoming a weight on the macOS as it wants to evolve because it has to maintain compatibility with these older ROM routines. Just I'm thinking of the original Mac. I don't know, you would probably know better than me how many operating systems it's still supported up to maybe a system 6 or system 7. I know the Mac plus supported like all the. Which came out in 1986, supported all the way up to system 7.5 which came out in the mid 90s. So. But it's having. But as they update the system, go to System six, System seven, whatever they're having to still have again, we could call them cludges or hacks in place to be compatible with this unchangeable code that shipped with the computer. Is that about right?

That's absolutely right. And a lot of effort had to be put into making the operating system work well and work the same on computers of different ages.

That's interesting. And I think through this conversation we're starting to understand for our audience like why they had to do all these clutches over the years, why they were so hobbled, why they couldn't move more quickly. Just as kind of a sidebar. You mentioned earlier, Copland, Apple was aware, right, that they had these problems and they were trying to resolve them through new operating systems or operating systems often that would try to have some kind of backwards compatibility with the old macOS but maybe also add some new operator frameworks or things like that. How come none of those efforts, in your opinion, succeeded?

That's a really good question. I am not a manager. Doctors are notoriously who very bad managers of people. I've heard from someone that we all complain about management but we can't manage on our own. I think a lot of ink has been spilled about the management problems inside Apple at the time. And there were some cultural problems because there were legions of very clever people with excellent ideas who were perfectly capable coders and, and could have written as good an operating system as anybody else. But the fact is that Microsoft realized that their Windows 95, 98 operating system had a real problem and they started a many years long effort to write Windows nt, which succeeded. And Apple realized that their operating system, which was, you know, Mac OS 6 and System 7 had lots of problems and they started a few years long episode to, you know, update the operating system with modern facilities and they failed. Some things that people complained about who were, who were in Apple at The time was empire building. So managers would move as much of as many parts of the as possible of the operating system under their own control so that they, their own career advancement would proceed and that they're part of the project wouldn't be very essential and that wouldn't get canceled. Excessive modularization. So although it was in vogue in the 1990s to have clean separation of parts and you know, there were some slightly quixotic projects about how computer, you know, computer applications could just be assembled by the user out of the bits that they find useful. That's not actually a good way to write an operating system that has a, you know, presents a coherent face to the user and works, well, skunk works projects. And so they were, instead of the whole company being marching in step and writing an operating system and one kernel, there were people who were working on alternative kernels and there were people who were being sent to work to get Linux running on the machine, which really was of no commercial benefit to Apple at all. And so that all culminated in the Copeland project failing and some quite famous changes in the executive team at Apple and the operating system still used today.

Absolutely, absolutely. I want to get through just a couple more elements of the classic macOS and how they interacted with each other. So another thing was kind of how programmers wrote apps for the classic Mac os. And I know that they use something called the Toolbox. And my understanding is that part of the Toolbox was actually in ROM on the early machines. And as time went on more and more of the Toolbox was on disk. But can you tell us a little bit about what the Toolbox was and how that may have evolved over time?

So the Toolbox is put simply the name of the API, the application programming interface for writing applications on the classic Mac os. It had a summarize the Toolbox. It was fairly low level in the sense that the user, in the sense that the programmer was expected to create, make the call to create a window and then to have some ongoing involvement of their code in what gets drawn on the window, even when the computer, even when the user isn't interacting with that window. It contains quickdraw, which was the. A really quite innovative programming interface for writing, for making graphics on the black and white and then a color screen. It contains the. It contained the dialog Manager, which was a set of function calls that could be used to put up a dialog box on the screen that the user could interact with. It contained the menu manager. So to allow your application to create pull down menus but something that was different about the toolbox and I think any other recent application programming interface for graphical operating systems is that these were all optional. Once a compute, once an op, once a program had started on the original Macintosh, it had full control of the hardware. And so it had the option, if it wanted, of using the window manager to create multiple windows that could be moved around the screen at the user's behest, but it didn't have to. It could blank the whole screen and use Quick Draw, which was a lower level API, just to draw lines and circles and arcs directly onto the frame buffer. It didn't have to use the event manager to get keyboard input and mouse input. You could just read the hardware on. You could just read the hardware that communicated with the keyboard directly. It didn't have to use a menu manager to create menus, or it could replace parts of the menu manager if it didn't want to, didn't, didn't want to have menus in the style of the operating system. If it wanted menus in its own style, that wouldn't be possible with a modern API, you wouldn't be able to replace large parts of the operating system routinely.

That's so interesting. And that points to this idea of safety again that we were talking about. We were talking about protected memory, right? Is like any app can just talk directly to the hardware. Well, what if an app does something bad when it's talking to the hardware? There's nothing stopping it. There's also then another problem for compatibility because now apps are not only maybe relying on routines that are hard coded in the ROM that then has to be patched over time. And. But there's also now maybe apps that are talking directly to the hardware. And of course the hardware is rapidly evolving. You have apps that might be talking, expecting to be talking to a keyboard on a Mac plus. And then a few years later you have ADB and you have a totally different set of keyboard hardware. And now it's not getting what it expects when it tries to talk to it. So we have another layer of difficulty, I guess, that you've divulged for us for Apple keeping backwards compatibility and for the operating system being able to evolve smoothly as time goes on. The fact that they even allowed this direct access in the first place, but I guess it was pretty standard at the time. I mean, the classic macOS was contemporary in 1984 with DOS or CPM or some other very primitive operating system like you spoke about at the very beginning. There's a totally different mindset and people are not really worrying about security or about, about apps doing bad things. I guess we could say.

Yeah, I think if, if you told people they needed to be worried about this, you know, a threat from their own computer programs that they've caught, they'd sort of scratch your head and say that that was an odd thing to, to worry about. Yeah. We see the heritage of, of the macro as being a, a scaled up and more sophisticated version of like a microcomputer, a home microcomputer operating system, rather than a scaled down version of Unix or Windows NT like we would be using on our, like we are both using on our computers today.

Yeah, that makes sense. Yeah, sorry, go ahead.

Oh, it's, it's in a, it's in a, like an aphoristic louvit and it has a name that I can't remember, but that if you publish an API, eventually somebody will come to depend on every conceivable behavior that the API exhibits, including the unintentional things.

Yeah, no, that makes sense and I think we see that in software engineering still today. So I want to talk about another term from the classic macOS that I think a lot of people who ever used, let's say One of the 1990s machines is familiar with, which is extensions. So when you loaded up Mac OS 7, 8 or 9, you'd see all these icons coming across the screen as the machine loaded and each of those was an extension. So what really were those? And why was it that a lot of times people would tell you, oh, you're having trouble, hold down the shift key and the extensions will be off as your machine boots and maybe things will be okay.

Yeah, so you're talking about the marching puzzle piece shaped icons, the come across the bottom of the computer screen as it starts up. And people would use Mac as Macs for a long time would remember that, both because they would install more software themselves and because the operating system would come with more of these, that row of extensions would get longer every year. Sometimes there would be a second row and a third row. It would cover the whole screen in contrived cases. So people who remember extensions from the 1990s, I would say probably have fairly mixed feelings about them and would remember things like extension conflicts and programs called Conflict Catcher. And maybe if they were power users, would remember extension sets. So what, what was a system extension? Well, the first release of the macOS was not, I don't think intended to have third party software run on it. On it, except for applications. So an icon that you could double click in the finder would suddenly fill your screen and there's Microsoft Word or there's, you know, 1, 2, 3, or some other useful program. But pretty early on, because it was an open system in the sense that it was easy for people to take apart and the guts, you know, the internals of the operating system were fairly well documented. People came up with third party developers, came up with interesting features that they wanted to add to the operating system. They came up with hardware that they wanted to add to the MacIntosh, like a SCSI card or some kind of clever, clever printer card or an external display that required them to be able to modify the operating system. And so that creates a bit of a conflict between Apple wanting to produce operating system releases that reliably work for the user. You know, have a single version number that gives you a pretty good idea of what you're going to get when you start this up on your computer, and third party developers wanting to add cool new features. And so early on, what a third party developer could do to change the behavior of the operating system that started from a particular floppy disk would be to adblock this, called a resource, to the system file, an init resource. Resources were denoted by four letters. They were called type codes by four letter type codes. And the operating system, as part of its startup process would just, would take this chunk of code that you had inserted in a specific way into the system file, and it would just run it as code that the processor can run. And the code would return control to the operating system, having made some kind of change to the system, patched over something in that big table of function pointers we talked about about earlier, changed a particular icon, added an interrupt handler, installed the driver, something like that. And so that application. So that was something that a software installer could do. It could add a resource to your system file. It became a bit impractical for people to, for developers to keep adding these little code resources to the system file. So at some point it became possible just to make them their own files inside, in file, excuse me, on the system disk or inside the system folder. And as part of the startup process of the computer, it would look for any files in your system folder that had this particular type. They became called extensions. And it would run them. It would run the code in that file pretty blindly. It would hope against hope that it would return control to the operating system, but it didn't always. And that code, when it had full control of the computer for that brief moment in the start of the process would make some kind of change in the memory of the computer that would add a feature to the os. So one of the things that these little bits of code had the opportunity to do was to draw an icon on the screen. And I'm not exactly sure how it happened, but it became a, a convention that the code would draw its icon on the screen and then leave the location for the next icon in a special piece of memory somewhere. And so that's how that, that marching extension thing came become a lot came to, came to be wasn't Apple's idea.

So I mean I think we're seeing the same theme here again. Apple is enabling third party developers to basically modify the operating system through these extensions or originally these INIT resources. And that involves, and the reason, and you mentioned like conflict catcher, you'd have to have programs because some of them might modify the operating system one way, another one might modify the operating system another way that's in conflict with the way the first one modified it. And you can get all kinds of problems as a result. And now we again are dealing with cludges that then Apple might need to have backwards compatibility. Now for extensions for ways that third party developers are modifying the operating system. So it sounds like just more of the same mess that they like they found they were trying to actually resolve a mess. It sounds like originally with extensions, but they actually, maybe they knew they were creating this but inadvertently created another set of compatibility issues and problems later on that would make the operating system hard to upgrade.

I mean it's still possible even in modern operating systems for third party software to get into the internals of the machine and change its behavior in the way that adds features. But it hopefully happens in a much more structured way. So a kernel extension on macOS these days needs to tell the kernel what it's doing and what kind of service it provides and how it can be started and how it can be stopped again and removed from the system. Yes. So there were some weak conventions about how extensions should, should behave. But inevitably because it was, you know, they had freedom to make any change that they wanted to the operating system, it was very possible for things to go wrong. And so conflicting combinations of extensions would often cause people's computers to fail in mysterious ways.

So Elliot, one thing I really wanted to talk to you about was the classic macOS file system, because I know you've done several projects related to it or at least one deep project related to it. And I know on the original macOS or we could really say system one there was MFS, which was soon replaced a couple years later by HFS, which then eventually in the 90s, got replaced by HFS plus. And Apple used that file system all the way up until, I think just a few years ago, it might have been like eight years ago or something, that they replaced it with apfs. And so they used this apartment, HFS and HFS plus file system for decades. And so I'm curious to get your impressions of it as somebody who's kind of dug into its internals. And was it a well designed file system? How did it compare to other file systems that were contemporary to it? And maybe why did Apple eventually feel they needed to replace it with apfs?

Well, to start with, you mentioned mfs, the first Macintosh file system. It was only used for a very brief time because it wasn't a well designed file system, but it was good enough for 400 or 800 kilobyte floppy disks with not very many files on them. When the files didn't really need to be organized into folders, there was some. The operating system sort of pretended to have folders, but it was a flat file system essentially. It was a lot like the kind of file system that your Commodore 64 would put on a disk or the Apple II would sit would put on a disk. So I think it shows Apple, you know, that Macintosh's microcomputer heritage pretty well. But then Apple released an external 10 megabyte, maybe 10, maybe 20 megabyte hard disk for Macintosh. It was large enough that people could put lots of files on it. And it really needed a file system like Unix computers had, which was a hierarchical file system, is that folders can contain, folders can contain folders, or directories, I should say main directories which can contain files. I don't actually know who wrote HFS in the. Very soon after, after the Macintosh came out, so 1985, it was called the Turbo file system. That was its codename, by the way. I don't know who wrote hfs, but they did a really good job. They did think I used data structures that even UNIX file systems, even the fast Unix file systems weren't using at the time. It used B trees pervasively, which are an information theoretic or computer theoretic data structure. It's a bit like a binary tree. It enables lists of items to be stored in a way that's space efficient, that's time efficient to add things to it, but it's also time efficient to iterate directly through it. So B trees, we use Pretty pervasively. And a sort of side effect of B trees being used pervasively was that because they were stored more or less contiguously, metadata was really nicely clustered on one part of a disk, which matters a lot when this time required for the arm of the hard disk and the sick time of the hard disk is slow. HFS was a pretty well designed file system. It had a few quirks though. And the quirk, the first quirk that caused a problem for Apple is that even though they had it really, the Macintosh was essentially a 32 bit machine. It could store 32 bit values and manipulate them pretty easily. It only used a 16 bit value for describing, for referencing locations on disk. And so only about 64,000 or 65,000. So the disk had to be divided into a maximum of 64,000, what we call allocation blocks. Which is fine until you get to disks that are hundreds of megabytes in size and then the allocation blocks start to be a bit bigger than the, than the carniv blocks that hard disk can read and write most efficiently. And so the minimum size of a file goes from being 4 kilobytes, which, or 512 bytes, which is pretty reasonable for a small text file. It'll usually be bigger than that to, you know, a couple of kilobytes to 16 kilobytes to 32 kilobytes. And once you get to about that size, your disk space use is really inefficient because tiny files are easier one part in 64,000 of your disk space. So HFS was a really good file system. That was the main flaw that it had, and that was almost the only part of it that HFS plus fixed once you could get hundreds hard disks of hundreds of megabytes in size. So the limit on the number of allocation blocks was really the only thing that H I did a few other things, it was really the only thing that HFS fixed. So you can have 4 billion allocation blocks on an HFS plus disk. And so if you reformatted your HFS disk with HFS plus, you would find that all your small text files no longer used up an inordinate amount of space on your Mac. But everything else worked just as well. And you were, you were pretty happy. It didn't change a few characteristics of HFS that by the mid-90s were starting to get a bit dated. Having one having timestamps with a 1 second resolution made pretty good sense in the 1980s, but these days isn't such a good idea because your computer can get significant operations on files done in a much shorter time than one second. And it's really nice if those operations on the files are reflected in the timestamp rather than just being swallowed up in this one second period. It didn't have a few features which in the. We didn't have a particular feature, which in the 2000s started to become a thing that was really good to have, which is a guarantee that it's always consistent on the disk. And so if while the operating system was updating part of the metadata of a file by renaming it or doing some other operation and then power was lost or the hard drive was disconnected, pretty serious corruption could result because the B tree structure wouldn't be readable when you restarted the machine. Or it would be readable, but it would have a few problems that would become apparent after a few more operations were done on it. Certain pointers that were pointing between nodes could, could not point the way they were supposed to. Although to be fair, that's not a guarantee that most file systems provide today. I think ZFS does provide it. I think APFS does provide it. It's a really nice thing to have. Another way that HFS plus was starting to show its age by the 2000s was that it didn't work very well with multitasking operating system, because there was all the. Because all the metadata of all the files on the file system was held in one virtual or hidden file called the catalog file. Only one operation, only one application or one client of the file system could change that at a time. And so there was a real bottleneck. And the kernel in Mac OS X had to have a very large lock preventing people, preventing to move calls or to rename calls from happening anywhere on the same file system at the same time.

That's really interesting and I think you've really shown why it was innovative for the time, but was not up to scruff for modern times. So one last component of the classic macOS that I really wanted to talk to you about is one you've already mentioned a few times, the nanokernel. And I think when people think about operating systems today, they do often think about the kernel. We think about the Linux kernel, or we think about, I think it's called xnu, the kernel of the modern Mac os. Or when people talk about Windows, they talk about the NT kernel. But when people talk about the classic macOS, it's not usually a part of their discussion, unless you're really deep into hacking it like you are. So can you tell us a bit about what the nanokernel was, what part of the operating system was it responsible for and why is it so interesting to you? As a hacking project, the NanoKernel was.

A very unusual piece of software that ran on all power Macs that ran the classic Mac os. I need to rewind a little bit and mention one of the other quirks of this operating system that I find very charming, but I think that developers at the time found very frustrating, and I know Apple found extremely frustrating, which was that it was a dual architecture operating system. The original Mac OS Macintosh operating system was written for Motorola 68000 processors, which at the time were very fast. They were being used in large workstations and it seemed that they had a very bright future. By the early 1990s it became apparent that Motorola was wasn't going to develop that line of processes much further and Apple needed to start putting different CPUs in their machine. And so through a complex series of business deals, they started putting IBM's power architecture processes in their computers. And at that time the architecture got a few changes and got renamed or got sort of rebranded as PowerPC. So in 1993, after a fair bit of work, Apple released Macintoshes that ran the same operating system but with a different processor. But the operating system had been written in pretty large part in 68k assembly code. And there's no switch that you can switch on your 68k assembler to have it have that spit out power PC machine code. And so just about all of the operating system at that time, this is system 7.1.2 was still made of 68k machine code. 6 Motorola 68000 machine code. And a very clever engineer named Gary Davidian wrote an emulator that would go through every single instruction as it was supposed to be run of the 68k machine code, turn that, run some PowerPC instructions to substitute it for it, move on to the next instruction. This was unsatisfactory, was fast enough. It was only intended as a temporary stopgap measure measure for about six months until the, you know, a better version of the operating system could be produced that depended on PowerPC code, as we saw, as in the event it turned out to take more like six years and six months, which was unfortunate. There was still a way for applications that wanted to run faster than the 68k emulator could run, to break out of the emulator and run native PowerPC code. And lots of applications were released. In fact, in the end most applications were doing that. Some parts, some speed critical Parts of the operating system did that in the early days. And more and more speed critical parts of the operating system got converted to PowerPC code. And so you had this operating system that was always in one of two modes. It was either running 68k code or it was running PowerPC code. And it had to accommodate large parts of the operating system and lots of hardware drivers that expected the machine to act as if in very specific ways, as if it still had a 68K processor. And so puppet stringing this whole messy interaction of components. The lowest level piece of software on the computer, the one that's running the very closest to the hardware, is the PowerPC nano kernel. Its main job is to accept interrupts from the hardware and a driver developer will know what I mean when I say an interrupt. It's when a piece of hardware on the computer, like the floppy disk drive, asks the CPU for attention. It's to take those interrupts from the hardware and make and expose them to the 68K Mac OS. And it's to arbitrate between the 68K part of the macOS and the PowerPC part of the macOS and to make the transition between those two parts of the system orderly. And so the two important pieces of software that permitted the 68K Mac OS to run largely unchanged on the Whiz Bang New PowerPC machines were on the low end, something called the Nanokernel, and on the slightly higher level in something called the 68k emulator. So that was the Nanokernel.

And why are you interested in hacking on the Nanokernel? What got you into that?

I read an April Fool's Day article on tidbits in about 2003 about a non existent software product called Countdown G5 which would promise to let you run Mac OS 9 on what was then new power Mac G5, which is that sort of. There's one behind me. That's that aluminium cheese grater machine that Steve Jobs introduced to great applause in 2003, which used IBM's new PowerPC 970 processor, which was, which was pretty fast. They were really cool machines if you had one when they were new. By 2003, there was no need for Mac OS 9 to run on Apple's new machines, except in the sort of the classic compatibility environment. And so you couldn't start Mac OS 9 on it like you could with a power Mac G4. And I thought, oh, it should be really interesting to get Mac OS 9 running on one of those machines because they are still PowerPC machines. They are still. They have got an updated version of the same CPU architecture, you know, implemented in the silicon. And I thought, well, what's the way to get it? What's the, what's the part of the operating system that runs most closely to the hardware? It's the nano kernel. Yes. So I started disassembling the nano kernel with a text editor and a pile of scripts and wound up with, yeah, I think a bit of an understanding of the history of that piece of software. I never got Mac OS 9 running on the power Mac G5. It's something in the back of my head that I'd like to do one of these days, but I got a pretty, pretty good appreciation and admiration for the two engineers who worked on the two versions of the NanoKernl. I told you that the first one had the job of just really just catching interrupts from the hardware, turning them into something that the 68k operating system doesn't mind, and arbitrating between the fast power PC and the slow 68k runtime context, if you like. A pretty clever chap named Rene Vega came and you can say he rewrote or he really substantially re architected the Nanokernel for one of the later releases of Mac OS 8 to take advantage of the hardware capabilities that were available in the Power Mac G4 line, specifically, not just to arbitrate between the PowerPC and 68K mode on one processor, but to be able to have PowerPC code run on a second processor concurrently with the first one. So it was the multitasking nano kernel. And as part of that it got much bigger because it exposed a really rich multitasking or implemented a really rich multitasking programming interface. And so assembling the nano, disassembling the nanokernal was how I learned actually about assembly code at all, but about PowerPC assembly code specifically. I later found out, by the way, after going to quite a bit of effort to disassemble different versions of it, that the source code had leaked and has been floating around on the Internet for years since then.

Which, I mean, that's. I hope you don't feel like it was a wasted effort. I'm sure you learned a ton disassembling.

It was really fascinating. It's a kind of. Doing that kind of work is a sort of flow state that I really get to achieve at other times. It was extremely good fun.

Well, that's another thing I wanted to ask you about. I wanted to just. I was just curious, like, what are your current interests on the Classic macOS. Like, what are you working on now? Hacking on the classic macOS? What, what project's kind of the highlight of your, of your current endeavors on, on the classic macOS?

Well, I should just rewind a little bit and say that one concretely useful thing that my understanding of the nanokernel did help with was getting Mac OS 9 to work on the Mac mini, which is how we managed to get in touch.

Right? Yeah, I'd love to talk more about that. Why don't we come back to that and tell me. Let's talk a little more about your current projects and we'll, we'll.

Oh, okay. Well, I'm a little bit. Last couple of years I've been a bit time poor for my favorite hobby and so I haven't had much time to come downstairs and work on the hardware. So it's been pretty, well, software only. I've been working for the, for maybe two, not quite two years, maybe 18 months on some virtio drivers for the Mac OS because those, that's a project that I can do just on my laptop, you know, in gaps at work or, you know, on the couch at home. The, the reason for this project is that I like playing with old versions of the Mac os. I hope that's clear by now. It's more convenient to, for other people to share in that hobby. And it's easier for me to do that if I could run it in an emulator on my nice compact, modern laptop than if I have to go down and, you know, start up loud, stinky, potentially sometimes slightly dangerous, you know, hardware in my basement. And so emulators have a really big role to play in, you know, retro computing and in people who are, in the lives of people who are interested in using these old operating systems. Making the system work as well as I can in an emulator, I think is a pretty good thing to spend my time on. And so if you've ever used a virtual machine on your computer, you would know that the first sticking point, the first really annoying thing, is when the virtual machine doesn't recognize that it's in a virtual machine. And so you have to click into the window so that the mouse cursor can start to be controlled and then press a special key combination so that the mouse no longer gets controlled. Now, somebody before me had already written a driver to, so that the Mac OS 9 or system 7 running inside QEMU would think it was being driven not by a mouse, but by one of those Wacom tablets that let you drag Your mouse cursor across the screen. Have you used one of those before?

I have used a Wacom tablet before, but it has been about 20 years, so it's been a while.

Anyways, like the usual way of convincing a virtual machine that the mouse cursor should be exactly where the user expects it to be is to tell it that here's a Wacom tablet. So somebody had written a tablet driver. I wrote another tablet driver with my own little spin on it. And then I thought, well, there are other little nice conveniences that would be useful, little affordances that would be useful. One of them is that you need to put all the files that you want to access on this machine, on this virtual machine into a disk image. And working with disk images, I've written a bit of software for it. Lots of people have written a bit of software for it. It remains a pretty significant pain, only more so now that macOS, current macOS has dropped support for HFS disks and will probably at some point drop support for HFS plus disks as well. And so you can't double click the image to mount it. You need to use software in your terminal. So I've been writing a virtual file system driver so that your Mac OS 7 or 8 or 9 virtual machine can read files on your in a folder on your host hard disk. And that's been a very long running project. Because the macros view of a file system is quite a bit different. So the classic macOS view of a file system is quite a bit different from the sort of the dominant way that file system APIs work now, which is Unix style. And so the main difference is that macOS expects each file to have two forks. One is the data fork of unstructured data, and the other is the resource fork of richly structured data with textual file types and things like that encoding those on a modern file system. There are quite a few ways that it's done with names like appledouble and binhex. There's a proliferation of standards. I'm guilty of adding my own one because I thought my is just a little bit better than all the other ones. And so adding support for those is a bit demanding. The file system macOS expects the file system to remember where each window was opened on the screen. So don't there again. And it has this other little quirk where macOS applications feel that they should always be able to access a folder just by giving a 32 bit number associated with that folder. And that's not something that Unix operating systems usually allow an application to do Unix operating systems have an inode number for each directory and for each file. So there is such a concept. But it would be circumventing the Unix permission model if a file was simply allowed to. If an application was simply allowed to say I want file number 365 please. And so making that work. So bridging that kind of gap there is quite challenging. And so it has taken me 18 months to write that file system. It only just barely works. The Apple manual for how to do that. It starts with an admonition that this isn't really something that most people are going to want to do. It's very, very hard, not particularly rewarding, and prone to subtle bugs. And they're absolutely right.

You know, I'm wondering if and this might be getting a little too esoteric, but if you know how some of the other emulators kind of handle this. Because for example, I know in Sheepshaver there's a way to mount your folder from your your host computer's hard drive. In Sheepshaver. So is this going to be somewhat similar to the way that you're handling this or is this, is that unrelated?

No, it's very closely related. There are a few differences with with between my implementation and shapeshavers. That one is much more mature than mine. But even in its maturity there are a few things that it can't do. Some kind of API calls that it just responds to incorrectly and so some programs that it's not compatible with and you can't boot to Virtual machine from sheepshavers shared folder Bin K can boot a virtual machine from. From my one, but there are there. Yes, I've used theirs as a reference.

I've.

I've shamelessly, you know, scanned the code in the Sheepshaver external FS implementation and hopefully mine will be as good as it as that one in some ways and will exceed it in some other ways. The reason to do one for Qingu is that. Is that Cheap Shaver is potentially coming to its the end of its useful life as an emulator. It makes lots, it takes lots of shortcuts in emulating the Mac OS and which really limits its software compatibility. But Cheap Shaver is a. Sorry, QEMU is a much more hardware accurate emulator and so it just naturally has really better compatibility.

That's really interesting and that actually is a good segue to the last couple topics I wanted to discuss. You mentioned earlier the hacks that you had done to get the. With some other team folks as well to get the macOS running on the Mac mini G4. And that's been. I want to publicly thank you for that and the rest of the team because that's been personally a big deal for me in the last year. So I had my son who's now 4 years old, but was 3 years old at the time. I had really limited his screen time the first few years of his life. Me and my wife had really limited screen time. And then we noticed, you know, he doesn't have great hand to eye coordination. And we were like, maybe if we could get him using a mouse, you know, his hand to eye coordination will improve. And I thought, you know what, I'd love to have him using some of the software. I remember growing up in the 90s and so then I found out about your project because I actually collect classic Macs like you do, but I was like, what if I could just get him right at the beginning on the fastest possible machine to run this classic software that I loved in the 90s. And so I found out about your hack for the Mac mini G4 and I purchased a couple of them on ebay. I actually purchased three at first because they were all broken. I bought like three broken ones and I installed an SSD in one and I installed the hacked version that you and the team had developed of Mac OS 9 for it and it worked wonderfully. And I got, I got my son working with the software and I will say now that was about 10 months ago. His hand eye coordination has really improved and he's actually very good with the mouse. So it's been great for him. And none of the junk from the Internet is on that machine of course. So it's, it's a very safe environment for as a young child to, to be in. Um, and it actually led to me getting into like a hobby business. I had these extra other machines and so I upgraded the other two and I ended up selling them on ebay. And then I was like, why don't I buy more and keep doing this? And so I've, I've actually. So it's been very impactful for me, the work that you did and the team did personally. So I want to thank you for that. And I'm curious if you could speak a little bit since you're so involved in this community, about why people are still running the classic Mac os. Whether it is because they want to go hack a Mac mini G4 and they want to run Mac OS 9 or whether it is because they want to use QMU and they Want to run the Mac OS in an emulator? As you've seen so many people be involved in this, like, what is it that inspires them? What is it that keeps them coming back to this classic operating system that actually at this point in 2025, I think Apple had a funeral for. I think it was either 2001 or 2002 Steve Jobs had a funeral for. So it's 23 years after its funeral and people are still coming back. There's actually a big community of people interested in the vintage Mac world. And what do you think is driving this interest?

Well, I would encourage anyone to ever have to watch that WWDC funeral video. It's pretty, pretty funny. Thanks for what you've just said, David. I appreciate it very much. Thanks for sharing that story about your son. That's, that's brilliant. I'm glad that you're sharing, you know, your own kind of childhood and the, you know, fun that you've had with him. That's that that kind of connection might go some way to explaining why people are still really passionate about these community, you know, about joining a community of people who are interested in these old computers. And thanks also for, for starting a hobby business that, that preserves these Macs and gets them in people's hands because the hardware is, you know, they're not making those anymore. The hardware is only going to decay, decay with time. And the only thing that can keep a computer working long term is human care and interest being taken in it. So I think by getting these into the hands of interested hobbyists, you're doing a really good job for the preservation of what really are cultural artifacts that have got a limited life, but I think are valuable to future generations. And so if even a handful of these machines are still working after you and I are gone, that would be, that would be a really good thing and you'd have contributed to that. So why do people like using old Macs specifically and old computers in general? I can name a few reasons why I think it is, but I'm not quite sure. I suppose the small to lower smaller scale reason is that childhood for most people is a happy time. And so people who were born in the 1980s and 90s really like to use computers that work like the first computers that they worked with. Nostalgia is a really great high and I think that's excellent. Maybe a bit more broadly, I think that retro computing in general is a bit of a cry for freedom from software companies that behave very paternally in their business practices and in the kind of hardware that they produce in the software that they release. I think it, it's a expression of a yearning for a computer that you own entirely and that you can run your own software on in whatever configuration you would like without having to ask someone permission. And I think it's a, you know, it sort of expresses an aspiration. Yeah. For a, for a more democratic computing world.

I like that. And I think you hit on in my experience doing this hobby business, like 90% of the customers that I've had, the only additional ones, and I don't know if you'll even find this surprising, but I've had a couple customers who were museum curators and so I don't think they're using, they're not putting the Mac mini G4 up on display, but they have old software that they want a really power efficient, quiet machine to run that is used in the museum. And there's actually been a couple different museums. And then I'm sure you're familiar with also there's these old folks using. I don't mean that they're old, but I mean there's folks using old audio software. There's audio software from the 1990s that people are still using in production, which some people might find really surprising. Like why wouldn't you use like modern audio? Well, it works well for them. It has a particular sound, it has a particular way that it fits into their studio. And so they're still using the Mac OS 9 is actually still a production operating system for some people. And you even hear about some old print shop sometimes it's still running like QuarkXPress 5 or something. And so there actually are people still using these machines for their work. And so the work you're doing is not only for the vast majority of people who are using it, getting people to relive some nostalgia or feel some, some connection or preserve some history, but it's also actually helping people in their day jobs being able to still preserve the software, whether through emulation or through hardware.

And I just think that's brilliant. And if that's what provides the impetus for preserving the software and hardware that I couldn't be happier. I'm not one of those people who does digital audio workstations that run OS9, but they're pretty cool people and I wish them every success. So I suppose what you really highlighted there is that there's no particular one reason that people like, you know, vintage computers, but it's a real broad coalition. And I think that's really, that's really good. Having such a variety of different motivations for getting interested in this hobby. It bodes well for the future of retro computing and retro Mac computing as a hobby.

And I think the other thing I love being in this hobby is just how quirky, kind of the old Apple was in some ways, and how fun the classic Mac OS was. And I think we've lost that a little bit in how sterile a lot of our modern operating systems and computing systems feel. But there was something about the classic macOS, the whole character of it, that just felt friendly. It felt like. It felt like, yes, it was a tool to get your work done, but it also felt like it was a tool that was working with you. And I think this is what you were getting to earlier about the paternalistic attitude of modern software companies. It felt like it was a tool that was working with you to get your work done, instead of a tool that sometimes feels like it's working against you with, with, with modern operating systems. At least that's, that's how I feel. I couldn't put a better Elliot, it's been a great discussion. I want to thank you so much for coming on the show. I have two final questions for you. One is, what are you up to next? What are some next projects for you related to hacking the macOS or otherwise? And also if listeners want to get in touch with you, how can they follow you on social media or send you an email? Of course I'm going to put a link in the show notes to your GitHub and to your website. But is there any, any other way that listeners could reach out to you next?

For me, I've got. Well, I'd like to make a bit more progress on my QEMU file system project and if anybody, any of your listeners has a bit of experience with either QNU or macOS or exotic old file systems, then I'd love to hear from them. I'd like to play a bit more with the builds that we have of the Copeland pre releases. So the failed Mac OS 8 project, because I think that some of them, with a little bit of tweaking actually might be a bit. It might be possible to make them a bit less crashy and unstable than they're reputed to have been. And lots of code from Copeland found its way into the lake os, so doing sort of comparison work would be interesting. And I still want to get Mac OS 9 to run on a power Mac G5.

I imagine that's a hard project. Like from what your descriptions earlier in the episode that is something that. How realistic do you think that really is?

I think I've got about 1.1chance in 3 of seeing it happen. But it will.

That's pretty good.

It will be enjoyable in the attempt.

Okay. And so that's very interesting. And we'll be looking out for that. That would be really something. I think that would shake the vintage Mac world a little bit because I'm seeing a lot of posts on forums about preserving the Power Mac U5. Now it's become a real area of interest to a lot of people in a way that I don't think it was five or even or 10 years ago. And that would really be pretty earth shattering. So also, how can our listeners get in touch with you or follow you or if they want to reach out.

Keep an eye on my projects on GitHub. You can find me on the elephant website just under the name Elliot Numb. Shouldn't be too hard to find. And you're very welcome to shoot me an email. Why don't we obfuscate my email address and put it in the sort of the show notes?

Absolutely. Yeah. We'll put a link to your mastodon as well. Okay. Elliot, thank you so much for coming on the show. I really appreciate it. And our listeners do too, I'm sure.

Thanks very much, David. It's been a really good talk and I appreciate it a lot.

Thank you very much to Elliot for coming on the show. I hope you enjoyed our dive into the classic Mac os. If you're interested in purchasing the ultimate machine for running the classic Mac OS, you can buy one from me at OS9 shop. That's OS9 period. S H O P. And I want to remind you to leave us a review on Apple Podcasts or Spotify or wherever you're listening to the show. The show has become a little bit more irregular, but if you follow or subscribe, you'll get notified when we come out with new episodes and we look forward to talking to you again on the next one.

Bye.