9 replies to this topic

[BenGman]

I am very disappointed in this autopatcher version (I used to use the discrete files in the 2007 Core and Update releases).

I am a system builder/repairer so I regularly use all the windows operating systems so I used APUP 1.0.5 to download all the English updates (X86, X64 for Win2K, WinXP and Vista, Office, DirectX, etc).

When I run autopatcher.exe (from the fileserver) on my target systems (Windows 2000, XP or Vista) ALL the modules load and ALL of them verify before I get to select the options.

I do not understand why Windows Vista modules have to load on a Windows 2000 machine and vice versa.. and even the X64 versions on the X86 machines. Then after ALL the modules load they still have to VERIFY - several times in a day!! And to top that autopatcher usually crashes.

Right now it is best to just go directly to the Windows Update site to download updates on each machine.. it is actually 1/5 the time for me compared to AP 1.0.5.

I actually tried this version of autopatcher on a Windows 2000 X86 system with OfficeXP .. then quit it because it was still verifying releases after 2 hours. Then I tried a Windows XP Offiice 2003 x86 system that took 1 hour to reach the selection page, but then crashed only after 10 modules were installed.

Finally I am using a Windows Vista X64 laptop with Office 2007 and I see that Windows 2000 modules are loading.. XP modules loading.. x86 modules...Office XP modules... and its been 50 minutes and its still in "Verifying release integrity... Office 2003SP3-KP923618........"

Please fix this!

Edited by BenGman, 16 September 2008 - 08:38 PM.

[Cristiano]

> I do not understand why Windows Vista modules have to load on a Windows 2000 machine and vice versa..
me too. but they aren't loaded, they are just checking integrity, like you can see at "Verifying release integrity". but how you believe that we can check integrity and grant security, if we can't check every single file to learn if they aren't tempered? you already tried split them into separated folders? one for 2k, one for xp, another one for vista? this us to work, allowing you have all versions like "official" and loading a lot faster. but to clear your understanding, autopatcher checks every single module to learn if those are tempered or not. by doing that, you see that "official" in right corner of the screen. if you don't wish check modules, you may just delete the .rti files, then autopatcher will load a lot faster, but you will see an "unofficial" in right corner of the screen

> Please fix this!
in order to grand integrity and security, all modules need to be checked by md5. by doing this way, we may be 100% sure that your downloads aren't corrupted. unfortunelly, this can be an very slow task in some systems. even more, according to the number of modules. believe me, there's no an faster way to do that checks. the only one way to do this in a faster way is just not to do (by removing the .rti files before run autopatcher, and dealing with an "unofficial") or split that into several folders. just think: do you really need that updates for vista be in the same folder that windows 2k or xp? just try that once and you will see the difference

[]s

[BenGman]

Suggestions:
1. Autopatcher can automatically check to see the host OS and architecture before it loads and verifies modules OR

2. Offer the user radio boxes to check off downloaded modules and what it wants the user to update based on what has been downloaded (or offer to download what is missing based on user selections):

3. Also offer a scripting option for advanced users to configure for silent/uninterrupted install of updates.

E.g.
(a) Select Operating System
O Windows 2000 O Windows XP O Windows Vista

