I hope that you enjoyed Saturday’s Mac Riddles, episode 302. Here are my solutions to them.

1: Shortened characters into the most common extension, formerly ASCII.

2: Medical practitioner at the end of word files until gaining a cross in 2002.

3: At the end of real estate inventory, most commonly for Info and preferences.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Shortened characters into the most common extension, formerly ASCII.

2: Medical practitioner at the end of word files until gaining a cross in 2002.

3: At the end of real estate inventory, most commonly for Info and preferences.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Disk images, files that contain the contents of a physical storage medium, go back long before the first Mac. Among other tasks, they were originally used to contain representations of floppy disks for replication in manufacture.

Today disk images are at the heart of macOS, and widely used by third-parties. They’re an essential part of macOS installers, home to Recovery mode, and the basis for cryptexes. They’ve been used to burn and replicate optical disks, to archive disk contents, extensively for network backups, and for the distribution of software.

Classic Mac OS

In Classic Mac OS there were two utilities that worked with different formats: Disk Copy used replicas later in DC42 format, after Disk Copy version 4.2, while compressed formats known as DART were handled by the Disk Archive/Retrieval Tool, hence their name.

Mac OS 9 brought Disk Copy 6.0 with added support for the New Disk Image Format (NDIF), which supported resource forks, and ended with its last release version 6.3.3. This also supported read-only Rdxx formats.

By this time, variants of formats had become complex. Here, Disk Copy is configured to create a read-only compressed .img file containing the contents of a standard 1.4 MB floppy disk. In the upper window, it has completed validating the checksum on a self-mounting .smi disk image that’s part of a DiskSet. These could also be signed, using certificates issued not by Apple but by DigiSign.

Here’s Disk Copy saving an image of a hard disk using a similar read-only compressed format, this time to accommodate 1.5 GB.

Mac OS X

The release of Mac OS X 10.1 Puma in 2001 brought Apple’s new Universal Disk Image Format (UDIF), used in DMG disk images, which only had a single fork as its resource fork was embedded in the data fork. Although pre-release versions of Disk Copy 6.4 and 6.5 were available with UDIF support for Mac OS 9, neither was ever released, leaving Classic Mac OS without access to UDIF images. Its support for compression options in Apple Data Compression (ADC) unified the two disk image types, and extended support for images larger than a floppy disk. This new format enabled disk images to represent whole storage devices, complete with a partition map and disk-based drivers.

Tools provided in Mac OS X for working with disk images include Disk Utility and the command tool hdiutil.

On 21 January 2002, the first version of DropDMG, a third-party substitute for creating disk images, was released by C-Command Software. This quickly enabled developers to create disk images with artwork, licences and other features that weren’t accessible from the tools bundled in Mac OS X. DropDMG has flourished over the last 23 years, and remains popular today.

DropDMG’s options for creating a new disk image far exceed those in Disk Utility. Particularly helpful are the compatible version hints shown on various options, to remind you of which file systems are available in different macOS versions, and which types of disk image container are supported. DropDMG will even convert old NDIF disk images last used in Mac OS 9 to more modern formats. It will also change the password of an encrypted disk image from a menu command.

In Mac OS X 10.2 (2002), UDIF and most other supported formats were served from a kernel extension without requiring a helper process. The following year, 10.3 Panther started using a faceless utility DiskImageMounter to mount disk images. Apple then dropped support for embedded resource forks in disk images in Mac OS X 10.4.7, and newly created disk images became less compatible with older Mac OS versions.

Sparse bundles

Until Mac OS X 10.5 Leopard in 2007, all disk images had used single-file formats, although some could be segmented across file sets. Leopard introduced the sparse bundle with its folder of smaller band files containing data. These enabled the image to grow and shrink in size, and became popular means of storing mountable Mac file systems on servers using different file systems.

This is another third-party tool that improved access to disk images from the GUI, DMG Packager, seen in 2009. Unlike DropDMG, this appears to have vanished without trace.

In 2011, with the release of Mac OS X 10.7 Lion, Apple removed more support for old disk image formats. DiskImageMounter no longer opened NDIF .img, .smi self-mounting, .dc42 and .dart compressed formats, although the hdiutil command tool still retained some access to them.

Disk Utility, seen here in 2011, has provided basic access to many disk image formats, but these are only a small selection of options available in the hdiutil command tool, or in DropDMG.

This shows the complex set of options available when creating a new disk image in Disk Utility in OS X 10.10 Yosemite, before the advent of APFS.

Support for compression was enhanced in OS X 10.11 El Capitan with the addition of lzfse in a new ULFO format, and macOS 10.15 Catalina added lzma in ULMO. In both cases, these new formats aren’t accessible in older versions of macOS.

APFS support

The arrival of a pre-release version of the new APFS file system in macOS 10.12 Sierra brought its support in disk images, although only for experimental purposes, and Apple cautioned users to ensure their contents were well backed up.

In addition to adding the more efficient ULMO compressed format, macOS 10.15 Catalina is the last to support many Classic Mac OS disk image formats, including those from DiskCopy42, DART and NDIF from Disk Copy 6.x. Support for AppleSingle and MacBinary encodings, and dual-fork file support, were also removed in macOS 11.0 Big Sur in 2020.

This ‘warning’ alert from 2020 illustrates one of the longstanding issues with disk images. Although integrity checking of disk images using checksums has been valuable, when an error is found there’s no possibility of repair or recovery as the image can’t be ‘attached’, so its file system can’t be mounted.

macOS 12 Monterey in 2021 brought multiple deprecations of older formats, including UDBZ using bzip2 compression, segmented UDIF images, and embedded resources. It’s also thought to be the first version of macOS in which UDIF read/write images (UDRW) have been stored in APFS sparse file format, although Apple has nowhere mentioned that. This has transformed what had previously been space-inefficient disk images that retained empty storage into a format that can prove almost as efficient as sparse bundles. This results from the Trim on mounting HFS+ and APFS file systems within the image freeing unused space, enabling that to be saved in the sparse file format.

Disk images have never been glamorous, but have remained at the heart of every Mac.

References

man hdiutil
Introduction
Tools
How read-write disk images have gone sparse
Performance
Bands, Compaction and Space Efficiency

Appendix: Disk image formats

Supported

• UDRW – UDIF read/write
• UDRO – UDIF read-only
• UDCO – UDIF ADC-compressed
• UDZO – UDIF zlib-compressed
• ULFO – UDIF lzfse-compressed (OS X 10.11)
• ULMO – UDIF lzma-compressed (macOS 10.15)
• UDTO – DVD/CD-R master for export
• UDSP – sparse image, grows with content
• UDSB – sparse bundle, grows with content, bundle-backed, Mac OS X 10.5
• UFBI – UDIF entire image with MD5 checksum.

