I hope that you enjoyed Saturday’s Mac Riddles, episode 310. Here are my solutions to them.
1: London to Pontarddulais in Macs for six months.
Click for a solution
M4
London to Pontarddulais (route of the M4 motorway in Britain) in Macs for six months (first shipped in Macs last November).
2: Jupiter’s flash now reaches 80 for the Pros.
Click for a solution
Thunderbolt 5
Jupiter’s flash (a thunderbolt) now reaches 80 (it offers 80 Gb/s transfer rates) for the Pros (it’s available in M4 Pro and Max chips).
3: Very long run from the Thames to Eastleigh came to the workshop in March.
Click for a solution
M3 Ultra
Very long run (an ultra) from the Thames to Eastleigh (route of the M3 motorway in England, from Sunbury-on-Thames) came to the workshop in March (first available in the Mac Studio of March 2025).
The common factor
Click for a solution
They’re all new hardware in Macs released over the last six months or so.
With strong rumours that Apple intends changing its version numbering system for the next major release of macOS and its other operating systems, it’s a good time to see how we got to macOS 15.
Early Classic Mac OS
The first version of Classic Mac OS released with the original Macintosh 128K naturally came with System 1.0 and Finder 1.0. Within a few months, version numbering was already becoming confusing, when the successor System Software 0.1 had apparently started at 0.0, but the System itself had reached 1.1. This worsened when System Software 1.0 was released two years later, and came with System 3.1 and Finder 5.2.
Apple then adopted its first triplet numbering scheme that resembled modern Semantic Versioning in System 6.0 of June 1988. Over the following three years that worked its way steadily up to version 6.0.8, then handed over to System 7 on 13 May 1991 without any minor versions being released.
System 7
The first full use of the triplet numbering scheme came with System 7. That had four minor versions, 7.0, 7.1, 7.5 and 7.6, with each having patch releases such as 7.0.1 in between. This scheme followed the rules:
the first number gives the major version;
the second number gives the minor version that should remain backward-compatible in its changes;
the third number gives the patch version denoting backward-compatible bug fixes.
It was then that Apple started to release special versions of Mac OS to support new models, for example 7.1P5 for Performa models, complicating the numbering. This was even worse with System 7.1.2, which was only supplied with some early Power Macs and a few 68K Quadra models. That was accompanied by System 7.1.2P, a special version for models released around the time that Apple also released System 7.5, in September 1994.
System 7.5 brought a different numbering scheme to deal with exceptions. For example:
System 7.5.3 Revision 2 followed 7.5.3 without any Revision 1, and made various improvements;
System 7.5.3 Revisions 2.1 and 2.2 were released on the same day to address problems with Revision 2 on different models;
System 7.5.4 was never released at all, and the next release was 7.5.5.
Fortunately, the remaining versions of Classic Mac OS were conventional in their numbering, until the last in Mac OS 9.2.2 in December 2001.
Mac OS X
The public beta of Mac OS X introduced build numbers to supplement their triplet version numbering. At this time, the build number was based broadly on three components:
the first number or build train gives the major version, starting from 4 for 10.0, as this includes NeXTSTEP up to version 3;
the letter gives the minor version number, starting from A, which can also be bumped for hardware-specific builds, so may not match the triplet minor version number;
the remaining number is the sequential build number within that minor version, usually incremented daily. That’s normally three digits, but an additional digit can be prefixed to indicate specific hardware platforms.
Triplet versions and build numbers were surprisingly well behaved until 2010, although separate build numbers were used during the transition from PowerPC to Intel architecture in Mac OS X 10.4 Tiger.
The first signs of complications came with Mac OS X 10.6.3, in March-April 2010, which came in three different builds and a v1.1, and 10.6.8 also had a v1.1 released a month after the original update. Mac OS X 10.7 Lion set a trend for a final Supplemental Update to 10.7.5, and frequent Security and Supplemental Updates became the rule by 2018, with macOS 10.12 Sierra and its successors.
By 2019, these updates had become uncontrollable. macOS 10.14 Mojave, for example, had three Supplemental Updates in the two months after its final release, named as 10.14.6 Supplemental Update, 10.14.6 Supplemental Update (a second time), and 10.14.6 Supplemental Update 2 (really 3).
macOS 11
The first version of macOS to support Apple silicon Macs, macOS 11 Big Sur, had been generally expected as macOS 10.16, but shortly before its announcement at WWDC in June 2020 the decision was made for it to become macOS 11, incrementing the major version number for the first time in almost 20 years. As that reset the minor version number from 15 to 0, there was the potential for chaos, as many scripts and much code had come to ignore the major version number, and to rely on the minor version to determine which release was running.
To cater for this, when those checked ProcessInfo.processInfo.operatingSystemVersion.minorVersion (or its equivalent), Big Sur identified itself as macOS 10.16. Apps ported to Xcode 12 used the 11.0 SDK; when they checked ProcessInfo.processInfo.operatingSystemVersion.minorVersion (or its equivalent), Big Sur identified itself as macOS 11.0. Those who relied on command tools were provided with a workaround, as sw_vers -productVersion
returned 10.16 when running in Big Sur on an Intel Mac, but 11.0 on an Apple Silicon Mac.
This enabled Apple to return to a triplet scheme without the complications of Supplemental Updates or other vagaries. Each year’s major version of macOS has thus been x.0, with scheduled minor versions numbered from x.1 to x.5 or x.6, and intermediate patch releases (usually security updates) from x.x.1 upwards. At the end of its year as the current release of macOS, x.6 marked the start of its first year of security-only support, and x.7 for the second and final year. The exception to this has been Sonoma, which started its first year of security-only support with version 14.7, so its security updates have coincided in their minor and patch numbers with the older Ventura.
The only complication to this much clearer system was introduced in Ventura with Rapid Security Responses (RSRs). Those didn’t change the triplet version, as macOS proper remained unchanged, but added a letter to form, for example, macOS 13.4.1 (c). That proved clumsy, and when reflected in a resulting Safari version number it broke a lot of major websites that were unable to identify the browser version correctly. Since RSRs have fallen out of favour, this proved to be a passing phase.
When I wrote about the unexpected change in version numbering brought in Big Sur, I claimed that “no matter what Apple may eventually settle on, I shouldn’t have to change that again for many years.” I’m not sure that five counts as many, but here we go again.
I hope that you enjoyed Saturday’s Mac Riddles, episode 308. Here are my solutions to them.
1: One of two of the three at the start, he left for 12 years with the successor before returning for one more thing.
Click for a solution
Steve Jobs (1955-2011)
One of two of the three at the start (co-founder of Apple with Steve Wozniak and Ronald Wayne), he left for 12 years with the successor (from 1985-1997 he ran NeXT) before returning (in 1997, when Apple bought NeXT) for one more thing (his catch-phrase used to introduce a new product at the end of a keynote).Wikipedia.
2: Writer for Bannister and Crun who originated and named it without a mouse.
Click for a solution
Jef Raskin (1943-2005)
Writer for Bannister and Crun (he first worked for Apple as a contract writer through his company Bannister and Crun) who originated and named it (he created and named the Macintosh project in 1979) without a mouse (he originally disliked the mouse).Wikipedia.
3: First to copy and paste, then changed Pascal and Newton, but was always modeless.
Click for a solution
Larry Tesler (1945-2020)
First to copy and paste (he devised these when working at Xerox PARC), then changed Pascal (he worked with Niklaus Wirth to develop Object Pascal for Lisa and Mac) and Newton (he led development of Apple’s Newton device), but was always modeless (throughout his career he eschewed modal interfaces).Wikipedia.
The common factor
Click for a solution
They’re three of the most influential people responsible for the development of the Mac.
Macs have undergone three major hardware architectural transitions over the last 41 years, and it may well be that this year sees the completion of the last of those. I’ve previously given a brief account of those changes in CPUs; this article summarises when and how those transitions have taken place.
Classic Macs used Motorola’s 68K series of processors until the Spring of 1994, when the first transition to PowerPC processors started.
PowerPC 1994-98
Apple had originally intended to launch its new range of Power Macs on the tenth birthday of the Mac in January 1994, but its first three models, the 6100, 7100 and 8100, weren’t ready until March, when they came with System 7.1.2 and a PowerPC ‘enabler’. Much of the system was still in 68K code, so to enable its continuing use, and to allow the running of existing 68K apps, it came with a built-in 68K emulator. That was surprisingly mature, as it had first been developed by Gary Davidian for use in experimental RISC-based Macs during 1990, as part of the Cognac project to identify a successor for the 68K.
Mac OS supported both PowerPC and 68K architectures from March 1994 to Mac OS 8.1 in January 1998. Support was dropped from 8.5 in October of that year, although the 68K emulator remained until the final version of Classic Mac OS, 9.2.2, released in December 2001. The last 68K Macs were the LC 580, produced between April 1995 and April 1996, and the PowerBook 190cs, discontinued in October 1996.
Thus, the transition period to PowerPC processors lasted from March 1994 to October 1998, a period of 4.5 years.
Apple System Profiler here shows details of a Power Mac G3 Blue and White from 1999.
TattleTech reveals that it was the first model to be officially assigned a name in the new series, as a PowerMac1,1, or 406 in the old Machine ID numbering.
Running a Windows PC in emulation using VirtualPC, seen here in July 1999, was useful but hardly performant.
PowerPC processors reigned for just over a decade before Apple switched a second time, to Intel CPUs.
Intel 2006-09
Moving to a well-established architecture was anticipated to be quicker, and when Apple announced the change at WWDC in 2005, Steve Jobs expected the hardware transition to start by June 2006, and to be completed by early 2008. In fact, the first Intel Macs shipped in January and February 2006, the iMac and Mac mini respectively. The last Power Mac G5 was produced between October 2005 and August 2006, and by the end of that year the full range of Intel Macs was complete.
Mac OS X came with initial Intel support in 10.4.4, installed on the first iMacs. The last version to run on PowerPC processors was 10.5.8 in August 2009, and in the same month Mac OS X 10.6 was Intel-only.
Rather than opting for another software emulator to run PowerPC code on Intel processors, Apple licensed code translation technology named QuickTransit from Transitive Corporation, an extension of Dynamite technology developed by the University of Manchester, England. This version of Rosetta could translate G3, G4 and AltiVec instructions, but not those specific to the PowerPC G5 processor. This was bundled in Mac OS X from 10.4.4 in January 2006, until it was discontinued in 10.6.8 in July 2011.
The transition period to Intel processors lasted from January 2006 to August 2009, a period of just over 3.5 years.
Apple silicon 2020-?
Apple’s third transition has been distinguished by its lengthy and staged preparation, and the fact that its goal was the first Mac that has been completely designed and developed by Apple. Its roots go back to a partnership with the British microcomputer manufacturer Acorn Computers in the 1980s that led to the development of the Acorn RISC Machine using an early RISC processor, and the origin of the name ARM. During the 1990s Apple, through Larry Tesler, was a major investor in ARM, who provided the processor for Apple’s Newton handheld devices launched in 1993. Although the Newton was a commercial failure, it was the germ for the first iPhone in 2007, and the iPad three years later.
Another landmark in the preparations for Apple silicon Macs was the incorporation of the T2 Arm-based ‘security chip’ in Intel Macs from December 2017 onwards, although Apple didn’t incorporate that into a regular iMac model until as late as 2020.
Apple announced this transition at WWDC in June 2020, and the first Apple silicon Macs shipped in November that year, Mac mini, MacBook Pro and MacBook Air models. This was less than a year after the release of the last Intel Mac, the delayed Mac Pro of December 2019, which continued in production until June 2023, and the more popular 27-inch iMac made between August 2020 and March 2022. First Apple silicon Macs came with macOS 11.0, and both architectures remain supported as far as macOS 15 Sequoia, from 2024.
To enable its new Macs to run apps built for Intel x86 processors, Apple returned to code translation in Rosetta 2, bundled in macOS 11 and later, but downloaded and updated separately. To accelerate the launching of x86-64 apps, this uses both ‘just-in-time’ translation at the time of launch, and ahead-of-time (AOT) when an x86-64 single-architecture binary is installed. In contrast to its earlier emulator and even the first version of Rosetta, this performs spectacularly well.
The transition to Apple silicon thus started in November 2020, and appears likely to end with the release of macOS 16 in the autumn/fall of 2025. That would be a period of almost 5 years, even longer than the first transition to PowerPC. This time we’re better prepared for the future, as Apple silicon Macs offer excellent virtualisation of macOS, allowing the latest chips to run macOS as old as Monterey from 2021, together with full support for x86-64 apps using Rosetta 2 in the virtual machine.
I hope that you enjoyed Saturday’s Mac Riddles, episode 307. Here are my solutions to them.
1: Workshop exhibition with thunder and lightning from the A13 in 68.58 cm.
Click for a solution
Studio Display
Workshop (a studio) exhibition (a display) with thunder and lightning from the A13 (it contains an Apple A13 Bionic chip with CPU cores named Thunder and Lightning) in 68.58 cm (27 inches).
2: First person seed vessel contact takes music wherever.
Click for a solution
iPod Touch
First person (I) seed vessel (a pod) contact (touch) takes music wherever (it does). (The first model came with a Samsung S5L8900 ARM SoC.)
3: Notes of brief communication from a pioneering mathematician.
Click for a solution
MessagePad
Notes (in a pad) of brief communication (a message) from a pioneering mathematician (Sir Isaac Newton). (It came with an ARM 610 processor running at 20 MHz.)
From the outset, the Macintosh was a single integrated unit, at a time when other personal computers came with separate displays.
Macintosh 128K (1984), Apple Museum Prague. Image by Benoît Prieur, via Wikimedia Commons.
It took three years for Macs to diverge into the all-in-one SE and the modular Macintosh II with its conventional case and separate colour monitor. The meteoric rise of desktop publishing demanded large, deep and heavy cathode-ray tube (CRT) colour displays that only came separately, and needed long graphics cards that had to be fitted inside the computer’s chassis.
Although the Mac SE weighed up to almost 10 kg (22 pounds), many lugged them around in soft cases slung over their shoulders, providing a degree of portability. There are some folk whose backs still bear witness to those days of the luggable Mac.
Integral CRT displays hardly changed over this period. The Macintosh 128K came with a 9 inch screen displaying a mere 512 x 342 pixels in monochrome. Ten years later, the Color Classic was the first all-in-one to come with a 10 inch colour screen, and that only increased resolution to 512 x 384 pixels. Neither was there any support for external displays, until the LC 520 in July 1993, with its 14 inch colour CRT at 640 x 480 resolution and display port.
During the 1990s, Apple offered various Power Macintosh, Performa and LC all-in-one models featuring integral or piggybacked displays, culminating in the Power Macintosh 5500 in 1997, with its 15 inch CRT of which less than 13 inches were viewable, and supporting up to 832 x 624 pixels.
Twentieth Anniversary Macintosh (1997). Image by Shelby Jueden, via Wikimedia Commons.
Apple’s next innovative all-in-one was the Twentieth Anniversary Macintosh (TAM), released a year late in 1997. It came with a 12.1 inch backlit active-matrix screen rather than the traditional CRT, in this unique design. Although a limited edition intended to be a collector’s item, it was overpriced and sold poorly, and has since been eclipsed by the most innovative model since the original 128K.
In May 1998, Apple announced the first iMac, based on a PowerPC G3 processor and a 15 inch CRT, of which 13.8 inches are viewable at resolutions of up to 1024 x 768 pixels. The design wrapped the case around the bulk of the display in the form of a ‘gumdrop’, using coloured translucent plastic later offered in a range of bright colours.
iMac G3 (1998). Image by Felix Winkelnkemper, via Wikimedia Commons.
It was also technically innovative, featuring novel USB ports and discarding the traditional floppy disk drive in favour of optical and hard drives. This shipped in August 1998, with hardware revisions that October and the following January.
A few months later Apple quietly slipped out the Power Macintosh G3 All-in-One, but that proved to be a dead-end and has been largely forgotten in favour of the iconic iMac.
By January 2002, flat-panel displays were starting to displace bulky CRTs, and Apple made use of them in its first flat-panel iMac. This featured a PowerPC G4 processor, and a 15 inch TFT active-matrix LCD delivering up to 1024 x 768 pixels. The computer components were assembled into a heavy hemispherical base on which the display was mounted using a hinged stainless steel arm resembling an Anglepoise desk lamp, which had been designed in 1932 by George Carwardine and is still in production.
iMac G4 (2002). Image by Maxime Bober, via Wikimedia Commons.
This ‘Anglepoise’ mount remains the best adjustable mechanism used with a display, ensured effortless positioning to suit each user, and eventually supported 20 inch flat-panel displays.
iMac G4 (2002), display mount. Image by Maxime Bober, via Wikimedia Commons.
With displays now thin enough to allow computer components to be integrated behind the screen, the next step was to eliminate the heavy base. Apple achieved that in August 2004 with the iMac G5, in its 17 and 20 inch models. With the switch to Intel processors and further integration in computer components, display size rose to 24 inches in 2007, and 27 inches two years later.
For many, the zenith of the iMac came in Retina 5K displays first offered in 2014, and the most powerful Intel iMac of all, the 27 inch iMac Pro released at the end of 2017. The latter features Intel Xeon processors with 8 or 10 cores together with the new T2 security chip. Although it doesn’t appear to have sold well, it was popular with developers and others during the hiatus between the Mac Pro models of 2013 and 2019.
Although the iMac Pro was the first Mac to feature a T2 chip, their inclusion in other iMacs was delayed until Apple had already announced its move to Apple silicon models. The last Intel iMac with a 27 inch Retina 5K display was released in August 2020, three months before Apple shipped the first M1 Mac mini and others.
Since May 2021, Apple has offered a succession of three iMacs powered by its M-series chips, all with a 24 inch Retina 4.5K display. They follow in the line of the original iMac from 1998, and come in a range of colours. But there are many who are still clinging onto ageing Intel iMacs in the hope that, one day, Apple will offer an all-in-one in the spirit of the iMac Pro, with a Pro grade chip and a 27 inch Retina 5K display.
Evolution of iMacs. Graphics by Giulia Piccoli Trapletti, via Wikimedia Commons.
I hope that you enjoyed Saturday’s Mac Riddles, episode 306. Here are my solutions to them.
1: Where I left my heart in our words since 2015.
Click for a solution
San Francisco
Where I left my heart (I Left My Heart in San Francisco) in our words since 2015 (when it became the system font across all Macs and Apple’s devices, now abbreviated to SF).
2: The first windy city from Susan Kare until 1997.
Click for a solution
Chicago
The first (the first system font on the Mac from 1984) windy city (Chicago) from Susan Kare (she designed the font) until 1997 (when it was replaced by Charcoal).
3: Bigelow and Holmes brought great clarity for the millennium.
Click for a solution
Lucida Grande
Bigelow and Holmes (it was designed by Charles Bigelow and Kris Holmes) brought great (grande) clarity (the origin of Lucida) for the millennium (it was adopted as the system font from 1999-2000 onwards).
The first Macs came with bitmap fonts stored in FONT resources, and those were normally used in the set sizes supplied, as they scaled so poorly. Later in 1984, with the release of the ‘Fat’ Mac 512K and its 128K ROM, Apple moved to NFNT bitmap fonts with a more flexible ID scheme. This continued to change the following year with the introduction of the LaserWriter printer and its built-in PostScript fonts, but those fonts remained in the printer, and Mac displays stayed with bitmap NFNT fonts.
At the outset, Apple had taken a small liberty with the size of the point, the standard unit in typography and print design. In normal US usage there were 72.27 points per inch, which Apple rounded down to 72 for the Mac, where it has remained ever since.
Adobe introduced PostScript Type 1 fonts, still primarily for PostScript laser printers and Adobe Type Manager software. Although competitors reverse-engineered the Type 1 format, Adobe brought them into costly licensing agreements, so limiting access to their rendering. This provoked Apple to start developing a rival outline format, later to be termed spline fonts or sfnt. This project was initially known internally as Bass, then renamed Royal, and was released as TrueType with System 7 in May 1991.
As late as 2002 Mac OS 9.2 still used some bitmap fonts.
Throughout Classic Mac OS, fonts were stored as resources, and in the early years had to be installed using Font/DA Mover, a bundled utility that also performed ID reconciliation. DA stood for Desk Accessory, which also required careful installation.
This is Font/DA Mover 4.1 in 1999.
Individual fonts were grouped into FOND font families, also introduced with the 128K ROM. These could include both NFNT and TrueType sfnt font types. FOND families each had their own ID, but those weren’t unique, so fonts had to be specified by name.
With the success of TrueType, Classic Mac OS became the first operating system to be able to work without the use of bitmap fonts, but still couldn’t itself render PostScript Type 1 fonts to a display. Those using Macs for pre-print design paid for Adobe Type Manager to perform that rendering.
TrueType was revolutionary in opening up font internals in a way that hadn’t been possible with Adobe’s control over PostScript Type 1 fonts. At the time I was writing CAD/CAM apps to support extreme-format cutting systems used by sailmakers and others, who also wanted to cut large characters from fabrics. One of Apple’s TrueType engineers worked closely with me to convert the outline drawing commands in TrueType glyphs into cutter control streams to fabricate letters and numbers sometimes several feet/metres high. I never did work out what point size they would have been.
Microsoft licensed TrueType free from Apple, but Adobe fought back by opening up its Type 1 font format as free to use. Apple enhanced TrueType in 1994, with TrueType GX, bringing Variations to compete with Adobe’s Multiple Master fonts, but it never caught on and few GX fonts were ever released. Its technology was, though, incorporated into Microsoft’s TrueType Open in 1994, and two years later that was merged with support for Type 1 features in OpenType, which became an ISO standard in 2007. The final milestone, for now at least, was the release of OpenType 1.8 in 2016, with its full incorporation of the font Variations of TrueType GX and Adobe’s Multiple Master fonts.
FontLab was originally developed for Windows, and version 3 came to Mac OS 8 in 1988. It’s seen here in 2001, in Mac OS 9.
The release of Mac OS X in 2001 drew Mac fonts away from their previous reliance on resource forks. Font suitcases thus moved to a data-fork format with the extension dfont.
These font suitcases are seen in data-fork format in Mac OS X 10.3 Panther in 2004.
At that time, Apple’s bundled Font Book app had limited features. Here it’s displaying a data-fork format TrueType font Zapfino.
Fontage was a substitute with additional features.
Mac OS X has also brought substantial improvements in Apple Advanced Typography (AAT), a successor to TrueType GX. Mac OS X 10.4 largely completed advanced support for Latin scripts, with later versions of OS X and macOS extending that to Arabic and Asian languages.
Major foundries produced their own software. This is Linotype’s FontExplorer X in 2006, helping to repair a PostScript font suitcase with missing files for download to a PostScript printer.
By 2006, FontLab had developed into FontLab Studio, seen here editing glyphs from my own handwritten font.
Linotype released a Pro version of its FontExplorer X, shown here in 2010. For typographers, designers and font nerds it revealed almost everything there was to know about a font, here a TrueType Helvetica variant.
The other major font design app for Mac OS was Fontographer, developed by James R Von Ehr II, and released by his company Altsys in 1986. This was the successor to an earlier bitmap font editor named Fontastic, and two years later Altsys released the pioneering illustration app FreeHand. In 1995, Altsys was bought by Macromedia, then ten years later Fontographer was bought by FontLab. This shows Fontographer 5.0, released in 2010, and sadly abandoned a few years later.
Mac OS didn’t require or even support the signing of apps or executable code for its first 23 years. Apple announced its introduction at WWDC in 2006, and it appeared in Mac OS X 10.5 Leopard the following year. This happened in conjunction with the release of the first iPhone, on which only code signed by Apple could be run, and could be the first instance of an iOS feature being implemented in Mac OS.
In Mac OS, it was an Apple engineer known as Perry the Cynic, probably Peter Kiehtreiber, who claimed to have been responsible. As he told Jeff Johnson later, “I do work for Apple, and I designed and implemented Code Signing in Leopard. If you think it’s going to usher in a black wave of OS fascism, you have every right to blame me – it was, pretty much, my idea.”
Third-party developers were rightly concerned about Apple’s plans. In 2008, developers were told that “signing your code is not elective for Leopard. You are *expected* to do this, and your code will increasingly be forced into legacy paths as the system moves towards an ‘all signed’ environment. You may choose to interpret our transitional aids as evidence that we’re not really serious. That is your decision. I do not advise it.”
Despite those ominous remarks, it wasn’t until Gatekeeper was introduced in 2012 that code signing became of general importance. With Gatekeeper came the quarantine of apps downloaded from untrusted sources, and first run checks made on all quarantined apps, including ascertaining signing identity and code integrity.
Certificates
From the outset, there were two types of code signature: self-signed using an ad hoc certificate that has no chain of trust back to a root, and those using a certificate traceable back to Apple’s root certificate. While ad hoc certificates can provide a weak form of identification, almost all the value of code signing requires traceability to a certificate authority.
Apple therefore provides registered developers (who pay an annual subscription) with certificates for signing their code, but macOS doesn’t recognise certificates provided by any other authority. Certificates are also specific to their purpose: those used to sign apps for distribution outside the App Store, for example, are known as Developer ID Application certificates, and are distinct from those used to sign installer packages.
Until 2018-19, macOS stored information about valid certificates in a local ‘Gatekeeper’ whitelist database at /private/var/db/gkopaque.bundle, updated every couple of weeks. Since the release of macOS 10.15 Catalina that became effectively disused and wasn’t updated after 26 August 2019. Gatekeeper started performing online checks, to determine whether a certificate had been revoked by Apple as the certificate authority, probably from before El Capitan in 2015, but until Catalina those were only performed on quarantined apps undergoing their first run. From around July 2019 and macOS 10.14.6 those were extended to include apps that had already cleared quarantine.
Checks with Apple to verify certificates are made using the Online Certificate Status Protocol, OCSP, which came under fire in November 2020, when Apple’s OCSP service failed, leaving many unable to launch apps. It was subsequently realised that online checks weren’t encrypted and could have been used by man-in-the-middle attacks to identify users and their apps. Although Apple made some changes, its initial promises don’t appear to have been fulfilled.
CDHashes
When code signing was introduced, most attention was paid to the certificates it required, although Apple also stressed the importance of the cryptographic hashes in the code directory that’s actually signed. This is a data structure containing hashes for pages of executable code, resources, and metadata such as entitlements and the Info.plist property list, that are protected by the signature. The hash of each code directory is known as a cdhash, although here I’ll perversely refer to it as a CDHash for readability.
CDHashes were originally computed using SHA-1, but that was replaced by SHA-256 in macOS 10.12 Sierra, when SHA-1 became deprecated. Apps signed to work with 10.11 and earlier will therefore contain SHA-1 hashes, in addition to SHA-256 hashes if they’re intended for 10.12 and later.
Because hashes are unique and sensitive to the slightest change in data, they have become increasingly used to check the integrity of signed apps and code, and to identify it. Make a tiny change in a signed app’s Info.plist and a CDHash check will report the error and refuse to open that app.
Errors detected following launch normally result in macOS crashing the app, with a code signing error.
Privileges and entitlements
From the outset, code signatures have been used by Apple to determine access to some privileges. Among those were keychain access, code injection, access to an app sandbox, and Parental Controls. Since then, they have extended to include kernel extensions and many controlled features such as the ability to use snapshot features in APFS, and even access to bridged networking in virtualisation on Apple silicon.
This was anticipated by Mike Ash in 2008, when he wrote “Perhaps initially there will be some APIs which are only available to signed applications. At some point Apple will decide that there are some areas of the system which are too dangerous to let anyone in, even when signed. Perhaps you will begin to need Apple approval for kernel extensions, or for code injection, or other such things.”
Mach-O binaries
Code signatures are suited to the app bundle structure, where they can be stored in their own folder. Single-file Mach-O executables don’t have that flexibility, but their signatures and CDHashes can be appended to the binary, or, when necessary, added in extended attributes (xattrs). Apple discourages the latter, as xattrs are prone to get stripped when transiting some file systems, so are less robust.
Notarization
From the outset of the iOS App Store, and later that for macOS, apps provided through those stores have been signed not by their third-party developers but by Apple. That gives Apple full control over their contents and their CDHashes, and enables it to revoke an app by checking those, rather than having to revoke the signing certificate. However, as Apple doesn’t have any record of apps or code signed by developers using their certificates, it has no means of verifying those distributed outside its App Stores. This changed with the introduction of compulsory notarization in macOS Mojave 10.14 in 2018.
Although the App Store process and notarization have common objectives, of ensuring that apps and code aren’t malicious, and providing Apple with CDHashes and a copy of the app, they are also fundamentally different. Apps distributed through the App Store are reviewed by Apple, must conform to its rules, and are signed by Apple; notarized apps distributed outside the App Store are only checked for malware, aren’t required to comply with rules, and are signed by their developer.
This diagram shows the evolution of code signing on Macs, from pre-2007, 2007-2018, and from 2018 onwards. In 2024, the release of macOS 15 Sequoia now effectively blocks developers from distributing apps that aren’t notarized by closing the simple Finder bypass that could be used to launch unnotarized apps.
Apple silicon
Although Apple had long maintained that users would remain able to run completely unsigned code in macOS, that too changed with the release of the first Apple silicon Macs in November 2020. All code run natively on ARM processors is required to be signed, although that could still be using ad hoc signatures, as originally allowed in 2007. Xcode, build tools and other systems for developing executable code for Macs have been modified to ensure that, when building apps and other executables that aren’t signed using a developer certificate, they are at least ad hoc signed. It’s thus well nigh impossible to build code that isn’t signed at all.
Ad hoc signatures are also used in codeless apps such as Web Apps introduced in macOS Sonoma in 2023. These provide a property list defining the app’s scope in terms of its domain URL, its Home page within that, and an icon to use. LaunchServices registers them against a UUID, applies an ad hoc signature, and keeps a record of the app bundle’s CDHashes from that signature, against which to validate its contents before trying to run it in the future.
Abuse
Before notarization became widespread, some malicious software was signed using Apple Developer ID Application certificates. Obtaining a developer ID on the ‘black market’ hasn’t been costly or difficult, but until recently relatively few have gone to the trouble. This may be the effect of certificate revocation: once signed malware has had its certificate revoked, it’s dead and can’t be run on a Mac again, while ad hoc and unsigned malware has been harder to block.
With notarization becoming more compulsory, particularly in macOS Sequoia, there have been occasional malicious apps that have slipped through Apple’s checks, and been notarized. This is more demanding, and requires techniques to obfuscate code to evade detection. Even when successful, the lifetime of notarised malware is likely to be short, and for most not worth the effort.
Conclusion
Seventeen years ago, Mike Ash expressed his concern that code signing would lead to Apple having to approve the apps we can run on our Macs. Although in certain respects Apple does control what our apps can do, we can still run many apps that I’m sure wouldn’t meet its approval, and code signing has played an important role in preventing those that are malicious. Things could have been far worse.
I’d like to acknowledge the help of Jeff Johnson of Underpass App Company in providing information this brief history, although all errors are mine alone.
I hope that you enjoyed Saturday’s Mac Riddles, episode 304. Here are my solutions to them.
1: Glance at a miniature image or foretaste.
Click for a solution
Quick Look
Glance (a quick look) at a miniature image (a thumbnail) or foretaste (a preview).
2: Desktop gadget should give your beer a creamy head.
Click for a solution
Widget
Desktop (where it can go) gadget (a widget) should give your beer a creamy head (it’s also the name of a device put in some canned beers to inject nitrogen and give them a creamy head).
3: Merchant of medics ensures indexing of contents.
Click for a solution
mdimporter
Merchant (an importer) of medics (MDs) ensures indexing of contents (what it does for Spotlight indexes).
The common factor
Click for a solution
They are all supported by app extensions (appexes).
I hope that you enjoyed Saturday’s Mac Riddles, episode 303. Here are my solutions to them.
1: Harvard or Yale cipher brought emoji and Ugaritic.
Click for a solution
Unicode
Harvard or Yale (a university or uni) cipher (a code) brought emoji and Ugaritic (two of its supported character sets).
2: US standard for 128 Roman characters now over 60.
Click for a solution
ASCII
US standard (initially ASA X3.4-1963, later an ANSI standard) for 128 Roman characters (originally consisted of only 128 characters including a basic Roman alphabet) now over 60 (first published in 1963, it turns 62 years old this year).
3: Two plus 128 more came in 1989, gained a euro in 1998, and still supported.
Click for a solution
MacRoman
Two plus 128 more (it consists of the 128 characters in ASCII, plus 128 more including punctuation, symbols and diacritics) came in 1989 (first appeared in System 6.0.4 in that year), gained a euro in 1998 (the only change made since introduction), and still supported (it is, although now encoded in UTF-8).
The common factor
Click for a solution
They are text encodings that have been used in Mac OS.
The first file system for Macintosh computers wasn’t HFS+ or even its predecessor HFS, but Macintosh File System, MFS. This was introduced in System 1 on the 128K Mac just over 41 years ago, to support its 400 KB floppy disks. Although it was fairly primitive, it incorporated some visionary features, including forks. Each file had two sets of data: a data fork as in other file systems, and a resource fork for storing structured blobs of data or resources.
File naming was liberal compared with MS-DOS, allowing names up to 255 characters long, although that was restricted to 63 by the Finder. Names could consist of any printable character except the colon :, a limitation that persists in the Finder today. As there was no directory hierarchy, folders were an illusion and couldn’t be created directly by the user. Instead there was always an Empty Folder available, and when that was used, a fresh Empty Folder was created. As this was a single-user file system, there were no permissions.
MFS was still supported until it was finally discontinued 13 years later in System 8, in 1997.
Hierarchical File System, HFS
MFS had been designed for the low-capacity floppy disks of the time, and not for use on hard disks, where its limitations would have been only too apparent. For the release of the Macintosh Hard Disk 20 in September 1985, and in anticipation of the Macintosh SE 18 months later, a new Hierarchical File System had to be released to replace MFS in System 2.1. HFS remained fully supported until the arrival of Mac OS X 10.6 Snow Leopard in 2009, and finally dropped altogether in macOS Catalina a decade later.
Developed by Patrick Dirks and Bill Bruffey, HFS maintained many of the novel features in MFS, with resource forks, long file names up to a maximum of 31 characters, still excluding the colon, and in its standard single-user version didn’t support permissions. The latter were incorporated into AppleShare later. File and folder names were case-preserving but case-insensitive.
Larger storage capacities brought the need for a hierarchical directory structure, implemented using B-trees in a Catalog File that made the display of even large directories very quick. Although much of HFS used 32-bit integers, that didn’t apply to the number of files in a logical disk, which was limited to 65,535, which must have seemed sufficient at the time, and given the maximum volume size of 2 TB. With early hard disks being measured in tens of MB, that may have seemed in the distant future.
Mac OS Extended, HFS+
With the growth in capacity of hard disks, HFS had to be updated to address its limitations, in a project with the internal name of Sequoia, delivering HFS+ in Mac OS 8.1 in 1998. Switching to 32-bit fields to identify allocation blocks allowed more efficient use to be made of storage and a larger number of files in each volume. File names were increased in maximum length to 255 characters, and changed from MacRoman encoding to Unicode UTF-16 to accommodate a broader range of languages. Support for additional forks beyond data and resource paved the way for the switch to extended attributes, and OS startup support was improved to allow alien operating systems to boot from HFS+ volumes.
This screenshot shows a set of custom icons in a BNDL resource, in the QuarkXPress app in about 2000.
This shows file information available in HFS+ in Classic Mac OS in 2002.
HFS+ and its predecessors were prone to develop errors as a result of operating system crashes and other unexpected events, and those could be cumulative, leading to data loss. This was addressed with the introduction of journalling, designed and implemented by Dominic Giampaolo, who came to Apple from implementing the file system for BeOS. This was tentatively introduced as an option in Mac OS X 10.2.2 in late 2002, and made a standard feature in 10.3 the following October. Alongside that came an optional wrapper for case-sensitivity in what was dubbed HFSX, and a change in Unicode decomposition to Normalisation Form D (NFD).
Mac OS X 10.4 augmented Posix permissions with Access Control Lists (ACLs), although they were little-used outside server environments for some years. Prior to 10.5, as with most other file systems, HFS+ supported file but not directory hard-links. With the introduction of Time Machine in 10.5 Leopard, directory hard-links were added to support the structure and illusions of Time Machine backup stores.
File system support for encryption was a bit more troubled. The original FileVault, introduced in 2003 with Mac OS X 10.3 Panther, located user Home folders in an encrypted sparse disk image, which was improved in 10.5 by moving to sparse bundles. This suffered several shortcomings and vulnerabilities, and was replaced by whole-volume encryption in FileVault 2 in Mac OS X 10.7 Lion. That required the addition of a logical volume manager, Core Storage, which was then used for Fusion Drives introduced in 2012.
Apple File System, APFS
HFS+ had been designed for computers with hard disks. It lacks some of the features of more modern file systems such as snapshots, special files such as sparse files, and concurrent access. It’s also not well-suited to use with SSDs and storage in smaller, mobile devices, although when the first iPhone shipped with iOS 1.0 in 2007, it used HFSX, the case-sensitive variant of HFS+. That was until the release of iOS 10.3 on 27 March 2017, which silently converted its file system to APFS.
In 2014, Apple had decided to write its own file system from scratch, and Dominic Giampaolo, responsible for journalling in HFS+, and Mike Mackovitch became its lead engineers. APFS was announced two years later at WWDC in 2016, when it was expected to be released in another 18 months if development and testing went smoothly. Those who had hoped for ZFS were disappointed and many remain so today. macOS Sierra already had a pre-release version for those who wanted to preview it, but as we discovered when we upgraded to High Sierra, that was a far cry from what was to come.
After a promising period in beta, Apple discovered fundamental problems between APFS and its popular Fusion Drives. The first release of macOS 10.13 shipped with APFS version 748.1.46, but abruptly dropped support for those, so converted only those startup volumes on SSDs and hard disks. Snapshots were wobbly at first, and it quickly became clear that APFS was never going to perform well on rotating disks.
High Sierra had a stormy early release history, marred by a series of security gaffes. Vulnerabilities were fixed in the Supplemental Update released less than two weeks after 10.13, leaving snapshots to be improved in 10.13.1 on 31 October. Many expected problems with Fusion Drives would be fixed quickly, but those weren’t ready for release until the following September. Another problem that troubled the introduction of APFS to all platforms was the refusal during beta-testing to incorporate Unicode normalisation; this had to be resolved in later versions of macOS 10.13 and iOS 10, as explained here and here.
In September 2018, Apple at last released Mojave 10.14 with support for Fusion Drives, accompanied by the first version of the Apple File System Reference. Although a long and detailed document, developers soon realised how incomplete it was, in spite of the long delay in its publication. At last third-party file system developers had some hard information to work with, and users started assuming that third-party disk maintenance and repair tools were imminent.
Catalina brought major changes to APFS, with the use of expanded volume roles to form System Volume Groups, with their separate but firmlinked System and Data volumes. macOS 10.15.5 fixed a serious bug preventing the transfer of very large amounts of data to RAID volumes. At that time, Apple released an updated version of the Apple File System Reference, building expectations that third-party tools were just round the corner, at least among those who weren’t aware of how much information was still missing. Nearly five years later, it’s still that same edition dated 22 June 2020 that remains the latest information released by Apple about APFS.
Further major changes came with Big Sur 11.0.1 when it was released in November 2020, introducing the sealed and signed snapshot now used to boot macOS. This was also the first release to support making Time Machine backups to APFS volumes, and to support Apple silicon Macs.
Although Apple dropped early hints that APFS might be released as open source, unlike its predecessors, after eight years, information about its internals released by Apple still appears to be insufficient to allow third-party developers to create maintenance tools independent of those bundled in macOS. This reluctance may stem from the deep involvement between the file system and macOS security.
Summary timeline
MFS Jan 1984 – Sep 1985, end of support 1997
HFS Sep 1985 – Jan 1988, end of support 2019
HFS+ Jan 1988 – present, still supported
APFS Sep 2017 (iOS March) – present, still supported
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.
Click for a solution
txt
Shortened characters (text, shortened) into the most common extension (it is), formerly ASCII (it used to be).
2: Medical practitioner at the end of word files until gaining a cross in 2002.
Click for a solution
doc
Medical practitioner (a doc) at the end of word files (the extension for Word native format) until gaining a cross in 2002 (progressively replaced by the newer docx from 2002 onwards).
3: At the end of real estate inventory, most commonly for Info and preferences.
Click for a solution
plist
At the end (a filename extension) of real estate (property) inventory (list), most commonly for Info (Info.plist in bundles) and preferences (also usually property lists).
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.
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.
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.
Click for a solution
M3
The first chips (Apple silicon SoCs) with six-packs (the M3 family is the first to support six-core clusters) celebrated Halloween (they were announced at Apple’s ‘Scary Fast’ event on 30 October 2023).
2: First with FireWire and almost see-through in its two-tone case.
Click for a solution
Power Macintosh G3 (Blue and White)
First with FireWire (it was the first Mac to come standard with FireWire ports) and almost see-through in its two-tone case (it has a distinctive translucent blue and white case).
3: It brought Exposé, Fast User Switching and Xcode.
Click for a solution
Mac OS X 10.3 Panther
It brought Exposé, Fast User Switching and Xcode (all three were new features in 10.3, released on 24 October 2003).
The common factor
Click for a solution
The number 3; in binary 11, which looks like the number 2 in Roman numerals.
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.
Login
