[Home | Contact | What's New? | Products | Services | Tips | Mike |
Living with Schizoaffective Disorder

Please to Forgive

This site totally sucks when viewed on a smartphone.
I'll fix this Real Soon Now.

Our Competitors Dine in Many of
the Same Fine Restaurants We Do

An Apple corporate propaganda poster, back in the day.

Loose Lips, you see.

So do those who were at one time but may no longer be among Apple's most-prominent, influential and productive developers.

Haiku mostly works well on an Early 2006 MacBook Pro but there are some driver issues. I'll try out my Retina Display MacBook Pro (MacBookPro10,1) late this afternoon. It may be 32-bit only, but there has been a 64-bit branch for a couple years.

That is, if you catch my drift.

Maybe Right Now would be a good time to lurk on, if not actually subscribe to a couple Apple lists:

I cross post but some replies don't.

That is, if you catch my drift.


Many of Apple's developer sites have been down for a couple weeks as they repair a security breach. That's not my concern here.

My concern is that, ten weeks after filing a bug report that is in reality of far more concern to Apple than to myself, there is no response of any sort, leading me to believe that Apple doesn't triage reports against its developer sites.

I served on Apple's triage team on a daily basis for a while back around 1996 or so, when I was a "Debug Meister" on their Traditional OS Integration Team - the team formerly known as "The Blue Meanies".

Our stated task was to take all the source drops from components that were ready for QA, then deliver a single source drop to Apple's source code control. The binaries that Apple's QA received, was built from the source - unaltered - that we delivered to source control. Were source control to find any issues at all, they'd kick it back to us.

But inevitably there are all manner of weird things that go wrong when one integrates the many complex but independently developed components of a single but complex systems. So most on our team were Debug Meisters ourselves, not always experienced coders but always those who were particularly good at debugging really weird shit.

Try this on each of your own boxen; quite likely you'll report an as-yet-unknown bug:

I wrote a one-line AppleScript, then dropped it into the Startup Items Folder:

Tell Finder Restart

Then rebooted, verified that it continued to reboot, then left for the day.

On Linux, that would require a reboot after end-user login to the GUI was ready. Perhaps that could be done by disabling the requirement of login, then in one of our GUIs, there is an API for launching an App just as the GUI is ready for that user. One would then either exec, or use system() to execute in a subshell:

$ sudo shutdown -r now

That would require sudo not to have to prompt for a password. Perhaps one could create a user with no password, as well as an entry in /etc/sudoers (?) that grants permission for that user to execute only /sbin/shutdown. It's important, when running this test, that the system configuration be as little as possible different from its production configuration.

The following day, I found that box - a prototype-hardware Power Mac 8500, running a dev build of 7.5.2 I think, but maybe it was 7.5.3, crashed into MacsBug, a machine debugger. On Linux, that would be kgdb or some such. That kind of debugger replaces the entire operating system with itself when it is entered, then replaces itself with the operating system to so much as step a single instruction.

I'm totally thrashed, so I'll post my debugging procedure as my next article. But more or less after a month of actually quite difficult work, I was able to identify the source file responsible. It was in the Ethernet driver for our new Open Transport network architecture. At that point I referred the bug to the owner of that source, who found a small edge case in the Ethernet shutdown procedure.

Open Transport was dramatically superior to MacTCP, and has many significant architectural advantages to both the kernel and userspace networking we use today, but it was quite complex. In my understanding no one was ever able to shake the bugs out of it, so today OS X uses Berkeley Sockets like everyone else, but the internal driver architecture is the I/O Kit, quite a lot easier to work with than your usual *NIX driver.

I eventually resigned, quite reluctantly from what I regarded as the most fascinating work of my career, because the entire time I was there, I never once checked in any of my own source. The very instant I knew who owned the source responsible, they got my bug report. Otherwise we never could have kept up.

While I did double the speed of an important code path that was in common use, at the time Apple could only build system software by using rsh to have the PowerPC build done by IBM AIX on an RS/6000 workstation. I would have been completely cool with that, but it was simply not possible, given that our actual build scripts were MPW Shell Makefiles. In many respects MPW is to this very day far superior to the UNIX Shell and even GNU Make, but it is dramatically different from anything that is done on UNIX.

For me to check in my code, I had to verify my build - on my own Mac - from a repository checkout of my code. I struggled with that to the point that I spent an entire day completely overcome with grief, eventually to mail my source to a colleague, who did of course credit me in the checkin message, but the actual ChangeLog credits him.

I am quite certain that particular code is still in use in OS X, but only for binary compatibility with Carbon Code. Carbon runs fine on OS X Intel Macs, but I don't think that component was ported to 64-bit. I don't know; it was a purely internal optimization of the Resource Manager, loosely speaking a binary blob database, whose keys are the concatenation of a 16-bit ID and a 32-bit sequence of four text characters. While intended for UI configuration - menu text and the like, from time to time it was used as a general purpose database.

I've been working on my very first iOS App, Warp Life, since December 2009. I did not at the time have a clue about either Objective-C or Cocoa Touch, so at first I worked out a basic prototype as a Cocoa OS X App, then upon having come to grips with Cocoa and Objective-C, rewrote it from scratch, still in Objective-C but far improved, to the Cocoa Touch framework, using Xcode's Interface Builder

[Home | Contact | What's New? | Products | Services | Tips | Mike]