In the early days of AutoPatcher, we used to distribute each release in a single package. That package contained the AutoPatcher program itself, together with all the updates needed, distributed as a single very large download. The whole idea was to allow any user to update Microsoft Software without needing an Internet Connection. Suddenly, on 29 August 2007, after more than four years of existence, as a result of one Microsoft Cease and Desist order being given to the team, to the Neowin forums and to some of our download mirrors, we were forced to abandon this distribution format. Microsoft stated that this was for "security reasons" but would not further clarify.
Shortly after the project was shut down, Antonis Kaladis decided to resume production of AutoPatcher. The main reason: without AutoPatcher, people would start to spread home-made versions of AutoPatcher over the internet, completelly breaking down the Cease and Desist order given to us by Microsoft. The worst part about it was: since home users are unable to sign the modules, how could someone know the difference between a legitimate version and a badly done pirate version, that could be full of very dangerous issues? How we know that our versions are safer than an home-made version? Pretty easy. All we from AutoPatcher team care a lot about it. We us to double-check every single download, to make sure that it isn't corrupted. Also, we check each file and we store his MD5 fingerprint to be checked later. Is md5 100% safe? No, it isn't. Long time ago, was proven that and md5 can be faked. But it easy to do? No, it isn't. Also, there's another issue: fake an md5 fingerprint could be easy to someone with the proper knowledge, but we are talking about just one file? No. We are talking about a few dozens files, each one downloaded straight from Microsoft Website, matching with the terms of the Microsoft Cease and Desist order. Would this be easy to fake?
So, how we may do a few dozens of updates come straight from Microsoft servers to your home, without be tempered? With this idea in mind, Antonis Kaladis has created an downloader tool, that we call AutoPatcher Updater, or just APUP, that download and store all the updates required in the same file structure used in previous AutoPatcher release.
At this point, you may have realized already that Apup is a kind of download manager, but please note that Apup currently isn't an download accelerator and also currently it doesn't do several downloads at the same time. It downloads each update, one by one, downloading every single file at the same speed as the website server delivers files to any other downloader, except that Apup doesn't split a download into several pieces to download the whole thing faster than downloading one update after another. Apup is an updater, like the updaters built into projects like Firefox. Not only does Apup download files, it also checks and verifies files and deletes files in order to bring up-to-date the set of files held locally on the hard-disk.
Currently, Apup is a very simple tool, that still needs to be perfected. But mostly, it works. This tool can run in default mode or it can run with a command-line string, each one designed with a specific purpose:
this option will tell Apup to store a log-file (apup.log) with details of what happened during the updating process. Mostly, it looks like this:
So, what kind of information can we find in here?
Do you remmember when we first talked about LCID, in AutoPatcher Documentation - APM Format? If so, you will also remmember what is that 1046 that you can see above. Yes, that log was taken from a system running on Microsoft Windows XP Service Pack 3 in Brazil. Why is this information included? We need it in order to be able to track Operating System related issues. Also, like any software, Apup isn't flawless. So, we need to know if Apup is running on a target system or not. Could you imagine how many people have no idea about their own OS? Well, we need know an closer answer than that. So, we need it.
In the next line, you can find this information:
So, what does this tell us? Well, to say the least, it says in what language your system is running. You may very well have the Current Locale as English - US and you may have Non-Unicode Default also Chinese and, in some cases, it may be a problem. So, we need to know about it. Take a look into this scenario, for example:
With this settings, the most probable issue that you will have is this:
Because of this kind of log, showing this issue, we now know that the most easy fix for this is issue is just change your Language for non-Unicode programs to English when you run Apup. This issue probably will be fixed someday, but to be able to fix it, we need to know about. So, if someday you find some issue in Apup, please show the log to us.
What is the importance of this info? Since you can very well download a couple of releases in a single shot, this info can say a lot to us. Let's say that you have selected the ptb and enu release, in a single shot. Well, some releases share the same file names. But then, what could happend? Easy. One script could look for an md5 fingerprint and another one, other md5 fingerprint. So, this can gives to the user an error, that is reported in the log.
Do you remmember the old days of MS-DOS, or have you ever used the Command Prompt in Windows, where to remove a file or a folder you need to type something? Well, in this one, we have 3 samples of it. In first case, Apup is trying to remove an already obsolete module. In the second case, Apup is trying to remove the folder where was stored the update. And, at the 3rd case, Apup was trying to rename an file. Remove file and folders, ok, an update may become obsolete and needs to be removed. So, del and rmdir are ok, but why rename? For a momment, just suppose that an file was downloaded with an non-desired name. Why download it again, if you can just rename the file?
So, what happend with this one? Easy. In order to save bandwith and download time, Apup currently checks for each file that you already have in apup folder, to download just the updates that changed since the last time that you have executed Apup. In this case, Apup has found that rootsupd.exe md5 doesn't match with the md5 fingerprint that was expecting. It may happends if:
1 - the was updated and still have the same name;
2 - the file that you have is corrupted.
In booth cases, Apup will add this update in his download list and download it again, until got the expected md5 fingerprint. Currently, Apup doesn't resume the download task if an file doesn't match. Why? Easy. You may just have found an new version for an KB (that is the exact case for this one) and our scripts may not have beeing updated to the new version yet. So, if is this the case and an auto-resume or an "try again" option was selected, Apup may download the same file over and over again, making you waste your time and bandwith. With that option turned off, you usually:
1 - try run the same script again to see if this is fixed and, if not, report it on our foruns;
2 - forget about the warning and run autopatcher despide of that, by your own will. The 2nd option is the worst that you can choose. First of all, you aren't helping yourself and, to say the least, your download may have arrived corrupted and will not work.
This option is usually choosen by Release Maintainers, to test his own scripts before it goes online. You may select this option with /log too, like in this sample:
Currently, Apup doesn't work alone. For some tasks, Apup acts like an interface. So, if it acts like an interface, it will need some extra files, isn't? If Apup needs extra files, why should we polute Apup root by other files? There's no need for that, right? So, in order to work, Apup also needs the files that are stored in apup_bin folder. In there, you can find:
7za.exe - this file was added in 1.0.5 release. This file is used to uncompress the modules. Some time ago, we us to choose uz.exe to this task, but by some reason, this file was giving false alarms by some antivirus software. So, we given up to it and we now can choose any one of the formats supported by 7zip to store our modules or uncompress anything that is stored in an format supported by 7zip, that includes: 7z, ZIP, GZIP, BZIP2 and TAR (packing/unpacking) and also RAR, CAB, ISO, ARJ, LZH, CHM, MSI, WIM, Z, CPIO, RPM, DEB and NSIS (unpacking only). You can learn more about this freeware in his own website: http://www.7-zip.org/
aamd532.dll - this file is used for MD5 Security implementation;
CAPCAB.EXE - this file is needed for Service Pack detection;
MSCOMCTL.OCX - this file is part of Microsoft Visual Basic 6.0 Common Controls;
MSWINSCK.OCX - this is the winsock control module used in Visual Basic applications to add the functionality of socket programming.
Again, in order to avoid polution under Apup root, in Apup 1.0.5 we moved all the scripts that Apup will need to work to an temp folder named temp_bin. This folder is set to be removed after Apup finish, but you may found this files in there:
apengine.script - this file says to Apup check for his own files, the files needed by AutoPatcher.exe and also the interface translations;
releases.list - in this file, we store the infos about each avaiable script and by doing so, this file is used by Apup in order to show to you what scripts you can choose;
autopatcher_directx.script - this is the script that you choose to download in Apup main screen. If you have selected to download several files at once, you will see in this folder several files like this one. Each one has the name (or an shortcut) for the name of the release that you have choosen.
Please, notice that this is an temp folder. So, if you choose this file to store any sort of file that you are working with, you will loose it. So, Never, never put your original script in this folder when using /localscript.
releases.list is a text file. You may open this file with Notepad or with any Programmer's Editor. Inside it, you will found something like this:
This file is self-explanatory, but in any case:
Name - is the name of the release;
Date - is the latest time that the script was released. The date format is YYYYMMDD;
DetectFile=autopatcher:\xp_x86_enu.rti - each release has its own. This is the signature file;
DetectHash - in this field, we can inform the md5 hash for the file that was detected in the line above it. It may or not be written, but only in releases.list file. In the script, you will need update it each time that you update your release;
WindowsVersion=XP_X86 - is the Operating System targeted by the script
SystemLanguage - is the language of the script. This information allows Apup to auto-select the proper script based in the Operating System that Apup is running on;
OfficeVersion - same as WindowsVersion, but for MSOffice;
OfficeLanguage - same as SystemLanguage, but for MSOffice;
Script - this field says where to download the desired script;
Size - this field was designed to stores the release final size, but at the moment we do not use this field, so is not needed;
APUPVersion - this field says the Apup version that is required for the script to work properly
For an end-user, no knowledge of this file is necessary. But for Release Maintainers, Staff and Developers, this is a need to know information. For security reasons, only a few AutoPatcher Team members are able to edit this file. Basically, only those that are Developers or who have Administrator privileges. Staff members and Release Maintainers cannot edit this file. So, each time that a Release Maintainer updates his script, he needs to send this information to a Developer, who will then update the releases.list file. There's no need to update this file 5 times a day and also there's no need to update this file if you only did a cosmetic update. But if you have updated your script with a critical update, the Release Maintainer MUST send us this file to update the releases.list file. Also, the Release Maintainer must bear in mind that the admins and Developers may not be reached all times. Also, there's no problem about choosing someone to update this information. When you need to update this info about your release, you may do that request in the proper topic at the BetaTeam or Staff area of our foruns. The Staff area is for AutoPatcher Team members only. So, if you are on trial to become an AutoPatcher Team member, you may not be able to reach this area.
You probably already know this one also:
And maybe also with other names, matching our current releases. In this file are stored all URLs, infos, etc that will be needed to deliver you the desired release. This file may or not have an changelog. If you wish, you may do yours in here, but don't forget that each line of comments need have this at start: #. So, a comment line needs to look like this:
Otherwise, Apup will think that this is something to process and may return an error or even crash. This file can have some sections, to make easier to you remember where you need put something.
Apup will process this in the exact same order that is written, so, every single time that you need add something that needs happend after something, you need put it in the last position of your Pre Actions or something may gone wrong. You may choose those pre action commands:
In order to work, anyone of this pre-actions must have set the relative patch for the action to be taken, between " ", like this:
Also you can see, one is for a file delete/remove and the other one is for folder removal/move. About the relative patches, you was supposed to learn about that at AutoPatcher Documentation - APM Format.html.
This pre action was designed to allow you remove any folder that is needed. This command was replaced by PreAction=rmdir /S /Q, but it still works. You may choose any of them, but please choose rmdir. This action need be writen like this, in order to work:
This action was desined to allow you to remove any file that is needed. This command was replaced by PreAction=del, but still works. You may choose any of them, but please choose del. This action need be writen like this, in order to work:
This action was desined to allow you to rename any file that is needed. This command was replaced by PreAction=ren, but still works. You may choose any of them, but please choose ren. This action need be writen like this, in order to work:
Where: 1.txt is the original name and 2.txt is the desired name
This action was desined to allow you to move any file that is needed. This command was replaced by PreAction=move /y ,but still works. You may choose any of them, but please choose move /y. This action need be writen like this, in order to work:
"autopatcher:\modules\Critical\1.txt" is the original path for reach the file and "autopatcher:\modules\1.txt" is the desired patch for the file. The pre action move /y also works for folders
This action was desined to allow you to move any file that is needed. This command was replaced by PreAction=move /y, but still works. You may choose any of them, but please choose move /y.
In order to allow you know when an action was taken, may be an good idea make an comment like this:
before take any action. You may choose your own date format, if you wish. In this case, it is written in DD.MM.YYYY
Currently, each autopatcher release shares some files with all languages. You may learn about the Parent Modules at AutoPatcher Documentation - APM Format.html. So, those files are to be let untouched in each release, unless that each other one Release Maintainer be warned about first. Basically, the shared modules are this ones:
So, if you need add/update any sort of translation in those files, ask for that in the Staff area of our forum. Those files can't be updated for yesterday, because each script must have the exact same file. You only will reach this area if you are an AutoPatcher Team member.
In this part of the script, you do the download for each .apm file. In order to save time and bandwith, all the .apm files must to be set to download all at same time, even if just one file isn't in there. This section is to be in the script so many times than needed to reach all modules that you have in your script. It looks like this:
In order to show the user what Apup is downloading, the Item must show what is. In this case, Apup will show to the user that is currently downloading the AutoPatcher WGA Modules and will not inform anything about the files that is downloading, unless that the user select Apup to run in /log mode.
6.1.1 - DetectFile
In this, you must write the relative patch to the file that must be checked. This patch must be exact and must not contain any spaces after the file name.
6.1.2 - DetectHash
In this, you must write the md5 hash for the file that you have set to be detected in the previews line. You can take the md5 for the file with any md5 tool that you like. The md5 isn't case-sentivive, so, doesn't matter if is e620cd404fa8fdcbb15c819434e02a67 or E620CD404FA8FDCBB15C819434E02A67, the file is still the same. Based on the infos about the detected md5 hash, the next 6 lines will be processed or not. If the info match, then those lines will be forgotten and the next Item will be processed. In order to work, the md5 hash must be exact and must not contain any spaces after it.
6.1.3 - DownloadFrom
In this, you must set the download location for the compressed modules for this Item. Currently, Apup chooses 7zip to uncompress, so, basically, you can choose any compression metod that you like and is supported by 7zip, but please, try choose the 7z format, with the highest possible compression. Please remember: those files are downloaded from our servers and we pay for it. In order to work, the patch must be absolute and must not contain any spaces after it.
6.1.4 - ExpectedSize
In this, you must say what exactally is the size of the file that you have set in DownloadFrom. You may take that info just by selecting the file, right-click, properties, size. You may see something like this: 1,84 KB (1.887 bytes). With that info in hand, you take the part between (), remove any . or , that may be in there and type the exact same value in this field. This info is used to allow Apup inform the user what still remains to be downloaded. Also, this is an check, if the ExpectedSize doesn't math, you will be given a warning. This value must be exact, can't contains any , or . and must not contain any spaces after it. Please, notice that is the File Size that matters and not the Size on disk.
6.1.5 - ExpectedHash
When after DownloadFrom and ExpectedSize, it will check for the md5 of the compressed file that you have informed in DownloadFrom. In order to work, the md5 hash must be exact and must not contain any spaces after it.
6.1.6 - ActionAfterDownload.Unzip
This is one of the possible actions that may be taken after that the download in DownloadFrom is completed. In this case, it will call for unzip the file. In order to work, this must look like this:
Where: autopatcher:\modules\wga\windows_wga_xp_x86_ptb.7z is the relative path for the downloaded file and autopatcher:\modules\wga is the relative path to the file be uncompressed. The double : in this command is choosen to split one thing from another.
6.1.7 - ActionAfterDownload=del
This is one of the possible actions that may be taken after that the download in DownloadFrom is completed. In this case, it will call for the removal of the compressed file that you have selected to download in DownloadFrom. The action must be taken with the relative path to work and, in order to work, this must look like this:
This can be the worst or the easier part about building an Apup script. It can be the worst part, because you will do this a lot of times. Also, because some updates are public, but you can't find them at Microsoft Download Center. This is the easier part, because you just need to look in the right places, like these:
For now, let us assume that you are starting at the Microsoft Download Center. Once at the Download Centre, you will see a search form and a "go" button. Select that search form and type a KB number to search for, like KB941569 and click "go". When the search results are displayed, look for the desired OS version and follow the link to the download page.
In order to download some updates, you will need to validate your copy of Windows. That situation is dealt with later. First, we will look at an update that does not need Windows to be validated. All security updates fall into this category.
You can arrive at the download page in other ways. For example, if you are starting from a TechNet Security bulletin, direct links to the download pages for each Windows Version are provided.
Once you are at the download page, you will find this:
So, all that you need to do is to select the proper language at "Change Language:" and click on the download button. But for Apup you will need not just the file but the download link to the file. For that task, you may need an download manager, like Getright, Free Download Manager or any other one that you like. But just select your download manager to be in paused mode, so, you will have the enought time to see the download link and save it.
There's also another way to find the download link, without any download manager. In your browser, just select "View, Source code". In the details about the update, you remember the file name? For the English update we are using as an example, the file name is WindowsXP-KB941569-x86-ENU.EXE. So, copy that name and with the source code window for the page opened and the cursor at the very begining of this file, enter CTRL F (both keys at the same time) and paste the file name to searh for in the search box and choose locate next. You will find this:
That is the download location that you need.
Usually, you will obtain the download links from the Microsoft Download Center, right? So, what happends if an update is made public by Microsoft (because you may see it at Windows Update), but you cannot find it at the Microsoft Download Center? Easy. You use Windows Update.
Even Windows Update needs a log file and this is what you use to discover the download links. In this log file, you may find each download that you already have obtained by using Automatic Updates or manually, by running Windows Update in Internet Explorer. This log file is located at: %windir%/windowsupdate.log. It is a text file that can be opened with Notepad or any Programmer's Editor and will look something like this:
Just suppose, for a momment, that you are looking for a download location for an language package for Microsoft .NET Framework 2.0: x86 (KB829019) (or, in Brazilian Portuguese, Pacote de idioma do Microsoft .NET Framework 2.0: x86 (KB829019), that was downloaded by Windows Update and you are unable to find a download location for that at the Microsoft Download Center? First, you have to open WindowsUpdate.log with Notepad (or your favourite Programmer's Editor). With this file opened and the cursor at his very beginning of the file, select CTRL F (both keys at the same time) or look for Edit, Find and type KB829019. You probably will find this:
You have found the moment when Windows Update first showed this update as available to you. If you have downloaded the file at that moment, take a closer look at that point. You probably will find something like this:
Well done, you have found it! Mostly, the packages have the KB number as part of the name. This wasn't the case, but I was trying to show you the worst case scenario!
These look a lot like the Parent Modules downloads, just that these ones are not compressed.
Basically, the structure looks like this:
Item: is the item name. You may choose any name that you like, but the best name is always the KB name for a Microsoft download;
DetectFile: is the name of the file you are checking for. In order to save time and download bandwidth, you need to check if the file that you need is already present. This item checks for the filename. It is always used together with the next line;
DetectHash: already was explained, this is the MD5 hash, or fingerprint, for the file;
DownloadFrom: is the download link for the file, as found in Section 7, above.
DownloadTo: is exactly the same file as at DetectFile.
ExpectedSize: is the file size in bytes.
ExpectedHash: is the MD5 hash or fingerprint for the file that will be downloaded. It is exactly the same as at DetectHash. When Apup finishes this download, it will check if the downloaded file matches this MD5. If it does not, Apup will show a message about "one or more files failed verification..."
MD5 hashing or MD5 fingerprinting can be carried out by any tool that you have. There are dozens of freeware tools for this task and you may choose any one of them.
Currently there are some limitations on the nature of the download link. It must be a direct link to the file itself and not a link that is redirected (an indirect link). Any link that returns the HTTP response 301 or 302 is an indirect link. Any Microsoft link that contains a "fwdlink?LinkId=" section is an indirect link and cannot be used by Apup. Similarly any link that requires a cookie or other form of validation, such as those used by SDN (Sun Developer Network) on the sun.com website can't be used.
For DownloadTo, usually exactly the same filename is used as in DownloadFrom. However, Microsoft regularly renames files downloaded from Windows Update by adding a long hash value to the filename. For these files it is normal to revove that long hash value by renaming the file as it is downloaded. So, in the example given above, the filename:
would be renamed in the DownloadTo line as:
There are several ways of finding the exact file size for ExpectedSize. First and the simplest, if you are comfortable using the Command Prompt, is to type a dir command. However if you are using Windows Explorer, this can be tricky, but basically you need to select the file, right click on it, select Properties, and copy the size from the General tab. In our example if you look for:
then, you just need to copy the part between the brackets ( ) and remove the dots or commas. It must be exact and it must not contain any dots or commas, or any trailing spaces, or in the log file, you will see something like this: