bright@dataio.Data-IO.COM (Walter Bright) (01/01/70)
In article <1909@ttrdc.UUCP> kad@ttrdc.UUCP (Keith Drescher) writes: #In article <1569@killer.UUCP> richardh@killer.UUCP (Richard Hargrove) writes: ##And I'm looking forward to CODEVIEW as soon as I get it in my MASM 5.0 upgrade. ##Then I'll use it with Turbo C. #My copy of Turbo C does not provide any of the information that #codeview needs to perform symbolic debugging. OK, TurboC will put #line numbers in the object file so you can do a combined source/assembly #listing, but as far as I can tell you can't access a variable by its #symbolic name because TurboC doesn't generate that information. #Maybe QuickC will be the answer to my needs. Nobody besides Microsoft generates symbolic data for Codeview because Microsoft regards the format as proprietary and won't tell anybody. Has anybody actually gotten a copy of QuickC yet? I'm still waiting for mine...
williams@vrdxhq.UUCP (Tim Williams) (09/04/87)
I saw an add in this weeks PC Mag. for QuickC from Microsoft. It gives a list of things it has and TurboC doesn't. My question is what does MSC 5.0 have that QuickC doesn't? Tim Williams <:-0
fmayhar@killer.UUCP (Frank Mayhar) (09/06/87)
In article <4491@vrdxhq.UUCP>, williams@vrdxhq.UUCP (Tim Williams) writes: > I saw an add in this weeks PC Mag. for QuickC from Microsoft. It gives > a list of things it has and TurboC doesn't. My question is what does > MSC 5.0 have that QuickC doesn't? > Tim Williams <:-0 Not having the Microsoft product description right here (it's at work), I can't provide too many details, but the difference is bascially that Quick C is meant to be a small-scale programming environment like Turbo C (albeit with extensions). MSC 5.0, on the other hand, is a real, production-quality optimizing C compiler with a very good standard library. Quick C is meant for quick program development and debugging. MSC is meant for large programs, and for production programs. Incidentally, MSC 5.0 has some neat improvements over MSC 4.0, including a set of graphics routines in the standard library, and in-line code generation for certain commonly-used standard library functions (eliminates the procedure call overhead). It also has a little better optimization, and a few other bells and whistles that I can't remember right off-hand. -- Frank Mayhar UUCP: ..!{ihnp4,dj3b1}!killer!fmayhar ARPA: Frank-Mayhar%ladc@BCO-MULTICS.ARPA USmail: 680 Grand Ave #201 Long Beach, CA 90814 DeathStarNet: (213) 438-7899
darrylo@hpsrlc.HP.COM (Darryl Okahata) (09/09/87)
In comp.sys.ibm.pc, fmayhar@killer.UUCP (Frank Mayhar) writes: > In article <4491@vrdxhq.UUCP>, williams@vrdxhq.UUCP (Tim Williams) writes: > > I saw an add in this weeks PC Mag. for QuickC from Microsoft. It gives > > a list of things it has and TurboC doesn't. My question is what does > > MSC 5.0 have that QuickC doesn't? > > Tim Williams <:-0 > > Not having the Microsoft product description right here (it's at work), I > can't provide too many details, but the difference is bascially that Quick C > is meant to be a small-scale programming environment like Turbo C (albeit > with extensions). MSC 5.0, on the other hand, is a real, production-quality [ ... ] > > -- > Frank Mayhar UUCP: ..!{ihnp4,dj3b1}!killer!fmayhar > ARPA: Frank-Mayhar%ladc@BCO-MULTICS.ARPA > USmail: 680 Grand Ave #201 Long Beach, CA 90814 > DeathStarNet: (213) 438-7899 > ---------- I've also heard that Quick C is a MEDIUM-model ONLY compiler. YUK! -- Darryl Okahata {hplabs!hpcea!, hpfcla!} hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
kcollinsthom@watmath.UUCP (09/10/87)
In article <3320052@hpsrlc.HP.COM> darrylo@hpsrlc.HP.COM (Darryl Okahata) writes: > > I've also heard that Quick C is a MEDIUM-model ONLY compiler. YUK! > From what "I've heard" Quick C includes an integrated environment like TURBO C and a command line environment. Only the integrated environment restricts you to the Medium memory model. If it has less bugs than Turbo C it seems like it might be worth throwing out Turbo C in favour of Quick C, although Borland is supposed to bring out a new version of Turbo C *soon*.
kneller@cgl.ucsf.edu (Don Kneller) (09/11/87)
In article <3320052@hpsrlc.HP.COM> darrylo@hpsrlc.HP.COM (Darryl Okahata) writes >In comp.sys.ibm.pc, fmayhar@killer.UUCP (Frank Mayhar) writes: >> In article <4491@vrdxhq.UUCP>, williams@vrdxhq.UUCP (Tim Williams) writes: >> > ... My question is what does MSC 5.0 have that QuickC doesn't? ... >> >> ... bascially that Quick C is meant to be a small-scale programming >> environment like Turbo C (albeit with extensions). >> MSC 5.0, on the other hand, is a real, production-quality ... >> > I've also heard that Quick C is a MEDIUM-model ONLY compiler. YUK! This is somewhat true. Like Turbo, Microsoft gets much of their speed by compiling and linking from memory into memory. As such, the library must be in memory with the compiler (and editor). The library loaded with the Quick C interactive environment (editor/compiler/linker in one) is a medium model. Hence you are restricted to medium model programs from this environment. It is possible to use the Quick C compiler from the command line with the QCL driver, which is much like the CL driver currently used by MSC 4.0. Then it is possible to use any model you wish. However, you lose the interactive environment. I'm not really sure why it wouldn't have been possible to have separate libraries that would load with the Quick C environment. Clearly the compiler part of Quick C can handle the other models. Personally, I have no desire to use a WordStar-like editor, which the QC editor is designed after. For "one-off" programs that require little work I have used the QC environment and it is fast! For more serious programming, I use QCL for relatively quick compilation and MSC 5.0 for production work. BRIEF will remain my editor (it can automatically position itself at compiler errors, among other neat features). ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller INTERNET: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
broehl@watdcsu.UUCP (09/11/87)
In article <14563@watmath.waterloo.edu> kcollinsthom@watmath.waterloo.edu (Kevyn Collins-Thompson) writes: >In article <3320052@hpsrlc.HP.COM> darrylo@hpsrlc.HP.COM (Darryl Okahata) writes: >> >> I've also heard that Quick C is a MEDIUM-model ONLY compiler. YUK! >> >If it has less bugs than Turbo C it seems like it might be worth >throwing out Turbo C in favour of Quick C It's *very* unlikely that Quick C will be less buggy than Turbo; Turbo has what, maybe four known bugs? Compare that to some of the stuff Microsoft has put out, and I'll stick with Borland. (I forget how many known bugs were in a recent Microsoft Fortran release, but it was a *three-digit* number!)
todd@uhccux.UUCP (The Perplexed Wiz) (09/11/87)
I'm still waiting for my Microsoft C 5.0 and QuickC update to arrive.
Can anyone tell me if the QuickC editor handles brace matching?
The lack of that feature in Turbo C's editor irritates me to no end.
--
Todd Ogasawara, U. of Hawaii Center for Teaching Excellence
UUCP: {ihnp4,uunet,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd
ARPA: uhccux!todd@nosc.MIL
INTERNET: todd@uhccux.UHCC.HAWAII.EDUrichardh@killer.UUCP (Richard Hargrove) (09/16/87)
In article <3826@watdcsu.waterloo.edu>, broehl@watdcsu.waterloo.edu (Bernie Roehl) writes: > In article <14563@watmath.waterloo.edu> kcollinsthom@watmath.waterloo.edu (Kevyn Collins-Thompson) writes: > >In article <3320052@hpsrlc.HP.COM> darrylo@hpsrlc.HP.COM (Darryl Okahata) writes: > >> > >> I've also heard that Quick C is a MEDIUM-model ONLY compiler. YUK! > >> > >If it has less bugs than Turbo C it seems like it might be worth > >throwing out Turbo C in favour of Quick C > > It's *very* unlikely that Quick C will be less buggy than Turbo; Turbo > has what, maybe four known bugs? Compare that to some of the stuff > Microsoft has put out, and I'll stick with Borland. I'll stick with Borland also. They've gotten a bad rap for the bugs in Turbo C 1.0 (how many bugs were in MASM 1.0 or MS C 2.0?). Though, I have no idea when a new release is coming from Borland, I suspect they are going to make sure it is well debugged. A short story about compiler bugs: at work (Texas Instruments) we are purchasing an Ada compiler targeted for the 1750A. It costs somewhere between $1000 and $100000 (I don't know how much - I just know it's the high-priced spread). I say purchasing it because: Guess what ? It's got bugs! Amazing! Our software people are working very closely with Tartan to find and fix them. These programs are horrendously complex, involving literally thousands of trade-offs, engineering decisions, and judgement calls. There will be bugs! Live with them, work araound them, and wait for the next release. Oh yes, bitch like hell to the vendor. That's the only way you stand a chance of having them fixed. But don't throw out a fine product because it has a few bugs! Note that it's the middle of September and we're still wondering what Quick C and MS C v5.0 are going to be like. Borland really turned up the heat on Microsoft back in May. Given Microsoft's history of buggy products (we use MS Pascal at work, v3.something or other; we still have modules that we must compile with optimization turned off or otherwise we get bad code generated) combined with the pressure of releasing something in September, we have the potential for a real buggy set of products. Borland has been very responsive to bug reports. We've gotten nothing but grief from Microsoft. Like I said, I'll stick with Borland. regards, richard hargrove ...!ihnp4!killer!richardh -------------------------
peter@aucs.UUCP (09/17/87)
in article <1535@killer.UUCP>, richardh@killer.UUCP (Richard Hargrove) says: > > I'll stick with Borland also. They've gotten a bad rap for the bugs in > Turbo C 1.0 (how many bugs were in MASM 1.0 or MS C 2.0?). Though, I have no > idea when a new release is coming from Borland, I suspect they are going > to make sure it is well debugged. > > regards, > richard hargrove > ...!ihnp4!killer!richardh > ------------------------- I am currently working on a 8000 line Turbo C application and have experienced only one obscure bug with memchr (which I solved by writing my own version). The whole thing's been developed under the integrated environment without any difficulty whatsoever, and I have both superkey and sidekick installed. I am definitely going to stick with Borland... Peter Steele Acadia Univ. Wolfville, N.S. Canada B0P 1X0 (902)542-2201x121 <<{uunet|watmath|utai|garfield}dalcs!aucs!Peter.BITNET>> <<Peter@Acadia.UUCP>>
aja@i.cc.purdue.edu (Mike Rowan) (09/17/87)
> I'll stick with Borland also. They've gotten a bad rap for the bugs in > Turbo C 1.0 (how many bugs were in MASM 1.0 or MS C 2.0?). Though, I have no > idea when a new release is coming from Borland, I suspect they are going > to make sure it is well debugged. > although more expensive, ill say one word. **CODEVIEW**
null@bsu-cs.UUCP (09/18/87)
In article <2347@i.cc.purdue.edu>, aja@i.cc.purdue.edu (Mike Rowan) writes: > > I'll stick with Borland also. They've gotten a bad rap for the bugs in > > Turbo C 1.0 (how many bugs were in MASM 1.0 or MS C 2.0?). Though, I have no > > idea when a new release is coming from Borland, I suspect they are going > > to make sure it is well debugged. > > > although more expensive, ill say one word. > > **CODEVIEW** I'll add another.... **BIG DEAL** -- ---- Patrick Bennett UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!null
kneller@cgl.ucsf.edu.UUCP (09/18/87)
References: In article <1155@bsu-cs.UUCP> you write: >In article <2347@i.cc.purdue.edu>, aja@i.cc.purdue.edu (Mike Rowan) writes: >> > I'll stick with Borland also. >> >> although more expensive, ill say one word. >> >> **CODEVIEW** > > I'll add another.... > >**BIG DEAL** I find CodeView invaluable for finding some bugs, provided you can get the program compiled with CodeView information in and that it fits in memory. Microsoft has introduced 2 enhancements toward this end: 1) a utility to pack exe files to take up less room in CodeView (not exepack, but something like it) 2) the use of expanded memory to store some CodeView information in memory above 1Meg. QuickC contains a subset of CodeView so you can single step, set break- and trace-points, examine variables. One thing not yet mentioned is that QuickC allows bounds checking on arrays so you can trap array over/underruns. This is a continual gotcha that Pascal programmers gloat about. I have no experience with TurboC. I do have with QuickC and MSC 5.0. ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller INTERNET: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
mac@idacrd.UUCP (Bob McGwier) (09/18/87)
in article <1155@bsu-cs.UUCP>, null@bsu-cs.UUCP (Patrick Bennett) says: > > In article <2347@i.cc.purdue.edu>, aja@i.cc.purdue.edu (Mike Rowan) writes: >> > I'll stick with Borland also. They've gotten a bad rap for the bugs in >> > Turbo C 1.0 (how many bugs were in MASM 1.0 or MS C 2.0?). Though, I have no >> > idea when a new release is coming from Borland, I suspect they are going >> > to make sure it is well debugged. >> > >> although more expensive, ill say one word. >> >> **CODEVIEW** > > I'll add another.... > > **BIG DEAL** > Patrick Bennett Either you have never used CODEVIEW or you have never written a big piece of code. IT IS <<THE>> reason I use MicroSoft C 4.0 and will use 5.0 I also cannot believe the gripes about a bug here or there in a compiler that costs under a hundred dollars, heck even a bug or two in those that cost less than a thousand dollars. PC users have gotten INCREDIBLY spoiled by cheap Taiwan clones and refusing to buy compilers that cost half as much as there computer. Step back and take the LONG view and look at what your company pays for a compiler that is full of bugs for its mainframes and you guys are complaining about compilers that cost peanuts. Bob
aja@i.cc.purdue.edu (Mike Rowan) (09/18/87)
In article <1155@bsu-cs.UUCP>, null@bsu-cs.UUCP (Patrick Bennett) writes: > > although more expensive, ill say one word. > > > > **CODEVIEW** > > I'll add another.... > > **BIG DEAL** > it blows anything borland has for debugging away. didnt i hear that msc 5.0 is gonna come with QuickC?? What is cool about tc is i use it for syntax checking and can shoot src through msc when im done. With tc and msc being so compatable you can have the best of both worlds. mike (aja@i.cc.purdue.edu)
richardh@killer.UUCP (09/19/87)
In article <2347@i.cc.purdue.edu>, aja@i.cc.purdue.edu (Mike Rowan) writes: > > I'll stick with Borland also. They've gotten a bad rap for the bugs in > > Turbo C 1.0 (how many bugs were in MASM 1.0 or MS C 2.0?). Though, I have no > > idea when a new release is coming from Borland, I suspect they are going > > to make sure it is well debugged. > > > although more expensive, ill say one word. > > **CODEVIEW** And I'm looking forward to CODEVIEW as soon as I get it in my MASM 5.0 upgrade. Then I'll use it with Turbo C. regards, richard hargrove ...!ihnp4!killer!richardh -------------------------
jbs@eddie.MIT.EDU (Jeff Siegal) (09/19/87)
In article <2357@i.cc.purdue.edu> aja@i.cc.purdue.edu (Mike Rowan) writes: > didnt i hear that msc 5.0 is gonna come with QuickC?? Yes, and if you purchased MSC 4.0 after July 1, 1987, you will get MSC 5.0 (including QuickC) at no extra charge. Be sure to get your user-registration card in, though. Jeff Siegal
peter@aucs.UUCP (Peter Steele) (09/21/87)
in article <287@idacrd.UUCP>, mac@idacrd.UUCP (Bob McGwier) says: > > Either you have never used CODEVIEW or you have never written a big > piece of code. IT IS <<THE>> reason I use MicroSoft C 4.0 and will use > 5.0 > I'm not sure what constitutes a large project, but I had been working on a 5000 line MSC 4.0 project when my Turbo C arrived. I had *never* used Codeview while I was using MSC and never felt a need to do so. So, switching to Turbo C caused no sense of loss. In fact, I much prefer developing under Turbo C; its faster, the integrated environment is great, and the code produced is better (at least the EXE file for my application is smaller using TC than MSC). My application is now 8000 lines and growing. I agree with your comments about the bugs people are griping about. Micro users have it pretty good compared to mainframe users when it comes to software prices. When I find a bug in some package I'm using, I try to find some work around and if I can I'm satisfied. I'm just glad there is at least one company (Borland) who's willing to sell software at prices that people can afford to buy. Peter Steele Acadia Univ. Wolfville NS Canada B0P1X0 (902)542-2201x121 {uunet|watmath|utai|garfield}dalcs!aucs!Peter.BITNET Peter@Acadia.UUCP
todd@uhccux.UUCP (The Perplexed Wiz) (09/21/87)
I got a note from Microsoft last week saying that the delivery date
for Microsoft C 5.0 has been pushed back to October. Does anyone know
if QuickC's delivery date has been pushed back also? I'm getting my
QuickC with my v 5.0 update, so I won't see either one until next
month (assuming the delivery date doesn't get pushed back again).
...todd
--
Todd Ogasawara, U. of Hawaii Faculty Development Program
UUCP: {ihnp4,uunet,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd
ARPA: uhccux!todd@nosc.MIL
INTERNET: todd@uhccux.UHCC.HAWAII.EDUkad@ttrdc.UUCP (09/22/87)
In article <1569@killer.UUCP> richardh@killer.UUCP (Richard Hargrove) writes: > >And I'm looking forward to CODEVIEW as soon as I get it in my MASM 5.0 upgrade. >Then I'll use it with Turbo C. How? My copy of Turbo C does not provide any of the information that codeview needs to perform symbolic debugging. OK, TurboC will put line numbers in the object file so you can do a combined source/assembly listing, but as far as I can tell you can't access a variable by its symbolic name because TurboC doesn't generate that information. I hope that Borland does update their compiler eventually so that it places the CodeView information in the .obj file. I like TurboC for the speed of compilation, and I like CodeView's debugging abilities. I just don't like waiting around for MSC to compile a program. Maybe QuickC will be the answer to my needs. -- Keith Drescher (kad@ttrdc) | ... You can check out any AT&T | time you like - but you can Computer Systems Division, Skokie, Il. | never leave ... PATH: ...!ihnp4!ttrdc!kad | - Hotel California
dalegass@dalcsug.UUCP (09/24/87)
In article <1373@dataio.Data-IO.COM>, bright@dataio.Data-IO.COM (Walter Bright) writes: > In article <1909@ttrdc.UUCP> kad@ttrdc.UUCP (Keith Drescher) writes: > #In article <1569@killer.UUCP> richardh@killer.UUCP (Richard Hargrove) writes: > #My copy of Turbo C does not provide any of the information that > #codeview needs to perform symbolic debugging. OK, TurboC will put > #line numbers in the object file so you can do a combined source/assembly > #listing, but as far as I can tell you can't access a variable by its > #symbolic name because TurboC doesn't generate that information. > > Nobody besides Microsoft generates symbolic data for Codeview because > Microsoft regards the format as proprietary and won't tell anybody. > This is not entirely true. I use Codeview and Turbo C together regularly. If you generate a MAP file with Turbo C, and convert that to a SYM file (using MAPSYM), Codeview will allow references to global variables... Unfortunately, local variables (on the stack) can not be referenced. I'm still waiting for TCDEBUG: Judging from TDEBUG, this could be a very useful and powerful product. dalegass@dalcsug.uucp