Path: utzoo!attcan!uunet!munnari!otc!metro!ipso!stcns3!peter
From: peter@stcns3.stc.oz (Peter Jeremy)
Newsgroups: comp.unix.xenix
Subject: Re: Pascal Compiler for Xenix
Keywords: XENIX PASCAL COMPILER
Message-ID: <912@stcns3.stc.oz>
Date: 6 Oct 88 03:44:43 GMT
References: <1343@ndsuvax.UUCP> <194@ispi.UUCP>
Reply-To: peter@stcns3.stc.oz (Peter Jeremy)
Organization: Alcatel-STC Australia, Alexandria, Australia
Lines: 58

In article <194@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes:
>In article <1343@ndsuvax.UUCP>, nenicola@ndsuvax.UUCP (Steven Nicolai) writes:
>> I am looking for Pascal compilers for a xenix based system.
>
>Look at  the Microsoft Pascal compiler.  It is compatable at the source level
>with the same compiler on dos.  It has both of the extensions you want (the
>strings are called "lstring"s), and is fairly bug-free.  We have been using
>both versions (DOS and Xenix) for a few years now with very few problems.

"Fairly bug-free" depends on your point of view.  I have had the unfortunate
experience of having to port some Pascal to XENIX using this compiler and
put simply, it stinks.  As does Microsoft's support for it (at least in Oz).

A quick overview of problems (from memory - I don't have all the bug info
handy) - (This refers to version 3.30 of the compiler)
1) The installation procedure destroys the SCO C development system (by
   altering a number of include file links so that they effectively #include
   themselves). (Under Xenix 2.1.3 anyway - having been bit once, I re-installed
   it manually when we upgraded to 2.2).
2) The compiler leaves its temporary files lying around (with fixed file
   names) in the current directory (not a major bug in itself, but can be
   nasty in combination with the following).
3) When pass1 fails, pass2 will be invoked anyway - and then fail because it
   can't find the temporary files it needs (assuming that they weren't left
   over from a previous compilation).
4) There are problems relating to the use of (global) user defined types
   in local record descriptions - like the type goes away when the record
   that used it does.
5) include files are supported, but cause random compiler core dumps - very
   time-consuming to fix, because the only way to do it is by trial and error
   (and my application had _lots_ of include files).
6) The use of the C procedure calling method (necessary to access OS
   functions) interacts fatally with some debugging options.
7) There appear to be bugs in the random-IO calls resulting in adjacent
   records being munged (faulty seeking and block-buffering I think).
8) Only large model is available, and the generated code is a lot poorer
   than equivalent C code.
9) The documentation for OS calls is in C and requires you to work out what
   the equivalent Pascal declarations are.

When I reported the bugs to Microsoft (in December 1986), I was sent a
(beta?) copy of version 3.31.  This didn't fix any of the bugs that
affected me, but did add a new one - the WRITE() procedure called the
library procedure to _read_ the file rather than write it (I comfirmed
this by studying the generated assembler).  When I reported this, I was
thanked and told that they had no plans for correcting it in the near
future.  (When I checked in Feb 88, I was told that no further work had
been done, or was likely in the near future).

Personally, I wouldn't touch the Microsoft compiler with a 10 foot pole.
(And if I sound heated, its because I spent many, many hours getting
around compiler bugs.  Especially the include file problem which is likely
to re-appear at any time).
-- 
Peter Jeremy  (VK2PJ)       ACS:  peter@stcns3.stc.OZ
Alcatel-STC Australia       ARPA: peter%stcns3.stc.OZ.AU@uunet.UU.NET
Gnd Floor, 41 Mandible St,  UUCP: {enea,hplabs,mcvax,uunet,ukc}!\
Alexandria  NSW  2015 AUSTRALIA    munnari!stcns3.stc.OZ.AU!peter