drew@vrdxhq.UUCP (Drew Johnson) (08/10/88)
Just thought that I'd throw in my 0.02 cents worth to the discussion
of reliability of 286 Xenix, and also ask a question.
I will not say that the 286 xenix 2.2.1 is not without problems.
Their C compiler leaves a little to be desired, as it has problems with
evaluation of complex statements (can you say 'infinite spill'?), also
with the order of evaluation. I had a statement like:
if ((ptr != NULL) && (ptr -> foo != 1))
And it will actually evaluate the second condition, even if the first is
false! Actually, it simply evaluated them in reverse order. At any rate,
it was a problem. Another one that I personally like is their optimizer.
In the release notes, it says something to the effect of "If you use the
-O option, and your program segmentation faults, remove the -O option".
I just recently compiled two programs with the -O option, where 1 forked
and exec'ed the other. Use of the -O option caused the exec to fail
with hardware address fault. Lovely.
Concerning loss of data on shared interrupt vectors, I use an 8-port
mux that shares a vector, and has no hardware flow control or buffering.
It works fine as long as no more than 1 port is run at 9600. Running 2
at 9600 is a problem, and you find out quick, because most of the ports
on the mux stop working.
Now, the question: I am in the process of migrating a system from
a xenix 286 to a 386 box. We already have it running under Xenix 2.2.1
on the 386. I would like opinions on how hard it would be to change
to SysV/386. Xenix 2.2.1 has a hard limit of 40 message queues, but
we find that we will need more than that. Is this a problem for SysV/386?
(I'm pretty sure that SysV/386 can handle it) Basically, I need to find
out just how difficult it would be to port the code. My system makes
use of xenix shared-memory and message queues.
Please e-mail responses to me.
Drew Johnson
verdix!drew
or
drew@verdix.uu.net