Improvements

Now that you've seen what's the same about the two generations of OS, let's look at where QNX Neutrino has improved functionality over QNX 4:

more POSIX standards supported
more embeddable
kernel is more readily customizable for a variety of hardware platforms
thread support
simpler device driver model
portable architecture; currently supports ARM processors as well as x86
supports SMP
more documentation

While some of these improvements are “free,” meaning that there are no compatibility issues (for example, POSIX pthreads weren't supported under QNX 4), some things did require fundamental changes. I'll briefly mention the classes of changes that were required, and then we'll look in detail at the compatibility issues caused as well as suggestions on how to port to QNX Neutrino (or keep your code portable between the two).

Embeddability
QNX Neutrino totally redesigned the way that the operating system was embedded. Under QNX 4, in the original release, it was marginally embeddable. Then QNX Neutrino came along, designed to be embeddable. As a bonus, QNX 4 underwent some changes as a result of the experience gained in QNX Neutrino, and now QNX 4 is vastly more embeddable than it had been. In any event, embedding QNX 4 versus embedding QNX Neutrino is almost like night and day. QNX 4 has no real support for things like:
Thread support
QNX 4 had a function called tfork() that let you use “threads” by creating a process with its code and data segments mapped to the same memory locations as the creating process. This gave the illusion of a thread by creating a process, and then changing the characteristics of the newly created process to make it look like a thread. While there is a thread library available for QNX 4 on QNX Software Systems' update system, the kernel itself doesn't support threads directly.
Message passing
While the impact of threads on message passing may seem minimal, it resulted in a fundamental change to the way message passing was done (not to the fundamental concepts of message passing, like SEND/RECEIVE/REPLY, but to the implementation).
Device driver model
Under the previous-previous version of the operating system (the QNX 2 family), writing device drivers was an arcane black art. Under QNX 4, it was initially a mystery, but then eventually some samples appeared. Under QNX Neutrino, there are books and courses on the topic. As it turns out, the QNX Neutrino model and the QNX 4 model are, at the highest architectural level, reasonably similar. Whereas QNX 4 had somewhat muddled concepts of what needed to be done as a “connect” function, and what needed to be done as an “I/O” function, QNX Neutrino has a very clear separation. Also, under QNX 4, you (the device driver writer) were responsible for most of the work—you'd supply the main message handling loop, you'd have to associate context on each I/O message, and so on. QNX Neutrino has simplified this greatly with the resource manager library.
ARM support
One of the driving changes behind the embeddability differences between QNX 4 and QNX Neutrino is the fact that QNX Neutrino supports ARM processors. Whereas QNX 4 was initially “at home” on an IBM PC with a BIOS and very standard hardware, QNX Neutrino is equally at home on multiple processor platforms with or without a BIOS (or ROM monitor), and with customized hardware chosen by the manufacturer (often, it would appear, without regard for the requirements of the OS). This means that the microkernel had to have provision for callouts, so you could, for example, decide what kind of interrupt controller hardware you had, and, without having to buy a source license for the operating system, run on that hardware.
SMP support
Released versions of QNX 4 are strictly single-processor, whereas QNX Neutrino has support for SMP.

Related concepts

System Architecture