AutoPatcher Documentation :: APM Format

By Lyndon Brown, Version 2.1.1, Updated 21st August 2007

1 - Preface

Every update, tweak, and addon offered by AutoPatcher exists in AutoPatcher as a "module". Each module consists of an .apm file and a folder which itself contains the setup file(s) for that module. This documentation is designed to walk you through all the properties and capabilities of .apm files for AutoPatcher version 5.6. The file extension .apm comes from AutoPatcher module. The .apm file contains all of the details about the module - the installation instructions, the title and description (that you see in AutoPatcher's selection window), and the estimated install time, are just a few of the properties an .apm file carries.

Basically, there's 2 ways to create an .apm file: with a tool called the Module Editor (v0.6.0.2) that simplified editing and creating module .apm files and the direct creation of any module, that can be done with any plain text editor, like Notepad. For now at least i will assume you are editing/creating an .apm file with notepad.

2 - Sneak peek

Before we get started, lets take a sneak peek at a module for a critical update included in the September 2008 edition of the English AutoPatcher for Windows XP SP3 (x86) release. We will use stuff from this example throughout this document. The module we will look at is KB951748_xp_x86_enu.apm:

[AutoPatcher 5.6 Module]

[General]
Title=Malicious Software Removal Tool - September '08 v2.2 (KB890830)
Title_1030=Microsoft Windows Værktøj til fjernelse af skadelig software v2.2 (KB890830)
Title_1031=Microsoft Windows-Tool zum Entfernen bösartiger Software v2.2 (KB890830)
Title_1032=Microsoft Windows Malicious Software Removal Tool v2.2 (KB890830)
Title_1036=Outil de suppression des logiciels malveillants Microsoft Windows v2.2 (KB890830)
Title_1040=Strumento di rimozione malware per Microsoft Windows v2.2 (KB890830)
Title_1043=Microsoft Windows-programma voor het verwijderen van schadelijke software v2.2 (KB890830)
Title_1046=Ferramenta de Remocao de Software Mal-Intencionado v2.2 (KB890830)
Title_2070=Ferramenta de Remocao de Software Malicioso v2.2 (KB890830)
Description=The Malicious Software Removal Tool helps remove specific, prevalent malicious software from computers that are running Windows 2000/XP/2003/Vista.
Description_1030=Værktøjet undersøger din computer for infektioner med bestemt, almindeligt udbredt skadelig software og fjerner eventuelle infektioner.
Description_1031=Das Tool zum Entfernen bösartiger Software überprüft Ihren Computer auf Infektionen durch bestimmte, weit verbreitete schädliche Software und entfernt diese.
Description_1032=Αυτό το εργαλείο ελέγχει τον υπολογιστή σας για προσβολή από κάποιες συγκεκριμένες και διαδεδομένες κακόβουλες εφαρμογές λογισμικού και σας βοηθά να αφαιρέσετε τη βλάβη.
Description_1036=Cet outil recherche sur votre ordinateur toute infection générée par les logiciels malveillants les plus connus et supprime les infections détectées.
Description_1040=Questo strumento controlla il computer per ricercare le infezioni causate dai più diffusi software dannosi e, se viene individuata un'infezione, la rimuove.
Description_1043=Dit programma controleert uw computer op infectie door specifieke en veelvoorkomende schadelijke software en verwijdert een eventueel gevonden infectie.
Description_1046=Essa ferramenta verifica a existência no seu computador de infecções por software mal-intencionado específico e predominante e ajuda a remover a infecção, caso seja encontrada.
Description_2070=A Ferramenta de Remoção de Software Malicioso do Microsoft Windows ajuda a remover software malicioso prevalecente específico de computadores com o Windows 2000/XP/2003/Vista.
ModuleAuthor=Erik Ramey
WebPage=http://support.microsoft.com/kb/890830/
ReleaseDate=20080910

[Behavior]
ParentID=WINDOWS_CRITICAL_PARENT
UniqueID=KB890830_X86_ENU
Critical=True
AutoExpand=False
Depends=
TimeToInstall=120
TimeToRemove=10
RequiresReboot=False
ModuleFolder=KB890830_files

[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\RemovalTools\MRT
KeyName=Version
KeyValue=7974CF06-BE58-43D5-B635-974BD92029E2

[DetectionFile]
FilePath=
FileName=
FileVersion=

[OperatingSystem]
WindowsVersion=2K,XP_X86,2K3_X86
SystemLanguage=1033,2057

[SystemComponents]
InternetExplorer=ANY
WindowsMediaPlayer=ANY
DotNetFramework=ANY
WindowsInstaller=ANY
DirectX=ANY
MSNMessenger=ANY

[OfficeComponents]
Word=ANY
Excel=ANY
PowerPoint=ANY
Outlook=ANY
Publisher=ANY
Visio=ANY
Project=ANY
OneNote=ANY
FrontPage=ANY
InfoPath=ANY
Access=ANY
SharePointDesigner=ANY
Groove=ANY

[Installation]
"Module:\windows-kb890830-v2.2.exe" /Q /N

[Removal]


[Slipstream]

Okay, now lets get stuck in.

3 - [AutoPatcher 5.6 Module]

This simply tells AutoPatcher.exe when it reads this file that first of all, this file is relevant to AutoPatcher, and second of all, that it's in the version 5.6 format. Make sure this is at the very start of every file.

4 - [General]

This section defines general properties about the module.

4.1 - Title

This property defines what will be listed in the selection window presented to the user. It is a short description of the update/tweak/addon the module will install. Example:

Title=Malicious Software Removal Tool - September '08 v2.2 (KB890830)

You can actually have multiple translations of this text in the same .apm file. In the following example the default text is defined by Title= and also the following translations are also avaiable:

Danish (LCID=1030)
German - Germany (LCID=1031)
Greek (LCID=1032)
French - France (LCID=1036)
Italian - Italy (LCID=1040)
Dutch - Netherlands (LCID=1043)
Portuguese - Brazil (LCID=1046)
Portuguese - Portugal (LCID=2070)

Each specific LCID will be used rather than the default if AutoPatcher is running into the specific localisation of Windows presented into the module.

You can learn more about the List of Locale ID (LCID) Values as Assigned by Microsoft in Microsoft website.

Title_1030=Microsoft Windows Værktøj til fjernelse af skadelig software v2.2 (KB890830)
Title_1031=Microsoft Windows-Tool zum Entfernen bösartiger Software v2.2 (KB890830)
Title_1032=Microsoft Windows Malicious Software Removal Tool v2.2 (KB890830)
Title_1036=Outil de suppression des logiciels malveillants Microsoft Windows v2.2 (KB890830)
Title_1040=Strumento di rimozione malware per Microsoft Windows v2.2 (KB890830)
Title_1043=Microsoft Windows-programma voor het verwijderen van schadelijke software v2.2 (KB890830)
Title_1046=Ferramenta de Remocao de Software Mal-Intencionado v2.2 (KB890830)
Title_2070=Ferramenta de Remocao de Software Malicioso v2.2 (KB890830)

Multiple language texts should only be used where the same setup files apply for the different languages, else seperate modules must be created for the seperate languages!

Note: currently, AutoPatcher 5.6.0.81 does support non-english characters, like é, è, á, à, ç, ã, etc, but only if the module is saved also UTF-8. Otherwise, those sort of characters will be replaced by another one or even may be missing. There's another well-know issue: this only works for Description, not Title. So, this means that in this section of the module souch characters can't exist or they will be replaced by another one or even may be missing, even if the module is saved in UTF-8.

4.2 - Description

This property defines a longer description of the update/addon/tweak. It will be displayed below the selection window when a user highlights the module in the selection window. Example:

Description=The Malicious Software Removal Tool helps remove specific, prevalent malicious software from computers that are running Windows 2000/XP/2003/Vista.

You can have multiple translations of this property too. In the following example, the default text is defined by Description= also other translations text, that will be used if AutoPatcher is running on a each specific localisation of Windows.

Description_1030=Værktøjet undersøger din computer for infektioner med bestemt, almindeligt udbredt skadelig software og fjerner eventuelle infektioner.
Description_1031=Das Tool zum Entfernen bösartiger Software überprüft Ihren Computer auf Infektionen durch bestimmte, weit verbreitete schädliche Software und entfernt diese.
Description_1032=Αυτό το εργαλείο ελέγχει τον υπολογιστή σας για προσβολή από κάποιες συγκεκριμένες και διαδεδομένες κακόβουλες εφαρμογές λογισμικού και σας βοηθά να αφαιρέσετε τη βλάβη.
Description_1036=Cet outil recherche sur votre ordinateur toute infection générée par les logiciels malveillants les plus connus et supprime les infections détectées.
Description_1040=Questo strumento controlla il computer per ricercare le infezioni causate dai più diffusi software dannosi e, se viene individuata un'infezione, la rimuove.
Description_1043=Dit programma controleert uw computer op infectie door specifieke en veelvoorkomende schadelijke software en verwijdert een eventueel gevonden infectie.
Description_1046=Essa ferramenta verifica a existência no seu computador de infecções por software mal-intencionado específico e predominante e ajuda a remover a infecção, caso seja encontrada.
Description_2070=A Ferramenta de Remoção de Software Malicioso do Microsoft Windows ajuda a remover software malicioso prevalecente específico de computadores com o Windows 2000/XP/2003/Vista.

Again, multiple language texts should only be used where the same setup files apply for the different languages, else seperate modules must be created for the seperate languages!

4.3 - Author

This property defines who created the update/tweak/addon that this module installs. E.g. for a Windows update that would be:

Author=Microsoft

4.4 - ModuleAuthor

This property defines who created the module itself, i.e. you!

ModuleAuthor=John Doe

4.5 - WebPage

This property provides a web-address where a user can find more information about the update/tweak/addon that will be installed. It is displayed beside the description on the selection screen when the user highlights an item in the selection window.

WebPage=http://support.microsoft.com/kb/890830/

4.6 - ReleaseDate

This property defines the date on which the setup file the module installs was created. It must be an eight digit number in the format YYYYMMDD (year, month, day).

* However * This property is much more important than it sounds. It actually defines the order that things are installed! AutoPatcher will install modules in the order: older date to newer date (smaller number to bigger). It also has an effect on the order things are listed in the selection window.

There is also a special rule! In the following sections you will find out about how modules are aranged into the tree structure you see in the AutoPatcher selection window. The special rule is that this value must always be higher (bigger number) than that used by a parent module (you'll learn about parent & child modules in a sec).

ReleaseDate=20080910

5 - [Behavior]

This section defines some general behaviour of the module (obviously).

5.1 - ParentID

I recommend that you read the next section about UniqueID first and then come back to this one!

Okay, this property is used to create the tree structure that you see in the Autopatcher selection window. You specify the UniqueID of another module and this will become a child node to that module in the tree.

Note what we said about the ReleaseDate property in the [General] section. The ReleaseDate of child notes must be higher (larger number) than that of parent nodes.

Example, setting our update module as a child node of the Windows critical update module section.

ParentID=WINDOWS_CRITICAL_PARENT
Currently, each one parent module is shared with each other translation for AutoPatcher, meaning that doesn't matter the translation, the ParentID= will be always the same for all.

5.2 - UniqueID

This property defines a unique identifier that AutoPatcher.exe uses to identify each module. It must be unique like the file name of each module, but even more importantly so!

For example, Windows update KB949269 comes in several flavours. The example below is for the English edition of the copy of KB949269 for Windows XP SP2 and SP3 (32-bit, aka x86). The UniqueID used in the example should be unique from the value used by any other possible KB949269 modules. Note that we have not specified 'SP2' in it because in this case: 1 - the update is the same for SP2 and SP3; 2 - the current script is designed to support SP3 only, meaning that no SP2 updates will be added into the script, unless the same update for SP3 also works for SP2. In this case, we will choose this module to be loaded into SP2 and SP3, according to WindowsVersion that we will select in [OperatingSystem] (you will read more about it later). Keep in mind that select an module to run also in SP2 isn't an option that the translator chooses. When Microsoft releases an update, in the infos about each one you can read if the update will or not run in other service packs than the current one (that is currently SP3)

UniqueID=KB949269_XP_x86_ENU

If you skipped the ParentID property, don't forget to go back and read that now!

5.3 - Critical

The policy as of AutoPatcher version 5.6 is to only select by default updates that are deemed critical. This property defines whether or not (True or False) your module is deemed critical. Please note that in the past people have translated the text True and False. Do not do this! Leave it as English else this property won't work! The same applies to other properties using the values True, False, and ANY!

Critical=True

5.4 - Recommended

As i just said, the policy as of AutoPatcher version 5.6 is to only select by default updates that are deemed critical. This property allows us to define whether or not (True or False) we feel a module should be 'recommended' for installation. If the user wishes to use our recommendations, they can run AutoPatcher with the /recommended command line parameter, and then, as well as critical updates being selected by default, recommended ones will be too.

This property should only be used (or at least only set to True) if the Critical property is set to False!

Also note that this is the first property not used in the example at the start of this document! Most properties can be added and removed with no problem!

Recommended=True

5.5 - AutoExpand

This property allows you to have a parent node in the selection window expanded by default should you wish it to be.

AutoExpand=False

5.6 - Depends

This property allows a module to depend on the status of other modules! If you specify the UniqueID of another module here, the user will only be able to select this module for installation in the selection window if the module it 'depends' on is either also selected, or is detected as already installed.

At this time this property only supports one dependency. The ability to have multiple dependencies will be built into a future build of AutoPatcher.

Example, depending on the .Net Framework v3.0 module:

Depends=DOTNET3.0_X86_ENU

5.7 - TimeToInstall

Well obviously this property allows you to specify how long you think it might take for the setup file(s) to be installed. The value should be specified in seconds. This value is used by the AutoPatcher installation window.

TimeToInstall=120

5.8 - TimeToRemove

Again, this property is pretty obvious in what it does. It allows you to specify how long you think it might take to uninstall this update/tweak/addon. Again, this should be specified in seconds.

TimeToRemove=10

5.9 - RequiresReboot

And yet again, another pretty self explanatory property. After the update/tweak/addon has been installed, is a reboot required? After installing everything the user selected in the selection windows, if any had this property set to true, AutoPatcher will attempt to reboot the computer.

RequiresReboot=True

5.10 - ModuleFolder

Normally the folder associated with an .apm file is named exactly the same (including the extension) as the .apm file itself, plus '_files' appended on the end. For example, the .apm file KB931906_x86_enu.apm will have a folder named KB931906_x86_enu.apm_files. As you will see later on in the installation sections, you refer to this folder with the special module: tag. AutoPatcher will normally guess what folder module: should point to from the filename of the .apm file.

There are special cases however where setup files need to be shared between multiple .apm files. Obviously, with different .apm files sharing the same folder, such guessing won't work! Hence the need for this property! If the name of the folder used by a module is not based on the name of the .apm file itself, this property is used to tell AutoPatcher what folder module: should point to.

Note that folders specific to a single .apm file will end with '.apm_files', whereas a shared folder should end in just '_files'.

An example, Sunjava_x86_enu.apm is an English module. The setup file is actually multi-lingual (therefore is shared). The associated folder is named Sunjava_x86_files. Note that the Title and Description fields could have been translated and included in the same .apm file, however we often choose not to so that translators can have more control! Sunjava_x86_enu.apm should use the following in order to point module: to the correct folder:

ModuleFolder=SunJava_x86_files

6 - [DetectionRegistry]

Detection allows AutoPatcher to tell whether or not something is already installed. If a module is already installed it can be highlighted in blue in the selection window, and set to deselected by default (if normally it would be selected by default).

This section details registry detection.

Note: you can have multiple instances of registry detection. They will work on an OR basis, i.e. only one registry detection check must be successful for the module to be considered as already installed. To have multiple registry detection checks, simply create a new set of registry detection properties beneath the first.

6.1 - RegCaseSensitive

This property turns case sensitive registry detection on or off. The default is off. The values you can use for this property are True (on) and False (off).

RegCaseSensitive=True

6.2 - RegistryPath

This property allows you to specify the path to the registry key that needs to be checked.

RegistryPath=HKLM\SOFTWARE\Microsoft\RemovalTools\MRT

Note that the 'hive' must be in shorthand, i.e. rather than HKEY_LOCAL_MACHINE you must instead use HKLM.

6.3 - KeyName

This defines the key (or entry) to check within the specified path.

KeyName=Version

6.4 - KeyValue

And this defines the value of the key (or 'entry') which will determin whether or not detection passes.

Note that AutoPatcher treats hex values as decimal. If for example a key as viewed in regedit contains 0x00000001 (1), it's actually the bit in the brackets (the decimal representation) that you want to use.

KeyValue=7974CF06-BE58-43D5-B635-974BD92029E2

7 - [DetectionFile]

As already said in the [DetectionRegistry] section, detection allows AutoPatcher to tell whether or not something is already installed. If a module is detected as already installed, it will be deselected by default and highlighted in blue in the selection screen.

This section details file detection.

File detection overall works on an OR basis with registry detection overall, i.e. either registry detection OR file detection must pass for detection to be true.
You can have multiple file based detection checks, and they work on an AND basis, i.e. all file based checks must pass, unlike registry detection where multiple registry checks operate on an OR basis.

If we look at detection over all it works like this: IF (reg_#1 OR reg_#2 OR reg_#3 ...) OR (file_#1 AND file_#2 AND file_#3 ...) == passed THEN overall_check == passed.

7.1 - FilePath

This property allows you to specify the path to the file that needs to be checked.

There are a load of special tags you can use here to refer to common system locations (the paths to which may vary from system to system). Such as windows:, i'll list them after the example.

FilePath=progfiles:\autopatcher\

autopatcher:The folder containing AutoPatcher.exe
module:The folder associated with this .apm file
windows:The windows directory, usually C:\WINDOWS\ (C:\WINNT\ on <= Windows 2000)
system32:The system32 directory, usually windows:\system32\
system:Normally the same as system32: however on 64-bit systems points to windows:\system64\
temp:Points to the temporary folder created by AutoPatcher when it runs
progfiles:The program files directory, usually C:\Program Files\
commonfiles:The common files directory, usually progfiles:\Common Files\

7.2 - FileName

This property allows you to specify the name of the file itself that needs to be checked.

FileName=AutoPatcher.exe

7.3 - FileVersion

This defines the specific version of the file your looking for.

FileVersion=1.2.3.4

You can also use comparison operators, for example the following requires that the version be equal or greater than 1.2.3.4:

FileVersion=>1.2.3

You could also specify ANY if you just want to do a simple file existance check:

FileVersion=ANY

7.4 - FileMD5

This is an optional property that allows you to check whether the MD5 hash of a file matches what you supply in this property. You should use this with FileVersion=ANY.

FileMD5=C217379134ACB9B870594156F499E5FB

7.5 - FileOS

This is another optional property. It allows you to restrict the file check to specific versions of Windows. E.g. a module may apply to multiple versions or service pack levels of Windows, and the MD5 or version of a file may be different depending on which system it's run on. This property allows you to specify multiple checks, for different versions of Windows.

The allowed values for this are the same as the WindowsVersion property you will learn about later on.

FileOS=XP_X86

So, then you hava all infos from [DetectionFile], the detection will becomes something like this:

FilePath=windows:\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=KB951376-v2.cat
FileVersion=ANY
FileMD5=EC1D59C0E133B70508FFC7E783CA6795

In this case, AutoPatcher will look if the file KB951376-v2.cat exists in windows:\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}. Please note that you can have registry and file detection in the same module.

8 - [OperatingSystem]

AutoPatcher will only load and display modules in the selection window that apply to the system that AutoPatcher is being run on. I bet your wondering how thats done aren't you? Well thats what this section is for! Here we list all the versions and languages of Windows that this module should be available for.

8.1 - WindowsVersion

Here is where we list the version(s) of Windows.

Format: FAMILY[_SUBFAMILY][_SUITE][_SERVICEPACK][_ARCHITECTURE]

You can use ANY if you want the module to load on any verison of Windows. Otherwise use the above format with the following rules: all capitals; underscores (_), no spaces; a comma (,) to seperate each version. If you need to specify the RTM version, use SP0. Allowed architectures are X86 and X64.

And now an example, the following will prevent the module loading on any system that is NOT Windows XP SP2 x86 or Windows XP SP3.

XP_SP2_X86,XP_SP3_X86

Windows families and suites available to you:

Family Sub-Family Suite
VISTA n/a STARTER
HOMEBASICN
HOMEBASIC
HOMEPREMIUM
HOMESERVER
BUSINESSN
BUSINESS
ENTERPRISE
ULTIMATE
LHSERVER n/a WEB
STANDARD
SMB
SMBPREMIUM
ENT
DTC
STORAGE ENT
EXPRESS
STD
WORKGROUP
CLUSTER
2K3 n/a DTC
ENT
STD
WEB
R2 DTC
ENT
STD
WEB
XP n/a HOME
PRO
MCE2002
MCE2004
MCE2005
MCE*
2K n/a PRO
DTCSERVER
ADVSERVER
SERVER
NT4 n/a WORK
ENTSERVER
SERVER

* XP_MCE is only possible if AutoPatcher could not get more specific information of the MCE version. There is currently an idea of turning "MCE" into a sub-family. We'll see. For now I suggest you stick to just XP_MCE2002, XP_MCE2004 and XP_MCE2005.

8.2 - SystemLanguage

Here is where we list the language localisations of Windows it should apply to. We use the LCID of each language seperated by a comma (,). For example, a module using the following should only load on US English or British English versions of Windows:

SystemLanguage=1033,2057

A list of LCID's can be found here: http://www.microsoft.com/globaldev/reference/lcid-all.mspx

9 - [SystemComponents]

This section expands upon the work of [OperatingSystem]. This section allows you to target specific versions of specific Windows components. For example, one Windows patch may apply to IE (Internet Explorer) version 7, and another to version 6. You can use the properties in here to make a module only load in the selection window if the relevant version of the component is available on the system AutoPatcher is running on.

All of the properties in this section accept the default value of ANY. They also all allow multiple versions to be specified seperated by commas (,), and allow comparisons with => and =< operators.

9.1 - InternetExplorer

For targetting specific Internet Explorer versions.

Example #1, any version:

InternetExplorer=ANY

Example #2, version 6:

InternetExplorer=6

Example #3, greater than or equal to version 5:

InternetExplorer=>5

9.2 - WindowsMediaPlayer

This property is for the Windows Media Player.

9.3 - DotNetFramework

This property is for the .Net framework.

Note that new versions of the .Net framework do not necessarily replace each other. Version 1.1 SP1 replaces all previous versions. Version 2.0 does NOT replace version 1.1 SP1. Version 3.5 SP1 is actually version 2.0 SP1, 3.0 SP1 and 3.5 SP1, bundled together with extra components (note, version 3.5 only applies to Windows XP and greater).

9.4 - WindowsInstaller

Sometimes addons and even occasionally Windows updates themselves require a certain version of the Windows installer in order to be able to actually install. Usually the requirement is that it is greater than version 2.0, but actually, Windows Installer is at version 4.5, meaning that certain modules will only run if the Windows Installed current installed is newer than an specific version, like happends to Windows Defender, that requires 3.1 or greater.

9.5 - DirectX

For targetting specific versions of DirectX - a component of Windows to do with processing graphics.

* Note * Here you must specify the "proper" version number! For example, DirectX 9.0c is actually version 4.09.00.0904!

Heres a list of what we gather are the proper version numbers:

Known asActual versionFirst available in
DirectX 1.04.02.0095
DirectX 2.0 / 2.0a4.03.00.1096Windows 95 OSR2 and NT 4.0
DirectX 3.0 / 3.0a4.04.0068 / 70Windows NT 4.0 SP3
DirectX 4.0Never Released
DirectX 5.04.05.00.0155
DirectX 5.1
DirectX 5.24.05.01.1600Windows 95
DirectX 5.24.05.01.1998Windows 98
DirectX 6.04.06.00.0318
DirectX 6.14.06.02.0436Windows 98 SE
DirectX 7.04.07.00.0700Windows 2000
DirectX 7.0a4.07.00.0716
DirectX 7.14.07.01.3000Windows Me
DirectX 8.04.08.00.???? (RC0)
DirectX 8.04.08.00.0400 (RC14)
DirectX 8.0a4.08.00.0400 (RC14)
DirectX 8.14.08.01.0810
4.08.01.0881 (RC7)
Windows XP
DirectX 9.04.09.0000.0900Windows Server 2003
DirectX 9.0a4.09.0000.0901
DirectX 9.0b4.09.00.0902 (RC2)
DirectX 9.0c4.09.00.0904 (RC0)Windows XP SP2, Windows Server 2003 SP1
DirectX 9.0c - bimonthly updates4.09.00.0904 (RC0)
DirectX 10.06.0.6000.16386Windows Vista (exclusive to)

Please note that the latest version for our AutoPatcher releases (Windows 2000, XP, Server-2003) is 9.0c (4.09.00.0904). DirectX 10.0 is only available in Windows Vista.

9.6 - MSNMessenger

For targetting MSN messenger should you ever need to. MSN messenger has actually evolved into Windows Live Messenger (such later versions only apply to Windows XP and greater).

9.7 - Custom dependencies

As well as all the above dependencies, you can also create your own!

This works similar to file detection which you should have read about ealier. You can have as many of these custom dependencies as you like too!

9.7.1 - ComponentFile

Used to specify the path and file to check.

9.7.2 - ComponentVersion

Used to specify the version of the file to check. You can use the =, =<, and => comparison operators. You can also use ANY to just do a file existance check.

9.7.3 - Example

A good example of a use for this is Windows update KB946648 for Windows XP SP2 and SP3 (x86). This patch updates an component of Windows XP. Most computers running Windows XP will not have this optional component installed and therefore will not require this critical update. Rather than having this update sitting in the critical section of the selection screen and refusing to install (which could confuse users), we can make use of these properties in order to make sure the module is only available in the selection screen if a certain file exists (which suggests the optional component is installed). Here is the what was used in the KB946648 module:

ComponentFile=progfiles:\Messenger\msgsc.dll
ComponentVersion=<5

10 - [OfficeComponents]

These are an extension to [SystemComponents] that will allow us to target Microsoft Office in order to make AutoPatcher for Microsoft Office releases.

10.1 - GUID detection

Each Microsoft Office suite and individual product can be identified by something called a GUID. See the separate 'Office GUIDs' documentation for details about the GUIDs themselves!

10.1.1 - Details

Format: guid<whatever>={GUID1}[,{GUID2}[...]]

<whatever> can be anything you like so long as it doesn't contain an equals character (=), and it must be unique to any other instances.
{GUID1} and {GUID2} are GUIDs for a Microsoft Office products. You can specify as many as you like, each separated by a comma (,). (The square brackets denote optional parameters!).

Multiple GUIDs in the same instance work on an OR basis. Multiple instances work on an AND basis!

10.1.2 - Examples

Example #1
Suite: Office 2003; Package: Office Basic Edition 2003; Language: English

guidOffice={**130409-6000-11D3-8CFE-0150048383C9}

Example #2
(Suite: Office 2003; Package: Office Basic Edition 2003; Language: English) OR (Suite: Office 2003; Package: Office Standard Edition 2003; Language: Portuguese (Portugal))

guidOffice={**130409-6000-11D3-8CFE-0150048383C9},{**120816-6000-11D3-8CFE-0150048383C9}

Example #3
(Suite: Office 2007; Package: Office Word 2007; Language: English; Arch: x86) AND (Suite: Office 2007; Package: Office Standard Edition 2003; Language: English; Arch: x86)

guidWord={********-001B-0409-****-0000000FF1CE}
guidExcel={********-0016-0409-****-0000000FF1CE}

10.2 - Individual component versions

These tags are useful for addons that need to target a specific office application rather than an Office suite.

Note, just like DirectX, you must supply the "proper" version numbers for all of these.

10.2.1 - Specific office dependencies

These properties allow you to specify dependencies for individual Microsoft Office applications.

The following comparison operators are available for you to use: =>, =<, =!.

The =! comparison operator is used for 'NOT equal to'. An example of it's use: You obviously don't need Visio Viewer 2007 if you already have Visio 2007 installed. In a Visio Viewer 2007 module, if you use Visio=<12, it only shows up if you have a version of Visio lower than 12 (aka 2007) but what if you don't have any versions of Visio installed? In order to correct this, you would use Visio=!12, which means, "Compatable if you DON'T have Visio 12 installed".

Here are all the available properties, along with version numbers for Office suites 2000 - 2007:

20002002/XP20032007
Access9101112
Word9101112
Excel9101112
PowerPoint9101112
Outlook9101112
Publisher9101112
Visio6101112
Project8101112
OneNoteN/AN/A1112
FrontPage41011N/A
InfoPathN/AN/A1112
SharePointDesignerN/AN/AN/A12
GrooveN/AN/AN/A12

10.2.2 - OfficeComparison

This property was brought in to solve a problem with some Microsoft Office modules which apply to more than one Office application, but only require one of those to be installed in order for it to apply. For example, an Office module may apply to both Word and Excel 2003, but can be installed even if only one of the two is present. Without this property, a module which depends on both Word and Excel 2003 would not be able to load on a system if only one of the two applications was installed.

The default behaviour described above is the same as setting this property to ALL. Setting this property to JUSTONE will solve the problem.

Note that any specific Office component property below set to ANY has no effect on this! It's only Office components where you specifically specify a version that would cause this issue.

Example #1, both Word and Excel version 10 here must be installed on the system for this module to display in the selection window, even though the patch is perfectly capable of installing when theres just one of the two present. The version of Access is set to ANY and so has no effect.

Word=10
Excel=10
Access=ANY

Example #2, now we have added this new property, this problem is solved. Now the module will load in the selection window whether one or both of the applications is installed on the system AutoPatcher is run on, like we wanted.

OfficeComparison=JUSTONE
Word=10
Excel=10
Access=ANY

11 - [Installation]

These are the instructions that will install the update/tweak/addon. Note that we will want to run the setup file in silent mode and supress any reboot.

As discussed earlier in the script, module: is used to refer to the modules associated folder.

When AutoPatcher actually installs something, it first of all replaces tags like module: with the full paths they represent, it then writes the modules installation instructions to a temporary .bat/.cmd file and executes it. So anything allowed in a .bat/.cmd file is allowed here.

An example set of installation instructions:

"Module:\WindowsXP-KB946648-x86-ENU.exe" /quiet /norestart /overwriteoem

Here we are running the setup file (WindowsXP-KB946648-x86-ENU.exe) and passing in several command line switches to alter it's behaviour.

11.1 - General update switches

Windows updates will generally use one of these three sets of switches:

  1. Older updates will use /q /z /o
  2. Newer updates will use /quiet /norestart /overwriteoem
  3. 'Self-Extractor' updates will use /Q:A /R:N

You can easily tell whether it's a 'Self-Extractor' type update because if you right click it, select properties, select the general tab, and look at the description, it will mention 'Self-Extractor'.

11.2 - .msi update switches

Updates using .msi installers should use the /qn /norestart switches.

"Module:\setup.msi" /qn /norestart

11.3 - Tweaks

To install tweaks, the instructions are as follows. Note that tweak files normally use the .reg file extension, however we rename them to the .apf file extension (AutoPatcher file) to prevent people accidentally running them manually.

An example of a tweaks setup instructions:

regedit /s "Module:\SortStartMenu.apf"

12 - [Removal]

For any update thats detected as already installed, the user has the option of right clicking it in the selection window and selecting an uninstall option. Here is where we specify the instructions that will be used to perform the uninstallation.

These instructions should be exactly the same as [Installation] except they need to tell the item to uninstall itself.

12.1 - General update switches

For uninstallation, Windows updates will generally use one of these two sets of switches:

  1. Older updates will use /q /z /o /uninstall
  2. Older updates using hotfix.exe will use /q /z /y
  3. Newer updates will use /quiet /norestart /overwriteoem /uninstall

I don't know what the switches would be for a 'Self-Extractor' type update, but o see if an older update uses hotfix.exe, right click the setup file, select properties, select the version tab, select 'Installer engine' and it'll say whether hotfix.exe or update.exe was used.

12.2 - .msi update switches

Uninstalling an .msi update is a little complex, but sometimes you can found some help at Windows Registry, following this patch: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

Once in there, you can select an desired update to be uninstalled, like the one for Windows Messenger 5.1:

MsiExec.exe /I{AC5454E7-009D-40BC-98F8-D9654BC2EA6F}

But please notice that the /I option MUST be changed to /X or it will only show an option asking to the user select an proper action. So, for real, this one can be like this:

MsiExec.exe /X{AC5454E7-009D-40BC-98F8-D9654BC2EA6F}

Sometimes, you also can choose more elegant ways to do this, like we currently chose for this same module:

MsiExec.exe /qn /X "Module:\messenger.msi"

In some cases, an reboot may be required in order to complete removal. In this case, if you don't add an /norestart (or the proper selection for the module that you are creating), after an uninstall, the computer will be rebooted automatically. See the example of the removal for Windows Defender:

msiexec /qn /norestart /X "Module:\WindowsDefender.msi"

12.3 - Tweaks

To uninstall tweaks, do exactly the same as installing them, just select a different setup file to run. Hopefully, as well as having a file to apply the tweak, you also have one to undo it!

13 - [Slipstream]

Allows integration of into installation media (user must run autopatcher.exe with the /slipstream switch to do this).

These instructions should be exactly the same as [Installation] except they need to tell the item to install into a share instead of the current system itself.

This section is new to AutoPatcher, and this section of the documentation is not complete, it only covers most general windows patches for now.

Note, this section uses share: to refer to the location of the share refered to by the user on the command line.

13.1 - General update switches

Most Windows updates (those that use /q /z /o or /quiet /norestart /overwriteoem type switches) will use: /integrate:"share:".

Example:

"Module:\WindowsXP-KB950762-x86-ENU.exe" /quiet /norestart /overwriteoem /integrate:"share:"