We’re looking for a development environment and OS for an embedded
application, and QNX and VxWorks are both candidates at this point. I’d
be curious if anyone here who knows VxWorks would be so kind as to
contrast it with QNX.
best regards,
Nick Caruso
Unicore Technologies
Previously, nick caruso wrote in comp.os.qnx:
We’re looking for a development environment and OS for an embedded
application, and QNX and VxWorks are both candidates at this point. I’d
be curious if anyone here who knows VxWorks would be so kind as to
contrast it with QNX.best regards,
Nick Caruso
Unicore Technologies
Heh heh heh…
Ok, first I should say that my knowledge of VxWorks is over a year old, and I dropped out of class after the first day…
We (IFS) were at the same crossroads. Our requirements were: high reliability, minimal footprint, full MMU support, flash file system, x86, and gui development tools. We had narrowed our choices down to VxWorks and QNX 4.
Here’s the comparison
Footprint:
VxWorks fits into 40-50k. QNX is heftier (our .boot file is about 500k). QNX is smaller than Linux, but bigger than OS-9.
CPU:
VxWorks runs on practically everything. QNX 4 only runs on x86 (but QNX 6 supports PowerPC, MIPS, and maybe ARM).
MMU:
VxWorks had an optional component (i.e., you pay extra for it) that lets the programmer MANUALLY set protected regions in memory. QNX does virtual memory “as God intended” - each process lives in it’s own protected, virtual address space. QNX is POSIX, so it handles memory just like Linux, Solaris, etc., except that it doesn’t have a swap file. BTW, VxWorks doesn’t have real processes like QNX. What they call tasks are really threads. You don’t even get to write your own main()… your code gets compiled in with everything else - one big, happy namespace!
FFS:
VxWorks had a flash file system as a third party option. QNX has one-stop shopping.
GUI:
VxWorks had Zinc (a GUI library) and an HTML-based UI tool. QNX has Photon (think of it as a light-weight form of X Windows) and Phab (an integrated GUI application builder). Phab has definitely saved us some time.
Reliability:
Presumably, the VxWorks executive is flawless since there’s not much to it. QNX 4 is pretty solid, but hiccups do happen. QSSL has to support a tremendous variety of PC hardware, as well as a GUI, a web browser, etc. Still, I haven’t seen anything that would make me question our decision to go with QNX.
Cost:
Licensing costs per unit were very similar. The cost of development tools, however, was quite different. 2 VxWorks seats cost approximately $40K; 2 QNX seats (including 1 Phab seat) cost about $8K. Also, Wind River charges a “per project” fee - if you use the development tools for another project/product, you have to pay them a percentage of the original tool cost. They also have a yearly maintenance fee.
My advice:
If you’re going to be cranking out a million widgets per year at $50 per widget, and if each widget only has to do 1 thing (like control a CD player), VxWorks may be the way to go. Otherwise, I’d recommend QNX.
… or embedded Linux. 
DISCLAIMER: All of the above is my opinion ONLY. My employer is not responsible.
“Pete D.” <peted@NOSPAM.ifspurity.com> wrote in message
news:Voyager.010321130916.165B@node1…
(adding my $0.02 to Petes)
MMU:
VxWorks had an optional component (i.e., you pay extra for it) that
lets the programmer MANUALLY set protected regions in memory. QNX does
virtual memory “as God intended” - each process lives in it’s own protected,
virtual address space. QNX is POSIX, so it handles memory just like Linux,
Solaris, etc., except that it doesn’t have a swap file. BTW, VxWorks
doesn’t have real processes like QNX. What they call tasks are really
threads. You don’t even get to write your own main()… your code gets
compiled in with everything else - one big, happy namespace!
Not such a happy namespace as I recall. One programmer where I worked would
have a namespace collision with something in the VxWorks library every
couple of days or so.
GUI:
VxWorks had Zinc (a GUI library) and an HTML-based UI tool. QNX has
Photon (think of it as a light-weight form of X Windows) and Phab (an
integrated GUI application builder). Phab has definitely saved us some
time.
Zinc is not only not in the same ballpark as Photon; it’s playing cricket.
Reliability:
Presumably, the VxWorks executive is flawless since there’s not much to
it. QNX 4 is pretty solid, but hiccups do happen. QSSL has to support a
tremendous variety of PC hardware, as well as a GUI, a web browser, etc.
Still, I haven’t seen anything that would make me question our decision to
go with QNX.
The executive in VxWorks is very stable. The QNX microkernel is just as
stable. All the other extra stuff (which is infinately stable from VxWorks
cuz they don’t have it) is somewhat less stable, but probably a lot better
than the stuff you would write yourself under VxWorks (cuz they don’t have
it), and cheaper than the stuff you might be able to buy from a third party.
Cost:
Licensing costs per unit were very similar. The cost of development
tools, however, was quite different. 2 VxWorks seats cost approximately
$40K; 2 QNX seats (including 1 Phab seat) cost about $8K. Also, Wind River
charges a “per project” fee - if you use the development tools for another
project/product, you have to pay them a percentage of the original tool
cost. They also have a yearly maintenance fee.
Yup.
My advice:
If you’re going to be cranking out a million widgets per year at $50
per widget, and if each widget only has to do 1 thing (like control a CD
player), VxWorks may be the way to go. Otherwise, I’d recommend QNX.
Bang on.
… or embedded Linux. >
If you don’t have hard realtime constraints, and you have a bunch of Linux
heads (with Linux you “just have to know” a lot of stuff - if you know it
then great, if not it’ll cost you).
Rennie
Previously, John Doe wrote in comp.os.qnx:
“Pete D.” <> peted@NOSPAM.ifspurity.com> > wrote in message
news:Voyager.010321130916.165B@node1…(adding my $0.02 to Petes)
MMU:
VxWorks had an optional component (i.e., you pay extra for it) that
lets the programmer MANUALLY set protected regions in memory. QNX does
virtual memory “as God intended” - each process lives in it’s own protected,
virtual address space. QNX is POSIX, so it handles memory just like Linux,
Solaris, etc., except that it doesn’t have a swap file. BTW, VxWorks
doesn’t have real processes like QNX. What they call tasks are really
threads. You don’t even get to write your own main()… your code gets
compiled in with everything else - one big, happy namespace!Not such a happy namespace as I recall. One programmer where I worked would
have a namespace collision with something in the VxWorks library every
couple of days or so.
What I found really scary is the add-on components. The Wind River salesguy bragged about having TCP/IP, a web server, etc. that can be added to the user’s application at a later date. I can’t imagine the nightmare of having to run around renaming identifiers in solid, working code just to add communications to my product. And how do you coordinate multiple developers?
With QNX, I was able to add Kermit support by just downloading the G-Kermit source and compiling…
My advice:
If you’re going to be cranking out a million widgets per year at $50
per widget, and if each widget only has to do 1 thing (like control a CD
player), VxWorks may be the way to go. Otherwise, I’d recommend QNX.Bang on.
… or embedded Linux. >
If you don’t have hard realtime constraints, and you have a bunch of Linux
heads (with Linux you “just have to know” a lot of stuff - if you know it
then great, if not it’ll cost you).Rennie
I should have added that my application is soft realtime. I don’t know if there are differences in response time between VxWorks and QNX.
“Pete D.” <peted@NOSPAM.ifspurity.com> wrote in message
news:Voyager.010321200434.2973A@node1…
I should have added that my application is soft realtime. I don’t know
if there are differences in response time between VxWorks and QNX.
Well, what I was comparing was QNX4 to VxWorks on Intel. They were almost
the same on context switch (except for the fact QNX was going from process
to process and VxWorks was going thread to thread 
. This might sound
surprising, but remember QNX4 is totally x86 optimized while VxWorks is
multi-platform. I haven’t tested VxWorks vs Neutrino thread-to-thread, this
would be a more appropriate match (same class of context switch, both are
multiplatform). I wouldn’t get hung up on this, if QNX is fast enough for
the app, use it because you get a lot more goodies, if it isn’t fast enough
then it isn’t an option.
Rennie
What about OS 9 isn’t it more reliable, flexible?
What about making device drivers under VxWorks or QNX or OS 9 wchic
system is easier?
nick caruso wrote:
We’re looking for a development environment and OS for an embedded
application, and QNX and VxWorks are both candidates at this point. I’d
be curious if anyone here who knows VxWorks would be so kind as to
contrast it with QNX.best regards,
Nick Caruso
Unicore Technologies
The contents of this message express only the sender’s opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
Previously, FIRSTNAME LASTNAME wrote in comp.os.qnx:
What about OS 9 isn’t it more reliable, flexible?
What about making device drivers under VxWorks or QNX or OS 9 wchic
system is easier?nick caruso wrote:
We’re looking for a development environment and OS for an embedded
application, and QNX and VxWorks are both candidates at this point. I’d
be curious if anyone here who knows VxWorks would be so kind as to
contrast it with QNX.best regards,
Nick Caruso
Unicore Technologies
The contents of this message express only the sender’s opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
I used OS-9/68k v3.0 back in the early 90’s. It was a good little OS, although we had some problems. I haven’t kept up with Microware, so I don’t know how solid OS-9 is today.
For what it’s worth, here’s my take on OS-9:
“FIRSTNAME LASTNAME” <WOJCIECH_MIRSKI@MERCK.COM> wrote in message
news:3AC1C932.CBC65C0B@MERCK.COM…
What about OS 9 isn’t it more reliable, flexible?
What about making device drivers under VxWorks or QNX or OS 9 wchic
system is easier?
Drivers are definately much easier in QNX than VxWorks (if by easier, you
mean TTDP - time to debugged product). Can’t comment on OS-9 (no
experience).
Rennie