berger@clio.las.uiuc.edu (10/22/88)
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.
Mike Berger
Department of Statistics
University of Illinois
berger@clio.las.uiuc.edu
{convex | pur-ee}!uiucuxc!clio!bergerjmoore@pc.ecn.purdue.edu (James D Moore) (10/26/88)
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. > > Mike Berger > Department of Statistics > University of Illinois Obviously you have never realy worked with Borland software. At work we typicaly buy strictly IBM machines. We have not been allowed to buy compatibles. 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. I wish I could say the same about Microsoft. Could you please explain your statement ? How can people make statements like this ? I still feel like many that the for the cost Borland is by far the best deal. Jim Moore Industrial Engr. Department Purdue University jmoore@cimlab.ecn.purdue.edu
asgard@cpro.UUCP (J.R. Stoner) (10/26/88)
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
dalegass@dalcs.UUCP (Dale Gass) (10/26/88)
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. What about TCC (the command-line version)? It will work on any generic MS-DOS machine, just like MSC will. I sincerely doubt that QuickC works any better on generic machines; I would expect it has even less of a chance. TCC allows you to compile many modules with only having to load TCC once (i.e. TCC one.c two.c three.c will copmile all three without reloading TCC). I believe MSC re-loads it's different passes for each module, which results in much slower compiles. -dalegass@dalcsug.uucp {watmath|uunet}!dalcs!dalcsug!dalegass
bright@Data-IO.COM (Walter Bright) (10/27/88)
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. Not totally. The install program for C5.0 would sieze my machine (an IBM AT). Turns out it won't work if you have a Quadram EGA. I use many graphics programs from other vendors on that EGA, and none of them fail. I also have trouble with Codeview on it. Surprisingly, OS/2 will work with it! I've never tried Quickc, because I have an 80mb disk with a western digital controller.
pjh@mccc.UUCP (Pete Holsberg) (10/27/88)
In article <1104@pc.ecn.purdue.edu> jmoore@pc.ecn.purdue.edu.UUCP (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. ...> .... I do all of my PC program writing with Borland and ...90% of it is done on my XT compatable system at home. That's what he said: you have a 100% compatible. He's talking about odd-ball machines that existed a few years ago that were 80% compatible, but I can't think of the names. Knowledgeable folk junked those when the prices of 100% compatibles dropped. -- Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh Mercer College CompuServe: 70240,334 1200 Old Trenton Road GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/29/88)
In article <1126@microsoft.UUCP> t-stephp@microsoft.UUCP (Stephen Poole) writes: >QuickC 1.0 had a problem >with a certain OLD Western Digital controller due to a BIOS flaw that >Western Digital promptly fixed. Why on earth would a C compiler be dependent on specific disk controller hardware? -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
mr@homxb.UUCP (mark) (11/02/88)
In article <4539@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: # In article <1126@microsoft.UUCP> t-stephp@microsoft.UUCP (Stephen Poole) writes: # >QuickC 1.0 had a problem # >with a certain OLD Western Digital controller due to a BIOS flaw that # >Western Digital promptly fixed. # # Why on earth would a C compiler be dependent on specific disk controller # hardware? The problem was not during compile time, it was during run time. Quick-C can also run a C program from within. Is seems that the same interrupt was used as the disk controller used and caused the disk to be scrambled. This happened to me once, though I was able to recover since DOS keeps two copies of the FAT table. # -- # Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi mark homxb!mr