The Windows Internet API (WININET)

It must nowadays be rare that a substantial Windows application will not sometimes want to connect to the Internet—often without caring to get the user’s explicit assent. Long before, it would at least have been very odd had Microsoft not provided a Windows API through which arbitrary Windows applications may set about the humdrum work of Internet access. WININET is the DLL where this functionality is implemented.

So, why do I place WININET in Internet Explorer for this study? I must admit that writing now in 2010 this placement is uneasy. WININET is used by just about every sort of Windows program, from malware to web browsers, as if calling on functionality taken for granted as part of Windows. Where Microsoft documents this functionality in the SDK, it is plainly in the section for Win32 and COM Development, not Web Development. A programmer coming to WININET now, or in the last decade, might easily and reasonably never think of it as having any particular connection with Internet Explorer.

My answer is that a large part of this survey’s motivation is to record for History how the functionality developed. The fact is that WININET was developed for Internet Explorer and was in its early years promoted by Microsoft as part of Internet Explorer. Of course, those were the years when Internet Explorer was often promoted as a means by which consumers of Windows, both users and programmers, could get new Windows functionality faster than waiting for the next Windows version. Boundaries were blurred, surely as deliberate strategy. Yet when the blurring became controversial enough to attract the attention of regulators and courts, the public record left behind shows next to nothing of any attempt to map what functionality actually went where in what software. I may be fighting the tide here, but I think that to place WININET with Windows rather than with Internet Explorer would be to revise history, not to record it.

Something Microsoft itself found to say in 1997 about whether WININET is a part of Windows or of Internet Explorer was:

Windows 95, OEM Service Release 2 includes Internet Explorer 3.0, which in turn includes the Windows Internet Extensions API (WinInet).

If only to me, the “in turn” is definitive. WININET was not then a Windows component that was being helpfully included with Internet Explorer even months ahead of eventual distribution with a new Windows version, as were COMCTL32 and SHLWAPI. No, WININET was plainly said to be an Internet Explorer component making its way into Windows because the former was bundled entirely into the latter.

Neither is it just Microsoft’s words that place WININET in Internet Explorer. The original Internet Explorer 3.0 has a WININET.DLL with a lower version number than ever got bundled into any Windows release. Many functions that have only ever been documented as WININET functions actually originated in a DLL, named URLCACHE.DLL, that seems to have been distributed only with Internet Explorer 3.0, never with any Windows version. All that was long ago, of course. A current test is simply that WININET’s version numbers still track the contemporaneous Internet Explorer release, not the Windows release.

For the general benefit of Windows programmers, I really would prefer that WININET were properly a component of Windows, not of Internet Explorer. If nothing else, Windows programmers would have more WININET functions to work with, since Microsoft’s settlement of anti-trust litigation would have required at least a few more to be documented (as Windows API functions used by Internet Explorer).