APPHELP Functions

The table on this page lists all the functions that appear in the export directory of any known version of APPHELP.DLL. It gives for each function just brief summaries of the APPHELP versions that export the function and of the function’s status with respect to Microsoft’s documentation. This master list is the key to other lists. More detail on each function’s availability and documentation status may be found by looking for the function in other lists according to the function’s first version. In the Table of Contents, expand the entry for APPHELP Versions to get the pages for each version. More explanatory notes follow the table.

Names

Function names are reproduced from the export directory of the APPHELP.DLL executable. All exports from APPHELP are by name, until version 6.2 (Windows 8) exports roughly 30 by ordinal only. The names of functions that are exported only by ordinal are inferred from symbol files that Microsoft publishes for customer support. For such functions, the ordinal is given in brackets after the name. Beware that some functions are shown with two ordinals.

Versions

The APPHELP versions shown for each function are inferred from a study of public releases only. My holdings are incomplete and I anyway have no time for (or interest in) examining pre-release builds or hotfixes. Of necessity then, the table makes what I hope are reasonable assumptions about likely continuity, especially to suppose that a function will exist in future versions or that a function exists in all released builds of a version if no counter-example is yet known. If you want more accurate or comprehensive information, try getting it from Microsoft.

Documentation Status

To describe the information that is publicly available from Microsoft about APPHELP.DLL as thin seems perfectly fair. This is not to say there can’t be good reason for the information to be so thin, just that it is conspicuously thin—and, yes, to suggest that this is very much Microsoft’s intention. No Software Development Kit (SDK) that I have on disc and which in turn has documentation that can be searched on disc has any documentation of any APPHELP function other than ApphelpCheckShellObject. Among the headers in these SDKs, only this one function has a C-language declaration. Something conspicuous about this declaration is that the header, appcompatapi.h, defines a macro, SDBAPI, for the calling convention of this one function. Apparently, there exists an API of SDB functions. A header, named shimdb.h, that is yet known only from a Windows Driver Kit (WDK) for Windows 10, has a #include for an sdbapi.h which the kit omits. Release of shimdb.h and its disclosure that an sdapi.h exists seem likely to be oversights: after all, shimdb.h cannot be compiled while the included sdbapi.h is missing. Most plausibly, this missing header is where Microsoft declares the exported APPHELP functions whose names begin with Sdb—at least the documented ones.

A significant minority of this API of SDB functions is indeed documented. Except for ApphelpCheckShellObject, however, all the functions that are marked above as documented seem to be documented only online, as with SdbBeginWriteListTag (which is here selected as the example only for being alphabetically first). Even as online-only documentation, it’s in a section of Archive Developer Notes as if the functions have historical interest only. Perhaps that’s all the interest they do have at Microsoft and should have to anyone else. Note in this context that where Microsoft provides an Application Compatibility Toolkit, it provides only ready-made tools that use the functionality, not headers and libraries that might help developers find innovatively different ways to use the functionality.

Such documentation as Microsoft does provide online has for all practical effect been frozen for a decade and may anyway have appeared only years after the functionality’s introduction. The functions that are documented are mostly concerned with SDB files. As the form in which Windows keeps its Application Compatibility Database, these files have been around since Windows 2000 SP3 and APPHELP itself dates from the original release of Windows XP in 2001. That the documentation was first made available as early as 2001 seems doubtful and may now be unknowable: the only date in the documentation as browsed now (in August 2016) is a copyright notice for 2016. The documentation certainly does cover functionality that was new for Windows Vista and some aspects of it (such as lists of tags that are defined for database items) are even complete for Windows Vista, but nothing that has been added to the APPHELP functionality since Windows Vista has made it to this documentation. If there have been updates to this documentation in the last ten years, even assuming the documentation was published contemporaneously with Windows Vista in 2006, they seem limited to a mechanical change of the style of annotations that Microsoft adds to function arguments to help its tools for static code analysis.

Pre-History

Though the late Windows 2000 service packs have SDB files, they have no APPHELP.DLL. The first exported functions for working with SDB files are found in an SDBAPIU.DLL. Except that SDBAPIU seems not to have been developed as a Windows component—see especially that its version numbering is not that of Windows—there seems to be very little reason not to regard SDBAPIU as an early APPHELP. The Microsoft Installer certainly does. Where its MSI.DLL, even as late as Windows 8, imports the SDB functions dynamically, it knows to look in SDBAPIU if not running on Windows XP or higher.

The functions that are notated above as “earlier in SDBAPIU” are exported by name from the SDBAPIU that is known from both Windows 2000 SP3 and SP4. The three SDBAPIU exports that were not taken over by APPHELP are included too, but notated “only in SDBAPIU”. The others did not all pass to APPHELP immediately: many are not exported from APPHELP until a substantial increase for the build of version 5.2 from Windows Server 2003 SP1.

