Blog

I'm trying to revive my old Macintosh Plus. The plan is to put a BlueSCSI in it, so instead of a real hard drive it boots from an SD card, and I've started building the hard disk image that will go on that card: System 6.0.8 plus the software I want on the machine. I'm putting it together in Mini vMac, an emulator of the same Mac Plus, so I can set everything up on my modern Mac before any of it touches the real hardware.

Most of the old games and apps I wanted come as .hqx or .sit files, and that's where last night went.

Getting files into the emulator

Mini vMac can't see files on your Mac's disk. It only mounts disk images, so dragging a .sit straight onto its window gets you nowhere:

For single files there's a small utility called ImportFl: you run it inside the emulated Mac, drag a file onto the Mini vMac window, and it saves a copy onto the emulated disk. So my first approach was to import the .sit files with ImportFl and expand them inside System 6 with StuffIt Expander, the way you would have done it back in the day.

StuffIt Expander didn't recognise them

That mostly didn't work. StuffIt Expander either didn't recognise the files at all or refused to open them. It took me a while to work out why, and it turned out to be three separate problems:

• Double wrapping. Some downloads are a StuffIt archive wrapped in BinHex (.hqx, the text encoding used to send Mac files safely over email and the early internet). The StuffIt versions that run on System 6 can't decode BinHex; that needs a separate tool first.
• Newer StuffIt formats. A lot of archives are saved in the StuffIt 5 format from 1998. No version of StuffIt that runs on System 6 can open those, however you get them onto the machine.
• Lost file types. Classic Mac files carry a hidden type and creator code, and that's how the old tools know what a file is. ImportFl brings files in without them, so even a perfectly good archive just looks like an unknown document to StuffIt Expander.

The fix: unpack on the host, mount a .dsk

In the end I stopped fighting it inside the emulator. I unpack everything on my modern Mac instead, with unar (the command-line version of The Unarchiver). It handles BinHex and every StuffIt version, and on macOS it keeps the resource forks and type and creator codes that old Mac files depend on.

What comes out is either a disk image or a pile of loose Mac files, so a small Python script turns each download into a raw .dsk image that Mini vMac can mount:

• Existing disk images, such as Disk Copy 4.2 images, get converted to raw .dsk.
• Loose files get packed into a fresh HFS volume, with their folders, resource forks and type and creator codes intact.

Now it's simple: I drag a .dsk onto the Mini vMac window, it mounts as a disk in System 6, and I copy the game or app onto the emulated hard disk. No ImportFl, no StuffIt, no guessing why a file won't open.

Next

The next step is to test everything in the emulator, finish the hard disk image, and then copy it to the SD card for the BlueSCSI and try it on the real Plus.

Barista 1.1 is out on the App Store. The 1.0.x updates were mostly fixes and small additions; this is the first release that adds real features. Here are the main ones.

Command palette

Press ⌥⌘K and a Spotlight-style search box appears. Type part of a widget's name, pick it with the arrow keys and Return, and its popover opens. If the widget isn't in your menu bar, choosing it adds it and opens it.

Your own global shortcuts

Settings now has a Shortcuts pane where you can rebind the built-in shortcuts (the Barista bar, Search, Clipboard and the command palette), clear any of them, and add new ones: quick-add a reminder, quick-add a calendar event, or open any specific widget with its own key combination. Restore defaults puts everything back.

Popovers you can unpin

A popover no longer has to stay under its menu-bar icon. Unpin it (the corner button or ⌘P) and it becomes a small floating window with a title strip: drag it anywhere, resize it from the corner, and close it when you're done. It reopens where you left it, and a reset button folds it back under the menu bar.

Notifications open the right thing

Clicking a notification now opens the widget it came from, on the exact item. A new-mail notification opens that email, not just the inbox. Calendar notifications still open the meeting link.

Calendar: a horizontal layout

The calendar has a new Orientation setting. The original vertical layout is still there, and the new horizontal one works as a day dashboard: the day's events and reminders on the left, with an Upcoming section below them, and the month grid on the right. On a wide screen it shows a lot more at a glance.

Email: filters, VIPs and clearer unread mail

The email widget can now show only unread or only starred messages. You can mark senders as VIPs so their mail floats to the top, or mute senders so they disappear from the list. Unread messages are also easier to spot, with a tinted row and separators between messages.

Weather and News

Weather gets a 10-day forecast, a wide layout with the forecast on the right, and next-hour rain and severe-weather alerts where WeatherKit provides them. News gets read and unread state with Mark all read, a saved list for reading later, notifications when a headline matches a keyword, and OPML import and export so you can bring your feeds from another reader.

Fixes

1.1 also fixes a crash when opening the calendar after an event had been deleted elsewhere, some emails showing up as raw encoded text instead of the message, and the Webpage and Email widgets going blank when macOS reclaimed their web renderer. They now recover on their own.

