Thar Be Tygars

Back to the old days.

Get It Try It

(SOMEWHERE IN CALIFONIA) (Rixstep) — macOS is no more. It's dead.

macOS is not to be confused with MacOS. That system died years ago, having reached version 9.22, at which time, according to John Sircusa, it could crash whilst just idling overnight.

That's quite a feat BTW. Think about it. A system so devilishly designed that its various constituent parts can, over the course of a night, so eat away at each other that by morning it's all raw inside, and thereafter goes to pieces in a tailspin.

Even Microsoft can't do that.

But this isn't about MacOS. This is about macOS. And not about Contents/MacOS either, that curious directory that's persisted all these years, for no good reason (perhaps a genius in Cupertino claimed that directories take no filesystem space) and despite the fact that Scott Forstall's finest dispensed with it for iPhone.

macOS is the new name for OS X, the descendant of NeXT's NeXTSTEP and OPENSTEP which basically brought Apple back from the brink of bankruptcy.

Do you remember how cool things were back then? How exciting they were? Oh the Maccies were happy to finally have a product to rally round and worship, but Apple management didn't give a shit about them. They were much more interested in 'switchers' - that massive number of refugees from the World of Windows™.

OS X was the Great White Hope. Windows wasn't only dying, it was starting to smell bad. And the Linux GUI APIs sucked. Just looking at how KDE went about creating a tableview was mind-boggling. Because they were dependent on Bjarne's abortion C++, they needed special constructors for each number of table columns - and if you needed more than ten columns, you were SOL.

By contrast, Steve Jobs used the space-age language Objective-C, a kernel built at Carnegie-Mellon, and a brilliantly organised API that must have got the programmers at IBM drooling. Several times bigger and more complex than the worst Redmond could hurl at the world, it had a consistency that made it eminently accessible, and development times were estimated to be one-third to as little as one-fifth of what was otherwise needed.

But Apple were held by a Gordian knot. Such a brilliant system, built on open source components, and yet it all was to be sealed down tight. They even put limericks in the kernel, begging people to not steal.

And so, despite its promise, and despite the fact that it could have wiped the floor with Microsoft's pathetic offerings, the market share of OS X remained at a barely noticeable 2-3%. Solvency had returned, but little more.

Time for iPod.

The war for the desktop is over, conceded Steve Jobs, even though he insisted on competing on an uneven playing field and otherwise wouldn't have had to lose. Apple conceded victory to Microsoft, to everyone's eternal disappointment. This handheld device, this music player, on the other hand...

Apple snuck in where Napster was no longer permitted to tread, where BitTorrent was finding itself not welcome. Revenues were up, and Apple was no longer a computer company.

OS X 10.2 Jaguar was a milestone. Still scratchy, it nevertheless had great potential. The earlier versions had been incomplete and sluggish. Jaguar was snappy. The dreaded 'beach ball' became rare. Internet Explorer was still the default web browser, but...

Things were looking good on the development side. Project Builder looked nothing less than brilliant, and Interface Builder almost literally changed the world. Running release builds through PB still offered tonnes of tips for developers. Serious runtime bugs and crashes were exceedingly rare. It was the best of times.

Panther succeeded Jaguar. A smooth grey surface replaced the pinstripes that so many found annoying. One major league journo told us that she returned her gift computer from Apple because of those Jaguar pinstripes. Telling her that the interface was more advanced than she or most people realised: it didn't change her mind.

Network admins seemed to appreciate Panther, but there was little change on the development side.

10.4 Tiger made things exciting again. Apple (Avie) announced that they'd be changing their KPIs, but this would be the final time. Havoc ensued. Visitors to the new Apple showrooms were met by screen remnants, halves of scroll bars, and worse.

And Apple were secretly hard at work on iPhone. Resources were diverted from OS X, where Scott Forstall plucked out 'the best of the best' for the new project, leaving behind - exactly what?

Bug reports mounted. Supposedly in the millions. And then, in one fell swoop, Apple tilted and cleaned off the table, telling ISVs to give up on Tiger and upgrade to 10.5 Leopard instead.

And somewhere along the line, the PowerPC faded into the sunset. Always heralded as the superior processor, both it and its successors were too hot for laptops, and Apple's meagre market share didn't offer IBM enough incentive to go on. Apple spread rumours that they would move to Intel, where shell code could spell disaster.

Xcode came along somewhere in there, and Xcode was not a joyous program. The elegant NIBs of the NeXT era gave way to 'keyed objects', then to 'designable' NIB files which served no purpose but to clutter hard drives for hundreds of megabytes. And the overall design of Xcode was horrific.

Xcode of today is even worse. Interface Builder is no longer a separate module, making maintenance much more difficult and bugs more numerous and apparent, and the design makeover no longer uses the desktop as its work area, but facetiously limits things to a parent window. It's hard to improve on perfection, as Apple satisfactorily demonstrated.

The ease with which one could declare actions and outlets is gone too. Now everything depends on a single way to do complex operations. Bugs still abound to this day. Simply saving a NIB (without making any changes) could render it useless. Connecting frameworks on several versions was only possible through egregious 'hacks'. The GNU debugger was a pale replacement for the always welcome comments previously offered by system frameworks through Project Builder.

Rixstamp Through Time

The ACP application Rixstamp is a case in point.

