QNX4 Configuration Files 


This is the alternate boot image. During booting the QNX boot loader will display the message


	Press ESC to boot alternate OS
By pressing the escape key at this point QNX will load this file instead of /.boot. If you have made some changes to your boot image, copy the old version to /.altboot and then if you have any problems you can at least get your system to how it was, rather than re-installing it.



This is the Operating System boot image that is loaded into RAM by the QNX boot loader when the machine is powered up. It must reside within the first 1024 cylinders of the hard disk (a PC BIOS limitation, not a problem with QNX) and should be smaller than 512K, although future revisions of QNX will address this issue.



The default QNX installation assumes that your machine is node 1, so it creates hard.1. This will need to be changed if you are running in a networked configuration. Also, you may wish to customise the QNX system that you are running. This file contains the parts of the Operating System that you wish to include in your /.boot file. An example may look like this:


    $ 52000 Proc32 
    $ 1 Slib16
    $ 1 Slib32
    $ 8000 Fsys
    $ 1000 Fsys.eide
    $ 1000 mount -p /dev/hd0 /dev/hd0t77 /
    $ 1000 sinit TERM=qnx
To convert this information into a QNX boot file you need to perform the following:
    cd /boot
    buildqnx -v build/hard.1 images/hard.1
    cp images/hard.1 /.boot
Everything in the boot configuration file is relative to the /boot directory, unless it has a full pathname. (See the difference between sys/Proc32 and /bin/Fsys.) So the make must be performed in the /boot directory. Also it is a good idea to link it with a disk driver so that QNX can load things like sysinit from the disk once it has started; this is the d= option. A file called /boot/images/hard.1 will be created. This is your new QNX boot image. For QNX to be able to use it you must copy it into the /.boot file.



QNX is a multi-tasking, multi-user system. This means that more than one user can connect to a machine running QNX and work on it, whether through terminals or a network. What happens if two users try to print a file at the same time? To save worrying about this QNX has a thing called a spooler. This is a queue management system. All files to be printed go into the queue and depending on a set of rules QNX will send the files to a printer as soon as one is available.

/etc/config/lpsrvr tells QNX about the queues, printers and rules that it should use when performing these functions. A typical file would look like this:


    co=lps -F4 -P12 $(spfile) > $(device)
    co=cat $(spfile) > $(device)
The file is split into sections and each section is delimited by the square brackets, [ ]. The first section must exist but everything else is optional. It tells QNX which spooler to use. /qnx/spooler2 is the default spooler for node 2, /qnx/spooler3 would be the default spooler for node 3 and so on. It also tells QNX where it should store the jobs until they are ready to be rinted, /usr/spool/lp in this case.

The first item [doc] describes a queue to QNX. The queue is called doc and any job that ends up here should be sent, eventually, to the device represented in lpt (the target). The co command tells QNX that it must do the following processing on the file after it has queued it but before it copies it to the device. In this case it formats plain text into PostScript output.

The second item is another queue, called ps. This one just does a straight copy of the files to the device.

The third item [-lpt] is a target device. This is indicated by the "-" preceding the name. It says that the device to be used by target lpt is the parallel port on node 2. It could have been any printer device on any node in the network. For example //12/dev/par3.

This example shows how we can use the queue mechanism so that both Postscript jobs and text documents can share the same PostScript printer. It is possible to have more than one target and any queue can send to any target or a number of targets may be specified so that if the first is unavailable the second will be tried and so on.



Each QNX machine on a network must have it's own unique logical node number. These start at one and generally increment each time a new node is added. This is fine but how does each machine know the address of any other on a network.

For historical reasons the default QNX network type is Arcnet. Each node on an Arcnet network can have a node number ranging from 1 to 255 so the default contents of this file are:


This means that Arcnet physical node 1 is QNX logical node 1, and so on. This isn't particularly helpful if you want to run Ethernet between your QNX machines. You need to change the contents of this file so QNX knows how to map logical node numbers to real life physical network addresses. For example:


