mikem@slp.UUCP (Mike Morris) (06/30/89)
I am considering purchasing Borland's Turbo C 2.0 professional package and
am wondering what kind of experiences other netland users have had using it.
I have used both Microsoft's codeview and Borland's Turbo debugger and feel
that the Turbo debugger totally outshines codeview. But what about the rest
of the Borland professional package such as the Turbo C compiler and Turbo
Assembler (TASM)?
Thanks in advance.
--
Mike Morris, Strategic Locations Planning {hpda,pyramid}!octopus!slp!mikemusenet@cps3xx.UUCP (Usenet file owner) (06/30/89)
in article <644@octopus.UUCP>, mikem@slp.UUCP (Mike Morris) says: > > > I am considering purchasing Borland's Turbo C 2.0 professional package and > am wondering what kind of experiences other netland users have had using it. Having used both professionally, I'd highly recommend Turbo over Microsoft. On the basis of just the C compiler Turbo has two features that aren't found in Microsoft. (1) Turbo has inline assembler. (2) Turbo can declare functions as interrupt routines. For both of these in Microsoft you need a separate assembler module (unless I missed something in the manual). Turbo's manuals are also easier to find things in. CUrrently, I'm trying to decide if I like Zortech C better than Turbo C. The facilities for generating interrupt functions are far easier to use and the online help TSR is great. I use MicroEmacs instead of going through Turbo's integrated development env. so I have no access to their online help when editting. Unfortunately, Zortech has no inline assembler, but does provide a macro package that makes generating assembler modules far easier. I haven't tried ZOrtech's debugger yet. I generally use codeview or turbo debugger and look at the stack frames by hand. Hope this helped, John H. Lawitzke UUCP: Work: ...uunet!frith!dale1!jhl Dale Computer Corp., R&D Home ...uunet!frith!ipecac!jhl 2367 Science Parkway Internet: jhl@frith.egr.msu.edu Okemos, MI, 48864 [35.8.8.108]
wew@naucse.UUCP (Bill Wilson) (07/05/89)
From article <644@octopus.UUCP>, by mikem@slp.UUCP (Mike Morris): > > I am considering purchasing Borland's Turbo C 2.0 professional package and > am wondering what kind of experiences other netland users have had using it. > I have been using the Turbo C professional package since its introduction and am very happy with it. I have ported a number of packages from Unix to the PC environment (shar, diff, Gnuplot, Gnuplot Help) and have had very few problems. The Gnuplot port was interesting. I only had to make a few additions using the TC graphics library and it worked without a flaw. Most of the code that I have tried out works fine without any changes. Some code that uses things like signal or other more Unix oriented protocol needs a little closer inspection. In contrast to this, MSC at least in the Gnuplot area needed to have special .asm files written to handle most of the graphics. As far as TASM goes, I haven't had any problems with it either. Every piece of code that I have tried assembles without any errors. And the resulting programs even work as they should! For the money, I would go with the Borland products. Have you ever tried MS tech support? -- Bill Wilson (Bitnet: ucc2wew@nauvm) Northern AZ Univ Flagstaff, AZ 86011 {Let sleeping dragons lie......}
fredex@cg-atla.UUCP (Fred Smith) (07/12/89)
In article <3607@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes: >in article <644@octopus.UUCP>, mikem@slp.UUCP (Mike Morris) says: >> >> >> I am considering purchasing Borland's Turbo C 2.0 professional package and >> am wondering what kind of experiences other netland users have had using it. > >Having used both professionally, I'd highly recommend Turbo over >Microsoft. On the basis of just the C compiler Turbo has two features >that aren't found in Microsoft. (1) Turbo has inline assembler. >(2) Turbo can declare functions as interrupt routines. For both of >these in Microsoft you need a separate assembler module (unless I >missed something in the manual). Turbo's manuals are also easier >to find things in. > ---------------------------------------- Below is a short piece of code written for Microsoft C 5.1 which illustrates how easy it is to write interrupt routines in C, despite what the other poster said. He was right, however, in the implication that it is difficult to find things in the Microsoft manuals. They contain lots of information, but somehow locating the particular piece you need is difficult. Please note that some of the information on interrupt routines is hidden in the various documentation supplement files provided on the distribution floppies so that it IS difficult to find. I must admit that I have not had the opportunity to use Turbo C or Zortech C, so I cannot offer a comparison--I just felt called upon to correct the error stated in the previous posting. This program is a complete program which you can test easily--just compile with MSC 5.1 using the -DDEBUG switch on the command line and try it! ulowell!cg-atla!fredex ------------------------------ #include <stdio.h> #include <dos.h> static void intercept_timer(void); static void restore_timer(void); static void interrupt far newtimer (void); static void (interrupt far *oldtimer)(void); static unsigned int ticker = 0; #define timeup() (ticker==0) #define timerset(tenths) ticker=(unsigned int)((long)tenths*182L/100L+1L) #define TIMER 0x1c #define getvect _dos_getvect #define setvect _dos_setvect static void intercept_timer (void) { if (oldtimer == NULL) { oldtimer = getvect(TIMER); setvect (TIMER, newtimer); } } static void restore_timer(void) { if (oldtimer) setvect(TIMER, oldtimer); oldtimer = NULL; } static void interrupt far newtimer() { (*oldtimer)(); /* call old timer ISR */ if (ticker) --ticker; } void sleep(int seconds) { intercept_timer (); timerset (seconds * 10); while ( ! timeup()) ; restore_timer (); } #if DEBUG #include <stdio.h> main() { char input[100]; int val; long when; printf ("Enter delay amount in 1/10 seconds: "); gets (input); val = atoi (input); intercept_timer(); when = timerset (val); while (!timeup (when)) ; restore_timer(); } #endif
suitti@haddock.ima.isc.com (Stephen Uitti) (07/13/89)
> informed discussion of ease of manual reading & use of interupts > deleted. TC - Borland's Turbo C compiler. MSC - MicroSoft's C compiler (big momma rather than Quick C) I have TC 1.5 (some dispute over the version number), TC 2.0, and MSC 5.0. I don't have MSC 5.1. I bought MSC 5.0 because i had some MSC code that i wanted to compile. It didn't compile. I could make it compile, but not easier than porting it to TC. The problem was that the code was written using MSC 4.0. MSC 5.0 has infinite bugs, is slow to compile, has a horribly complicated command line interface, comes with a tiny compiler (quickc) that has a good environment, but is not quite compatible, and is not really a production compiler (doesn't support enough of the machine models). TC has a nice environment (though the editor isn't MY editor), compiles quickly, has lint-like features, better than UNIX lint, understands the ANSI features (and does the right things with them), supports the machine well, has good manuals, has an awesome debugger, assembler. I'm told that MSC 5.1 is better than 5.0 - that it doesn't die when compiling stuff, and that it produces correct code more often. I'm unlikely to get the upgrade, even if it is free. The fact will remain that the compiler will produce code slowly, and it will be a pain to get the compiler to do anything at all by comparison. I never did find a bug in either TC 1.5 or TC 2.0. That's the way i like it. I only ever called customer support to upgrade. I only upgraded to get the debugger. Curiosly, i'm a UNIX hack with 8 years of experience, and i do makefiles. Under TC, however, i don't bother with makefiles - i just use the integrated environment and set up a project file. It is easy. It compiles 7000 lines per minute on my 7 MHz XT clone (we're talking 8 bits at a time here). My 386/25 running UNIX doesn't compile stuff faster, and you still have to run lint, and you have to wade through the output looking for something that means "you have a bug", rather than TC's "look at this and fix it and it will be one less thing to go wrong". I turn on all errors and warnings in TC. I use prototypes. Stephen.
grano@kreeta.cs.Helsinki.FI (Juhani Grano) (07/14/89)
In article <3607@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes:
!CUrrently, I'm trying to decide if I like Zortech C better than Turbo C.
!The facilities for generating interrupt functions are far easier to use
!and the online help TSR is great. I use MicroEmacs instead of going
!through Turbo's integrated development env. so I have no access to their
!online help when editting. Unfortunately, Zortech has no inline
!assembler, but does provide a macro package that makes generating
!assembler modules far easier. I haven't tried ZOrtech's debugger yet.
!I generally use codeview or turbo debugger and look at the stack frames
!by hand.
Borland supplies an utility programme called THELP bundled with TC 2.0.
This is a resident utility, which allows the use of TC online help via
your favorite editor. I use it with MicroEmacs.
Another point about Microsoft C that has not been mentioned is that many
third-party libraries depend heavily upon it. I had to purchase
Microsoft C 5.1 for my current project for that reason, though I prefer the
graphics features of Turbo C. MSC 5.1 offers some graphics support too,
though, and it's compile time is better than with MSC 4.0, but still
sooou far behind TC... sigh.
Another point. The CodeView debugger supplied with MSC seems to be able
to handle larger programs than the Turbo Debugger supplied with TC
Professional package. I have successfully debugged 300+ KB programs with
it, having the standard 640K core. With TD, I remember having
difficulties with 200+ KB programs.
------------------------------
Kari Grano University of Helsinki, Finland
email to: grano@cs.helsinki.fi Department of CS
"I have a thousand telephones that don't ring"scole@tekirl.LABS.TEK.COM (Steve Cole) (07/14/89)
In article <14015@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes: [Lots deleted...] >[MSC 5.0] comes with a tiny compiler (quickc) that >has a good environment, but is not quite compatible, and is not >really a production compiler (doesn't support enough of the >machine models). I'd just like to point out a few things about the NEW version of Microsoft's Quick C (version 2). -It supports all of the memory models available on the IBM PC (small, medium, compact, large, huge.) -It has a *very* much improved interface over QuickC v. 1. (Primarily better help -- All of the library routines have online documentation, as well as things like symbolic constants and C language reference) -It comes with new Presentation Graphics libraries that didn't come with MSC 5.1. (To draw graphs and such.) -It comes with a *new* make utility so that the makefiles you use with Quick C will also work under UNIX. -It uses incremental linking and compiling even on the old 8086 boxes to try and help speed compile and link times. -It supports inline assembly code. (No external assembler required.) -The help system is extendable: If you have your own personal libraries, you can write your own help pages and link them into the built in help system. (The system uses "hyperlinks" to move from spot to spot; this is very nice.) -It has its own debugger, and can produce code for use with CodeView. It still compiles slowly, but that may be because I still use an archaic PC XT, and everything seems slow. I've been very very impressed with this new system. The help is wonderful; I'd always wanted my instant UNIX man pages when programming on the PC, and now I've got something better. Version 2 is simply heads and tails better than version 1. I quite seriously don't see any reason to use the "big" compiler, MSC 5.1, instead. (By the way, my version of QuickC is newer than my 5.1, it may be that much of this stuff has been added to MSC since I got mine.) Steve Cole, scole@tekirl.labs.tek.com, or scole@sim.berkeley.edu (when the semester starts again).
cliff@ficc.uu.net (cliff click) (07/14/89)
In article <14015@haddock.ima.isc.com>, suitti@haddock.ima.isc.com (Stephen Uitti) writes: > MSC 5.0 has > infinite bugs, is slow to compile, has a horribly complicated > command line interface, [...] > I'm told that MSC 5.1 is better than 5.0 - that it doesn't die > when compiling stuff, and that it produces correct code more > often. True; don't use 5.0, get 5.1. It does produce better code than TC 2.0, just alot more slowly. I use TC 2.0 for all my development, and MSC 5.1 for the final release code. -- Cliff Click, Software Contractor at Large Business: uunet.uu.net!ficc!cliff, cliff@ficc.uu.net, +1 713 274 5368 (w). Disclaimer: lost in the vortices of nilspace... +1 713 568 3460 (h).
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (07/15/89)
In an article of <12 Jul 89 13:00:06 GMT>, (Fred Smith) writes: >I must admit that I have not had the opportunity to use Turbo C or >Zortech C, so I cannot offer a comparison--I just felt called upon to >correct the error stated in the previous posting. I do use all three professionally and would offer a few quick comments on the interrupt issue in particular and the three compilers in general... First of all, neither MSC nor TC give you any control over the local stack required by an ISR. The code posted showing ISR implementation in MSC was quite correct - i.e. it's not a daunting task. TC is perhaps a little easier to use, but both are comparable. Zortech provides a function `int_intercept()' which you pass a function name and a stack size. The specified function is passed all the registers in an array. The function's return value determines whether the you return immediately or if the previous ISR is chained to. There's no need for the non-standard "interrupt" keyword since any function can be an ISR, plus the programmer is in total control of the ISR's local stack. Note also that MSC does not properly support `volatile' although it does recognize it as a keyword - ZTC and TC do support it. So much for the posted code - any of the three can do the job without too much distress. ZTC's most powerful, TC's easiest, and MSC's OK, too. In general, MSC is the type of product usually described as a workhorse. It's quite good, but it's the type of product that inspires supporters rather than enthusiasts - a subtle but real distinction. MSC's manuals are the best of the lot, although you may get tired of wading through them before you find what you want. MSC's compile times are the worst of the lot. Even without optimization, MSC compiles slowly compared to the other two. MSC's optimizer works well, but is often overly aggressive, often breaking otherwise working code. The be safe, try to avoid loop optimizations or full optimization (-Ox or -Ol). MSC comes with Quick C to enable quick compiles prior to the "real" code generation pahse. Whenever the new QC 2.0 is shipped with MSC, it will make the whole package more appealing. Finally, if you're working with MS Windows or OS/2, it's probably the best way to go for now. The CodeView debugger was revolutionary when introduced, but has been passed by now. TC offers the fastest compile times of the three. A non-optimizing compiler, TC still has an excellent code generator and often produces the tightest .EXE files. Tyros and ex-Turbo Pascal programmers particularly are fond of its integrated environment, although impartial observers might prefer QC 2.0's. In general, TC is a good, competent all-around package with many rabid followers. On the negative side, everything in the TC package has a voracious appetite for memory. The integrated environment is almost useless for any large source files and the integrated editor neither supports windows nor source files over 64K (yeah, I know, but in the real world we sometimes have to deal with such beasts even if someone else wrote them!) If you're a pro, you'll likely use the command-line version of the compiler, your own editor and their excellent (but still memory-hungry) Turbo Debugger, sold separately or combined in the Professional Pack. But remember, watch out for your TSR's and carefully husband your memory - even the command-line compiler plus the librarian and linker eat memory like it's going out of style! Finally, Zortech - my personal favorite (your mileage may vary). Without optimization, it compiles almost as fast as TC. With full optimization, it slows down to MSC territory, but never breaks working code. It's .EXE sizes are often lower than TC and consistently better than MSC. Code quality is excellent and I/O speed is outstanding. The separate debugger is also excellent and can compete with TD. Originally marketed as Datalight Optimum-C, Walter Bright's compiler had an excellent reputation and cult following particularly among embedded systems programmers. ZTC continues to be an excellent compiler for embedded applications, though Zortech's marketing and support efforts are all directed at the C++ market. The compiler is modular, the only difference between the C and C++ compilers being the first pass parser/preprocessor - when you buy ZTC++, you get ZTC for free. Zortech has thrown in a few extras the mass market expects - pseudo-integrated editor, etc. - and they're generally quite good as well, but not up to the compiler's standards. One standout here is their resident help facility which may be used from within anybody's editor and includes library references. Fast, tight, and powerful - I use MSC and TC for clients, but for my own products, it's ZTC.
stuart@bms-at.UUCP (Stuart Gathman) (07/16/89)
In article <1169@hydra.cs.Helsinki.FI>, grano@kreeta.cs.Helsinki.FI (Juhani Grano) writes: > Another point. The CodeView debugger supplied with MSC seems to be able > to handle larger programs than the Turbo Debugger supplied with TC > Professional package. I have successfully debugged 300+ KB programs with > it, having the standard 640K core. With TD, I remember having > difficulties with 200+ KB programs. Turbo debugger comes with two programs to debug large applications. 1) remote debugging works with 2 PC's linked with a serial cable. Only a small stub resides with the application, all the symbol tables & window goodies are on the other PC. Can, incidently, be used for 115000 baud file transfer also. GREAT! 2) 386 debugger uses virtual 8086 mode to accomplish the same feat. I don't have a 386 and haven't tried this.
campbell@redsox.bsw.com (Larry Campbell) (07/16/89)
In article <5002@ficc.uu.net> cliff@ficc.uu.net (cliff click) writes:
-
-I use TC 2.0 for all my development, and MSC 5.1 for the final release code.
This seems irresponsible to me. It basically guarantees that if MSC ever
generates obscurely bad code, you probably won't find out until a customer
calls to complain about your software dying a horrible death.
Using different tools to develop a product than the tools used to build the
final release for customers is a VERY bad idea.
[Since this issue is not C-related, I've directed followups to
comp.software-eng.]
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (07/17/89)
In an article of <14 Jul 89 13:02:11 GMT>, (cliff click) writes: >True; don't use 5.0, get 5.1. It does produce better code than TC 2.0, >just alot more slowly. > >I use TC 2.0 for all my development, and MSC 5.1 for the final release >code. I use Zortech C 1.07 with the optimization turned off for all my development (compiles at about the same speed as TC 2.0), then turn on optimization for the final release version with code quality comparable to (often better than) MSC. Same result, one compiler - savings > $400...
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (07/17/89)
In an article of <13 Jul 89 23:18:10 GMT>, (Juhani Grano) writes: >Borland supplies an utility programme called THELP bundled with TC 2.0. >This is a resident utility, which allows the use of TC online help via >your favorite editor. I use it with MicroEmacs. Borland's THELP is useful for checking language syntax and checking errors but lacks a complete set of library references like the Zortech help system does. >Another point. The CodeView debugger supplied with MSC seems to be able >to handle larger programs than the Turbo Debugger supplied with TC >Professional package. I have successfully debugged 300+ KB programs with >it, having the standard 640K core. With TD, I remember having >difficulties with 200+ KB programs. Borland supplies a version for 386 boxes to run in protected mode, leaving application program memory clear. Without a 386, you can try using a second machine and the remote debuggingg version. For a compiler which built a lot of its reputation on producing tight code, Borland's tools are memory hogs! Zortech's debugger isn't quite as good as TD, but it's a lot better than CV and uses less memory than either.
bright@Data-IO.COM (Walter Bright) (07/18/89)
In article <1169@hydra.cs.Helsinki.FI> grano@cs.helsinki.fi writes:
<Another point about Microsoft C that has not been mentioned is that many
<third-party libraries depend heavily upon it. I had to purchase
<Microsoft C 5.1 for my current project for that reason, [...]
If you want to use compiler X, but third-party library Y doesn't support
it, call up the library vendor and request it. Most library vendors are
sensitive to customer demand, but if they don't know that customers
want support for compiler X, they won't think it's worthwhile to support it.
For most libraries, supporting a new compiler is a simple matter of
recompiling the library and then testing it. This means that a library
vendor does not have to sell many packages for compiler X to pay back
the additional development costs. Thus, calling them and requesting it
can make a bigger difference than you might expect.
Not so many PC vendors read Usenet, so complaining here has limited
usefulness.