Unsupported

• DC42 – Disk Copy 4.2 (Classic)
• DART – compressed, for Disk Archive/Retrieval Tool (Classic)
• Rdxx – read-only Disk Copy 6.0 formats
• NDIF – Disk Copy 6.0, including IMG and self-mounting SMI
• IDME – ‘Internet enabled’, on downloading post-processed to automatically copy visible contents into a folder, then move the image to the Trash. Now deemed highly insecure.
• UDBZ – UDIF bzip2-compressed image (deprecated).

I hope that you enjoyed Saturday’s Mac Riddles, episode 301. Here are my solutions to them.

1: Roll pasted on the interior background.

2: Secure partition for the idle display.

3: Pastime bull’s-eye for the player.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Roll pasted on the interior background.

2: Secure partition for the idle display.

3: Pastime bull’s-eye for the player.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Given that it was over three years before Apple first shipped a Mac with an internal hard disk, it’s not surprising that one of its early shareware apps was Harry Chesley’s PackIt III for compressing archives of files, in 1986. At that time, the emphasis was more on working out how to archive both forks of Mac files and how to restore them, and less on achieving efficient compression.

The following year, 16 year-old Raymond Lau, then still a high school student, developed and marketed its replacement, Stuffit, which rapidly established itself as the standard, and probably the most popular shareware utility for the Mac. From 1987 until the release of Mac OS X in 2001, Stuffit had few rivals and its .sit archives were widespread across Macs, but didn’t make it to PCs or Windows until much later.

In 1988, Aladdin Systems was formed to take over development and sales of Stuffit, and in 2004 it changed name to Allume Systems, and was bought by IMSI. The following year, Allume was bought by Smith Micro Software, Inc.

Aladdin continued a shareware version as Stuffit Classic, and launched a commercial version as Stuffit Deluxe. This line-up was later augmented with a freeware decompressor Stuffit Expander that was bundled in Mac OS X until 10.4 Tiger.

Less known today are Stuffit’s self-expanding archive apps, with built-in decompressors and the extension .sea, that enabled the few Macs without a copy of Stuffit to open them with a double-click.

Until more powerful Macs of the mid-1990s, compression was performed in software and painfully slow. One of the more popular add-in cards for expandable Macs like the Macintosh II was Sigma Designs’ DoubleUp NuBus card that compressed in real time using Salient Software’s DiskDoubler.

This is Stuffit Deluxe version 8.0.2 from 2003, the year before Aladdin was renamed Allume.

Stuffit Deluxe included support for conversion to and from BinHex encoding, used for sending binary files via email without the risk of data corruption.

DropStuff was a drag-and-drop tool or droplet for compressing files into Stuffit, Zip or Tar archives, with support for encryption, and segmentation for use where file sizes were limited.

Its Zip option also preserved resource forks.

Archives in a range of formats, including RAR, could be managed in Stuffit Archive Manager, which could even schedule automatic creation of archives.

Although Aladdin launched a Mac OS X version with a new archive format, .sitx, and support for additional compression methods beyond its own proprietary formats, Stuffit entered decline by the time it was acquired by Smith Micro. Compression requirements had changed in Mac OS X, with decreasing use of resource forks, and free availability of bundled cross-platform compression tools such as GNU Gzip.

In 2007, BetterZip supported a standard set of compression formats, including 7-Zip, but never really caught on.

This is cross-platform WinZip seen in 2015, five years after its first release for the Mac. This originated as a graphical interface for PKZIP.

Apple started including compression tools in /System/Library/CoreServices, initially with BOMArchiveHelper in Mac OS X 10.3 Jaguar, which became Archive Utility that lives on today, supporting the Compress command in the Finder’s contextual menu. This uses a modified implementation of the Zip method that preserves extended attributes, successor to the resource forks of Classic Mac OS.

For many years, Mac OS X has had access to compression at a system level, but Apple has unaccountably not opened that up to developers. In modern Macs, compression is extensively used both on disk and in memory. However, in macOS Big Sur in 2020 Apple introduced AppleArchive with its system-level support for LZ4, LZMA, zlib and a proprietary implementation of LZFSE, and those are available in a new command tool aa.

Archive Utility offers a few options, and from 2020 has included support for plain and encrypted AppleArchive format.

The arrival of Apple silicon Macs has expanded options available for compression utilities to make better use of their two core types and energy efficiency. Freeware Keka now gives the user the choice.

Legacy copies of Stuffit are still available from here.

I hope that you enjoyed Saturday’s Mac Riddles, episode 300. Here are my solutions to them.

1: The first chips with six-packs celebrated Halloween.

2: First with FireWire and almost see-through in its two-tone case.

3: It brought Exposé, Fast User Switching and Xcode.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: The first chips with six-packs celebrated Halloween.

2: First with FireWire and almost see-through in its two-tone case.

3: It brought Exposé, Fast User Switching and Xcode.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them. To celebrate this anniversary edition, that’s a number which can be expressed in a way that a Roman might read as being one less than it really is.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

With Mac OS X came a new tool for installing and updating the system, quite different from what had been used in Classic Mac OS. The Mac OS X Installer app uses packages (.pkg), and metapackages (.mpkg) containing multiple packages to be installed together. Apple thus provided installations and updates as metapackages that could either be downloaded from its update servers using Software Update, or from the update’s web page. The same method was used until Big Sur, when updates changed again.

A system update in Mac OS X 10.1.3 in March 2002 was installed by the Installer app following authentication.

This update required just 148 MB of disk space, and could readily be accommodated by any of these volumes of 11.5 GB capacity.

Most updates were concluded by a period ‘optimising system performance’, as determined by the post-install scripts in the package.

Here, Software Update is delivering Security Update 2004-05-03 to Mac OS X 10.3.3 Panther. Some system components like QuickTime were still supplied and installed separately, but the great majority of Mac OS X was integrated into a whole, and there were no options to install separate components.

Over this period, the system and user data shared a single boot volume, and updating the system mainly involved replacement of updated files. Installer packages contained those replacements together with scripts that were run to update the contents of the boot volume. For much of this, firmware updates were still supplied and installed separately, although later they were integrated into macOS updates.

Until the introduction of System Integrity Protection (SIP) in El Capitan, the only protection provided to system files and folders was in their permissions. Incomplete or incorrect installations and updates were therefore not uncommon, as despite its name, SIP didn’t have any means of verifying the integrity of system files. A procedure was introduced to verify directory structures and permissions against those listed in the Bill of Materials (BoM) for macOS updates, by repairing permissions, but that was still unable to verify the integrity of the files themselves.

