macOS Archive

Yesterday we had SDL2 for the classic Mac OS, today we have modern SSL/TLS for the classic Mac OS. This is a C89/C90 port of MbedTLS for Mac System 7/8/9. It works, and compiles under Metrowerks Codewarrior Pro 4. This is a basic app that performs a GET request on whatever is in api.h, and prints the result out to the text box (with a lot of debug information, of course). The idea of this project was to build an ‘app’ of sorts for 640by480, my ‘instagram clone for vintage digital cameras’. The idea would be to login, post images, view images, and read comments. I would need HTTPS for that, so here we are: a port of MbedTLS for the classic mac. ↫ MacSSL GitHub page It’s remarkable what tenacity can achieve.

Well, this you certainly don’t see every day. This is a “rough draft” of SDL2 for MacOS 9, using CodeWarrior Pro 6 and 7. Enough was done to get it building in CW, and the start of a “macosclassic” video driver was created. It DOES seem to basically work, but much still needs to be done. Event handling is just enough to handling Command-Q, there is no audio, etc etc etc. ↫ A cast of thousands The hardest part was a video driver for the classic Mac OS, which had to be created mostly from scratch using the QNX driver as a “skeleton” because it happened to be the smallest one. It works on both m68k and PowerPC as well as on SheepShaver and Basilisk II, and there’s already a few screenshots of it up and running at the link, too. Amazing work, and it opens the door for a whole bunch of especially games to be made available on classic Mac OS.

I signed up for GlobalTalk in 2024, but never found the time to get a machine set up. Fast-forward to MARCHintosh 2025 and I wasn’t going to let another year go by. This is a series of notes from my experience getting System 7.6 up and running on QEMU 68k on Ubuntu. Hopefully this will help others that might be hitting a roadblock. I certainly hit several! ↫ Cale Mooth A short and to-the-point guide for those of us who want to partake in GlobalTalk but can’t due to the lack of compatible hardware.

James Thomson, developer of, originally, DragThing and now PCalc, also happens to be the developer of the very first publicly shown version of the Mac OS dock. Now that it was shown to the world by Steve Jobs exactly 25 years ago, he reminisces about what it was like to create such an iconic piece of software history. The new Finder (codename “Millennium”) was at this point being written on Mac OS 9, because Mac OS X wasn’t exactly firing on all cylinders quite yet. The filesystem wasn’t working well, which is not super helpful when you are trying to write a user interface on top of it. The Dock was part of the Finder then, and could lean on all the high level C++ interfaces for dealing with disks and files that the rest of the team was working on. So, I started on Mac OS 9, working away in Metrowerks Codewarrior. The Finder was a Carbon app, so we could actually make quite a bit of early progress on 9, before the OS was ready for us. I vividly remember the first time we got the code running on Mac OS X. ↫ James Thomson I especially like the story about how Steve Jobs really demanded Thomson live in Cupertino in order to work on the dock, instead of remaining remote in Ireland. Thomson and his wife decided not to move to the United States, so he figured he’d lose his assignment, or maybe even his job altogether. Instead, his managers told him something along the lines of “don’t worry, we’ll just tell Steve you moved”. What followed were a lot of back-and-forth flights between Ireland and California, and Thomson’s colleagues telling Steve all sorts of lies and cover stories for whenever he was in Ireland and Steve noticed. Absolutely wild. The dock is one of those things from my years using Mac OS X – between roughly 2003 and 2009 or so – that has stuck around with me ever since. To this day, I have a dock at the bottom of my screen that looks and works eerily similar to the Mac OS X dock, and I doubt that’s going to change any time soon. It suits my way of using my computer incredibly well, and it’s the first thing I set up on any new installation I perform (I use Fedora KDE).

Firmware, software that’s intimately involved with hardware at a low level, has changed radically with each of the different processor architectures used in Macs. ↫ Howard Oakley A quick but still detailed overview of the various approach to Mac firmware Apple has employed over the years, from the original 68k firmware and Mac OS ROMs, to the modern Apple M-specific approach.

You have to wonder how meaningful this news is in 2024, but macOS 15.0 Sequoia running on either Apple Silicon or Intel processors is now UNIX 03-certified. The UNIX 03 Product Standard is the mark for systems conforming to Version 3 of the Single UNIX Specification. It is a significantly enhanced version of the UNIX 98 Product Standard. The mandatory enhancements include alignment with ISO/IEC 9989:1999 C Programming Language, IEEE Std 1003.1-2001 and ISO/IEC 9945:2002. This Product Standard includes the following mandatory Product Standards: Internationalized System Calls and Libraries Extended V3,Commands and Utilities V4, C Language V2, and Internationalized Terminal Interfaces. ↫ UNIX 03 page The questionable usefulness of this news stems from a variety of factors. The UNIX 03 specification hails from the before time of 2002, when UNIX-proper still had some footholds in the market and being a UNIX meant something to the industry. These days, Linux has pretty much taken over the traditional UNIX market, and UNIX certification seems to have all but lost its value. Only one operating system can boast to conform to the latest UNIX specification – AIX is UNIX V7 and 03-certified – while macOS and HP-UX are only UNIX 03-certified. OpenWare, UnixWare, and z/OS only conform to even older standards. On top of all this, it seems being UNIX-certified by The Open Group feels a lot like a pay-to-play scheme, making it unlikely that community efforts like, say, FreeBSD, Debian, or similarly popular server operating systems could ever achieve UNIX-certification even if they wanted to. This makes the whole UNIX-certification world feel more like the dying vestiges of a job security program than something meaningful for an operating system to aspire to. In any even, you can now write a program that compiles and runs on all two UNIX 03-certified operating systems, as long as it only uses POSIX APIs.

We all know about the Desktop Publishing revolution that the first Macs and their PostScript LaserWriter printers brought in the late 1980s, but many have now forgotten the Desktop Video revolution that followed in the next decade. At its heart was support for multimedia in Apple’s QuickTime. QuickTime isn’t a single piece of software, or even an API in Classic Mac OS, but a whole architecture to support almost any media format you could conceive of. It defines container and file formats for multiple media types, forming the basis for the MPEG-4 standard, extensible encoding and decoding of a wide variety of media using Codecs, and more. ↫ Howard Oakley As a Windows users before I switched to the Mac somewhere in 2003 or 2004 or so, I mostly associated QuickTime with an annoying piece of crapware I sometimes had to install to watch videos, despite my Windows installation being perfectly capable of playing a whole slew of video codecs just fine. To make matters worse, Apple eventually started forcing Windows users to also install their auto-update tool that ran in the background, which would occasionally just… Install stuff without your permission. Of course, QuickTime was a whole lot more than that, especially on the Mac, where it was simply a core technology of the Mac operating system and the name of the built-in video player. It also served as underpinnings for a whole slew of related technologies, from movie editors like iMovie to the QuickTime streaming tools included in Mac OS X Server, so odds are that somehow, somewhere, you’ve used QuickTime in your life time. I’m not entirely ashamed to admit I had to check if QuickTime was still part of macOS today – I haven’t actively used macOS since, I think, the Snow Leopard days in 2009 – but it obviously has been sunset quite a while ago in favour of AVFoundation, which macOS still uses today.

