Gordon Bell and Dan Dodge were finishing their time at the University of Waterloo in Ontario in 1979. In pursuit of their masters degrees, they’d worked on a system called Thoth in their real-time operating systems course. Thoth was interesting not only for having been real-time and having featured synchronous message passing, but also for originally having been written in the B programming langue. It was then rewritten in the UW-native Eh language (fitting for a Canadian university), and then finally rewritten in Zed. It is this last, Zed-written, version of Thoth to which Bell and Dodge would have been exposed. Having always been written in a high-level language, the system was portable, and programs were the same regardless of the underlying hardware. Both by convention and by design, Thoth strongly encouraged programs to be structured as networks of communicating processes. As the final project for the RTOS course, students were expected to implement a real-time system of their own. This experience was likely pivotal to their next adventure.
first QNX system found in QNX corporate’s attic, from Paul Leroux
The duo’s first year after graduation was a busy one. They moved to Kanata, went to work for Bell-Northern Research (now Nortel), and on the 30th of March in 1980, they founded Quantum Software Systems. To continue their research and experimentation with operating systems, they assembled a microcomputer built around a Motorola 6809. With the release of the IBM PC in September of 1981, Quantum’s efforts shifted to that target. Their goal was to produce a real-time operating system that would enable the PC’s use in factories, communication systems, and anywhere else that emphasized reliability.
The first version of Bell and Dodge’s operating system was QUNIX 0.1 (the Q could have been for Quantum, or for Quick, I’ve seen both from former Quantum employees), and it was running on that early, hand-assembled, 8bit microcomputer. This earliest creation was never released outside of Quantum Software as far as I know. QUNIX was a vaguely UNIX-like, microkernel, real-time operating system. I say that it was vaguely UNIX-like because in these early versions, there were some serious differences. In QUNIX, there were CP/M-like things too. Each disk had a drive number prefix, non-disk device files’ names were reserved, and the commands were a bit different from those in UNIX, often simplified to the point of being more CP/M-like than UNIX-like. Another major difference was the directory hierarchy. On a traditional UNIX system, binaries were stored in /bin or /usr/bin , configurations in /etc , and user directories in /home . On QUNIX, this wasn’t the case. Commands included in the path variable were in /cmds , configuration files were in /config , the OS binaries were in /sys , user directories were /user , drivers were in /drivers , and utilities were in /util . Then, the man command did not exist, and help was used instead. Instead of ps , the system had task with the labels of father, son, and brother to denote parent and child processes. The first version of QUNIX for the IBM PC was made before the end of 1981, and released either in December of 1981 or January of 1982, making QUNIX the first known microkernel operating system for the PC platform.
QUNIX product brochure image
A fun note from Paul N. Leroux, the bar chart on the monitor in the back left was physically glued to that monitor for another press image. It wasn’t meant to be in this image, but as photo editing tools were essentially non-existent at the time, fixing this would have required them to reshoot. They chose to go to press with bar chart present.
QNX 0.4, image from andreww591.blogspot.com
QUNIX 0.4, image from winworldpc.com
With QUNIX 0.4.33 in 1982, QUNIX became the first operating system for the IBM PC to support a hard disk, and in particular, it supported a 5MB Davong HDD. Given that a 10MB disk in 1982 could cost around $3000, it makes sense that the company’s first target was a bit more modest. At this point, however, QUNIX would not boot from an HDD. All of the floppy contents could be copied to a hard disk, but the user would still need to boot from a floppy disk.
QNX 1.2 Splash Screen, image from winworldpc.com
QNX 1.2 CLI, image from winworldpc.com
QNX 1.2, Hanoi, image from winworldpc.com
Even in these early stages of development, the system began getting recognition, and this became a small problem. The name QUNIX was a bit too close to the name UNIX for AT&T. The name of the system was changed to QNX in late 1982 following a Cease and Desist by AT&T. The first official QNX version was released the following year. At the time of the name change the kernel consisted of around 10K line of C, and it handled task scheduling, message passing, and task priority. Everything else was implemented in services that used the microkernel’s message passing to communicate with each other (even drivers, filesystems, and networking). As an important feature, message queues were network transparent so a task on one physical machine could communicate with a task on a separate physical machine on the same network as easily as if it were local. This inherently multitasked and multiuser system allowed 250 simultaneous tasks from 4 to 16 simultaneous users. The system would make extensive use of the 8087 if it was available, and required a minimum of 96K RAM. Loading up the C compiler would require an additional 32K. It’s impressive what the small company achieved on the 8088, even if, for the time, the RAM requirements were quite high. QNX release version 1.0, in March of 1983, running on an IBM PC achieved 29% to 47% the speed of a DEC VAX 11/780 depending upon the task at hand when tested by Rao Mikkilineni at Bell Labs. Sadly, I’ve been unable to find his original write-up of his testing, which was apparently in the publication Personna. If you have information about it, I’d love to get some details. While RV1 was limited to just C and x86 assembly language, the company was hard at work on BASIC, FORTRAN, and Pascal compilers that would utilize common code generators allowing for the mixed-use of languages without losing optimization. With the introduction of GUIs on the Apple Lisa, Xerox systems, and VisiCorp’s Visi-On, Quantum also had plans for windowing as well. According to Quantum’s president Syd Geraghty in InfoWorld on the 21st of March in 1983, the majority of customers were high-end system developers at large corporations. Version 1.0 cost $650 in 1983 (around $2100 in 2025), and that included a C compiler, full-screen editor, the ability to read MS-DOS disks, and full networking support. I haven’t found much information about versions 1.1 through 1.14, but I did find some information about 1.20 released on the 15th of November in 1984. This version brought pattern matching on filenames in the current directory, expanded shell programming, login was now a separate task with fast user switching and login stacking, TCAP (think terminfo), ed was rewritten and supported full-screen visual mode (think Vi), and support for the IBM AT (real-mode) was added. The price of QNX had also fallen to $450.
In June of 1981, the Ontario Ministry of Education identified computing as being important for the future, and they wanted to bring computing into their schools. They were also quite aware that some teachers had taken the initiative to bring microcomputers into their classrooms already, and the Commodore PET was the most common for programming courses, while the Apple II was the most common for other educational programs. Targeting many computers would have meant that they’d have rather high software development costs in any attempt to achieve standardization, and it was therefore decided that they’d need a single computer. In 1983, it was found by the ministry and the Canadian Advanced Technology Alliance that no existing computer would fully satisfy the goals of their educational computer. By March that year, some requirements had been drafted: all-in-one PET-like design, headphone output for voice and sound, a trackball, an 80186 CPU, a multitasking operating system, color graphics, voice synthesis, keyboard with accented characters, and networked storage (no physical disk in the computer itself). This machine as described had the sobriquet “bionic beaver.”
Burroughs ICON, image from jasoneckert.github.io
With the specifications in hand, Robert Arn at CATA created CEMCORP (Canadian Educational Microprocessor Corporation) and won a contract from the ministry for $10 million to develop the initial machines. This resulted in the ICON having been chosen. This machine was initially manufactured by Microtel and it ran QNX from Quantum Software Systems. The first machines were delivered in 1984. Later machines were produced, sold, and supported by Burroughs Canada, and after the merger with Sperry in 1986, by Unisys.
Child with Unisys ICON 2
The ICON was built around an Intel 80186 clocked at 7.16MHz and 512K RAM. It lacked any local storage having neither a hard disk drive nor floppy disk drive. At boot, the computer grabbed QNX from a local LexICON file server over a 2.5Mbps ARCNET connection, and loaded the OS into RAM. Once loaded, the user logged into the system and his/her home directory was on the file server. Up to 32 of these machines could be on a single LAN. Saving any work to a floppy, meant putting the floppy into the file server, and then copying the file from the LexICON hard disk (early models were 10MB, later models were 64MB) to that floppy. The cost of these machines was high at $2500, but any school need only have paid $495 with the government covering the rest. One incredibly forward thinking feature was the lessonware. This would have been a hypertext system in which educators could have written pages that linked to others building an extensive corpus overtime. Even applications could have been run by simply clicking a link. This model was rejected by the ministry before the ICON shipped, and was replaced by a top-down system with ministry making lesson decisions. This also resulted in the ICON having shipped a QNX CLI with the CEMCORP text editor in the earliest models.
Burrougs ICON internals, image from vintagecomputer.ca
The ICON was a project hated by many and loved by many. For detractors, it was seen as expensive and wasteful while not exposing students to industry currents. For supporters, it accomplished all of its goals. It was excellent for programming, and it was excellent at multitasking, networking, and running educational software. The software was also quite reliable. It was QNX doing what QNX does best.
From students who used ICONs, we know that it did have educational games, text editors, compilers, word processors, spread sheets, circuit design and simulation software, and CAD software. Of course, being networked machines, some unconventional students figured out ways to hack into other machines over the network, print stuff to other students’ screens, and generally cause some chaos. Combined with audio capabilities (later models even included MIDI support), this apparently got a bit out of hand from time to time.
QNX ad from Byte, April of 1986
QNX ad, Byte, January 1987
QNX ad, Byte, August 1987
QNX ad, Byte, November 1987
I normally wouldn’t show so many ads, but here is a development that is rather interesting. OS/2 had been announced on the 2nd of April in 1987, and Quantum perceived the OS as a real threat. The comparisons to UNIX were now joined by comparisons to OS/2, and QNX wanted to be certain that people understood QNX to be superior. This advertisement also shows us that QNX had responded to OS/2’s ability to run DOS software by adding that feature to QNX with the QDOS II (invoked as QDOS ) emulator, or by running a DOS application as a task via RUNDOS . QNX had been ported to the IBM PS/2 as well. This was QNX version 2.
QNX disks and manual from VirtuallyFun.com via archive.org
As far as I can tell, the release of QNX version 2 was announced on the release date of version 1.2. The release of this version appears to have been quite late, and it occurred in autumn of 1987 (two years after the initial release date given). This release brought protected-mode support for the IBM AT, full LAN support with some networking enhancements ported from BSD, support for files of up to one terabyte in size, up to 32 serial ports in one machine, and a somewhat primitive GUI called House about which I can find nothing but the name.
QNX Windows 2.3 on QNX 2.2, image from VirtuallyFun.com
While I couldn’t find anything about the House graphical environment, QNX Windows running the Open Look Window Manager (OLWM) is available.
Top, Dodge and Bell cut the ribbon; middle, expansion; third, final phase with a second building
These buildings are too big to get into a single shot in Google Maps… even two shots, and it won’t fit.
In June of 1987, Quantum Software Systems ceased renting their office space, and they moved into a building they’d had built just for them. Following this, the company would expand the building three times, and finally add another building. So, the company moved from 215 Stafford Road to 175 Terrance Mathews Crescent.
As late as 1990, QNX advertisements still mentioned performance on the 80286. This seems more as though Quantum didn’t spend much on marketing rather than not having progressed. In Dan Hildebrand’s An Architectural Overview of QNX from April of 1992, we find that the company had developed QNX versions up to 3.15, and articles about operating systems in the tech press had mentioned QNX as one of the systems that took advantage of features in the 80386.
QNX 4 demo floppy
QNX 4 demo floppy, menu and license
QNX demo floppy with applications
QNX demo floppy, showing the file browser
In 1989, Quantum Software Systems began work on a dramatic overhaul of the operating system. This new version would be fully POSIX-compliant and increase performance over the prior generation of QNX operating systems. This version, 4.0, was released in 1991. The kernel now had just 14 calls associated with IPC, network, scheduling, and interrupts, and the kernel weighed in at just 7K (605 LOC), allowing the entire kernel to fit in CPU caches of the time. Unlike earlier versions, messages were no longer queued. Instead, they were copied from process to process. Being POSIX-compliant allowed for the easier porting of software, and it also meant that the directory hierarchy was decidedly more familiar to UNIX veterans. Beyond source compatibility, Quantum was actively working on becoming binary compatible with UNIX as of 1992. In 1994, beyond POSIX and performance, QNX 4.1 introduced the QNX Photon microGUI. This system was developed by Patrick Hayden and Robin Burgener. Much like the underlying system, it was built around a microkernel (around 20K), and it was network transparent. A Photon application could have its interface beamed to another QNX 4 machine at any point in time, or it could be dragged from one device to another just as easily. Photon likewise allowed remote monitoring or control of the user interface. This worked regardless of the device class (desktop, laptop, handheld, server). For those who needed it, the X Windows System (X11R5, Motif Window Manager) was also available, though Photon did implement a binary interface library that was X compatible. Being so lightweight allowed the company to release a demo disk that combined networking, a web browser, web server, graphical environment, file manager, text editor, a vector animation demo, and Towers of Hanoi game onto a single 1.44MB floppy. Unlike prior QNX versions, version 4 required at least an Intel 80386 and VGA graphics card. No 16bit systems were supported.
KANATA, ONTARIO, September, 1994—QNX Software Systems Ltd., developers of the QNX realtime operating system, announced a unique window system targeted for handheld and embedded applications.
According to Rob Oakley, Corporate Communications and Product Management, "the Photon Window System is the first of its kind—a GUI built around a graphical microkernel."
QNX Software Systems designed the Photon Window System as a graphical microkernel and a team of cooperating processes, basing this design on the company's QNX OS, a microkernel network-distributed system.
Photon's cooperating processes provide the functionality to scale the system up into a full-featured windowing system or down to fit into resource-constrained environments, like handheld personal computers (HPCs) and compact embedded systems.
Photon provides a rich widget library that operates much like the X Window System widget set, with an X-inspired API. A Motif-like window manager and a code-generating, visual application builder are also available.
"Photon is extremely light and fast. It runs in only 256K, yet provides enormous GUI functionality," Oakley said.
Like the QNX OS itself, Photon is network transparent—an HPC running Photon and QNX, equipped with a wireless LAN interface, becomes a transparent extension of the LAN, able to use all the LAN's resources as if they were integrated directly into the HPC. The power this brings to the HPC user is difficult to appreciate—imagine having the power of 100 Pentiums in the palm of your hand!
According to Dan Dodge, Vice President R&D, "Photon applications are very network distributed. From the application's perspective, all the resources of all the nodes on the LAN look like a single, logical machine. The environment is so transparent that a user can drag applications from one physical screen to another."
For example, a user in a factory control environment could walk up to a computer and drag an application from the control screen onto an HPC, and then walk out onto the factory floor with it and interact with the live application.
Although Photon is aimed at compact environments, its dynamic range is extensive. "Photon's API and rich widget library can support high-performance GUI applications with enough functionality to enter the domain of X, while consuming only a fraction of the resources," said Dodge.
The QNX operating system is a POSIX-certified realtime OS for Intel and AMD processors. Scalable and modular, QNX fits a wide range of environments, from compact embedded controllers to resource-rich X-based development systems, to distributed realtime systems running hundreds of CPUs.
Versions 4.2, 4.22, and 4.24 all released in 1995. The final version 4 release was 4.25 in 1997. At least one QNX 4 installation ran for over 20 years without a reboot at the ESA. This was possible because peripherals could be hotswapped, drivers could be changed, and network nodes could be added or removed without bringing the system down.
Notably, we see that in 1994, Quantum renamed itself to QNX Software Systems Limited. And with a new name and a new version of their operating system, the company won some major installs. From POS systems at FasFax that allowed for real-time sales figures from geographically disparate locations, to video conferencing systems at Georgia State University, to factories, power plants, hospitals, set-top boxes, phone systems, trains, jets, the Space Shuttle, ISPs, and even traffic lights. The price for a single license dropped to around $285 at this time, and by 1995, QNX was the leading real-time OS for x86 systems. The majority of the company’s revenue was from large enterprises.
Of course, change was coming in the 1990s, and QSSL knew it. The company took the QNX kernel from version 4.24 and forked it. They had multiple goals with this fork. The system needed to be SMP capable, support POSIX, and be more portable to new hardware. The kernel handled only IPC, message passing, interrupts, and timing. Threading became the minimal unit of scheduling. The new Process Manager then used a loader thread that copied a process’s image into memory freeing the Manager to service other requests while a program continued to load. Naturally, being a real-time system, priority levels were used when scheduling any time-critical process, and new processes inherited the priority of their parent by default. The Process Manager weighed in at 32K (same size as the kernel itself) but added memory allocation, process contexts, resource-manager namespaces, and so on. In this new QNX version, the Process Manager ran inside the microkernel’s address space, but was the only element of the OS to do so. Much of the network stack for this version came from NetBSD, and with that came the ability to use NetBSD network drivers. There was another major change that came from the wider UNIX world, GCC. This naturally meant that language support was quite broadened to include not just C, C++ but all of the other languages supported by the GNU Compiler Collection. This became QNX Neutrino 1.0 released in 1996.
On the 19th of October in 1998, QSSL announced QNX Neutrino 2.0 which featured UPM (Universal Process Model). In the words of CTO Dan Dodge:
The premise of UPM is simple. Go beyond the limited MMU protection provided by the other major embedded OSs - where only applications are prevented from corrupting memory - and extend that protection down to services at the kernel level. The result? For the first time, MIPS and PowerPC-based embedded systems can intelligently recover from software faults in drivers, protocol stacks, and custom OS extensions - typically without rebooting.
QNX was branching into non x86 platforms, and this included PowerPC processors: 401, 403GC, 603e, 821, 823, 860; MIPS processors R4000 and R5000; and naturally all x86 CPUs from the 80386 onward. At this stage, however, the development environment was restricted to QNX 4 and Windows 95/98/NT.
This announcement was followed by another about a partnership with Amiga:
Cologne, Germany, November 13 - Amiga Inc. today announced a partnership with QNX Software Systems Ltd. to utilize the QNX realtime operating system (RTOS) as the foundation for the next-generation Amiga architecture. The announcement was made at Computer '98 in Cologne. "The Amiga shook the industry in the 80s with world-leading multimedia architecture," said Jeff Schindler, general manager of Amiga Inc. "QNX's RTOS resembles many of Amiga's unique qualities. It provides the foundation in reaching our vision for the rebirth of Amiga in the new millenium." "We see this partnership as a powerful combination of superior OS technologies, common corporate cultures, and shared business vision," said Dan Dodge, Chief Technology Officer and Cofounder of QNX Software Systems Ltd. About Amiga Amiga Inc. is a technology company targeting the next generation of Amiga architecture with a continued focus on multimedia and the Internet. Since the introduction of the Amiga A1000 in 1985, Amiga has represented the embodiment of the efficient use of memory and hard drive capacity, while pioneering industry developments in multimedia, 32-bit multitasking, and autoconfiguration. Amiga led the industry in combining computer graphics, animation, and film sequences with stereo sound known today as multimedia. Visit http://www.amiga.com and http://www.amiga.de. About QSSL Founded in 1980, QNX Software Systems is one of the top three realtime operating-system vendors in the world, with products licensed in more than a million systems worldwide. The company has established a strong customer base in a variety of industries, including aerospace, telecommunications, medical instrumentation, process control, point-of-sale, consumer electronics, finance, and telephony. With products distributed in over 100 countries, the company is headquartered in Ottawa, Canada.
The Amiga port should have been somewhat straightforward considering that Amiga accelerators had been using PowerPC chips, and those chips were now supported by QNX. Gateway’s Amiga team was working closely with QSSL to build a new Amiga (Amiga NG) around the PowerPC G3 and G4 chips running QNX, and these were apparently prototyped as single, dual, and quad processor machines. During alpha testing, Gateway PowerPC boards apparently had some issues, and the two parties blamed one another. By the middle of 1999, Gateway, QSSL, and to some extent Motorola, had poured a hefty sum into the project, and Gateway began insisting on a solid date for the availability of a QNX Neutrino port. Evidently they weren’t satisfied, and I do not believe communication between the two teams, which had one been quite good, was solid by this point. At noon on the 8th of July in 1999, Dan Dodge announced the QNX Developers Network for Amigans. This was followed by another announcement at 15:15 the following day:
Eight months ago we were chosen by Amiga as their foundation OS partner. Our development group was thrilled to be part of the rebirth of such an innovative product. To meet the challenge we knew it would take a tremendous effort on our part. We had a team of people in place working on our part of the Amiga NG soon after the alliance was announced. Over the next few months we involved more and more of our engineering resouces towards making QNX an advanced multi-media platform. Our investment so far has been significant. These are costs we have borne ourselves. It is clear today from Jim's letter that we were not chosen for the next generation Amiga. Naturally we're disappointed. So, where do we stand now? It is not our intent to confuse the Amiga community. We are proud of what we have accomplished and want to include Amigans in what we've achieved. I did make a promise to deliver an operating system and I intend on keeping that promise. I don't want to split the community, nor do I wish to engage in a war of words. I don't ask you to "trust" me or to take me at my word. Both QNX and Amiga have promised to deliver technology into your hands in the very near future. I ask only that your assessment of QNX be based on what we do and what we deliver. Thanks for the overwhelming support we have received so far.
That letter by Jim Collas read, in part:
Dear Amigans, After months of research and in-depth discussions with all of our technology partners we have decided to use Linux as the primary OS kernel for the new Amiga Operating Environment (OE). I know this decision is a shock to many of you given the previous announcements and activities relative to QNX. This was a very complicated and difficult decision to make and I assure you that I didn't make this decision without a significant amount of research and deliberation. We have been researching Linux since February but didn't finalized our decision until several weeks ago. We were planning to communicate it to the Amiga community in the technology brief that will be released in the next few days. I am pressed to communicate the Linux decision before the technology brief because of information released by QNX in the last few days. This information had not been reviewed or approved for release by Amiga. In light of our Linux decision, this information is confusing and misleading so I would like to take the time to clarify the situation. I can't disclose any details of the Amiga/QNX discussions because of legally binding confidentiality agreements but I can talk to you about our decision to use the Linux kernel. I think that you will agree that this is the right decision once you understand the reasons for this decision. Before I continue, I should mention that our technology decision does not reflect negatively on QNX. I believe that QNX is a good company with great technology. I just believe that Linux gives us a better chance of executing our plans successfully. The decision to use QNX as our OS partner on our next generation multimedia convergence computer (MCC) was made late last year. When I took over as president of Amiga in February of this year, I initiated an in-depth review of existing Amiga plans and decisions. As president of Amiga I had to make sure that we were defining a strategy and an execution plan that would allow Amiga and the Amiga community to be successful. We reviewed our strategy, architecture decisions, technology partners, and execution plans. During this review period we also added a number of very talented and experienced people to help us finalize our technology and product decisions. I am confident that we now have a solid and exciting plan that people can have confidence in. Linux has been picking up substantial momentum over the past year as a viable, open OS alternative in the marketplace. This momentum, the growing commitment to Linux applications from a wide variety of software vendors, and the growing availability of Linux device drivers from hardware vendors, makes it a compelling candidate. Additionally, with all of the significant component suppliers putting resources on writing drivers for Linux it was difficult to get them to port to yet another operating system. Using the Linux OS as a foundation for our Amiga OE allows us to leverage a significant amount of available software drivers and utilities. This allows us to quickly support multiple graphics cards and other peripherals. Given the above-mentioned advantages, we decided to do an in-depth technical analysis of Linux to determine if it was a suitable OS kernel for our new Amiga operating environment (OE). As we ported parts of our higher level operating environment and AmigaObject architecture to Linux, we discovered some significant performance advantages in the Linux kernel in areas such as distributed object messaging across a network (up to 10X the performance of Windows NT). Does this mean that the next generation Amiga will not be unique? Absolutely not! Remember that the OS kernel is only one component of the new Amiga OE and the hardware is unique. The revolutionary nature of the Amiga OE is in the way it extends the traditional operating system to provide a host environment for a new class of portable applications - applications that exist in a pervasive networked computing environment. We will be integrating multiple technologies including an efficient windowing environment and a unique user interface. In summary, we decided to use Linux because of the incredible momentum and the fact that it is solid technology and a good foundation for our new Amiga OE. Additionally, the Linux community is an impressive force that we should be aligned with. We share many common values and objectives with the Linux community. Using Linux as our OS kernel allows us to build a unique and revolutionary operating environment while leveraging the enormous momentum of Linux. The soon to be released technology brief will further explain our architecture and plans for integrating all of the selected technology. Once you read it, I am confident that you will understand the revolutionary nature of the next generation Amiga. I assure you that Amiga and the Amiga community will be a driving force behind the next computer
revolution.
As a person using Linux at the time, I believe this to have been the wrong decision. Despite the momentum that Linux had, it wasn’t (still isn’t) as stable, as reliable, or as efficient as QNX. If network performance were a serious consideration, one of the BSDs would have been the better choice. Linux’s hardware support also wasn’t that great in reality. While it could run on quite a bit of kit, it didn’t always support that hardware well, and it didn’t always support all features. Plus, QNX was doing the work to build drivers for the new Amiga. Of course, none of this really mattered. Gateway chose to divest itself of Amiga entirely. The new Amiga Inc. then turned to AmigaOne Partners for Amiga OS 4.
QNX Neutrino 2.1 was released in 1999 with support for Java, the Glide API, a wide array of microcontrollers, ARM, StrongARM, and Hitachi SH-4. Interestingly, this release had beta packages including RealPlayer and X in Photon, and it had experimental packages that included Quake 3 Arena and Doom.
On the 14th of September in 1999, QNX made an announcement that would shape the future of QNX. The company was partnering with Motorola to develop automobile driver information systems that included in-vehicle navigation, internet access, natural language processing, car audio, multimedia, and vehicle information dashboards. While the Motorola unit responsible for mobileGT wouldn’t last and the unit at IBM working on Java wouldn’t last, QNX would survive and thrive in that segment.
QNX 6.2.1
QNX 6.2.1 software installer
QNX 6.2.1 file manager
QNX 6.2.1 Voyager web browser
QNX version 6 was released on the 18th of January in 2001. The new version was focused on multimedia with streaming video and audio as well as hardware accelerated MPEG encode/decode. The new system included a web based package manager greatly easing the installation of available software. Thankfully, all supported architectures could now be used for developing QNX native software too. Version 6.1 was mostly a patch release and followed later the same year. QSSL was a founding member of the Eclipse Foundation, and QNX software development got quite a bit better with the release of the Momentics Tool Suite on the 4th of June in 2002 (along with QNX 6.2). This was largely the Eclipse IDE combined with a series of plugins that were QNX and Photon oriented.
Version 6.3 login
Version 6.3 with Mozilla
Version 6.3 with file manager & terminal emulator
The last release of QNX by QSSL was version 6.3 on the 3rd of June in 2004. This version was visually slightly different, and Voyager was replaced by the Mozilla Suite. The development environment was improved and now offered a clustering framework for the development of networked applications utilizing distributed processing. Among the highlights for this release were SCTP support, IP filter and NAT support, IPv6 support, 2D and 3D graphics layering/compositing, full UTF8 support in Photon, USB2 host support, and support for up to 64GB of RAM on x86 and PPC, up to 1TB on MIPS.
On the 27th of October in 2004, QNX Software Systems Limited was purchased by Harman International Industries. Harman specifically wanted to focus on QNX Neutrino in the embedded market, and within that market, specifically on automotive applications where Harman had found a market in audio. Under Harman’s ownership, QNX operated as a separate division led by Dan Dodge as CEO. While QNX did continue to serve networking, medical, and industrial markets, the direction was clear. What had begun with the Motorola partnership in automotive would become the primary market.
QNX CAR circa 2009
A different QNX CAR interface from 2009
QNX CAR concept hardware, image from Paul Leroux
QNX development continued with 6.3 SP1, SP2, and SP3. Version 6.3.2 was released on the 16th of August in 2006, 6.4 on the 30th of October in 2008, and 6.4.1 in May of 2009. Throughout that time period, QNX had introduced support for Adobe Flash and developed the QNX CAR platform winning a trophy from Adobe for their efforts. This platform was built of modular components allowing manufacturers to mix and match based upon the market segment. QNX was chosen by companies like BMW, Mercedes, Dodge, Toyota, Volkswagen, and Audi. When QNX demoed their automotive systems in the 2007-2009 timeframe, they had concept dashboards. These all ran QNX Neutrino on ARM CPUs (often Freescale i.MX6 or TI Sitara [Cortex A8]) with the EtherCAT motion library, and many demo units had UIs created in Qt5 and QML while a few had hardware accelerated OpenGL interfaces. From 2008 to 2010, QNX had been licensed for use in more than 17 million in-vehicle systems representing an increase of around 130% over those two years. By March of 2010, more than 200 vehicles were already shipping with QNX, and the QNX CAR platform had more than 60 participants. Those participants included 17 auto makers and 26 automotive suppliers.
On the 9th of April in 2010, Research in Motion announced their acquisition of QSS from Harman for $200 million:
“RIM is excited about the planned acquisition of QNX Software Systems and we look forward to ongoing collaboration between Harman, QNX and RIM to further integrate and enhance the user experience between smartphones and in-vehicle audio and infotainment systems," said Mike Lazaridis, President and Co-CEO at RIM. "In addition to our interests in expanding the opportunities for QNX in the automotive sector and other markets, we believe the planned acquisition of QNX will also bring other value to RIM in terms of supporting certain unannounced product plans for intelligent peripherals, adding valuable intellectual property to RIM's portfolio and providing long-term synergies for the companies based on the significant and complementary OS expertise that exists within the RIM and QNX teams today." "We welcome the opportunities that a strengthened relationship with RIM will create, as two innovation leaders collaborate to bring new connectivity solutions to the industry," said Dinesh C. Paliwal, Harman's Chairman, President and CEO. "We expect to maintain our close association with QNX and the cutting-edge software solutions it provides to Harman and our customers. We believe our leading customers will fully endorse this move and see it as a major step in advancing seamless connectivity and integration among intelligent devices." "Like Harman, RIM shares our passion for innovation and reliability, so we are absolutely thrilled with this opportunity," said Dan Dodge, CEO, QNX Software Systems. "Moreover, RIM will give us the best of all possible mandates: to continue on our innovation path and to increase investment in our core products, professional services, and go-to-market channels. This is a great time to be a QNX customer, as we focus on collaborating with RIM to create an even more exciting platform for the next generation of connected and embedded devices."
Also in 2010, QNX gained the QNX Safety kernel variant. This was a version of Neutrino that was security hardened specifically for mission critical applications. This variant continues to this day with the most recent version (8.0) having been independently certified by TÜV Rheinland to meet several standards including ISO 26262 ASIL D, IEC 61508 SIL3, IEC 62304 Class C, and ISO/SAE 21434. Aside from security hardening, the QNX Safety variant is still fully compatible with Neutrino’s native APIs and POSIX.
QNX Neutrino 6.5
In July of 2010, QNX Neutrino 6.5 was released. This version brought performance improvements to the kernel when systems were seeing high memory utilization, the kernel gained zombie reaping, and it gained address space randomization. SMP support was increased, and CPU support was extended to ARMv7 Cortex A-9. The Photon microGUI saw some refinements. As one would expect, version updates were present for everything imported from BSD, Linux, and GNU. This version could make use of the NetBSD’s Pkgsrc tool.
BlackBerry PlayBook home screen
BlackBerry PlayBook app switcher
Version 6.5 was forked to create both the BlackBerry Tablet OS and BBX shortly after its creation. The first device to see a QNX-derived operating system from RIM was the PlayBook, which featured an OMAP 4430 SoC (1.5 GHz dual-core A9), PowerVR SGX540 GPU, 1GB of RAM, 16GB of eMMC flash, a 1024 by 600 seven inch LCD, Bluetooth, 802.11n, USB2, micro HDMI, a 5MP rear camera, and a 3MP front camera. It measured 5.1 inches by 7.6 inches, was about 2/5 of inch thick, and it weighed just under a pound.
BlackBerry Playbook, images from pcper
The PlayBook was released on the 19th of April in 2011 to mixed reviews. While many loved the webkit browser, user interface, HDMI output, and multitasking, many loathed the requirement of a BlackBerry to get certain apps working. Additionally, there was a dearth of third party applications. This latter complaint did get ameliorated. While at launch there weren’t too many applications, this grew to over 24,000 by the same time the following year. Around 2,465,000 PlayBooks had been sold by June of 2013.
BlackBerry Z10, images from CNET, by Josh Miller
The BlackBerry Z10 was released on the 31st of January in 2013 running BBX (officially BlackBerry 10 due to a trademark dispute, and at the launch event for BBX, Research in Motion announced that they were changing their name to BlackBerry Limited). The Z10 was built around a Qualcomm Snapdragon S4 Plus SoC (dual core 1.5GHz Krait CPU, Adreno 225 GPU) for LTE units, or around the TI OMAP 4470 for non-LTE units. The shell was plastic wrapped around a stainless steel inner frame, and the on/off, voice command, and volume buttons on the right side were of metal. While it didn’t have quite the premium feel of an iPhone, it did feel good in the hand. In its dimensions it was 5.1 inches by 2.6 inches, and just over an 1/3 of an inch thick (or just slightly larger than an iPhone 5). It was a slick piece of kit with a high price for the time at $599. The display, however, was excellent. It was a 4.2 inch LCD with a resolution of 1280 by 768 at 355ppi (the iPhone 5 was 326ppi). The device had a 2MP font camera, and an 8MP rear camera capable of HDR, panorama, and 1080p video at 30fps. Wi-Fi was dual band 802.11n, and the device featured Bluetooth, GPS, and NFC. Of course, connectivity didn’t stop there. This device had physical ports: micro USB2, micro HDMI, and 3.5mm audio.
BBX made heavy use of gestures with a swipe up from the bottom taking the user to the Home Screen, a swipe to right to hit the App Library, and a swipe to the left going to the BlackBerry Hub. The Hub was a combination of SMS/MMS, email, social media, chat, notifications, and calls in a single unified location. BBX was QNX Neutrino, but it did differ. Multitasking was limited to 8 applications at any one time which I believe to have been done due to the application frameworks. A developer could choose to use C/C++ and the Cascades UI framework, or WebWorks which utilized HTML5 with Zepto.js (JQuery API, but 8.4k compressed), or WebKit, or Adobe AIR (Flash), or Android runtime. With so many different application types, decisions would have had to have been made around resource management, and a best guess at when performance would become unacceptable.
BlackBerry had been unable to compete against the iPhone and Android, and BBX was their last, best hope. By 2014, BBX was in the number four spot behind Windows Phone. By 2017, it was clear that they weren’t going to survive in the mobile market. Due to the extreme devotion of their fans, they kept BBX on life support until 2022. Being an amazing OS running on good hardware, why did BBX fail? Likely, the most pressing problem was application support. While BBX could run some Android applications, support was limited. The platform likewise failed to grab many developers as the existing install bases for iOS and Android were enormous. What applications were made for BBX were often of quite low effort. Finally, moving to a touch screen angered BlackBerry’s existing fanbase. For those individuals hanging on to the BlackBerry ecosystem, the keyboard was one of the main reasons why. Removing the physical keyboard made many of those fans feel betrayed. When BlackBerry Limited did release another phone with a physical keyboard, it was a bit too late.
On the 20th of September in 2013, BlackBerry Limited announced a 4500 person staff reduction and $1 billion (CAD) loss. On the 23rd, they announced an acquisition by Fairfax Financial Holdings for $9/share. This deal was canceled in November. Instead, John Chen became CEO and initiated a turn around that focused on QNX’s former markets of healthcare, finance, law, and mission critical systems. This focus allowed the company to pick up Ford Motor Company as a QNX customer on the 11th of December in 2014 (Ford had previously used Microsoft Auto).
On the 28th of February in 2014, BlackBerry released QNX 6.6. The supported platforms were now the expected x86 and ARM CPUs with no mention of any others. This was a major change despite being a point release. Photon support was removed in favor of the Screen Graphics Subsystem. Screen operates as a lower-level service, and this has the benefit of supporting off-screen rendering and compositing of various image sources, and as QNX software had been increasingly using Qt, HTML5, or OpenGL rather than the toolkits supplied with Photon, this made logical sense.
QNX version 7 was released on the 4th of January in 2017 for ARM v7, ARM v8, x86, and AMD64. This release featured a rewritten PCI server with APIs moved out of libc and into libpci, rewritten virtual memory manager, fewer synchronization objects with increased limits, and filesystem encryption was moved into the Encrypted Filesystem package available from QNX Software Centry.
By June of 2023, QNX was in over 255 million vehicles around the world, and this would explain why the BlackBerry blog featured a rather large section on automobiles:
The automotive evolution to SDVs and “connected cars” requires an OS capable of speed, safety, and security — while unlocking the power to innovate. "With more than 300 million vehicles capable of over-the-air software updates expected to be on the road globally by 2032, automakers are clamoring for better tools to help them develop compelling technology features in the software-defined vehicle," says Alex Oyler, director of North America at SBD Automotive, a leading global automotive technology research and consulting firm. “Both automakers and suppliers rely on validated software and well-integrated development tools to help them more efficiently build and maintain differentiating software for their fleets,” Oyler adds. "A secured-by-design operating system such as the next generation QNX OS — that seamlessly integrates with other software components on a high-performance system-on-chip — represents the foundation of a safe, secure, and seamless experience for drivers.” In addition, early reviews of the new QNX SDP 8.0 give automotive industry leaders a glimpse into what’s possible. “The combination of our DRIVE Thor centralized computer and the new QNX OS will serve as a powerful foundation on which OEMs can build next-generation automotive systems that offer the highest levels of safety and security,” says Ali Kani, vice president and general manager of automotive at NVIDIA. “This represents another major milestone in a nearly 20-year collaboration with BlackBerry QNX that has helped both companies move to the forefront of the automotive industry.”
QNX 8.0 was officially announced in December of 2023, and the release was made in January of 2024. Version 8.0 was quickly discontinued with 8.0.1 taking its place. Version 8.0.3 was made available on the 21st of March in 2024. This latest release is available for a variety of Aarch64 platforms including the Raspberry Pi, and is also available for AMD64. QNX 8 supports SoCs with up to 64 cores and has near linear performance scaling. The network stack is now based upon FreeBSD 13.2, Wi-Fi 6 support is present with WPA3 and TLS 1.3, Screen can operate fully headless and now supports Vulkan 1.3 and OpenCL 3, and Screen now supports Wayland 1.21. Developers are now encouraged to use LLVM and libc++ 16 though GCC is still available with libstdc++ 12.2. Python 3.11, valgrind, libasan (address sanitizer), libubsan (undefined behavior detection), and libunwind are all available. For the UNIX user land, Toybox has replaced many common GNU utilities.
If the Raspberry Pi port caught your attention, this is available free for non-commercial use via QNX Everywhere. The image requires a Raspberry Pi 4 with at least 2GB of RAM and an 8GB or greater MicroSD card.
On the 2nd of January in 2025, it was announced that BlackBerry IoT would now be known as QNX. This decision was made largely by BlackBerry responding to their customers who recognized and desired the QNX brand. QNX CEO John Giamatteo stated:
Relaunching the QNX brand is an important step in BlackBerry’s broader strategy to increase our visibility and fortify our leadership within the automotive and embedded industries, with a view to better positioning us for sustained growth and success. The values that QNX stands for have always been a cornerstone for our customers and this brand relaunch honors that strong history while setting the stage for the division to fire on all cylinders and drive smarter, safer, and faster innovation through precision-engineered performance.
QNX is a fascinating operating system. It was extremely well designed from the start, and while it has been rewritten, the core ideas that allowed it survive for 45 years persist to this day. While I am sad that Photon was deprecated, the reasoning is sound. Most vendors using QNX either do not require a GUI, or they implement their own. For example, while Boston Dynamics uses QNX in their robots, they don’t really need Photon, and neither do SpaceX’s Falcon rockets. While cars certainly have displays, most vehicle makers desire their screen interfaces to have a unique look and feel. Of course, just stating these use cases of robots, rockets, and cars speaks to the incredible reliability and versatility of QNX. Better operating systems are possible, and QNX proves it.
My dear readers, many of you worked at, ran, or even founded the companies I cover here on ARF, and some of you were present at those companies for the time periods I cover. A few of you have been mentioned by name. All corrections to the record are sincerely welcome, and I would love any additional insights, corrections, or feedback. Please feel free to leave a comment.