Installer metapackages are highly portable, and were commonly downloaded to be installed on multiple Macs. To keep updates as small as possible, they were provided in two forms: a Delta update converted only the previous release, while a Combo update contained everything required to update the last major version and all intermediate minor versions in a single step.

The High Sierra 10.13 upgrade in September 2017 brought greatest change, with its inclusion of Apple’s new file system APFS. Macs that didn’t have a Fusion Drive had their system volume converted to APFS during the upgrade, although it was another year before the same happened to Fusion Drives.

Updates didn’t always work out right for everyone. This was a common problem with High Sierra Supplemental Update of 29 November 2017, for example.

This all changed with the first version of macOS to boot from a signed snapshot, Big Sur, in November 2020, to support the improved Secure Boot of Apple silicon Macs. This abandoned the use of Installer packages, relying instead on an Update Brain integrated into each installer app and downloaded update.

From then onwards, Apple has provided several different presentations of macOS installers and updates:

• Updates are only delivered through Software Update or its command tool equivalent softwareupdate, and have to be downloaded from Apple’s servers, or delivered through a local Content Caching Server.
• Full macOS installer apps are offered in the App Store then delivered through Software Update.
• Full macOS installer packages are available through softwareupdate or direct from Apple’s servers, and are named InstallAssistant. When installed, these create a full installer app.
• Full macOS installers are offered in Recovery, from where they’re downloaded from Apple’s servers.
• Full IPSW images containing firmware, Recovery and macOS partitions can be installed to restore Apple silicon Macs in DFU mode, using Apple Configurator 2 or later versions of the Finder. Those effectively reset that Mac to factory condition with that version of macOS pre-installed.

There are further complications to this. For instance, an older macOS Installer app can’t be run in a newer major version of macOS. The workaround for that is to create a bootable installer volume, and boot from that to run its older installer.

macOS updates are supplied compressed, and require up to 30 minutes preparation before they can be installed.

There are now no optional installations, as every copy of any given version of macOS is identical within its Signed System Volume (SSV).

The size of these new updates is considerably greater than those of older Installer packages, particularly in Big Sur, as engineering optimisations were being performed.

This chart shows cumulative sizes of updates to macOS on Intel Macs from 10.14 Mojave, with its traditional single boot volume, through to macOS Sonoma 14.6. Each point represents the cumulative sum of all updates to that major version of macOS required to reach that minor version. Thus the point for 14.2 is the total of update sizes for 14.1, 14.1.1, 14.1.2 and 14.2. Sizes used aren’t those reported by Software Update, but those of the download itself, as reported in articles here, indexed on this page. Lines shown are best fits by linear regression.

Update sizes rose markedly from Mojave, with its single boot volume, to Catalina, with its boot volume group, and again to a peak in Big Sur, with the SSV. They fell again as Monterey introduced greater efficiency, and Ventura and Sonoma have been almost identical, and smaller than Mojave.

Apple silicon Macs started with the huge updates of Big Sur, which were even larger than those for Intel models, and benefitted from the improved efficiency of Monterey and Ventura. Unlike Intel Macs, though, Sonoma has seen further reduction in update sizes, although in each update they remain significantly larger than those for Intel models.

macOS Ventura in 2022 experimented with Rapid Security Responses (RSRs), much smaller updates intended to provide urgent security fixes to Safari and some of its supporting components. These take advantage of cryptexes, cryptographically verified disk images stored on the hidden Preboot volume. Updating cryptexes alone is far quicker too, as the SSV is left untouched. Unfortunately, the second RSR resulted in serious problems with Safari so had to be replaced three days later. The last RSR was released on 12 July 2023, and they appear to have been abandoned since.

Upgrading to the first release of the next major version of macOS had required downloading its full installer app from the App Store. Apple broke from this in macOS Ventura in October 2022, when that new macOS was installed as an update instead. Although this reduced its size and installation time required, it caught many users on the hop, as Apple provided no warning of the change. This approach has since become standard with both Sonoma and Sequoia.

Installing and updating the Mac’s operating system has probably changed more over the last 41 years than any other feature.

I hope that you enjoyed Saturday’s Mac Riddles, episode 299. Here are my solutions to them.

1: Lucida or obscura, it rests between lights and action.

2: Robot production line controls other apps including system events.

3: Interconnected with the neighbourhood inside your router.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Lucida or obscura, it rests between lights and action.

2: Robot production line controls other apps including system events.

3: Interconnected with the neighbourhood inside your router.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Installing and updating the Mac’s operating system has probably changed more over the last 41 years than any other feature. Initially in Classic Mac OS there was little more to do than install the System and ‘bless’ that disk to make it bootable. As the System became more complex and grew various extensions this required a more formal installation process, and Mac OS and its components were stored inside the System Folder. In this article, I summarise how this worked towards the end of Classic Mac OS, in version 9.1 in 2001, the same year that Mac OS X 10.0 Cheetah was released.

By this time, Mac OS was distributed on CD-ROM rather than a stack of floppy disks, and it was quite usual to install only selected parts of it. Installation was considerably easier if you had more than one volume available on your Mac’s hard disk, as that allowed you to run from one volume while installing or updating into another. As those were HFS+ volumes, they were fixed-size partitions of the disk, corresponding to containers in APFS.

ROM updates were provided separately, and you had to check Apple’s support site to discover whether your Mac required an update. If it did, then that had to be performed as a separate step before upgrading Mac OS.

Another vital task before installing or upgrading Mac OS was to run the new version of Disk First Aid provided on the CD-ROM to check and repair disks. Minor errors were common, but if left they could bring disaster, leaving one or more volumes completely broken.

Once all mounted volumes had been checked and repaired using Disk First Aid, you opened the Drive Setup utility provided on the installer CD-ROM. Although the Mac OS installer would by default update any disk drivers it could, it was best to do this manually first, then restart the Mac, so those updated drivers could be used during installation.

Classic Mac OS installer apps relied on proprietary compressed archives called tomes containing the software to be installed. A full installation of Mac OS 9.1 consisted of multiple tomes for each of its components including the main system, Internet access, ColorSync, and so on.

Once restarted you then ran the installer, which was largely self-explanatory. If you were updating a volume that already had Mac OS on it, you could opt to perform a clean install by selecting this as one of the install options. There was also a freeware Clean Install Assistant to help move over old System Folder contents easily.

Although recent installers had improved considerably, most normally opted for a ‘custom’ installation by clicking on the Customise button, rather than just accepting that recommended.

