Stoelzel Software Technologie SST
SST ShlWAPIFunctionInfo Icon   ShlWAPI.pas Version 1.08

Click to expand or collapse Topic Hierarchy  
Click to expand or collapse Sub-Topics  
Click to expand or collapse Related Topics  
  This topic outlines the reasons for the research conducted by SST on functions implemented in, and exported by various versions of the Windows shell, light-weight, utility dynamic link library, ShlWAPI.dll. It also describes the methods applied in attaining the (intermediate) results described in the functions' descriptions in our ShlWAPI.pas Developer Reference and as summarized in the ShlWAPI.dll Function Support table(s).
Although translating a (large) C/C++*1 header file into a Delphi (Object Pascal) unit is generally a tedious but straightforward task and when we ported the first versions of ShlWAPI.pas from the then current versions of ShlWAPI.h this was no exception to the rule. Unfortunately, starting with the header files that supported functions exported by the ShlWAPI.dlls that shipped with certain Internet Explorer disitributions, things began to get increasingly confusing.
The cause for this confusion not being the changes/modifications that were to be expected in the corresponding, updated, (ShlWAPI) header files, but an in­creasing number of minor in­consistencies that were hard to grasp, but resulted in further development of ShlWAPI.pas having to be temporarily dis­continued, in order to identify the problem(s).
Even though the inconsistencies were quickly found to be (mainly) discrepancies between the functions being imported by our implementantion (of ShlWAPI.pas) and the functions actually exported by ShlWAPI.dll, the underlying cause was more elusive, because we initially ascribed the problems to our own work and this proved unfounded.
The subsequently planned, more systematic review became in itself a problem, because, not only was it forseeable that it would be hard to determine the point at which the problems had actually arisen, but also, in that it raised the question which documentation and C/C++ header file version(s) to use as the basis for the analysis (potentially, any or all might contain mistakes or omissions).
Particularly for the latter of the two aforementioned reasons, it was unlikely that an analysis solely of the header files would render the cause(s). Furthermore, without the ShlWAPI.dll builds' source code, and the export definition (.def) files in particular, we were forced to start by resolving the former. This meant, we would first have to determine which functions are (really) exported by each of the various ShlWAPI.dll versions. Subsequently, we could then merge and compare the results with the functions that are/were officially documented and/or are/were declared in a (Microsoft SDK) header file.
Apart from the work, neither task was (alt. is) particularly demanding, but obtaining reliable results within a limited time frame was not quite as easy as it (initially) appeared. This was (mainly) due to the fact that the development tools*2 that were) at our disposal (at the time), such as the Microsoft SDK's Depends.exe, facilitate copying exported functions' names, but only from one dll at a time.
The first step was therefore to devise a method, by which a list could be compiled from an arbitrary number of text files, each file containing the function names exported by one ShlWAPI.dll build/version, but from which (any (alt. all)) duplicate names had been eliminated. But, as each text file was likely to contain several hundred function names, merging the names in even two or three (let alone five to ten, or more) files, manually, to a (single) list (in which each name occurred only once,) would not only be extremely time consuming, but also highly susceptible to mistakes.
The obvious answer (alt. solution) was to write a script or program that would perform this task. ShlWAPI.pas Version 1.08 being a Delphi project and as the Delphi framework (already) provided a class that was ideally suited for the purpose, (alt. provided an ideal class for the purpose ...) we decided to do the latter.
With this list, we were now in a position
in which, with the aid of program, we were able to easily determine which of its functions were exported by name, as of which ShlWAPI.dll and operating system version, without the risk of mistakes
in which we could, by eliminating all occurrences of the function names in the list from the copy of a header file, determine as of which SDK/header file version (programming) support for a particular function was introduced
in which we could search the other header files belonging to the respective SDK to determine if the functions not declared in ShlWAPI.h were declared elsewhere
in which we could determine which of these functions were officially documented
Thus, the only question that would remain (alt. remained) unanswered was that of the functions that were exported only by ordinal.
Results text
Summary text
*1 Obviously only in as far as the C or C++ code does not contain syntactic elements without an equivalent in (Object) Pascal, such as open parameter lists, template classes, overloaded operators, etc..
*2 short of employing reverse engineering tools

Site Map

Document/Contents version 1.00
Page/URI last updated on April 28, 2022
Copyright © Stoelzel Software Technologie (SST) 2010 - 2017
Suggestions and comments mail to: