Path: utzoo!utgpu!water!watmath!focsys!larry From: larry@focsys.UUCP (Larry Williamson) Newsgroups: comp.sys.ibm.pc Subject: Re: QNX anyone? Summary: I love it and hate it. It's great and awful. etc. Message-ID: <189@focsys.UUCP> Date: 20 Jun 88 15:39:08 GMT References: <22273@tis.llnl.gov> Reply-To: larry@focsys.UUCP (Larry Williamson) Organization: Focus Automation Systems Inc. Waterloo, Ontario. Lines: 169 Sorry about the excessive length of this posting. I would have kept it shorter, but I had so many things to say about this operating system. In article <22273@tis.llnl.gov> bae@ati.tis.llnl.gov (Hwa Jin Bae) writes: >Is anyone out there using QNX? [ ... ] I spent two and a half years working exclusively with QNX while I was employed at Automation Tooling Systems (ATS) here in Kitchener. ATS is a producer of factory automation systems. QNX was (and is still) used in a cell controller function and as a supervisory system. ATS also uses QNX in a big way as their office system and development environment. They have about a 70 node system in house. > This message passing OS recently caught >my eyes again and I would like some detail information on: > > 1. Developement environment: > How's their C compiler and debugger? > How's their Assembler - or do they have one? > If they has an Assembler, is it MASM compatible? Their compiler is okay. There are a number of non-standard extensions that make the compiler very nice to use in a purely QNX environment. If you hope to port software into the QNX environment, it's not too difficult. If you wish to port software from QNX to DOS or UNIX, then this is a pain in the butt. You will most likely find yourself using all of the extensions because they are sooooo nice. But then your stuck with them. Their assembler works well enough. I like it because it is very difficult to write large programs with. This forces you to use C to write almost everything. The only time I ever had to use the assembler was in a task that needed to know the current data segment. This was solved in the C program using inline assembler code. Very simple and non portable. ( I did not have to do it this way, I just chose to ). > 2. Device Drivers: > What's envolved in writing a device driver for QNX? This is very simple. The only thing that is difficult is determined by what device you are driving. The QNX interface is clean, simple and easy to understand. Compared to unix device drivers, QNX is trivial. Compared to dos, QNX is clean and straight forward. > 3. Is it really worth $695 for runtime and development package? I guess this depends on your needs. If you really need a realtime multitasking os, then the cost is peanuts. Have you checked out the cost of RMX from intel? The Intel's C compiler alone costs this much. If all you really need is multi tasking, then spend less and get unix from sco, microport, bell technologies, interactive, etc. Their editor is good, easy to use, clean command set, fast screen updates, and contains some nice powerful features. > 4. How's their networking (ARCnet board)? This is probably the BEST feature of the system. I loved it. Every keyboard, every screen, every disk (hard and floppy and ram based), every cpu, every serial port, every parallel port, everything is accessable from the network. And if you design your software properly, it is all transparent. To give you an example. One of the projects I worked on at ATS we wrote the software assuming the entire machine would be controlled by one XT (This was 2 1/2 years ago and protected mode QNX was only just being introduced). Just before the project was to ship, we had to add a few more features. This made the system too big for the XT. All we had to do was add a second computer, modify a couple of startup shell scripts and ship the system. Not one single line of code had to be recompiled. The network is very fast. Whether you are compiling something that is on a hard disk in your machine, or from a remote hard disk, the speed is not noticably affected. In the ATS system, we put all the commands on a couple of server systems, and distributed the user directories around the net. Many machines had no hard disks at all. I understand that there are a number of diskless XT's and AT's on the market now. These would be perfect in this application. > 5. Are you developing any products for QNX? Since I've gone into freelance contracting, I have not done any QNX development. But if a contract came up that QNX seemed a good fit for, I would not hesitate to recommend it. > 6. How are you using it? > >------- >Hwa Jin Bae | Standard excuses...not responsible.../dev/null...etc. A couple of other notes. Their support is fantastic. If you have a problem, or you find a bug, you will often get a fix that same day. Upgrades, bug fixes, enhancements and quite a lot of free software is available online from their update service. They have an X.25 interface board available. Through this you can access their update service through datapac and telenet. This can save a bundle on long distance charges. You can install this board in your system as well. Very nice if you have or need access to to datapac or telenet, etc. Quantum has drivers for a QIC-60 tape driver. This works reasonably well if you use it intelligently. The compiler only supports the small model. But I never felt this to be a restriction. Because the message passing system works so well and so very fast, writing two tasks to do a job is about like writing two C functions. The message system is a send block system. You send a message, you are blocked from further processing until the receiver answers you. This is okay in the right environment, but you do have to design yout system carefully. Because of my background in RMX/86, I was appalled that there was no mailbox system of message passing. The first thing I did at ATS was to describe this type of mailbox system to one of my colleagues who promptly wrote a first mailbox system that was to become the basis of all future software at ATS. Quantum has since released a simple version of this same concept called (i think) queue_admin. The system is fast, but not at the command line level. Some commands seem to take too long. These are usually commands that hit the disk a lot. QNX does not have very sophisticated disk caching. But anything that is memory resident is very fast. Their permissions and user protection mechanism is a joke. It is pretty obvious that it is only meant to protect users against each other's accidents. This allows a user to leave files open for others to inspect and copy, but not to delete them. Of course you can make your files unreadable, or you can allow others to delete them if you wish. The password file is in plain ascii. It is not readable by normal users. This is the easiest protection mechanism to break in the world. All a user has to do is execute a command that has the change user bit set with it's standard input redirected from the password file and the contents of the password file will be available. ie 'mail send larry