That enabled you to browse through the components to be installed, and to ensure that nothing important to you was missed out. If you didn’t get those right first time, you could always run the installer later to add the bits you forgot.

It was also common practice to check what was in the Recommended Installation for each component. There were a great many components in the main Mac OS 9.1 install item, some of which were seldom wanted. You needed to take your time and browse these thoroughly before pressing ahead. Once the installation had completed, you then used the Startup Disk control panel to select the volume containing Mac OS 9.1, and restarted.

Starting up from the newly installed system then opened the Mac OS Setup Assistant to configure the new system. You might then find that some drivers were missing, in this case for a Graphire pad. Many of those could be found and installed from the Internet.

The installer could also be run to install or re-install individual components of Mac OS using its Customize button.

For example, to re-install the OpenGL components from within Mac OS 9.1, you opted for a custom installation mode for the Mac OS 9.1 group, and unchecked all the other components. Because these were listed in a hierarchical series, this was fairly quick provided you were careful not to leave any checked inadvertently.

Some components, such as QuickTime, weren’t readily installed from the Mac OS Installer. If you looked through the folders on the CD-ROM could locate their installer scripts. Sometimes, double-clicking that script would start the installation process. However, particularly with Mac OS 9.1, you would probably see this error message. In that case, you’d have to perform a manual install from its file tome, using the freeware TomeViewer utility.

You dragged and dropped the installation tome file on TomeViewer, and it opened up its contents as a list like this. You could either get it to extract the entire contents of the tome, or you could select one or more files and extract them into a folder before installing them manually into the System Folder of your choice.

Once you had saved the individual components you needed, you dragged and dropped them onto your System Folder. It would automatically put them into the correct folders within – Control Panels, Extensions, etc. However, some might require to be put in sub-folders within those. If you were unsure, you could always copy the layout of a fully functional System Folder.

Installing and maintaining Mac OS 9.1 was a complex process even when you were content to follow the recommended installation, and it could easily occupy you for several hours to get it just right.

I hope that you enjoyed Saturday’s Mac Riddles, episode 298. Here are my solutions to them.

1: Causing to act with a tress of hair stops the thief from using your Mac.

2: Twice 250 validates your account with two pieces of evidence.

3: Complete safety measures set in recovery.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Causing to act with a tress of hair stops the thief from using your Mac.

2: Twice 250 validates your account with two pieces of evidence.

3: Complete safety measures set in recovery.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Early versions of classic Mac OS didn’t offer a lot of choice in terms of settings, and those that did were often implemented in their own tools as printers and networking were in the Chooser. Separate Control Panels came of age with System 7 in 1991, where they became applets accessible from Apple Menu Options. Originally, most were implemented as cdev code resources, but by the time of Mac OS 9 many had become full-blown apps.

Mac OS 9: Control Panels

The Energy Saver control panel offered three separate settings for sleep, each with its own slider: for putting your whole Mac to sleep, including its CPU, and optional separate controls for the display and hard disk(s).

In those days, virtual memory was controlled by the user in the Memory control panel, and RAM disks were popular among those Macs with ample physical memory.

Internet access and app settings were largely configured in a dedicated control panel, among the more complex in classic Mac OS. Details entered here, particularly for incoming and outgoing mail, applied to all compliant apps.

Mac OS X 10.0: System Prefs

By the end of classic Mac OS, there were 32 control panels, from the original Apple Menu Options to Web Sharing. Reproviding similar support in the first version of Mac OS X came in System Prefs, before its name was expanded to System Preferences a little later. These stepped away from being apps, and became the modernised equivalent of cdevs, using the NSPreferencePane API from Mac OS X 10.1 in 2001, and are assembled into bundles. Those have survived to the present, through System Preferences to the current System Settings.

Unlike control panels, System Prefs constrained all its panes to a fixed size, leading to deep and labyrinthine interfaces.

The QuickTime preference pane from 2002 illustrates how complicated these became.

In 2001, the Network pane was still used to configure AppleTalk, as supported by Apple’s own printers, the last of which had been discontinued in 1999. This also shows how individual panes had to cross-reference others, making navigation messy.

Individual views often contained remarkably few settings, here just five popup menus.

Mac OS X: System Preferences

At some time after 2002, System Prefs was expanded in name to System Preferences in a redesign, although its panes remained fixed in size.

QuickTime’s pane changed remarkably little in Mac OS X 10.3 Panther (2003).

In Mac OS X 10.4 Tiger (2005), the customisable favourites bar at the top was replaced by a navigation bar with search. Accessibility had been introduced as Universal Access, and in Mac OS X 10.8 Mountain Lion of 2012 it was revamped under its current name. The following screenshots show examples from around OS X 10.11 El Capitan in 2015.

The most visually impressive of all these panes was that for the Trackpad, containing embedded video clips demonstrating each gesture. These came at a cost, though: the pane was almost 100 MB in size as a result.

Bucking the trend to increasingly complex detail, Energy Saver in El Capitan was stripped down from its three separate sliders of Mac OS 9.

At its peak in macOS 12 Monterey in 2021-22, System Preferences provided around 30 panes arranged in what was intended to be logical order. Only after extensive use did many know where each was located. As some like Touch ID were model-specific, even experienced users sometimes took several seconds to locate the pane they wanted. Some, like Security & Privacy, had long outgrown the limitations imposed by their tiny windows.

macOS 13: System Settings

Apple’s radical redesign in macOS 13 Ventura of 2022 shocked many. Although it finally brought resizing to the System Settings window, that was confined to the vertical direction, resulting in many panes becoming long lists arranged in no obvious order. Given that almost all displays are wider than they are tall, that appeared an odd decision. Moreover, although it’s thought that SwiftUI was used to implement System Settings, little use has been made of its rich and extensible controls.

This is System Settings’ entry view in macOS Sequoia of 2025. Although its search feature has been improved, locating the appropriate section without using that remains a challenge for most.

Extensive use is made of floating modal windows, which in some settings can be nested so deep that reversing out of them is disorientating.

The greatest sin of all was that the wonderful video clips used previously in the Trackpad item had been dropped completely, and replaced by unhelpful static designs. After mass protests, Apple recanted and added animations, as shown above, but they were a pale shadow of System Preferences.

For all its shortcomings, and the limitations of fixed window size, System Preferences is one feature that many would like to see reinstated. Maybe the next redesign will be better conceived and received.

I hope that you enjoyed Saturday’s Mac Riddles, episode 297. Here are my solutions to them.

1: Can still spin a disc with five between two five-hundreds.

2: Joins overhead and face together in shared video.

3: Railway inspector for the hound of Hades.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Can still spin a disc with five between two five-hundreds.

