nenicola@ndsuvax.UUCP (Steven Nicolai) (09/22/88)
I am looking for Pascal compilers for a xenix based system. Some
friends of mine have a large system consisting of about 300 pascal
programs that they are looking at moving to xenix from MS-DOS.
The programs are written in Turbo Pascal 3.0, but use none of the
Pascal I/O, this is done through calls to a C library. The programs
don't use many of the features supported by Turbo. The programs
are also compilable on the Macintosh with MPW.
The biggest extensions to Pascal that are needed are:
1. The ability to take the address of a variable. (This is
used to comunicate with the C library)
2. ANSI strings, strings as arrays of CHAR won't do.
If you know of a Pascal compiler that might fit this bill, please
email me.
Steve
--
---------------
Steve Nicolai USMAIL: 1717 40th St SW Apt 106
ARPA & UUCP: nenicola@plains.NoDak Fargo, ND 58103
BITNET: nenicola@ndsuvax (701)-281-1230jbayer@ispi.UUCP (id for use with uunet/usenet) (09/25/88)
In article <1343@ndsuvax.UUCP>, nenicola@ndsuvax.UUCP (Steven Nicolai) writes: > I am looking for Pascal compilers for a xenix based system. Some > friends of mine have a large system consisting of about 300 pascal > programs that they are looking at moving to xenix from MS-DOS. > > The biggest extensions to Pascal that are needed are: > > 1. The ability to take the address of a variable. (This is > used to comunicate with the C library) > > 2. ANSI strings, strings as arrays of CHAR won't do. 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. Jonathan Bayer Intelligent Software Products, Inc.
peter@stcns3.stc.oz (Peter Jeremy) (10/06/88)
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
jbayer@ispi.UUCP (id for use with uunet/usenet) (10/08/88)
In article <912@stcns3.stc.oz>, peter@stcns3.stc.oz (Peter Jeremy) writes: > 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) ^^^^ I have been running the compiler version 3.32 for a year or so, with no problems. > 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). It has been a while, but I do not recall this problem. It is possible that it was masked by my other work. > 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). True. > 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). Not with 3.32 > 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. This is a documentation problem. The compiler works OK, but if you are not careful with your scoping it will seem like a bug. > 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). Again, not with my experience with 3.32, and I have an application which compiles and links to about 600k, and it also has _lots_ of include files > 6) The use of the C procedure calling method (necessary to access OS > functions) interacts fatally with some debugging options. Please expand on this. > 7) There appear to be bugs in the random-IO calls resulting in adjacent > records being munged (faulty seeking and block-buffering I think). I use my own file-io routines, so I never saw this. > 8) Only large model is available, and the generated code is a lot poorer > than equivalent C code. True about the large model code, and how do you conclude that the generated code is poorer? > 9) The documentation for OS calls is in C and requires you to work out what > the equivalent Pascal declarations are. True. > 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). > I can add one more problem to his list. If you declare too many variables, the compiler will get a stack overflow. I still stand by my previous statement. Admittedly it is not the best, but with this compiler (and the DOS version) I am able to maintain a large (>50,000 lines of code) program on both DOS and Xenix without too many problems. I have received version 4 of the DOS compiler, and have not yet been able to check it out. Jonathan Bayer Intelligent Software Products, Inc.