1   1   02cf1f09ed23
2   1   02cf1f23a234
3   1   02cf1f876ad0
The left column is the QNX logical node number. The middle column is the QNX logical network number (more about this in a minute). The right column is the physical address of the network adaptor in the machine. Each of the three QNX nodes described in the above example must have an identical copy of this file if they are to communicate together.

QNX also supports many networks in a single machine. The limit currently is about 37 networks in a single machine but since that is far more than the number of slots in a PC you don't have to worry. The middle column above is to tell QNX which network to route traffic down to get to it's destination. So I could mix Arcnet and Ethernet networks like this:

1   1   02cf1f09ed23
2   1   02cf1f23a234
3   1   02cf1f876ad0
1   2   1
4   2   2
5   2   3
I have added an Arcnet network and two extra nodes (logically 4 and 5) with Arcnet ids 2 and 3. I have to put node 1 in twice because it has two network connections.

Node 1 is sitting on both networks. There is a utility in QNX called netbridge that would allow me to use node 1 as a bridge between both networks. This is outside the scope of this document and if you would like further information please mail support@anglia.demon.co.uk



Once the system has booted the first thing it does is process this file. If you are running on node 3 and /etc/config/sysinit.3 exists then that is processed instead of the default. This file simply contains a list of QNX commands and comments. A simple example would be:


#set time zone and get clock from PC hardware
rtc -l hw
#Start device manager and console, serial and parallel device drivers
Dev &
Dev.con -n 4 &
#Need to reopen /dev/con1 for STDERR,etc.
reopen //0/dev/con1
Dev.ser &
Dev.par &
#Start Floating Point emulator - Many QNX apps need this
#Not necssary on 486 or better
emu87 &
#Start Network manager and arcnet device driver
Net &
Net.arcnet &
#Sort out node mapping
netmap -f
#Spawn logins on the console devices
tinit -t /dev/con1 -T /dev/con[2-4] &
It can be thought of as a cross between DOS' autoexec.bat and config.sys. Any of the QNX device drivers and system managers can be started and stopped from the command line but having them all started in sysinit is more convenient.



This file is used by the system to determine to which group users belong. A typical example may look like this:


    sales::100:gary trevor ralph tracy
    technical::101:bob imogen
The first two lines are for system use only and must exist, the rest are optional. In this example we have set up two groups sales and technical. Sales have group id 100 assigned to them and technical have group id 101. Each group has a list of users associated with it. Access to everything in QNX is based upon permissions. It is possible to allow a file to be read by sales although the technical department can both read and write it.



This file contains the sign on banner that is displayed on the console when the system boots up. The default is:


  Welcome to QNX 4.23
  Copyright (c) QNX Software Systems Ltd.1982,1994
You can change this to read anything you like.



This isn't really a file but a directory that contains all the licenses to run QNX or it's applications. Each file in here is 100 bytes in length and corresponds to a particular utility in the QNX system. If you had installed QNX and the RunDOS DOS emulator then your /etc/licenses directory would contain two files that would look a bit like this:


If you had a two node QNX network then you would need both QNX licenses in this directory because as far as QNX is concerned you only have 1 licensed copy so it will not talk to anyone else.

QNX license files cannot be copied; if you try to copy them they simply will not work. You must use the license utility to transfer them from the original floppy disk to the /etc/licenses directory on your hard drive.

With the advent of QNX 4.23A this style of licensing is becoming less and less common, moving to the new style licensing. These new style licenses are kept in the /.licenses file and look like this:

tcprt.00766641-0r22-08ab-1i73-0k56-0174 (1 node)
phinx.00200541-0dez-5ib9-2924-b7r6-f511 (2 node, 0597 expire)
  nto.00276259-0faf-9420-9998-f1rb-09c5 (1 node)
 vpro.00054687-060a-ke03-jat5-9879-3fe9 (20 node, 0897 expire)
The advantages of the new style are that timed licenses can be given and that you can ring up and get a new license number over the phone for a product which is included on your QNX CD-ROM.



This file is printed as part of the standard /etc/profile. It is used for displaying messages to all users as they login. For example you may want all users to know that a certain printer is not available today. This is a convenient way of ensuring that they will all see the message.



This contains information about users on the system. Based on the /etc/group discussion earlier, it might look like this:


