wininet timeout problem with IE7

[Clodo]

I have different VC++ application which downloads files from server and
process that data at client side. This application uses WinINet.dll
functions for connecting to server through HTTP protocol. It is working fine
with huge data. Recently customers upgraded IE6 to IE7 and they are facing
problems now. while downloading huge data, application showing a timeout
error.
I discover that previous WinINet timeout (with IE6) was infinite, and now
with IE7 it's 30 seconds.
I also discover and tested a solution that work:

CHttpConnection* pServer = NULL;
DWORD dwTimeOut = <a big value or 0 for infinite>;
pServer = pSession->GetHttpConnection(....);
pServer->SetOption(INTERNET_OPTION_RECEIVE_TIMEOUT, &dwTimeOut,
sizeof(dwTimeOut));

This piece of code resolve my problem, BUT...
my company don't have anymore the source code for an old application
installed in many customers (houndred)...
We cannot migrate to an alternative application all this customers in a few
days, but actually many of this costumers (who have IE7) are blocked... I
tried to investigate if the timeout value can be set in registry with no
success, so actually the only possible solution may be disassembly the old
application, and insert the assembly code of the InternetSetOption call, but
seem to be complicated...

The question is: Exists other solution? Sorry for my english! Thanks!

[Clodo]

When i launch my app.exe, internally they done a LoadLibrary (delayed) of
'wininet.dll'.
If i put the older IE6 wininet.dll in the same directory of the old
application, they always use the version in c:\windows\system32
(i think because the LoadLibrary is delayed).
There isn't any method, without changing the old application exe, to tell to
Windows that only 'myoldapp.exe' need to use the 'Wininet.dll' in the same
path of the executable that request it? Thanks!

[Vladimir Scherbina]

Clodo,

Seems like you met an interesting situation. I don't think that using old
wininet module will help you because there might be OS components that rely
upon the new interfaces exposed by wininet.dll. I am also not sure that old
wininet.dll will work properly. Most likely your application uses the new
module because it's linked with wininet.lib and loader binds the import
functions with new version of wininet.dll. Try to use LoadLibrary and
specify the *exact* path to a module.

However, this is not a elegant solution. What about writing the second
application that does the following:

- start your main application and suspend it
- inject written by you dll module that is executing code that sets timeout
value
- resume the main application

I suggest you to create a wrapper application over your main one - each time
customer wants to run your program in runs the wrapper which injects the
code and resumes the program.
--
Vladimir (Windows SDK MVP)
http://msmvps.com/blogs/v_scherbina/

Post by Clodo
I have different VC++ application which downloads files from server and
process that data at client side. This application uses WinINet.dll
functions for connecting to server through HTTP protocol. It is working
fine with huge data. Recently customers upgraded IE6 to IE7 and they are
facing problems now. while downloading huge data, application showing a
timeout error.
I discover that previous WinINet timeout (with IE6) was infinite, and now
with IE7 it's 30 seconds.
CHttpConnection* pServer = NULL;
DWORD dwTimeOut = <a big value or 0 for infinite>;
pServer = pSession->GetHttpConnection(....);
pServer->SetOption(INTERNET_OPTION_RECEIVE_TIMEOUT, &dwTimeOut,
sizeof(dwTimeOut));
This piece of code resolve my problem, BUT...
my company don't have anymore the source code for an old application
installed in many customers (houndred)...
We cannot migrate to an alternative application all this customers in a
few days, but actually many of this costumers (who have IE7) are
blocked... I tried to investigate if the timeout value can be set in
registry with no success, so actually the only possible solution may be
disassembly the old application, and insert the assembly code of the
InternetSetOption call, but seem to be complicated...
The question is: Exists other solution? Sorry for my english! Thanks!

[Clodo]

