esa@msdc.UUCP (02/14/87)
It seems that Borland has released (well, announced/advertized at least)
a Turbo C compiler. According to the ad, it produces linkable object
modules and comes with its own make utility; also, it appears to support
the plethora of Intel memory models. Lists for $99.95, probably less at
mail order houses. So far, so good.
What concerns me is that unlike most C compiler ads, this one did NOT
mention K&R or the "standard" C library. I wonder if Turbo C is Borland's
vision of what C "should" be, much like Turbo Pascal was. They got away
with it for Turbo Pascal because the language needed what they provided,
but I think the situation is different with C.
Comments? Has anyone seen or used Turbo C yet?
--
Esa Ahola, Medical Systems Development Corp, Atlanta, GA
esa@msdc.UUCP, ...{akgua, gatech, ihnp4, mcnc}!msdc!esajjc@sdiris1.UUCP (02/17/87)
In article <203@msdc.b.msdc.UUCP>, esa@msdc.UUCP (Esa T. Ahola) writes: > > .. What concerns me is that unlike most C compiler ads, this one did NOT > mention K&R or the "standard" C library. .. I have not seen Turbo C, but : Turbo C will likely turn a lot of people on as the "standard" for C if they havn't already been using C. I hope Turbo C is K&R, Many of the Borland products are not fashioned after any particular "standard". Don't get me wrong, Borland products are good quality. They seem to make more money selling products which sell, rather than deem the "standard" stamp. ----------------------------------------------------------------------- UUCP: ...!sdcsvax!jack!man!sdiris1!jim | Jim Carter Work : +1 619 450 6516 | Control Data Corporation (CIM) Home : +1 619 455 0607 | 4455 Eastgate Mall, | San Diego, CA 92121
ccs016@deneb.UUCP (02/17/87)
> In article <203@msdc.b.msdc.UUCP>, esa@msdc.UUCP (Esa T. Ahola) writes: > > > > .. What concerns me is that unlike most C compiler ads, this one did NOT > > mention K&R or the "standard" C library. .. > > I have not seen Turbo C, but : > Well... What I'm worried about is that it is a ONE pass compiler. Doesn't this mean we have to conform to the top down design? If it is infact a one pass compiler as mentioned a couple postings ago then there is no way in my opinion that it will become the standard compiler, plus most C'ers are very defensive of K&R. Patrick Tully ucdavis!deneb!ccs016
bright@dataio.UUCP (02/18/87)
In article <168@ucdavis.UUCP> ccs016@ucdavis.UUCP (Patrick Tully) writes: >Well... What I'm worried about is that it is a ONE pass compiler. Doesn't >this mean we have to conform to the top down design? If it is infact a >one pass compiler as mentioned a couple postings ago then there is no >way in my opinion that it will become the standard compiler, plus most >C'ers are very defensive of K&R. There is no obstacle to creating a 1-pass compiler that is full K+R or ANSIC C. The compiler I wrote (Datalight C) is two pass mainly to reduce memory requirements. The Greenhills C compiler is 1 pass.
kent@ncoast.UUCP (02/20/87)
s/*** REPLACE THIS LINE WITH YOUR MESSAGE ***/YOUR MESSAGE/g A number of people have posted inquiries about Borland's Turbo C. The following is an editorial of sorts, along with some biased and unsolicited opinions of MS-DOS C compilers. I am associated with NONE of the companies discussed. My opinion is : don't bother with Turbo C. There are other products out there that must be just or good (or better), and by all indications, Borland's Turbo C will share all of the drawbacks of the other Borland Products, to wit: 1. Non-standard (in troubling and non-trivial ways) implementations. Borland says that Turbo C will adhere to ANSI Standard C, but don't expect it to be any closer than Microsoft C 4.0. My bet is that it will be as close to ANSI C as Turbo Pascal is to ISO Pascal. Is this a fatal flaw? Depends on your point of view. It is definitely fatal in a professional, production environment. 2. A lack of a batch mode for compiles. Ever try to run Turbo Prolog from make? 3. Bugs. I found several in Turbo Prolog, just screwing around for a day or so (V1.0). Borland was nice enough to send me 1.1 unsolicited, but I haven't verified that the bugs are gone. Why go with a new, untested product when there are mature products around? I have been working for three years with C compilers daily, and have the following two-bit reviews to offer: 1. MSC 4.0. Love codeview (but it has annoying bugs!), love the extensive library. Code generation good to excellent. I haven't found any library bugs myself, but supposedly if malloc fails, it will sometimes clobber DS. ROM support sucks - regardless of the source they give you to startup. 2. Aztec C86 - good to excellent code generation. Occasionally you will still hit ugly code generation bugs in large models. Excellent ROM support. Nice package of development tools, (make diff vi clone etc), but there are them
klotz@aicchi.UUCP (02/22/87)
In article <168@ucdavis.UUCP> ccs016@ucdavis.UUCP (Patrick Tully) writes: >> > .. What concerns me is that unlike most C compiler ads, this one did NOT >> > mention K&R or the "standard" C library. .. Are all of the Borland nay-sayers blind or do they not just refuse to read? The add says: [/] ANSI C compatible!!!!!!!
ted@imsvax.UUCP (02/22/87)
kent@ncoast of Cleveland Public Access UNIX, Cleveland, OH writes: >My opinion is : don't bother with Turbo C. There are other products out there >that must be just or good (or better), and by all indications, Borland's Turbo >C will share all of the drawbacks of the other Borland Products, to wit: >1. Non-standard (in troubling and non-trivial ways) implementations. Borland >says that Turbo C will adhere to ANSI Standard C, but don't expect it to >be any closer than Microsoft C 4.0. My bet is that it will be as close to >ANSI C as Turbo Pascal is to ISO Pascal. Is this a fatal flaw? Depends on your >point of view. It is definitely fatal in a professional, production >environment. I've used Turbo Pascal in a professional production environment quite a lot. It speeds up the professional production something like 10 to 1 over using the C compilers which are available for PCs. Normally, all things being equal, I would prefer C to any other programming language, however, aside from programs which must be ported to other architectures, I have switched my PC programming almost entirely to Turbo Pascal simply because I view the available C compilers as retarded by comparison. There are a number of reasons: 1. Price: at a retail price of around $70 and a street price of around $55, Turbo Pascal is nearly free. Reasonable DOS C compilers go for around $300 and the only reasonable C INTERPRETER available until now has been going for around $450. Keep this point in mind; compilers and interpreters both have their place in the scheme of things and Turbo products function as both. Few if any other packages make this claim. 2. Turbo Pascal produces very fast code. Further, the compiler itself is almost supernaturally fast, typical 2000 line programs compiling in 15 seconds on 6mh ATs. A CCI Power-6 (rated 10 times VAX 780 compute power) cannot match this with one user on the system. Present DOS C compilers don't come anywhere close to this. 3. Turbo has the only completely believable debugging system in the Micro world. All other debugging systems amongst micros, to my knowledge, involve breakpoints and single stepping. In real life, blowups usually occur on the 876'th pass of some 200 line logical loop; who in hell wants to single step through all of that? The ONLY thing I ever want to know when a program blows up is the line number on which it blew; I figure I'm bright enough to figure out WHY it blew. Turbo not only tells me that, it puts me right on that line in its editor. It is the only realistic and helpful debugging aid I have ever found in the mini-micro world (the ideal being something like the debug feature on the UNIVAC 1100 series 10R1 Fortran, of course). 4. Turbo is a large super-set of standard Pascal, with a tremendously good interface into DOS and PC functionality, things which lie outside of any of the ANSI standards for programming languages. It actually allows machine-coded routines to be imbedded right into Turbo routines (Turbo inline code), allows DOS calls with the use of only one simple register structure, and has easy systems for addressing segments and offsets of Turbo variables, labels etc. Such code can be made as fast as is possible on 80x86 devices. Masm interfaces for the various C compilers are not as clean or elegant. I am assuming Turbo C will also have this feature. 5. Turbo has several good systems for dealing with graphics applications, including the "turtle" system. These capabilities go beyond those of other programming languages available for DOS machines. I assume Turbo C will also have these features as well. 6. Turbo is heavily supported by after-market and free-ware packages and applications. Typical bulletin boards in the DC area will have 20 C-related files on hand, 45 Basic files, and 200 Turbo files. C programmers end up spending an extra $100 or $200 for a new function library every time they turn around. For Turbo, an unbelieveable number of such items are lying around free. Things of this nature which are lying about on the various D.C. area BBS's and from the PC SIG (and which are, hence, free) include: a. A sprite editor and very clean and elegant system for producing animation and cartoon effects using Turbo. b. An assembler which generates accurate Turbo inline code. This is a biggie and could be used to do nearly anything which could ever be done on a PC. c. A good screen font creation and editing system for Turbo. d. A system for handling Dbase3 files. e. A system for handling Lotus (wks) files. f. A good asynchronous line handling routine for use in writing communications packages. g. Several very good general purpose window and menuing packages etc., including one, the QWIK21 library, which is actually better than any I've seen for C. h. A system for dealing with music exactly as Basic does; one simply changes the Basic "play" statements to "pibplay", a global editor change, and includes the handler .INC program in his code. i. A fast-fourrier transform system. j. A system for writing memory-resident programs in Turbo. k. A system for executing other programs from within a Turbo program. The driving force behind all of this is the $70 price tag, which has had the effect of generating 700,000 users out there, many of whom have bright ideas to contribute to the common pool of knowledge. This will also be true of Turbo C after a year or two. [whew, sorry to be so long-winded with that list, back to the original article] >2. A lack of a batch mode for compiles. Ever try to run Turbo Prolog from make? Ever try to run anybody else's Prolog from make? Correct me if I'm wrong, but I thought Borlands was the ONLY Prolog compiler and that all other implementations of Prolog were essentially interpreters, this being necessary to allow for the so-called "metalinguistic" features, the lack of which causes the hard-core AI freaks to decry TurboProlog the way they do. Have I missed something? >3. Bugs. I found several in Turbo Prolog, just screwing around for a day or >so (V1.0). Borland was nice enough to send me 1.1 unsolicited, but I haven't >verified that the bugs are gone. Why go with a new, untested product when there >are mature products around? The $100 price tag, speed (the up side of a compiled Prolog), module connectivity with other Turbo Languages, the good turtle graphics system, Philippe Kahn's winning smile...... By the way, have you ever gotten free upgrades to any other software products unsolicited? I know I never have. >I have been working for three years with C compilers daily, and have the >following two-bit reviews to offer: >1. MSC 4.0. Love codeview (but it has annoying bugs!), love the extensive >library. Code generation good to excellent. I haven't found any library bugs >myself, but supposedly if malloc fails, it will sometimes clobber DS. >ROM support sucks - regardless of the source they give you to startup. I regard 3.0 as satisfactory for small programs. Programs beyond 400 lines of code have always generated "module too large for post-optimization step" and other fun kinds of things, and I have encountered numerous failings which I regard as major. I haven't tried 4.0. >2. Aztec C86 - good to excellent code generation. Occasionally you will >still hit ugly code generation bugs in large models. Excellent ROM support. >Nice package of development tools, (make diff vi clone etc), but there are Failed every test I put it to, utterly failed to compile several standard UNIX items which the Mark Williams and Lattice compilers can readily handle, including the standard "cb.c". I didn't consider the Aztec compiler worth pursuing after that. I hate to say it; I see the Lattice and Mark Williams C compilers as the two best so far, which is pitiful. I plan to get a copy of Turbo C as close as I can to the first day it is available and put every copy of every other DOS C compiler which I have access to in the Potomac river where they belong. Ted Holden, IMS
gervers@gpu.utcs.toronto.edu (02/23/87)
in <619@imsvax.UUCP> ted@imsvax.UUCP writes >kent@ncoast of Cleveland Public Access UNIX, Cleveland, OH writes: > >>My opinion is : don't bother with Turbo C. There are other products out there >>that must be just or good (or better), and by all indications, Borland's Turbo >>C will share all of the drawbacks of the other Borland Products, to wit: > >>1. Non-standard (in troubling and non-trivial ways) implementations. Borland >>says that Turbo C will adhere to ANSI Standard C, but don't expect it to >>be any closer than Microsoft C 4.0. My bet is that it will be as close to >>ANSI C as Turbo Pascal is to ISO Pascal. Is this a fatal flaw? Depends on your >>point of view. It is definitely fatal in a professional, production >>environment. > >I've used Turbo Pascal in a professional production environment quite a lot. >It speeds up the professional production something like 10 to 1 over >using the C compilers which are available for PCs. Normally, all things Like comparing oranges with apples (the fruit). Ever tried to write Turbo Pascal with : var s : array [1..255] of string255 t : array [1..255] of string255 ? > > 1. Price: at a retail price of around $70 and a street price Yup, the price is great, and Turbo Pascal is a great product. Even I use it lots of time, but when anything BIG has to be done, it is always > 3. Turbo has the only completely believable debugging system in > the Micro world. All other debugging systems amongst PLUG for U of T Turing Compiler and Interpreter : :-) has anybody tried the Turing programming environment? It's an editor that highlights ALL errors upon compile instead of just one. > 4. Turbo is a large super-set of standard Pascal, with a Only a few extra commands. What about large memory model? I know a few (2?3?) packages are written to support large memory model with TP, but this is at BEST kludgy. > tremendously good interface into DOS and PC functionality, You got to be kidding!! Ever try to write external asm routines to use with TP? > things which lie outside of any of the ANSI standards for > programming languages. It actually allows machine-coded > routines to be imbedded right into Turbo routines (Turbo > inline code), allows DOS calls with the use of only one This method of programming involves either of : 1 . asm, link, exe2bin, hexdump OR 2 . MANUALLY translating the opcodes into things like $90 (NOP) \$CD\$21 (INT 21H) etc (you get the picture). > devices. Masm interfaces for the various C compilers are NOT AS CLEAN? You got to be kidding. > not as clean or elegant. I am assuming Turbo C will also > have this feature. > > 5. Turbo has several good systems for dealing with graphics > applications, including the "turtle" system. These > capabilities go beyond those of other programming languages > available for DOS machines. I assume Turbo C will also have > these features as well. You got to be kidding. The turtle system is fine as a toy to impress your kids, but can you write a commercial product based on it? [comments follow, which I would probably agree] Parting notes : I love TP, but I'm afraid you have made it into something it's not. If Turbo C is like TP, I'm sure I will buy a copy, but, I will treat it as an interpreter/debugging tool. Meanwhile, I use TP for any small program with minimal data, when it comes to large arrays, sorry. <Opinions are entirely mine> no smart comments here.
root@hobbes.UUCP (02/24/87)
> [lots of wide eyed drivel about Borland's New Turbo C]
Whoa! What's great about Turbo C?
It's made by Borland and it cost's $99.
What's not so great about it?
It's not shipping yet (April 1, if we are 'lucky')
You must order before July 1 to get the $99 price
It only will run on "IBM PC, XT, AT, or true compatibles"
ALTERNATIVE:
Why don't you take a look at the Datalight C compiler?
This $99 / $139 package includes:
library source code,
.obj, exe, and com program generation,
Full Unix System 5 language plus ANSI extentions
Global DATA FLOW optimization including 12 optimization parameters!
DOS Wildcard support
Compatable with Lattice C version 2.x
Interrupt handling IN C
ROMable code + Startup source,
Mouse support,
etc
If I was spending ~$100, guess what I'd buy?
Johnbrandon@tdi2.UUCP (02/27/87)
Quoted from <691@imsvax.UUCP> ["Re: Turbo C"], by ted@imsvax.UUCP (Ted Holden)... +--------------- | kent@ncoast of Cleveland Public Access UNIX, Cleveland, OH writes: | | >1. Non-standard (in troubling and non-trivial ways) implementations. Borland | >says that Turbo C will adhere to ANSI Standard C, but don't expect it to | >be any closer than Microsoft C 4.0. My bet is that it will be as close to | >ANSI C as Turbo Pascal is to ISO Pascal. Is this a fatal flaw? Depends on your | >point of view. It is definitely fatal in a professional, production | >environment. +--------------- For all practical purposes, there *is* no such thing as Standard Pascal. The ISO Pascal standard and Jensen/Wirth both define a language which lacks just about everything needed for real-world applications. So I can't port the program I wrote in the TOPS-20 ``souped-up Touretzki'' Pascal compiler to Turbo pascal? Well, I can't port it to Berkeley ``pc'' either. And maybe not even to VAX Pascal. Turbo Pascal has *finally* defined a practical standard for Pascal. Don't knock it. +--------------- | >2. A lack of a batch mode for compiles. Ever try to run Turbo Prolog from | make? | | Ever try to run anybody else's Prolog from make? Correct me if I'm | wrong, but I thought Borlands was the ONLY Prolog compiler and that all | other implementations of Prolog were essentially interpreters, this | being necessary to allow for the so-called "metalinguistic" features, | the lack of which causes the hard-core AI freaks to decry TurboProlog | the way they do. Have I missed something? +--------------- You can't run Turbo Pascal in batch mode, either. But the data sheet from Borland, as posted on the net, says that Turbo C *can* be used in Makefiles. (Standard Pascal doesn't make sense in Makefiles, anyway. Pascal doesn't support multiple modules, guys! Even Turbo's {$I filename.ext} directive is non-standard. +--------------- | >3. Bugs. I found several in Turbo Prolog, just screwing around for a day or | >so (V1.0). Borland was nice enough to send me 1.1 unsolicited, but I haven't | >verified that the bugs are gone. Why go with a new, untested product when there | >are mature products around? | | The $100 price tag, speed (the up side of a compiled Prolog), module | connectivity with other Turbo Languages, the good turtle graphics | system, Philippe Kahn's winning smile...... By the way, have you ever | gotten free upgrades to any other software products unsolicited? I know | I never have. +--------------- So Version 1.0 of *any* product won't have bugs? Also, Prolog is not what I would call a compileable language. That it can be done at all is surprising. +--------------- | >1. MSC 4.0. Love codeview (but it has annoying bugs!), love the extensive | >library. Code generation good to excellent. I haven't found any library bugs | >myself, but supposedly if malloc fails, it will sometimes clobber DS. | >ROM support sucks - regardless of the source they give you to startup. +--------------- See the recent discussion on MSC license policy. Borland doesn't restrict your rights with programs compiled using their products. Like h*ll I'm going to stick a *Microsoft* copyright on my whiz-bang program compiled with MSC -- *I* wrote the part of the program that does the interesting stuff. I am very much looking forward to Turbo C. In the meantime, I use Turbo Pascal for everything (including work on a rewrite of uuslave.c, via an assembler hook to access the com ports directly; the DOS drivers are worse than useless). And consider also that for another $50, you can buy the heart of a DBMS (!) written in Turbo Pascal (the Turbo Database Toolbox). Try getting C-ISAM at that price (worse, try getting Ingres). Borland is changing the nature of commercial software. Kudos to Phillipe Kahn for providing a system better than $400 packages (i.e. Turbo Pascal) for $50! ++Brandon -- ``for is he not of the Children of Luthien? Never shall that line fail, though the years may lengthen beyond count.'' --J. R. R. Tolkien Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon Tridelta Industries, Inc. CSNET: ncoast!allbery@Case 7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET@relay.CS.NET Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home) +1 216 974 9210
leder@ihlpm.UUCP (05/28/87)
TURBO C IS ALIVE AND WELL! By now, I am sure that most of you have plunked down your 69.95 (at Egghead in Chicago) or whatever demands your vendor has made to get TURBO C. If you have not, then you must because it is the fastest compiler on the market. It is as fast as BDS C (for those who remember CP/M) and it is nice. The only complaint that I have is that I have not been able to find a way to set the stack size. The exemod utility from the MSC 4.0 package reports that the requested stack is 128 bytes. Increasing this, using exemod helps some, but not enough for the particular program I wanted to run. I'm sure that the answer is just around the corner. I have now ported 3 fairly large programs with minimal effort with the exception of the stack problem. For those people who don't want to use the integrated environment, the same functuallity is available via command line commands for the compiler, linker, and a make utility. According to the documentation, the MS linker can read turbo .obj's but because of undocumented record types, they cannot interpret the MS .obj's. With one program that is a ~39K exe with MSC, it came out to ~35k with turbo C. The MSC options for program size reduction seem to make the program larger. If others want to send info (bugs, etc.) I will summarize on the net. Bob Leder
bright@dataio.UUCP (05/29/87)
In article <1148@ihlpm.ATT.COM> leder@ihlpm.ATT.COM (Leder) writes:
-By now, I am sure that most of you have plunked down your 69.95
-(at Egghead in Chicago) or whatever demands your vendor has made to get
-TURBO C. If you have not, then you must because it is the fastest
-compiler on the market. It is as fast as BDS C (for those who remember
-CP/M) and it is nice.
I beg to differ. Datalight C compiles faster, according to benchmarks
we've run. DeSmet C also is fast at compiling. In Borland's ads, they
carefully benchmarked it only against relatively slow compilers.ee163adj@sdcc18.ucsd.EDU (Steven "B.J." Martin) (06/12/87)
A bug in turbo c that hasn't yet been mentioned is a problem with huge model. In declaring an array greater than 64k or 2 arrays totaling greater than 64k the compiler gives a message that it is out of memory. I called Borland and they know about the problemand say it can be aleviated with a farmalloc. I haven't tried this yet, and am not sure whether the problem persists with structures other than arrays. I read in last weeks PC week that Microsoft is coming out with Quick C and MSC 5.0 and 5.0 will come with Quick C. Looks like Microsoft is afraid Borland will take over their compiler business (what's next Quick Pascal, can you imagine Microsoft advertising it as compatible with Turbo). Steven "B.J." Martin
todd@uhccux.UUCP (The Perplexed Wiz) (06/16/87)
In article <736@sdcc18.ucsd.EDU> ee163adj@sdcc18.ucsd.EDU (Steven "B.J." Martin) writes: >I read in last weeks PC week that Microsoft is coming out with Quick C and >MSC 5.0 and 5.0 will come with Quick C. Looks like Microsoft is afraid >Borland will take over their compiler business (what's next Quick Pascal, >can you imagine Microsoft advertising it as compatible with Turbo). FYI: I moved a couple of programs written in Microsoft C 4.0 that had a lot of interrupt calls [int86() & intdos()]. They compiled fine with no changes using Turbo C 1.0 and ran ok too. I've also been writing programs using Turbo C and then compiling them on a VAX 8650 running Ultrix ok too. Needless to say, I'm very pleased with the portability of code written using Turbo C so far. A real time saver. I saw Bill Gates on "The Computer Show" the other night demoing Quick C. It looks like it has a number of advantages over Turbo C. Will hold off making a judgement until I get my Microsoft C 5.0/Quick C upgrade though...todd -- Todd Ogasawara, U. of Hawaii Computing Center UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd ARPA: uhccux!todd@nosc.MIL INTERNET: todd@uhccux.UHCC.HAWAII.EDU
frisk@askja.UUCP (Fridrik Skulason) (08/04/87)
I have heard that Borland does not change the version number of the
Turbo C compiler when fixing bugs.
Now - the good thing about this is that you don't have to wait for months
for the fixes, but unfortunately it's hard to know just which bugs have
been fixed in "your" version.
Since I have never seen a list of the various versions, I am going to
create one.
So - those of you using Turbo C, and having a few spare minutes how
about mailing the following information to me:
TC creation date [on the original disk please, not your HD copy]
TC size
Known fixes in this version
The resulting list will probably appear a few days after the replies stop
arriving......
--
Fridrik Skulason Univ. of Iceland, Computing Center
UUCP ...mcvax!hafro!askja!frisk BIX frisk
"This line intentionally left blank"dalegass@dalcsug.UUCP (09/17/87)
Maybe I've just been incredibly spoiled by Aztec C, but I find Turbo C to generate relatively larger and slower code (except for stdio, which Aztec C kinda flops on). I don't know why everybody is so crazy about it, except possibly for the nice environment. I've found very many cases of redundant instructions in the code that a very minimal peephole optimizer would pick up, such as MOV var,AX MOV AX,var. And where a simple MUL or DIV would suffice, there always seems to be a bunch of pushes and calls. I won't even mention the stack screwups it's generated, which caused major crashes... Overall, I'm not very impressed, although I do like the environment. Hopefully Turbo C ver 2.0, or QuickC will offer good optimization with this type of environment... -dalegass@dalcsug.uucp
glazer@osupyr.UUCP (09/20/87)
Could one of you Turbo C hackers out there please e-mail me the phone number for Borland's technical help. I would like to order the latest release. The version I have is 1.0000000 and not bugless. Thanks Jon ******************************************************************************* * * * At * * Jon Glazer * The |\/| | | * Ohio State University * * Sysop of MGS (IBM BBS) * | | | | * Columbus, Ohio * * (614)-848-5971 * | |ICRO |/\|IZARD * Via PYRAMID * * * * [glazer@osupyr.UUCP] * * * * [glazer%osupyr@cbosgd] * *******************************************************************************
Aron_Fingers_Nelson@cup.portal.com (09/21/87)
Borland (408) 438-8400 Ask for costumer support.