davel@booboo.SanDiego.NCR.COM (David Lord) (04/06/91)
Is there someplace on the net where people are discussing Borland C++?
We don't seem to receive comp.windows.ms.programmer here, something I
hope to have corrected. I am crossposting this there anyway since it
seems like the appropriate place. Overall I like the compiler and the IDE alot
except that I don't really want to learn a new text editor so I use Windows
to go back and forth between BC++ and Elvis.
I do have a number of complaints which I intend to call Borland about but
I'm wondering if other people are having the same problems (or not having
them).
1) Linking even a minimal Windows program on my 386SX takes twenty minutes.
Using Hyperdisk in Staged Write mode will cut the time down to about five.
2) Using the debugger TDW causes my mouse cursor to vanish in Windows. The
result is that I have to exit Windows everytime I finish with the
debugger. Anyone know a way around this? I'm running Windows in 386
enhanced mode, my mouse is a three button Qtronix Mighty Cat, unusual
perhaps but I've never had a problem with any other program. I load
the mouse driver as MOUSE.SYS in my CONFIG.SYS.
I have now found a rather kludgy way around it, I wrote a windows
program which calls ShowCursor(1). After exiting the debugger I
run this program and it gives me my cursor back.
3) The Menu Editor (Whitewater Resources Toolkit) is all but unusable.
If I add or delete a menu item, any existing items with the 'grayed'
attribute still say 'grayed' but don't get treated as grayed. I have
to remove the 'grayed' attribute from each one and then put it back.
Also I have had the system crash in this program just from clicking
on the scroll after deleting menu items. The rest of the WRT seems
to work adequately although the Dialog Box Editor doesn't always
behave the way I think it should.
Oh, one other bit of information for anyone thinking of buying BC++ to
write Windows applications, expect to pay another $40 for Microsoft's
Windows Programmer Reference. Also, if you're upgrading from TC++ expect
to shell out for Peltzold's (sp?) book on Windows programming (I hear that
you get this free if you are buying BC++ outright rather than as an upgrade.)
I've also read that Borland is sending the Windows Help compiler to
registered owners of BC++. If so they don't seem to be in a big hurry
about it.
If I seem to be making a lot of complaints, I should say that I'd still
take this product over Microsoft "C" any day.
--
Dave.Lord@SanDiego.NCR.COM
Opinions expressed are my own and usually contrary to those of my employer.dwebster@cs.arizona.edu (Dave E. Webster, Jr.) (04/07/91)
I called about the BC++ 2.0 windows help compiler and they verified
that it was in and shipping. Unfortunately, however, it appears that
you may have to call their customer service desk to get your copy.
I was told by the service rep that they should be shipped automatically,
but .... Anyway, if you don't mind the cost of the phone call, the
phone number is 1-408-438-5300. It is an electronic forwarding system,
so press '2', then '2' to get an actual service rep (this saves having
to wait 30 seconds for the condescending electronic explanation of how
to use the D*MNED thing!)
While speaking with the tech reps about a bug I had come across (turns
out that everyone else has as well, apparently), they told me that there
is now an RBBS setup which contains BC++ patches and info, rather than
using COMPUSERVE's GO BORLAND directory. I was told that I could go ahead
and post the number for all to see and (ab)use:
BORLAND's BBS: 1-408-439-9096
Best wishes from the land of sunshine,
Dave.mlord@bwdls58.bnr.ca (Mark Lord) (04/09/91)
In article <1991Apr5.171426.28904@SanDiego.NCR.COM> davel@booboo.SanDiego.NCR.COM (David Lord) writes:
<... Overall I like the compiler and the IDE a lot
<except that I don't really want to learn a new text editor so I use Windows
<to go back and forth between BC++ and Elvis.
I put Elvis onto the Transfer menu, and also assigned a Hotkey to it.
This way, I just hit F2 and bingo.. my favorite PC editor fires up on
the source I was looking at, *at the line I was looking at*!
<I do have a number of complaints which I intend to call Borland about but
<I'm wondering if other people are having the same problems (or not having
You can send bug reports to bugs@borland.com
although they don't guarantee confirmation.
There is also a file with two official patches already on Simtel/wuarchive:
pd1:<msdos.turbo-c>bc20p1.zip
<1) Linking even a minimal Windows program on my 386SX takes twenty minutes.
< Using Hyperdisk in Staged Write mode will cut the time down to about five.
This is *much* faster outside of Windows on my 386SX. One idea is to either
close all of your ELVIS windows first, or assign 100% of CPU to the foreground.
ELVIS is a real CPU hog, using a polling loop to read the keyboard. Perhaps
TAME could be of help here.
<2) Using the debugger TDW causes my mouse cursor to vanish in Windows. The
< result is that I have to exit Windows everytime I finish with the
Somebody else has also noticed this bug.
< I have now found a rather kludgy way around it, I wrote a windows
< program which calls ShowCursor(1). After exiting the debugger I
< run this program and it gives me my cursor back.
Post it!!
<If I seem to be making a lot of complaints, I should say that I'd still
<take this product over Microsoft "C" any day.
Ditto.
--
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
``
endmlord@bwdls58.bnr.ca (Mark Lord) (04/09/91)
In article <> mlord@bwdls58.bnr.ca (Mark Lord) writes: <In article <> davel@booboo.SanDiego.NCR.COM (David Lord) writes: ..and, *no*, we are not (directly, at least) related to once another! -- 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
jerry@polygen.uucp (Jerry Shekhel) (04/10/91)
davel@booboo.SanDiego.NCR.COM (David Lord) writes: > >1) Linking even a minimal Windows program on my 386SX takes twenty minutes. > Using Hyperdisk in Staged Write mode will cut the time down to about five. > From the description of your setup, I suspect that you're running Windows in 386-Enhanced Mode, and running BC.EXE in a DOS box. Now look at the size of BC.EXE -- it is a huge program with overlays and such. When you make it spawn the linker, no wonder it takes so long to link. Use the Borland-suggested method. Install TKERNEL and run Windows in Standard Mode, open a DOS session and run BCX.EXE. Your compiles and links will fly. You will, however have a longer wait when switching to another DOS session (for your editor). I have a question about pre-compiled headers. This feature is a miracle, but it seems like a new header image (.SYM) needs to be created during the MAKE process whenever a file is compiled which includes a set of headers which is different from the current .SYM image. In other words, the project maintains only one .SYM image. So if your project contains two files, each including a different set of headers, turning on the pre-compiled header option doesn't save you any time. Is there a way around this, so that the project can handle multiple .SYM files (disk space is not a problem)? > >Dave.Lord@SanDiego.NCR.COM > -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
ar12@prism.gatech.EDU (REGISTER,ANDREW H) (04/10/91)
What is ELVIS?
A mail reply may be appropriate here.
--
Andy Register Internet: ar12@prism.gatech.edu Bitnet: aregiste@gtri01.bitnet
-- Sometimes the Bears Win, Sometimes the Bulls Win --
-------- But the Pigs *Always* Lose -------- (author unknown)sidney@borland.com (Sidney Markowitz) (04/10/91)
Note: at the end of this article is *free* source for a workaround to the disappearing mouse cursor *and* SVGA screen noise problems of TDW. In article <6427@bwdls58.bnr.ca> mlord@bwdls58.bnr.ca (Mark Lord) writes: >In article <1991Apr5.171426.28904@SanDiego.NCR.COM> davel@booboo.SanDiego.NCR.COM (David Lord) writes: ><1) Linking even a minimal Windows program on my 386SX takes twenty minutes. >< Using Hyperdisk in Staged Write mode will cut the time down to about five. > >This is *much* faster outside of Windows on my 386SX. One idea is to either >close all of your ELVIS windows first, or assign 100% of CPU to the foreground. The fastest link times are using the protected mode linker, which you get from BCX or TLINKX (but not BCCX!), which means running under DOS or standard mode Windows. If you are really set on running under enhanced mode, set up the pif for BC with 1.5 Mb of EMS, no XMS and lock the EMS memory. That last detail is what will bring up the speed, because without it, Windows may simulate the EMS on the swap disk. The interaction between TLINK's handling of symbols, the pattern of symbol usage in the Windows API interface lib and the RTL, and the way Windows swaps simulated EMS leads to really awful performance when you let the EMS swap during a link of a Windows app. Any fix I've thought of would degrade performance under all other conditions, so I'm afraid there will be no cure for that before we have a DPMI version. (No, I won't say when :-) ) ><2) Using the debugger TDW causes my mouse cursor to vanish in Windows. The >< result is that I have to exit Windows everytime I finish with the > >Somebody else has also noticed this bug. > >< I have now found a rather kludgy way around it, I wrote a windows >< program which calls ShowCursor(1). After exiting the debugger I >< run this program and it gives me my cursor back. > >Post it!! A little-known fact: The disappearing mouse cursor problem in TDW seems to happen only when you start TDW using a launch or shell program other than Program Manager. The difference seems to be that ProgMan uses LoadModule while other programs use WinExec to launch an app. Here is an unofficial (not tested by Borland QA) program that will bring back the mouse and also restore the screen after it has been messed up by TDW. I use it to make TDW practical to use with my SVGA driver. I attach this program to a hot key, a capability of the launch program I use, so even if the screen is totally trashed I can run it. (The launch program is a beta version of a shareware product a friend wrote, so I can't post it yet). It is a little more sophisticated than calling ShowCursor(1), because if the mouse is already visible it will not mess up the display counter by incrementing it anyway. The screen is restored via a call to the undocumented Windows API function RepaintScreen, that was found by experiment to do the right thing here. I'm working on a version that can be loaded in win.ini and will run automatically after TDW exits, and hope to make that an official workaround release, but until then, some people may find this useful. At least it's cheaper than the $10 shareware one I saw on cica. Feel free to post this or pass this around to whoever needs it: -------------- cut here --------------------------------------------- /* If the mouse cursor is not visible, make it visible, otherwise leave it at the same display level it was at. Then repaint the entire desktop using an undocumented Windows call. build using bcc -WS kleen.c rc kleen.exe */ #include <windows.h> void FAR PASCAL RepaintScreen (); #pragma warn-pro int PASCAL WinMain() { int crs; for ( crs = ShowCursor(0); crs < 0; crs= ShowCursor(1)); RepaintScreen(); return 0; } -------------- cut here --------------------------------------------- -- sidney markowitz <sidney@borland.com>
davel@booboo.SanDiego.NCR.COM (David Lord) (04/11/91)
davel@booboo.SanDiego.NCR.COM (David Lord) (that's me!) writes: >1) Linking even a minimal Windows program on my 386SX takes twenty minutes. > Using Hyperdisk in Staged Write mode will cut the time down to about five. I've gotten about a zillion suggestions on how to make this go faster, many of which I haven't had a chance to try yet. First thing I found was that adding a permanent swap file and switching from SMARTDRIVE to HYPERDISK gave a moderate speed improvement. Running HYPERDISK in STAGED WRITE mode gave an even bigger improvement. I gather from what other people have said that this merely causes my swapping to be memory-to-memory rather than memory-to-disk. Other suggestions I have received: 1) Compile outside of Windows. Not really practical most of the time, didn't seem to make much difference anyway. 2) Same as 1) but use a memory manager. I'm running QEMM 5.1. System has 4 meg. One meg. is allocated to HYPERDISK. 3) Run BCX (protected mode compiler). This means running Windows in REAL mode. Sounds awful, but I'll try. Actually I thought I had tried this at one point, but I don't remember just what I was doing at the time. Since BC shows: "175k memory remaining" the whole time I'm linking I didn't think swapping was the problem. 4) Run BC in Windows using a pif file with 1.5 meg of EMS memory LOCKED. When I start BC as an Aporia Tool it starts up in the directory I'm currently working in (the one the Tree Tool is pointed at). When I tried to use a pif this didn't happen anymore, which is a real pain. Anyone know a way around this? Oh, and I've heard that the problem I have with the mouse cursor dissapearing doesn't happen if you are using Windows' Program Manager. Unfortunately hell hasn't frozen over yet so I'm going to to keep using Aporia. In article <1038@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes: >I have a question about pre-compiled headers. This feature is a miracle, >but it seems like a new header image (.SYM) needs to be created during the MAKE >process whenever a file is compiled which includes a set of headers which is >different from the current .SYM image. In other words, the project maintains >only one .SYM image. So if your project contains two files, each including >a different set of headers, turning on the pre-compiled header option doesn't >save you any time. Is there a way around this, so that the project can >handle multiple .SYM files (disk space is not a problem)? Use the same headers in each module :-). Actually I think only the first few have to be the same.
davel@booboo.SanDiego.NCR.COM (David Lord) (04/12/91)
In article <1991Apr11.162855.10164@SanDiego.NCR.COM> davel@booboo.SanDiego.NCR.COM (David Lord) writes: >davel@booboo.SanDiego.NCR.COM (David Lord) (that's me!) writes: > >>1) Linking even a minimal Windows program on my 386SX takes twenty minutes. >> Using Hyperdisk in Staged Write mode will cut the time down to about five. To all those people who kept telling me to run the compiler in protected mode: you were right. The program I'm working on took 8 minutes to link in normal mode, 4 minutes with Hyperdisk in staged write mode, and 6 SECONDS when I run the compiler in protected mode, and that's running under Windows. Color me astounded. I would kind of like to know where all that extra time is going in normal mode. Thanks for the help. Dave Lord
curt@cctb.wa.com (Curt Johnson) (04/13/91)
In article <1991Apr11.162855.10164@SanDiego.NCR.COM> davel@booboo.SanDiego.NCR.COM (David Lord) writes: | davel@booboo.SanDiego.NCR.COM (David Lord) (that's me!) writes: | | >1) Linking even a minimal Windows program on my 386SX takes twenty minutes. | > Using Hyperdisk in Staged Write mode will cut the time down to about five. | | I've gotten about a zillion suggestions on how to make this go faster... | | Other suggestions I have received: | ... | 3) Run BCX (protected mode compiler). | | This means running Windows in REAL mode... ^^^^ RT*M. Load TKERNEL (see the manual for the proper parameters) Load Windows in STANDARD mode (win /s) Run BCX This is very fast on my computer (386/33, 8M ram) Curt Johnson == curt@cctb.wa.com
jamshid@ut-emx.uucp (Jamshid Afshar) (04/13/91)
In article <1991Apr11.162855.10164@SanDiego.NCR.COM> davel@booboo.SanDiego.NCR.COM (David Lord) writes: >davel@booboo.SanDiego.NCR.COM (David Lord) (that's me!) writes: > >>1) Linking even a minimal Windows program on my 386SX takes twenty minutes. >> Using Hyperdisk in Staged Write mode will cut the time down to about five. Solution: >3) Run BCX (protected mode compiler). > > This means running Windows in REAL mode. Sounds awful, but I'll... BZZT! Wrong, but thanks for playing. (Oh, sorry, I thought this was comp.lang.c) To run BCX (the _protected_ mode compiler), you must run windows in _protected_ mode (win /s). I wouldn't use Windows in real mode. RTM (_User's Guide_, p.4) about running BC++ in protected mode. >In article <1038@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes: > >>I have a question about pre-compiled headers. This feature is a miracle, >>but it seems like a new header image (.SYM) needs to be created during the >>MAKE process whenever a file is compiled which includes a set of headers >>which is different from the current .SYM image. ...(stuff deleted)... > >Use the same headers in each module :-). Actually I think only the first few >have to be the same. The one .SYM file keeps the data for _all_ previously compiled modules. You know when BC++ uses a pre-compiled header because the compiler spits out a message. See Appendix A in the _User's Guide_ for more info. about Precompiled Headers. I would say RTFM, but I understand how difficult it is to figure out which Borland manual has the information you want (am I a User or a Programmer?). Jamshid Afshar jamshid@emx.utexas.edu PS: Precompiled headers are really great, but their usefulness in large projects is kinda limited because, for example, almost none of my modules include the same headers or include them in the same order. This means the SYM file has to have a separate entry for each module (over 100) with each entry containing alot of duplicate information. I wish Borland would find a way to just precompile a .h file instead of a set of includes statements. I don't do anything fancy in header files, so I don't mind restrictions. Know what I mean?
jerry@polygen.uucp (Jerry Shekhel) (04/14/91)
davel@booboo.SanDiego.NCR.COM (David Lord) writes: > >3) Run BCX (protected mode compiler). > > This means running Windows in REAL mode. Sounds awful, but I'll > try. Actually I thought I had tried this at one point, but I > don't remember just what I was doing at the time. Since BC shows: > "175k memory remaining" the whole time I'm linking I didn't > think swapping was the problem. > No. This means running Windows in Standard (286) Mode. This mode is just as good as enhanced, except you don't get V86 DOS windows or virtual memory. It's even faster than Enhanced mode. > >In article <1038@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes: > >>I have a question about pre-compiled headers. This feature is a miracle, >>but it seems like a new header image (.SYM) needs to be created during the MAKE >>process whenever a file is compiled which includes a set of headers which is >>different from the current .SYM image. In other words, the project maintains >>only one .SYM image. So if your project contains two files, each including >>a different set of headers, turning on the pre-compiled header option doesn't >>save you any time. Is there a way around this, so that the project can >>handle multiple .SYM files (disk space is not a problem)? > >Use the same headers in each module :-). Actually I think only the first few >have to be the same. > Actually, I do use the same headers in each file, but in order to save myself from having to keep track of my external variables in two places, I do this: #ifndef EXTERN #define EXTERN extern #endif [...] EXTERN HWND MyWindow; [...] Then, in MAIN.C I have "#define EXTERN" to force the variables to actually "materialize" in MAIN.OBJ. This causes BC to recompile the headers before and after compiling MAIN.C. I have found, however, that I can use some pragma to selectively prevent header compilation for certain files, and this reduces the number of header compilation steps necessary for a complete build. -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
whitney@sunnyland.cs.unlv.edu (Lee Whitney) (05/03/91)
In article <1991Apr12.154854.29070@SanDiego.NCR.COM>, davel@booboo.SanDiego.NCR.COM (David Lord) writes: ) From: davel@booboo.SanDiego.NCR.COM (David Lord) ) Subject: Re: Using Borland C++ ) Date: 12 Apr 91 15:48:54 GMT ) Organization: NCR Corporation, Rancho Bernardo ) ) In article <1991Apr11.162855.10164@SanDiego.NCR.COM> davel@booboo.SanDiego.NCR.COM (David Lord) writes: ) >davel@booboo.SanDiego.NCR.COM (David Lord) (that's me!) writes: ) > ) >>1) Linking even a minimal Windows program on my 386SX takes twenty minutes. ) >> Using Hyperdisk in Staged Write mode will cut the time down to about five. ) ) To all those people who kept telling me to run the compiler in protected ) mode: you were right. ) ) The program I'm working on took 8 minutes to link in normal mode, ) 4 minutes with Hyperdisk in staged write mode, and 6 SECONDS when ) I run the compiler in protected mode, and that's running under Windows. ) ) Color me astounded. I would kind of like to know where all that extra ) time is going in normal mode. ) Really! Why is protected mode an excuse? The Turbo C 2.0 linker was lightning fast in real mode, so obviously it's possible to avoid at least an unreasonable delay. That kind of link speed is not even livable let alone likable.
hagins@gamecock.rtp.dg.com (Jody Hagins) (05/04/91)
In article <1991May2.192124.26449@unlv.edu>, whitney@sunnyland.cs.unlv.edu (Lee Whitney) writes: |> In article <1991Apr12.154854.29070@SanDiego.NCR.COM>, davel@booboo.SanDiego.NCR.COM (David Lord) writes: |> ) From: davel@booboo.SanDiego.NCR.COM (David Lord) |> ) Subject: Re: Using Borland C++ |> ) Date: 12 Apr 91 15:48:54 GMT |> ) Organization: NCR Corporation, Rancho Bernardo |> ) |> ) In article <1991Apr11.162855.10164@SanDiego.NCR.COM> davel@booboo.SanDiego.NCR.COM (David Lord) writes: |> ) >davel@booboo.SanDiego.NCR.COM (David Lord) (that's me!) writes: |> ) > |> ) >>1) Linking even a minimal Windows program on my 386SX takes twenty minutes. |> ) >> Using Hyperdisk in Staged Write mode will cut the time down to about five. |> ) |> ) To all those people who kept telling me to run the compiler in protected |> ) mode: you were right. |> ) |> ) The program I'm working on took 8 minutes to link in normal mode, |> ) 4 minutes with Hyperdisk in staged write mode, and 6 SECONDS when |> ) I run the compiler in protected mode, and that's running under Windows. |> ) |> ) Color me astounded. I would kind of like to know where all that extra |> ) time is going in normal mode. |> ) |> Really! |> |> Why is protected mode an excuse? The Turbo C 2.0 linker was lightning fast in real mode, so obviously it's possible to avoid at least an unreasonable delay. That kind of link speed is not even livable let alone likable. Also, you will notice a very large speed difference when you turn debugging information off. I'm talking VERY LARGE! Unfortunately, not many people can write large applications without needing the debugger at least once! -- Jody Hagins hagins@gamecock.rtp.dg.com Data General Corp. 62 Alexander Dr. RTP, N.C. 27709 (919) 248-6035 Nothing I ever say reflects the opinions of DGC.
wolf@netcom.COM (Buckskin Tech.) (05/04/91)
whitney@sunnyland.cs.unlv.edu (Lee Whitney) writes: > Really! > Why is protected mode an excuse? The Turbo C 2.0 linker was lightning fast in real mode, so obviously it's possible to avoid at least an unreasonable delay. That kind of link speed is not even livable let alone likable. The Turbo C linker was only designed to link DOS-mode apps. When linking for DOS mode, the Borland C++ linker is at least respectable. However, this is Borland's first linker for Windows (the NewEXE format), and believe me, the NewEXE format is NOT easy to work out. I would guess that Borland tries to make sense of the convoluted NewEXE format by keeping tables of everything in memory. When running in Real mode, that's too much to store, so it tries to do it piecemeal (and takes forever). In Protected mode, it can store all the tables in memory at once, so it can be reasonably fast. Again, this is only a guess. I'm just waiting for the next revision of the Windows linker, hoping it'll be faster in Real mode. - Wolf