|
|
<?xml version="1.0"?>
<!--
the above tag must be at the beginning of the file for it to be recognized as XML
-->
<!--
NT Application Compatibility Database
Created: 11/19/99 markder
-->
<!--
The database must be bracketed by <DATABASE> and </DATABASE> tags
-->
<DATABASE>
<!--
Within the database, the first section is the library, which specifies the shim DLLs and the patch PATCH files. It must be bracketed with <LIBRARY> and </LIBRARY>
-->
<LIBRARY> <!-- Within the library can be any number of INCLUDE, EXCLUDE, DLL and PATCH entries in any order. By convention we put all the INCLUDE and EXCLUDE entries, then the DLL entries, then the PATCH entries
-->
<!--
An EXCLUDE or INCLUDE entry has one required attribute (MODULE). MODULE specifies a module whose calls should be included or excluded from shimming.
It is expected that the Global list will be only generic EXCLUDE entries, just for the system DLLs. Later in the file one may encounter more specific, single-API excludes in the <DLL> tags.
An <INCLUDE> or <EXCLUDE> tag should be terminated with />.
See below, in the <EXE> section for more about precedence of <EXCLUDE> and <INCLUDE> tags.
-->
<EXCLUDE MODULE="FOO.DLL"/>
<!--
The DLL tag has only one attribute, which is required, NAME. It specifies the filename of the DLL. A DLL tag requires a terminating </DLL> tag
-->
<DLL NAME="MyShim.dll">
<!--
A DLL tag in the scope of the LIBRARY section just names a shim dll that should be added to the database. It can contain an optional <DESCRIPTION> tag and any number of optional <INCLUDE> or <EXCLUDE> tags
-->
<DESCRIPTION> This is the description of the MyShim Dll </DESCRIPTION> <EXCLUDE MODULE="FOO.DLL"/> <INCLUDE MODULE="BAR.DLL"/> </DLL>
<!--
The PATCH tag has only one attribute, which is required, NAME. It specifies the name of the PATCH (as it will be references outside the library). A PATCH tag requires a terminating </PATCH> tag
-->
<PATCH NAME="MyPatch"> <DESCRIPTION> This is the description of the MyPatch patch </DESCRIPTION>
<!-- A patch is executed by matching bytes in memory (to ensure that what resides in memory is what you expect) and overwriting them. Use the MATCH_BYTES and WRITE_BYTES tags as shown below. All bytes must be specified as two-digit hex. Offsets are relative to the base address of the module specified by the MODULE attribute. Use %EXE% as an alias for the main executable module.
--> <MATCH_BYTES MODULE="%EXE%" OFFSET="0x00083FE2">6a 01 56</MATCH_BYTES> <WRITE_BYTES MODULE="%EXE%" OFFSET="0x00083FE2">EB 07</WRITE_BYTES> </PATCH>
</LIBRARY>
<!--
The <APP> tag is optional; an EXE tag can be placed within it or just placed under the <DATABASE> tag. It's a handy way of tying together all the executables associated with a specific Application, including perhaps the installer, the main application, and perhaps various tools or subsidiary executables. An <APP> tag contains one or more <EXE> tags. The <APP> tag requires a </APP> terminator
-->
<APP NAME="AppName" VENDOR="BigISV">
<!--
The <HISTORY> tag keeps a record of who created or modified this entry and what was done to fix the application. From this description, a program manager should know exactly what the application was doing wrong or what changed in the OS to cause the problem.
In cases where generic shims were applied (e.g. version lying, 2GB free space problem), it is sufficient to simply list the problem and the reader can refer to the description of the shim as it is found in the library.
-->
<HISTORY ALIAS="billg" DATE="01/02/2000"> <DESCRIPTION> - Windows 95 version lying. - 2GB disk free space problem. - App was putting its start menu items in the user-specific folder, but uninstalling them from the common folder. It was shimmed so that it installs its items to the common folder. </DESCRIPTION> </HISTORY> <HISTORY ALIAS="steveb" DATE="02/13/2000"> <DESCRIPTION> - App wasn't getting focus in certain startup scenarios. Forced SetWindowForeground to succeed. </DESCRIPTION> </HISTORY>
<!--
The <EXE> tag identifies a specific executable that needs to be shimmed or patched, and specifies the shims or patches to apply to it. The <EXE> tag contains zero or more optional <MATCHING_FILE> tags, zero or more <DLL> tags and zero or more <PATCH> tags. The EXE tag has one required parameter, NAME, and three optional parameters, SIZE, CHECKSUM, and TIME. The <EXE> tag requires a matching </EXE> terminator.
SIZE is the size of the executable in bytes CHECKSUM is a checksum calculated with an algorithm borrowed from the AppsHelp code. See dmunsil or markder for the code. TIME is a human-readable creation time, in UTC (GMT), in the form MM/DD/YYYY HH:MM:SS
-->
<EXE NAME="AUTORUN.EXE" SIZE="12345" CHECKSUM="0xDEADBEEF" TIME="01/01/2001 01:01:01"> <!--
The <MATCHING_FILE> tag allows for checking other files near the executable, to ensure a good match. The files are first checked relative to the executable's directory, and then in the current working directory, which is the directory that the parent process is in (if there is a parent process). For example, if the "SETUP.EXE" program on the CD-Rom root directory E:\ unpacks an installer into C:\WINNT\TEMP\, then executes the installer, the NESY matching system will check for matching files in (or relative to) both C:\WINNT\TEMP\ and E:\. The matching file name can contain a relative path, but should not contain a drive designator, as the target machine may have different letters for the various drives.
The <MATCHING_FILE> tag should be terminated with />
-->
<MATCHING_FILE NAME="..\WIN\MYMATCH.FOO" SIZE="2468" CHECKSUM="0xBEDEBEDE"/>
<!--
In the scope of an <EXE> tag, the <DLL> tag names a DLL that should be applied to this EXE. The shim dll should have already been declared above in the <LIBRARY> section. Optional <INCLUDE> and <EXCLUDE> tags can be inserted between the <DLL> and </DLL> tags.
--> <DLL NAME="MyShim.dll">
<!-- The order of precedence for INCLUDE and EXCLUDE tags is in reverse of their appearance in the file. The shim system walks the list in reverse order and the first INCLUDE or EXCLUDE that matches on all provided attributes will take effect.
For this reason, it is important to put INCLUDES and EXCLUDES ordered from the generic to the specific, as demonstrated below.
-->
<EXCLUDE MODULE="FOO.DLL"/> <INCLUDE MODULE="FOO.DLL"/> </DLL>
</EXE>
<EXE NAME="SETUP.EXE" SIZE="67890" CHECKSUM="0xFEEDBEAD" TIME="02/02/2002 02:02:02">
<!--
In the scope of an <EXE> tag, the <PATCH> tag names a patch file, which should have been declared above in the <LIBRARY> section. The <PATCH> tag should be terminated with />
-->
<PATCH NAME="MyPatch"/>
<!--
<INCLUDE> and <EXCLUDE> tags are not valid for <PATCH> tags, as the PATCH gets applied to the app once at load time, and can't be turned off and on.
-->
</EXE>
</APP>
</DATABASE>
|