mdt@information-systems.east-anglia.ac.uk (M.D. Templeton GEC) (04/17/89)
[Moderators Note:- This is probably the most 'Fascist' domain-name I have
*ever* seen -- the mind boggles... - Der]
I was asked this morning by one of our
local bigwigs about my opinion of UNIX for use in a particular
application. This application{needs speed, graphics and needs to be flyable.
I felt that from what little I know of QNX it could be suitable.
I do actually have an old version (I think it's version 1) but no
documentation.
Can anyone tell me of their experiences with QNX, and does anyone have
some old documentation that might match my old version.
Eagerly awaiting your responses,
The Druid.michaelw@microsoft.UUCP (Michael Winser) (05/12/89)
In article <1046@altos86.UUCP> "M.D. Templeton GEC (Alvey" <uunet!information-systems.east-anglia.ac.uk!mdt> writes: >I was asked this morning by one of our >local bigwigs about my opinion of UNIX for use in a particular >application. This application{needs speed, graphics and needs to be flyable. >I felt that from what little I know of QNX it could be suitable. >I do actually have an old version (I think it's version 1) but no >documentation. > >Can anyone tell me of their experiences with QNX, and does anyone have >some old documentation that might match my old version. QNX is a very nice unix-like os that came out of the University of Waterloo. The kernel is split up into 4 tasks: Task Manager Device Manager File Manager Network Manager All communication is through inter-process message sends. The standard send receive reply trio is used. This is not quite true. There are also exceptions (unix like signals) and ports. Ports can be signaled (not the unix signal) or read in a non blocking manner (they can also act as semaphores with a blocking read). They are used primarily for getting interrupts into the system. QNX also supports shared libraries. In fact almost all of the standard 'C' library is in a shared library. This means that a simple programme's executable can be very small (pwd is less than 64 bytes I believe). You can add your own shared libraries quite easily (they are accessed via software interrupts). The filesystem is much better than DOS but not quite as nice as unix. It supports multiple users and (I think) locking. The network support is great. It is trivial to "mount" another machine's drive (or it's entire filesystem) as a "drive" on your own machine. You can load and run across the net (including booting). [2] [3]3:/usr/bin/ls [4]1:/ > [5]/tmp/ls.out Will run /usr/bin/ls from node 3's drive 3 on node 2. Ls will look at node 4, drive 1 and output to node 5 on /tmp (whereever node 5 finds /tmp). I highly recommend the protected mode version of QNX. It is much more secure and can use all 16Mbytes of address space. QNX's biggest problems are its compiler and other software. The compiler (when I last used it) did not support large memory models. I and D space is limited to 64k each. There is however a hack in the compiler allowing the programmer to access other segments (which can be allocated from the os). The -} token (no typo) references of the es register instead of ds. We used this (in Toronto) to build a fairly sophisticated object oriented programming environment. The data segment was for locals and "oop system" stuff and our "send" function would set up the es to be the object's instance space. The other big problem is software. There is precious little canned software for the machine. You have to write your own drivers for almost any new hardware. Fortunately this is quite easy. Interrupts are translated into signals to a port and your driver just hangs around reading signals from a port and doing all the work in a scheduled and orderly manner. I had not trouble writing drivers for a speech board and a telephony board last summer. Overall, QNX is a nice operating system for standalone applications. If your code size is going to be huge and does not lend itself to being spread across tasks and shared libraries then you might have problems. QNX is sold by Quantum. You can reach them at: Quantum Software Systems Ltd Kanata South Business Park 175 Terrence Matthews Crescent Kanata, Ontario Canada K2M 1W8 Their technical support is generally pretty good and quick too! Michael None of these opinions are those of Microsoft Inc. -- /\ no guts michael winser \/ no glory microsoft corp. (206) 882-8080, michaelw@microsoft.uucp
peter@ficc.uu.net (06/12/89)
I was also under the impression that QNX does NOT implement the fork() system call. This is just fine for realtime work (fork() is a pig), but it's not adequate in a development environment where you're going to want to run your favorite UNIX tools. I could go into why fork() is a lossage for non-VM systems, and how it's cool for VM, and so on... but I won't. --- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
jmberkley@watnext.waterloo.edu (J. Michael Berkley) (07/07/89)
In article <1226@altos86.UUCP> peter@ficc.uu.net writes: > I was also under the impression that QNX does NOT implement the fork() > system call. This is just fine for realtime work (fork() is a pig), but > it's not adequate in a development environment where you're going to want > to run your favorite UNIX tools. No, QNX does have fork(), and it works very efficiently. I once wrote a terminal emulator for QNX that used fork() to start two copies of itself, one task for each of the screen, keyboard and serial port. QNX also shares code, so the only memory overhead was the data. Inter-task messages under QNX are so efficient that using the three tasks with inter-task messaging made the emulator faster than one monolithic task polling the keyboard and serial port. Mike Berkley, University of Waterloo PAMI Lab jmberkley@watnext.waterloo.edu {utai,uunet}!watmath!watnext!jmberkley
bahman@nixtor (Bahman Koohestani) (07/11/89)
>QNX has a fork call and it works very efficiently.....
Yes, QNX does have a fork call; it also works very "efficiently", however,
it is brain damaged. Why???? Because it is nothing like the unix fork() call.
It does not let you pass file descriptors or file pointers to the son task. All
it does is that it allows you to create a son task and then you must re-open]
any files that you would have expected to inherit from the parent task.
QNX is a good system for real time (process control) applications, it is
not as open as unix is in a lot of different ways. fork () also has a lot
of other side effects (depending on the version of QNX you are working with).
At one point, one could not create a background task from another background
task..... SO WHAT?jmberkley@watnext.waterloo.edu (J. Michael Berkley) (07/12/89)
In article <3505@altos86.Altos.COM> bahman@nixtor (Bahman Koohestani) writes: >QNX has a fork call and it works very efficiently..... Yes, QNX does have a fork call; it also works very "efficiently", however, it is brain damaged. Why???? Because it is nothing like the unix fork() call. It does not let you pass file descriptors or file pointers to the son task. All it does is that it allows you to create a son task and then you must re-open] any files that you would have expected to inherit from the parent task. Agreed! This behaviour comes as a result of one of QNX's other weird qualities. QNX's filesystem is fairly fragile, in my opinion, and one of the things that they have done to enhance stability is a mandatory file locking concept: a) many people can open a file for read b) only ONE person can open a file for write, c) files cannot be opened for read and write (i.e. you can't open it for read if someone has it open for write and you can't open it for write if someone has it open for write). So, of course the child process cannot use the same file descriptors as the parent - some of those descriptors might be for write. I found this behaviour very frustrating at times. Imagine something like news, where you couldn't unspool news if someone was reading the active file. QNX file locking makes this kind of administrative stuff more difficult. I never got used to it. QNX is a good system for real time (process control) applications, it is not as open as unix is in a lot of different ways. fork () also has a lot of other side effects (depending on the version of QNX you are working with). At one point, one could not create a background task from another background task..... SO WHAT? Lest anyone forget, QNX is not Unix. If you buy QNX expecting fast, real-time Unix on your PC, you may be disappointed. However, QNX does have other features that make it a nice, elegant system to work with, but it's not Unix. I prefer Unix, but I could live with QNX if I had to and needed real-time. Mike Berkley, University of Waterloo PAMI Lab jmberkley@watnext.waterloo.edu {utai,uunet}!watmath!watnext!jmberkley