AutoPatcher XP/2003 x64 Hotfix Depot
#21
Posted 09 July 2009 - 02:01 AM
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
#22
Posted 09 July 2009 - 07:06 AM
Edited by johnspack, 09 July 2009 - 07:08 AM.
#23
Posted 09 July 2009 - 10:43 AM
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:
that is sell in here."
johnspack said:
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
#24
Posted 09 July 2009 - 11:14 AM
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
#25
Posted 10 July 2009 - 04:42 AM
#26
Posted 10 July 2009 - 07:14 AM
#27
Posted 11 July 2009 - 08:16 AM
johnspack, on Jul 9 2009, 11:14 PM, said:
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).
#28
Posted 11 July 2009 - 01:31 PM
Quote
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.
#29
Posted 17 July 2009 - 11:51 PM
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.
#30
Posted 18 July 2009 - 01:01 AM
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
#31
Posted 22 July 2009 - 10:28 PM
Cristiano, on Jul 17 2009, 05:01 PM, said:
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.
#32
Posted 22 July 2009 - 11:21 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.
#33
Posted 22 July 2009 - 11:24 PM
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
#34
Posted 23 July 2009 - 02:33 AM
excalibur and Cristiano pretty much summed it up but if I could I would like to add a few things.
Quote
Master List of available releases.
Quote
"xp_sp2_x64_beta.script".
Quote
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
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
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.
#35 Guest_Dapxin_*
Posted 26 August 2009 - 11:21 AM
#36
Posted 29 November 2011 - 12:12 AM
#37
Posted 29 November 2011 - 10:16 PM
#38
Posted 30 November 2011 - 11:47 AM
#39
Posted 01 December 2011 - 06:05 AM
#40
Posted 02 December 2011 - 01:57 AM
3 user(s) are reading this topic
0 members, 3 guests, 0 anonymous users