The full list is in the app's What's New window.

Barista is on the Mac App Store.

I originally posted this elsewhere some time ago. The problem is long solved, but I'm putting it here too, as a note for my future self and for anyone who lands here from a search.

The problem

At some point, a few games on my Apple silicon Mac mini stopped playing any sound at all. Other games were completely fine. The ones I noticed it in were Cities: Skylines, StarCraft II and Heroes of the Storm.

The fix

A quick disclaimer first: this is what worked on my machine, so do it at your own risk.

The cause was an extra audio driver that Microsoft Teams installs as a plug-in. I deleted its folder, restarted the Mac, and the sound came back:

/Library/Audio/Plug-Ins/HAL/MSTeamsAudioDevice.driver

While looking into it, I found other people with silent games who fixed them the same way, by removing extra audio drivers. Some of those reports were about the audio driver that Zoom installs, so it's not only a Teams thing. If you have similar symptoms, /Library/Audio/Plug-Ins/HAL/ is a good place to look.

One more thing: removing the driver didn't break Teams. It kept working normally for me, so I'm honestly not sure what the driver is for. It's an optional component in the Teams installer, so you can also just leave it unchecked when you install.

In the last post I wrote about what Barista is and why I built it. This one is about the building part: three problems that took far longer to figure out than they should have, and what I learned from each.

1. The app that died before it started

Barista's weather widget uses WeatherKit, Apple's weather service. Adding it was supposed to be a small change: enable the service for the app, add one entitlement, call the API. Instead, the next development build refused to launch. No crash report, no error, nothing in the logs under the app's name. The process was simply killed the moment it started (exit code 137, a SIGKILL).

The cause turned out to be a chain of things I didn't know:

• As soon as an app carries any com.apple.developer.* entitlement (WeatherKit is one), macOS fully checks its provisioning profile at launch. Without such an entitlement, that check is mostly skipped, which is why every earlier build had worked fine.
• A development profile only works on the Macs listed in it.
• On Apple Silicon Macs, the ID the developer portal needs is the Provisioning UDID, not the Hardware UUID. Both appear in System Information, and the Hardware UUID looks like the obvious choice, so that's the one I had registered.

So my own Mac wasn't in the profile, and the system killed the app before any of my code ran. The fix was registering the right ID, which you can find with:

system_profiler SPHardwareDataType | grep "Provisioning UDID"

One more catch: I build Barista with Swift Package Manager and a shell script rather than Xcode, and Xcode normally adds two entitlements (the application identifier and team identifier) behind the scenes. Without them the same check fails too, so they now sit explicitly in the entitlements file.

TestFlight and App Store builds never had the problem, because distribution profiles aren't tied to specific Macs. Which made it even more confusing: the "real" builds worked and only my local ones died.

2. Writing a small email client

I didn't want the email widget to depend on Mail.app, so Barista talks to mail servers itself, using IMAP to read and SMTP to send. The client is written on top of Apple's Network framework and only implements the handful of commands the widget needs.

It only supports servers that accept a TLS connection straight away (ports 993 and 465). The older way, where a connection starts unencrypted and upgrades to TLS partway through (STARTTLS), has no clean path in Apple's NWConnection, and the direct approach is the more secure one anyway. When someone adds a server that only supports STARTTLS, the setup says so plainly instead of failing with a vague error.

A few lessons from the first weeks:

• Sequence numbers move. IMAP gives each message in a mailbox a position number and a separate, stable ID (the UID). I originally marked messages as read using the position number, remembered from when the list was loaded. But if anything removes a message in between (a server-side filter, Gmail sorting mail into categories, your phone), every position after it shifts, and the server marks the wrong message as read. Switching every action to UIDs fixed it.
• Not all mail is UTF-8. Older mail and some languages still use legacy encodings like Windows-1252, ISO-8859-7 (Greek) or Shift_JIS. They showed up as =E9 artifacts or garbled text until the client started reading the declared charset of each message and header and decoding with it.
• Reconnecting is slow. At first, every page of the inbox opened a fresh connection: TCP, TLS handshake, login, fetch, logout. That's 500 to 800 ms per click. Keeping one logged-in connection per account brought paging down to around 250 ms. Later I did the same for opening a message, and added a small in-memory cache so recently fetched messages open instantly.
• Data indices can surprise you. I buffered server responses in Swift's Data, trimming bytes off the front as they were parsed. After enough trimming, the indices returned by one Data method stopped lining up with what another expected, which crashed on long responses. Switching the buffer to a plain [UInt8] array, whose indices always start at zero, made the problem go away.

3. One process, many widgets

