🚀 go-pugleaf

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>