AutoPatcher XP/2003 x64 Hotfix Depot
Cristiano
09 Jul 2009
johnspack, in here, there's an law that states that you can't win less than R$ 465,00. in US money, that is something like 236,75. that is just an fictional value, because a lot of people don't win half of that by month). i win a lot more than that, but i work night and day, anytime. the most sell machines has about 2 or 3GB RAM, with an INTEL onboard vga (you know that this is the worst crap that you can choose for an vga). those machines (that us to broke or burn in 1 year or so are sell by something like R$ 800 (~U$ 407). a few hours ago, i had to fix one machine that the owner was proud of, because it has 3GB of ram and 500gb of hd. my ancient machines are a lot faster than that machine (i've made my own to be able to break an password from an important file. toke almost 3 months, night and day, 24x7. at that time, my machine was state of the art and even the motherboard was imported). worst: an windows vista ultimate x64, in oem, is sell by R$ 610 (U$ 310) and a full license is sell by something like R$ 899 (U$ 457). also, ms and a lot of other companies doesn't think in the rest of the world as their marked, because or we buy the worst crap that can't be sell in any other part of the globe by twice or more the value from US. also, we can't buy an license for any OS in pre-order (or by the half of price of it) because it is for US and Canada only. it's funny know that yours win twice or more than us and still, your pay half or less for an better version from the crap that is sell in here.
in here, if you don't have a job, you are so f... that you have no idea about. sick? forget. is more provable that you will die waiting for an appointment of 5 minutes or less. fast IC? i buy about R$ 100 (U$ 50) to have an 1mb download. i bet that this looks like an offense, but i've said about gasoline? 20% of our gas has alcohol (i know that yours call it from another thing, but i don't remember the word for it). today, i had to refuel my bike. for each lt, i've paid about R$ 2,68 (U$ 1,36). compared with the value that yours paid for it is an offense, isn't?
[]s
in here, if you don't have a job, you are so f... that you have no idea about. sick? forget. is more provable that you will die waiting for an appointment of 5 minutes or less. fast IC? i buy about R$ 100 (U$ 50) to have an 1mb download. i bet that this looks like an offense, but i've said about gasoline? 20% of our gas has alcohol (i know that yours call it from another thing, but i don't remember the word for it). today, i had to refuel my bike. for each lt, i've paid about R$ 2,68 (U$ 1,36). compared with the value that yours paid for it is an offense, isn't?
[]s
johnspack
09 Jul 2009
Sorry, I'm just trying! Guitar_mike if you saw the post below, it shows all new updates since beta3. I'm trying to interpret what Cristiano is saying, but I'm just a dumb Canadian hick! But if you get those updates I show below, you will be up to date. There are 4 more software updates, like windows search ect, I don't care.. but I'll post those too if you like. And I hope Cristiano doesn't think I never worked, I have a college degree, and worked for as many years as I could until I destroyed my spine. Now I can barely walk.
Edited by johnspack, 09 July 2009 - 07:08 AM.
Edited by johnspack, 09 July 2009 - 07:08 AM.
_def_x_
09 Jul 2009
@johnspack
I can assure you Cristiano isn't saying anything negative about you, his message if you will, "is lost in translation".
I think he is trying to say for Americans and Canadians (people in most developed countries), we can come and go more
freely including when and how we update our computer hardware and software. He was attempting to explain the limits on
available components and that it comes at a hefty price so just to go out and buy new parts to run an x64 OS just isn't
practical. I think by "win" he means "make" - so, re read the post and replace win with make...
OK, translating duties over!
I'm very sorry to hear that, back / spinal problems can put otherwise vibrant people on the floor for sure.
Now, I got a screenshot of your "updates" post and I will try to add them once I finish downloading the beta3 script. It looks as if
"rootcerts" has been updated, the hashes don't match and the script re downloads. I have no way of testing an x64 so your input
will be crucial. In fact I would like to see a "fullscreen" scrollable pic of the module loaded in AutoPatcher - everything expanded just
to make sure the naming and descriptions are adequate for all the updates - the way they display in the AutoPatcher window.
I might start "PM"ing you about XP x64, but I still have 350+ MB to go. I don't know if you can get the direct links to those updates
you mention, that would be helpful - the links we use in the scripts, not to the KB page or download page.
Infact, let's talk privately from now on, why you ask - Read More! - I must admit I helped write that, it is unfortunate but true.
Mike
I can assure you Cristiano isn't saying anything negative about you, his message if you will, "is lost in translation".
I think he is trying to say for Americans and Canadians (people in most developed countries), we can come and go more
freely including when and how we update our computer hardware and software. He was attempting to explain the limits on
available components and that it comes at a hefty price so just to go out and buy new parts to run an x64 OS just isn't
practical. I think by "win" he means "make" - so, re read the post and replace win with make...
Cristiano said:
"it's funny know that yours make twice or more than us and still, your pay half or less for an better version from the crap
that is sell in here."
that is sell in here."
johnspack said:
I have a college degree, and worked for as many years as I could until I destroyed my spine. Now I can barely walk.
Now, I got a screenshot of your "updates" post and I will try to add them once I finish downloading the beta3 script. It looks as if
"rootcerts" has been updated, the hashes don't match and the script re downloads. I have no way of testing an x64 so your input
will be crucial. In fact I would like to see a "fullscreen" scrollable pic of the module loaded in AutoPatcher - everything expanded just
to make sure the naming and descriptions are adequate for all the updates - the way they display in the AutoPatcher window.
I might start "PM"ing you about XP x64, but I still have 350+ MB to go. I don't know if you can get the direct links to those updates
you mention, that would be helpful - the links we use in the scripts, not to the KB page or download page.
Infact, let's talk privately from now on, why you ask - Read More! - I must admit I helped write that, it is unfortunate but true.
Mike
Cristiano
09 Jul 2009
Mike, the expression "win" for money isn't very practical, at least, for me. but you make your own money, by deserving it working hard. also, you are paid to do something and the only way that you have to not deserve that money is not going to work.
also, there's an huge difference between G8 and the rest of the globe. by yours, i'm pretty sure that x64 can be the reality, but if any company just stops x32, they go off the market or will sell it to G8 only.
> I hope Cristiano doesn't think I never worked
my friend, i know a lot of people that is currently unemployed by some reason. my girlfriend lost her job last year and, so far, nothing. the same thing goes to a lot of guys. about your issue, i'm pretty sorry about that.
[]s
also, there's an huge difference between G8 and the rest of the globe. by yours, i'm pretty sure that x64 can be the reality, but if any company just stops x32, they go off the market or will sell it to G8 only.
> I hope Cristiano doesn't think I never worked
my friend, i know a lot of people that is currently unemployed by some reason. my girlfriend lost her job last year and, so far, nothing. the same thing goes to a lot of guys. about your issue, i'm pretty sorry about that.
[]s
darthyoda6
10 Jul 2009
I thought I was the on;y one here on dialup
which is why I have to download all the updates at the library.
johnspack
10 Jul 2009
Yes, it looks like I'm be doing a fresh install yet again, it looks like comodo antivirus doesn't work well with xp64, but the firewall does. Hrrrrrmmmm. So I'll do another install, and do a screen snap of windows update after I apply beta3. I'll try to expand everything so you can see what I do. I'll try to do this tomorrow. I'll be back!
René Kåbis
11 Jul 2009
johnspack, on Jul 9 2009, 11:14 PM, said:
Yes, it looks like I'm be doing a fresh install yet again, it looks like comodo antivirus doesn't work well with xp64, but the firewall does. Hrrrrrmmmm. So I'll do another install, and do a screen snap of windows update after I apply beta3. I'll try to expand everything so you can see what I do. I'll try to do this tomorrow. I'll be back!
You may wish to “obtain” Symantec Endpoint Protection. As long as you are not running a server, this is an excellent product (I am experiencing some major conniption fits between the firewall and services on my Windows servers). Anyhow, SEP has got both the widely-acclaimed corporate product (NOT the consumer antivirus… that stuff is just brutally bad!!) along with some malware defence and a very well designed firewall that does both inbound and outbound monitoring. I find it a lot less chatty and a lot easier to use than Commodo and other products of that caliber.
Other than that, cheers from another Canuck. I’m out West, in Kelowna.
With that said, however, I am looking to update AutoPatcher on my own. How do I modify it to deal with newer updates that are not a part of the current x64 beta? I have tried looking in the *.rti files, but all of those seem to be binary (or, at least unintelligable).
_def_x_
11 Jul 2009
@René Kabis... Welcome.
First, know you will forever look at the "Unofficial" status due to the outdated "rti" file, in fact, I would delete any "rti"
named "xp_2k3_rti", and down the road it may help load things faster by removing "apengine.rti" as well.
Note: This applies only to "xp_2k3_x64_beta", don't do this to a release that is still being updated!
I would look at your existing release, studying how the "apm files" work with detecting updates, and as new updates are
offered, download the update, create a new folder, "copy" the appropriate apm to the category (make a template apm file),
fire up autopatcher.exe and see if the update is detected as needed -> "Black". If you should install the update and your
detections are correct the update will appear "Blue" in AutoPatcher. Whether an update is selected for install or not is
decided by the apm conditions - "Critical=" and "Recommended=" -> these are important details.
I have made Critical. NonCritical, Component, and Addon "apm" templates from existing files. Each time I need a new one the
contents of the apm must be modified, the name changed (match the name of the new folder where the update is located).
Important: The key to successfully creating a new apm is to look carefully at all the "conditions" you have placed on the update
from within the apm file - open one in notepad and look, it's all there, but you will need to know about the update based on what
Microsoft says as well - Critical, NonCritical, what OS and SP level, maybe more. You can see why it takes a bit of work to keep
a release updated. You will need to extract the contents of updates to get critical information needed...
...Look inside the apm for details wanted / look at the extracted contents of the update for details given!
Important: Make sure you are using appropriate switches for each update -> update.xxxxxx.exe /norestart /quiet
...This is only an example, switches can vary - consult update documentation for usable switches.
You will need to manually delete all outdated files/folders for updates replaced. In fact, this is easier than updating scripts which
is what we do for "house cleaning" within the release directory. You will need to delete the folder and associated apm -> Done!
Note: When I finish with what I'm doing now, I will update the "apup_bin", "bin", and "tools" folders with new .ocx / .dll files.
Run "apup.exe /log" on your x64 release, check only "AutoPatcher Updater" and "AutoPatcher Engine" to download the new files.
I will post later in "Announcements" when the updated files will be available.
Quote
I am looking to update AutoPatcher on my own. How do I modify it to deal with newer updates...
named "xp_2k3_rti", and down the road it may help load things faster by removing "apengine.rti" as well.
Note: This applies only to "xp_2k3_x64_beta", don't do this to a release that is still being updated!
I would look at your existing release, studying how the "apm files" work with detecting updates, and as new updates are
offered, download the update, create a new folder, "copy" the appropriate apm to the category (make a template apm file),
fire up autopatcher.exe and see if the update is detected as needed -> "Black". If you should install the update and your
detections are correct the update will appear "Blue" in AutoPatcher. Whether an update is selected for install or not is
decided by the apm conditions - "Critical=" and "Recommended=" -> these are important details.
I have made Critical. NonCritical, Component, and Addon "apm" templates from existing files. Each time I need a new one the
contents of the apm must be modified, the name changed (match the name of the new folder where the update is located).
Important: The key to successfully creating a new apm is to look carefully at all the "conditions" you have placed on the update
from within the apm file - open one in notepad and look, it's all there, but you will need to know about the update based on what
Microsoft says as well - Critical, NonCritical, what OS and SP level, maybe more. You can see why it takes a bit of work to keep
a release updated. You will need to extract the contents of updates to get critical information needed...
...Look inside the apm for details wanted / look at the extracted contents of the update for details given!
Important: Make sure you are using appropriate switches for each update -> update.xxxxxx.exe /norestart /quiet
...This is only an example, switches can vary - consult update documentation for usable switches.
You will need to manually delete all outdated files/folders for updates replaced. In fact, this is easier than updating scripts which
is what we do for "house cleaning" within the release directory. You will need to delete the folder and associated apm -> Done!
Note: When I finish with what I'm doing now, I will update the "apup_bin", "bin", and "tools" folders with new .ocx / .dll files.
Run "apup.exe /log" on your x64 release, check only "AutoPatcher Updater" and "AutoPatcher Engine" to download the new files.
I will post later in "Announcements" when the updated files will be available.
René Kåbis
17 Jul 2009
Knucklehead,
I guess that is one step away from contributing, no? If so, how would I go about contributing updates?
Just to confirm -- there are just the KB apm's to be created; there are no "overall OS" apm's specifically for each OS that Autopatcher uses to list the updates available/installed, no?
I guess this is why Autopatcher takes so long to scan… not only does it have to read the directories inside \modules and "ignore" any apm's which are not applicable to the OS it is running on, but it then has to check each applicable apm to see if the KB in question is installed or not.
I guess that is one step away from contributing, no? If so, how would I go about contributing updates?
Just to confirm -- there are just the KB apm's to be created; there are no "overall OS" apm's specifically for each OS that Autopatcher uses to list the updates available/installed, no?
I guess this is why Autopatcher takes so long to scan… not only does it have to read the directories inside \modules and "ignore" any apm's which are not applicable to the OS it is running on, but it then has to check each applicable apm to see if the KB in question is installed or not.
Cristiano
18 Jul 2009
> there are no "overall OS" apm's specifically
there's apms for all Os's. those are the shared modules, like ms update, windows update, rootcert, malicious software removal tool, etc.
> I guess this is why Autopatcher takes so long to scan
not only that. autopatcher also checks for the integrity of each file and that takes time. the detection for the OS and checks for already installed updates takes less than 30s. but the checks for the integrity of the updates is another history
[]s
there's apms for all Os's. those are the shared modules, like ms update, windows update, rootcert, malicious software removal tool, etc.
> I guess this is why Autopatcher takes so long to scan
not only that. autopatcher also checks for the integrity of each file and that takes time. the detection for the OS and checks for already installed updates takes less than 30s. but the checks for the integrity of the updates is another history
[]s
René Kåbis
22 Jul 2009
Cristiano, on Jul 17 2009, 05:01 PM, said:
> there are no "overall OS" apm's specifically
there's apms for all Os's. those are the shared modules, like ms update, windows update, rootcert, malicious software removal tool, etc.
> I guess this is why Autopatcher takes so long to scan
not only that. autopatcher also checks for the integrity of each file and that takes time. the detection for the OS and checks for already installed updates takes less than 30s. but the checks for the integrity of the updates is another history
[]s
there's apms for all Os's. those are the shared modules, like ms update, windows update, rootcert, malicious software removal tool, etc.
> I guess this is why Autopatcher takes so long to scan
not only that. autopatcher also checks for the integrity of each file and that takes time. the detection for the OS and checks for already installed updates takes less than 30s. but the checks for the integrity of the updates is another history
[]s
Okay, I am starting to get a bit confused.
When APUP starts up, it obviously grabs the latest list of packages available. This would be the Win2K-SP4, Vista, Office2K7, etc.
From this, it knows to download updates directly from Microsoft, based on which package is selected (if you just want XP 32-bit updates, for example, you toggle the XP [English] package checkbox).
So how do I go around creating a "master package list" for XP 64-bit so that APUP knows what files to download from where? I have had a look in the *.apm files, but they do not seem to have download URL's at all -- just URL's for more information.
It appears that the *.apm files are just "extra information" files designed to allow Autopatcher to select the correct downloaded files to install based on what operating system it is running on. They appear to have no relationship to APUP, aside from the fact that they were downloaded from the Autopatcher web site. That is, each *.apm is downloaded from Autopatcher at the same time its associated patch is downloaded from Microsoft. I still have yet to find the "master list" which controls which files are downloaded from where for XP 64-bit specifically.
The *.apm files I can create individually (since they obviously don't exist on Autopatcher's web site), but I would like to use APUP to download the patches and updates from Microsoft automagically. That way, I can grab them in one large burst and don't have to backtrack to see if I missed downloading anything.
excalibur
22 Jul 2009
Hi René,
You are mostly correct in the use of the apm files howerver...
I think the confussion is because there are two programs in the update process...
APUP.EXE - This is to download the updates from Microsoft/Adobe/Sun etc...
AUTOPATCHER.EXE - This is to install the updates/addons/tweaks etc to your computer.
APUP downloads a Master List from the autopatcher site. This tells APUP which OS/Tweaks/Addons etc are available to be downloaded and their respective release dates.
You chooses the OS to download and APUP uses the information in the Master List file to download a script file for that OS. The script file holds all the relative details of the updates; size/MD5 Hash/URL to download from etc.
Using these scripts APUP validates that the downloaded file is correct. It also downloads a corresponding module file (*.APM) for each of the update files.
AUTOPATCHER uses the *.APM files to install the updates.
The APM files tells AUTOPATCHER how and where to install the update (using switches such as silent, noreboot etc); also links to the site of the update so that you can get for extra information. It also checkes that the version that you are installing is greater than that which you might already have in your system.
If you are making your own modules then you create your own APM files with the relevant information.
These APM files and the necessary details of the downloads, need to be passed to the mods so that the details can be added to the OS script and the APM can be authorised and released by them.
BTW there are also *.rti files which tells Autopatcher whether the release has been sanctioned by the mods. These are only created/updated by the mods and cannot be changed by the updaters/testers.
I hope this is correct if not I am sure that the mods will put it straight
E
Edited by excalibur, 22 July 2009 - 11:23 PM.
You are mostly correct in the use of the apm files howerver...
I think the confussion is because there are two programs in the update process...
APUP.EXE - This is to download the updates from Microsoft/Adobe/Sun etc...
AUTOPATCHER.EXE - This is to install the updates/addons/tweaks etc to your computer.
APUP downloads a Master List from the autopatcher site. This tells APUP which OS/Tweaks/Addons etc are available to be downloaded and their respective release dates.
You chooses the OS to download and APUP uses the information in the Master List file to download a script file for that OS. The script file holds all the relative details of the updates; size/MD5 Hash/URL to download from etc.
Using these scripts APUP validates that the downloaded file is correct. It also downloads a corresponding module file (*.APM) for each of the update files.
AUTOPATCHER uses the *.APM files to install the updates.
The APM files tells AUTOPATCHER how and where to install the update (using switches such as silent, noreboot etc); also links to the site of the update so that you can get for extra information. It also checkes that the version that you are installing is greater than that which you might already have in your system.
If you are making your own modules then you create your own APM files with the relevant information.
These APM files and the necessary details of the downloads, need to be passed to the mods so that the details can be added to the OS script and the APM can be authorised and released by them.
BTW there are also *.rti files which tells Autopatcher whether the release has been sanctioned by the mods. These are only created/updated by the mods and cannot be changed by the updaters/testers.
I hope this is correct if not I am sure that the mods will put it straight
E
Edited by excalibur, 22 July 2009 - 11:23 PM.
Cristiano
22 Jul 2009
> So how do I go around creating a "master package list" for XP 64-bit so that APUP knows what files to download from where?
oh well, that, in deed, is the tricky part. in that link, you must look for the IT version. in the IT version, you have the full description of the update, with the download link for each windows version. also, you may found the updates that are required in the bulletin:
http://www.microsoft...ty/Current.aspx
but pay attention: ms doesn't read ms. looks weird? well, it's weird. sometimes, the things that are written in there don't match with WU and you only will realize that by doing an clean install. so yes, from times to times, you have to check the entire script by doing an clean install
> knows what files to download from where?
from the script. in here there's the releases link. if you follow some .script files, you will see the list of download locations
> "master list"
well, that has to be done. one way to know the updates that are required for an OS is do an clean install, with just the latest SP and check the updates at WU. after that, of course, you will require check for WU mistakes...
well, time to work again. i had an client call
[]s
oh well, that, in deed, is the tricky part. in that link, you must look for the IT version. in the IT version, you have the full description of the update, with the download link for each windows version. also, you may found the updates that are required in the bulletin:
http://www.microsoft...ty/Current.aspx
but pay attention: ms doesn't read ms. looks weird? well, it's weird. sometimes, the things that are written in there don't match with WU and you only will realize that by doing an clean install. so yes, from times to times, you have to check the entire script by doing an clean install
> knows what files to download from where?
from the script. in here there's the releases link. if you follow some .script files, you will see the list of download locations
> "master list"
well, that has to be done. one way to know the updates that are required for an OS is do an clean install, with just the latest SP and check the updates at WU. after that, of course, you will require check for WU mistakes...
well, time to work again. i had an client call
[]s
_def_x_
23 Jul 2009
@René Kabis...
excalibur and Cristiano pretty much summed it up but if I could I would like to add a few things.
Yes, this is the "releases.list" file, AutoPatcher's list of available packages - "xp_sp3_x86", "vista_sp2_x86" etc. This could be looked at as AutoPatcher's
Master List of available releases.
Yes, APUP will download the "script" based on your selection - "xp_sp3_x86.script", "vista_sp2_x86.script", and of course you want to develop further
"xp_sp2_x64_beta.script".
If I could, I would like to get you to refer to this as simply the "xp_sp2_x64_beta" release or script. Master Package sounds confusing, you want to develop
the XP x64 script further that's all. Also, you don't need to reinvent the wheel here, the xp_sp2_x64_beta.script is about 90% good to go, all you need to do
is go back about March 2009 and systematically and carefully add new updates and remove old ones, and test as you go.
Cristiano pointed out the TechNet Security Bulletins are a good way to get going - here's the Security Bulletin Summaries - I would start at March 2009 and
compare the additions / subtractions from the script, and carefully add and remove updates - this is where most of the work on releases takes place.
Please learn how these programs differ and how each works in the context of downloading a release, updating a release, installing updates, what errors are
produced by what program and so on. As an example, if you create an "apm" file and the detections need some help, we will be talking about AutoPatcher,
not APUP. If you edit your script and a hash fails we will be talking in terms of "downloading" which means we are discussing APUP.
No, not at all, in fact I would refer to an "apm" file as the mediator between AutoPatcher and the "executable", you get the details wrong in your apm files your
release will be plagued with problems to say the least. If I was in your shoes, I would carefully look at a release, study the script and look at the details within
various "apm" files - paying close attention to all the dependencies, some updates will have more others less, you will need to learn this from the details given
in the extracted contents of the update and from details given at the update security bulletin summary.
Here's an example - MS09-026 (KB970238)
Scroll down to - Affected Software - look for Operating System (for the link to the update) - Bulletins Replaced by this Update (updates replaced),
also Security Update Deployment (a few details are available here as well).
These few tools can help you assemble a working script that can be developed even more with input from the user base, and you can compare your
list with what WU recommends - you may find you need 1 or 2 more updates but you will be close.
The key will be organization - I would work in an orderly fashion, systematically working from one patch month to the next until you reach July 2009 - this
will be good experience and you could easily have the script pretty well updated in a few weeks - here's what I mean...
The script is about 4 or 5 updates "Patch Tuesdays" behind so I would take each one every few days and add and remove as needed. I do believe that the
script was updated for March -> Added 2 / Removed 2, but April 2009 was big and I think there were 7 additions and at least 4 removals for XP SP2 x64,
and the regularly updated (~) MRT.
Note: Like I said, I think the script was updated for March 2009 Patch Tuesday, I would double-check. The editing should start from April 2009
forward until you complete the "Additions (+) / Subtractions (-) / Updates (~)" for July 2009 Patch Tuesday.
excalibur and Cristiano pretty much summed it up but if I could I would like to add a few things.
Quote
When APUP starts up, it obviously grabs the latest list of packages available.
Master List of available releases.
Quote
From this, it knows to download updates directly from Microsoft, based on which package is selected
"xp_sp2_x64_beta.script".
Quote
So how do I go around creating a "master package list" for XP 64-bit
the XP x64 script further that's all. Also, you don't need to reinvent the wheel here, the xp_sp2_x64_beta.script is about 90% good to go, all you need to do
is go back about March 2009 and systematically and carefully add new updates and remove old ones, and test as you go.
Cristiano pointed out the TechNet Security Bulletins are a good way to get going - here's the Security Bulletin Summaries - I would start at March 2009 and
compare the additions / subtractions from the script, and carefully add and remove updates - this is where most of the work on releases takes place.
Quote
APUP.EXE - This is to download the updates from Microsoft/Adobe/Sun etc...
AUTOPATCHER.EXE - This is to install the updates/addons/tweaks etc to your computer.
AUTOPATCHER.EXE - This is to install the updates/addons/tweaks etc to your computer.
produced by what program and so on. As an example, if you create an "apm" file and the detections need some help, we will be talking about AutoPatcher,
not APUP. If you edit your script and a hash fails we will be talking in terms of "downloading" which means we are discussing APUP.
Quote
It appears that the *.apm files are just "extra information" files
release will be plagued with problems to say the least. If I was in your shoes, I would carefully look at a release, study the script and look at the details within
various "apm" files - paying close attention to all the dependencies, some updates will have more others less, you will need to learn this from the details given
in the extracted contents of the update and from details given at the update security bulletin summary.
Here's an example - MS09-026 (KB970238)
Scroll down to - Affected Software - look for Operating System (for the link to the update) - Bulletins Replaced by this Update (updates replaced),
also Security Update Deployment (a few details are available here as well).
These few tools can help you assemble a working script that can be developed even more with input from the user base, and you can compare your
list with what WU recommends - you may find you need 1 or 2 more updates but you will be close.
The key will be organization - I would work in an orderly fashion, systematically working from one patch month to the next until you reach July 2009 - this
will be good experience and you could easily have the script pretty well updated in a few weeks - here's what I mean...
The script is about 4 or 5 updates "Patch Tuesdays" behind so I would take each one every few days and add and remove as needed. I do believe that the
script was updated for March -> Added 2 / Removed 2, but April 2009 was big and I think there were 7 additions and at least 4 removals for XP SP2 x64,
and the regularly updated (~) MRT.
Note: Like I said, I think the script was updated for March 2009 Patch Tuesday, I would double-check. The editing should start from April 2009
forward until you complete the "Additions (+) / Subtractions (-) / Updates (~)" for July 2009 Patch Tuesday.
Guest_Dapxin_* 26 Aug 2009
Does anyone know where I may download the last release of XP x64 autopatcher pack? thx.
ViroMan
29 Nov 2011
Since I have windows XP x64 and I am considering a reinstall soon I MIGHT update the current beta script file to be current.
DesertJerry
29 Nov 2011
I have XP Pro x64 w/SP2 installed here so if/when you do an update I can check it here to see if I have any issues. I have not reported any for a while because I knew there was no one keeping things up to date.
ViroMan
30 Nov 2011
hmm... does it matter if you slipstream sp2 into your XP sp0 disk and make a new disk? Some people say its still better to install with the disk then put sp2 in. Although that takes 10x as long to do but, less issues like missing files and so on.
DesertJerry
01 Dec 2011
I really can't answer your question about SP0 versus SP2. It's been a couple of years since I received XP Pro x64 and soon after I started using it I slipstreamed SP2 into the original CD and burned a new XP Pro x64 w/SP2 CD - which I have used as the primary source whenever I deem it necessary to use the RyanVM Integrator, an update pack, and addons to create a 'new' CD.
ViroMan
02 Dec 2011
Ahh so no problems then. I already created a disk with sp2 on it when I posted that, I just was wondering if it would effect anything. I already installed with it, although I must say, the installation took 2.5x longer to do then a SP0 install even though the ISO size only increased by 20mb.