Rixstamp is an offshoot/spinoff from a Windows application of the same name. The project for the Windows version was gratifying (and extraordinary) in that its development was planned for a single day, and went completely according to schedule.

The idea was deceptively simple: an application that read and applied file timestamps. Microsoft were notorious back then for stamping all files in an OS release with the OS version and build number in their timestamps. And surely there are more practical uses as well.

Traditional Unix admits of three timestamps, whereof two are modifiable from userland. atime is the time the file was last accessed, mtime is the time the file was last modified or written to, and ctime is the time the file's inode was last changed.

The ctime value can only be changed in kernel mode. The API utimes is used to regulate atime and mtime.

Apple's HFS is a horse of a different colour, starting its 'epoch' before Unix (1904-01-01 as opposed to 1970-01-01) and admitting of five (5) time stamps: create, contentMod, attributeMod, access, and backup.

Early versions of the 'Carbon' API had a fatal flaw, allowing userland code to programmatically modify the attributeMod stamp (bridged to the Unix ctime stamp) which meant that uninvited 'guests' (trojans) could cover their tracks. The error was fortunately remedied.

But as long as OS X ran on HFS, HFS stamps and stamping methods were more in use.

Then Unix introduced a fourth timestamp: birthtime, the time the file was created. This too was to be a field not modifiable from userland (or supposedly in kernel mode either, for that matter).

The 'Carbon' APIs used for HFS were deprecated as of OS X 10.8. With the announcement of the new filesystem APFS, they were officially on their way out the door.

Rixstamp offers a number of useful facilities: it can retrieve the modifiable timestamps for any 'type' of file (and modify them). It can do this on a per-file basis, or on a 'batch' basis, through drag-and-drop, or by recursing through a specified directory. It can also set a 'default' stamp, to be used in 'batch' operations, and backdate files to the first of the month for the same operations, a useful precaution when uploading image and ancillary files used by HTML pages, as this obviates the need for a client browser to reload them on a page refresh, thereby minimising bandwidth and maximising user-friendliness.

Further ideas not yet implemented include backdating timestamps to the start of the filesystem epoch and bumping them forward to the 'rollover'.

The ACP application Xstamp superseded Rixstamp in everyday use and overall functionality. Now, with the move to APFS, it was necessary to add the same functionality to Rixstamp.

And that's where the fun began.

10.4 Tiger Revisited

This is what happens when you merely save a NIB in the brand new IB with Xcode - before:

And after:

As the NIB looks fine in the IB simulator, there's nothing that can be done - it already looks OK. Reverting on older systems to older versions of Xcode/IB doesn't help. The error seems to go a long way back.

And so, in a last-ditch effort to save what should be an eminently straightforward project, it became necessary to dust off an old trusty machine running OS X 10.4 Tiger.

That one could have gone all the way back to 10.2 Jaguar was tempting, but 10.4 Tiger was far back enough. But note that the NIB formats, used over the years as Apple performed alchemy on them in several stages, changed, and it isn't possible to jump straight away from 10.4 to the present - see below.

IB for 10.4 offered two formats: the classic 'NeXT' format with classes.nib, info.nib, and objects.nib, as well as a lugubrious forerunner to the current keyedobjects.nib.

And yes, it was possible to add the two new NSForm columns without incident - of course it was.

But the output file from 10.4 was a walloping 200 KB where ultimately it'd only have to be one-tenth that size.

To get there? Why of course port the files to 10.6 Snow Leopard and save again!

Done deal.

Revisiting these older systems is like reacquainting with an old friend. They look good, and they feel good. The graphics styles seem 'dusty' and outdated (and the screens aren't at all as bright as with the new MBAs and MBPs) but one can't help but marvel at the work that went into their implementation.

And as for the tools, especially IB: far superior. What takes long minutes (hours) and hair-pulling on the 'IB' of today is finished in seconds on yesteryear's NeXT tools. The engineers who built those tools knew not only how their systems worked, but also how to best design things.

Those systems reeked of a creativity that's lost with the same tools of today. The NeXT engineers were explorers, and researchers, and had a lot of flexibility within which to create. Today's engineers are but pieces of plumber's pipe, leading rather dreary lives.

The freedom to tinker is gone. The excitement of discovery is gone. You can't do bootstrap work on a handheld anyway, even if you wanted to. You can't get under the bonnet - Apple have that all sealed off. Freedom of speech is gone. You can't create and distribute as you want - you need Apple's root certificate for that, and that will cost you up front, before you even approach with cap in hand to see if they 'approve'.

And then there's the hassle and complexity of trying to be a good vendor with the hoops Apple will have you jump through, just to get out a product update or - worse - a vital bug-fix.

The big corps can do it - the suits can do anything - but their 'engineers', soulless automatons, will burn out in record time, because there's no joy in programming anymore.

The hoi polloi might love it - what's not to love with a device that needs only a finger and a thumb - but who's going to do more than produce - who's going to create?

When's the last time something truly disruptive came along? Sir Tim can't dwell on the memory of Steve Jobs forever. That's just not enough to stay afloat.

The dilemma of the ever-popular 'smartphone' and its humdrum development society isn't one that will be easily solved, but, if things are to truly move forward instead of pirouetting around and actually standing still, something's got to give.

And until then, it's not only macOS that's dead. It's a lot, lot more.

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.