2: Joins overhead and face together in shared video.

3: Railway inspector for the hound of Hades.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Passwords and other secrets were little-used until the arrival of email and the Internet. Secure storage for them in keychains was developed for the PowerTalk mail engine in Apple Open Collaboration Environment (AOCE), and was first released in about September 1993, probably in System 7.1.1. When AOCE was dropped from Mac OS 8, keychains languished until their revival later that decade, and were probably first supported by the System in around 1999 in Mac OS 8.6.

Those early keychains were the ancestors of what’s now referred to as file-based keychains, in contrast to the data protection keychain that can be shared in iCloud. Although macOS Sequoia still supports classic keychains, their use was discontinued with the introduction of Mac OS X in 2001, when they were replaced with newer keychains supported by the SecKeychain API.

SecKeychains gained full support in Mac OS X 10.2 Jaguar in 2002, and ever since have provided the central login keychain still used in Sequoia over 20 years later. These are encrypted databases containing login credentials and other secrets. Each keychain can be unlocked using a single password, with that of the login keychain being the same as the user’s login password, enabling it to be unlocked following login.

With the introduction of iPhones and their iOS operating system, they didn’t use SecKeychains, but a new and more secure relative known as the Data Protection keychain, with a separate SecItem API. Although support for that was added in Mac OS X 10.6 Snow Leopard in 2009, it wasn’t until OS X 10.9 Mavericks in 2013 that Macs started using Data Protection keychains for their iCloud Keychain. Two years later, with OS X 10.11 El Capitan, SecKeychains and their ancestors were formally deprecated, although much of their APIs still remain.

Throughout Mac OS X and into macOS, the bundled tool for maintaining keychains has been Keychain Access provided in /Applications/Utilities. With the arrival of the iCloud Keychain, Safari provided access to passwords stored in the iCloud Keychain, and that was later augmented in a Passwords item in System Preferences and Settings.

Earlier versions of Keychain Access, such as that seen here in Mac OS X 10.4 Tiger in 2005, provided a valuable First Aid tool to verify and repair keychains. That was dropped some years ago.

After the introduction of iCloud Keychain, the login keychain has steadily lost importance. Here it’s seen at its zenith in Mac OS X 10.6 Snow Leopard.

This shows the login keychain again, in Keychain Access from OS X 10.10 Yosemite in 2014.

macOS Sequoia brought a dedicated app Passwords that only works with the Data Protection keychain, and relegated Keychain Access to /System/Library/CoreServices/Applications, where it can still be used to work with traditional file-based keychains as well.

login keychain

For each user, their default personal file-based SecKeychain is the login keychain, located in ~/Library/Keychains/login.keychain-db. This is unlocked automatically when the user logs in as it has the same password as that user account. It’s here that each user can still store certificates, secure notes, etc. for general use on that Mac.

Although kept unlocked, readable and writeable while the user is logged in, that doesn’t guarantee access to its contents. If an app makes a call to the macOS security system to retrieve a stored password for its use, that system determines whether the app is trusted to access that information, and whether that keychain is locked. Assuming the password is stored there, the app is trusted, and the keychain is unlocked, then the password is retrieved and passed back to the app. If the app isn’t trusted or the keychain is locked, then the security system, not the app, displays a distinctive standard dialog asking for the password to that keychain to authenticate before it will provide the password to the app.

Access to secrets is determined by the security system, the specific access it grants to an app, and to individual items in that user’s keychain. At its most restrictive, the system can limit all other apps from accessing a particular secret in the keychain, but specific secrets can also be shared across several different apps.

System keychains

For the system, there two two vital groups of keychains:

• in /System/Library/Keychains, in the SSV, are SystemRootCertificates and others providing the set of root security certificates for that version of macOS;
• in /Library/Keychains is the System keychain and others providing certificates and passwords required for all users, including those to gain access to that Mac’s Wi-Fi connections.

Data Protection keychain

Since OS X 10.9, Macs have also had one and only one Data Protection keychain that’s accessed using the SecItem API. If you share your keychain in iCloud, this is the local copy of that shared keychain and is known as iCloud Keychain; if you don’t share it in iCloud, then it’s known as Local Items instead. The local copy of this is normally stored in ~/Library/Keychains/[UUID]/keychain-2.db, where the UUID is that assigned to that Mac.

This Data Protection keychain stores all the standard types of secret, including internet and other passwords, certificates, keys and passkeys. Prior to macOS 11, it only synchronised internet passwords using iCloud, but from Big Sur onwards it synchronises all its content, including passkeys, which have now become first class citizens. Unlike file-based keychains, secrets in the Data Protection keychain can be protected by the Secure Enclave in T2 and Apple silicon Macs, and can therefore be protected by biometrics including Touch ID, and Face ID on iOS and iPadOS. Hence they’re required for passkeys, which can’t be supported by traditional file-based keychains.

Future

Much as Apple wants to support only the Data Protection keychain in macOS, there are still many that rely on the login and other file-based keychains. SecKeychain will thus remain supported reluctantly until macOS can finally call it a day on keychains that originated well over 25 years ago.

References

Apple TN3137: On Mac keychain APIs and implementations
Apple Keychain Services

I hope that you enjoyed Saturday’s Mac Riddles, episode 296. Here are my solutions to them.

1: No amateur volume has gone from Yonah to M4 Max.

2: Prophetic revelation is in favour of spatial computing.

3: The first desktop with Apple silicon took six months to release.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: No amateur volume has gone from Yonah to M4 Max.

2: Prophetic revelation is in favour of spatial computing.

3: The first desktop with Apple silicon took six months to release.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

If the Mac is to be the computer for the rest of us, it also needs to give access to more advanced controls by scripting its actions. This article traces some of the more significant attempts to bring scripting to the rest of us.

Over the last forty years there have been dozens of programming and scripting languages that have been developed for, or ported to, Mac OS. The great majority have had no pretensions of use by regular users. The first intended to be used by anyone and everyone was HyperTalk, released three years after the original Mac.

HyperTalk (1987)

Apple’s hypertext authoring environment HyperCard contained its own scripting language HyperTalk. For many of those who built brilliant HyperCard stacks, this new scripting language was the first programming language they had used. Sadly, although seriously cool in its day, HyperTalk was both limited and limiting, as most came to discover.

If you’ve written AppleScript, HyperTalk has a distinct familiarity in its informal language, often mistakenly claimed to resemble normal English. This code snippet illustrates that:
on mouseUp
put the value of card field "age" into theAge
end mouseUp

HyperTalk spawned many imitators, and some like SuperCard went on to outlive it, but by 2000 HyperCard and HyperTalk were all but dead.

