Path: utzoo!mnetor!frank From: frank@mnetor.UUCP (Frank Kolnick) Newsgroups: comp.sys.ibm.pc Subject: Re: QNX anyone? Message-ID: <4654@mnetor.UUCP> Date: 3 Jul 88 19:11:17 GMT References: <22273@tis.llnl.gov> <4632@mnetor.UUCP> <962@gethen.UUCP> <1286@odyssee.UUCP> Reply-To: frank@mnetor.UUCP (Frank Kolnick) Organization: Computer X (CANADA) Ltd., Toronto, Ontario, Canada Lines: 61 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