Subject | Re: [IBDI] IB 6 Install w/TIBInstall |
---|---|
Author | Dmitry Yemanov |
Post date | 2000-09-25T14:51:48Z |
Hi Helen,
wherever else, please feel free to move the example to appropriate places
by yourself.
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. When it's trying to update Microsoft
COMCTL32 library (at 84% of installation process, if I'm not mistaken), it
seems the program is entering an infinite loop. As far as I can understand,
the situation is similar to the following (the source code below has been
reverse engineered by myself and may not correspond the original one exactly).
----------
PROCESS_INFORMATION info;
if (!CreateProcess("...\\401comupd.exe", ..., &info))
... // we handle this error
CloseHandle(info.hThread);
switch (MsgWaitForMultipleObjects(1, &(info.hProcess), FALSE, 5000,
QS_ALLINPUT)) {
case WAIT_OBJECT_0: // OK, we continue the installation
case WAIT_OBJECT_0 + 1: // we do something and then try to call
MsgWaitForMultipleObjects again
case WAIT_TIMEOUT: // we try to call MsgWaitForMultipleObjects a
number of times else
...
};
CloseHandle(info.hProcess);
----------
In my case MsgWaitForMultipleObjects always returns WAIT_OBJECT_0 + 1 and
then this function is called again and again infinitely.
The most interesting and intriguing thing is that it worked okay a couple
of months ago, and I don't know why it doesn't work now (I tried it on some
different machines and the result was always the same). Of course, the
native GUI setup always completes successfully.
Maybe I'm very unlucky guy ;-) and nobody in this world has such trouble
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.
Best regards,
Dmitry
> You can upload files to the Files area of the IBDI list -I'll do it tonight. If anyone wishes to see it in Borland Attachments NG or
> http://www.egroups.com/community/ibdi and click Files in the
> sidebar menu.
wherever else, please feel free to move the example to appropriate places
by yourself.
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. When it's trying to update Microsoft
COMCTL32 library (at 84% of installation process, if I'm not mistaken), it
seems the program is entering an infinite loop. As far as I can understand,
the situation is similar to the following (the source code below has been
reverse engineered by myself and may not correspond the original one exactly).
----------
PROCESS_INFORMATION info;
if (!CreateProcess("...\\401comupd.exe", ..., &info))
... // we handle this error
CloseHandle(info.hThread);
switch (MsgWaitForMultipleObjects(1, &(info.hProcess), FALSE, 5000,
QS_ALLINPUT)) {
case WAIT_OBJECT_0: // OK, we continue the installation
case WAIT_OBJECT_0 + 1: // we do something and then try to call
MsgWaitForMultipleObjects again
case WAIT_TIMEOUT: // we try to call MsgWaitForMultipleObjects a
number of times else
...
};
CloseHandle(info.hProcess);
----------
In my case MsgWaitForMultipleObjects always returns WAIT_OBJECT_0 + 1 and
then this function is called again and again infinitely.
The most interesting and intriguing thing is that it worked okay a couple
of months ago, and I don't know why it doesn't work now (I tried it on some
different machines and the result was always the same). Of course, the
native GUI setup always completes successfully.
Maybe I'm very unlucky guy ;-) and nobody in this world has such trouble
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.
Best regards,
Dmitry