UserTalk (1988-92)

In 1988, Dave Winer started developing a scripting language that became UserTalk in Frontier, released in 1992. Built around an object database, Winer took his early work to Apple. In 1988-89, Jean-Louis Gassee, then president of Apple Products Division, announced the formation of a HyperTalk Standards Committee to develop a scripting language, and Apple agreed with Winer that they would each develop their own mutually compatible scripting systems.

After Apple’s release of AppleScript, Frontier’s UserTalk declined in popularity. By 1994, Winer was burnt out, and the following year Frontier moved on to become a cross-platform Web content management system.

AppleScript (1988-93)

In some respects a successor to HyperTalk, AppleScript was released in October 1993, with System 7 Pro version 7.1.1. Despite all the odds, and several determined attempts to strangle it, it’s still supported in macOS Sequoia.

The concept behind AppleScript is simple: scripts that compile to a series of instructions for dispatch by macOS to their destination application, which in turn is controlled by those commands to perform a co-ordinated sequence of functions. At their simplest, these can open a document and print it, for instance. At their most complex, they can automate intricate and repetitive tasks that are messy in a GUI.

As a minimum, every application supports a core of commands to play clean with the Finder and macOS. Those, and the suites of additional commands that bring joy to the scripter, are documented in standard formats within each application’s dictionary, which can be browsed by the bundled Script Editor and other tools. Rather than having to locate additional documentation sets specific to each application, all a scripter should need to do is open the dictionary.

Complexity comes because AppleScript is in fact an object-oriented language as sophisticated as Objective-C; don’t be deceived by its apparently relaxed and informal style, with examples such as
tell application "System Events"
set mailIsRunning to application process "Mail" exists
end tell
if mailIsRunning then
-- do one thing
else
-- do another thing
end if

You might use that code to set up a script that interacts with the Mail app. It first asks macOS whether it knows that Mail is running, and depending on the answer it executes the code that you insert where the comments (prefaced by ‘--‘ characters) are placed. Unlike the majority of programming languages, punctuation marks are used sparsely in AppleScript, making it considerably easier to write code that works, rather than tripping over a missing semicolon.

When ready to test your script, it compiles into intermediate code, and the editor automatically checks, formats and colours your source code, reporting any errors that it finds. When run, the intermediate code works through macOS to fire off AppleEvents (AEvents) to trigger the target applications to perform the actions.

For the more serious AppleScript coder bundled support was too limited, and it was the arrival of Mark Alldritt’s Script Debugger in late 1994 that unleashed its full power. Sadly, Script Debugger is retiring this year after over 30 years of innovative development.

Although AppleScript was integrated into Apple’s Xcode as AppleScript Studio, in recent years it has been left to languish, with occasional rumours of its demise.

Prograph (1982-89)

In 1989, the visual programming language Prograph was launched on the Mac. Sometimes described as a dataflow language, and thoroughly object-oriented, it won awards, was ported to Windows in the late 1990s, but was last seen running as Marten.

In this example method, data flows from the top to the bottom. Normally terminals on the top ‘shelf’ of the method diagram represent the inputs to that method. Data then flows from the top shelf through the intermediate processes, until it reaches the bottom. If there are outputs from the method, they are gathered by connections made to terminals on the bottom ‘shelf’ in the method. Order of execution is not prescribed, and can take place whenever data is available; this allows for inherent concurrency, and the potential to exploit multiprocessor systems without the need for language primitives.

Shell scripts (2001)

With the advent of Mac OS X 10.0 Cheetah came Terminal and shell scripts, inherited from NeXTSTEP. Although powerful and popular with those who prefer this Unix-based approach, they have predictably had limited impact on the regular user wanting to script actions on their Mac.

Automator (2002-05)

Even ‘natural’ programming languages like AppleScript have to be learned, a task that many find too verbal and mechanical. Recognising this, Apple introduced Automator in OS X 10.4 in 2005 to produce custom workflows and apps using more intuitive visual tools.

Although often assumed to be a development of AppleScript, apart from its ability to run AppleScript objects, Automator is very different. Instead of relying on AppleEvents and dictionaries, Automator’s modular actions are separate code objects installed in the Automator folder in a Library folder. macOS comes with a huge free library of actions that can accomplish tasks you might pay good money for, so familiarity can save cost.

Automator is highly extensible, as its actions can include both AppleScript code and Terminal shell scripts. Thus if you cannot find a standard action to do what you want, if it can be expressed in a suitable script, you can build that into your workflow. Nevertheless, in 2021 Apple announced that Automator was to be succeeded by Shortcuts.

Swift Playgrounds (2014-16)

From the early days of the Mac, Apple has invested in programming languages designed to make best use of its APIs. In Classic times, that was Object Pascal, and its open-source class library MacApp. In 2014, Apple released a new language intended to be the preferred choice across all its platforms, Swift. From those early days, Swift has had an interactive mode, based on the read-eval-print loop (REPL) popularised by Lisp. This versatility has been developed in Swift Playgrounds, recently renamed in the singular, both within Xcode and as a standalone app targeted at those learning to code for the first time.

As an introduction to Swift in education, this has been impressive, but it hasn’t yet proved a gateway for those who didn’t really want to learn how to use Xcode in the first place.

Shortcuts (2014-21)

Shortcuts started out in the winter of 2014-15 as Workflow by DeskConnect. Apple bought it in 2017, and it became Shortcuts the following year, when it was integrated into Siri in iOS 12. Its arrival in macOS 12 was announced at WWDC in 2021, as Automator’s intended successor.

While Shortcuts on macOS can run AppleScript and shell scripts, the mechanisms involved in Shortcuts’ actions are completely different from AppleScript and Automator. For an app to support all three well requires it to present four different interfaces: one for the user in the GUI, AppleEvents for AppleScript, Automator actions, and now Shortcuts actions.

While Shortcuts has attracted quite a following, particularly in iOS and iPadOS where it’s the first real scripting environment, its impact in macOS has so far been limited. Like all its predecessors, it still hasn’t brought scripting to the rest of us.

Credits

HyperTalk: Dan Winkler
UserTalk: Dave Winer and Doug Baron
AppleScript: William R Cook and many others
Script Debugger: Mark Alldritt and Shane Stanley
Prograph: Tomasz Pietrzykowski, Jim Laskey and others
Automator: Sal Soghoian and other Apple engineers
Swift Playgrounds: Chris Lattner, Doug Gregor, John McCall, Ted Kremenek, Joe Groff and others
Shortcuts: Ari Weinstein, Conrad Kramer and Nick Frey

Selected references