It’s one of the most pervasive common wisdoms shared all over the web, no matter where you go – it’s one of those things everybody seems to universally agree on: Chrome will absolutely devastate your battery life on the Mac, and you should really be using Safari, because Apple’s special integration magic pixie dust sprinkles ensures Safari sips instead of gulps electricity. Whether you read random forum posters, Apple PR spokespeople, or Apple’s own executives on stage during events, this wisdom is hard to escape. Is it true, though? Well, Matt Birchler decided to do something entirely revolutionary and entirely unheard of: a benchmark. Back in the olden days of yore, we would run benchmarks to test the claims from companies and their PR departments, and Birchler decided to dust off this old technique and develop a routine to put the Chrome battery claims to the test. After 3 days of continuous testing on a freshly installed 14” MacBook Pro with an M2 Pro processor and 16 GB RAM running the latest stable releases of both browsers, Birchler came to some interesting conclusions. In my 3-hour tests, Safari consumed 18.67% of my battery each time on average, and Chrome averaged 17.33% battery drain. That works out to about 9% less battery drain from Chrome than Safari. Yes, you read that right, I found Chrome was easier on my battery than Safari. While I did experience some variability in each 3 hour test run, Chrome came out on top in 5 of the 6 direct comparisons. ↫ Matt Birchler His methodology seems quite sound and a good representation of what most laptop users will use their browser for: YouTube, social media, a few news websites, and editing a Google Doc, in a 20 minute loop that was repeated for three hours per test. Multiple of these three hour tests were then ran to counter variability. I highly doubt using different websites will radically change the results, but I obviously am curious to see a similar test ran on Windows and Linux, x86 and ARM, for a more complete picture that goes beyond just the Mac. Conventional wisdom is sometimes wrong, and I think we have a classic case of that here. While there may have been a time in the past where Chrome on the Mac devastated battery life, it seems Chrome and Chromium engineers have closed the gap, and in some cases even beat Safari. Now, this doesn’t mean everybody should rush and switch to Chrome, since there are countless other reasons to use Safari over Chrome other than supposed battery life advantages. With Apple PR arguing that alternative browser engines should not be allowed on iOS because Chrome would devastate iOS’ battery life, tests like these are more important than ever, and I hope we’re going to see more of them. Tech media always just seems to copy/paste whatever manufacturers and corporations claim without so much as a hint of skepticism, and this benchmark highlights the dangers of doing so, in case you didn’t already know believing corporations was a terribly idea.

Speaking of an operating system for toddlers: Apple is eliminating the option to Control-click to open Mac software that is not correctly signed or notarized in ‌macOS Sequoia‌. To install apps that Gatekeeper blocks, users will need to open up System Settings and go to the Privacy and Security section to “review security information” before being able to run the software. ↫ Juli Clover at MacRumors On a related note, I’ve got an exclusive photo of the next MacBook Pro.

With macOS Sequoia this fall, using apps that need access to screen recording permissions will become a little bit more tedious. Apple is rolling out a change that will require you to give explicit permission on a weekly basis to these types of apps, and every time you reboot your Mac. If you’ve been using the macOS Sequoia beta this summer in conjunction with a third-party screenshot or screen recording app, you’ve likely been prompted multiple times to continue allowing that app access to your screen. While many speculated this could be a bug, that’s not the case. ↫ Chance Miller Everybody is making comparisons to Windows Vista, but I don’t think that’s fair at all. Windows Vista suffered from an avelanche of permission dialogs because the wider Windows application, driver, and peripheral ecosystem was not at all used to the security boundaries present in Windows NT being enforced. Vista was the first consumer-focused version of Windows that started doing this, and after a difficult transition period, the flood of dialogs settled down, and for a long time now you can blame Windows for a lot of things, but it’s definitely not throwing up more permission dialogs than, say, an average desktop-focused Linux distribution. In other words, Vista’s UAC dialogs were a desperately necessary evil, an adjustment period the Windows ecosystem simply had to go through, and Windows as a whole is better off for it today. This, however, is different. This is Apple having such a low opinion of its users, and such a deep disregard for basic usability and computer ownership, that it feels entirely okay with bothering its users with weekly – or more, if you tend to reboot – nag dialogs for applications the user has already properly given permission to. I don’t have any real issues with a reminder or permission dialog upon first launching a newly installed screen recording application – or when an exisiting application gains this functionality in an update – but nagging users weekly is just beyond insanity. More and more it feels like macOS is becoming an operating system for toddlers – or at least, that’s how Apple seems to view its users.

