Date:	Mon, 29 Sep 1997 09:17:38 -0500 (CDT)
From:	Andrew Deren <aderen AT eecs DOT uic DOT edu>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	Peter Palotas <blizzar AT hem1 DOT passagen DOT se>, djgpp AT delorie DOT com
Subject:	Re: Mouse Cursors, GUI's.
In-Reply-To:	<Pine.SUN.3.91.970929100554.1917E-100000@is>
Message-ID:	<Pine.SUN.3.95.970929091546.3024A-100000@bert.eecs.uic.edu>
MIME-Version:	1.0

On Mon, 29 Sep 1997, Eli Zaretskii wrote:

> 
> On Sun, 28 Sep 1997, Peter Palotas wrote:
> 
> > But let's skip the DOS-boxes.
> 
> I'd love to, but since we are talking DJGPP here, we can't run our
> programs any other way.
> 
> > When running windows 3.11 I can't notice *any* mouse-flicker.
> 
> Try harder.  On my system, when I put the mouse pointer on a display
> that gets updated (e.g., the one that shows the system load), or the
> clock, the pointer flickers every time the display changes.  So I
> don't see any magic in Windows' handling of the mouse.
> 
> Since Shawn tells in his message that Windows uses hardware pointer
> feature, I guess that my card (Tseng Labs ET6000 PCI) doesn't support
> it, while yours does.

You are probably not using the default mouse cursor (3d cursor, or some
other animated or custom one). With the default cursor the mouse does not
flicker even when the display is changed, I think it's because it's
supported by the hardware as Shawn pointed out.

 > 
> > I have actually gotten some weird effects sometimes,
> > when windows hangs and exits directly to DOS, where the mousepointer was is
> > now a white square (distorted)... In DOS that is, and it won't move. And
> > doing a QEMM-Quickboot, won't get rid of it.
> 
> Actually, nothing's weird here, AFAIK.  That white square is the last
> mouse pointer that didn't get erased because your program crashed
> instead of orderly shutting down (which includes disabling the mouse,
> which erases the pointer).  And QickBoot doesn't erase it because it
> bypasses some of the boot process which erases the video memory.
> 
> > Well, let me just ask you this first... Would it work to use printf in
> > fork'ed functions? 
> 
> Yes.  This `fork' is implemented using signals, so it never gets close
> to the dreaded DOS non-reentrancy problems.  Using signals means that
> threads cannot be rescheduled while any real-mode call is in progress,
> because the signal from the timer is not delivered until the real-mode
> call returns (this is how the DJGPP signal mechanism works in
> general).  So when some thread calls DOS, it won't be interrupted
> untill that DOS call returns.  Which means that the multi-tasking
> effectively stops until `printf' returns to protected mode (so you
> better not call `printf' to print a 2MByte-long message ;-).
> 
> > And let me also thank you for all the great work you are contributing with,
> > and all questions you answer.
> 
> You are welcome.
> 


                        ,,,
                       (0 0)
   +-------------oOO----(_)-------------------+
   |                Andrew Deren              |  
   |             aderen AT eecs DOT uic DOT edu          |
   | www.eecs.uic.edu/~aderen/ader/main.html  |
   +-------------------------oOO--------------+
                       || ||
                      ooO Ooo
 

- Raw text -