Then, in the late 1990s, we decided to take the same OS architecture that made QNX so successful on x86 and deploy that architecture on other platforms as well. As a result, the QNX RTOS now runs on PowerPC, MIPS, x86, SH-4, ARM, StrongARM, and, soon, XScale. Supporting these processors is enabling QNX to grow rapidly in previously untapped markets: routers, switches, in-car computers, etc.

How is QNX different than other operating systems? Is it based on a UNIX core?

Let me try to answer both these questions simultaneously. Like Solaris, Linux, and various other Unix-style OSs, the QNX RTOS is POSIX-compliant. As such, it lets you take advantage of an immense pool of source code and programming talent. Nonetheless, QNX's underlying architecture is completely different from Unix, and has been designed from the ground up for high-availability embedded systems - high-end routers and switches, for example.

For example, compared to a conventional Unix-style OS, the QNX RTOS can provide:

Higher availability and reliability: Instead of the monolithic architecture adopted by most Unix-style OSs, QNX uses a microkernel architecture in which every driver, protocol stack, Java VM, and OS module (e.g. file system) can run in the safety of its own memory-protected address space. As a result:

It's very difficult for any module, even a poorly written driver, to corrupt either the kernel or any other module. Faulty drivers, protocols, applications, etc. can be automatically stopped, and restarted, before they cause other services to fail.

Virtually any component of the system - be it a driver, protocol stack, OS module, or an application - can be upgraded dynamically; no need for user intervention or reboots. This makes software upgrades much simpler. In fact, many QNX systems run nonstop for years at a time, even though they are upgraded regularly with new file systems, drivers, etc (Refer to images given below).

Easier to scale: QNX also makes it easier to scale your systems, whether you are creating loosely coupled CPU clusters or tightly-coupled SMP systems. Either way, there's no need for special code: