amit@umn-cs.UUCP (10/30/87)
Aside from a self-promoting ad in Byte Mag., I've seen very little discussion about the QNX operating system. I spoke to these guys quite extensively, but I would be interested in personal experience. Would anyone with experience in QNX and either SCO Xenix or uPort compare them for the rest of us? Issues of interest might be: - Compatability with Sys V; Stability; Technical support; - Quality of C compiler, debugger (windows?), runtime environment; - Hardware support (multifunction, video, disk controller boards) - Invoking DOS as a task, and running business oriented software. -- Neta Amit U of Minnesota CSci Arpanet: amit@umn-cs.cs.umn.edu
ittfb@dcatla.UUCP (Thomas F. Blakely) (11/03/87)
In article <2540@umn-cs.UUCP> amit@umn-cs.UUCP (Neta Amit) writes: >Would anyone with experience in QNX and either SCO Xenix or uPort >compare them for the rest of us? Issues of interest might be: >- Compatability with Sys V; Stability; Technical support; It's not Unix, system V or otherwise. Libraries are _very_ different (other than standard i/o functions). It has more Unix-like utilities with every release (grep, make, etc.) but still has room for improvement there. It's *MUCH* smaller than unix, however. >- Quality of C compiler, debugger (windows?), runtime environment; Excellent, but not quite standard C compiler (has "extensions"), limited to 64K code and 128K data, which is not a practical limitation since shared libraries are possible (standard library is shared). Debugger is primitive at best, machine level only. Multitasking seems excellent (ie., no spurious crashes), intertask communications very usable. Manuals better than they were, still need work. >- Hardware support (multifunction, video, disk controller boards) Supports AST, Quadboard and other clocks. I was able to write one for the clock on my turbo XT clone (an obscure one). Uses any disk controller. Many are supported with real-time drivers, others use BIOS driver, which blocks other tasks when accessing disk (not a serious problem most of the time). Supports CGA, Mono; I don't know about EGA, others. >- Invoking DOS as a task, and running business oriented software. The version of QDOS that I was running would only work on an XT, not on several clones I tried it with (problems with BIOS hard disk driver). Quantum claims to have this fixed now, >-- > Neta Amit > U of Minnesota CSci > Arpanet: amit@umn-cs.cs.umn.edu Caveats: I have not tried the networked versions of QNX. I have also not used the 286 protected-mode version (I have run the non-protected AT version). Note also that the boot disk is copy protected. I have been unable to get QNX to boot from the hard disk, but I didn't try very hard. Overall, I have been fairly impressed with QNX, but I don't use it much since there's little 3rd party software available for it. I've used it mostly for development with a cross-assembler we wrote, and for a dedicated pc-based lab controller. I encountered no serious bugs in either of these uses. SDA. T. Blakely
gardner@kodak.UUCP (dick gardner) (11/04/87)
In article <2030@dcatla.UUCP> ittfb@dcatla.UUCP (Thomas F. Blakely) writes: >In article <2540@umn-cs.UUCP> amit@umn-cs.UUCP (Neta Amit) writes: >>Would anyone with experience in QNX ............. deleted many questions & answers re:QNX (generally agreed with responses) >Overall, I have been fairly impressed with QNX, but I don't use it much >since there's little 3rd party software available for it. I've used it >mostly for development with a cross-assembler we wrote, and for a >dedicated pc-based lab controller. I encountered no serious bugs in either >of these uses. > >SDA. >T. Blakely I am using the protected mode version of QNX on my AT and an IBM Industrial PeeCee. NO problems whatsoever. I am waiting for some cable to be strung to complete my little development network, but I have seen several network implementations, some quite large, and am thoroughly impressed. All the resources on the network are (optionally) accessible to everyone on the net, including CPU's. I can, for example, off-load a compile on the 10 MHz PC, instead of using my 6 Megger, and it's totally transparent. What I wanted to add, is that there are several firms now offering software to run under QNX. Databases, (including entity-relational), spreadsheets, graphics packages, etc. There is also lots of free stuff available from Quantam's bulletin board for registered users. =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=# Dick Gardner -- Eastman Kodak Co. Rochester, New York 14650 Phone: (716) 477-1002 UUCP: {allegra,rutgers}!rochester!kodak!gardner "Oh yeah?!? Well, MY computer is SOOOOO FAST, it executes an infinite loop in 6 seconds!!!" =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
bae@ati.tis.llnl.gov (Hwa Jin Bae) (06/15/88)
Is anyone out there using QNX? 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?
2. Device Drivers:
What's envolved in writing a device driver for QNX?
3. Is it really worth $695 for runtime and development package?
4. How's their networking (ARCnet board)?
5. Are you developing any products for QNX?
6. How are you using it?
-------
Hwa Jin Bae | Standard excuses...not responsible.../dev/null...etc.
Control Data Corp. | (415) 463 - 6865
4234 Hacienda Drive | bae@tis.llnl.gov (Internet)
Pleasanton, CA 94566 | {ames,ihnp4,lll-crg}!lll-tis!bae (UUCP)gardner@kodak.UUCP (dick gardner) (06/15/88)
In article <22273@tis.llnl.gov> bae@ati.tis.llnl.gov (Hwa Jin Bae) writes: >Is anyone out there using QNX? 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? It's fully K&R with lots of extension to support task-task communication, message-passing, graphics,etc. The QNX C compiler is a small-model only, but this does not usually present a problem since tasks are usually small. It doesn't make much sense to build a huge monolithic task that hogs the CPU in a system that was designed to divide an application into small, efficient tasks that talk to each other. The linker resolves all the FAR and NEAR problems. Computer Innovations is introducing a full-fledged C compiler for QNX soon (like about 1 mo.) > How's their Assembler - or do they have one? > If they has an Assembler, is it MASM compatible? Their assembler is totally non-standard. It takes a little getting used to. > 2. Device Drivers: > What's envolved in writing a device driver for QNX? In QNX, you need to write a privileged task, called an Administrator. I don't have a lot of experience doing this, but am about to start one next week. From talking to others, it appears to be easier than DOS. > 3. Is it really worth $695 for runtime and development package? YES. > 4. How's their networking (ARCnet board)? It's a little too expensive. (OK, maybe VERY expensive -- $450) It's very reliable, and very smooth and smart. During the boot sequence, you are given a chance to interrupt the currently programmed sequence and change it to boot from local disk or from the network. If the network is used, you can select the image to be down-loaded. For example, an AT-class machine could run in Real mode, Protected mode, or re-located Protected mode to make room for DOS to run in lower memory. Other firms make ARCNET cards that can be used, but the value-added firmware obviously has to come from somewhere, and I don't know of any source. Networking is one of QNX most powerful features. First, ARCNET is a token bus system, where network times are deterministic. This is absolutely essential for the Machine Control applications that I am involved with. Next, this is a peer-peer system, where any resources on the network are (optionally) available to any node. The network system is smooth and fast. I can sit at my desk and run programs on another machine transparently. In case you haven't noticed, I am obviously biased, but I have seen QNX applied in some impressive ways. > 5. Are you developing any products for QNX? Kodak has a product which has QNX built-in, but I am not directly involved in that project. I do know some people who are. > 6. How are you using it? I am in a development group that is responsible for testing and developing machine control systems for our Manufacturing Engineering. I am looking at QNX for use as a Cell Controller in Manufacturing. > >------- I attended a QNX conference in Ottawa a week or so ago, and was pleased to see the many wayss that QNX has been used to handle jobs that other OS's just couldn't manage. The presentations each day featured specialized, and widely-varied applications. They ranged from a Pizza-ordering system where customers in a large city called one phone number for home delivery, to a flood control system that is at the heart of the National Weather Service Flood Alert system. In between, one main-frame manufacturer actually replaced their own machine with a QNX network to manage a testing facility. A major oil company is replacing their extended engine & fuel testing hardware with industrial-strength PC's running QNX. A gigantic communications company is using QNX for all(or, at least a lot) of their office, as well as software development and maintenance. They have one plant with a 300 node network. Granted, many of these presentations were testimonials made by un-paid members of the Quantam marketing divsion, but they were ALL success stories by very clever people, who were not able to meet their needs with DOS and other OS's. Many vendors were present, offering software and hardware that closely resembles DOS programs. Lotus look-alikes, DBaseIII clones, file managers, windowing systems, code generators, are all available now. Also shown were process control systems utilizing graphics interfaces. As for the future of QNX, several new items were announced. One is called RUNDOS. It will run DOS applications (while in protected mode), giving you even more memory than DOS! It leaves about 620K to run your program. It is in Beta now, running Lotus, Dbase, etc, quite nicely. Another product to be introduced soon, is a distributed Make facility, which allows you to define network nodes as a team, and do compiles in parallel on all the team CPUs! One of the major efforts in the near future will be to establish bridges to other networks(such as Ethernet). Sorry for being long-winded, but I hope this info will be helpful. =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=# Dick Gardner -- Eastman Kodak Co. Rochester, New York 14652-4201 Phone: (716) 477-1002 UUCP: {allegra,rutgers}!rochester!kodak!gardner "Oh yeah?!? Well, MY computer is SOOOOO FAST, it executes an infinite loop in 6 seconds!!!" =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
frank@mnetor.UUCP (Frank Kolnick) (06/20/88)
In article <22273@tis.llnl.gov> bae@ati.tis.llnl.gov (Hwa Jin Bae) writes: >Is anyone out there using QNX? 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? The compiler is very plain vanilla (i.e., not quite full K&R; they don't support unsigned longs, etc.) and not particularly quick. It also only builds small-model tasks, which isn't so terrible if you take advantage of the message-passing to build lots of small, co-operating tasks. The most recent debugger (released this winter) is symbolic and seems nice (e.g., it doesn't alter the target imag, just adds lots of supplementary files), but I haven't used it extensively yet. They do have a decent make, though. > How's their Assembler - or do they have one? They do, but it's obviously not intended for programming (just as a pass of the compiler), i.e., practically no documentation. However, the compiler lets you embed assembler code and lets you reference variables and the stack cleanly. > If they has an Assembler, is it MASM compatible? Very much not. > 2. Device Drivers: > What's envolved in writing a device driver for QNX? Don't know yet, but I will find out in the near future. > 3. Is it really worth $695 for runtime and development package? As a consultant, I just get to use it. Friends of mine like it so much that they not only buy it but do their DOS development under it. (QNX goes out of its way to be compatible with DOS, by reading DOS files, supporting a separate DOS partition on the disk, running DOS as a subtask, etc.) I dislike their editor, but there may be some third-party offerings (MKS, where are you?). An ANSI compiler has been announced but I don't think it's available yet. > 4. How's their networking (ARCnet board)? Generally, it's transparent to the programmer, meaning two tasks can exchange messages without knowing where they are located. However, if you do want to know about nodes, you can create tasks remotely, create them locally and direct their output to another node's terminal, share a file system, etc. (BTW, it's not strictly ARCnet, it's a proprietary version designed and manufactured only by Corman Custom Electronics.) > 5. Are you developing any products for QNX? Not personally, but for a client. > 6. How are you using it? The current application is a distributed, real-time monitoring system. (I think that's all I'm allowed to say. This has nothing to do with Computer X, by the way. I just happen to consult here as well and use their Unix system.) Actually, since I mentioned it, Computer X is also a distributed, real-time o/s based on message-passing. Unlike QNX, it runs on 680x0 machines (surprised?). It has been written up in Unix World (since it can share a processor with System V and communicate with it via messages), among other places which I can't recall. The recent issue of Dr. Dobbs has an article on QNX by one of its developers, and an independent review ran in PC Tech Journal some time last year, I think. -- Frank Kolnick, UUCP: {allegra, linus, ihnp4}!utzoo!mnetor!frank BELL: (416)-475-8980 ext. 311
larry@focsys.UUCP (Larry Williamson) (06/20/88)
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 </config/pass' mails me the password file. I mentioned that ATS used QNX in a supervisory role in their products as well. This I see is the major failing in QNX. There is just not enough application software available for it. There are two data base systems, both quite expensive, and very powerful, but not always appropriate. There is a spread sheet program, but it is not always the best solution either. What it comes down to is that the options available to you are limited. You can always do it with QNX, QNX never prevents you from getting the job done, but sometimes it seems like more work that it should be. While at ATS, we ported many public domain packages from usenet to run on QNX. Some ported easily, others more difficult. Usually, we enhanced the package during the port. For example, porting kermit was easy enough, but we added many new command line options that made kermit much easier to use in an automated customer update system. I liked it, but I'm glad I'm using Unix now. larry -- Larry Williamson Focus Automation Systems UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4 +1 519 746 4918
isaac@gethen.UUCP (Isaac Rabinovitch) (06/27/88)
In article <4632@mnetor.UUCP>, frank@mnetor.UUCP (Frank Kolnick) writes: >[The QNX C compiler ] only > builds small-model tasks, which isn't so terrible if you take advantage of > the message-passing to build lots of small, co-operating tasks. That strikes me as a good way to develop programs, but which few programmers are likely to understand. Most PC programmers *love* the complicated addressing scheme in MS C and its ilk. Perhaps Quantum would increase the market for QNXif they devoted some effort to deprogramming (forgive the pun) all those DOSiers who think complexity is power.
ddb@ns.nsc.com (David Dyer-Bennet) (06/30/88)
In article <962@gethen.UUCP>, isaac@gethen.UUCP (Isaac Rabinovitch) writes: > PC programmers *love* the > complicated addressing scheme in MS C and its ilk. We do? I haven't met ANYONE who struck me that way. Probably some of us glory in understanding and controlling the monster, but I haven't met any who like the monster itself. -- -- David Dyer-Bennet ddb@viper.UUCP Fidonet 1:282/341.0
pinard@odyssee.UUCP (Francois Pinard) (07/01/88)
In article <962@gethen.UUCP>, isaac@gethen.UUCP (Isaac Rabinovitch) writes: > In article <4632@mnetor.UUCP>, frank@mnetor.UUCP (Frank Kolnick) writes: > >[The QNX C compiler ] only > > builds small-model tasks, which isn't so terrible if you take advantage of > > the message-passing to build lots of small, co-operating tasks. > That strikes me as a good way to develop programs, but which few > programmers are likely to understand. Even if debatable for efficiency considerations, I see your point for executable code. But it does not apply when you need large (not so large, after all :-) data space, for intepreters like LISP or Prolog, or when you are doing anything requiring large arrays, like (sometimes) mathematical programming or in-memory databases. It does not apply either when you simply want to import external software, which was not made explicitely for this system. QNX looks like a small, nice, development system that still needs a lot of development (read: you cannot really escape doing development to use it). > Most PC programmers *love* the > complicated addressing scheme in MS C and its ilk. Has it come to your mind that maybe a lot of us just *hate* all this complexity, but cannot get rid of it without throwing our machines in the basket? -- Francois Pinard pinard@odyssee.uucp (514) 279-0716 `Vivement GNU!' pinard%odyssee@larry.mcrcim.mcgill.edu (514) 588-4656
frank@mnetor.UUCP (Frank Kolnick) (07/04/88)
In article <1286@odyssee.UUCP> pinard@odyssee.UUCP (Francois Pinard) writes: >In article <962@gethen.UUCP>, isaac@gethen.UUCP (Isaac Rabinovitch) writes: >> In article <4632@mnetor.UUCP>, frank@mnetor.UUCP (Frank Kolnick) writes: >> >[The QNX C compiler ] only >> > builds small-model tasks, which isn't so terrible if you take advantage of >> > the message-passing to build lots of small, co-operating tasks. >> That strikes me as a good way to develop programs, but which few >> programmers are likely to understand. > >Even if debatable for efficiency considerations, I see your point for >executable code. The efficiency aspect of any message-oriented system is debatable. The fundamental assumption is that a relatively complex application, particularly one that requires a lot of components and involves a high degree of interaction between components, is better served by a multi-task (even multi-node) message-passing environment. For raw speed, a single task will always outperform, but as always there are trade-offs. (Not intending to start a war here, but message systems are fundamentally different from DOS-like systems. Which also addresses the next couple of points...) >But it does not apply when you need large (not so large, after all :-) >data space, ... Keep in mind that the small model is a Quantum compiler restriction, not a QNX restriction. A third party compiler supports all models. Also, if it's only local data you need, QNX will let you allocate as many additional 64K segments as you like. However, you have to manage them yoursef. If the data is at all structured and has well-defined operatiosn which can be applied to it (e.g., a data-base), then a separate data-manager task might be appropriate. >It does not apply either when you simply want to import external >software, which was not made explicitely for this system. ... Given the substantial difference in philosophy between QNX and most other operating systems, porting any application may be a chore. Only self- contained programs can be ported easily -- language compatibility and o/s compatibility are two separate issues. About six months ago I had to port a substantial DOS application to QNX and yes, it was a pain. But it was a conscious decision and the end result justified the effort; the newer version was distributed, had more parallelism, could handle background I/O, such as polling, without bending over backwards, etc. >> Most PC programmers *love* the >> complicated addressing scheme in MS C and its ilk. > >Has it come to your mind that maybe a lot of us just *hate* all this >complexity, but cannot get rid of it without throwing our machines in >the basket? I'm staying out of this one. It's sufficient to point out that there are alternatives, and I personally like the flexibility of a message-passing architecture. -- Frank Kolnick, UUCP: {allegra, linus, ihnp4}!utzoo!mnetor!frank BELL: (416)-475-8980 ext. 311
isaac@gethen.UUCP (Isaac Rabinovitch) (07/04/88)
In article <1286@odyssee.UUCP>, pinard@odyssee.UUCP (Francois Pinard) writes: >>(previous discussion on QNX C compiler and its limitation to small >>memory model used to build programs out of small, QNX processes. some >>assert this is a good thing.) > > Even if debatable for efficiency considerations, I see your point for > executable code. There's more than one definition of efficiency. One is making your program work with an absolute minimum of cpu time -- that's the one everyone thinks about first but it's the least important. There's also efficiency of programmer time, efficiency of user time (all these down and dirty MS-DOS programs collide with each other and with the hardware, causing much distraction), efficiency of psychiatric time.... > > But it does not apply when you need large (not so large, after all :-) > data space, for intepreters like LISP or Prolog, or when you are doing > anything requiring large arrays, like (sometimes) mathematical > programming or in-memory databases. Once again, we are reminded that some twit actually thought 64K was all the memory a PC would ever really need! But I digress. You're right, I wouldn't want to develop the programs you describe using the QNX C compiler. But how many of us are writing that kind of program? The real question is whether existing LISP interpreters (and other such programs) will *run* under QNX. And managing memory ought to be the OS's job, no? > > > > Most PC programmers *love* the > > complicated addressing scheme in MS C and its ilk. > > Has it come to your mind that maybe a lot of us just *hate* all this > complexity, but cannot get rid of it without throwing our machines in > the basket? You're not the first person to call me to task for that one, and I'll just back down and apologize for the glib little overcategorization. But it does strike me that many programmers have this attitude. Maybe I associate with the wrong people, but whenever I complain that MS-DOS or the Mac "OS" doesn't support any of the basic system functions, which then must be built into the user program, somebody says, "but that makes them more flexible"! Anyway, I'd sure like to see QNX survive, cause then we could have a real OS *without* throwing away our hardware. (No even 8086 machines!) But we've got more than one albatross around our collective nets. Not just the existing hardware base, but the existing user-vendor-programmer culture, which appears very well entrenched.
jdm1@eds1.UUCP (Jon McCown) (04/25/89)
I just acquired a qnx system and am interested in discussing same with other qnx users. Especially curious about experiences with application development (caveats etc). Please followup to comp.os.misc where the s/n is better. If mail responses are significant I will summarize to comp.os.misc. - Jon -- J.D. McCown - RCSG Director - Senate of Pennsylvania - psuvax1!eds1!jdm1 I disclaim it all, no I never said anything. Even if I did say anything the owners of this system and/or my employers likely wouldn't agree or support it.
frank@mnetor.UUCP (Frank Kolnick) (04/25/89)
In article <208@eds1.UUCP> jdm1@eds1.UUCP (Jon McCown) writes: >I just acquired a qnx system and am interested in discussing same with >other qnx users. Especially curious about experiences with application >development (caveats etc). I've been a QNX consultant for a while and have just finished a book about the o/s (to be published next week). I can sum up by saying it's a very well designed real-time, distributed o/s, founded on the concept of message-passing for inter-task communication. I like it a lot, and find it highly suitable to real-time applications (although I imagine it would also do well in non-industrial environments). It's certainly more difficult to learn, and the documentation is very good but terse. Beats the pants off OS/2, in speed, size and capabilities. Probably the main caveat is to not get carried away with messages. Most people seem to have difficulty designing truly parallel applications, esp. across networks. BTW, Quantum's support for QNX is exceptional. Not only good voice support, but also a BBS for users. You can discuss issues with other developpers *and* the designers of the o/s, and can often download fixes to the o/s and utilities within days of reporting a problem. Quantum is also commited and to developing QNX, with regard to POSIX, windows, etc. Obviously I'm biased (as a satisfied user), but I think QNX is worth a look for any serious real-time application. (There are some really *big* users out there and, I believe, about 75,000 systems installed world-wide.) Anything else you'd like to know? -- Frank Kolnick, consulting for, and therefore expressing opinions independent of, Computer X UUCP: {allegra, linus}!utzoo!mnetor!frank
paine@rust.dec.com (Willy Paine) (04/26/89)
Cc: I was investigating QNX for awhile and I think this is very good OS for 286 machine. There are many disadvantage and I never heard any plans for 386 machine in the future. I would like to run BBS in DOS shell but it runs only one dos shell at time and video displays bleeds through console screen very badly even sysadm is not using this shell. I would say QNX is pretty backward as comparing with other Unix for 386. I don't give you all negative commments and I like the runtime benchmark for QNX and this runs fast enough to run ms-dos BBS in dos shell without any problem. I hope QNX developers are agressive to take advantage using full 386 power like multi-tasking and multi-users on ms-dos shells without any direct video problem. I have never heard of any newsgroup for QNX but there is good FidoNet echomail on QNX. Willy