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.

One of the magic tricks that characterised the Mac was its association between documents and their apps. No longer did a user have to type in both the name of the app and the document they wanted it to edit. All they needed to do was double-click the document, and it magically opened in the right app.

In Classic Mac OS, that was accomplished by hidden Desktop databases and type and creator codes. For example, a text document might have the type TEXT and a creator code of ttxt. When you double-clicked on that, the Finder looked up which app had the creator code ttxt, which turned out to be the SimpleText editor, and opened that document using that app.

Although those ancient type and creator codes still live on today in modern macOS, they no longer fulfil that role. Instead, each file has what used to be a Uniform Type Indicator (UTI), now wrapped into a UTType, such as public.plain-text, normally determined by the extension to its name, .txt or .text. When you double-click on a file, LaunchServices looks up that UTType in its registry, discovers which app is set as the default to open documents of that type, then launches that app with an AppleEvent to open the document you picked.

Recognising that we often want to open a document using a different app rather than the default, the Finder’s contextual menu offers a list of suitable apps in its Open With command. That list is built and maintained by LaunchServices, and has changed in recent versions of macOS. Whereas those lists used to consist of apps installed in the traditional Application folders, LaunchServices now scours every accessible volume and folder using Spotlight’s indexes to build the biggest lists possible. If you happen to have an old copy of an app tucked away in a dusty corner, LaunchServices will find it and proudly display it alongside those in everyday use, like a game dog triumphantly presenting not one dead pheasant but every one from miles around.

For those with lean systems, this gives them the flexibility to open a large text document using BBEdit rather than TextEdit, or to select which image editor to use for a JPEG. But for those of us with lots of apps lurking in storage, the result is absurd and almost unusable. It’s bad enough working through the 33 apps that LaunchServices lists as PNG editors, but being offered 70 text editors is beyond a joke.

Unfortunately, there’s no lasting way to block unwanted apps from being added to the list LaunchServices builds for this Open With feature. You can gain temporary relief by excluding them from Spotlight search, but should you ever open the folder they’re in using the Finder, those are all added back. This also afflicts apps in folders shared with a Virtual Machine, where the list includes App Store apps that can’t even be run from within that VM.

There are, of course, alternatives. I could drag and drop the document from its Finder window towards the top of my 27-inch display to the app’s icon in the Dock at the foot, which is marginally less awkward than negotiating my way through that list of 70 apps.

But there are better solutions: why not empower me to determine which of those 70 apps should be offered in the Open With list? This is such a radical idea that it used to be possible with the lsregister command that has become progressively impotent, as LaunchServices has cast its net further in quest of more apps to flood me with. Or maybe use a little machine learning to include only those text editors I use most frequently to open documents? Apple could even brand that LaunchServices Intelligence, although that’s a little overstated.

I can’t help but think of what those magicians from forty years ago would have done, but I’m certain they wouldn’t have offered me that list of 70 apps to choose from.

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.

In the last couple of weeks I’ve been asked to help recover data lost when files have been accidentally deleted, and an internal SSD has been wiped remotely using Find My Mac. What we perhaps haven’t fully appreciated is how improved security protection in our Macs has made it far harder, if not impossible, to recover such lost data. Allow me to explain in three scenarios.

Lost files on a hard disk

When files are deleted from a hard disk, the file system marks them as no longer being in use, and they’re left in place on the hard disk until they need to be overwritten with fresh data. If the hard disk has ample free space, that could occur days, weeks or even months later. Data recovery software and services can be used to scan each storage block and try to reconstruct the original files. If the file system and its data are encrypted, the encryption key is required to enable the contents to be decrypted.

There’s extensive experience in such data recovery, and provided the disk isn’t physically damaged or malfunctioning, results can be surprisingly good. As services charge according to the amount of data they recover, there are also strong incentives.

This works both ways, of course, in that someone who gets access to that hard disk could also recover files from it if they’re unencrypted. For this reason, when you’re passing on or disposing of a hard disk, you should perform a secure erase to overwrite its entire contents. If it’s going for recycling, once that has been done, you should also render the disk unusable by physically damaging its platters.

Deleted files on an SSD

What happens on an SSD depends on whether there’s already a snapshot of that volume. If there is, and that snapshot includes the deleted files, the file system metadata for them is retained in that snapshot, and the storage containing their data is also retained. The files can then be recovered by mounting that snapshot and either reverting the whole volume to that earlier state, or copying those files to a different volume.

If there’s no prior snapshot containing the files, the file system marks their extents as being free for reuse. At some time after their deletion, that information is sent to the SSD in a Trim command. When the SSD next has a moment to perform its routine housekeeping, the physical storage used will then be erased ready to be written to again.

Although there’s some uncertainty as to when that Trim command will be sent to the SSD, one time that we know that supported SSDs are Trimmed is during mounting, in the case of an internal SSD when that Mac starts up. So if your Mac has started up since the files were deleted, those files are most likely to have been completely erased from its internal SSD. With their erasure, chances of ever recovering those files have gone.

