I just noticed this in a call stack when network connections fail:
uROWinInetHttpChannel.TROWinInetHTTPChannel.Check(True)
uROWinInetHttpChannel._Check
uROWinInetHttpChannel.TROWinInetHTTPChannel.SendData($2F261A0)
uROWinInetHttpChannel.TROWinInetHTTPChannel.IntDispatch($2F261A0,$2F261E0)
uROClient.TROTransportChannel.Dispatch($2F261A0,$2F261E0)
uROClient.TROTransportChannel.Dispatch(TROBinMessage($2EA2630) as IROMessage)
DataAbstract4_Intf.TBaseLoginService_Proxy.LoginEx(‘User Id=abc;Password=“def”’)
WinHTTP I have no problem with, it’s great stuff. If WinInet didn’t suck, Microsoft wouldn’t have ditched it completely, and recommended people move to WinHTTP. Most importantly, various versions of Windows and IE include versions of WinInet with dreadful timeout bugs. There are other strange WinINET glitches too, especially when you get proxies and advanced Windows networking stuff involved. Why is the base login service using WinInet and how do I turn it off so it doesn’t use WinInet any more? The last app I used that heavily used WinInet was full of these dread Timeout problems, we had to get rid of all use of WinInet to solve them.
Stackoverflow references:
Yes, I’m the person complaining in the second link, that WinInet is crap. But in case anybody else gets these random freezes (even on working network connections, it freezes and times out, on some versions of Windows and various Internet Explorer editions that exist in the wild, and that’s the darndest thing).
This question isn’t rhetorical. If there’s a good reason to use winInet that I’m unaware of, I’d like to know about it. WinHTTP would be much better for http get functionality without the dreaded stupid Timeout bugs.