Turbo C vs Quick C
Ric Messier
had even decided on which one to get. The price was just right and so
was the name when all of a sudden, I hear about this other compiler for
the same price and also from a well-respected name. Here's my dilemna:
I can pick up both Microsoft's Quick C and Borland's Turbo C for $53/ea but
I am not sure which is the better compiler. I have asked everyone I know
but they all give me the runaround without answering the really
important questions. Therefore, I am going to ask the experts, hopefully
those of you that have used either or both. I am currently using Turbo
Pascal and I like it well enough, mainly because I have recently
discovered a comprehensive reference manual that covers everything from
inline assembler code to DOS and BIOS interrupt calls within the code,
to graphics to version 4 and all the toolboxes to ... Well, you get the
picture. But I want to get a C package that is at least as good because,
all though the work I am currently doing is in Pascal, I have never been
partial to the language.
Anyway, to the point. I want to know what kind of package each of them
is, what kind of graphics capabilities, support of the Kernighan/Ritchie
C, other C compilers they are compatible with, how much low level access
there is, etc. I have asked the companies themselves for the infomation,
but I doubt that I will be getting any of it soon, if at all. The other
thing I want to know is what kind of editor comes with the latest
release of Turbo C. I am kind of partial to pulldown menus which are
included in the Quick C package and I don't particularly enjoy going to
the Turbo editor sometimes, though I realize that I can change the
commands to whatever suits me, there are just some things I want to do
that it can't.
Whatever information anyone can provide me with would be greatly
appreciated.
--
- Kilroy
'Just what cowpatch is Lyndonville, Vermont in anyway?'
dartvax!lscvax!ram
*** Can't deal, &CRASH
Bill Wilson
Educators can pick up Turbo C for $39.95 directly from
Borland. Most of the articles I have read indicate that
Turbo C is superior to Quick C. On our campus here we have also
had Quick C blow away hard drives, so be careful.
Bill Wilson
Peter J. Holsberg
|
|Educators can pick up Turbo C for $39.95 directly from
|Borland.
I just got my coupons and found that the new price is $44.95. Still better
than mail order at ~ $65. Incidentally, essentially ALL of BORLAND's
products are available at a discount to educators and educatees. (I said
"essentially" because I'm C-ing my A! :-))
--
Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh
Technology Division CompuServe: 70240,334
Mercer College GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800
mark
GODDAM !!! I also had quick C blow away my drive. It wrote
all over the FAT table. The program was as simple as you can
get :
fp = fopen(.. some file ..)
fclose(fp);
Fortunately, I had another copy of the FAT table and was
able to recover after only 4 hours of panic.
mark
homxb!mr
Kumar_Swaminath...@xerox.com
c., based on following 3 points:
1. "Quick"/"Turbo" means one thing: No serious optimization. At least with
quick C, It is compatible with ms's "real" C compiler. So i can use qc to
develop,and build the program with reg. c compiler for production.
2. Turbo C has no debugger, while qc does.
3.qc is from Microsoft, and for whatever it's worth it is a big name company,
as for as future considerations (With other compilers from MS).
Finally, ofcourse it depends on the application that u want to develop with
either of compilers.. If u can buy each of 'em for about 60 bucks, why not buy
both of them, and evaluate yourself ?.
William Phillips
> had Quick C blow away hard drives, so be careful.
I know of a case where MSC (4.0 I think) utterly scrambled a hard drive
(not backed up, natch), when a module compiled with one memory model was
linked with modules compiled with a different model. I've forgotten the
exact details, but I saw what was left of the directories after the
program was run -- total garbage. So watch out for that one!
--
William Phillips {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!wfp
New York, NY, USA (-: Just say "NO" to OS/2! :-)
John Robinson
In article <11...@brl-adm.ARPA>, Kumar_Swaminath...@Xerox.COM writes:
> All things considered as for as capabilities (lack of them), I recommend quick
> c., based on following 3 points:
>
> 1. "Quick"/"Turbo" means one thing: No serious optimization. At least with
> quick C, It is compatible with ms's "real" C compiler. So i can use qc to
> develop,and build the program with reg. c compiler for production.
>
Be that as it may, the postings I have seen indicate very little difference
in execution time between TurboC and MSC 5.0.
> 2. Turbo C has no debugger, while qc does.
This is true. My experience with Microsoft languages included
Microsoft Fortran v 4.0. This includes CodeVeiw which is a very
nice debugger. However, I prefer to use debuggers to find errors
in MY programs, not THEIR compiler!
Also, Borland has announced a debugger to TurboC in the 'first
quarter of 88'. Till then the one posted on compuserve will do
fine. So, for that matter, will Codeview which comes with
MASM 5.0.
>
> 3.qc is from Microsoft, and for whatever it's worth it is a big name company,
> as for as future considerations (With other compilers from MS).
I guess you failed to notice that Borland has shipped over 500,000
copies of Turbo Pascal. Also, they shipped over 30,000 copies of
TurboC in the first WEEK. They now claim over 100,000 copies. I'm
sure that Borland is heartbroken, given this, that you don't consider
them a 'big name company' :-).
>
> Finally, ofcourse it depends on the application that u want to develop with
> either of compilers.. If u can buy each of 'em for about 60 bucks, why not buy
> both of them, and evaluate yourself ?.
This is very good advice even if the English is a little weak!
Dick Flanagan
>In article <29...@dasys1.UUCP> w...@dasys1.UUCP (William Phillips) writes:
>>In article <5...@naucse.UUCP>, w...@naucse.UUCP (Bill Wilson) writes:
>>> Turbo C is superior to Quick C. On our campus here we have also
>>> had Quick C blow away hard drives, so be careful.
>>
>>I know of a case where MSC (4.0 I think) utterly scrambled a hard drive
>>(not backed up, natch), when a module compiled with one memory model was
>>linked with modules compiled with a different model.
>
>If you break the rules and link large model with small model, who knows
>what is going to happen? . . .
>
>The only solution is to stick to small models or get some memory protection
^^^^
An alternative solution is to simply be careful and not break the rules.
DOS has always been very unforgiving in this area (it's as much a victim
of the Intel architecture as we are), and blaming any compiler because it
"lets" us screw up is a bit tacky. (Flame != Tim)
Dick
--
Dick Flanagan, W6OLD GEnie: FLANAGAN
UUCP: ...!ucbvax!ucscc!slvblc!dick Voice: +1 408 336 3481
INTERNET: slvblc!di...@ucscc.UCSC.EDU LORAN: N037 05.5 W122 05.2
USPO: PO Box 155, Ben Lomond, CA 95005
Timothy L. Kay
>> Turbo C is superior to Quick C. On our campus here we have also
>> had Quick C blow away hard drives, so be careful.
>
>I know of a case where MSC (4.0 I think) utterly scrambled a hard drive
>(not backed up, natch), when a module compiled with one memory model was
>linked with modules compiled with a different model. I've forgotten the
This can happen with *any* C compiler that uses the large model. Once
you allow the compiler to generate code that messes with the segment
registers, you open yourself up for much more destructive bugs. If you
break the rules and link large model with small model, who knows what
is going to happen? Suppose the result is that your bug scribbles all
over low memory, exactly where some sectors from the FAT happens to
be. Then the program bombs. Your next disk write will scribble in
random places on the disk because the in-core copy of the FAT sectors
has been clobbered.
The only solution is to stick to small models or get some memory protection
ala Unix/386.
Tim
James R Vallino
>(not backed up, natch), when a module compiled with one memory model was
>linked with modules compiled with a different model. I've forgotten the
>exact details, but I saw what was left of the directories after the
>program was run -- total garbage. So watch out for that one!
>
To be somewhat fair to Microsoft, especially since the "exact details"
were forgotten, this type of thing can easily occur with ANY C program
which uses large data, that is segment:offset pointers. You can get it
to happen even when you link the correct library. The problem is with
the hardware and operating system (or in this case the programmer) not
the compiler. A program running under MS-DOS can get to any memory location
in the 1 MByte memory space in which MS-DOS runs. This includes overwriting
critical sections of the operating system, such as the file allocation
table (FAT). Once this is trashed and a program does another write to disk
then you better hope that the Gods are on your side.
The situation which seemed to cause this most frequently was inexperienced C
programmers writing code which ended up using pointers which were NULL. These
then read from low memory and got garbage other data which ended up trashing
the FAT. My boss was not pleased when it was his system that got trashed the
first time this problem surfaced. So if you want to blame a compiler then
blame ALL the C compilers for not providing an option to check for use of
NULL pointers at runtime. (The MSC V5.0 compiler is the first C compiler I
have ever worked with which does have this option.)
--
Jim Vallino Siemens Research and Technology Lab.,Princeton, NJ
CSNET: j...@siemens.siemens-rtl.com
UUCP: {ihnp4,philabs,seismo}!princeton!siemens!jrv
Kumar_Swaminath...@xerox.com
Quick C and Turbo C. This is what i think of his response :
In article <11...@brl-adm.ARPA>, Kumar_Swaminath...@Xerox.COM
writes:
> All things considered as for as capabilities (lack of them), I recommend
quick
> c., based on following 3 points:
>
> 1. "Quick"/"Turbo" means one thing: No serious optimization. At least with
> quick C, It is compatible with ms's "real" C compiler. So i can use qc to
> develop,and build the program with reg. c compiler for production.
>
Be that as it may, the postings I have seen indicate very little difference
in execution time between TurboC and MSC 5.0.
>>Quote from PC Mag. (Vol 6 #16 Sep '87) : "Microsoft C compiler ties or beats
Turbo C on most numeric, screen write and file operations." Mr.Robinson sys
that the posting that he had seen indicates very little difference in
execution time. My point here is that with MSC you get more optimization. I'm
sure whatever (john's)source that did that comparison must have used a
ridiculously simple benchmark like sieve. One can only compare the degree of
optimization by running the test on programs that can be optimized.
> 2. Turbo C has no debugger, while qc does.
This is true. My experience with Microsoft languages included
Microsoft Fortran v 4.0. This includes CodeVeiw which is a very
nice debugger. However, I prefer to use debuggers to find errors
in MY programs, not THEIR compiler!
Also, Borland has announced a debugger to TurboC in the 'first
quarter of 88'. Till then the one posted on compuserve will do
fine. So, for that matter, will Codeview which comes with
MASM 5.0.
>>This is exactly the point i was trying to make in the next item (#3 ). With
MicroSoft (The "big" name company),
i get the OS, compiler, linker AND the debugger from one company. So when john
or I have a problem with any of them we call one company for help. With TC you
get the compiler from one company and the debugger from who knows where?. So,
who the hell do you call when you have problems debugging in TC?.
> 3.qc is from Microsoft, and for whatever it's worth it is a big name company,
> as for as future considerations (With other compilers from MS).
I guess you failed to notice that Borland has shipped over 500,000
copies of Turbo Pascal. Also, they shipped over 30,000 copies of
TurboC in the first WEEK. They now claim over 100,000 copies. I'm
sure that Borland is heartbroken, given this, that you don't consider
them a 'big name company' :-).
>>If only john will pay more attention to what he reads. Does anyone see
anything that i have written that says Borland is NOT a "big name company"?. I
was comparing compilers from two different companies, and i made a statement to
the effect that Microsoft is a "bigger name company". See the point that i made
above. Moreover don't throw those numbers at me. Don't u (short for 'you',
in case someone didn't have enough brain to understand this in my last mail)
know that almost every PC in the world that runs DOS gets that OS from MS?
> Finally, ofcourse it depends on the application that u want to develop with
> either of compilers.. If u can buy each of 'em for about 60 bucks, why not buy
> both of them, and evaluate yourself ?.
This is very good advice even if the English is a little weak!
>> While I thank Mr. Robinson knowing that I can now go to him whenever I have
any problems with my English, I cannot but feel that if john had pursued his
career in English instead of programming, he would have made it, ... probably.
Ian Phillipps
> I've finally talked myself into picking up a C compiler and thought I
>
> I can pick up both Microsoft's Quick C and Borland's Turbo C for $53/ea but
> I am not sure which is the better compiler. I have asked everyone I know
I've used Turbo 1.0 and MSC 4.0.
The latter got squeezed off my disk a while back.
The Turbo editor is limited as an editor, but does have remap - you could
tart it up if need be with a keyboard remap program.
> inline assembler code to DOS and BIOS interrupt calls within the code,
access, if you like that sort of thing.
>
> Anyway, to the point. I want to know what kind of package each of them
> is, what kind of graphics capabilities, support of the Kernighan/Ritchie
as I haven't read the draft ANSI standard, I dont know if declarations like
main( int argc, char **argv ) { /* hello world */ }
are in it - Borland takes them, MSC doesn't. MSC 5.0 "totally compatible
with Quick C" barfs on #pragma - guess how I found that out!
There are irritating differences with the header files (memory.h vs mem.h)
but not much serious unless you use the Turbo extensions in non-macro form.
(If you use inp or outp, Turbo will do them in-line via macros).
> release of Turbo C. I am kind of partial to pulldown menus which are
> included in the Quick C package and I don't particularly enjoy going to
> the Turbo editor sometimes, though I realize that I can change the
> commands to whatever suits me, there are just some things I want to do
> that it can't.
There are lots of graphics in Turbo V 1.5 - I haven't got that yet.
... all views purely personal ...
--
UUCP: ...!ukc!camcon!igp | Cambridge Consultants Ltd | Ian Phillipps
or: i...@camcon.uucp | Science Park, Milton Road |-----------------
Phone: +44 223 358855 | Cambridge CB4 4DW, England |
Dave Levenson
> ...So if you want to blame a compiler then
> blame ALL the C compilers for not providing an option to check for use of
> NULL pointers at runtime. (The MSC V5.0 compiler is the first C compiler I
> have ever worked with which does have this option.)
MS-C release 3.0 and 4.0 also check for NULL pointer references at
runtime. They do this by loading a 16-byte constant (actually,
their copyright notice) into the first sixteen bytes of the data
segment. This is checked against another copy before and after the
execution of your program. If they don't compare, the runtime
package displays the nessage "NULL POINTER REFERENCE" as your
program exits. If you also managed to munge the operating system,
however, this check probably won't save you!
--
Dave Levenson
Westmark, Inc. A node for news.
Warren, NJ USA
{rutgers | clyde | mtune | ihnp4}!westmark!dave
Russ Nelson
>MS-C release 3.0 and 4.0 also check for NULL pointer references at
>segment. If they don't compare, the runtime package displays the
>message "NULL POINTER REFERENCE" as your program exits.
Turbo C does this also. Perhaps what the original poster meant was that
MS-C 5.0 checks *every* pointer use for the null pointer.
--
-russ
AT&T: (315)268-6591 BITNET: NELSON@CLUTX Internet: nel...@clutx.clarkson.edu
GEnie: BH01 Compu$erve: 70441,205
Peter Knoppers
Why, oh why don't the .obj files in MSDOS contain some bits telling
the linker whether a function in the .obj file expects to be called
with a FAR or a NEAR call. This can prevent accidentally linking
modules compiled for different models.
--
Peter Knoppers, Delft Univ. of Technology
...!mcvax!dutrun!dutesta!knop
or
kn...@dutesta.UUCP
Walter Bright
<runtime. They do this by loading a 16-byte constant (actually,
<their copyright notice) into the first sixteen bytes of the data
<segment. This is checked against another copy before and after the
<execution of your program. If they don't compare, the runtime
<package displays the nessage "NULL POINTER REFERENCE" as your
<program exits. If you also managed to munge the operating system,
<however, this check probably won't save you!
This, of course, only works for NEAR pointers. Most of my programs use
FAR pointers (the default for C and L and H models). Assigning to
a far pointer with a NULL or small value results in stomping on the 8088's
interrupt vector table, necessitating a power off reset. This is nearly
always why the Ctrl-Alt-Del fails, it's because the keyboard interrupt
vector is gone!
P.S. I'll never understand why Intel didn't put the vector table at
FFF00, it would haved saved hundreds of programmers lots of grief.
Barnacle Wes
> In article <5...@naucse.UUCP>, w...@naucse.UUCP (Bill Wilson) writes:
> > Turbo C is superior to Quick C.
At filling my garbage can, yes. I took a program that I wrote on Unix
(MicroPort System V/AT if it makes any difference to you) and ported
it to the Atari ST using Mark Williams C. I kermitted over the data
file, the program ran fine - the same as Unix. Then I ported the
program to MS-DOS using Turbo C. I kermitted over the data file, the
output was meaningless garbage. I #defined the debugging code to find
out what was happening to the data buffers (no Turbo Debugger, of
course). The debugging code did not work the way it did under Unix
either. I got mad and pitched TC into the garbage (from across the
room, accompanied by great noises). I bought Quick C. I compiled
the code without the debugging defines. It ran just like Unix.
Hmmm... If it runs on iAPX286 'pcc', MWC on the 68000, and on Quick
C on 286, what's wrong with Turbo?
> > On our campus here we have also
> > had Quick C blow away hard drives, so be careful.
>
> I know of a case where MSC (4.0 I think) utterly scrambled a hard drive
Yah, Microsoft said something about MSC 5.0 blowing away hard disks on
PCs and XTs using Western Digital WX2 series disk controllers. I
guess Microsoft beta-testers don't stoop to using mere 8088's any
more.... (I can't blame them, I wouldn't either).
--
/\ - "Against Stupidity, - {backbones}!
/\/\ . /\ - The Gods Themselves - utah-cs!utah-gr!
/ \/ \/\/ \ - Contend in Vain." - uplherc!sp7040!
/ U i n T e c h \ - Schiller - obie!wes
Patrick McCarthy
In article 7731 of comp.lang.c kn...@dutesta.UUCP (Peter Knoppers) writes:
> Why, oh why don't the .obj files in MSDOS contain some bits telling
> the linker whether a function in the .obj file expects to be called
> with a FAR or a NEAR call. This can prevent accidentally linking
> modules compiled for different models.
Fortunately, most of the time this will result in fixup overflow errors
at link time. Using make is an excellent way to avoid this problem
altogether (though many consider it a major pain for single module
programs).
Pat McCarthy
Reply: mcca...@well.UUCP
terry
>
> Why, oh why don't the .obj files in MSDOS contain some bits telling
> the linker whether a function in the .obj file expects to be called
> with a FAR or a NEAR call. This can prevent accidentally linking
> modules compiled for different models.
Because there is no way to set up a function such that if you call
it 'NEAR' at such-and-such an address, you can still call it 'FAR' at a prior
address. The push's end up in the wrong order for near and far calls. There
was a very good column on this in 'The Devil's advocate', a column carried by
several magazines, I think, and written by Stan Kelly Bootle (sp?). I think
that fact that his Porshe liscence plate is 'MC68000' has nothing to do with
this dim view.
Of course, the linker COULD do this, IF it were to generate code, but
linkers are not supposed to have to do that (if you can call what MSC uses
a linker :-( ). Barring generation of appropriate code by the linker, which
would have to include translation of some previous code generated by the
compiler, such as _calls_ ;-), external refs, and so forth, as well as segment
crossing code requiring different instructions in large model, you can't do
it. Even if you did, you 'small model' code would be using JMP's and so forth
with 16 bit addressing, rather than the 8 normally needed in small model.
You should get a 'error: mixed code models' anyway, if you are using
a *real* compiler and linker...
terry@wsccs
John Unekis
>In article <10...@dutesta.UUCP>, kn...@dutesta.UUCP (Peter Knoppers) writes:
>>
>> Why, oh why don't the .obj files in MSDOS contain some bits telling
>> the linker whether a function in the .obj file expects to be called
>> with a FAR or a NEAR call. This can prevent accidentally linking
>> modules compiled for different models.
The problem is not with the linker, but with the compiler. The code
which performs a subroutine call is generated at compile time, and it
either pushes the segment registers on the stack (FAR call) with the
offset registers, or it simply pushes the offset registers alone (NEAR
call). The problem with labelling entry points for the linker is that
an entry point may be NEAR when placed in the same segment with the
calling code by the linker, or FAR when it has to be placed in a
separate segment due to code size. Therefore a lot of large model FAR
subroutine calls are redundant because the code actually fits in one
segment (but there are no guarantees).
If all this gets too frustrating for words, you could always buy a
computer with a real processor chip(like the 68000) that doesn't have
20 year old START-OF-THE-ART problems like segment boundaries.
=========================================================================
My opinions are so good that my employer would like to own them,
but they remain mine alone. {ihnp4 or voder}!wlbr!etn-rad!jru
=========================================================================
Jerry Fountain
In article <3...@wsccs.UUCP> te...@wsccs.UUCP (terry) writes:
>>
>> Why, oh why don't the .obj files in MSDOS contain some bits telling
>> the linker whether a function in the .obj file expects to be called
>> with a FAR or a NEAR call. This can prevent accidentally linking
>> modules compiled for different models.
>
>
>
Digging around in the .obj file I did run across an interesting item. MSC
*does* include a flag in the .obj to indicate the model for which the file
was generated. The bad part is that only placed in the .obj for Xenix
compatibility.
(from MS-DOS encyclopedia, pg. 659)
COMENT record (0x88), comment class 0x9D
Hope this clears up this minor point...The info is there, LINK just ignores it.
--
-----Jerry Fountain-----
UUCP: {hplabs!hp-sdd,sdcsvax,nosc}!crash!pnet01!gof ARPA: crash!g...@nosc.mil
MAIL: 523 Glen Oaks Dr., Alpine, Calif. 92001 INET: g...@pnet01.CTS.COM
William Phillips
>a *real* compiler and linker...
Precisely.
--
William Phillips {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!wfp
New York, NY, USA !!! JUST SAY "NO" TO OS/2 !!!