Wiped Data volume

Macs with T2 or Apple silicon chips have an ingenious method of ‘wiping’ the entire contents of the Data volume when it’s encrypted on the internal SSD. This can be triggered using the Erase All Content and Settings (EACAS) feature in the Transfer or Reset item in General settings, or remotely via Find My Mac. Either way, this destroys the ‘effaceable key’ and the ability to decrypt the contents of the Data volume, even if it’s not additionally protected by FileVault. As Apple states: “Erasing the key in this manner renders all files cryptographically inaccessible.”

This is to ensure that if your Mac is stolen, no one can recover the contents of its internal SSD once it has been wiped in this way. Nearly a year ago there were claims that old data could re-appear afterwards, but those turned out to be false.

I’m afraid that the only way to recover the data from a volume wiped using EACAS or Find My Mac is to restore it from a backup.

Backups are more important

For Intel Macs with T2 chips, and Apple silicon Macs, the chances of being able to recover files from their internal SSDs have become diminishingly small. This makes it all the more important that you make and keep good and comprehensive backups of everything in your Mac’s Data volume.

I’m always sad to hear of those who have suffered data loss, and shocked to learn of how many still don’t keep backups.

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.

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.

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.

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.

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.

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

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.

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.

Do you occasionally double-click on a folder in a Finder column view, expecting it to open that folder in a new window? If so, somewhere deep in your neurones are a few that still remember how the Finder worked in Classic Mac OS, quite differently to that in modern macOS. This article traces its history.

In the original Macintosh human interface, the Finder was its centre, the scene of all interactions between the user and the computer, apart from applications. There were no diversions like a Dock, and little by way of ornament.

Even when it had gained colour with the Macintosh II and Colour QuickDraw, the Finder in Classic Mac OS was a clean and spartan environment, with no toolbar, no traffic lights, just basic controls. At the top left is the close button, and the drag resizer is at the bottom right. But its biggest difference from today’s Finder was that double-clicking a folder within a window opened that folder in a new Finder window, according to its underlying spatial metaphor, hence its name. If you double-clicked with the Option key held, the previous window was automatically closed as the new window opened on top.

Thus, each Finder window could only show the contents of a single folder, and that location couldn’t be changed within that window. Navigating from one folder to another was accomplished by opening windows. It wasn’t uncommon to end up with stacks of half a dozen or more, each displaying the contents of a different folder, and Steve Jobs once unjustly criticised this as turning the user into a window janitor.

Note in this screenshot from 1999, showing Mac OS 9.0, the printer and disk icons on the upper right of the Desktop, and the Trash can at the bottom right. There was no Dock until Mac OS X inherited it from NeXTSTEP.

Here’s another example, this time from 2001. The upper window here shows the top level of a bootable disk, Scratch1, with its custom System Folder icon containing the bootable System for Mac OS 9.1.

Mac OS X 10.0 Cheetah brought with it the distinctive blue-and-white Aqua look, traffic lights at the top left, and the first toolbar. This view shows its tools being edited, and how its special folders and locations including iDisk, a precursor to iCloud, were arranged in the toolbar rather than any sidebar. This replaced the Classic spatial metaphor with an interface more akin to a browser, a move that proved unpopular with some.

By Mac OS X 10.3 Panther, the sidebar was added. The original Aqua style is here being progressively replaced by brushed metal, and it worked more like NeXTSTEP than Classic Mac OS. Two of its three view types are shown here: Icon and Column views, the third being List view, and those remain today, with the addition of what was originally Cover Flow and became Gallery view after Mojave.

Optical disks added tools for ejection, and to burn writable media from the Finder’s toolbar. The Finder’s Preferences were starting to offer subtle customisations including ‘spring-loading’ using drag-and-drop.

In 2007, Mac OS X Leopard introduced bespoke icons for certain document types, such as images, with a thumbnail preview. Categories offered in the sidebar included Devices such as disks, Places for popular folders, and quick access to some Spotlight search categories.

These are the toolbar options for OS X 10.11 El Capitan from 2016, still with support for optical disk burning, to which are added Finder Tags (also a category in the sidebar) and the new Share tool.

The Finder also has the privilege of featuring one of the oldest obvious bugs in macOS, affecting the width of column views, as demonstrated below in macOS 10.15 Catalina of 2019, and still present in Sequoia.

The Finder underwent its last major redesign in macOS 11 Big Sur, when all traces of brushed metal were removed, icons were changed, and every corner became rounded. It’s a far cry from the original spatial metaphor.

Reference

Wikipedia on changing style in the Aqua interface style.

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

1: Paul’s creator of an errand boy now forty years old but dead for twenty-four of them.

2: Drawing without aid came three years later, only to suffer the same fate.

3: Lovers’ quarrel over thousands of incompatible file formats from an Italian printer.

The common factor

I look forward to your putting alternative cases.