Nov 12, 2009

QNX Interface Lags Mac, Windows

I've been a QNX user since 2000, when QNX Software Systems released the new Neutrino-based QNX6 platform. This was a large-but-welcome upgrade: QNX finally had a 32-bit kernel with hard realtime capabilities that ran on multiple microarchitectures. Likewise, the Photon microGUI was much improved and was even impressive for its day.

Apple's Mac OS 9 was working with the Platinum interface introduced in 1997 and Windows, at the time, was still using the Chicago GUI from 1995. QNX took a couple pages from each company's interface book for Photon and the system had a cutting-edge look and feel. But the industry didn't stand still, and Apple and Microsoft both upgraded their graphical user interfaces significantly in 2001.

The GUIs were much improved: Apple's Aqua interface had been the darling of the industry since Mac OS X Beta was available, and debuted to a chorus of praise while Microsoft showed off their Fischer-Price scheme that wowed non-technical users and other lower rungs of society. But QNX stayed still.

QSS released QNX 6.1 that same year, followed by QNX 6.2 in 2002, both without any changes to the GUI. Well, I do tell a lie—there were some new wallpaper thrown in, but that was it. Two years later, QSS released QNX 6.3 which more or less copied Microsoft's Fischer-Price look and added larger widgets, rounded corners, and bolder, brighter colors.

Finally, after a crawlingly slow development, QSS released QNX 6.4. Without any GUI updates. Tired of waiting and using a system where I could't do basic things like access the Dock or switch apps with a keystroke like Windows XP Service Pack 2 or Mac OS X Panther, I went to work.

Since Apple's Aqua was considered the best user interface in the history of the world, and Mac OS X was based on UNIX and was therefore full POSIX compliant, and since QNX had added POSIX support in its latest release, I ought to be able to merge the two systems into something small, tight, and fast that had a killer GUI to get all my work done.

Mac OS X's architecture works like this: full FreeBSD-derived UNIX services sit on top of the Mach kernel. At boot, launched opens WindowServer, which then loads the GUI widgets. Once the user logs in, Finder.app starts and offers the hands-down best file manager the world has ever seen. So it stands to reason that, if one were to copy WindowServer to QNX, and then in turn the static Aqua libraries and the Finder, one should be able to run the Mac OS X interface on top of QNX, thereby merging the world's smallest microkernel with the world's best graphical user interface.

Boy, was I naive. Despite claims of POSIX compliance, QNX is a confusing mess of broken standards and unfinished documentation. I was working with QNX 6.4 and Mac OS X v10.5, Leopard. Both run on Intel. Both have been designated POSIX-compliance. And both have a set of UNIX libraries. But it just did not work.

First off, launched would not work. I even downloaded its source to try to figure out what was wrong. I couldn't compile it using the Eclipse IDE included with QNX and the man page was an archaic, cryptic mess.

Upgrading to QNX 6.4.1 and Mac OS X v10.6 didn't help. One problem I ran into was QNX's non-standard directory structure. Mac OS X includes directories like /Library and /System for system files, and most of the Mac OS X GUI lives in /System/Library/CoreServices/. QNX has only old, out-of-date directories like /bin or /var, and nothing with any capital letters, let alone a place to stick important system commands and components. So creating a /System in QNX didn't do anything; on Mac OS X folders with special names are blessed and get a special icon. None of this happened for me in QNX and documentation on it was unavailable.

Copying WindowServer didn't go much better. Apparently QNX lacks the ability to present directories appended with .app as applications, and I so when I copied Finder.app, I was left with an impotent directory structure. To be sure, attempting to open the Finder binary also failed. I was getting pissed at this point. POSIX my ass! Mac OS X had it right. Why couldn't QNX?

After several more weeks of this crap, discovering just how POSIX-incompatible QNX was, I gave up. I'm still running the Photon microGUI on my QNX box and hating every minute of it. Why should I have to put up with some Nineties throwback while Apple has see-through menu bars and 3D effects? Even Windows 7 has that stuff now! (I'm not familiar with the Windows GUI system or directory structure, but maybe I should try it next…)

Pairing the world's tightest realtime kernel with a subpar graphical user interface is nonsensical. If QNX Software Systems ever hopes for wide QNX adoption, it needs to do something and do something fast. Five years without GUI updates is five years of ridiculous disservice to customers that has cost the platform wide popular adoption. Get your look-and-feel with the times, QSS. Until then, you can't compete with Mac or Windows.

3 comments:

  1. You're missing a major point: QNX doesn't target the desktop. They target embedded systems, which have totally different user interface requirements from a general-purpose PC. It's like complaining that Mac and Windows can't handle the hard realtime requirements of a factory robot. Well, duh.

    ReplyDelete
  2. You do realize that even if QNX was truly POSIX compliant, Finder binary will still fail to load, right? It's an Apple protected binary and requires a decryptor similar to Don't Steal Mac OS X.kext but not as restrictive as that kernel extension.

    You would probably need to somehow port dsmos/AppleDecrypt/FakeSMC.kext to QNX in order to get the protected binaries to load. I might be wrong, but I think WindowServer is also another protected binary, along with loginwindow.app.

    ReplyDelete
  3. Man, you're pretty good at this!

    ReplyDelete