|
|
**QNX FAQ from MBA** FAQ last updated: 04/19/99
Author: Mitchell Schoenbrun, Micro Business Applications
EMAIL: maschoen@pobox.com
Available from: comp.os.qnx, at website http://www.schoenbrun.com/mba
I will try to enhance this FAQ as I get feedback. Please send corrections, additions, and updates to maschoen@pobox.com
I am enhancing my first version of this FAQ by integrating a considerable amount of previous work done by Martin Zimmerman. His document was compiled with the help of others including Dan Hildebrand, Tom McGrath, Gregory Soo, Trever Miller, Randy Martin and John Wall. Thanks to all.
I will improve the HTML version later as time allows.
0) Where can I find The QNX Community Portal?
3) What is the History of QNX?
11) How does QNX's network work transparently?
12) What other forms of Inter Process Communication does QNX support
15) What Windowing GUI's does QNX support?
18) What is Photon's theoretical design?
19) How is QNX different from NT?
22) Why should I pay for QNX when Linux is free?
23) How do I get technical support for QNX?
25) How does TCP/IP run along side of QNET?
26) How do I write a QNX Driver?
27) How do I write an FSYS Driver?
28) How do I write a Dev Driver?
29) What is an I/O Manager and how do I write an I/O Manager driver?
30) How do I write a simple Administrator driver?
31) How do I write a simple subroutine package driver?
32) What do I have to know about interfacing to Hardware?
33) How do I write to I/O ports?
34) How do I write to Dual Ported Memory?
35) How do I use DMA channels?
35A) How do I write an interrupt handler?
36) Why does my program abort when I access an I/O port
37) What hardware does QNX run on?
38) Why doesn't QNX 4 support Multi-Processor Hardware?
39) Does QNX run on MMX processors?
40) Does QNX run on any non-Intel processors?
42) How do I connect to QUICS.
43) Are there any QNX related publications available?
44) Does QNX support a swap file?
45) Does QNX support virtual memory?
47) What compilers/languages are available for QNX 4.+?
49) What are the memory and HD requirements for a QNX system?
50) What editors are available?
51) How stable and robust is QNX?
52) I can ping 192.7.6.5 but when I use the name it fails.
53) I cannot get my domain name server to work.
54) I telnet qnx.quics.com and get "Connection closed by foreign host"
55) When looking up names what does it check first /etc/hosts or
56) I telnet/rlogin to a QNX host and get "Connection closed by
57) The r cmds still ask for username and password even after configuring
58) I got the r cmds working but I can't get on as root, it still
59) How do I start NFS as a server?
60) What is the difference between Socket and Socklet?
61) Does Sock(l)et support FDDI?
62) Does Sock(l)et support token ring?
64) What types of networking are supported?
65) What network adapter cards are supported?
66) What SCSI cards, disk drives, CD-ROM drives, DAT and tape drives
67) What sound cards are supported?
68) What non-SCSI CD-ROM devices are supported?
70) Which PCMCIA chipsets are supported?
71A) What video cards does X-windows support?
71B) What video cards does Photon support?
72) Yeah, but can I play DOOM on it?
74) Is there a de-fragger for QNX?
76) How is QNX 2 different from QNX 4?
77) What new problems are QNX 2 users experiencing?
78) What can and should QNX 2 users do to solve unsolvable problems?
79) What Books are Available for QNX?
80) What is meant by real-time
80) What are the differences between QNX 4 and Neutrino
81) Who is MBA?
0) Where can I find The QNX Community Portal?
You can find this most useful website at http://www.openqnx.com
QNX pronounced like "queue nicks" is a commercial operating system that runs on intel processors, mainly the 386, 486, and Pentium, and their clones, such as MD, Nat Semiconductor, Cyrix, and SGS Thompson.
The simple answer is that QNX is a realtime, microkernel, preemptive, prioritized, message passing, network distributed, multitasking, multiuser, fault tolerant operating system. This is a "true" microkernel, with the largest QNX kernel to date being less than 10K.
The QNX/Neutrino microkernel is about 32K, but can run standalone, something the QNX4 microkernel cannot. The QNX/Neutrino microkernel + process manager is about 64K, which is half the size of the QNX4 microkernel + process manager, and it does more.
QNX is made by QNX Software Systems Limited, QSSL based in Ottawa, Canada QSSL is a medium sized rapidly growing company with about 150 employees, doing a rumored $24M/year in sales.
QSSL
175 Terrance Matthews Crescent
Kanata South Business Park
Kanata, Ontario K2M1W8
Tel: (800) 363-9001 (Customer Service line for established customers)
Tel: (800) 676-0566 (New Customers)
Tel: (613) 591-0931
Tel: (613) 591-0941 (Tech Support)
Fax: (613) 591-3579
Web: http://www.qnx.com
EMAIL: info@qnx.com.
3) What is the History of QNX?
QNX was created by the two founders and co-presidents of QSSL, Gordon Bell and Dan Dodge. Legend has it that the first ideas were melded during their college days at the University of Waterloo. In the early 80's they began work on a small message passing kernel based OS that had some user interface similarities to UNIX. The prototypes were a 6809 processor board built by Dan, and an 8088 board built by Gordon. In the Early 80's IBM released their 8088 based IBM PC, and the race was on. About 6 months after IBM's release, Dan and Gordon made their product known with an ad in PC Magazine. They called their product QUNIX, reportedly because it was a "Quick UNIX". They named their company Quantum Software Systems Limited. The QUNIX name lasted a year or two until they received notice from AT&T that a change would be appropriate. Always ready for a challenge, they changed the spelling to QNX without changing the pronunciation. By the time they started advertising, a third person, Syd Geraty had joined the company in marketing and sales, but located in South San Jose, California. Later a third employee named Sandy Kingston joined up in Ottawa and took care of administrative chores for a number of years.
Early beta-releases lacked multi-tasking, but ran on an IBM PC with only 64K of RAM and one 180K floppy disk. After a few months a 1.0 version that did support multi-tasking was released. Amazingly enough, 64K was enough memory to run the OS, a shell, and actually compile programs. I believe it was even possible to do a few background chores at the same time, like printing a file. A relatively small cadre of early ambitious users worked with the developers to report bugs, and add improvements. Some of these developers, Terry Laughlin, Bill Flowers, Dan Hildebrand, Luc Bazinet (did I miss anyone?) come to mind, and are still familiar faces at QNX conventions, either as users or employees. I think Terry ranks as the first technical employee, and Bill was the longest running employee until he left this year. QSSL was shut down to hold a barbecue in his honor.
As hardware for the IBM-PC came down in price, users found it possible to upgrade to 256K, then 512K and finally a whopping 640K of memory. This was such an excessive amount of memory for QNX, that a typical thing to do was to mount a 256K ram disk to speed up compiles. Otherwise this memory would go unused. 360K floppies appeared, and any serious QNX developer needed two, one to hold the OS and utilities, the other for active source files. Early on QNX provided integrated support for a 5Meg Hard disk from Davong, a name now long gone from the PC market. This was an unbelievable luxury in terms of development. Later this was followed by dynamically mountable drivers.
The next big step for QNX was the IBM AT. At first some simple modifications allowed the use of the much faster |-), it really was at the time, 6Mhz 80286 processor. 6 weeks later protected mode was supported. Due to amazing forethought, most programs ran in protected mode unmodified. In fact re-compilation was not even needed. Remember all the recompiles for other OS's to switch between modes? Following a few simple rules, even drivers could run in either mode. Of course applications became much more stable quickly as protection exceptions would keep a task from crashing the system.
Following at about the same time as 286 support came the QNX network. At the time the developers chose to support Arcnet for its robustness, realtime characteristics, and reasonable expense. As there was no "defacto" standard for these cards, QNX arranged with Corman Technologies to build a custom card, support for which was integrated into the OS. Some early versions of these reliable cards are reported to still be working today.
Sometime in the mid 80's the first QNX conference was held in Ottawa. While somewhat less than 100 participants came, the energy was electric. Everyone moved in tandem for three days back and forth between meals, lectures, the display booths and finally the bars, late into the night. Ideas for products and development tools and new OS features were thrown back and forth. In the last conference over 700 people attended and 70 companies exhibited.
Many large well known companies started using QNX in this period, mostly in back-room projects where details like which OS was running wasn't visible at the executive level. What was important was that it worked, and nothing else seemed to. It seemed a yearly event that Microsoft would announce another new version of DOS that really really really would be multi-tasking this time. Historians will note that when this finally came to pass, the product was called OS/2.
Following the 286, came the 386 and incremental changes to QNX continued, however there came a time when the company needed to make a big jump. It had grown to about 50 employees and was ready for a new challenge. The question was whether to revamp, or start from start from scratch. Over the years the QNX community had a varying relationship to its progenitor UNIX. On one hand, many of its superficial features had grown out of UNIX. On the other hand, its own architectural features had been shown to have clearly better performance characteristics. In the early days, many UNIX advocates were notoriously rigid about what could qualify as UNIX, which created a palpable resistance to making QNX too UNIX like. Some barely usable UNIX products also created confusion in the market. I remember an early version of SCO running on an 8088 that need a 2 Meg Ram disk for its root file system to run.
All the same, times were changing. A tremendous amount of energy was being put into public domain code that was compilable on UNIX machines. The Internet, a system predominantly built on UNIX machines was starting to become a name heard at conventions. With all this momentum, how could QNX fit in but at the same time distinguish itself in the market?
The answer came in the form of POSIX. The POSIX specification was written so that QNX could become POSIX compliant without forcing it to lose its underlying high performance characteristics. This is because POSIX describes the interface, but makes no requirements on how it is implemented. While it was not a decision that attracted the love of purists, in hind-sight it has turned out to be a brilliant maneuver. By keeping the underlying message passing kernel, QNX would keep its realtime performance characteristics.
In fact, since the OS was going to be rewritten, why not make it even better? For what seemed like ages, QSSL provided the user community glimpses of what was to come. A revamped network system supporting a wider range of hardware, as well as fault tolerance. A highly optimized file system, with many QNX 2 limitations and bottlenecks removed. Some of the community feedback at the time was foolish, such as "please support my dear old 8088." Little did we know that an era of extremely rapid growth of hardware performance, coupled with free falling prices was upon us.
After what seemed like decades of waiting, QNX 4.0 was released. What seemed like a company motto at the time, "You're going to love it as soon as the pain stops" turned out to have much truth. The early versions showed much promise, as well as some teething pains. In spite of the time spent in planning, a number of issues had be re-thunk and incorporated into the 4.1 version. While it showed much promise, most users concluded in retrospect that 4.0 was a beta. With 4.1 the new OS became much more stable. Reports of a new faster GUI named Photon started to surface. QNX 4.2 supporting 32 bit programs followed soon afterwards, providing a watershed product that was no longer encumbered by 16 bit code. The timing could not be better as cpu's with 16Meg of memory and up were becoming common place.
In the last chapter we find our two person startup has grown to around 150 employees. A relatively recent change has been to change the name to QNX Software Systems Limited. The name Quantum was often confused with many other companies with similar names, and QSSL wanted to identify themselves more closely with their product. The latest 4.24 version seems near a plateau. Changes are mostly incremental. Photon has been realized, pun intended, and seems a Ferarri next to the slow and rarely steady Win95. But in the fast moving computer market, nothing stays still for long. QNX's successor product QNX/Neutrino is now available, mostly targeted to the embedded market. The future replacement of 4.24's kernel with QNX/Neutrino seems sketchily mapped out, but the time table is unclear. In addition, Microsoft seems to have made an all out marketing assault on the hearts of the corporate world, with their NT product. They seem to believe that a poorly performing OS with a fast enough processor can provide realtime if you don't mind it being "soft". Sadly this type of argument often keeps QNX out. Will brawn win out over brain? Will future toasters need a gigabyte of ram just to boot their OS? The future is unwritten.
QNX 4 is QSSL's most current product. Version 4.24 is the latest version. It's main difference from QNX 4.22 is that with QNX 4.22 the main OS processes were written with 16 bit code. This caused a number of limitations in resources such as the maximum number of processes. With QNX 4.24 all of these processes are written in 32 bit code. Dev is still provided in both 16 and 32 bit versions in case you have any old un-ported drivers. Also the latest 16 bit version of Fsys, 4.22H still works well under 4.24.
The basic design of QNX is a micro kernel. Win95, NT, UNIX and OS/2 all have a "monolithic" design in which the core operating system code is very large. Generally speaking, system level functions like hardware drivers must be part of the kernel to run. This is for, among other reasons, processor "supervisor" privileges are usually limited to kernel code for protection. In older UNIX systems, all kernel code must be linked into the OS before booting making testing such code time consuming, and configuration difficult. DOS and Win95 load all their drivers at boot time. Kernel resources are usually accessed by jumping into the kernel code. On Intel hardware this is best accomplished by the use of "gates". By jumping through a gate into the kernel, supervisor priviledges are obtained. The kernel is usually not returned from until the system function is complete. This makes the kernel multi-threaded, and so all kernel code must protect non-re-entrant areas with semaphores. In addition, kernel code must protect against processes that pass bad addresses either out of error, or with malicious intent. Many security holes are based on taking advantage of the kernel this way.
QNX's micro kernel design is very different. Instead of a large kernel, the kernel is extremely small. It contains a minimum number of features implementing basic system calls. These include message passing along with other interprocess communication, interrupt handling support, and other features. The other functions of the operating system are provided optionally and modularly through processes that communicate mostly through message passing. One exception is the Proc process which provides required scheduling services and process creation services. With QNX/Neutrino, even Proc becomes optional, and the kernel itself is modular, and user configurable.
Other important OS functions are provided by:
A) Fsys - Block I/O and QNX file system access
B) Dev - Device handling
C) Net - Network communications
A curious feature of QNX's message passing architecture is that these system processes have no additional priviledges unavailable to user processes. The normal line drawn between OS and application is much muddier.
Message passing is QNX's main form of inter-process communication. Message passing is not unique to QNX, however few operating systems rely on it in as fundamental way as QNX. All the standard POSIX API services are implemented with these QNX message passing primitives.
Message passing is a two way asymmetric synchronized exchange of data between two processes. It is asymmetric in that one process must be a "sender" and the other must be a "receiver". In a complex system of processes, a single process can and will often take both roles. The way an exchange starts is either the sender will call the Send() primitive, or the receiver will call the Receive() primitive. It does not matter which goes first, but that process block until the IPC completes When the second of the two processes calls its primitive routine, the first phase of the message pass occurs. Data of a variable and prescribed size is sent from the sender process space, to the receiver's process space. The receiver can limit the size of the data received, and request additional transmition at a later time. Once the copy is complete, the receiver process wakes up and can process the data that it has received, while the sender process continues to wait. At some time in the future, the receiver process can call the Reply() primitive sending a packet of data back to the sender process. Once the copy is complete, both the sender and receiver are able to run again. A receiver does not have to reply to the sender between calls to Receive(). In this way it can hold up the sender until some future event, such as a hardware interrupt, or receipt of information from another sender.
There are many variations and modifications on this process, but the details do not change. An example is that a receiver can chose to accept messages in the priority of the processes that are sending them. In addition it can chose to run at the priority of the process whose data it is working on. This is called priority float. This allows a receiver to give a process no more attention because of priority than it would get if it was running the code itself.
Typically receiver processes are resource managers. That is a message will be sent to a receiver to gain single threaded access. An example might be a database manager. It would receive read, and write messages which are processed against the database files in a single threaded manner. This eliminates the need for applications to lock a file for update, and also allows all file buffering in one convenient location.
As mentioned in 9), all system processes use message passing. So in fact a call to read a file is really a message sent to the the file system process Fsys. Fsys receives the message, calls a driver to read the data off of a disk, and then replies the data. While the hardware is busy with the data, the application process is blocked from running, and Fsys can receive and process other I/O requests.
11) How does QNX's network work transparently?
QNX's network works transparently because the Net process and its drivers extend message passing across the network. In the case of the file system, an I/O call to a file across the network is turned into a message to the Fsys on the node where the file is located.
This feature extends to most system resources, and can be used by application processes equally as well.
12) What other forms of Inter Process Communication does QNX support
QNX supports all the standard forms of interprocess communication, such as pipes, queues, and signals. Unlike most POSIX systems, these forms of communication can extend across the network. QNX also supports POSIX compliant shared memory. Shared memory cannot be shared across the network of course. QNX also supports shared memory with non-portable routines known as the qnx_segment..() routines. These were mostly important for 16 bit applications that could not use the POSIX shared memory routines, and require the use of large model compiler features. These should be avoided in favor of shm_open() and mmap().
POSIX is a family of standards that were developed to describe a UNIX like user interface. The standards were and are being developed by a wide range of industry members. The official POSIX standards are published by the IEEE.
POSIX provides a level of standardization that allows OS manufacturers to provide compile time compatibility of programs. QNX supports the API standard, the utilities standard, and most of the Real Time standard, known as 1003.1, 1003.2, and 1003.4. This needs some clarification. A curious feature of the Real Time standard is that an OS can comply with it, without providing any of its features. It is merely necessary to provide the appropriate source code include files that indicate which features are supported, which can be none.
QNX 4.24 does not support the POSIX thread standard, however it does provide a limited form of threads through the tfork() routine. Anyone needing this feature should study the documentation carefully for all the limitations involved. QNX/Neutrino fully supports the POSIX realtime and thread standards.
QNX/Neutrino is QSSL's latest OS product. QNX/Neutrino features a modular, user configurable kernel. Features such as hardware protection and a scheduler are optional. QNX/Neutrino provides similar functionality to QNX 4.24's message passing, with some differences. It may be described as QSSL's answer to the Holy Grail of OS's. It should be able to support a very wide range of systems with respect to cpu power, from small embedded 386 systems, up to very large SMP and VLAN servers. Most descriptions from QSSL include a gradual migration of QNX 4.24 to the QNX/Neutrino kernel, although no time table has been provided. That's the good news.
The bad news is that QNX/Neutrino isn't all here yet. The current product is being marketed mostly toward embedded systems development. It only has a very limited file system for now, and does not host its own development environment. Development must be from QNX 4, or NT (in beta as of 9/97). It's even possible that with all the pressure from Microsoft's NT product, that QSSL could wander in this niche market and not return. This certainly does not seem to be their current marketing plan however.
Robert Krten has a Neutrino FAQ at http://www.parse.com/free/neutrino-faq.html which you might want to look at.
15) What Windowing GUI's does QNX support?
There are three choices for Windowing GUI's for QNX at the current time.
A) QNX Windows
This product was originally available under QNX 2. While it is no longer being promoted by QSSL, it is being actively supported, and improved upon by the third party that originally licensed to it QSSL, Basis Computer Systems Inc. In addition to providing improved replacements for QNX Window's Olwm and Olfm, an HTML viewer has been added. There is also a new picture editor which supplements Iedit, to add fonts, etc. to pictures. QNX Windows is an object-oriented GUI which manages graphical objects. Their display and user interaction controlled separately from the application. Objects such as text, lines, buttons, numbers, dials, sliders, images, and menus, can be copied or 'linked' between applications, and stored in files. The look and feel is highly customizable, allowing Motif-like and W95-like GUI's. There are three new utilities, Bwm, a W95-like workspace manager, Bhtml, an HTML/on-line manual viewer, and Bpict, a picture editing utility. QNX Windows also has a 'graphical ditto' product called QW Mirror. It transmits objects rather than bitmaps. The programming model is supposed to be fairly easy to understand. Development on QNX Windows appears to be on-going. For more details, you can contact Frank Kolnick at fkolnick@sentex.net.
B) X-Windows
This is a port of the familiar UNIX GUI. It does not fit comfortably under QNX, needing a minimum of 16Meg. With memory prices in what seems a continual state of free fall, (about $60/16Meg in my area) this is not as big a problem as it used to be. X should be considered by those needing cross OS compatibility, or if the development environment is desired because of existing skills.
C) Photon
Photon is the newest QSSL GUI product.
Photon is QSSL's newest GUI product offering. It combines extremely fast GUI response, with a very small footprint. To aid in development of Photon programs, QSSL provides an application builder program PhAB that simplifies construction of Photon programs, as well as enabling fast prototyping.
Be warned, The Photon model and API is not very straightforward or familiar. The API is however very X-like in philosophy. Expect a significant learning curve, even if using the PhAB. PhAB removes a lot of the drudgery of building a GUI application, but it does not remove the complexity of the interface. In addition, an understanding of Photon's design model can be valuable.
Because Photons are particles of light.|-). Oh I guess that's not it, but it would take a long time to tell, and I'm not really all that sure why. Like most QNX applications it uses message passing, but that's only part of the story.
18) What is Photon's theoretical design?
At the bottom level Photon provides an innovative design model for a GUI. Photon applications work within a 3D "Photon Space". Two of the dimensions are the usual spatial dimensions associated with the computer screen. The size of the space in these two dimensions is 65K X 65K. Each point in Photon space can represent a pixel on the screen. Programs create rectangular regions within this space. There is a third dimension, so the regions can overlap each other.
Interaction between the user and the GUI are represented as events within Photon. Events travel back and forth in Photon space only in the third dimension. Regions that events pass through have two properties related to these passing events. They can be sensitive to the event, that is, the process owning the region receives a copy of events intersecting with the region. They can also be opaque or transparent to the event. That means that they can let the event pass through, or stop it.
Here is a short list of events that might travel through Photon space. Draw events are events that travel from an applications region until they hit screen driver's region. The screen driver can absorb the event, but then display it on the real console. Keyboard events are events created by the keyboard input device, which pass through or are absorbed by application regions. Note that an application could see a key press, but allow it to pass on. This is useful in a screen saver application which only wants to know if there has been keystrokes recently.
Some brief observations about all this. It is relatively easy to have multiple screen drivers that may overlay different parts of the screen. It also is easy to see how "ditto" must work. It puts a region transparent but sensitive to draw events between the applications and the screen drivers. This way it sees what goes on the screen, but allows their display. These events are then transmitted through some medium like a serial port, or the network.
On top of this Photon kernel is a window manager that provides a variety of windowing functions. Examples are, re-sizing of a window, minimizing, exiting, etc. Above this, QSSL has also provides a desktop manager. Both the desktop manager and windowing manager are optional parts of Photon.
19) How is QNX different from NT?
Both QNX and NT provide a multi-processing environment for running programs. Unlike NT, QNX provides realtime capabilities. QNX needs much less disk space to run. This can be crutial if you are running an embedded system with expensive flash memory. In addition QNX provides context switching that is much faster than NT. QNX was created by a relatively small company near Ottawa Canada. NT was created by the software behemoth Microsoft in Redmond Washington.
QNX can be purchased in two ways. Direct from QSSL, or through a distributor. You should check their web site at http://www.qnx.com for a detailed listing of distributors.
http://www.qnx.com/info.html for general information
http://www.qnx.com/company/sales.html for sales contacts
QSSL would rather I not publish specific pricing because the price is very dependent on which OS modules are included and the runtime volumes. (I guess I should retract this statement as QSSL is now updating me with new price/packages). Since QNX is being built into set top boxes and televisions, runtime prices must be very inexpensive.
Anything you see here may be out of date, so you should check with QSSL directly for current pricing. Here is their "web" statement on the subject.
"Like the architecture of the QNX OS itself, our unique pricing structure gives you enormous flexibility and control over your target systems. You can configure the OS as you want - with or without a filesystem, a network manager, utility set, etc. - and you pay only for the modules you need.
Contact us for more information on products, services, pricing, or evaluations."
With that disclaimer out of the way, here are some US list prices as of 9/97.
Some new prices as of 2/99: QNX4 C/C++ Developer's Kit CD $2,195.00 QNX4.25 OS Photon runtime TCP/IP runtime Voyager runtime Watcom C/C++ TCPIP Development Online Documentation QUOTE> QNX4 Developer's Kit Printed Docs $400.00 Photon Developer's Kit CD $4,095.00 QNX4.25 OS Photon runtime TCP/IP runtime Voyager runtime Watcom C/C++ TCPIP Development PhAB Online Documentation Photon Developer's Kit Printed Docs $500.00 Internet Appliance Toolkit Development CD QNX4.25 OS Photon runtime TCP/IP runtime Voyager runtime Watcom C/C++ TCPIP Development PhAB Voyager SDK Online Documentation IAT Developer's Kit Printed Docs $500.00
QNX 4.24 node license with printed docs $795.00
QNX 4.24 node license with on-line docs $695.00
Watcom 10.6 with printed on-line docs $845.00
Watcom 10.6 printed docs $110.00
Watcom C++ (requires C) with on-line doc $195.00
Watcom C++ printed docs $65.00
Ditto $100.00
TCP/IP Runtime 4.23a $350.00
TCP/IP Runtime printed docs $75.00
TCP/IP Development 4.23a $295.00
TCP/IP Development printed docs $75.00
Photon Runtime 1.11 $95.00
Photon Runtime printed-docs $40.00
Photon Development Toolkit (Appbuilder) $1890.00
Photon Development Toolkit printed docs $100.00
QNX X Windows 5.0 $295.00
QNX X Windows documentation $65.00
QNX X Windows Development $395.00
QNX X Windows Development documentation $215.00
QNX X Windows Motif $195.00
QNX/Neutrino Development System 1.00 (QNX 4 Hosted) $1655.00
These prices are mostly relevant to development systems. Prices can vary quite a bit. Discounts are available to developers, and there are also quantity discounts. For embedded and OEM applications modular pricing is available. This lets you pay only for modules of the system that you need. In volume, embedded pricing gets quite low. You should check with QSSL or your distributor for details.
QSSL would like you to know that: Independent of the pricing thread in comp.os.qnx, we've been preparing a new discount schedule to address OEM embedded systems developers. Since the timing of the announcement seems to nicely coincide with this discussion on comp.os.qnx, I thought it appropriate to post this message from Mike Hornby, VP of Sales and Marketing, QNX Software Systems Ltd.
-- start of quote --
In recognition that many of the smaller volume opportunities are very important to QSSL we have introduced to our channel partners and sales organization a new policy that sets the QNX runtime price at a more effective level to meet the needs of these organizations. Even though these opportunities are smaller, they are much more numerous and therefore, in total, amount to a significant revenue.
There are no changes in list prices. We will now be more generous with discounts depending on the application and the volumes.
If anyone is interested in finding out if their application or project can take advantage of this new policy, I would encourage them to contact their local QNX representative.
I would also ask that people not look "skin deep" at our list prices and come to their own conclusions about volume runtime prices (even for small volumes). Our list price and runtime price differ significantly depending on volume.
-- end of quote --
22) Why should I pay for QNX when Linux is free?
If you need an OS to host a web site, or you just want to write some 'C' programs, you probably can't go wrong using Linux. That's just not where QNX fits in the marketplace. If you have a serious commercial product that needs to take maximum advantage of the performance available on your hardware, then Linux is probably not a very good choice. If the cost differential does not seem rational to you, $0 vs. about $2K to get going, then the advantages of QNX are probably not those that you will be needing.
23) How do I get technical support for QNX?
Here are a number of ways from least expensive, to most.
A) Post Questions on the Internet Group comp.os.qnx
B) Sign on to QSSL's QUICS BBS
If you have Internet access, you can telnet to qnx.com. If not, you can dial: 1-613-591-0934 1-613-591-0935 1-613-591-0940 1-613-591-1735
The first time you will need to enter newuser at the prompt. Once signed in enter tin at the $ prompt. You will only be able to read the experts newsgroups, but you can ask questions in the user2user groups. QSSL techies don't usually answer user2user questions.
C) Get a service plan from QSSL or through your distributor. A service plan gives you credits that let you call the QSSL technical support line: (613) 591-0941. You can get some free support from them, but I don't know the details. Credits also let you post questions to the experts news groups. You can expect a answer to questions posted there, although not right away always.
D) Take a course. QSSL offers some courses. DataKinetics Ltd also provides a number of QNX related courses. There may be others who want me to mention themselves here.
E) Hire a consultant. Check the QSSL web site at http://www.qnx.com.
Here is QSSL's official Tech support options:
Technical Support We know how important technical support can be. We also know that not all customers need the same amount of support, so we let you choose between three levels of service: Free, Standard, or Gold. Free Service Plan All QNX users receive this basic level of service, which includes: *Free phone support (first-come, first-served) *Subscription to QNXnews *Access to QUICS (read only) *Ability to download from QUICS (including free software and updates to previously purchased products) Standard Service Plan This plan offers all the services of the Free Plan, plus a set of points that can be used for services on a pay-for-use basis: *Fax support *Write access to QUICS to post technical questions *Email support Your annual subscription is good for 50 credits or one year-whichever comes first. (If you require more service you can opt for a Frequent User Package with 150 credits.) Each service is allocated a credit value: *QUICS Support-Reporting a problem or asking a technical question using QUICS uses two credits. *Fax Support-Faxing a question to Technical Support uses five credits. *Email Support-Asking a question via private email using QUICS or the Internet uses five credits. Gold Service Plan Gold Plan subscribers enjoy all the Free and Standard Plan services, together with unlimited access and guaranteed response times, as follows: *Priority phone support-separate phone lines are reserved exclusively for Gold Plan subscribers *Two-hour call back* *Priority fax response within 24 hours* *Priority email response within 24 hours* * During business hours 8:00 am to 6:00 pm ESTQNET is the local area network that is built into QNX that allows message passing between processes on separate nodes. FLEET is QSSL's product name for the fault tolerant, load balancing features of QNET. QNX 4.24 supports multiple lan cards connected to multiple lans. QNX provides both fault tolerant access, as well as additional throughput.
25) How does TCP/IP run along side of QNET?
The QNX Net process allows other processes to register and communicate over the lan directly at a "raw" level. TCP/IP uses this interface to bypass QNET. A good example of another program that uses this feature is Cynosure's Netsniff product.
26) How do I write a QNX Driver?
This is a very big subject, but is a frequently asked question because it is not covered sufficiently in any of the standard QNX documentation. There are many resources available to driver writers, and much information is distributed throughout the QNX documentation that can help. Lots of free driver samples are available at ftp.qnx.com.
First an overview. Since code that talks to hardware does not have to be in the kernel, any process that accesses hardware can be considered a driver. This muddies the definition of a driver, which under DOS, Win95, and NT is usually just a single "driver" module loaded with the OS at boot time. QNX drivers can be roughly divided into 5 categories.
A) Fsys drivers
B) Dev drivers
C) I/O manager drivers
D) Administrator drivers
C) Subroutine packages
27) How do I write an FSYS Driver?
Many drivers for disk drives come with QNX. You will find them in the /bin directory with the Fsys prefix. This is not a requirement however. Should you need access to a disk drive or other block I/O device that QNX does not support, you might need to write your own Fsys driver. Fsys drivers are quite peculiar in design and function.
Fortunately there are a number of examples that you can down-load from QUICS. After signing on to your QUICS account, you can start searching below /usr/free. There is also a specific document on the subject.
The main function of an Fsys driver is to get I/O requests from Fsys to read or write one or more contiguous sectors on the device. Fsys drivers remain cheerfully unconcerned with details of the file system. This allows the driver to be used with whatever file system is actually being examined, be it a QNX 4 file system, a direct access of a block I/O device such as /dev/hd0, or possibly a DOS file system through the DosFsys program.
An Fsys driver is written as a normal 'C' program with a main() routine. This program must create a table of subroutine entries that are passed to Fsys. The subroutines pointed to are:
init - Initialize the hardware, usually the controller
term - Hardware will no longer be used
open - Initialize access to a particular disk
close - Releases access to this disk
unit_open - Called the first time a process opens the block I/O device. Very useful for removable media.
unit_close - Called when all opens to a block I/O device are closed. Also very useful for removable media.
read-write - Called when either a read or write is requested
ioctl_mask - Checks for permission to use a particular ioctl call
ioctl - Allows for non-standard interaction with the driver
These routines are never called directly from the driver process. Instead Fsys sets up links to them so it can jump directly into this code. For some drivers that do not need to run as a separate process, it is permissible for the driver process to exit. Fsys continues to have access to the drivers data segment and code segment. If the driver process does not exit, a major pitfall must be avoided. If only local data and "near" pointers are used there is no problem. However if far pointers are used, a programmer must keep aware of what context the pointer is being used in, and whose selector is being used, Fsys's or the driver's. In fact there are three possible contexts that might be encountered in the driver code, A) the drivers, B) Fsys's, and C) an interrupt handlers. In the ugliest situation, you might have a common routine that could be called from all three of these contexts. A thorough understanding of The Intel LDT and GDT are a must.
28) How do I write a Dev Driver?
The interaction with a Dev driver and Dev is similar to the interaction between Fsys and Fsys drivers. There are good examples on QUICS as well as a detailed document on the subject. Dev drivers typically only have to add to and remove from data queues. Issues like cooked vs. raw mode of a device, are handled by Dev.
29) What is an I/O Manager and how do I write an I/O Manager driver?
I/O Managers are a very powerful feature of QNX. They allow your to write a process that adds a standard POSIX interface device to a QNX system. An application accessing this device uses standard I/O calls such as open(), close(), read(), write(), and qnx_ioctl(). These calls and others are turned into request messages passed to the I/O manager. The I/O manager then processes these requests in a manner appropriate to the function of the device.
It is important to note that an I/O manager may or may not have some real hardware that it is handling. The hardware may or may not be on the same cpu. An I/O manager can manage a virtual resource, such as a pipe. Instead of direct access to hardware, an I/O manager might use the services of another I/O manager.
Both Fsys and Dev are examples of I/O managers, although they are unusual in that their hardware code is dynamically loaded through drivers.
There are some good examples of drivers on QUICS however there is nothing that describes the subject in all the detail that it deserves. In addition, many of the functions that an I/O manager might deal with are not described or documented anywhere.
Building an I/O manager is an excellent way to create a device driver for a device that doesn't fit the characteristics of an Fsys or Dev driver. It also maximally shields any applications that use the driver from hardware or api details.
30) How do I write a simple Administrator driver?
An Administrator driver is similar to an I/O manager, except that it can be much less complicated. Like an I/O manager, the administrator receives messages from applications requesting some hardware function, however the format of these messages can be a very simple design. User processes find the administrator processes PID using the qnx_name_locate() function, looking for a name that the administrator has previously registered with qnx_name_attach(). The message passing code in the user application can be hidden below a set of custom api routines.
31) How do I write a simple subroutine package driver?
A subroutine or set of subroutines that access hardware used by an application, can be written without any additional concerns other than details of the hardware. Generally this form of driver can only allow only one process to access the hardware at a time. Typically a program compiled this way, must be run as super user and if it does I/O port calls, must be compiled with the "-T 1" parameter. If it is not desirable to run an application program with these priviledges, then the device code should be written as an administrator or I/O manager with the application sending it messages.
32) What do I have to know about interfacing to Hardware?
There are a few different classes of hardware that must be interfaced to, each with their own details.
33) How do I write to I/O ports?
QNX allows any process compiled with the "-T 1" parameter and run as super user to access any I/O ports. The "-T 1" parameter causes a process to run in ring 1 of the Intel protected mode environment. Otherwise a process will run in the lowest ring 3. Ring 0 is reserved for the kernel, Proc and a low level debugger if loaded.
34) How do I write to Dual Ported Memory?
Dual Ported Memory can be accessed in one of two ways. Using the POSIX compliant shared memory routines, the memory object "Physical" can be opened with shm_open(). A particular offset into memory is then mapped in with mmap(). The flags parameter must use MAP_SHARED, and protections should include PROT_NOCACHE.
The second method to accessing dual ported memory is to use the qnx_segment_overlay() routine to create a segment that points to the memory. This segment must then be used to create a far pointer which a program can use to access the data.
35) How do I use DMA channels?
DMA channels are programmed using Port I/O calls, which are covered in section A). The memory DMA'd from and to should be "DMA SAFE". Before QNX version 4.24 the shared memory routines always allocate contiguous memory. In 4.24 this changed. Now the only way to allocate DMA SAFE memory with the qnx_segment_alloc_flags() routine. There is a _PMF_DMA_SAFE flag as well as a _PMF_DMA_HIGH flag. Use the DMA HIGH flag if memory above 16Meg is ok, or in other words, you have a PCI adapter.
The return from qnx_segment_alloc_flags() is a selector. There are two things you can do with this. You can use the MK_FP() routine to create a far pointer. This can be somewhat inconvient, as well as forcing the compiler to do segment loads, which carry somewhat heavy overhead. The other is to use the qnx_segment_info() routine to find the real memory address of the segment you've allocated, and then use the shared memory routines with the "Physical" shared memory object. You can them mmap in the memory to your program and access it as part of your 32 bit address space.
If you are planning to use DMA channels there are some subroutines on QUICS that provide most of needed setup.
35A) How do I write an interrupt handler?
QNX 4.24 provides excellent hardware interrupt support. Interrupt drivers are attached to a hardware interrupt with the qnx_hint_attach() routine. All interrupt controller and interrupt mask issues are handled by the kernel. In fact more than one interrupt handler may be attached to each interrupt. This provides a convenient way to be woken up on every timer interrupt by attaching a handler to interrupt 0. The rate that this interrupts is not consistent across systems, however it may be set with the clock_setres() routine. QNX also offers a pseudo interrupt (-1) which always fires every 50ms, or 20 times a second.
When writing and testing an interrupt handler a few special things must be watched. First of all an interrupt handler must be reached through a far call as follows:
#pragma off( check_stack );
pid_t far int_handler()
{
return(0);
}
Note that stack checking must be turned off. The return value from the interrupt handler is a PID. The PID should be either 0, or the PID of a proxy that will be Triggered.
In addition you should usually compile your interrupt handler with the -Wc,-zu parameter, which tells that compiler not to assume that the DS is the same as the SS segment. This is important if you allocate any memory on the stack and pass its address via subroutine call.
36) Why does my program abort when I access an I/O port
Check whether you compiled your program with the "-T 1" parameter. Also make sure that you run the program as super user.
37) What hardware does QNX run on?
QNX 2 runs on Intel processors and clones from the 8088 through the Pentium, however problems due to speed have arisen on some 486's and Pentium's, and no fixes are anticipated.
QNX 4.24 runs on most Intel Processors and clones from the 386 up through the Pentium II. QSSL has been rumored to have looked at ports to other cpu's such as the PowerPC, however, there have been no public announcements.
QNX/Neutrino works on most Intel Processors including a number of embedded processors.
AMD SC300, SC310, SC400, SC410
Cyrix MediaGX
Intel 386EX, ULP486
National Semiconductor NS486SXL, NS486SXF
SGS Thomson STPC
and more...
QSSL supports a lot of standard hardware such as EIDE drives, ATAPI CD roms, and a growing list of the more popular SCSI cards, such as the Adaptec AHA2940.
Some limited Sound card support is provided with the Audio drivers.
A wide range of Video drivers are available for use with Photon. I believe that X and maybe QNX Windows can now use these drivers.
The 3rd party community provides a wide range of drivers for hardware that is not supported by QSSL. A good place to start looking is at the QSSL web site, http://www.qnx.com.
38) Why doesn't QNX 4 support Multi-Processor Hardware?
The design model for QNX 4 makes the support of SMP hardware somewhat complicated. For the moment QSSL is pushing VLAN designs for users who need the additional cpu cycles. VLAN solutions make use of an extremely fast lan connection such as a backplane connecting multiple cpu cards.
QSSL has announced SMP support for QNX/Neutrino.
39) Does QNX run on MMX processors?
Nothing prevents QNX from running on these processors as their main difference is the addition of some instructions. I believe that Photon will be able to take advantage of these instructions in the future, however there isn't much the OS itself needs them for. The MMX instructions store temporary variables in the same stack as the floating point instructions, and these registers are already preserved through context switches. This means applications can use MMX instructions now.
40) Does QNX run on any non-X86 processors?
QNX does not currently run on any non-x86 processors. QSSL is no doubt watching the market carefully for trends that they might want to take advantage of.
QUICS is the QNX Update Information Conferencing System, or in other words, it is QSSL's publicly accessible site in cyberspace. QUICS provides users with public domain files, sample source code from QSSL, as well as ported source and executables from various sources. QUICS also provides registered QNX users with online updates and technical support. There are several public conferences available that provide a valuable information resource to the QNX developer and user communities. QUICS currently has 8 high-speed modems, 8 X.25 lines (which will disappear soon in favor of the internet), and a full T1 internet connection.
42) How do I connect to QUICS.
You can connect to QUICS using several different methods each listed below:
+1 613 591 0934 V.34/V.32bis/HST-28.8K
+1 613 591 0935 V.34/V.32bis/HST-28.8K
+1 613 591 0940 V.32bis/HST-16.8K
+1 613 591 1735 V.32bis/HST-14.4K
+1 613 591 3009 V.32bis/HST-14.4K
+1 613 591 3128 V.32bis/WorldBlazer
+1 613 591 6093 TrailBlazer
* telnet://quics.qnx.com
* ftp://ftp.qnx.com/
* http://www.qnx.com/
43) Are there any QNX related publications available?
Yes, QNXnews is published quarterly by QSSL. It is sent out free to all registered users of the QNX Operating System.
QSSL also publishes a Products and Consultants guide annually.
44) Does QNX support a swap file?
No. There are some plans for implementing this sometime in the future, but don't expect to see it any time soon, or even at all. There are other features that will be added to QNX well before a swap file is added. The main reason for this is that reasons for requiring realtime response/performance typically conflict with the reasons for requiring a swap file.
The requirement for swapping in most QNX applications is quite low. The efficiency of the OS and Watcom compiler provide relatively small processes in terms of memory requirements. When this is combined with the ability to share code between multiple process invocations and shared libraries, the memory demands for QNX are quite moderate.
45) Does QNX support virtual memory? Yes. Don't confuse this with a swap file though. Virtual memory only refers to the mapping of real physical memory through a MMU. QNX operates in the protected mode of the Intel processors, and makes use of LDT and GDT selectors to provide memory mapping to physical memory. Use of virtual memory also allows QNX to provide shared memory on a per-process basis as well as memory protection between processes, and even the processes that make up the OS itself.
No.
47) What compilers/languages are available for QNX 4.+?
Watcom C/C++, version 10.6
Jean-Claude MICHOT (jcmichot@teaser.fr) has released a version of the GNU pascal compiler. Check out http://www.teaser.fr/~jcmichot/gcc
GCC is available, at following URL http://www.teaser.fr/~jcmichot/gcc This release contain GCC 2.7.2 and G++ compiler. You need WatcomC lib & linker to use this release of gcc.
In general, once developers start using Watcom C/C++, demand for GCC isn't as high. Watcom provides a very good, high quality C and C++ development environment.
49) What are the memory and HD requirements for a QNX system?
Depends on what you plan on running, and if the machine is going to be a development node or not.
The basic runtime will require less than 20Mb of HD, and can run stand alone with as little as 2Mb of RAM. For nodes that boot over the network, I (MZ.) have booted up machines with 512K.
You can easily make a floppy bootable QNX environment.
A development system will want at least 8Mb of RAM, and 120Mb of HD, but you can get away with 4Mb of RAM and <100Mb of HD.
File servers will want at least 16Mb of RAM, possibly more so that it can be dedicated to file system Cache.
QNX will boot from floppy, which might be all that is required for small embedded applications. You can download a demo disk from QSSL's web site that contains: QNX OS, Photon, TCP/IP, Web browser, Web server, a Dialer, and some HTML files.
50) What editors are available?
QNX ships with vedit and vi, there are ports available of crisp, micro emacs, gnu emacs, pico, and a few others.
51) How stable and robust is QNX?
Very, but that depends on what you make it do. If you are a developer, you tend to be able to blow up ANY operating system on a regular basis while testing code. QNX seems to be able to survive even the torture of the developer without crashing.
There are many mission critical applications using QNX, everything from medical instrumentation, to nuclear reactor monitoring, to financial transaction processing, to traffic light control. You probably use QNX several times a day without being aware of it.
52) I can ping 192.7.6.5 but when I use the name it fails.
Try configuring your local interface.
53) I cannot get my domain name server to work.
Try adding a nameserver directive to resolv.conf. Here's an example:
nameserver 192.1.2.3
54) I telnet qnx.quics.com and get "Connection closed by foreign host"
Must have a registered domain name to use quics. Quics will perform a reverse mapping of your site-name.
55) When looking up names what does it check first /etc/hosts or the domain name server?
They are mutually exclusive. If the name serve directive is in resolve.conf then the name server is used, otherwise the /etc/hosts file is used.
56) I telnet/rlogin to a QNX host and get "Connection closed by foreign host"
You need to be running Dev.pty on the QNX host you are trying to connect to. You might have to add more devices to Dev with the -n parameter.
57) The r cmds still ask for username and password even after configuring the .rhosts.
Check the ownership and permissions on the .rhosts file, the file must be owned by root, and be set to 644.
58) I got the r cmds working but I can't get on as root, it still asks me for a password.
For security reasons a password is *ALWAYS* required for root.
Another QNX user disputes this. Instead he says:
"Not true. I use no login root QNX rsh's all the time."
"The difference between root and other users is that root r command authentication never uses /etc/hosts.equiv, only $HOME/.rhosts"
59) How do I start NFS as a server?
Try this script (provided by QSSL):
#!/bin/sh
slay -f Socket Socklet
Socket node$SOCK
/etc/ifconfig en2 node$NODE
/etc/ifconfig lo0 localhost
/etc/portmap
/etc/nfsd -u 0,0,2 -t 0,0
/etc/mountd -n
/etc/inetd
60) What is the difference between Socket and Socklet?
Socket supports NFS and Socklet doesn't. Socklet is intended to be a less memory intensive version of Socket for embedded applications that do not require NFS, but still require TCP/IP connectivity. By the time you read this, Sockppp will probably be out of beta. It's a PPP only version of Socket that is smaller than Socklet.
61) Does Sock(l)et support FDDI?
Yes, you must be running the Net.fddidfe driver, see the section on hardware for which FDDI network adapters are supported.
62) Does Sock(l)et support token ring?
Yes, you must be running the proper Net driver for token ring, see the section on hardware for which token ring network adapters are supported.
Try this script (provided by QSSL):
#!/bin/sh
slay -f Socket Socklet
Socket node$SOCK
/etc/ifconfig en2 node$NODE
/etc/ifconfig lo0 localhost
64) What types of networking are supported?
Ethernet, FDDI, Token Ring, Arcnet, NCR's wireless WaveLAN, serial ports, parallel ports, and anything you can open() and get back a file descriptor from.
Ziatech provides a high-speed local bus network driver for their STD-32 bus products.
65) What network adapter cards are supported?
Take a look in ftp://ftp.QNX.com/etc/readme/hardware/network_support
66) What SCSI cards, disk drives, CD-ROM drives, DAT and tape drives are supported
Take a look in ftp://ftp.QNX.com/etc/readme/hardware/scsi_support
67) What sound cards are supported?
Take a look in ftp://ftp.QNX.com/etc/readme/hardware/audio_support
68) What non-SCSI CD-ROM devices are supported?
QNX driver: Fsys.mitsumi
LU-005 : Mitsumi internal CD ROM
FX-001 : Mitsumi internal CD ROM
FX-001D: Mitsumi internal CD ROM (double spin)
ATAPI: EIDE CD ROM drives
Yes. QNX supports the PCMCIA 2.01 spec, also known as the JEDEC 4.1 spec. PCMCIA I, II, and III cards that conform to the PCMCIA 2.00 spec or later should work.
70) Which PCMCIA chipsets are supported?
Take a look in ftp://ftp.qnx.com/etc/readme/hardware/pcmcia_support
71A) What video cards does Xwindows support?
Take a look in ftp://ftp.qnx.com/etc/readme/hardware/X_video_support
71B) What video cards does Photon support?
Take a look in ftp://ftp.qnx.com/usr/free/qnx4/os/technotes/photon_support
72) Yeah, but can I play DOOM on it?
You bet! There are versions of DOOM ported for QNX by the QSSL folks that will run on the console, Xwindows, and even photon. You'll need a sound card, to get the full-effect, but you *CAN* play DOOM.
Be warned that DOOM will consume all unused CPU ticks at or below the priority you run doom. Then again, if you are playing doom, you probably aren't running any mission critical code.
Amoung other amazing things you can do with the QNX version of DOOM are to run it under Photon. Then have fun dragging it between QNX and Win95 running Phindows.
Unlike the Linux port, music and sound effects are supported by the QNX audio driver. Linux only supports the sound effects.
73) Where can I get this FAQ? Currently I hope to post this FAQ in comp.os.qnx at least monthly. It should also be available at ftp://ftp.tsoft.net/pub/maschoen/qnx.faq. as well as at http://www.tsoft.net/~maschoen/faq.htm.
74) Is there a de-fragger for QNX? No. At the time I wrote this, there is no disk utility that will de-fragment a QNX disk. It is possible to de-fragment a disk by unloading the fragmented files, deleting them, and then re-loading them. There are numerous strategies that can make this easier. For example, you could have a data only partition, separate from your boot and execution files. Then you only have to de-fragment your data. There is other good news. QNX's Fsys will generally keep the file system somewhat de-fragmented without assistance. It does this by trying to allocate larger and larger segments when a creating or expanding files. This is not a guarentee agains fragmentation, but it helps. It works best in a system where there is sufficient extra free space at all time.
More specifically what is QNX 2.21. This is the latest and probably final version of the original QNX product first created in the early 1980's. While similar to QNX 4.24 in many respects, it differs in many. It is not POSIX compliant, although it has a somewhat UNIX like feel to it. It has similar message passing primitive to QNX 4. QNX 2 is quite old now, and has not been actively supported by QSSL for some time. Current users can still purchase it, and QSSL tries to be helpful with problems.
76) How is QNX 2 different from QNX 4?
A) In QNX2:
A) Processes are called tasks
B) System is limited to 256 tasks
C) No proxies, instead used "ports" which could be "signaled"
D) Interrupts handlers must run masked, limited OS support
E) Limited file system buffering, 64K per disk
F) Only supports Corman arcnet network cards, no fault tolerance, limit of slightly less than 256 nodes, and 2Megabit/second bandwidth.
G) Only GUI supported is QNX Windows
H) No 32 bit code
I) Limited to 16Meg of memory
J) Not well supported
K) No new updates anticipated 77) What new problems are QNX 2 users experiencing
In addition to these limitations, users of QNX 2 are finding other problems in keeping their systems going. The speed of newer processors was not anticipated and has created a few problems.
Thankfully PCI Interface EIDE drives work with the older ISA driver. Larger (> 512Meg) disks are supported with the disk.ata driver or by switching to SCSI. However no PCI/SCSI controllers are known to be supported. This also means that Fast, Ultra, and Wide improvements to SCSI hardware cannot be taken advantage of.
QNX 2, like QNX 4 does a short performance test of the processor that it is running on at boot time. This value is available for tasks that need to adjust for the speed of the processor. Unfortunately, somewhere around a 100Mhz Pentium, this 16 bit value rolls over. The problem is most commonly seen in the floppy driver, but also in the old tape backup drivers. A possible fix is with a "speed_control" program available on QUICS which sets the speed value to 0xffff.
Recently a problem has emerged with the QNX 2 network related to the higher rate of network messages that 486 and Pentium processors can provide. The problem occurs when a fast processor is creating and destroying virtual circuits very quickly. The problem seems to be that when two circuit destroy commands come over the network very quickly, one of them can get lost. This leaves a half open, half closed virtual circuit. Obviously it can't be used, but the real problem is that it is a permanent loss of a resource to the system. If allowed to accumulate, eventually new circuits cannot be created. QSSL has posted a program that may be able to recover these circuits. My personal experience with this program was not successful, however QSSL seemed willing to work on the problems. I have some other suggestions.
A) Try to limit VC creates and destroys. If your application doesn't use too many circuits, leave them open when not in use and recreate them as needed.
B) Try to limit how many VC's you are using. If an application is being run many times, and each copy is opening a VC, it may be possible to route the messages through a concentrator task. If the many tasks were not able to keep the VC open because of limited resources, then the concentrator may be able to.
C) Single thread your destroys. I haven't tried this, but it seems like a possible solution. Always destroy VC's explicitly. Don't let them be destroyed when a task dies. Before each destroy call, Send a message to a "single threading" task. This task should receive messages and reply to them immediately, but wait at least a 1 timer tick between receives. This will slow down the rate of destruction and may prevent the problem.
78) What can and should QNX 2 users do to solve unsolvable problems?
Port to QNX 4.24. QSSL still supplies some valuable migration tools.
79) What Books are available on QNX?
1) "The QNX 4 Real-time Operating System" by Frank Kolnick, Basis Computer Systems ISBN: 0-921960-01-8, $55.00.
This well written book has something for the beginning QNX programmer as well as the seasoned expert. With over 900 pages, there are 14 chapters which address using QNX at a variety of skill levels. I provided a small hand in proof reading the chapters on drivers. I think it is available at amazon.com, though you can check with Frank at fkolnick@sentex.net.
2) "Getting Started with QNX 4 - A guide for Realtime Programmers" by Robert Krten, PARSE Software Devices.
I haven't had a chance to review this book yet, but I will soon. Take a look at http://www.parse.com/book_v1.html for more information. Robert informs me that a Neutrino book is on the way.
3) "The QNX Operating System" (QNX 2) by Frank Kolnick
This classic book is now out of print though Frank might still have some copies.
80) What is meant by real-time
The exact definition of real-time is a subject of some controversy, more because a single definition does not pin it down well, but here's a good explaination to start with.
The following is taken from the comp.realtime FAQ and is one of several listed definitions: (see http://www.faqs.org/faqs/realtime-computing/faq/ )
A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred. Hence, it is essential that the timing constraints of the system be guaranteed to be met. Guaranteeing timing behavior requires that the system be predictable. It is also desirable that the system attains a high degree of utilization while satisfying the timing constraints of the system.
A good example is a robot that has to pick up something from a conveyor belt. The piece is moving, and the robot has a small window to pick up the object. If the robot is late, the piece won't be there anymore. Thus the job will have been done incorrectly, even though the robot went to the right place. If the robot is early, the piece won't be there yet, and the robot may block it.
Another example is the servo loops in a plane when on auto-pilot. The sensors of the plane must continuously supply the control computer with proper measurements. If a measurement is missed, the performance of the airplane can degrade, sometimes to unacceptable levels.
In the robot example, it would be hard real time if the robot arriving late causes completely incorrect operation. It would be soft real time if the robot arriving late meant a loss of throughput. Much of what is done in real time programming is actually soft real time system. Good system design often implies a level of safe/correct behavior even if the computer system never completes the computation. So if the computer is only a little late, the system effects may be somewhat mitigated.
80) What are the differences between QNX 4 and Neutrino
1. Neutrino supports Posix threads, and QNX4 will never have them.
2. Due to threads, Java will only run on Neutrino, not on QNX4. Apparently, Sun Java uses threads extensively, and would be too difficult to port to QNX4.
3. QNX4 will only run on X86, ever. Neutrino supports multiple processor families.
4. Neutrino is targeted more for the embedded systems market, QNX4 for PC's and embedded x86 markets
5. QNX4 compiler is Watcom 10.6, Neutrino compilers are MetroWerks (in Beta) and gnu.
MBA or Micro Business Applications is the dba name for Mitchell Schoenbrun, consultant, and longest known QNX user. I purchased my first license from Syd Geraty (I'm sure I spelled his name wrong) in the early 80's. My serial number was 1040, but I'm now pretty sure that there hadn't been 1039 nor even 39 other sales at that time. Since then I've provided consulting services and products to the QNX community. I can be reached at maschoen@pobox.com and I have a newly created web site at http://www.pobox.com/~maschoen where a number of free software programs may be obtained. Thanks for not complaining about my shameless advertisement.