kent@ncoast.UUCP (02/20/87)
s/*** REPLACE THIS LINE WITH YOUR MESSAGE ***/YOUR MESSAGE/g A number of people have posted inquiries about Borland's Turbo C. The following is an editorial of sorts, along with some biased and unsolicited opinions of MS-DOS C compilers. I am associated with NONE of the companies discussed. My opinion is : don't bother with Turbo C. There are other products out there that must be just or good (or better), and by all indications, Borland's Turbo C will share all of the drawbacks of the other Borland Products, to wit: 1. Non-standard (in troubling and non-trivial ways) implementations. Borland says that Turbo C will adhere to ANSI Standard C, but don't expect it to be any closer than Microsoft C 4.0. My bet is that it will be as close to ANSI C as Turbo Pascal is to ISO Pascal. Is this a fatal flaw? Depends on your point of view. It is definitely fatal in a professional, production environment. 2. A lack of a batch mode for compiles. Ever try to run Turbo Prolog from make? 3. Bugs. I found several in Turbo Prolog, just screwing around for a day or so (V1.0). Borland was nice enough to send me 1.1 unsolicited, but I haven't verified that the bugs are gone. Why go with a new, untested product when there are mature products around? I have been working for three years with C compilers daily, and have the following two-bit reviews to offer: 1. MSC 4.0. Love codeview (but it has annoying bugs!), love the extensive library. Code generation good to excellent. I haven't found any library bugs myself, but supposedly if malloc fails, it will sometimes clobber DS. ROM support sucks - regardless of the source they give you to startup. 2. Aztec C86 - good to excellent code generation. Occasionally you will still hit ugly code generation bugs in large models. Excellent ROM support. Nice package of development tools, (make diff vi clone etc), but there are them
shaffer@operations.dccs.upenn.edu (Earl Shaffer) (07/08/87)
PEOPLE!!! - Hey, am I the only one who is angry that my 1.0 software is buggy! Worse than that, *I* have to fix it! I have not heard any of you saying ".. I cant believe this.." I called Borland and said "what are you going to do about your bug problem" and they said ".. we will mail you patch information". This means I have to sit down with DEBUG and fix *THEIR* error! Yes, I do not like this! This does not say much for their company, their customer service policies, not to mention their QA procedures. I have to teach a C course using this product. My first lesson is going to have to be "lets patch the buggy software". ============================================================================== Earl Shaffer - University of Pennsylvania - Data Communications Department "Time was invented so that everything wouldn't happen at once." Steven Wright ==============================================================================
kbrown@irs1.UUCP (07/09/87)
In article <1439@super.upenn.edu.upenn.edu> shaffer@operations.dccs.upenn.edu.UUCP (Earl Shaffer) writes: >PEOPLE!!! - Hey, am I the only one who is angry that my 1.0 >software is buggy! Worse than that, *I* have to fix it! > >I have not heard any of you saying ".. I cant believe this.." >I called Borland and said "what are you going to do about your >bug problem" and they said ".. we will mail you patch information". > > I am probably going to get flamed for this but I think this is typical of the way Borland operates. First they pre-announced the product as vaporware (and began taking orders!!) several months before the product was ready. I was at a show a week or so after Turbo C was announced, the Borland people didn't even have a copy, beta or otherwise, of the software yet. Some time after that I saw a rather lame excuse that they were giving people who had already placed orders as to why it was taking so long to ship th product. And now that they are finally shipping it is buggy. I am sure that they knew that Microsoft was going to ship QuickC in September and pushed an unfinished product out the door to beat Microsoft. Anyone want to take bets on how many patches Microsoft will have to distribute in the first month after QuickC is shipped? Does anyone know what the latest count from Borland is? As of a couple of days ago I have 1 through 9. ken brown kbrown@irs1
bagpiper@csvax.caltech.EDU (07/15/87)
People keep mentioning stuff about TurboC bugs and their fixes. From
what I gather, the DTM of the file(s) change but not the version number(1.0).
We have a version of TurboC that we are thinking of using on a project. If
anybody could post (I think this is of general interest) the DTM's of each
new mini-minor version, it would be a help. At the least I would be interested
in the DTM of the most current copy of TurboC that Borland is shipping.
Thanks
Michael Hunter UUCP : ....{seismo, rutgers, ames}!cit-vax!oxy!bagpiper
Box 241 ARPA : oxy!bagpiper@csvax.caltech.edu
Occidental College BITNET: oxy!bagpiper@hamlet.bitnet
Los Angeles, CA 90041 CSNET : oxy!bagpiper%csvax.caltech.edu@relay.cs.netephram@violet.berkeley.edu (07/17/87)
In article <8293@brl-adm.ARPA> oxy!bagpiper@csvax.caltech.EDU (Michael Paul Hunter) writes: >People keep mentioning stuff about TurboC bugs and their fixes. From >what I gather, the DTM of the file(s) change but not the version number(1.0). >We have a version of TurboC that we are thinking of using on a project. If >anybody could post (I think this is of general interest) the DTM's of each >new mini-minor version, it would be a help. At the least I would be interested >in the DTM of the most current copy of TurboC that Borland is shipping. > > Thanks > >Michael Hunter UUCP : ....{seismo, rutgers, ames}!cit-vax!oxy!bagpiper >Box 241 ARPA : oxy!bagpiper@csvax.caltech.edu >Occidental College BITNET: oxy!bagpiper@hamlet.bitnet >Los Angeles, CA 90041 CSNET : oxy!bagpiper%csvax.caltech.edu@relay.cs.net The date of the latest version that I have is 6-3-87 1:00a. I got it from the borland folk as an update because I couldn't apply the patches (I forgot to rename my exe file to anything != exe so debug applied offsets to relocatable ...). The original version was one of the earlier versions I purchased it in the 1st few days from a company that drove down to borland the day it was shipped and got a truckload. I did a file compare with the version I already had and found out that aside the 3 patches I have division of constants, -G and structure push floating point patch) the files compared exactly the same. I really must say that the people at borland are willing to help and have a satisfactory resolution alternitive to "You will have to wait for version X.1.2.3.2.1.5". ephram@violet.berkeley.edu
steve@ondine.uucp (Steve Jenkins) (07/22/87)
In article <4376@jade.BERKELEY.EDU> ephram@violet.berkeley.edu () writes: >[...] I did a file compare with >the version I already had and found out that aside the 3 patches I have >division of constants, -G and structure push floating point patch) the >files compared exactly the same. > There is also another bug of which Borland is aware, unfixed as of now. Fortunately, it's easy to work around. Formal parameters of type float are not adjusted to double in function definitions without function prototypes. The obvious workaround is to use prototypes, or declare the parameters double. ----------------------------------- Steve Jenkins UCLA Dept of Anesthesiology ucla-an!steve@EE.UCLA.EDU
frisk@askja.UUCP (Fridrik Skulason) (08/04/87)
I have heard that Borland does not change the version number of the
Turbo C compiler when fixing bugs.
Now - the good thing about this is that you don't have to wait for months
for the fixes, but unfortunately it's hard to know just which bugs have
been fixed in "your" version.
Since I have never seen a list of the various versions, I am going to
create one.
So - those of you using Turbo C, and having a few spare minutes how
about mailing the following information to me:
TC creation date [on the original disk please, not your HD copy]
TC size
Known fixes in this version
The resulting list will probably appear a few days after the replies stop
arriving......
--
Fridrik Skulason Univ. of Iceland, Computing Center
UUCP ...mcvax!hafro!askja!frisk BIX frisk
"This line intentionally left blank"wjones@andromeda.rutgers.edu (Wendell E Jones) (03/31/88)
I am wondering is there anyway that I can get turbo C to do a fork().
I looked all over for something to tell me if it does but I am at a
lost. Please E-mail me the reply.
Thanks in advance,
*********************************************************
* W.E.Jones A.K.A. The Ronin *
* U.S.Mail 91 Ackerson St. Hackensack New Jersey 07601 *
* Nan ja desu karma ka? Karma desu karma. Neh? *
* DISLAMER : I DON'T DO SPELLING!!! SO DON'T REMIND ME.*
*********************************************************C08922DB%WUVMD.BITNET@cunyvm.cuny.edu (Don Branson) (07/21/88)
I am interested in understanding the structure of the function type "interrupt" in Turbo C. Basically, what is special about this function definition, and what approaches can be used in other compilers to simulate this feature? Optimum-C is what I'm using. Thanks in advance, Thank you. Don Branson C08922DB@WUVMD.BITNET
brb@akgua.ATT.COM (Brian R. Bainter) (07/21/88)
From article <16577@brl-adm.ARPA>, by C08922DB%WUVMD.BITNET@cunyvm.cuny.edu: > > I am interested in understanding the structure of the function type > "interrupt" in Turbo C. Basically, what is special about this function > definition, and what approaches can be used in other compilers to simulate > this feature? Optimum-C is what I'm using. > > Thanks in advance, > > Thank you. > Don Branson > C08922DB@WUVMD.BITNET I am not entirely sure, because I haven't worked with it before, but according to my reading I believe that the biggest speciality of this type of function is that it does a return from interrupt instead of just a normal return from subroutine. I think that it may also save off all of the registers before entering the routine, and then restores them just before the return. If after I get home and find out that this is not correct by consulting the manual, I will post another article to clarify if someone has not already done so. -- Brian R. Bainter AT&T Technologies Atlanta Works {cbosgd, gatech, ihnp4, moss, mtune, ulysses}akgua!brb
jfh@rpp386.UUCP (John F. Haugh II) (07/22/88)
In article <16577@brl-adm.ARPA> C08922DB%WUVMD.BITNET@cunyvm.cuny.edu writes: >I am interested in understanding the structure of the function type >"interrupt" in Turbo C. Basically, what is special about this function >definition, and what approaches can be used in other compilers to simulate >this feature? Optimum-C is what I'm using. it declares the function as being called at interrupt time. this means that the function can have no stray side effects, such as not restoring a modified register, and that the function must be ended with a return from exception rather than a short or long return from subroutine call. - john. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
driscoll@eecae.UUCP (Mike Driscoll) (07/22/88)
in article <16577@brl-adm.ARPA>, C08922DB%WUVMD.BITNET@cunyvm.cuny.edu says: > > > I am interested in understanding the structure of the function type > "interrupt" in Turbo C. Basically, what is special about this function > definition, and what approaches can be used in other compilers to simulate > this feature? Optimum-C is what I'm using. > > Thanks in advance, > > Thank you. > Don Branson > C08922DB@WUVMD.BITNET In TurboC, a function declared to be of type interrupt has three major differences: 1. All registers are pushed onto the stack on entry and popped from the stack on exit. 2. The DS register is set to point to the DGROUP of the program. 3. The function returns with an return from interrupt instruction (IRET) instead of a normal return (RET). Note that pushing the registers on the stack makes them available to the function as if they were function parameters. They may be changed and the changed values will be placed in the registers on return. If your compiler allows inline assembly language, you can probably insert the neccesary instructions in any function that should be interrupt. You need to know how to access the address of the DGROUP segment. You might also be able to compile to assembly language and insert the needed assembly code in the file and then assemble that to get an executable. Mike -- Michael A. Driscoll UUCP: ...ihnp4!msudoc!eecae!driscoll Dept. of Electrical Engineering ARPA: driscoll@eecae.ee.msu.edu (35.8.8.151) Michigan State University Office: (517) 353-5337 E. Lansing, MI, 48824
grimlok@hubcap.UUCP (Mike Percy) (07/22/88)
From article <4244@rpp386.UUCP>, by jfh@rpp386.UUCP (John F. Haugh II): > In article <16577@brl-adm.ARPA> C08922DB%WUVMD.BITNET@cunyvm.cuny.edu writes: >>I am interested in understanding the structure of the function type >>"interrupt" in Turbo C. Basically, what is special about this function >>definition, and what approaches can be used in other compilers to simulate >>this feature? Optimum-C is what I'm using. Well, how about this (file = int.c) void interrupt test() { } then I do a tcc -S on it and get name int int_text segment byte public 'code' dgroup group _data,_bss assume cs:int_text,ds:dgroup int_text ends _data segment word public 'data' _d@ label byte _data ends _bss segment word public 'bss' _b@ label byte _bss ends int_text segment byte public 'code' ; Line 2 _test proc far push ax push bx push cx push dx push es push ds push si push di push bp mov bp,dgroup mov ds,bp ; Line 3 @1: pop bp pop di pop si pop ds pop es pop dx pop cx pop bx pop ax iret _test endp int_text ends _data segment word public 'data' _s@ label byte _data ends int_text public _test int_text ends end Oh yeah, that was with all other options default (small MM, etc.)
dennett@usage.csd.unsw.oz.au (Dennett Jaques) (08/04/90)
G'day there,
I am having a small problem with some functions in Turbo C 2.01 relating
to 'gets' and 'scanf' when in graphics mode.
The program runs fine on EGA VGA displays but the same code when run on
Hercules equipped machines causes small lines of scattered pixels to be
displayed across the top half of the screen at the point where 'scanf' or
'gets' are called. Additional pixels appear as keyboard input is processed
by these functions. No characters are echoed to the screen at this time
although they should be, EGA and VGA OK here.
On the other hand if I program using 'getch' in place of the above - this
works for all types of graphics cards.
But this method is too sloppy.
The above code first uses 'InitGraph' to determin display hardware.
Anybody have any thoughts?
Cheers.
Dennett Jaques.
_________________________________________________________________
,-_|\ Network Analyst E-mail: dennett@usage.csd.unsw.edu.au
/ \ The University of N.S.W Phone: +61 2 697-2324
\_,-._* <- Sydney, AUSTRALIA FAX: +61 2 662-8665
v _________________________________________________________________
When I want my employers opinion,
I'll give it to them.