Having all the widgets in one app is the whole point of Barista, but it has a downside: if one widget crashes, the whole app goes down with it. And some crashes can't be caught in Swift. An early example was a text-formatting tool that, given a bare value like 42 instead of a full JSON document, triggered an Objective-C exception that try? doesn't catch.

I can't prevent every crash, but I can stop the same widget from taking the app down again and again. So Barista has a small crash quarantine:

• Right before a widget does something risky (starting up, or building its popover), Barista writes a small note saying "this widget is doing this now", and clears it afterwards.
• When the app quits normally, it records a clean exit.
• On the next launch, if the last exit wasn't clean and a note was still there, Barista knows which widget was busy when things went wrong.

That widget gets switched off before it can run, and a banner in Settings explains what happened, with a button to turn it back on. A popover crash quarantines the widget immediately, since popovers open one at a time and it's clear who was responsible. A crash during start-up needs to happen twice in a row, because many widgets start together, and one unlucky force-quit shouldn't blame an innocent widget.

None of this is visible when things work, which is exactly how it should be. But it means a bug in one widget stays a bug in one widget, instead of an app that won't start.

---

There were plenty of smaller puzzles too (getting text fields to accept typing inside a menu bar popover deserves its own post), but these three are the ones I'll remember.

Ten days ago I shipped Barista. This is a short write-up of what it is, what problem it solves for me, and a few decisions I made along the way.

Small tasks, many times a day

A lot of what I do on my Mac during a day is small: check when the next meeting starts, glance at the weather, convert a unit, paste something I copied an hour ago, see what just landed in my inbox, jot down a note. Each one takes a couple of seconds. But doing it usually means stepping away from what I'm working on: switching to another app, opening yet another window, or hiding everything to get to the widgets on the desktop. And then finding my way back to where I was.

The menu bar is the one place that's always there, above whatever I'm doing. Clicking something there, doing the task in two seconds and carrying on doesn't move a single window or break my train of thought. That's what I wanted for all of those small tasks: click, done, back to work.

One app for all of it

The idea behind Barista is to put those small tasks in the menu bar, in one app. Each widget is one item in the menu bar, and clicking it opens a small popover that behaves like a proper little app rather than a dropdown menu. They all share the same look, spacing and keyboard handling (arrow keys, Return, Esc to close), so once you've used one you know how the others work. Everything is configured from a single settings window.

It started with a handful of widgets and grew to more than 35: calendar, reminders, weather, email, clipboard history, CPU, memory and battery, a calculator, a unit converter, world clocks, a colour picker, and a few small games for when a build is taking its time. A fresh install starts with none of them switched on. You pick the ones you want, so the bar only holds the things you actually reach for.

Calendar

The calendar is the widget I use most. It's something I was used to from GNOME, where clicking the clock in the top bar opens a small calendar with your upcoming events. macOS doesn't have that (clicking the clock opens Notification Center instead), and I missed it.

The menu bar shows the next event and its time. Clicking it opens a month grid with dots for busy days, a "Next up" card, and the agenda for whichever day you select. Meetings with a video link get a Join button. It reads from the calendars already set up on your Mac, so there's nothing new to connect.

Email

The email widget was the most work by far. The menu bar shows the unread count. The popover lists recent messages across all your accounts, and you can read, reply and write new mail without leaving it. It talks to mail servers directly, so it doesn't need Mail.app running. Gmail, iCloud, Yahoo and AOL are set up with a few clicks, and other servers work too if they accept a direct TLS connection (the setup runs a quick test and tells you if yours doesn't). It's not trying to replace a full mail client. It's for glancing at what came in and dealing with the quick ones.

Running out of room

With enough widgets turned on, the menu bar fills up quickly, especially next to the notch. So Barista can fold everything behind a single icon. Clicking it drops down a separate Barista bar that holds all the widgets, with its own space independent of the system menu bar. This is set per display, so a laptop screen can stay tidy while an external monitor shows everything.

A few decisions

• Mac App Store only. Barista runs in Apple's sandbox and uses only public APIs. That ruled out a few things I wanted, such as showing what's playing in any app, a widget for switching Spaces, and a small terminal, because each of them would need private APIs or permissions the sandbox doesn't allow. I'd rather drop a feature than ship something that could break with the next macOS update.
• Nothing leaves your Mac unless a widget needs it. There's no analytics. Clipboard history and the scratchpad are encrypted on disk, and email passwords live in the Keychain.
• Light on resources. All the widgets run in one lightweight process. A menu bar app should never be the reason your fans spin up.

What's next

This is the first version, and there's plenty I want to improve. If you try it and something annoys you, I'd genuinely like to hear about it. There's a support page with ways to reach me, and more about the app on its project page.

In the next post I'll write about a few of the technical problems that took far longer to solve than I expected.

#include <stdio.h>

int main(void) {
    printf("Hello, World!\nThis is the first post on the blog.\n");
    return 0;
}