gary:x:100:100:Gary Jones:/bin/sh
trevor:x:101:100:Trevor Smith:/bin/sh
ralph:x:102:100:Ralph White:/bin/sh
tracy::103:100:Tracy Brown:/bin/sh
bob:x:104:101:Robert Harris:/bin/sh
imogen:x:105:101:Imogen Clarke:/bin/sh
Let's look closely at the entry for gary to determine what it all means. 'gary' is the login id that will be used. The semicolons are field separators and can be ignored for our purposes. The 'x' indicates that gary has a password associated with his account. (In fact all the users except tracy have a password.) 101 is gary's user number. 100 is gary's group number (if you look back at /etc/group this is group 100 - sales). Gary jones is his real name - if you do anything like electronic mail or some system logging functions then gary would be expanded to Gary Jones by QNX. /bin/sh is the command interpreter that gary will be using.



This file contains a list of instructions and macros that are executed when any user logs into QNX. It does things like check the users mailbox and sets any environment variables that are required. For example the search path PATH is set here. When a user logs in /etc/profile is run and then the .profile file in the user's home directory. Anything that is set or unset in the user's .profile file over-rides the settings made in /etc/profile. It is a good way of restricting a particular user or granting a particular user extra privileges.

A typical file would look like this:

    export PATH=$PATH:./:/bin32:/usr/bin/X11:/usr/lib/X11:/etc
    umask 2
    if [ ! ­f .hushlogin ]; then
        cat /etc/motd
    date "+%x%t[ %I:%M %p ]"
    if[ $LOGNAME != "root" ]; then
        test ­s $MAIL && echo "You have mail."
    stty quit 1C term=$TERM
    export DBDPATH=/usr/db
    export DBFPATH=/usr/db
    export LPSRVR=/qnx/spooler2
    export LPDEST=doc


This file holds all the passwords for the users. They are encrypted and mean nothing to anyone looking at them but it would look something like this:

QNX Disaster Recovery

The QNX filesystem is very robust. Data is usually written to a cache before it gets written to disk. Whilst the data is in the cache it is ordered so that it can be written with a single sweep of the heads across the disk platter when the cache is flushed. The cache is flushed every two seconds but the system administrator can set this interval. This caching also be disabled.

All critical filesystem data, such as bitmap blocks or directory entries are written immediately to disk, bypassing the cache. In the event that multiple pieces of critical data are to be written concurrently they are ordered in such a way that if the power goes down midway through the operation the filesystem will come up sane and at worst a few blocks will have been assigned that aren't used. Unfortunately, you've lost the last two seconds worth of data in the cache but your system is able to get up and running immediately. Even if the worst happens and you have a corrupt filesystem, QNX has a series of utilities that are designed to repair and rebuild damaged filesystems. These will be discussed here.



This is the main tool that you will use in recovering damaged or corrupted filesystems. It checks the directory structure of the entire disk partition, reports any inconsistencies and fixes them if possible. In addition to this is verifies the overall disk block allocation and optionally writes a new /.bitmap file.

chkfsys requires that the filesystem is idle - it CANNOT be run whilst users or applications are making use of the filesystem as this would lead to inconsistencies in the newly created data. If you can't afford to shutdown your application to run chkfsys you can run it in read-only mode where it will just report it's findings and not try to fix anything.

It starts at the root and works down the filesystem, building an in-memory copy of what the /.bitmap file should be. Once it has finished this it checks that against the /.bitmap and asks the user if it should write a new /.bitmap. Whilst it is doing this it will try and tidy up any little problems that it finds. It will clear busy bits on files and re-write the files size if it differs from the amount of data in the file and things like this.



This utility creates the following:
  • boot block
  • root block
  • bitmap blocks
  • root directory
  • inode file (/.inodes)

Once these have been created it is up to Fsys to maintain them. Running dinit on a filesystem will effectively clean it. chkfsys assumes that your root block has been unaffected by the disk corruption. Sometimes this is not the case; you can run dinit -r to rewrite a blank root directory and then by running chkfsys it will be able to rebuild the filesystem from there. This should be used with extreme caution.



