ECS-L Home Automation and Security Archives
  learn more | view messages for this month | NetBloc® | terms of use | search

Google
 


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects

Subject:
From:
Date:
Re: [ECS] screen saver / execute
Mark Gilmore
Thu, 11 Jun 1998 07:29:52 -0700

Ingo, thanks for the impressive reply !
I modified my pgm execution rtn such that it triggers
a fake keyboard event (shift down/up) to kill the screen
saver (if active) before executing the pgm. Works good.
BTW, my screen saver is set to blank the screen (no drawing).

Ingo Pakleppa wrote:
> 
> You fell into one of Microsoft's traps. When they say Windows 95 is a
> multithreaded 32-bit OS, they aren't outright lying, but they are
> fudging the truth a lot; it's really neither 32-bit nor fully
> multithreaded.
> 
> Your problem is in the fact that at heart, Windows 95 is still a
> single-threaded 16-bit OS in a multithreaded 32-bit disguise (in fact,
> it really is just Win 3.x with an enhanced Win32s and a new user
> interface). In particular, all code that draws to the screen has to use
> GDI, which is still almost completely a 16-bit component - and not
> reentrant. To "solve" this problem, Microsoft implemented a kludge known
> as the Win16Mutex - every time you (or the screen saver) makes a GDI
> call, or for that matter any call into any 16-bit code, the Win16Mutex
> will be set, and all other programs in 95 will be prohibited from
> calling 16-bit code until the Win16Mutex is free again. The same
> Win16Mutex will also be set as long as a 16-bit executable program
> executes. That is, if you run, say, a 16-bit version of Excel in the
> background and let it do a lengthy recalculation, none of your 32-bit
> applications will be able to draw anything to the screen and appear
> frozen (even though as long as the 32-bit application stays in 32-bit
> code to, say, make computations, it will continue to run - it just can't
> display anything).
> 
> Now obviously screen savers do a lot of drawing onto the screen - it's
> their whole purpose in life -, so they essentially keep the Win16Mutex
> locked every time they make a GDI call, which is almost permanently. And
> if you happen to have a 16-bit screen saver, it is even worse because it
> will never exit the Win16Mutex at all.
> 
> Thus, the W95 program will continue to run exactly until the point when
> it needs to draw or call any other 16-bit function, and then be stopped
> dead in it's tracks by the Win16Mutex until the screen saver no longer
> needs to draw to the screen - i.e., until you hit a key.
> 
> The only workaround is not to use a screen saver, or to give up on 95
> and move to NT. NT truly is a 32-bit operating system and won't suffer
> from this problem.
> 
> Ingo
> 
> Mark Gilmore wrote:
> 
> > I have found that when my screen saver has cleared the screen, that
> > any W95 pgms that ECSW attempts to execute will pause until a
> > key is pressed. Any clues on this one ?
> > BTW, to have ECSW execute a W95 pgm AND wait for its completion,
> > use "START /WAIT {pgm} {args...}". This is only required for
> > W95 pgms (not DOS pgms).
> > --
> > Mark Gilmore
> > Omnipotence
> > http://ourworld.compuserve.com/homepages/mark_gilmore_2

-- 
Mark Gilmore
Omnipotence
http://ourworld.compuserve.com/homepages/mark_gilmore_2

  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects




Services provided by [NetBloc]®! NetBloc Solutions Inc.
Terms of use. Indexing software (c) 1999 Lin-De, Inc
.