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:
WININET.DLL : This DLL exposes the Windows Internet API. It provides the interface between applications using WinINet and Windows Sockets. Applications that use this API check to see whether an Internet connection exists, and establish a connection if necessary. To accomplish this, WinINet leverages the Remote Access API (RASAPI). Once a connection is verified, the application can open a handle to the remote resource, request a connection for a specific protocol and open sessions on that handle for HTTP, FTP or Gopher communications. WinINet provides capabilities such as:
It is during this process that any proxy settings are verified and handled, the username is retrieved (if required) and a connection is made with the server through sockets for any FTP requests. A connection to the server is not created for HTTP requests until the request is actually sent. If necessary, WinINet communicates with Crypto components such as SCHANNEL.DLL. WinINet.Dll provides support for many things, including cookies, history, header interpretation and processing (for example web page redirection and keep-alives), authentication and encryption. WinINet.Dll leverages another DLL, URLMON.DLL for various activities dealing with URL's.
URLMON.DLL : This DLL is the URL Moniker support library for WinINet. A moniker is just a nickname that is used to make an object more familiar and recognizable. The following functions are handled by URLMON.DLL:
And that brings us to the end of this post. In upcoming posts,we will discuss WinHTTP and also look at some troubleshooting scenarios which will better explain when and how to gather the proper data to assist in root cause analysis of Internet Explorer issues. I'd like to thank Brent Goodpaster, one of our Escalation Engineers, for his review and feedback on this post. Until next time ...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.