Monday, December 08, 2008 


I tend to think that I know the Windows API quite well. In the past few years I've been using mostly the Kernel API, since .NET has made most (but not all) of the others kinda useless. Still, there are times when only knowledge of the right API can save the day. There are also times when the right API can save the day, but nobody (myself included) knows about it :-).

A few days ago, while working on a large, legacy application that we're slowly moving into modern times, we faced an unexpected challenge. The process was busy doing some math. There is only one thread involved, so the GUI was supposed to be frozen, as we do not dispatch Windows messages while doing math. We actually counted on that, for reasons too long to be explained here.

Unfortunately, as we know, in Windows XP and Vista we can move a top-level window around even if the process is not responding, and that broke our expectations.

Now, armed with some background on Windows internals, that XP/Vista feature always seemed odd. Moving a window requires, among other things, that the window itself answers the WM_NCHITTEST message. If our process is stuck doing math, it's unlikely to answer that message.

Looking around with Spy++ we discovered that (most reasonably) the movable window was a fake (ghost) window, hosted by Windows itself into another process. Great: we just needed a way to disable that behavior for our application. Unfortunately, I didn't know any :-).

It took a careful digging to discover the magic API: DisableProcessWindowsGhosting. We never stop learning :-).

As an aside, that old app is supposed to run on Windows 2000 as well (yeap :-), and the magic API requires Windows XP or above, but good old GetProcAddress will take care of that...

Labels: ,

Ecco il genere di post che ogni tanto fa piacere leggere...
Ciao Romano,
capisco la velata protesta "embedded" nel complimento :-))

Giusto ieri ho anche scoperto una sfilza di bug di Windows legati ad un SetCapture fatto in momenti (apparentemente innocenti) in cui non se lo aspetta.
Vista la casistica un po' peculiare, non credo valga la pena approfondire, anche se purtroppo ci ha fatto buttare diversi giorni di lavoro...
Ma si sa, lo sviluppo del software e' un processo di apprendimento :-)
Ciao Carlo.

Ne sono convinto. Non si finisce mai d'imparare. Fortunati quelli che "imparano" prima le idiosincrazie di MS...
Ops... idiosincrasie
Post a Comment

<< Home