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