Geoff Chappell - Software Analyst
This function obtains compatibility flags for the current process.
DWORD SHGetAppCompatFlags (DWORD dwMask);
The dwMask argument tells which flags are being queried. The following flags are defined. Names are reproduced from corresponding registry values (see below).
It is not presently intended that this page will describe what each of these flags is for, just what this function does to report them.
The function returns the compatibility flags for the current process. Flags can be returned that were not requested.
There are two sets of compatibilty flags. All but 0x00000100 and 0x01000000 are determined from the name of the current process’s executable and possbily also from its product version as found in the executable’s version resources. The other two flags are determined from window class names.
The filename flags are evaluated just once per process, when this function is first called with any of these flags in the given mask. If the process is marked (in its executable header) as requiring Windows 5.00 or higher, then none of these compatibilty flags apply to it and no identification is attempted.
For the function to identify the process correctly, the process’s fully-qualified pathname must not exceed 80 characters. Failure to meet this condition is here treated as producing undefined behaviour.
Where a filename comes with a version constraint, the compatibility flags do not apply unless version information can be read from the executable, without exceeding 0x1000 bytes, and contains a product version from any of the following version-information values:
Many applications have hard-coded compatibility flags.
|CORELDRW.EXE||major version == 7||OLDREGITEMGDN|
|DAD9.EXE||major version == 9||CORELINTERNETENUM|
|PDEXPLO.EXE||major version == 1;
major version == 2
|PDEXPLO.EXE||major version == 3||MYCOMPUTERFIRST
|POWERPNT.EXE||major version == 8||WIN95SHLEXEC|
|PRWIN9.EXE||major version == 9||CORELINTERNETENUM|
|QPW.EXE||major version == 7||CONTEXTMENU|
|QPW.EXE||major version == 8||ANSIDISPLAYNAMES
|QPW.EXE||major version == 9||CORELINTERNETENUM|
|SIZEMGR.EXE||major version == 3||CORELINTERNETENUM
|softice.EXE||major version == 5||STAROFFICE5PRINTER|
|WPWIN9.EXE||major version == 9||CORELINTERNETENUM|
Note that PS80.EXE appears twice in the function’s tables but since neither entry has version criteria, only the first is ever matched.
All processes can also have compatibility flags set through the registry, in the following key and in each of its subkeys:
The names of any subkeys are irrelevant. Their purpose is just to allow multiple definitions for the one process, most notably because different compatibility flags are required for different versions of the application.
Within each key, data for a value named RequiredFile may specify a file (or pathname relative to the directory that contains the process’s executable) such that compatibility flags defined in this key are to apply only if the specified file exists. String data is intended, but the function accepts data of other types, with bytes interpreted as ANSI characters.
Data for a value named Version may specify any number of version constraints, such that compatibility flags defined in the key apply only if the process’s executable satisfies at least one of the version constraints. Again, string data is intended, but data of other types is accepted, with bytes interpreted as ANSI characters. The data is a sequence of constraints separated by semicolons. If the first character in a constraint is 0x01, then the characters that follow specify a major version, to be matched against the product version up to but not including the first period or comma. In general however, the constraint is to match the whole of the product version, but with an asterisk allowed in the constraint as a wildcard which matches all remaining characters in the product version.
Other values anticipated in the key represent the compatibility flags. To each flag, there corresponds one or more registry values, as listed above. If the value is readable, whatever its data, then the application has that flag. The function tests for each of the defined values and returns the combination. If the application also has hard-coded compatibility flags, then the two sets of flags are combined.
The window class name flags are evaluated just once per process, when this function is first called with either of these flags in the given mask. If among the windows that exist at the time is any whose class name begins with either “bosa_sdm_” or “File Open Message Window”, then both compatibility flags 0x00000100 and 0x01000000 apply.
The returned compatibility flags include the 0x80000000 bit if the window class name flags have yet been evaluated.
The SHGetAppCompatFlags function is exported from SHLWAPI.DLL as ordinal 461 in the version 5.00 from Windows 2000 and Internet Explorer 5.01, and higher.
Though this function dates from as long ago as 1999, it was still not documented by Microsoft as late as the January 2007 edition of the Windows Vista Software Development Kit (SDK).