Dmitry,

> BTW, I should note that there's a problem I've found while was working with
> Install API. I don't know what exactly is wrong, because I haven't seen the
> source code, so I can only suppose. The problem is within
> 'isc_install_execute' implementation.

You reverse engineering attempt is almost correct. If you had read
MsgWaitForMultipleObjects API description you'd see that WAIT_OBJECT_0 + 1
means that there is a Windows message in the queue of your GUI application
that makes use of Install API. If this is the case the Install API allows
you to receive this message and process it by calling FP_STATUS callback
function that you are supposed to provide. If you use Delphi or C++Builder
you simply call Application->ProcessMessages() and return successfully.
Install API indicates when it calls FP_STATUS for this reason. FP_STATUS
also allows you to advance a Progress Bar that you may want to provide.

If you do not supply FP_STATUS callback and do not process the message
then MsgWaitForMultipleObjects will always return WAIT_OBJECT_0 + 1
because the message that arrived to your GUI application will not be
processed and will remain in the application queue.

We wanted to make application more responsive to user/system actions while
Install API waits until Microsoft update program completes.

> except of me. But the only way I could avoid this problem is that I had to
> modify the binary code of this library. I've done it to let my development
> be continued, but of course I'd like to see this thing analyzed by original
> developers and fixed if required.

There is nothing to fix in the install API. Provide the callback and
process your GUI messages while Install API waits for Microsoft binary to
complete. (You could have guessed this if you did went an extra step and
read what MsgWaitForMultipleObjects actually returns).

Former InterBase R&D engineer,
--
Dmitri Smirnov
Borland
x6558