HyperCard Pantechnicon, in the Internet Archive
Dave Winer’s Story of Frontier and AppleScript
Apple’s AppleScript Overview, last revised 31 October 2007
Apple’s Mac Automation Scripting Guide from 7 June 2018
Script Debugger history from Mark Alldritt
Wikipedia on Prograph
Automator and other automation
Apple’s Swift Playground page
Apple’s Shortcuts User Guide for macOS

I hope that you enjoyed Saturday’s Mac Riddles, episode 295. Here are my solutions to them.

1: Visible vapour after I sync with remote storage.

2: From SoundJam it brought everything from lectures to tracks until broken up in 2019.

3: √-1 spider’s threads brought single-click sites until 1 came along.

The common factor

I look forward to your putting alternative cases.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Visible vapour after I sync with remote storage.

2: From SoundJam it brought everything from lectures to tracks until broken up in 2019.

3: √-1 spider’s threads brought single-click sites until 1 came along.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

In the elegant simplicity of Classic Mac OS, applications were intended to be single files with much of their contents stored in their resource fork, where they kept all the paraphernalia they required, from code resources to windows, icons and dialogs.

This is QuarkXPress version 4.11 from around 2000, its resources displayed in the resource editor ResEdit. The app icons shown are stored in a resource of type BNDL, a ‘bundle’, but not in the later sense of the term.

In this respect, as in many others, Mac OS X abandoned its Mac past in favour of what had been developed in NeXTSTEP, here a structured directory termed a bundle. These were primarily used for constructs that the user was intended to see as a single item, usually containing executable code and its resources, forming applications, frameworks and plug-ins.

Early bundles

At first, there were two types of bundle in use. Versioned bundles consisted of a file containing executable code, together with a directory containing resources and more directories with further resources, without any Contents directory or top-level property list. New-style bundles contained a minimum of a top-level directory named Contents, and inside that a property list named Info.plist, as continues today. Some implementations of the new-style bundle also contained a file named PkgInfo containing type and creator information that had originated in Classic Mac OS; although apparently not mandatory, PkgInfo has survived to the present in app bundles.

The information property list Info.plist contained key-value pairs in XML format, for attributes such as:

• bundle name,
• name of bundle executable,
• version,
• type and creator codes, inherited from Classic Mac OS and duplicating those in PkgInfo,
• app and document icons,
• other metadata.

Current bundles are direct descendants of those new-style bundles.

Fat apps with support for both Classic Mac OS and Mac OS X had a more complex structure. Inside their Contents directory, they had the following:

• MacOSClassic directory, containing the Classic version of their executable code,
• MacOS directory, containing the Mac OS X version of their executable code,
• Info.plist file,
• Resources directory, containing resources such as icons, images, and directories of localised resources such as nibs and strings,
• Other directories such as Frameworks, PlugIns, SharedFrameworks and SharedSupport as necessary.

To enable that to run in Mac OS 9, alongside the Contents directory was an alias to the executable code in Contents/MacOSClassic.

The Finder recognised a directory as a bundle and treated it as a single entity if:

• the directory name had an extension for a standard bundle type, such as .app, .bundle, .framework, .plugin, .kext and others, or
• the directory name had an extension identifying it as a type set as a bundle (or package), such as .rtfd, or
• the directory had its Finder bundle bit set.

Frameworks are an exception to the general rule that the Finder displays bundles as single items, as they are still shown as folders. However, the original reason given by Apple for this, “so that you can browse their header files”, no longer applies.

Packages

By 2005, Apple was drawing a distinction between bundles with the formal structure given above, including the Info.plist inside a Contents directory, and other directories presented to the user as a single item, such as RTFD documents, that had different structures and are strictly termed packages. For example, the Rich Text Format Directory (RTFD) favoured by Apple consists of:

• Contents, a directory containing a PkgInfo file
• files containing graphics to be included within the documents
• TXT.rtf, a Rich Text Format file containing the styled text.

This is closer to the versioned bundles of early Mac OS X. Currently, there are distinct UTI types for com.apple.bundle and com.apple.package, with bundles conforming to both, but packages only to the latter. Unfortunately, this distinction between bundles and packages has largely fallen into disuse because of the name collision with Installer packages.

More recently, in its iWork documents, Apple has moved away from plain document packages or bundles to a custom package in a Zip-compressed archive, for example in .pages documents, which still conform to com.apple.package although they can’t be opened in the Finder. Compression has also become popular with space-inefficient formats such as XML.

Signatures

The introduction of code signing in 2007 brought the requirement to store signature information including code directory hashes (CDHashes) inside the app bundle. This has been implemented using an additional directory, _CodeSignature, containing a CodeResources file. Single-file command tools can instead have their signature embedded in their binary.

Most recently, in 2018, notarization has added the requirement to accommodate its ‘ticket’, which is ‘stapled’ as another CodeResources file inside the Contents directory. However, stapling isn’t required, as notarization can be verified by looking up the CDHashes with Apple’s online service in iCloud. There’s also still no way to staple a notarization ticket to a single-file binary.

Platform-specific code

The transition from Classic Mac OS to Mac OS X used separate directories for executable code within app bundles, with that named MacOS containing code to be run in Mac OS X. When the Mac architecture changed from PowerPC to Intel, from 32-bit to 64-bit, and again from Intel to Arm, app bundles have continued to use the MacOS directory, with executable code for each supported architecture being saved within each file.

Key dates

• 1984 single-file application with resource fork, type and creator codes
• 2001 Mac OS X 10.0 Cheetah, with versioned and new-style bundles, PkgInfo for type and creator codes, Info.plist in new-style bundles
• 2005 bundles and packages
• 2007 Mac OS X 10.5 Leopard, _CodeSignature directory for code signatures
• 2018 macOS 10.14 Mojave, CodeResources for notarization ticket.

References

Apple’s Bundle Programming Guide, last updated to 2017
Apple, Inside Mac OS X, System Overview, July 2002, PDF no longer available online.

I hope that you enjoyed Saturday’s Mac Riddles, episode 294. Here are my solutions to them.

1: Cool colour with a liking for sugar for connecting keyboards and mice.

2: Although never inside a Mac, its laser can burn over 25 GB.

3: Hue of the first in 1998 that became five the following year, and is now seven.

The common factor

I look forward to your putting alternative cases.

Yesterday’s brief history of ColorSync was one of the most interesting in this series to research. In most cases, these brief histories cover well-trodden ground, with several previous accounts to provide a framework for my collection of screenshots and personal experience. On this occasion, even Wikipedia was vague and brief. Yet at the time ColorSync’s role was of great importance, as faithful colour reproduction was so essential to the creatives and businesses that relied on Macs.

It’s also a richly multi-disciplinary field, drawing on neurophysiology, physics, colour science and perceptual psychology. Key concepts like the modelling of colour appearance have grown into lengthy and highly technical books, several of which I seem to have collected over the years. They also provide absorbing accounts of the lengthy journey over several centuries to bring basics such as colour order systems.

In 1615, the Flemish physicist Franciscus Aguilonius, also known as François d’Aguilon, (1567-1617) was the first to propose a colour line extending from white (albus) to black (niger), passing through the primaries of yellow (flavus), red (rubeus), and blue (caeruleus). Below that are secondary combinations of orange (aureus) and purple (purpureus), with green (viridis). This was published in his six volume treatise on optics, whose title page and illustrations were designed by Peter Paul Rubens.

In the early twentieth century, Albert Henry Munsell (1858-1918) devised a system closer to those used to specify colour today. This shows the circle of ten hues, here displayed with values of 5 and chromas of 6. The vertical value scale ranging from 0 to 10 is shown in neutral colours, from black to white. A wedge of constant 5PB hue is then shown at a fixed value of 5, the chromas ranging from 0 (grey) to 12 (pure colour).

Contemporary designers are also familiar with the Pantone System of swatches of standardised colours, that have become standards in several sectors such as process colour printing.

The problem tackled by ColorSync is that no device used with computers can represent the full range of colours, each having its own range or gamut. For colour to appear consistent in the image captured by a scanner or camera, on the display used to adjust settings such as white point and balance, and in the final printed page, colours have to be adjusted or mapped to look right on that device. To do that each device has its own colour profile, and a colour management system adjusts colours on each according to the desired quality and goals of the operator.

Most of the principles involved were known before the arrival of Macs. But when Apple, Adobe, Agfa, Microsoft, Kodak, Silicon Graphics, Sun and Taligent (an Apple-IBM partnership) sat down together in 1993 as the International Colour Consortium, they had a lot of work to do before photographers and designers could have confidence that their work would survive the journey into print retaining what appeared to be faithful colour.

ColorSync and colour management is but one example of the broad range of fields that form the basis of what we do on our Macs, from floating point computation to Unicode text. With the marketing drive to sell modern computers as appliances, we have lost sight of what goes into them. Just as with transport history, our view of what happened is largely superficial and limited to the tangible in collections of hardware.

This misleads us into thinking that today’s Artificial Intelligence is somehow capable of replacing human research and discovery when all it can really do is rehash what we have created in the past. If any of today’s much-vaunted large language models could have started to tackle the problems addressed by ColorSync during the 1990s, do you seriously think that they would have come up with the solutions embedded in Mac OS X less than a decade later? For without prior knowledge won by humans, we’d still be wrestling with the number of rs in the word strawberry.

Let’s celebrate human achievement and empower that instead.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Cool colour with a liking for sugar for connecting keyboards and mice.

2: Although never inside a Mac, its laser can burn over 25 GB.

3: Hue of the first in 1998 that became five the following year, and is now seven.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Each colour output device, such as a printer, has a limited range of colours that it can reproduce, its gamut. To ensure that output best matches expectations, it’s necessary to adjust colours to a device colour profile using a colour management system. When Apple released the Macintosh II in 1987, colour management was in its infancy. With the development of colour output devices like inkjet printers, Xerox, Apple and other manufacturers realised its importance. Apple therefore recruited Robin D. Myers and together with Gary Starkweather they started work on what was to become the first version of ColorSync, released in January 1993.

That year Apple, Adobe, Microsoft, Kodak and others co-founded the International Color Consortium (ICC) to develop ColorSync into an open cross-platform colour management system, and worked on improvements to version 1.0. Although ColorSync was being integrated more with the Mac System, its use remained optional until the release of Mac OS X, and until then plenty of software simply ignored it.

ColorSync 1.2 brought support for Apple’s new PowerPC-based Macs, then in March 1995 ColorSync 2.0 brought major improvements, and was followed by 2.5, probably released with System 7.6.1 in 1997.

ColorSync is seen here in the later days of Classic Mac OS in 2001, managing colour profiles for devices, and providing colour management workflows.

ColorSync 2.0 used a new format for device profiles that had been developed by the ICC for use over a wide range of platforms and devices, although it retained backward compatibility with version 1.0 profiles. In addition to supporting input devices (scanners, cameras), displays, and output devices (printers), these new profiles also supported device links for batch processing, colour space conversions, and abstract devices for subjective transformations. Embedded profiles contained additional information indicating desired quality and rendering intent for colour matching. Printing to a ColorSync-aware printer driver became transparent for apps, allowing them to get the most from the built-in colour management in Mac OS.

With the release of Mac OS X 10.0 Cheetah in 2001, ColorSync came of age and was fully integrated at last, and had won its place in System Prefs. Version 4.0 was soon released in Mac OS X 10.1 Puma that September.

ColorSync Utility provided a rich range of tools for managing device profiles, and repairing any that had become damaged.

The following sequence of screenshots shows the calibration of an Apple Studio Display using Display Calibrator in Mac OS X 10.2 Jaguar in 2003.

ColorSync Utility’s features continued to grow, with the addition of a colour calculator in Mac OS X 10.4 Tiger, and improved visualisation of profiles, seen here in Mac OS X 10.5 Leopard in May 2009.

Colour profiles for printers were often specific not just to the printer, but also to the type of paper used, as with these in Mac OS X 10.7 Lion in 2011.

Since then, the demand for quality colour printing has steadily declined, and by macOS Monterey in 2021, ColorSync Utility was growing neglected, and its Calculator was and remains dysfunctional. The Display Calibrator app is now buried deep in /System/Library/ColorSync/Calibrators. A new colour calibration tool, Pro Display Calibrator, is tucked away in /System/Library/CoreServices to support Apple’s Pro Display XDR, but little has been done to develop the capabilities of the Studio Display since its introduction in 2022.

ColorSync version 4.13.0 carries on managing colour in macOS Sequoia 15, an unsung triumph of science and engineering.

References

Robin D. Myers’ early history
David Hayward Print Hints: Syncing Up With ColorSync 2.0, develop issue 23, September 1995
Apple, ColorSync on Mac OS X, Technical Note TN2035, 8 October 2005
Alas ColorSync Utility!

I hope that you enjoyed Saturday’s Mac Riddles, episode 293. Here are my solutions to them.

1: 42, 3.14159, 0x2A, but not x.

2: Forty has formulas to be pre-eminent against Apple’s digits.

3: One of six in a cider press that died in 2007.

The common factor

I look forward to your putting alternative cases.