A curiosity that is not yet resolved is that SDBAPIU has some sort of continued existence beyond what looks at first to have been its replacement by APPHELP. Though no SDBAPIU executable is known in Windows XP and higher, symbol files for one are contained in Microsoft’s packages of symbol files for Windows 7, Windows 8 and Windows 8.1.

Separate Existence

Many of the functions that APPHELP exports—and many internal routines, too—are not written specifically for APPHELP but are instead incorporated into APPHELP from a statically linked library. This library is nowadays named simply sdbapi.lib. Before Windows 10, however, the library was named differently when built for user mode and kernel mode: sdbapil.lib and sdbapint.lib, respectively.

Kernel Mode

The kernel-mode use was designed from the start, with Windows XP recognising a particular SDB file named DRVMAIN.SDB as listing drivers that are blocked from being loaded. The file is loaded into memory by the loader and interpreted by the kernel (the address and size having been passed in the LOADER_PARAMETER_EXTENSION, via what were then the newly introduced DrvDBImage and DrvDBSize members). Where these SDB functions are used by the kernel there is of course no hope of them being imported from the user-mode APPHELP. There is not a kernel-mode APPHELP to import from, either. They are internal routines and therefore not ordinarily the business of these lists in any mode. The historical interest, however, is hard to resist. More than a few functions that are eventually exported from APPHELP have an earlier history in the statically linked library. Where this history is particularly that the function exists also as an internal routine in the kernel, it is not shown in this page’s master list of APPHELP exports but may be followed among the Remarks in the separate lists of exports by version.

User Mode

Of the user-mode Windows components that need Application Compatibility functionality, surprisingly many get it not by importing from APPHELP but by having it in their own executable image via the statically linked library. Of course, it’s only to be expected that where some low-level DLL such as KERNEL32 wants to work with an SDB file it should have the code in its own binary rather than import from the relatively higher-level APPHELP. Why, though, something as seemingly high-level as GAMEUX.DLL for the Games Explorer carries code from the statically linked library instead of importing from APPHELP may be anyone’s guess.

Delay-Load Failure Hook

From the beginning, a selection of APPHELP exports are covered by the undocumented DelayLoadFailureHook function that has long been exported from KERNEL32 (in its version 5.0 and higher). This function is intended to extend the capability of the library code that Microsoft Visual Studio supplies (with source code) to support delay-loaded importing. The default behaviour of this library code is to throw an exception if the module to be imported from can’t be loaded or if the function that’s to be imported from that module isn’t exported by that module. The usual effect is to crash the program, if not completely brutally for lack of an exception handler then at least unpleasantly for it’s not as if a general-purpose exception handler can really do much about it. Programmers who don’t like to risk this from the default support can supply their own __delayLoadHelper2 routine, but a middle path is to extend the default by setting either or both of two pointers that are defined by the library but which are acted on only if they are not NULL when the library code is called to resolve a delay-loaded import. The DelayLoadFailureHook function is suitable for setting into the __pfnDliFailureHook2 pointer. It is acted on when the module to import is loaded but the function to import from it is not found. If the function is one of some thousands of Windows API functions, both well-known and not, from hundreds of DLLs, then the KERNEL32 implementation of DelayLoadFailureHook resolves the problem by returning the address of a stub that fails the function trivially. The importing module then gets to handle the failure of just the called function.

Even for the first release of APPHELP, DelayLoadFailureHook covers 11 APPHELP functions this way. Probably none were documented at the time. Hardly any have been documented since, and many more have been added to the coverage. This would not, of course, be the slightest bit remarkable were DelayLoadFailureHook exported only from KERNEL32 for use by other Windows components only. And it may be that the implementation in KERNEL32 is just for other Windows components. However, KERNEL32 gets the code and data for its DelayLoadFailureHook from a statically linked library, named dload.lib, which provides the same code and data for SHLWAPI to export DelayLoadFailureHook in its version 6.0 and higher (which, arguably confusingly, means Windows XP and higher). This SHLWAPI implementation is then imported (dynamically) by various components of Internet Explorer. For Windows Vista, a supposed separation of Internet Explorer from calling undocumented Windows API functions is handled by moving the same DelayLoadFailureHook to the new IERTUTIL and renaming it to IERT_DelayLoadFailureHook function. How Internet Explorer has this indirect knowledge of many undocumented APPHELP functions is not satisfactorily dismissed as being anyone’s guess. It ought instead to count to some regulator’s shame. The days were supposed to be long gone that Internet Explorer was written with any access to Windows functionality that Microsoft did not publish for use by competing browsers.

Again, the master list on this page cannot feasibly show the detail of which functions have delay-load support in which versions. For that, look through the separate lists of exports by version. It is not known what guides Microsoft’s choice.