Hier finden Sie Antworten zu häufig gestellten Fragen über QNX® . Vorerst leider nur in englischer Sprache.
© 1999, Mitchell Schoenbrun, Micro Business Applications

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 QNX® 4 microkernel cannot. The QNX® /Neutrino microkernel + process manager is about 64K, which is half the size of the QNX® 4 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.

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.

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.

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/samples/manpages/neutrino-faq.html which you might want to look at.

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.

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.

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. BitCtrl Systems is the German QNX® Distributor.

QSSL would rather 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.

"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.

For a list of prices write an Email to BitCtrl.

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.

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.

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 (BitCtrl). A service plan gives you credits that let you call the QSSL technical support line. 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. BitCtrl Systems offers some courses. QSSL also provides a number of QNX® related courses.

E) Hire a consultant.

QNET 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.

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.

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

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.

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.

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.

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.

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.

There are a few different classes of hardware that must be interfaced to, each with their own details.

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.

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.

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.

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 );

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.

Check whether you compiled your program with the "- T 1" parameter. Also make sure that you run the program as super user.

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.

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.

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.

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.

You can connect to QUICS using several different methods each listed below:

* telnet://quics.qnx.com

* ftp://ftp.qnx.com/

* http://www.qnx.com/

Yes, QNX® news 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.

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.

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.

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/

GCC is available, at following URL http://www.teaser.fr/. 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.

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.

QNX® ships with vedit and vi, there are ports available of crisp, micro emacs, gnu emacs, pico, and a few others.

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.

Try configuring your local interface.

Try adding a nameserver directive to resolv.conf. Here's an example:

nameserver 192.1.2.3

Must have a registered domain name to use quics. Quics will perform a reverse mapping of your site-name.

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.

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.

Check the ownership and permissions on the .rhosts file, the file must be owned by root, and be set to 644.

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"

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

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.

Yes, you must be running the Net.fddidfe driver, see the section on hardware for which FDDI network adapters are supported.

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

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.

Take a look in ftp://ftp.QNX.com/etc/readme/hardware/network_support.

Take a look in ftp://ftp.QNX.com/etc/readme/hardware/scsi_support

Take a look in ftp://ftp.QNX.com/etc/readme/hardware/audio_support

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.

Take a look in ftp://ftp.qnx.com/etc/readme/hardware/pcmcia_support.

Take a look in ftp://ftp.qnx.com/etc/readme/hardware/X_video_support

Take a look in the knowledge base on www.qnx.com.

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.

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.

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.

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

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.

Port to QNX® 4.24. QSSL still supplies some valuable migration tools.

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 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.

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.

1. Neutrino supports Posix threads, and QNX®4 will never have them.

2. Due to threads, Java will only run on Neutrino, not on QNX® 4. Apparently, Sun Java uses threads extensively, and would be too difficult to port to QNX® 4.

3. QNX® 4 will only run on X86, ever. Neutrino supports multiple processor families.

4. Neutrino is targeted more for the embedded systems market, QNX® 4 for PC's and embedded x86 markets

5. QNX® 4 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.