""Robert F. Tulloch"" <tultalk@...> wrote in message
news:3C578D86.320D87D4@......

> Hi:
>
> Working on inno setup script for IB. I am very concerned that these
> identities
> are very different with FB. I assume that if I switch to FB I will
> have to redo this all.

The class and title of the hidden windows has not changed. Therefore, your
FindWindow() call will work with any flavor.

> There is no guardian with FB??

There's the same horrible thing that comes with IB, but with a couple of bug
fixes. Before I had my own access to the CVS tree, I reported that old news
that I had found, that the guardian is a black holes for handles. In other
words, it keeps swallowing OS handles and doesn't return them because it
doesn't close them. This is easy to see:
Start the guardian as an application.
Start NT Task Manager and make sure it shows the columns for handle count
and thread count in the Processes tab
Simulate a crash by killing ibserver from the same Processes tab. Do it
several times. Observe how the aforementioned counters go up. If you kill IB
1000 times, you will lose between 3000 and 5000 handles, no joke.
When Mike Nordell decided to fix the issue based on my report, he found that
some handle variables were reused, hence it was impossible to track the lost
handles. It seems that the original dev thought it was more important to
save a few bytes in the stack and not define additional variables.
After several iterations with Mike sending me new compiled versions, the
thing seemed to stabilize. At the same time, Mike fixed that annoyance that
made the Guardian to show 1999 for year 1999 but 19100 for year 2000 and so
on in the little Crash Report dialog when you double click the Guardian's
icon in the tray.

I sincerely thought the problems were gone. However, a few days ago I
stepped into the source to verify an OS API call and discovered a new
problem (Task Manager was not crazy, indeed). If you put the Guardian in the
tray, its icon begins flashing when it detects that the engine crashed. It
only returns to normal mode when you double click it to get the crash
report. However, if the engine crashes several times before you read the
report, each time, a NEW THREAD is created to flash the icon... and I
thought that renowned SW companies always write good code (aren't Borland
manuals the ones that put emphasis in proper resource management?). When the
engine has crashed 3 or more times, the race condition between the three or
more threads to flash the icon in the tray gives the impression the icon is
again frozen, because it's very hard to detect that it's flashing
chaotically. Only way to stop the festival is to double click the icon in
the tray. As long as you don't do that, you are wasting as many threads as
times the engine has crashed. This issue should be put in our bug tracker.
It won't affect the service, since when it runs as service, it doesn't show
any icon. (If there were more lines of code in it, it would be perfectly
possible that the service would be paired with an icon in the tray. Simply
put, the crash report is unreachable when running the guardian as a
service.)

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing