Dmitry,

> > We wanted to make application more responsive to user/system actions while
> > Install API waits until Microsoft update program completes.
>
> Yes, I supposed something similar, because this problem was only in my GUI
> setup and all worked fine in the console variant. But why don't you process
> all setup in the separate thread (maybe with its own message queue) to
> prevent such lazy developers as me from breaking their mind? I think I
> should be responsible for my code only and I wouldn't like to write some
> additional code to make an external library working good. Or maybe it's
> possible to use WaitForMultipleObjects instead of MsgWaitForMultipleObjects
> in the case you have separate thread and thus the message queue won't be
> essential. Don't take my opinion for critics, but maybe you'll look at this
> thing another way while will be working on the next version.

Without getting into much of technical discussions I can only say that the
implementation fully conforms to "Install API Functional Specification and
External Interfaces" and "Install API Desing Spec" as it was adopted for
version 6.0 given all the factors present at the time. It is not my fault
that it was not properly documented.

InterBase saga was the only thing that was not expected and this is the
reason why TIBInstall components were not fully finished for version 6.0.
Install API is not Open Source (which was a surprise for me) and there is
nothing much I can do now.

--
Dmitri Smirnov
Borland
x6558