Understanding the concepts is a key component in understanding the root causes. To assist in understanding those concepts, we’re going to cover a couple of key components for Internet Explorer. Today we’re covering the WinINet (Windows Internet) Application Programming Interface.
The WinINet API was added to Windows in Windows NT4 and Windows 95. This API set is located in Wininet.dll and is used by WinINET-aware applications such as Internet Explorer, Media Player, and Instant Messenger. The WinINET API itself enables applications to interact with the Gopher, FTP and HTTP protocols. WinINet abstracts these protocols to provide application developers with an interface that resembles standard file IO. Something important to note here is that WinINet is not intended to be used by a server application or Windows service. This is due to the user interaction that is often required by applications that leverage WinINet – such as User Dialogs etc. When writing serviced-based applications, winHTTP.dll should be used instead. This DLL is based on the WinINET API set, but has been modified so that user response (dialogs, etc) has been removed.
So how does WinINet work? WinINet leverages the underlying sockets interface and emulator to access the network as shown in this diagram. It builds its services on top of this infrastructure. WinINet also interfaces with other OS components to provide services such as security and manipulation of the TCP/IP Stack configuration. In addition, upper layer protocol implementations such as UPnP also leverage WinINet. WinINET talks directly to Winsock when making it’s request. In its most basic form Internet Explorer is a Winsock application.
When dealing with WinINet issues, there are two important DLL’s to consider, wininet.dll and urlmon.dll. Let’s take a look at each of these. The diagram below shows the relationship of these components:
Microsoft, Internet Explorer, IE, WinINet, Troubleshooting, Architecture, Knowledgebase, Articles
Source:→ Performance Team Blog