This utility creates and maintains the partition block on a hard disk. This can be used to re-build partitions or re-create missing or damaged partition loaders.



This utility allows you to read and write the raw data on a disk and to fix problems at a bits and bytes level. This cannot be used on a disk that has open files on it.



This lets you removes files from the disk without returning the used blocks to the free list. This is useful if two files occupy the same space on the disk or the directory entry has become damaged. To recover the blocks and check the filesystem, run chkfsys.


QNX Information Gathering Functions

There are several utilities in QNX that allow you to see what's going on inside the OS and it components. Probably the most widely used is the sin command. it stands for System INformation. For more details please see the entry in the user guide. Sin outputs information about all running processes, their versions, system interrupt handler, proxies, memory usage and a whole host of other pieces of information.

The next is stty. This allows you to take a look at what is happening on any of the QNX character based devices, including consoles, serial and parallel ports and change their values. It displays the status of the hardware signals, the mode that the device is operating in and the parameters that it is currently using.

Netinfo is particularly useful when trying to diagnose QNX networking problems. Any time something strange happens on any of the QNX networks an event is logged to netinfo. Netinfo includes the time of the event and an english explanation of what the error means.

Traceinfo queries the Process Manager's internal table of trace events. When an interesting event or a problem occurs most QNX processes log an error within this table. Traceinfo allows users to see what events have been generated. It is especially useful for debugging Interrupt handlers, where the standard print commands cannot be used.

Input Touch Screen through QNX Windows

Touch doesn't provide particularly comprehensive support for Touch Screens. The newer Input, as used with Photon, provides a much broader support for Touch Screen devices. The trick is to use Input to communicate with the underlying hardware and to interface this to Touch to provide the events required by QNX Windows. Hopefully, this archive will help some way towards that.

The files in this directory need to be moved as follows. (It might be a good idea to make backups of your originals)


Input /bin/Input
Touch.input /bin/Touch
TCalib.32 /bin/TCalib.32
Mouse /bin/Mouse

Once this has been done you'll need to run the following:

Mouse &

To start the Mouse server for use with QNX Windows.

Input -d/dev/mousein ps2 -r kb -2 &

Start an Input driver to talk to a PS2 mouse but use the mousein File Descriptor to communicate to the Mouse server with. This is required for use with QNX Windows.

Touch &

Start the Touch Screen server for use with QNX Windows.

Input -d/dev/touchin intellitch elo &

Start an Input driver which will access an Intellitouch screen and communicate with Touch via it's File Descriptor interface. For a look at which drivers are supported type


	use Input

/windows/bin/gr.vga &

Start the QNX Windows graphics driver in order for the calibration program to run.


Follow the instructions on screen to calibrate the Touch Screen with your graphics card. Once this is complete have a play with some of the other options:-) When you are finished exit this program and enter:


to start QNX Windows in the normal way.

Click HERE to download the drivers and utilities mentioned in this note (approx 92K). The archive can be extracted using the following command:

melt -c tqw.tar.F | tar -xv

The files will be extracted into a directory called tqw in your current working directory.


Compiled by Richard Copeman.

How To Access Resources of a Windows 95 Computer From QNX Using Smbfsys


There are many cases when it is handy to access resources on another computer connected to the network. Now it is possible with QNX to access resources on a Windows 95 computer. These detailed step-by-step instructions will help you to configure the systems to do this. You will set up the sharing access permissions on the Windows 95 system so its resources can be accessed and run SMBfsys to mount the remote Windows 95 resources for the QNX computer.

You need:


  1. QNX and Windows 95 computers connected on the same network.
  2. For the QNX computer, QNX version 4.23A or later and TCP/IP 4.23A or later.
  3. The other computer should have Windows 95 installed.
  4. This document does not discuss installation and configuration of TCP/IP, which must be already installed and configured on both computers.


Set Sharing Permissions For The Windows 95 Resources:

If you already share the resources with other Windows 95 computers, most of this will be already done. Follow these instructions to verify the names and passwords.

  1. Select Control Panel, Network, Configuration, File & Print Sharing.
  2. Put a check mark in both the files and printers boxes as desired and click OK.
  3. Select TCP/IP->Ethernet Adapter with the mouse, then click Properties.
  4. Make a note of the IP Address of the computer, then click Cancel.
  5. Select the Network tab Access Control. Choose the access control method you desire.
  6. Select the Network tab Identification.
  7. Enter a Computer Name and make a note of it (The Workgroup is not used by the QNX connection, but should probably be changed to something other than WORKGROUP, to make it more difficult for others to access the computer via the Internet, if connected.)
  8. Click OK to close the Network dialog.
  9. If you have made any changes, you will need to reboot now.
  10. Open My Computer.
  11. Position the mouse over Drive C and click the right mouse button.
  12. Select Sharing.
  13. Choose Share As.
  14. Enter a name into Share Name and make a note of it.
  15. Select Read-Only or Full Access as desired and enter a password.
  16. Make a note of the password too.
  17. If you wish to access the CD-ROM drive, repeat the same procedure for it.
  18. Click OK.
  19. If you wish to access printers, double-click the Printers icon to open it.
  20. Repeat the procedure for the printers you wish to access.
  21. Unless you want to, it is not necessary to protect the printer with a password.


Check The TCP/IP Connectivity:

If TCP/IP is incorrectly configured, the following instructions will not work. On the Windows 95 computer, go to an MS-DOS command prompt and type:


  ping <ip_address_of_QNX_computer>

You should get messages of Reply from, including a time in ms. Press Control-C to stop. On the QNX computer, type:


  ping <ip_address_of_Windows95_computer>

You should see similar messages. Press Control-C to stop. If you received error messages, such as Request timed out, you will need to properly configure the TCP/IP on one or both machines before you continue.


Mount The Windows 95 Resources On The QNX Computer:

As root, create a script to execute the following commands. Items in triangle brackets should be substituted with the actual values noted when the Windows 95 computer was configured. Do not type the triangle brackets. Do not key in the comments on the right. You can create the script with a text editor. It may be most convenient to do this in a directory that is included in the search $PATH.


  #! /bin/sh                        This should be the first line of each script
  # Mount Windows 95 Resources
  SMBfsys -d20 &                    -d is idle disconnect time in minutes
  sleep 1
  user_smb <windows_network_login_name> < windows_network_login_password>
  mount_smb -mu //<comp_name>:<ip_address>/<disk_c_name> /w95diskc <disk_c_passwd>
  mount_smb -mu //<comp_name>:<ip_address>/<cdrom_name> /w95cdrom <cdrom_passwd>
  mount_smb -p //<comp_name>:<ip_address>/<prt_name> /dev/w95prt <prt_passwd>

For an actual example, assume the identification name of the computer is GATES and its IP Address is Its drive C share name is DISKC and password is cpass and it will be mounted as directory /diskc. Its CD-ROM share name is CDROM, no password (blank), which will be mounted as /cdrom. Its printer share name is HP6P and has no password. It will be mounted as /dev/hp6p. The Windows Network Login name is bill and his password is rich. So the example script, called mount_w95 would be:


  #! /bin/sh
  # Mount Windows 95 Resources
  SMBfsys -d20 &
  sleep 1
  user_smb bill rich
  mount_smb -mu //GATES: /diskc cpass
  mount_smb -mu //GATES: /cdrom
  mount_smb -p //GATES: /dev/hp6p

For testing, add a line in the script after the /bin/sh line:


  set -x

This will display each line of the script as it executes. Save the file and exit. The permissions of the text file need to be changed so that it can be executed as a command. Type:


  chmod 700 mount_w95

This script must be run by root.

Run your script. At this point you can type ls /diskc and see a directory listing of the root directory of drive C of the Windows 95 computer. If everything works as expected, remove the set -x line from the script. If you wish to set access on the per QNX user basis, remove the user_smb line from the script and have each user run it individually. You could add it to their $HOME/.profile. If a password is not included, the user will be prompted for it.

You will likely want to modify the QNX spooler to copy data to the new device. Depending on the printer and the application that creates the print data, you may want to use a control program to append a form feed to eject the page at the end.


Special thanks to Jeff Page (jpage@qenesis.com) for this document.