Previously, Norton Allen wrote in qdn.public.qnxrtp.os:
Having downloaded the latest updates and run uname, I’ll
repeat my question or observation of October 6:
Between QNX4 and QNX6, there appears to have been a reversal
of the definition of uname -v and uname -r:
QNX4.24G QNX6.00
uname -r G 6.00
uname -v 424 2000/10/17-14:59:25edt
Was this change intentional? A quick survey suggests the
new definition is more in line with, say, Linux. Is there
any intention to alter the function of uname under QNX4?
Yes this change was intentional. Here is a copy of the offical
statement that we made on this. This was released sometime
around Nov I think.
There has been much talk and confusion about the QNX naming
of products. This is a description of how our products are
named and how that applies to programmers.
The operating system has always been called QNX. The first
popular version we refer to as QNX2. The next version we
refer to as QNX4. They include the micro-kernel, filesystems
and device drivers. When we started working on the next
generation operating system, we code named the micro-kernel
“Neutrino”. We sold it only as a cross development product
and it was targeted mainly as embedded devices, not as a
desktop operating system like QNX2 or QNX4. This version was
internally called QNX5 but because it was not yet ready for
desktop use it started to be called by the kernel code name
and became “Neutrino 1.00”. Version 2.00 added support for
multiple processor vendors, but was still targeted at cross
development. With version 2.10 we now have enough support to
have a desktop operating system like QNX2 and QNX4, so its
name is QNX6. QNX6 is “Neutrino” plus our graphical user
interface (GUI) “Photon”. “Neutrino” refers to the kernel
and device drivers part of QNX6 and Photon refers to the
GUI.
When we decided to make QNX6 available for download, we
wanted make a complete developers system available so we
packaged our development tools (which we will be giving a
nifty code name to) and ported lots of useful programs. We
make all these available for download, and refer to the
collection as the Real Time Platform (RTP).
If you look at what is installed in the RTP with the package
installer (or Package Mgr) the “Core Repository” is QNX6. It
consists of version 2.00 of “Photon” and version 2.10 of
“Neutrino”.
For QNX6 we made the uname function and utility report values
that are more consistent to traditional unixs. QNX4 reported
values that where correct, but not as compatible to unixs.
Here are some examples:
-m -n -r -s -v -p
nto2.0 x86pc localhost 2.00 procnto* (date) x86
nto2.1 x86pc localhost 6.00 QNX (date) x86
nto2.1 sandpoint localhost 6.00 QNX (date) ppcbe
nto2.1 AMDSC400 localhost 6.00 QNX (date) x86
nto2.1 DBB-VRC4373 localhost 6.00 QNX (date) mipsbe
sun(sunos) sun4* localhost 4.2 SunOS Generic m68k???
sun(bsd) sun4* localhost 1.4??? NetBSD (date)(url)??? m68k???
solaris5 sun4m localhost 5.5 SunOS Generic sparc
solaris6 i86pc localhost 5.6 SunOS Generic_(date) i386
solaris6 sun4u localhost 5.6 SunOS Gerneric_(date) sparc
solaris8 i86pc localhost 5.8 SunOS Generic i386
linux i586 localhost 2.2.12-20 Linux (date) unknown
NetBSD i386 localhost 1.4 NetBSD (date)(url) i386
sgi sgi localhost ??? OpenBSD ??? ???
QNX4 PCI 1 I QNX 425 N/A
OSF alpha localhost V4.0 OSF1 ??? ???
The value from “uname -s” refers to the operating system
which we identify as “QNX”. This differentiates us from other
operating systems except for QNX4. For QNX4 the revision is
used. QNX4 uses letters for revision where QNX6 uses the
more traditional numbers for revision. A simple shell script
to use is:
case $(uname -sr) in
procnto*|QNX\ [0123456789]*)
echo QNX6;;
QNX\ *)
echo QNX4;;
esac
Many packages that are ported use “./configure” scripts that
try to determine the operating environment they are executed
in. They use a shell script called “./config.guess” to do
this. We have modified it with a test similar to the above
and submitted it to the “configure” maintainers so QNX will
be correctly identified. But even if you have a package with
older “./configure” scripts, you can generate a new one with
two utility programs called “automake” and “autoconf”. We
have made these packages available in the RTP so if you want
to port an application and it doesn’t have current configure
scripts, you can update them my using “automake”, then
“autoconf”, then using the new “./configure” that got
generated.
When we started with the “Neutrino” kernel we were planning
to keep the full operating system called QNX. Therefore for
programs we always defined “QNX”. For “Neutrino”
programs we also defined “QNXNTO”. This a decision
that has caused grief to people porting code, but we have it
now so we need to rationalize it 
. The main problem is
for porting code to both QNX4 and QNX6. The #ifdefs need to
be something like:
#ifdef QNX
// This is for QNX4 and QNX6 operating systems
#ifdef QNXNTO
// This is specific to QNX6
#else
// This is specific to QNX4
#endif
#endif
or
#if defined(QNX) && !defined(QNXNTO)
// This is specific to QNX4
#endif
So when you get some code that is ported to QNX4, you should
“grep QNX *” and examine the code to see if it should be
different for QNX6 or maybe not needed at all as QNX6 more
closely matches traditional unix semantics. Then modify the
#ifdef’s as nessessary.
If you are writing code for different versions of neutrino
you can use “_NTO_VERSION” for version specific
dependencies.
#if _NTO_VERSION+0 >= 600
// QNX6
#elif _NTO_VERSION+0 >= 200
// Neutrino 2
#elif _NTO_VERSION+0 >= 100
// Neutrino 1
#else
// Not Neutrino
#endif
I hope this helps explain our naming conventions, both the
history and how to work with what we have now. We will not be
changing the current #defines or uname output as there is
already alot of code that uses them the way they are.
Sorry for any grief it may cause, but please work with us to
get this message across and in converting programs to use the
current defines and uname output.