245 lines
8.6 KiB
Plaintext
245 lines
8.6 KiB
Plaintext
<?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>
|
|
|