( Select Architecture
O x86 O x64

© Do you want to verify releases?
O Yes O No

(d) Office Versions (check boxes for mulitple)
[ ] Office XP [ ] Office 2003 [ ] Office 2007

(e) Do you want to install/update add-ons?
O Yes O No
If yes, possibly load all the options or have select options for those groups.

All the above options is done BEFORE modules are loaded and verified if the user wants them verified.


Maybe as well my above suggestions may be bordering on why Microsoft asked to stop the project in its previous form, but now the system is changed to have users download directly from Microsoft.

I know that this is asking a lot for a not for profit project, and for this I am willing to be more involved in this project.

Thanks for your reply!

Cristiano, on Sep 16 2008, 05:22 PM, said:

> I do not understand why Windows Vista modules have to load on a Windows 2000 machine and vice versa..
me too. but they aren't loaded, they are just checking integrity, like you can see at "Verifying release integrity". but how you believe that we can check integrity and grant security, if we can't check every single file to learn if they aren't tempered? you already tried split them into separated folders? one for 2k, one for xp, another one for vista? this us to work, allowing you have all versions like "official" and loading a lot faster. but to clear your understanding, autopatcher checks every single module to learn if those are tempered or not. by doing that, you see that "official" in right corner of the screen. if you don't wish check modules, you may just delete the .rti files, then autopatcher will load a lot faster, but you will see an "unofficial" in right corner of the screen

> Please fix this!
in order to grand integrity and security, all modules need to be checked by md5. by doing this way, we may be 100% sure that your downloads aren't corrupted. unfortunelly, this can be an very slow task in some systems. even more, according to the number of modules. believe me, there's no an faster way to do that checks. the only one way to do this in a faster way is just not to do (by removing the .rti files before run autopatcher, and dealing with an "unofficial") or split that into several folders. just think: do you really need that updates for vista be in the same folder that windows 2k or xp? just try that once and you will see the difference

[]s

[BenGman]

Cristiano, on Sep 16 2008, 05:22 PM, said:

do you really need that updates for vista be in the same folder that windows 2k or xp?

I already broke up the OSes but I have to run different 'autopatcher.exe' files for the OS and then for the Add-ons/Office/DirectX group.

Having to only run one 'autopatcher.exe' for updating everything and keeping all together so the apup.exe just runs once to update should definitely be more convenient, without having to load/verify all the modules as well.

[Cristiano]

> can automatically check to see the host OS
in order to do that, autopatcher needs read each module, to learn if the module is for 2k, vista, etc. there's no way to autopatcher learns about an module without read it

> Offer the user radio boxes to check off downloaded modules
that will make no difference, since the issue is regarding the checks for integrity and, to learn if everything is ok, it needs read each module and compare with the infos stored in .rti files

> (a) Select Operating System
it does automatically

> Select Architecture
it does automatically

> Do you want to verify releases?
that could be an interesting feature, but that option shouldn't be loaded by default. it could be loaded like this: autopatcher.exe /nolicense . but if the user don't check the module, an "unofficial" tag should be there. do you have any idea about how many people could be concerned about that "unofficial" tag?

> why Microsoft asked to stop the project in its previous form
they said that the files could be some virus or something and they was afraid about take the blame for that. well, not only ms, we too are concerned about that. your files could be damaged in some way, God knows what could happend if the files are infected/damaged. because of that, we do the checks that may do the load process takes more time. and we need do that, because you know who the people blame if they do something wrong and damage his own computers because of an virus or something

> BEFORE modules are loaded
how autopatcher suppose learn about this:
[OperatingSystem]
WindowsVersion=2K,XP_X86,2K3_X86

without read the module? do you know what is written in a book, word by word, without read it? autopatcher also can't do that. also i said, your main problem probably be the integrity checks, that can be avoided just by deleting the .rti files, but then autopatcher will becomes unofficial and this sort of thing. but the load becomes a lot faster. just also an sample:
my version, with integrity checks, loads in 27s. removing the .rti files, it takes 3s. booth tests done with autopatcher.exe /nolicense

but of course, it is loading in my local machine. the load from remote folders can take a lot more time, according to the load on network/server

> I already broke up the OSes but I have to run different 'autopatcher.exe' files for the OS and then for the Add-ons/Office/DirectX group
well, you may leave all together, but just try this first:
1 - remove the .rti files and try run it from your remote folder;
2 - leave the .rti files and try run it from your local machine;
3 - remove the .rti files and try run it from your local machine;

then, you will see what is doing your load process becomes so slow

[]s

[BenGman]

Cristiano, on Sep 16 2008, 09:23 PM, said:

> can automatically check to see the host OS
in order to do that, autopatcher needs read each module, to learn if the module is for 2k, vista, etc. there's no way to autopatcher learns about an module without read it

Bear with me.. I am learning about the inner workings as I make these posts..

I know that some updates are 'across the board' and apply to all OSes. I am watching the *.script files and the *.rti files... autopatcher seems to 'know' the names of the modules and divides them (many if not all) according to OS because there is a *.rti file for each OS. Does autopatcher load the entire module or determine the modules as listed in the *.rti file? If it just reads from the *.rti file (or wherever apup gets the information on which module is for where to create the *.rti file in the first place) why does it take minimum 10 minutes to do the "Loading..." before it starts "Verifying..." ?

excerpt from the autopatcher_2k_enu.script file

#Module Downloads								#
################################################################################
#

Item=AutoPatcher Critical 2K Modules

DetectFile=autopatcher:\modules\Critical\KB842773_2K_enu.apm
DetectHash=25137678000e4acab09b865a9b21481d
DetectFile=autopatcher:\modules\Critical\KB890830_x86_enu.apm
DetectHash=91C4B148B4D88FF3D8E34FDB936FEC9D
DetectFile=autopatcher:\modules\Critical\KB891861_2K_enu.apm

The above shows that the *.script file 'knows' that the following modules are part of the Windows 2000 Critical Modules I figure.

I have to run the apup/autopatcher.exe to see when exactly this script file was created (e.g. if it is created when autopatcher.exe runs). If so, there should be some flag in a config file so to know that these modules where already accessed to be in the Win2k group so it would not have to be set again when autopatcher is run from that computer again or another computer.

(some of the computers I tested on were slow, and some were quite fast. I am familiar with the HD speeds/network speeds of my fileserver/network to know they play a part in all this, but it only takes less than 5 minutes to transfer 2GB - the approx size of the AP english downloads - of files on my network)

Please explain what really happens in the "Loading.." stage.. or even how the *.rti/*.script files are created.

Edited by BenGman, 17 September 2008 - 01:58 AM.

[BenGman]

Cristiano, on Sep 16 2008, 09:23 PM, said:

1 - remove the .rti files and try run it from your remote folder;
2 - leave the .rti files and try run it from your local machine;
3 - remove the .rti files and try run it from your local machine;

then, you will see what is doing your load process becomes so slow.

I tried the above along with /nolicense and it did speed up the loading time.

I am still interested in the inner workings and having those options though!

Thanks!

[Cristiano]

> the names of the modules and divides them (many if not all) according to OS because there is a *.rti file for each OS
no. the .rti file be there or not have no change about this. there's one rti file to each release because you may not need all them. just that

> Does autopatcher load the entire module
autopatcher reads the module to look for [OperatingSystem] tag. if matches, it will load it later

> apup gets the information on which module is for where to create the *.rti file
apup doesn't create the .rti files, we do. then, we just set that .rti files to be downloaded from our server when the script runs, like any other update

> why does it take minimum 10 minutes to do the "Loading..." before it starts "Verifying..." ?
because of the amount of the files that are checked using infos stored in the .rti file. plus, hd speed, processor, etc has his share of guilt in that time too. besides of that, even if not checking each module, autopatcher need read the full patch, looking for the .apm files. this may take some time, according to the number of files or, in this case, modules. so, even if you remove the .rti files, the load will not start in 1s (unless you have an really fast computer)

> *.script file 'knows' that the following modules are part of the Windows 2000 Critical Modules I figure
yes, but the .script files aren't loaded by autopatcher. those files are for apup only. if i'm not mistaken, i've read some time ago that one new version of autopatcher was borning, making apup.exe and autopatcher.exe the same thing. but i don't know when or if this will arrive some day

> 5 minutes to transfer 2GB
transfer isn't the same thing than open each file to read, you know. read operations us to take a lot more time than just copy

> "Loading.." stage.. or even how the *.rti/*.script files are created.
i believe that i already did it, but in loading process, autopatcher will look into subfolders looking for .apm files, read each one found, compare the file found with the fingerprint stored in the .rti file, do the same thing to each .exe and other files listed in .rti file, read the .apm file to learn if the files need to be loaded into your system, read the translation interface to your system, then prepare every single module in proper install order, create the module tree and then it's finished.

basically, this are fast tasks, except for the part of " compare the file found with the fingerprint stored in the .rti file, do the same thing to each .exe and other files listed in .rti file", that takes a lot more time than the other tasks to execute

about the .rti files, we do that, not apup and not autopatcher.exe. after make an release, we run a tool to read the fingerprint of each file found in subfolders and store it in an .rti file. that isn't really needed by autopatcher, except for check integrity

about the .script files, since ms bore us, we can't offer their updates from our own computers/servers. they say that it must come only from their servers. so, in order to do that, a lot of tasks need be performed, a lot of files need to be downloaded, like an download manager does. so, in that .script file, you found download locations for each update and each module. in order to save time in future updates, it also checks each file to see if the module needs to be updated. if so, it will download it again. in that file, you also found instructions to remove obsolete things, so, the user don't need remove manually any module. but after download, this file is useless. in apup 1.05, you will not see the current file anymore, since this file will be stored in a temp folder, that will be removed after apup finish his task or be closed

[]s

edit: sorry about the time that i'm taking to answer. i'm with an broken bone in my right arm, so, i'm taking more time to type. besides, i need think before i type and also think something about the translation (i speak brazilian portuguese...)

[James]

Hi BenGman

Just to clarify one of the points that Cristiano has explained:

AutoPatcher and the forum hosting then being used (Neowin.Net) were served with a C&D (Cease and Desist) order by Microsoft's lawyers. Microsoft maintain the exclusive right to distribute updates and so the old form of AutoPatcher, which included all the updates, ceased in August 2007.

That is why APUP was born and why all updates are now downloaded direct from Microsoft's servers to your own computer by APUP, before you run AutoPatcher.

Secondly, I am concerned about the very very long times that AutoPatcher is taking on your system. In my experience this points to a network problem as well. In my tests, I have had to update the NIC (Network Interface Card) drivers for Windows 2000, before running AutoPatcher. The changes were truly remarkable - from 8 hours (or more -- estimated) to 3 minutes.

Also:

BenGman, on Sep 16 2008, 09:31 PM, said:

I am a system builder/repairer ...

I do this too.

Even when restoring very old hardware (Pentium III based) AutoPatcher takes only a minute or so to load and verify. For this, I use a patch tree which includes Windows 2000 only.

--

[James]

I, for one, am pleased you want to become more involved. Many of your questions about how AutoPatcher works can be answered by downloading the documentation to be found here: AutoPatcher 5.6 Documentation
You will find AutoPatcher Documentation - APM Format.html (v2.1.1) to be most useful.

--