mlord@bwdls58.bnr.ca (Mark Lord) (03/29/91)
So far, I have used BC++ for about three hours. In that time, I have noticed that the environment is MUCH more stable than TC++ 1.00/1.01.. *no* crashes of any kind. I have yet to try the WINDOWS3 stuff, though. HOWEVER.. the following two bugs may be of general interest. I will likely call Borland about them after the Easter weekend. 1) The <conio.h> routines are slightly broken. When outputing a "\r\n" sequence using either putch() or cputs(), these routines no longer perform an implicit clreol() to clean the rest of the line before advancing. This broke my port of LESS.. very obvious, as the screen just filled up with identical "garbage" at the end of all short lines of output. My interim work-a-round is to simply perform a clreol() immediately before outputing "\r\n". 2) The GREP.COM program *still* does not know how to display its permanent option settings correctly. Try doing GREP -o -u and then GREP ? to see what I mean. This bug has been there from TC++ 1.00 onwards. To fix it in BC++ 2.00, apply the following patch to GREP.COM (note also that even though the GREP.COM is not identical to previous releases, it still has the same version number, 3.0. haha!): For the GREP.COM that comes with BC++ 2.00, At offset $1A83, the values: 8C 19 A9 19 BD should be changed to: A9 19 BD 19 8C For the older version of this from TC++ 1.00, At offset $1A89, the values: 92 19 AF 19 C3 should be changed to: AF 19 C3 19 92 Enjoy. --- MLORD@BNR.CA Ottawa, Ontario *** Personal views only *** begin 644 NOTSHARE.COM ; Free MS-DOS utility - use instead of SHARE.EXE MZQ.0@/P/=`J`_!9T!2[_+H``L/_/+HX&+`"T2<TAO@,!OX0`N1(`C,B.P/.DS <^K@A-<TAB1Z``(P&@@"ZA`"X(27-(?NZE@#-)P#-5 `` end
resnicks@netcom.COM (Steve Resnick) (03/30/91)
In article <6286@bwdls58.bnr.ca> mlord@bwdls58.bnr.ca (Mark Lord) writes: > >So far, I have used BC++ for about three hours. >In that time, I have noticed that the environment is MUCH >more stable than TC++ 1.00/1.01.. *no* crashes of any kind. >I have yet to try the WINDOWS3 stuff, though. > >HOWEVER.. the following two bugs may be of general interest. >I will likely call Borland about them after the Easter weekend. > > > 1) The <conio.h> routines are slightly broken. > When outputing a "\r\n" sequence using either putch() > or cputs(), these routines no longer perform an implicit > clreol() to clean the rest of the line before advancing. > This broke my port of LESS.. very obvious, as the screen > just filled up with identical "garbage" at the end of all > short lines of output. > > My interim work-a-round is to simply perform a clreol() > immediately before outputing "\r\n". > Turbo C 2.0's cputs never did this. I have never tried TC++ so I can't tell you. Personally, I would expect it NOT to do a clreol() unless explicitly called. One "bug" (feature?) I found in the conio stuff is with cgets. In TC Version 2.0 (Why the hell didn they name it Borland C++ 2.0?) cgets called DOS function 0x0A to get it's input. From there you could set buffer[0] = 254 and get 254 characters back. Now, they get the characters using getch. They do a signed comparison on the first byte in the buffer passed. The net result is that you can only read in 127 byte strings. (Argh!) A call to borland cleared this up for me, and basicly told me I need to write a cgets which worked like the TC 2.0 version... - Steve -- ------------------------------------------------------------------------------- resnicks@netcom.com, steve@camphq, IFNA: 1:143/105.0, USNail: 530 Lawrence Expressway, Suite 374 Sunnyvale, Ca 94086 - In real life: Steve Resnick. Flames, grammar and spelling errors >/dev/null 0x2b |~ 0x2b, THAT is the question. The Asylum OS/2 BBS - (408)263-8017 12/2400,8,1 - Running Maximus CBCS 1.2 -------------------------------------------------------------------------------