www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/09/29/04:10:07

Date: Mon, 29 Sep 1997 10:06:32 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Peter Palotas <blizzar AT hem1 DOT passagen DOT se>
cc: djgpp AT delorie DOT com
Subject: Re: Mouse Cursors, GUI's.
In-Reply-To: <3.0.16.19970928200950.087f930c@hem1.passagen.se>
Message-ID: <Pine.SUN.3.91.970929100554.1917E-100000@is>
MIME-Version: 1.0

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.

> 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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019