Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!pasteur!ames!pacbell!cpro!asgard
From: asgard@cpro.UUCP (J.R. Stoner)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Turbo C 2.0 / pricing reality, buil
Summary: What compatibility might mean
Message-ID: <9@cpro.UUCP>
Date: 25 Oct 88 21:59:16 GMT
Article-I.D.: cpro.9
References: <182@imspw6.UUCP> <16800385@clio> <1104@pc.ecn.purdue.edu>
Organization: COG Gateway, Hayward, CA
Lines: 86

In article <1104@pc.ecn.purdue.edu>, jmoore@pc.ecn.purdue.edu (James D Moore) writes:
> In article <16800385@clio> berger@clio.las.uiuc.edu writes:
> >Borland's development environment works ok on a 100% compatible
> >machine, but the Microsoft stuff continues to work on generic
> >ms-dos computers.  To those of us with an investment in machines
> >that aren't 100% compatible, that's a big selling point.

> Obviously you have never realy worked with Borland software. 
> At work we typicaly buy strictly IBM machines.
[...]
> I use the Borland software extensively at work and at home on my
> "generic" compatible system.  I do all of my PC program writing with
> Borland and 90% of it is done on my XT compatable system at home.
				      ^^^^^^^^^^^^^
> I have not had the first problem with Borland software not working 
> on my generic ms-dos machine.
        ^^^^^^^^^^^^^^
O.K.  Which is it? :-)

I think you misunderstand what the compatibility issue means.
A system can be more, or less, "compatible" based on the limitations and
abilities a system has inherent to its design.  I will speak about the
particular system I know (too well, maybe?).

In 1982 CompuPro introduced a multiple-user system based on the dual
processor (85/88) which ran Concurrent CPM release 3.1 as its native OS
starting about 1985.  This was essentially "compatible" to the DOS 1.1
level, meaning some INT21 functions worked as they would on your XT.

Later, came release 4.1 of CDOS which, in combination the PC-VIDEO board
allowed a CompuPro to behave exactly like a CGA/keyboard combination found
in an XT.  Release 4.1 also updated functionality to the DOS 2.1 level
and some BIOS compatibility through some really snarfy tricks (details not
important) while still allowing multiple users to use the same machine
(up to 15 terminals at the time).  At about this time CompuPro bought its
first version of Lotus 123 (which worked) and I bought my own PC-DOS version
of TURBO Pascal 3.0 (which worked on the CompuPro).

Along comes Borland, with their exciting ;-) new version of the Pascal
compiler (3.1) which also worked with the floatbox (which is important to me
for my personal projects) and I snapped it up faster than a snapping turtle.
Unfortunately, this version *always* hung on the first input from the
keyboard.  I could use TURBO only with the XT clone (boo hiss) and the
compiled objects also hung up in the same way.  I gave up on 3.1 and
continued on.  It seemed that TURBO 3.1 made some assumptions about the
availability of the 8037 timer and keyboard controller being in the same
port addresses as they are in the XT/AT.  TURBO 3.0 did not make these
assumptions and used BIOS functions, or DOS functions, which were
sufficiently simulated by CDOS 4.1 and later.

The upshot?  Borland, in some misguided attempt to cram as much compute in
as little time essentially broke their product in a major way by bypassing
DOS and BIOS functions to read the keyboard, which otherwise would maintain
"compatibility" with prior versions of their product.  They thought that
*all* possible use of TURBO Pascal would occur on clones only and kissed off
an existing customer base that died on the vine.  I got zero response and
satisfaction from my calls to Borland (and letters, too) on this subject.

I essentially gave up on the DOS compiler and used the CP/M version, which
did not help my sour stomach any at all.

I divined the answer to the problem only this year while testing 386 CDOS
projects (having a uniform exception/trap for naughty I/O is NICE :)
Consequently, TURBO Pascal current versions (including the editor and TC)
will work on a CompuPro system only with CDOS 386.  Not good people.
The system is now highly "compatible" insofar as I have invested about 3
man-years on continual changes to the OS to fix this, that, and the other
"compatibility"-related bug introduced by the next software company
circumventing the (reasonable) restrictions placed on what a program can
reliably get away with.

Even supposedly "stable" products like the Macintosh is showing the effects
of this problem.  Maybe a browse into the Quickdraw interface for A/UX would
be instructive.

> I wish I could say the same about Microsoft.

My sour experience with Borland predated the existence of CodeView and
QuickC.
[Both QuickC and Codeview work very nicely on a CompuPro MP-300 with the
video and WYSE-60 terminals.]
-- 
"To prevent having to tell fools to RTFM don't let on you WTFM in the first
place." - J.R. (May the Source be With You) Stoner
asgard@cpro.uucp	asgard@wotan.uucp	asgard@well.uucp
...decwrl!pacbell!cpro!asgard