vu0112@bingvaxu.cc.binghamton.edu (Cliff Joslyn) (12/04/88)
So I have TC 2.0 and I just got 256K of EMS, and I *really* want to be able to use it during compilation and linkage in the integrated environment. Once I get the MKS shell, Sidekick, and Superkey (all of which are critical to my productivity) all loaded in, and then add in the 290K for tc.exe, I've got about 100K left for compilation and linkage. I bomb with out of memory for even very small programs. I'd run from command line, but then I lose the debugger. I find no obvious way to get the thing to link in EMS or have it swap pieces to disk during linkage. I mean, that shouldn't be a problem, right? Doesn't it run my target .exe from disk anyway? I find it necessary now to 'exec command.com' (25K vs. 73K for sh.exe) before loading tc.exe. But this can only be a temporary fix anyway, because once my target .exe grows by 50K I'm still dead. Even if I were running lean and mean without sh.exe and my TSRs, tc.exe only leaves some 300K for the user's program, with debug code. This seems to leave the integrated debugger useless for seriously large code unless TC 2.0 can use above 640K. Help!? -- O----------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large | Systems Science, SUNY Binghamton, vu0112@bingvaxu.cc.binghamton.edu V All the world is biscuit shaped. . .
schanck@dinghy.cis.ohio-state.edu (Christopher Schanck) (12/04/88)
In article <1624@bingvaxu.cc.binghamton.edu> vu0112@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: > >So I have TC 2.0 and I just got 256K of EMS, and I *really* want to be >able to use it during compilation and linkage in the integrated From what I understand, only the editor workspace can be put into EMS; other than that, you are out of luck. >some 300K for the user's program, with debug code. This seems to leave >the integrated debugger useless for seriously large code unless TC 2.0 >can use above 640K. You got it; that is the reason for the higher-priced "Professional" package with the command line debugger. The integrated environment is a real pain for large stuff. Personally, I want *my* favorite editor, so I use command line, which means I would need to buy the Professional package, which I can't afford since I am a poor grad student. Gee, remember when Borland was the company that gave you far more then you could want for $49.95? Somebody ought to tell Phillippe that integrated environments are not the be-all, end-all of programming. Turbo Pascal was a hit more because it was a quality Pascal compiler for $50 than because of the environment. In fairness, I have to point out that without a hard drive, the integrated environment is the only way to go. Chris -=- "My brain is NOT a deadlock-free environment!!!!" --- Christopher Schanck, mammal at large. schanck@flounder.cis.ohio-state.edu
vu0112@bingvaxu.cc.binghamton.edu (Cliff Joslyn) (12/05/88)
Newsgroups: comp.sys.ibm.pc Subject: Re: Turbo C 2.0 and EMS Summary: Expires: References: <1624@bingvaxu.cc.binghamton.edu> <29045@tut.cis.ohio-state.edu> Sender: Reply-To: vu0112@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (Cliff Joslyn) Followup-To: Distribution: Organization: SUNY Binghamton, NY Keywords: In article <29045@tut.cis.ohio-state.edu> schanck@dinghy.cis.ohio-state.edu (Christopher Schanck) writes: >In article <1624@bingvaxu.cc.binghamton.edu> vu0112@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: >> >>So I have TC 2.0 and I just got 256K of EMS, and I *really* want to be >>able to use it during compilation and linkage in the integrated > >From what I understand, only the editor workspace can be put into EMS; other >than that, you are out of luck. OK, I'll take that. How do I do it? >>some 300K for the user's program, with debug code. This seems to leave >>the integrated debugger useless for seriously large code unless TC 2.0 >>can use above 640K. > >You got it; that is the reason for the higher-priced "Professional" package >with the command line debugger. The integrated environment is a real pain >for large stuff. Personally, I want *my* favorite editor, so I use command >line, which means I would need to buy the Professional package, which >I can't afford since I am a poor grad student. Ditto. Are you implying that this is a marketting ploy on Borland's part? Am I correct that there are no real technical reasons why linkage in EMS is not feasible? Are they just lazy? Should I stop complaining? FOod for mailer Food for mailer Food for mailer Food for mailer Food for mailer Food for mailer Food for mailer Food for mailer Food for mailer Food for mailer -- O----------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large | Systems Science, SUNY Binghamton, vu0112@bingvaxu.cc.binghamton.edu V All the world is biscuit shaped. . .
schanck@dinghy.cis.ohio-state.edu (Christopher Schanck) (12/05/88)
In article <1628@bingvaxu.cc.binghamton.edu> vu0112@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (Cliff Joslyn) writes: >In article <29045@tut.cis.ohio-state.edu> schanck@dinghy.cis.ohio-state.edu (Christopher Schanck) writes: >>In article <1624@bingvaxu.cc.binghamton.edu> vu0112@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: >>> >>>So I have TC 2.0 and I just got 256K of EMS, and I *really* want to be >>>able to use it during compilation and linkage in the integrated >> >>From what I understand, only the editor workspace can be put into EMS; other >>than that, you are out of luck. > >OK, I'll take that. How do I do it? Got me, I got that info from the ad. "EMS support for editor". If it is not in the manual, go figure. >Ditto. Are you implying that this is a marketting ploy on Borland's >part? Am I correct that there are no real technical reasons why linkage >in EMS is not feasible? Are they just lazy? Should I stop complaining? I would assume that compilation and linking and executing would be a cast- iron bitch in EMS, but I could be wrong. I suspect they are right when they figure serious developers will want command line. Of course, what is a serious developer? I want command line mainly for my editor, with its multiple file and macro capabilites. Keep complaining, maybe someone will listen. Chris -=- "My brain is NOT a deadlock-free environment!!!!" --- Christopher Schanck, mammal at large. schanck@flounder.cis.ohio-state.edu
hardin@hpindda.HP.COM (John Hardin) (12/06/88)
>Gee, remember when Borland was the company that gave you far more then you >could want for $49.95? Somebody ought to tell Phillippe that integrated >environments are not the be-all, end-all of programming. Turbo Pascal was >a hit more because it was a quality Pascal compiler for $50 than because >of the environment. > >Chris >schanck@flounder.cis.ohio-state.edu >---------- I'd like to offer a counter opinion here. I have been programming since the sixties on lots of different machines and using lots of different languages, but when I first saw Turbo Pascal on a CP/M machine I thought it was the slickest thing I'd ever seen. The reason was entirely the integrated environment. Though I agree that its nicer if you can use a full featured editor (my favorite is Brief) when you are doing major editing, once you are into the debugging stage it's hard to beat an integrated environment. I use Turbo C 2.0 and love being able to step though my program with the integrated debugger, find a bug, fix the source, then re-compile and link without losing the breakpoints I set or the watch variables. Its a real pain when a program gets too big for this environment because of the loss of productivity aids when you have to revert to the command-line tools. I sure hope noone gives Phillipe the impression that the integrated environment doesn't help sell the Turbo language products! John Hardin hardin%hpindda@hplabs.hp.com ----------
schanck@dinghy.cis.ohio-state.edu (Christopher Schanck) (12/06/88)
In article <4330113@hpindda.HP.COM> hardin@hpindda.HP.COM (John Hardin) writes: >> [Various light Borland bashing] > >I'd like to offer a counter opinion here. I have been programming since >the sixties on lots of different machines and using lots of different >languages, but when I first saw Turbo Pascal on a CP/M machine I thought >it was the slickest thing I'd ever seen. The reason was entirely the >integrated environment. How about counter-counter-point? Look at the time frames. One, when TP first came out, PC's with hard disk were not nearly as popular. Heck, a lot of PC's had less that 640k! This has 2 effects. On a non-hard drive system, command line is loads slower than integrated because of the time required to load the compiler. This is true today; I am sure people with floppy systems are fanatic about the integrated environment and they are right; it is nearly the only way to do any serious development with a hard drive. Now as to the memory sizes being lower, this meant smaller programs were being developed. This meant fewer users were running up against the memory wall when programming. 4 of my 5 ongoing projects are to large too compile in the integrated environment! I will surely agree that ther integrated environment sold lots of copies; heck I bought one and thought it was the cat's meow, but I had 1 drive and 256k (I think...it has been awhile) at the time. But I stipulate that it was the speed of compilation offered by the environment, not the environment itself, that made TP so attractive. But the lowest common denominator of hardware has been raised; the average user can get the speed of the integrated environment without being chained to it. Don't get me wrong, at some point, I will lay out the cash for the "Professional" package; I need the debugger to much. But the regular version is pretty near equivalent to 1.5, so I'll leave it alone for now. Finally, even with all this, they are still the most useful compilers on the market. This is more of good-naturedly aggravation with a favored son than actual bashing. Smile... Chris -=- "My brain is NOT a deadlock-free environment!!!!" --- Christopher Schanck, mammal at large. schanck@flounder.cis.ohio-state.edu
funkstr@ucscb.UCSC.EDU (-=/ Larry Hastings /=-) (12/08/88)
+-In article <1628@bingvaxu.cc.binghamton.edu>, +-vu0112@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (Cliff Joslyn) wrote:- +---------- | | In article <29045@tut.cis.ohio-state.edu> schanck@dinghy.cis.ohio-state.edu (Christopher Schanck) writes: | >In article <1624@bingvaxu.cc.binghamton.edu> vu0112@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: | >> | >>So I have TC 2.0 and I just got 256K of EMS, and I *really* want to be | >>able to use it during compilation and linkage in the integrated | > | >From what I understand, only the editor workspace can be put into EMS; other | >than that, you are out of luck. | | OK, I'll take that. How do I do it? | +---------- (No reply for a few days, so I guess I will...) Run TCINST.EXE (the install/setup program). Select [O]ptions/[E]nvironment/ [O]ptions for Editor/[M]ake use of EMS memory On +---------- | | Am I correct that there are no real technical reasons why linkage | in EMS is not feasible? | +---------- Of course not. Set up a ramdisk in EMS, and tell Turbo C to do your compiling/linking there. (This would probably include changing some other stuff in TCINST, as well as perhaps just running the program there. I don't know, it isn't a problem for me... I use the MetaWare compiler :) -- /|\ /|\ .. . . . . . . . . . . | |\| |\| .. . . . . . . . . . . |/|\|/|\|/|| _ _ _ _ |_| _ _ |_ -__ _ _ARPA: funkstr@ucscb.ucsc.EDU | |/| |/|L_ (_\( ( (_/ | |(_\_) (_ || )(_)_)UUCP: *!ucbvax!ucscb!funkstr \|/ \|/ larry / hastings _/ WORK: sun!acad!metaware!funkster MetaWare Incorporated Disclaimer: It was a bad day. "If any of your OSF force are caught or killed, the Secretary will deny any knowlege of your activities." --from the new Mission: Impractical
ejablow@dasys1.UUCP (Eric Robert Jablow) (01/09/89)
Some people have complained that their programming projects are too
big for TC2.0's integrated environment. I'd like to put my own two
cents in.
Suppose you have a large project with lots of modules,
subroutines, etc. Do you always edit them all at once, or do you
write the subroutines one at a time? If the latter, then you don't
have giant projects all in memory at the same time, and you can use
the integrated environment anyway, using the following paradigm.
Say you are writing a function foo, taking two int variables and
returning a long. Test it, not by running the main program and
using all the complexity of your entire project, but by writing a
"shell" around the routine foo as that will read in test data, run foo
on said data, print out the results, and loop. That way, you get foo
to work right, and can use the integrated editor/debugger in its
development. Then you use all thepower of the command-line version to
put them all together.
The major difference, I think, between the TC integrated environment
and the QC or WATCOM C integrated environments, (and I've never
used them, so don't take my word for it) is that the others restrict
you to just one memory model, while TC doesn't; you can choose
whatever is appropriate. Thus, you can do much more of your
compilation through the screen-version, relying on the command version
for linking and putting things together. You can also experiment with
the environment of your program much more; how big would foo be if
compiled for medium model, or small, or compact,...
--
Eric Jablow {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!ejablow
New York, NY, USA
New address: jessica!eric@sbee.sbcc.edu.schanck@harmonica.cis.ohio-state.edu (Christopher Schanck) (01/12/89)
In article <8204@dasys1.UUCP> ejablow@dasys1.UUCP (Eric Robert Jablow) writes: >Some people have complained that their programming projects are too >big for TC2.0's integrated environment. I'd like to put my own two > [...suggestions on using integrated environs on big projects...] I am one of those people who has had problems with the size of the integrated environment. Several of my personal projects are just too big. Now, I understand your rational in your suggestions, but it is still to much of a sacrifice for me. For me (and this is just for me, no other claims made :-), I like as few different edit/compile/link sequences as possible; using both environments as you suggest means having two different tools to do the same thing. For me, that is in addition to what I use on the university systems. Using the IE also means using TC's editor, which is really iritating to me. It is not a bad editor, but I can't live without split-screen/multiple-file editing. Besides, I am used to my editor. The reason I like to keep things as streamlined as possible is to let me concentrate on the code. As some forgotten hacker once said "The code is the thing, man; the code is the thing!" My beef with TC is a pretty bogus one, but it is a beef nonetheless. How come you can by a version completely functional only integrated (no debugger=not functional) for cheap; or a version with both complete systems for more; but you can't by a version that is just command line, with a debugger, for cheap. I wouldn't mind not having the IE, but I would really like the debugger for the command-line!!! Oh well, I am probably in a minority here... >The major difference, I think, between the TC integrated environment >and the QC or WATCOM C integrated environments, (and I've never >used them, so don't take my word for it) is that the others restrict >you to just one memory model, while TC doesn't; you can choose PLEASE don't get get me wrong, I think TC's integrated environment is awesome, as such things go. I am just wedded to my command-line work... Aww what the heck, it was fun.. Chris -=- "My brain is NOT a deadlock-free environment!!!!" --- Christopher Schanck, mammal at large. schanck@flounder.cis.ohio-state.edu
morris@dms.UUCP (Jim Morris) (01/13/89)
From article <31050@tut.cis.ohio-state.edu>, by schanck@harmonica.cis.ohio-state.edu (Christopher Schanck): > > My beef with TC is a pretty bogus one, but it is a beef nonetheless. How come > you can by a version completely functional only integrated (no debugger=not > functional) for cheap; or a version with both complete systems for more; but > you can't by a version that is just command line, with a debugger, for cheap. > I wouldn't mind not having the IE, but I would really like the debugger for > the command-line!!! Oh well, I am probably in a minority here... > > -=- > --- Christopher Schanck, mammal at large. > schanck@flounder.cis.ohio-state.edu The stand alone debugger has FAR more functionality than the built-in one, so I would expect to pay extra for it anyway. $150 - $180 (discount price) for the standalone debugger, c compiler and assembler, (and an integrated environment, if you can use it) seems cheap to me, compared to say $300+ for MSC 5.0. In my opinion the standalone debugger is one of the best c level debuggers I have ever had the pleasure to use, and I have used MANY Emulators, debuggers and machine code monitors!! Additionally if you are lucky enough to have a 386 system with > 1MB you almost get a hardware emulator builtin. This allows you to set up global breakpoints with no slowing down of your code at all, and the code can run at the same address it would run if it were stand-alone. How they can release quality code like that for the price they do is beyond me, but my wallet and sanity thanks them. (I am not saying all their code is bug free, but what code is?? :>} ) -- Jim Morris. morris@dms.UUCP or weitek!dms!morris Atari Games Corporation, Sycamore Drive, Milpitas CA 95035. (Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer). Any opinions expressed are probably my own, and not those of Atari Games Corp.
jmoore@pc.ecn.purdue.edu (James D Moore) (01/13/89)
In article <31050@tut.cis.ohio-state.edu> Christopher Schanck <schanck@cis.ohio-state.edu> writes: >My beef with TC is a pretty bogus one, but it is a beef nonetheless. How come >you can by a version completely functional only integrated (no debugger=not >functional) for cheap; or a version with both complete systems for more; but >you can't by a version that is just command line, with a debugger, for cheap. >I wouldn't mind not having the IE, but I would really like the debugger for >the command-line!!! Oh well, I am probably in a minority here... > What do you consider cheap? The fact that you work (or are a student) for a University you can get the TC2.0 and TD1.0 software for less than it cost me to upgrade and get the debugger. Call Borland and talk to their educational sales. I beleive that the cost for TC 2.0 was $59.95 and for the TD 1.0 was also $59.95. It cost me $149 to upgrade and get my copy of the TD debugger. I did not go through the University since my copy was for personal use. The TD debugger is real nice. It is well worth the money. Jim Moore jmoore@cimlab.ecn.purdue.edu
robertb@june.cs.washington.edu (Robert Bedichek) (01/17/89)
I called Borland a few days ago to ask what serial number of TC 2.0 had
the latest bug fixes. The guy said "There are no known bugs in 2.0".
Wow. Really? I used it intensively for about a week and didn't
run into a single bug, not even in the debugger. Debuggers in my
experience are usually the buggiest tool in a development environment.
Then I read this:
"<stuff about how great TC 2.0 is deleted>
">
">(I am not saying all their code is bug free, but what code is?? :>} )
">--
">Jim Morris. morris@dms.UUCP or weitek!dms!morris
"> Atari Games Corporation, Sycamore Drive, Milpitas CA 95035.
"> (Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer).
"> Any opinions expressed are probably my own, and not those of Atari Games Corp.
So, my question: Does anyone know of any bugs in TC 2.0? The only
thing that comes close is that the if your program runs in graphics
mode and you use the debugger, the screen can get messed up if you
don't do something special. I read about this special thing in the
manual but haven't done it yet. So I don't consider this a bug
(its a limitation that they tell you about and how to work-around).
Rob Bedichek
.. "Code to live.
Live to Code."jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) (01/18/89)
In article <6957@june.cs.washington.edu> robertb@uw-june.UUCP (Robert Bedichek) writes: >So, my question: Does anyone know of any bugs in TC 2.0? The only cprintf() treats the character '\n' as a linefeed only -- it omits the carriage return. I would say that this was some sort of bizarre feature :-) except that in TC 1.5 '\n' was treated as a normal CR/LF combination. Took me a while to track the problem down when I ported a program from 1.5 to 2.0. Since I ended up having to use gotoxy(), generating a lot more code and slowing down the program, and since this is a marked departure from standard practice *and* their own previous practice, I'm going to call this one a bug. Unless somebody can give me a good reason why they did this. As for other bugs, didn't somebody report an odd bug in the stat() function a few days ago? -- James W. Birdsall jwbirdsa@phoenix.Princeton.EDU jwbirdsa@pucc.BITNET ...allegra!princeton!phoenix!jwbirdsa! Compu$erve: 71261,1731 "For it is the doom of men that they forget." -- Merlin
morris@dms.UUCP (Jim Morris) (01/18/89)
From article <6957@june.cs.washington.edu>, by robertb@june.cs.washington.edu (Robert Bedichek): > "> > ">(I am not saying all their code is bug free, but what code is?? :>} ) > ">-- > ">Jim Morris. morris@dms.UUCP or weitek!dms!morris > > So, my question: Does anyone know of any bugs in TC 2.0? The only > <etc> > Rob Bedichek > Well I have read about other bugs in TC 2.0, but I have only found a few. Off the top of my head I remember that there is a bug in the integrated debugger that will totally screw up your programs graphics output to the second page of video memory, regardless of what the debugger settings are, but works fine if you only use the first video page, and don't swap pages. I have had the TD386 stand alone debugger crash the system, or hang and need a reset, even though my code doesn't use protected mode at all. The compiler doesn't always issue an error if you use, but forget to declare a local variable. Of course the code doesn't work properly, and it is usually a bitch to find the problem as you expect the compiler to barf on an error like that!! I have not had time to report these errors to Borland as I am too busy reporting errors on the 3 or 4 other c compilers I use at work!!! The problem you mention about not refreshing the graphics screen when you re-run your program after a breakpoint or such, is not a problem. As you said there are about 2 options as to how the debugger saves the original screen, and if you choose the slowest one it saves a complete copy of the screen then repaints it. This mode leaves no rubbish on the screen, and does a genuine restore. Its just a matter of RTFM, although it takes a while to figure out what TFM is trying to tell you ( :-) ). I still think its great!! -- Jim Morris. morris@dms.UUCP or weitek!dms!morris Atari Games Corporation, Sycamore Drive, Milpitas CA 95035. (Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer). Any opinions expressed are probably my own, and not those of Atari Games Corp.
johnm@trsvax.UUCP (01/18/89)
>I called Borland a few days ago to ask what serial number of TC 2.0 had >the latest bug fixes. The guy said "There are no known bugs in 2.0". The guy on the phone is a goon (not unexpectedly). Turbo keeps a continuously updated archive on CompuServe that contains the patch program and patch files to fix all of the Turbo C, Turbo Assem (no patches posted yet), and Turbo Debugger problems as they fix them. The first version of TDCONVRT (which you wouldn't use if Turbo is your main development language, but we use heavily) was garbage. The fixed version solved a plethora of problems that we had. Get on Compu$erve and "GO BPROGB". You will find the patch files and whatnot in data libraries 5, 6 and 7 (if memory serves). I'm sorry but I don't remember what all of the problems are that the patches fix. John Munsch
diwarner@sdrc.UUCP (Mark_Warner) (01/19/89)
In article <5543@phoenix.Princeton.EDU>, jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) writes: > In article <6957@june.cs.washington.edu> robertb@uw-june.UUCP (Robert Bedichek) writes: > > cprintf() treats the character '\n' as a linefeed only -- it omits > the carriage return. I would say that this was some sort of bizarre > feature :-) except that in TC 1.5 '\n' was treated as a normal CR/LF > combination. Took me a while to track the problem down when I ported a > program from 1.5 to 2.0. > stuff deleted This is truly not a bug. I also got bitten by the change to cprintf(). I also called Borland and after I found out that the manual had the change marked in it under CPRINTF() I felt pretty dumb. Anyhow they say that it was a bug in 1.5 and that they were fixing it. If you use '\n\r' in 2.0 you get the same result as before in 1.5 with '\n'. I used this and it works okay. As for the size of code because of gotoxy() I believe it is because of the gotoxy() where x,y are for the current window and not for the whole screen. For example point 1,10 in window1 might actually translate to point 10,15 on the real screen and the function must be able to handle this and to verify that it doesn't go outside the current window. I haven't found any other problems with TC 2.0 but there was something I did find with the documentation on fgets() I think. It's one of the Xgets() functions and the doc says that it doesn't put the '\n' in the string and it does. The function still functions like it did in 1.5 but the doc is just wrong. That is if the function is correct. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Warner | UUCP: uunet!sdrc!diwarner SDRC | Milford Ohio | This space is for rent. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
adam@gpu.utcs.toronto.edu (Adam R. Iles) (01/19/89)
In article <5543@phoenix.Princeton.EDU> jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) writes: >In article <6957@june.cs.washington.edu> robertb@uw-june.UUCP (Robert Bedichek) writes: >>So, my question: Does anyone know of any bugs in TC 2.0? The only > > cprintf() treats the character '\n' as a linefeed only -- it omits >the carriage return. I would say that this was some sort of bizarre >feature :-) except that in TC 1.5 '\n' was treated as a normal CR/LF >combination. This is actually the effect of them "FIXING" a previous bug. The documentation appearantly stated that this was the action that cprintf() would take. > Since I ended up having to use gotoxy(), generating a lot more code A simpler solution would be to change the '\n' at the end of the string into a '\r' '\n' sequence. this will eliminate the need for a gotoxy() call and should speed up the code. I got this information from the latest issue of Dr. Dobbs (Jan 1989) If you want the full scoop on this "Feature" of TC 2.0 read the C Programmint column in that issue. One good feature of TC 2.0 is that now you can use 43 line mode with an ATI EGA Wonder card (this didn't work in TC 1.5.) >-- >James W. Birdsall jwbirdsa@phoenix.Princeton.EDU jwbirdsa@pucc.BITNET > ...allegra!princeton!phoenix!jwbirdsa! Compu$erve: 71261,1731 >"For it is the doom of men that they forget." -- Merlin -- Any opinions stated above may, or may not, refect those of any sane person living, dead, or just sleeping. Adam R. Iles: adam@utgpu adam@gpu.utcs.utoronto.ca
boba@hpwala.wal.hp.com (Bob Alexander) (01/19/89)
>Off the top of my head I remember that there is a bug in the integrated >debugger that will totally screw up your programs graphics output to the second >page of video memory, regardless of what the debugger settings are, but >works fine if you only use the first video page, and don't swap pages. I don't understand this. I've been working on a game that uses both graphics pages on a Hercules adapter clone, and I've had no problems with the TC debugger. Is there a certain sequence that triggers the bug that I might be missing? Bob Alexander | Nerds are people, too - I think... boba@hpwala.hp.com | -------------------+--------------------------------------------------- Organizations don't have opinions: individuals do. The opinions expressed above do not necessarily reflect those of the stockholders, employees, or directors of Hewlett-Packard.
sullivan@phyllis.math.binghamton.edu (fred sullivan) (01/19/89)
In article <5543@phoenix.Princeton.EDU> jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) writes: >In article <6957@june.cs.washington.edu> robertb@uw-june.UUCP (Robert Bedichek) writes: >>So, my question: Does anyone know of any bugs in TC 2.0? The only > > cprintf() treats the character '\n' as a linefeed only -- it omits >the carriage return. I would say that this was some sort of bizarre > Since I ended up having to use gotoxy(), generating a lot more code >and slowing down the program, and since this is a marked departure from I agree that it's annoying, but have you considered replacing \n's by \n\r's rather that using gotoxy? Fred Sullivan SUNY at Binghamton Dept. Math. Sciences Binghamton, NY 13903 sullivan@marge.math.binghamton.edu First you make a roux!
diwarner@sdrc.UUCP (Mark_Warner) (01/19/89)
In article <598@dms.UUCP>, morris@dms.UUCP (Jim Morris) writes: > From article <6957@june.cs.washington.edu>, by robertb@june.cs.washington.edu (Robert Bedichek): > stuff deleted > > The compiler doesn't always issue an error if you use, but forget to declare > a local variable. Of course the code doesn't work properly, and it is usually > a bitch to find the problem as you expect the compiler to barf on an error > like that!! > I wish that when people start FLAMING a product that they show some proof to what they are saying. I mean if you find something that you think is a bug then post it and let the net take a look also. I tried what you said above and the compiler gave me an error every time. I tried the following: main() { int i,j; i = 10; j = 11; { int k; k = 10; printf("%d %d %d\n",i,j,k); <==== i,j are consider global, k local } printf ("%d\n",k); <==== produces error (k not defined) } Please post the example that doesn't work. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Warner | UUCP: uunet!sdrc!diwarner SDRC | Milford Ohio | This space is for rent. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mdfreed@ziebmef.uucp (Mark Freedman) (01/19/89)
(known bugs in Turbo C 2.0) This isn't a bug, but I did spend some enjoyable time with Turbo Debugger verifying that fgets() works as it SHOULD, not as it's DOCUMENTED. On page 122 of the "Turbo C Reference Guide", the "Remarks" section for fgets() states "fgets does not place the newline character in the string". Aside from the questionable English, this statement contradicts every other definition of fgets which I have AND the actual behaviour of the function. Perhaps Borland has to add an "is this blatantly false" checker to the Sprint wordprocessor :-) (yes, I ***KNOW*** that "REAL" programmers determine what a function does by stepping through it with a debugger, rather than by reading the manual :-))
jmoore@pc.ecn.purdue.edu (James D Moore) (01/23/89)
In article <216100078@trsvax> johnm@trsvax.UUCP writes: > >>I called Borland a few days ago to ask what serial number of TC 2.0 had >>the latest bug fixes. The guy said "There are no known bugs in 2.0". > >The guy on the phone is a goon (not unexpectedly). Turbo keeps a continuously >updated archive on CompuServe that contains the patch program and patch files >to fix all of the Turbo C, Turbo Assem (no patches posted yet), and Turbo >Debugger problems as they fix them. > ....... more text ..... Is there any way for those or us that do not have access to compuserve to get these patches. If so where can I grab them ? If not then could some kind soul either post them or mail them to me. THANKS !! Jim Moore jmoore@cimlab.ecn.purdue.edu
morris@dms.UUCP (Jim Morris) (01/24/89)
From article <505@sdrc.UUCP>, by diwarner@sdrc.UUCP (Mark_Warner): > In article <598@dms.UUCP>, morris@dms.UUCP (Jim Morris) writes: >> From article <6957@june.cs.washington.edu>, by robertb@june.cs.washington.edu (Robert Bedichek): > >> >> The compiler doesn't always issue an error if you use, but forget to declare >> a local variable. Of course the code doesn't work properly, and it is usually >> a bitch to find the problem as you expect the compiler to barf on an error >> like that!! >> > I wish that when people start FLAMING a product that they show some proof to > what they are saying. I mean if you find something that you think is a bug > then post it and let the net take a look also. > > Please post the example that doesn't work. First I do not consider what I posted a flame! Someone asked what bugs had been noticed so I listed the ones I found. I didn't say it happened all the time. I noticed it twice, it is very hard to reproduce. Next time I see the problem I will send it to Borland, but it is probably a context sensitive bug, as are most complicated compiler bugs that I have found in other products. If you read my previous posting you will see that I am an avid supporter of TC2.0, but people should be aware of potential problems so they don't spend too long tracking down bugs in their code, when they expect the compiler to find certain errors. Now I have mentioned it people will be aware of the possibility that it could be the compiler! I'm sure that if the bug were easily reproducible it would never have gotten through Borland's quality control, they seem to have some of the best quality code, (meaning less bugs than other products) that I have seen. -- Jim Morris. morris@dms.UUCP or weitek!dms!morris Atari Games Corporation, Sycamore Drive, Milpitas CA 95035. (Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer). Any opinions expressed are probably my own, and not those of Atari Games Corp.
einari@rhi.hi.is (Einar Indridason) (01/26/89)
.In article <1166@pc.ecn.purdue.edu> jmoore@pc.ecn.purdue.edu.UUCP (James D Moore) writes:
.>>
.>>The guy on the phone is a goon (not unexpectedly). Turbo keeps a continuously
.>>updated archive on CompuServe that contains the patch program and patch files
.>>to fix all of the Turbo C, Turbo Assem (no patches posted yet), and Turbo
.>>Debugger problems as they fix them.
.>> ....... more text .....
.>
.>
.>Is there any way for those or us that do not have access to compuserve
.>to get these patches. If so where can I grab them ? If not then could
.>some kind soul either post them or mail them to me.
.>
Please mail me too ?
--
To quote Alfred E. Neuman: "What! Me worry????"
Internet: einari@rhi.hi.is
UUCP: ..!mcvax!hafro!rhi!einaripathak@s.cs.uiuc.edu (01/29/89)
How can you tell if you need the patches? I just bought my copy of Professional TC 2.0 in January. Would it not need the patches? Heeren Pathak s.cs.uiuc.edu zaphod.ncsa.uiuc.edu