Howard Oakley has written an interesting history of secure enclaves on the Mac, and when he touches upon “exclaves”, a new concept that doesn’t have a proper term yet, he mentions something interesting. While an enclave is a territory entirely surrounded by the territory of another state, an exclave is an isolated fragment of a state that exists separately from the main part of that state. Although exclave isn’t a term normally used in computing, macOS 14.4 introduced three kernel extensions concerned with exclaves. They seem to have appeared first in iOS 17, where they’re thought to code domains isolated from the kernel that protect key functions in macOS even when the kernel becomes compromised. This in turn suggests that Apple is in the process of refactoring the kernel into a central micro-kernel with protected exclaves. This has yet to be examined in Sequoia. ↫ Howard Oakley I’m not going to add too much here since I’m not well-versed enough in the world of macOS to add anything meaningful, but I do think it’s an interesting theory worth looking into by people who posses far more knowledge about this topic than I do.

noTunes is a macOS application that will prevent iTunes or Apple Music from launching. Simply launch the noTunes app and iTunes/Music will no longer be able to launch. For example, when bluetooth headphones reconnect. You can toggle the apps functionality via the menu bar icon with a simple left click. ↫ noTunes GitHub page Apparently, this is such a common complaint that an application had to be made just to gain some semblance of control over what some people still refer to as “their” computer. For both macOS and Windows, there’s a giant industry – you can’t really call it a cottage industry anymore at this point – of tools, applications, and fixes just to deal with or avoid all the user-hostile, anti-choice garbage Apple and Microsoft shove into their respective operating systems. As a Linux user – and recent OpenBSD convert – I find this absolutely wild. Following any Apple podcast, or reading any Windows website, makes it so clear just how many hoops these people have to jump through and how many weirdly-shaped holes they have to contort into just to be able to gain some vague semblance of ownership of their own hardware. I’m not judging – we all have areas in our lives where we do this, they just differ from person to person – but it’s still confronting to see it so clearly, all the time.

This is a contender for the World Record for Feature Creep Side Project. It is pretty high in the contender list as it’s a bolt on to another contender for the World Record for Feature Creep Side Project (the MII Apple //e emulator). It is a library that duplicate a lot of a Macintosh Classic “Toolbox” APIs. It is not a complete implementation, but it is enough to make a few simple applications, also, all the bits I needed for the MII emulator. ↫ libmui GitHub page This is absolutely wild.

About a year ago I came across the Previous emulator – it appeared to be a faithful simulation of the NeXT hardware and thus capable of running NeXTStep. While including it in Infinite Mac would be scope-creep, NeXT’s legacy is in many ways more relevant to today’s macOS than classic Mac OS. It also helped that it’s under active development by its original creator (see the epic thread in the NeXT Computers forums), and thus a modern, living codebase. Previous is the fifth emulator that I’ve ported to WebAssembly/Emscripten and the Infinite Mac runtime, and it’s gotten easier. As I’m doing this work, I’m developing more and more empathy for those doing Mac game ports – some things are really easy and others become yak shaves due to the unintended consequences of choices made by the original developers. Previous is available on multiple platforms and has good abstractions, so overall it was a pretty pleasant experience. ↫ Mihai Parparita By porting previous to WebAssembly/Emscripten, Infinite Mac now offers access to a whole slew of NeXTSTEP releases, from the earliest known release to the last one from 1997. There’s also a ton of applications added to make the experience feel more realistic. This makes Infinite Mac even more useful than it already was, ensuring it’s one of the best and easiest ways to experience old macOS and now NeXTSTEP releases through virtual machines (real ones, this time), available in your browser. I’ll be spending some time with these new additions for sure, since I’ve very little experience with NeXTSTEP other than whatever I vicariously gleamed through Steven Troughton-Smith‘s toots on the subject over the years. Mihai Parparita is doing incredibly important work through Infinite Mac, and he deserves credit and praise for all he’s doing here.