Geoff Chappell - Software Analyst
In all Microsoft’s reorganisation of code for the integration of Windows and Internet Explorer in the late 1990s, one executable is strikingly hard to classify. BROWSEUI was first released with Internet Explorer 5.0 and has been a standard part of the NT stream of Windows releases since Windows 2000. It does much that is very specific to Internet Explorer, including to parse the Internet Explorer command line. Yet it also does much that is essential to using the Windows Shell even in the complete absence of an internet connection, let alone of any web browser. For instance, BROWSEUI also has a function for parsing the Windows Explorer’s command line. Between a study of the Windows Shell and a study of Internet Explorer, where does BROWSEUI properly fit?
No guidance is to be found even by looking at what Microsoft itself says about BROWSEUI: hardly anything about BROWSEUI is documented.
However, a good inference exists that Microsoft does not regard BROWSEUI as belonging essentially to Windows in the sense expected of the Final Judgment in United States v. Microsoft, CA No. 98-1232. To settle this case, Microsoft agreed to disclose “the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product”. Inasmuch as this put Microsoft to decide whether BROWSEUI belongs to Internet Explorer (which the judgement lists specifically as Microsoft Middleware) or to Windows, it seems fair to infer that Microsoft must have chosen to regard BROWSEUI as internal to Internet Explorer. Otherwise, at least some BROWSEUI functions, e.g., SHParseIECommandLine, would have needed to be documented for settlement compliance.
Another indirect inference comes from more recent work on the code by Microsoft. For Windows Vista, various functions in BROWSEUI, COMCTL32, SHDOCVW, SHELL32 and SHLWAPI are retired, in the sense that they are now forwarded to a new DLL, named SHUNIMPL, which exists just to provide stub codings for failing the forwarded functions. Of the BROWSEUI functions that parse command lines for the Windows Explorer and for Internet Explorer, BROWSEUI retires the former but keeps the latter (which finally get retired in Windows 7).
The clincher for me is Microsoft’s practice regarding localised resources. In versions from Windows 2000 up to but not including Windows Vista, several large executables that are supplied with Windows have most of their localised resources separated into a file whose name ends in LC.DLL. For instance, the resource file for BROWSEUI.DLL is BROWSELC.DLL. The copy of BROWSELC that is in the Windows SYSTEM32 directory, with the executable, is for what’s called the system default UI language. If you have installed multi-language support, you may also have a BROWSELC for one or more other languages. Where does Microsoft install such extra copies of BROWSELC? The answer is: in subdirectories of the Internet Explorer installation, e.g., beneath “C:\Program Files\Internet Explorer”. It’s just not credible that this location for these resource files can have been chosen without it having been thought at Microsoft that BROWSEUI belongs with Internet Explorer.
Rightly or wrongly, then, this study treats BROWSEUI as an Internet Explorer module.