Thanks Vladimir, i do that.
But i don't know in the application when & where wininet handles are created
or used (i don't have the sources..), so i inject the 'LoadLibrary' code,
and send to customers the exe wrapper and the old wininet.dll to put in the
same directory, so only this apps use the old edition. I already tested this
and work.
I know it's not an elegant solution, but to inject only the
InternetSetOption, i don't know how i can obtain the handle to use as
parameter...
thanks again!

Post by Vladimir Scherbina
Clodo,
Seems like you met an interesting situation. I don't think that using old
wininet module will help you because there might be OS components that
rely upon the new interfaces exposed by wininet.dll. I am also not sure
that old wininet.dll will work properly. Most likely your application uses
the new module because it's linked with wininet.lib and loader binds the
import functions with new version of wininet.dll. Try to use LoadLibrary
and specify the *exact* path to a module.
However, this is not a elegant solution. What about writing the second
- start your main application and suspend it
- inject written by you dll module that is executing code that sets
timeout value
- resume the main application
I suggest you to create a wrapper application over your main one - each
time customer wants to run your program in runs the wrapper which injects
the code and resumes the program.
--
Vladimir (Windows SDK MVP)
http://msmvps.com/blogs/v_scherbina/

Post by Clodo
I have different VC++ application which downloads files from server and
process that data at client side. This application uses WinINet.dll
functions for connecting to server through HTTP protocol. It is working
fine with huge data. Recently customers upgraded IE6 to IE7 and they are
facing problems now. while downloading huge data, application showing a
timeout error.
I discover that previous WinINet timeout (with IE6) was infinite, and now
with IE7 it's 30 seconds.
CHttpConnection* pServer = NULL;
DWORD dwTimeOut = <a big value or 0 for infinite>;
pServer = pSession->GetHttpConnection(....);
pServer->SetOption(INTERNET_OPTION_RECEIVE_TIMEOUT, &dwTimeOut,
sizeof(dwTimeOut));
This piece of code resolve my problem, BUT...
my company don't have anymore the source code for an old application
installed in many customers (houndred)...
We cannot migrate to an alternative application all this customers in a
few days, but actually many of this costumers (who have IE7) are
blocked... I tried to investigate if the timeout value can be set in
registry with no success, so actually the only possible solution may be
disassembly the old application, and insert the assembly code of the
InternetSetOption call, but seem to be complicated...
The question is: Exists other solution? Sorry for my english! Thanks!

[Vladimir Scherbina]

AFAIR you can pass NULL as the parameter to InternetSetOption and it will
work. In any case, if old wininet.dll works then it is good :)
--
Vladimir (Windows SDK MVP)
http://msmvps.com/blogs/v_scherbina/

Post by Clodo
Thanks Vladimir, i do that.
But i don't know in the application when & where wininet handles are
created or used (i don't have the sources..), so i inject the
'LoadLibrary' code, and send to customers the exe wrapper and the old
wininet.dll to put in the same directory, so only this apps use the old
edition. I already tested this and work.
I know it's not an elegant solution, but to inject only the
InternetSetOption, i don't know how i can obtain the handle to use as
parameter...
thanks again!

Post by Vladimir Scherbina
Clodo,
Seems like you met an interesting situation. I don't think that using old
wininet module will help you because there might be OS components that
rely upon the new interfaces exposed by wininet.dll. I am also not sure
that old wininet.dll will work properly. Most likely your application
uses the new module because it's linked with wininet.lib and loader binds
the import functions with new version of wininet.dll. Try to use
LoadLibrary and specify the *exact* path to a module.
However, this is not a elegant solution. What about writing the second
- start your main application and suspend it
- inject written by you dll module that is executing code that sets
timeout value
- resume the main application
I suggest you to create a wrapper application over your main one - each
time customer wants to run your program in runs the wrapper which injects
the code and resumes the program.
--
Vladimir (Windows SDK MVP)
http://msmvps.com/blogs/v_scherbina/

Post by Clodo
I have different VC++ application which downloads files from server and
process that data at client side. This application uses WinINet.dll
functions for connecting to server through HTTP protocol. It is working
fine with huge data. Recently customers upgraded IE6 to IE7 and they are
facing problems now. while downloading huge data, application showing a
timeout error.
I discover that previous WinINet timeout (with IE6) was infinite, and
now with IE7 it's 30 seconds.
CHttpConnection* pServer = NULL;
DWORD dwTimeOut = <a big value or 0 for infinite>;
pServer = pSession->GetHttpConnection(....);
pServer->SetOption(INTERNET_OPTION_RECEIVE_TIMEOUT, &dwTimeOut,
sizeof(dwTimeOut));
This piece of code resolve my problem, BUT...
my company don't have anymore the source code for an old application
installed in many customers (houndred)...
We cannot migrate to an alternative application all this customers in a
few days, but actually many of this costumers (who have IE7) are
blocked... I tried to investigate if the timeout value can be set in
registry with no success, so actually the only possible solution may be
disassembly the old application, and insert the assembly code of the
InternetSetOption call, but seem to be complicated...
The question is: Exists other solution? Sorry for my english! Thanks!

[Vladimir Scherbina]

Another solution came into my mind recently(I hope it can be useful for
you). You can hook the calls to wininet functions.

For example, hook the call to InternetOpen. Once your hook procecure will be
called you can call original function, then call InternetSetOption to
specify the timeouts on a handle. In this case you also need to create
wrapper application which starts your main application, suspends it and
hooks the needed function. There are a lot of articles in the net concerting
api hooking, so I don't think it's problematic to implement.

HTH
--
Vladimir (Windows SDK MVP)
http://msmvps.com/blogs/v_scherbina/

Post by Clodo
Thanks Vladimir, i do that.
But i don't know in the application when & where wininet handles are
created or used (i don't have the sources..), so i inject the
'LoadLibrary' code, and send to customers the exe wrapper and the old
wininet.dll to put in the same directory, so only this apps use the old
edition. I already tested this and work.
I know it's not an elegant solution, but to inject only the
InternetSetOption, i don't know how i can obtain the handle to use as
parameter...
thanks again!

Post by Vladimir Scherbina
Clodo,
Seems like you met an interesting situation. I don't think that using old
wininet module will help you because there might be OS components that
rely upon the new interfaces exposed by wininet.dll. I am also not sure
that old wininet.dll will work properly. Most likely your application
uses the new module because it's linked with wininet.lib and loader binds
the import functions with new version of wininet.dll. Try to use
LoadLibrary and specify the *exact* path to a module.
However, this is not a elegant solution. What about writing the second
- start your main application and suspend it
- inject written by you dll module that is executing code that sets
timeout value
- resume the main application
I suggest you to create a wrapper application over your main one - each
time customer wants to run your program in runs the wrapper which injects
the code and resumes the program.
--
Vladimir (Windows SDK MVP)
http://msmvps.com/blogs/v_scherbina/

Post by Clodo
I have different VC++ application which downloads files from server and
process that data at client side. This application uses WinINet.dll
functions for connecting to server through HTTP protocol. It is working
fine with huge data. Recently customers upgraded IE6 to IE7 and they are
facing problems now. while downloading huge data, application showing a
timeout error.
I discover that previous WinINet timeout (with IE6) was infinite, and
now with IE7 it's 30 seconds.
CHttpConnection* pServer = NULL;
DWORD dwTimeOut = <a big value or 0 for infinite>;
pServer = pSession->GetHttpConnection(....);
pServer->SetOption(INTERNET_OPTION_RECEIVE_TIMEOUT, &dwTimeOut,
sizeof(dwTimeOut));
This piece of code resolve my problem, BUT...
my company don't have anymore the source code for an old application
installed in many customers (houndred)...
We cannot migrate to an alternative application all this customers in a
few days, but actually many of this costumers (who have IE7) are
blocked... I tried to investigate if the timeout value can be set in
registry with no success, so actually the only possible solution may be
disassembly the old application, and insert the assembly code of the
InternetSetOption call, but seem to be complicated...
The question is: Exists other solution? Sorry for my english! Thanks!