stone@usfvax2.UUCP (Scott Stone) (07/13/87)
I am considering buying a product called "QNX", which is the
product name for a unix system that runs on PC's. Does anyone out
there have any specific experience with QNX? Can someone give me
the low-down on the real advantages/disadvantages of this product?
I know that it is not as well known as SCO, or Microport, but appears
(at least is advertised to be) much faster than any of the others.
This is probably because it is much smaller, and does not have many of the
standard unix features, but for the application I intend, this is not
as important as the speed.
Thanks, in advance,
--
Scott T. Stone, University of South Florida, Tampa 33612 (813)974-3307
UUCP: {codas,gatech,ucf-cs}!usfvax2!stone
ARPA: stone%usf.edu@csnet-relay.ARPA CSNET: stone@usf.edujr@amanue.UUCP (Jim Rosenberg) (07/16/87)
In article <789@usfvax2.UUCP>, stone@usfvax2.UUCP (Scott Stone) writes: > I am considering buying a product called "QNX", which is the > product name for a unix system that runs on PC's. Does anyone out > there have any specific experience with QNX? I've been using UNIX for quite a while now, but have only made the acquaintance of QNX in the last few months. I specified it as an operating system for a user interface machine to be connected to a real-time process control system. The long and short of it is that QNX is an elegant operating system indeed, but not related to UNIX in any way whatsoever, except that it presents a somewhat similar user interface. I don't know where you heard that it was a "unix system", but this is *VERY* incorrect. I bring to it my UNIX prejudices, of course, but for what it's worth here is my evaluation of QNX. BTW, there was an excellent article on it in (I think) January PC Tech Journal. STRENGTHS: QNX is built from the ground up around message-passing. If you've read Andy Tannebaum's MINIX book you'll know excatly what I'm talking about. QNX messages can be any size (up to 64K) in no specific format. When a task sends to another task, the sender is send-blocked if the receiver is not waiting for it. What is interesting, however, is that when the receiver receives the sender becomes *reply-blocked* waiting for a reply, and (here's the good part) when the receiver replies reply() is guaranteed to be non- blocking. This is very cute. It means servers can easily be written which exchange messages with clients, but where the server can be guaranteed not to block on the action of an ill-behaved client. QNX supports another form of non-blocking interprocess communication called "Ports". Signalling a port sends a zero-length message, essentially, and it does not block. These queue, so that if n signal()s occur before a task does an await() it will not block for the next n await()s. The QNX analogue of UNIX signals, called exceptions, are handled pretty well too. An exception can be permitted but not allowed. A task receiving an exception under these circumstances will have a pending bit set for the exception, and can poll for it. QNX seems not to have that horrid disease of non-Berkeley-UNIX where there is a window in which a second signal too rapidly can't be caught. The message passing architecture allows them to deliver a full distributed file system in their networked version. I know of no other product delivering a distributed file system that will run on 8088s. Messages can be sent transparently to other tasks across the network. The operating system comes with libraries that have a hefty set of device independent primitives for bit-mapped graphics. I recently ported a demo from CGA graphics to EGA graphics. After downloading their EGA shared library, all it took to get the code changed from mono 640 x 200 to color 640 x 350 was to change the setting for the bottom pixel number and change the settings for variables assigning colors. Took maybe 10 whole minutes. Impressive. There is a scheme whereby a task may adopt a device and redirect messages. Using this they have developed an MS-DOS file system administrator. (Actually a 3rd party developed it, but they sell it.) This allows full QNX semantics for most commands transparently on DOS files, including files on the DOS partition of the hard disk. They also sell a product called QDOS, which runs DOS underneath QNX as a task. It works. I've successfully run Dan Bricklin's Demo program with it, just as one example. So: You get multi-user, multi-tasking, message-passing, elegant interprocess communications, in the networked version fully distributed file system, device independent bit-mapped graphics, and oh I forgot to mention you can have up to 4 virtual terminals at the system console. **MOST** impressive!! There is a protected mode version for AT's, and the QDOS DOS-under-QNX works with that too (I haven't tried that.) Quantum support is *EXCELLENT*!! They maintain an on-line system, and since they wrote the code they've got the answers. There is also a hotline you can call. Their update system lets you download fixes and beta test releases as soon as they're done. In one case I asked a question about how exception handling worked in a certain case, and was greeted by the actual source code for exception handling! WEAKNESSES: As with OS-9, when viewed as a software development engine QNX offers a strong alternative to the functionality of maybe 15% of UNIX. Not only are the super-tools like yacc and lex and awk missing, the medium level tools are missing too. No sed, for instance. They have an asynchronous pipe administrator, but the standard shell uses temporary files for pipes. grep won't work when hung on the end of a pipe. That tells you in one sentence that the author(s) of the tool kit don't have a clue what a tool kit is really all about. There is no lint, and it shows. The standard header files are full of monstrosities, like using unsigned for addresses and declaring 0- length arrays, which is not standard C. If you are buying it as a software development environment only then these things are serious, and QNX can't hold a candle to VENIX, SCO, or Microport. It's not even in the same league. Porting software to QNX is decidedly non-trivial. Just as a for-instance, someone decided that it should be illegal to open a device for both reading and writing!! The logic of this absolutely escapes me. It means some serious hacking on anything like communications programs. The C library is missing read() and write(). They use the FILE calls for all I/O, but also have fget() which is something like UNIX read, and fput(), which is something like write(). Again, this means major hacking for UNIX code. In many cases porting software to QNX means writing an administrator. This is like a UNIX daemon, but a QNX administrator is immortal -- i.e. not killed by exceptions -- and has special duties to inform other administrators when tasks die, and so on. Not like writing a device driver, by a long shot, but there will certainly be a learning curve writing an administrator for the first time. Major major major parts of the operating system are *NOT DOCUMENTED* and probably never will be. What counts as the UNIX kernel is modularized into a task administrator, file system administrator, and device administrator, which of course communicate by message passing. (Wonderful, Quantum rightly toots their horn over this.) Unfortunately there is no documentation at all for these administrators at the message level. The messages that the mount command sends to the task administrator are not documented. Quantum can be excused, I guess, for not wanting to support code at this level, but it makes me nervous to have an operating system where the developers keep secrets. If a program that operates at the user level needs undocumented information to work, something is wrong. In other places the documentation is misleading or inaccurate. E.g. it states that an exception handler is called with no arguments (wrong). It states under fopen() that only one task may read a device at a time. I interpreted this to mean that fopen() would fail for a second task. No, fopen()s are stacked -- the second fopen() will get all the characters, on close the first fopen() gets back its access. Now this is just fine -- the code does the right thing! -- but the manual can't always be counted on to tell you that the code is doing the right thing. SUMMARY: If you need a multi-tasking multi-user operating system for PC or AT type equipment and it doesn't have to be really UNIX, QNX is a genuinely elegant operating system. As a C software development platform it doesn't cut it -- and is actually more expensive than Microport. Why QNX is not more popular is a major mystery to me. It has been for a long time what everyone will decide OS/2 should have been, once OS/2 struggles into the light of day. The only thing I can figure out about why QNX is not more popular is that Quantum doesn't know how to sell it. Here's an example. I've been wanting to play with it for years, but wasn't going to spend $600 just to play. I called them asking for a list of vertical market packages and 3rd party software solutions built around QNX, hoping to make it part of a consulting project. THEY DIDN'T HAVE SUCH A LIST!! They sent me their literature, which is a marvellous treatise on their kernel architecture. As a card carrying operating systems junkie I loved it. But IT DIDN'T MAKE ME BUY. Hopefully this will change. QNX deserves much more attention than it's getting. Disclaimer: I have no connection with Quantum, etc. etc. -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg seismo!cmcl2!cadre! /