troj@icon.weeg.uiowa.edu (03/14/90)
In <10125@portia.Stanford.EDU>, dma@nova.stanford.edu (Domingo Mihovilovic A) writes: >Hi, > I am planning to switch from Pascal to C, and I have the doubt >of Turbo or Microsoft. I would choose Borland because I have been >working with Turbo Pascal and it is very good. > > Do you know of some real and important differences that could move >me to select Microsoft C instead of Turbo C ? > Thanks for your comments, > >Domingo Mihovilovic A. >dma@scotty.stanford.edu 1) Turbo-C costs lots less than full MSC, and about the same as Quick-C. 2) Borland's debugger is better than Codeview, though it costs extra. For a bit less than MSC alone would cost (approx $275 mail-order, I believe), you can pick up Turbo-C professional (approx $200, I believe) which gives you Turbo-C 2.0, Turbo Debugger 1.5, and Turbo Assembler 1.5. 3) Turbo-C compiles faster than MSC, though from what I've read, MSC performs better optimization. 4) I prefer Borland's documentation, though Microsoft's is very usable. 5) MSC consumes significantly more space on a hard drive than Turbo-C does. When I switched from QuickC 1.0 (no HUGE model) to Turbo-C, my total drive space used by the C compiler was actually reduced! Full MSC takes even more than QuickC. Basically, in my opinion, you can't go wrong either way, but I definitely prefer Turbo-C. If you do go the Turbo-C route, I'd strongly suggest you purchase Turbo-C Professional, just for the sake of the debugger alone. Turbo Debugger has saved me countless hours on single projects alone. -Kevin Trojanowski troj@umaxc.weeg.uiowa.edu trojpg@uiamvs.bitnet troj@cadfx.ccad.uiowa.edu
tom@mims-iri (Tom Haapanen) (03/14/90)
>> Do you know of some real and important differences that could move >> me to select Microsoft C instead of Turbo C ? Kevin Trojanowski <troj@icon.weeg.uiowa.edu> writes: >1) Turbo-C costs lots less than full MSC, and about the same as Quick-C. > >2) Borland's debugger is better than Codeview, though it costs extra. For > a bit less than MSC alone would cost (approx $275 mail-order, I believe), > you can pick up Turbo-C professional (approx $200, I believe) which gives > you Turbo-C 2.0, Turbo Debugger 1.5, and Turbo Assembler 1.5. In version 6.0 of Microsoft C (as of last week, unannounced, but previewed in the March BYTE), Codeview has an improved data inspector, and can now run in extended memory on 286/386/486 machines. It also has more help. >3) Turbo-C compiles faster than MSC, though from what I've read, MSC performs > better optimization. ...and MSC 6.0 does better optimization yet. >4) I prefer Borland's documentation, though Microsoft's is very usable. Doesn't Borland still use the paperback-style manuals? If so, I'd galdly pay $50 extra to get real binders as with MSC. MSC has comprehensive documentation, but I haven't used Turbo C, so I can't compare. >5) MSC consumes significantly more space on a hard drive than Turbo-C does. > When I switched from QuickC 1.0 (no HUGE model) to Turbo-C, my total drive > space used by the C compiler was actually reduced! Full MSC takes even > more than QuickC. 6) Microsoft C generates code for OS/2 and Windows as well as DOS, including DLL's. 7) MSC 6.0 includes a real Make, not the abomination in MSC 5.0, plus a makefile generator which looks for dependencies. 8) MSC 6.0 has the Browser; this is something like a fancy interactive cross-referencer, which uses the information built by the compiler. >Basically, in my opinion, you can't go wrong either way, but I definitely >prefer Turbo-C. Ditto, except I prefer MSC. :) Take a look at March BYTE, page 115. [ \tom haapanen -- university of waterloo -- tom@mims-iris.waterloo.edu ] [ "i say what i say, but i say it for myself and myself only" -- me ] [ "i don't even know what street canada is on" -- al capone ]
cjwein@watcgl.waterloo.edu (Chris J. Wein) (03/14/90)
In article <924@ns-mx.uiowa.edu> troj@icon.weeg.uiowa.edu () writes: >In <10125@portia.Stanford.EDU>, dma@nova.stanford.edu (Domingo Mihovilovic A) >writes: > >If you do go the Turbo-C route, I'd strongly suggest you purchase >Turbo-C Professional, just for the sake of the debugger alone. Turbo Debugger >has saved me countless hours on single projects alone. > Just a note but recently, Borland and Watcom signed an agreement where Turbo Debugger (v2.0) will be compatible with Watcom's C compiler. There will be a translation program which converts Watcom OBJ files to TDEBUGGER compatible format. Maybe this is a third option. I have no personal experience with the Watcom product but it's code generation is supposedly at or near the top in the industry. By the way, this is not a plug for the Watcom C compiler...just a tidbit of info FYI.
ferris@eniac.seas.upenn.edu (Richard T. Ferris) (03/15/90)
Could someone tell me what the latest version of Turbo Assembler/ Turbo Debugger is? Is version 2 available for both or either of these now? I have Turbo C and I'd like to get the most recent versions of Assembler/Debugger. Thanks. Richard T. Ferris ferris@eniac.seas.upenn.edu University of Pennsylvania
peggy@pyr.gatech.EDU (Cris Simpson) (03/15/90)
In article <1468@watserv1.waterloo.edu> tom@mims-iri (Tom Haapanen) writes: >>> Do you know of some real and important differences that could move >>> me to select Microsoft C instead of Turbo C ? > >Kevin Trojanowski <troj@icon.weeg.uiowa.edu> writes: >In version 6.0 of Microsoft C (as of last week, unannounced, but previewed >in the March BYTE), [stuff deleted] > >>4) I prefer Borland's documentation, though Microsoft's is very usable. Get Serious! > >Doesn't Borland still use the paperback-style manuals? If so, I'd galdly >pay $50 extra to get real binders as with MSC. MSC has comprehensive >documentation, but I haven't used Turbo C, so I can't compare. Unfortunately, you can expect MS to have paperback manuals too. Witness the OS/2 Programmer's Ref. In addition, they abandoned the one-function-per-page "rule" with OS/2 1.1 Prog Ref kit. From talking to MS people here and on CI$, paperback is the way of the future. (Boo! Hiss!) I'm told it was a "marketing decision". (stupid marketing decision, IMHO). cris
lmm@cci632.UUCP (Lance Michel) (03/15/90)
In article <9944@pyr.gatech.EDU> peggy@pyr.UUCP (Cris Simpson) writes: >In article <1468@watserv1.waterloo.edu> tom@mims-iri (Tom Haapanen) writes: >>>> Do you know of some real and important differences that could move >>>> me to select Microsoft C instead of Turbo C ? NO!
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/18/90)
In article <35104@cci632.UUCP> lmm@op632.UUCP (Lance Michel) writes: >In article <9944@pyr.gatech.EDU> peggy@pyr.UUCP (Cris Simpson) writes: >>In article <1468@watserv1.waterloo.edu> tom@mims-iri (Tom Haapanen) writes: >>>>> Do you know of some real and important differences that could move >>>>> me to select Microsoft C instead of Turbo C ? > >NO! There is some value to using the industry standard for production work. On the other hand the "real" differences are probably insignificant. Borland is turning out stuff that is just as rock-solid as Microsoft, and they are pretty much in the same league. Borland does have the advantage of lower cost. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
jhallen@wpi.wpi.edu (Joseph H Allen) (03/18/90)
In article <924@ns-mx.uiowa.edu> troj@icon.weeg.uiowa.edu () writes: >In <10125@portia.Stanford.EDU>, dma@nova.stanford.edu (Domingo Mihovilovic A) >writes: > >> Do you know of some real and important differences that could move >>me to select Microsoft C instead of Turbo C ? >> Thanks for your comments, >[good comparison] Also for turbo C's __emit__() function and the pseudoregisters are invaluable for MS-DOS programming. You can make TSRs with no assembly language at all. -- "Come on Duke, lets do those crimes" - Debbie "Yeah... Yeah, lets go get sushi... and not pay" - Duke
srg@cunixd.cc.columbia.edu (Steven R Gerber) (03/19/90)
In article <9771@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: >In article <924@ns-mx.uiowa.edu> troj@icon.weeg.uiowa.edu () writes: >>In <10125@portia.Stanford.EDU>, dma@nova.stanford.edu (Domingo Mihovilovic A) >>writes: >> >>> Do you know of some real and important differences that could move >>>me to select Microsoft C instead of Turbo C ? >>> Thanks for your comments, >>[good comparison] > >Also for turbo C's __emit__() function and the pseudoregisters are invaluable >for MS-DOS programming. You can make TSRs with no assembly language at all. >-- > "Come on Duke, lets do those crimes" - Debbie >"Yeah... Yeah, lets go get sushi... and not pay" - Duke I don't know what the __emit__() function does. But, MS-C has pseudo-registers and "you can make TSRs with no assembly language at all." **************************************************************** * Steven R. Gerber - PAL (Programmer At Large) * srg@cunixd.cc.columbia.edu * Tel: 212-794-8721 * UUCP: ...rutgers!columbia!cunixd!srg * FAX: 212-794-8722 ****************************************************************
aj-mberg@dasys1.uucp (Micha Berger) (03/26/90)
I bought quickC, because it was cheaper, at least in the stores around here, then TurboC. I since realized that TurboC has several functions that QuickC doesn't, basically aimed toward home programming. (For example, there is no QuickC function to control the beeper.) On the other hand, QuickC has features, more geared toward professional programmers. (For example there is not only a graphics library, but a second, business graphics library.) It also have special niceties for system programmers. It allows you to declare a function to be a driver for a given interrupt, the debugger and integrated system are for both C and MASM, the inline code is full MASM. I also liked being full MicroSoft C compatable. Each claim that they produce faster code. For the same benchmarks. I don't know how. Comments? I also underplayed TurboC's advantages. But is my basic categorization (but TurboC for the home, QuickC for work - business or system programming) correct? -- Micha Berger mberger1%tasha@graf.poly.edu Imitatio Dei means never having to say "I'm sorry."
dank@eng.umd.edu (Daniel R. Kuespert) (03/27/90)
In article <1990Mar26.154024.11739@dasys1.uucp> mberger1%tasha@graf.poly.edu (Micha Berger at Polytechnic U.) writes: >On the other hand, QuickC has features, more geared toward professional >programmers. (For example there is not only a graphics library, but a second, >business graphics library.) It also have special niceties for system >programmers. It allows you to declare a function to be a driver for a given >interrupt, the debugger and integrated system are for both C and MASM, the >inline code is full MASM. ... >Each claim that they produce faster code. For the same benchmarks. I don't >know how. Comments? ... >I also underplayed TurboC's advantages. But is my basic categorization (but >TurboC for the home, QuickC for work - business or system programming) >correct? Doesn't sound like the Quick C I know and hate. I've never played with QC graphics, but Borland's BGI system is miles ahead of the crude MSC library. (It also has business-type graphics like bars and pies.) Both Quick C and Turbo C's integrated debuggers are toys, more suitable for home use; with the Turbo C Professional package you get Turbo Debugger, which is a considerable improvement on the Turbo C integrated debugger and makes CodeView look like DEBUG. All in all, I'd reverse the categorizations you've applied to the two products. "Who has the fastest code" is difficult to measure because companies sometimes customize their compilers to win benchmarking contests. Speed on a benchmark does not necessarily translate to speed on _your_ application. Both Quick C and Turbo C are credible compilers, although Turbo C would most likely edge out Quick C (there's a PC Tech Journal article comparing the two as well as several commercial compilers--Jan or Feb '88, I think). For fast code and really good optimization, MSC is the way to go. Unless you're doing really loop-intensive types of code, though, it may not be worth coping with all the command-line switches and byzantine error messages MSC spews out, though. dan Daniel R. Kuespert Chemical Process Systems Laboratory University of Maryland, College Park dank@eng.umd.edu
boerner@ut-emx.UUCP (Brendan B. Boerner) (03/27/90)
In article <1990Mar26.174313.1976@eng.umd.edu> dank@eng.umd.edu (Daniel R. Kuespert) writes: >Both Quick C and Turbo C's integrated debuggers are toys, >more suitable for home use; with the Turbo C Professional package you get >Turbo Debugger, which is a considerable improvement on the Turbo C I have seen comments similiar to the above and finally decided to find out what I am missing. I have spent the last year working on a 33,000+ line application written in Turbo Pascal and estimate that I have used the Integrated Enviroment ~90% of the time. The other 10% of the time I used the Turbo Debugger in order to debug assembler. It is true that I was at home while writing the code (:-)), but I think that I was able to be more productive since a) the IDE compiled/linked my code faster than the command line compiler, and b) I could compile and run, not compile, load the debugger, load the .EXE, and then run. Comments? Brendan -- Brendan B. Boerner Phone: 512/471-3241 Microcomputer Technologies The University of Texas @ Austin Internet: boerner@emx.utexas.edu UUCP: ...!cs.utexas.edu!ut-emx!boerner BITNET: CCGB001@UTXVM.BITNET AppleLink: boerner@emx.utexas.edu@DASNET#
stever@Octopus.COM (Steve Resnick ) (03/27/90)
>Both Quick C and Turbo C's integrated debuggers are toys, >more suitable for home use; with the Turbo C Professional package you get >Turbo Debugger, which is a considerable improvement on the Turbo C >integrated debugger and makes CodeView look like DEBUG. All in all, >I'd reverse the categorizations you've applied to the two products. > I would welcome seeing a better debugger than Turbo Debug. I think td is the best debugger I have ever used on any system. Barrning None! Steve (My $.02)
dank@eng.umd.edu (Daniel R. Kuespert) (03/28/90)
In article <26942@ut-emx.UUCP> boerner@emx.UUCP (Brendan B. Boerner) writes: >In article <1990Mar26.174313.1976@eng.umd.edu> dank@eng.umd.edu (Daniel R. Kuespert) writes: >>Both Quick C and Turbo C's integrated debuggers are toys, >>more suitable for home use; with the Turbo C Professional package you get >>Turbo Debugger, which is a considerable improvement on the Turbo C > >I have seen comments similiar to the above and finally decided to find >out what I am missing. I have spent the last year working on a 33,000+ >line application written in Turbo Pascal and estimate that I have used >the Integrated Enviroment ~90% of the time. The other 10% of the time >I used the Turbo Debugger in order to debug assembler. > >It is true that I was at home while writing the code (:-)), but I think >that I was able to be more productive since a) the IDE compiled/linked >my code faster than the command line compiler, and b) I could compile >and run, not compile, load the debugger, load the .EXE, and then run. I hadn't meant to say that TD is better than the IDE debugger in all circumstances. For small and/or simple programs, the IDE is quite enough. Additionally, the early stages of (attempting to) compile a larger program call for the use of the IDE if at all possible, since it takes some time before all the stupid mistakes (like calling scanf() with variable values rather than pointers, which I'm _still_ doing after 2+ years of C experience) are worked out. Nevertheless, I've found TD to be invaluable for debugging errors in the (numerical) software I sometimes write. The ability to follow a linked list and the flexibility of TD's breakpoints are quite useful. I'm not sure of how much of an advantage that TD would give over the TP IDE debugger, simply because of the differences between the two languages. With Turbo C, you have to use the command line compiler for a few things, like using inline assembler or isolating the assembly code that tcc produces. regards, dan Daniel R. Kuespert Chemical Process Systems Laboratory University of Maryland, College Park, MD dank@eng.umd.edu WhY ArE ``TeX'' AnD ``LaTeX'' So HaRd To TyPe?
bhan@ohs.UUCP (Bruce Hansen) (03/29/90)
From article <26942@ut-emx.UUCP>, by boerner@ut-emx.UUCP (Brendan B. Boerner): > In article <1990Mar26.174313.1976@eng.umd.edu> dank@eng.umd.edu (Daniel R. Kuespert) writes: >>Both Quick C and Turbo C's integrated debuggers are toys, >>more suitable for home use; with the Turbo C Professional package you get >>Turbo Debugger, which is a considerable improvement on the Turbo C This brings up the very dillema I have been struggling with the past couple of weeks: Is the integrated debugger "good enough"? By "good enough," I mean is it reasonbly easy to use and powerful enough for a programmer like me who is not exactly up to the "professional" level of programming and who does not know assembly anyway. Based on this, I'd tell myself to just get the regular package. BUT, there is an excellent chance that I will learn assembly in the next couple of years and that my own projects will increase in complexity to warrant a purchase of Turbo C Professional. To get to the point, the question is: How good is the integrated debugger and is it worth it to get Turbo C Professional? Assume we're operating on a finite budget here. :-) Bruce Hansen
schaut@cat9.cs.wisc.edu (Rick Schaut) (03/29/90)
In article <1990Mar26.174313.1976@eng.umd.edu> dank@eng.umd.edu (Daniel R. Kuespert) writes: | For fast code and really good optimization, MSC is the way to go. | Unless you're doing really loop-intensive types of code, though, it | may not be worth coping with all the command-line switches and | byzantine error messages MSC spews out, though. As far as speed of the resultant program is concerned, MSC 6.0 has Watcom on the run. It's impressive. However, there is one other plus for MSC. Since ver 5.0, the compiler has generated re-entrant code (i.e. code that will run in protected mode). Being able to port code from MS-DOS to OS/2 or WinNext with a minimum of hassle seems, to me at least, to be a _big_ plus. Don't get me wrong. I'm a TC user, and I like Borland's product very much. However, I'm rapidly reaching the point where I wish I had chosen MSC instead. Hell, Borland won't even support Windows. It get's a little irksome when a company with a fine product refuses to support a particular environment for political reasons. -- Rick (schaut@garfield.cs.wisc.edu) "Your degree in Economics is not necessarily an aide to finding gainfull emplyoment, but at least it helps you understand why you're unemployed"
jhallen@wpi.wpi.edu (Joseph H Allen) (03/30/90)
In article <4548@daffy.cs.wisc.edu> schaut@cat9.cs.wisc.edu (Rick Schaut) writes: >As far as speed of the resultant program is concerned, MSC 6.0 has Watcom on >the run. It's impressive. However, there is one other plus for MSC. Since >ver 5.0, the compiler has generated re-entrant code (i.e. code that will >run in protected mode). Is this for real? What about returning structures? Every compiler I know of puts returned structures in a global variable. It would make sense to just stick it on the stack, but I think this might have some portabilty consequences. Does this compiler actually do this? Or does being able to run in protected mode mean something else... (why should you need reentrant code to run in protected mode anyway?) -- "Come on Duke, lets do those crimes" - Debbie "Yeah... Yeah, lets go get sushi... and not pay" - Duke
weeks@ssbell.IMD.Sterling.COM (John Weeks) (03/30/90)
In article <529@ohs.UUCP> bhan@ohs.UUCP (Bruce Hansen) writes: >To get to the point, the question is: How good is the integrated debugger >and is it worth it to get Turbo C Professional? > >Assume we're operating on a finite budget here. :-) Aren't we all! |:-) The answers to your questions: very good and yes. The integrated debugger is very good - within its range of capabilities. I find that I can find most typos and simple logic errors, errors that are, as it were, internal to the C language and my program. When you try to trace/debug the interaction of your program with the environment, I find myself wanting a little more information, the kind you get with register displays and assembler dumps. And this is where the stand alone debugger shines. I'd say that your need fror the stand alone debugger has more to do with the kinds of code you are writing than with your current capabilities. On the other hand, the ability to *use* it depends on your capabilities and knowledge. I would note, though, that you don't have to be an assembler *programmer* to make use of the information derived from register displays, assembler dumps, etc. You do have to aquire some knowledge about notation and about e.g. intel architecture. -- John Weeks Phone: (402) 291-8300 Sterling Software FSG/IMD e-mail: uunet!ssbell!weeks 1404 Ft. Crook Rd. South e-mail: weeks@ssbell.IMD.Sterling.COM
schaut@cat9.cs.wisc.edu (Rick Schaut) (04/02/90)
In article <10378@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: | In article <4548@daffy.cs.wisc.edu> schaut@cat9.cs.wisc.edu (Rick Schaut) writes: | >As far as speed of the resultant program is concerned, MSC 6.0 has Watcom on | >the run. It's impressive. However, there is one other plus for MSC. Since | >ver 5.0, the compiler has generated re-entrant code (i.e. code that will | >run in protected mode). | | Is this for real? Well, Ver 5.0 and up will generate code for both MS-DOS and OS/2, so the result code must run under protected mode. I've also been told by people at Microsoft (including one of the lead developers for Windows) that the code generated runs under protected mode because it's re-entrant. | What about returning structures? I've never used MSC, so I don't know what it does for structures. However, I can't immagine that someone with access to the compiler would have too much difficulty finding out. -- Rick (schaut@garfield.cs.wisc.edu) "Your degree in Economics is not necessarily an aide to finding gainfull emplyoment, but at least it helps you understand why you're unemployed" --Samuel Bates
schaut@cat9.cs.wisc.edu (Rick Schaut) (04/06/90)
In article <90091.124928JEFF@psuvm.psu.edu> JEFF@psuvm.psu.edu (Jeffrey J. Nucciarone) writes: | Rumor has it TC 3.0 supports windows. Whenever I have asked the people at Borland what their plans are with respect to Windows, their answer has been that they do not plan to ever support the environment. Mere rumors don't help much here. -- Rick (schaut@garfield.cs.wisc.edu) "Your degree in Economics is not necessarily an aide to finding gainfull emplyoment, but at least it helps you understand why you're unemployed" --Samuel Bates
bcw@rti.rti.org (Bruce Wright) (04/12/90)
Sorry to write a followup on my own article, but I realized that what I wrote was not the best way of saying what I meant - I was tired and didn't realize that the words I chose could confuse some people. In my defense, I didn't invent the terminology; I was just combining terms from two different areas without considering that they are confusingly similar. In article <3757@rtifs1.UUCP>, bcw@rti.rti.org (Bruce Wright) writes: > > As far as Windows goes, there is a _big_ advantage for code that is > re-entrant, but this is an architectural quirk of Windows and is true > whether you are in protected mode or not (if a routine is not ^^^^^^^^^ > re-entrant under Windows, you often have to protect it somehow to ^^^^^^^ > prevent corruption). The first "protect" refers to the memory mapping mode of the 80286/ 80386/80486 chip family (which probably shouldn't be called protected mode - maybe "memory mapped mode" would be a more apt term, but as I said I didn't invent any of this terminology). The second "protect" refers to techniques like semaphores, which are often used to protect critical regions in a program (see any book on real-time programming or operating systems). The only connection between the two is that, unfortunately, both unrelated areas of computing use the same word "protect" to mean totally different things. Hope nobody was any more confused than I was 8-). Bruce C. Wright
Ralf.Brown@B.GP.CS.CMU.EDU (04/12/90)
In article <3760@rtifs1.UUCP>, bcw@rti.rti.org (Bruce Wright) wrote: }> As far as Windows goes, there is a _big_ advantage for code that is }> re-entrant, but this is an architectural quirk of Windows and is true }> whether you are in protected mode or not (if a routine is not } ^^^^^^^^^ } }The first "protect" refers to the memory mapping mode of the 80286/ }80386/80486 chip family (which probably shouldn't be called protected }mode - maybe "memory mapped mode" would be a more apt term, but as I }said I didn't invent any of this terminology). The second "protect" If you look at Intel's docs, you see that the "official" name is Protected Virtual Address Mode (80286 Programmer's Reference, page 1-2). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 "How to Prove It" by Dana Angluin Disclaimer? I claimed something? 21. proof by ghost reference: Nothing even remotely resembling the cited theorem appears in the reference given.