The Macintosh was intended to be different in many ways. One of them was its file system, which was designed for each file to consist of two forks, one a regular data fork as in normal file systems, the other a structured database of resources, the resource fork.

Resources came to be used to store a lot of standard structured data, such as the specifications for and contents of alerts and dialogs, menus, collections of text strings, keyboard definitions and layouts, icons, windows, fonts, and chunks of code to be used by apps. You could extend the types of resource supported by means of a template, itself stored as a resource, so developers could define new resource types appropriate to their own apps.

Apple’s engineers developed a resource editor that quickly became one of the best-known apps on the Mac: ResEdit, last seen in version 2.1.3 way back in 1994. This was the power user’s quintessential tool: if you didn’t like a particular dialog in an app, ResEdit could be used to change it; if you wanted to create your own custom keyboard layout, it was the first choice for that too. If you were wicked enough to want to mess someone’s Mac up, you could go into their system files and change things around when they were out at lunch. Not that anyone ever did that, of course.

Each resource type had a four-character name, such as ALRT for an alert definition, CODE for executable code, DLOG for dialogs, KCHR for keyboard layouts, MENU for menus, STR for text strings, and so on.

You could have many different KCHR resources, each numbered, so that changing your keyboard layout was a matter of switching from KCHR number 2, the standard British layout, to number 26 for Dutch, for example. Adding your own custom keyboard layout was then merely a matter of defining a new KCHR resource with a unique ID number, here 128, and editing it to map the keys how you wanted.

Many resource types had custom editors: that for KCHR has a simple keyboard layout and tabular form. The highlighted (black) keys indicate that the Euro character € being shown would be generated by holding the Opt (Alt) modifier key and pressing the 2 key on the top row of the main keyboard, but not the 2 on the numeric keypad.

Customising the icon displayed for QuarkXPress was another fun job for ResEdit.

In those days, it was ResEdit that displayed the Get Info dialog for folders and files, where the sizes of resource and data forks were revealed. Note the vital Type and Creator fields shown: those used four characters that determined the icon to be used for documents, and which app would open them when double-clicked. They were used to build the Desktop Databases, mapping files to their icons and apps.

Resource forks and the thinking behind them are ingenious and empowering, but open up many security issues. In the days when there was Classic Mac OS malware, it often came in resource forks, and took advantage of their features. Although it was possible to lock and protect individual resources, armed with a copy of ResEdit you could soon change that, and almost anything else that you wished to, just as malware could and did.

This is demonstrated in the names seen in this malware library: WDEF preyed on windows resources, MDEF on those for menus, and several of these malicious files are shown with the icon for ResEdit’s resource files.

With Mac OS X, resource forks went into hiding, soon becoming extended attributes. App resources were split out into bundles, folders containing standard structures of files and more folders. Within those, the data structures that would have gone into resources are now folders full of files with standard data forks. In many cases, structured data are set out in XML, which is far less efficient than those old resources, and less suitable for power users to tamper with.

Instead of the limitless customisations to Mac OS, apps, and almost everything on your Mac, accomplished using ResEdit, apps are now locked down by their signatures, and can’t be tampered with any more. While they lasted, resources and ResEdit were exciting and satisfying, if horribly insecure.

References

Wikipedia on resource forks.
Wikipedia on ResEdit.
Apple reference manual for ResEdit 2.1.

For the first three years after the release of the Mac, it’s believed to have remained blissfully free of viruses and other unwanted and malicious software, which was only just starting to plague other personal computers.

Then came the first variant of the nVIR virus in 1987, and the following year a spate of malware in HyperCard stacks. Those were encouraged by the app’s rapid popularity, and exploited its built-in scripting language HyperTalk. John Norstad of Northwestern University responded by releasing his popular anti-virus app Disinfectant in 1989, and others followed in his wake.

Symantec Antivirus for Macintosh (SAM), renamed Norton AntiVirus (NAV) in 1998, was launched in 1989, two months after Disinfectant. McAfee later based its commercial VirusScan on Disinfectant.

During the 1990s viruses became more widespread and malicious, and some exploited features such as CD AutoPlay, widely used to run QuickTime rich media from optical disk. Apple’s new accessible scripting language AppleScript soon fell victim to a whole range of nasties, which continues to this day. In 1997, it was estimated that there were at least 35 Mac-specific viruses, together with numerous malicious macros for Microsoft Word and Excel that caused mayhem across platforms.

Here’s my small collection of samples that I used when evaluating and reviewing anti-virus products at the time. Many of these were INITs that loaded at startup, and several could prove very damaging. There were several unfortunate accidents where Mac malware was distributed by commercial sources, including one provided in the cover floppy disk of a reputable Mac design and publishing magazine.

John Norstad’s Disinfectant finally bowed out on 6 May 1998 after nearly a decade of service to the community, but there were still free tools including Agax, with its modular design, shown above.

By the end of that decade there were six commercial anti-virus products for Macs, of which the most popular were Norton/Symantec Antivirus for Macintosh, and Virex for Macintosh from Datawatch Corporation. In addition to those, two British developers offered products, Dr. Solomon’s AntiVirus ToolKit for Macintosh and Sophos, and there was one from France.

Intego, then based in Paris, first released its anti-virus Rival in 1997, initially only in French. Then in October 2000, it released the first version of VirusBarrier for Mac OS 8 and 9.

Throughout this period, Classic Mac OS retained its reputation as being largely untroubled by malicious software, despite reality. Protection provided by Mac OS seemed rudimentary if not lacking altogether. This didn’t change with the introduction of Mac OS X, at least not until Renepo/Opener, a widely publicised Trojan, appeared in 2004 and Apple was forced to add protection in Mac OS X 10.4 Tiger.

Fortunately, by that time commercial developers were supporting Mac OS X, and Tomasz Kojm’s freeware ClamAV, first released in 2002, had been ported from Unix as ClamXav.

Further reading

Key Moments in the History of Mac Malware – 1982 to the Present, Kirk McElhearn
The Evolution of macOS Security and Privacy Features, Joshua Long

One of the few things Apple got badly wrong in the original Macintosh forty years ago was memory. It came with just 128 KB of RAM, barely sufficient for demonstration purposes, and by the autumn/fall of 1984 had been replaced by the ‘Fat Mac’ with 512 KB costing an extra $700. Apple proved quick to demonstrate that memory for its new Mac products was never going to come cheap.

Until the release of System 7 in May 1991, Macs couldn’t use virtual memory when running Mac OS, and memory management was primitive to say the least. Even in System 8.6 eight years later, virtual memory remained optional. Some apps required it, while others couldn’t run when it was enabled. Most users stuck with only enabling it when their software needed it, and made do with the limitations of physical memory of 384 MB or even less. The maximum my Blue & White Power Mac G3/350 could accommodate was just 1 GB. As apps were far more conservative in their memory requirements, this worked better than you might expect.

My Power Mac G3 worked well with Mac OS taking its lion’s share of just over 50 MB, my mail client with less than 7 MB, and the whole of Microsoft Word in under 20 MB. But apps could and did run out of memory, when they would simply quit with an error alert.

Memory leaks still plagued Mac OS 8, and many users had to resort to utilities like R Fronabarger’s freeware Memory Mapper to track free memory and try to understand what was going on.

One memory problem never fixed in Mac OS 8.x occurred in many apps including Web browsers, Microsoft Office 98, and others. Using these led to a progressive reduction in the amount of contiguous free memory, until eventually the whole Mac crashed. This appeared worst in Macs with most physical memory, and although some patches were produced by third-parties, none was a complete solution. The only workaround was to keep an eye on memory, and restart the Mac before crashing became likely.

In those days, you had to set the amount of memory to be allocated to each app in the Finder’s Get Info dialog. Getting this right was usually a matter of trial and error.

Mac OS X was completely different, with virtual memory a permanent feature, and greatly improved management by the kernel. But memory leaks continued, and we learned the pain brought by those in Mach zone memory, memory blocks allocated for use by the kernel and its extensions. That happened as recently as macOS Catalina 10.15.6, resulting in kernel panics. Those were preceded by the kernel complaining of zone_map_exhaustion in the log:
03:21:09.447981+0100 kernel zone_map_exhaustion: Zone map size 12240662528, capacity 12884901888 [jetsam limit 95%]
03:21:09.448533+0100 kernel zone_map_exhaustion: Largest zone kalloc.48, size 6544393440
03:21:09.449437+0100 kernel kernel zone_map_exhaustion: Nothing to do for the largest zone [kalloc.48]. Waking up memorystatus thread.
Memory leaks, fortunately not affecting Mach zones this time, also troubled macOS 12.0.1.

With the advent of Apple silicon Macs came the greatest change in memory management and use since the release of Mac OS X twenty years earlier: instead of having separate physical memory for devices like GPUs, M-series chips use Unified Memory, one pool for use by CPU cores, GPU, and much else apart from the Secure Enclave.

Although it’s now over 23 years since Mac OS X was first fully released, take a look in the App Store at the products claiming to ‘clean up’ or somehow manage memory, as if we were still in the days of Classic Mac OS. If anyone can explain to me how those apps aren’t making fraudulent claims, I’d be very grateful, as I stopped trying to manage my Mac’s memory when I switched from Mac OS 9 to Mac OS X, and haven’t looked back.

One of the first things that we did with early personal computers was to personalise them further by extending their operating systems. For PCs, that came in software devices such as ‘terminate and stay resident’ (TSR) programs, and for Classic Macs in different types of extension to the System. In those days, executable code was contained in resources attached to files. The resource type used for extensions was named INIT, so an alternative name for these extensions was INITs. Later, some were included in Control Panels, giving the user an easy way to configure their appearance and behaviour.

Rise

Because these INITs patched the System, they brought with them the risk of instability, and of conflicts with other extensions. Those could easily get out of hand, so in System 7.5 of 1994, Apple introduced the Extensions Manager, to make it easier to enable and disable individual extensions. The previous year, Casady & Greene had introduced Jeffrey Robbin’s invaluable Conflict Catcher which quickly became very popular.

The number of extensions involved was often great: here, although my Mac had only one Early Startup File, it had 50 other Startup Files whose loading order could be rearranged to improve stability, a further 121 other extensions, and 23 Control Panels. Even with the aid of Conflict Catcher, managing all those became a nightmare.

Kexts

Mac OS X did away with all those, replacing them with a different architecture where a relatively small kernel had scores of kernel extensions (kexts) to support different types of storage, networking, and pretty well everything else our Macs could do. It wasn’t long before kexts went the same way of Classic extensions, only this time there was no Conflict Catcher to help.

Here’s a small sample of those I used in about Mac OS X 10.4 Tiger in 2005.

In early Mac OS X, kexts were loaded individually after the kernel. As that took increasing time, Mac OS X took to prebuilding kexts into caches that could be loaded more rapidly following booting of the kernel. Almost every hardware device came with its own kext(s), and they were also popular even among fairly mundane apps.

Not only were there many kext conflicts, and plenty of old and outdated kexts causing havoc, but some proved impossible to load in the first place, here in Mac OS X 10.6 Snow Leopard. A few even appeared to be malicious.

XProtect

To try to address this, Apple introduced blacklists of known bad kexts, that the system blocked using XProtect. These were extended in El Capitan (OS X 10.11, 2015) to block a long list of incompatible kernel extensions (KEXTs), and a shorter list of undesirable Safari extensions.

The list of blocked kernel extensions was split between Incompatible Kernel Extension Configuration Data, kept in /System/Library/Extensions/AppleKextExcludeList.kext, and XProtectPlistConfigData. The former data was seldom updated, but XProtectPlistConfigData changed more frequently. The scale of the problem was such that, in 2015, XProtect’s configuration files listed more than 10,000 signed kernel extensions that were permitted to load in OS X.

Kernel extensions are vital – they include all the main hardware drivers to make your Mac work – but because they operate so close to the kernel, they have become an Achilles heel. Even simple conflicts can make a Mac unusable, and a malicious kernel extension would be catastrophic. Patrick Wardle of Objective-See introduced KextViewr to inspect extensions, and check that they’re all above board.

EtreCheck is another long-established utility that examines kexts that are currently installed.

Decline

Around the time of El Capitan and Sierra, Apple started to make discouraging noises over the future of kexts in macOS. While they remained an essential part of the system architecture, like the kernel kexts run at the highest level of privilege, so allowing kexts to be written by third-parties opened macOS to the risks of malicious or simply buggy kexts causing kernel panics and havoc. With the wisdom of hindsight, it’s obvious that this formed part of Apple’s plan for Secure Boot in Macs built around its own chips rather than Intel processors.

It makes all-round good sense to move as much code as possible from running with the same privileges as the kernel, to running at a user level. To enable that, Apple had to provide system support for alternatives such as what are now known as system extensions, provision for hardware drivers, network extensions, endpoint security, and file systems. In a few cases, such as the software RAID utility SoftRAID, Apple has been unable to achieve that; as a result SoftRAID’s kext is now bundled in macOS as standard.

This made even better sense with the arrival of macOS Big Sur and Apple silicon Macs, with their Secure Boot. Almost all system kexts are now stored on the Signed System Volume (SSV), which can’t contain third-party kexts. The kernel and system kexts are built into a Kernel Collection not unlike the kernel caches of the past.

When an Apple silicon Mac boots without any third-party kexts, it does so with full security. When it’s intended to use a third-party kext, a different Kernel Collection is required; as that doesn’t enjoy the same level of protection as the contents of the SSV, the user has to drop the Mac’s security policy to Reduced Security and explicitly enable the loading of third-party kexts.

Fall

Apple hasn’t yet announced when third-party kexts will go away altogether, but their days are certainly numbered.