![[Previous]](prev.gif) |
![[Contents]](contents.gif) |
![[Next]](next.gif) |
|
|
|
 |
This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs. |
Architecturally, QNX Neutrino is the same as QNX 4. It provides an open-systems POSIX API in a robust scalable form suitable for a wide range of solutions -- from tiny resource-constrained systems to high-end distributed computing environments.
One big difference between QNX 4 and QNX Neutrino is that the new OS runs on a number of different processors -- x86, ARM, MIPS, PowerPC, and SH4. Assuming that you didn't use any processor-specific tricks, a program written for QNX Neutrino on an x86 could be recompiled and relinked so that it will also run on a Power PC machine.
QNX Neutrino can also run on a multi-processor machine. This machine might have 4 Gbytes of physical memory managed by a number of processors.
QNX Neutrino was also designed to be even more portable than QNX 4. The new OS contains newer POSIX components (e.g. POSIX threads). New functions from the Unix 98 standard and from other sources have been added.
Migrating files from a QNX 4 system to a QNX Neutrino system isn't complicated for this simple reason: they use the same filesystem. If you're going to run QNX Neutrino on a PC with a QNX 4 filesystem, then all the files in the QNX 4 partition or disk are accessed exactly the same as they were before.
In fact, you could replace your /.boot or /.altboot file with a QNX Neutrino bootable image and reboot into the new QNX Neutrino OS.
Many developers may want to have their QNX Neutrino target machine act as an NFS or CIFS client; this is certainly possible.
Using this scheme, you can set up a QNX 4 development system and a QNX Neutrino target system that has access to the QNX 4 files. With two machines side-by-side, a typical development cycle becomes:
 |
Run. |
|
|
|