Updater utility

[Kykc]

May be I post into inproper section, but I didn't find out where it will looks better than here

If you use WUD you may find useful my small utility called 'Updater'. It can install downloaded updates automatically, like original Windows Update (without user interaction). All you need to do is select folder with updates.. It's for case when you're not integrating updates but install them, of course. You can find it here

PS One thing that can upset you - Updater needs .NET 2.0. If so you can try nuhi small net runtimes..

[jcarle]

Does your updater detect updates that are already installed?

[Glenn9999]

Does your updater detect updates that are already installed?

(trying to keep any salesmanship out of this)

Since I tested it just now, I can answer that question. Seems the answer is No (it installed 3 patches that I could verify were already installed - verified by having it install the patches again a second time). Evidently, this person is using a similar method to the one I arrived upon when I wrote my patching program.

The problem I encountered in doing many things I wanted to do with the patches is that there's really no uniformity present in the way Microsoft presents their updates. This is one of them.

1) To be able to detect updates that are already installed in the list, a foolproof way to identify the KB number would be a requirement. You could parse it out of the file name, but given #2, I had reservations in whether the patches would have a uniform name that would always have a KB # in it. If I have a KB #, given in a reasonably reliable way I could feel comfortable with (i.e. not easily renamed out), I would know how to detect updates that are already installed, and would have already put it into the program.

2) As I mentioned in the accompanying documentation, there are certain updates where Microsoft uses what could be referred to as a non-uniform convention for running the patches silently. The patches listed within the documentation are great examples - they either use unique parms everything else doesn't use, or they do not accept parms at all.

3) Then, there always the issue of telling the difference between updates and installs. My program will identify WMP 11, IE7, and Service Pack 2 as something that it can run. While it will run WMP 11 okay (I tested it), but will run IE7 and then the IE7 install will reboot itself. I haven't tried actually running Service Pack 2 with my program, but I'm not sure I want to try. In short, basically, it picks up things that could be run, but are best left to be run by themselves. Or again, could be run, but require unique command parms.

In short, the issue is really one of identifying and cataloging what the patches are when they are presented.

(salesmanship mode on)

I'm looking at working on this program again soon (1 and 2 are done, actually) to add a few things that have been nagging at me:

1) Changing how the wait code is handled on running the patches. Gives more CPU to the patches and will shave a few seconds off of big patch runs.

2) Give the option at the beginning if qchain isn't detected to bring up the file from Microsoft's site to download it. This works in IE, but not tested yet for FF, Opera, etc. The method I used should work for those, though.

3) Give the option in attended mode to be able to select the patches to install.

4) Shut down System Restore while the patch run is going, if it is on. I can do this in XP very easily, but not sure how to do it with Windows ME yet (mine looks to support more than just 2000/XP, etc)

[Kykc]

jcarle no but if You try to install already installed update, it wouldn't install anything.. When I try to install already installed update, setup runs, but shortly quits and there is no uninstall folder in my %windir%.. (as I have this update integrated..) But I think i can fix it in few days =) Thanks for suggestion =)

[jcarle]

I'd love to see if some people could get together and figure out exactly how updates could be detected. It's probably the most asked about feature request for WUD.

[Glenn9999]

I'd love to see if some people could get together and figure out exactly how updates could be detected. It's probably the most asked about feature request for WUD.

Perhaps the most fool-proof way to handle the issues I referred to earlier is what you're already doing with WUD (store information relating to specific patches for each OS, like reference KB#, MD5 of the file (to identify it), install parms, etc). I really didn't want to get into that much work in supporting my patching program, though. Honestly, that's the only way I could see to do it 100%. I ended up doing what was recommended in Microsoft's data when I wrote the program (query the extended file info), but found that they weren't even consistent with anything they've done. As a result, it's maybe 99% consistent, and maybe that's going to have to be enough.

As far as identifying whether patches have already been installed, that's easy enough, but again you need that reference KB # in order to identify it against data in the system that isn't routinely thrashed by anything (uninstall directories and logs get thrashed by CCleaner for example), and you can't get it from the file itself in any consistent way. Then, of course, Microsoft isn't even consistent themselves regarding this one.

Then, there's always the possibility of storing data on what patches you've already run, downloaded, etc, but that would sacrifice portability. Perhaps the thing that got it closest was AutoPatcher, and they did it by storing all the data relating to the patches in the install (along with the patches themselves of course).

I do have an idea I'm going to try out once I get those before-mentioned enhancements completed.

[beats]

I'd love to see if some people could get together and figure out exactly how updates could be detected. It's probably the most asked about feature request for WUD.

WU uses [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates] + file version checking.

[Kykc]

beats exactly. And detect updates via Registry is very simple, but with file versions.. It is hard to detect such updates.. Not hard, in fact, but it needs lot of stupid programming.. Different checks for every single update..

[Glenn9999]

WU uses [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates] + file version checking.

Rather it uses data downloaded from the WU servers, and then compares that data against things like this in the system.

[Nuno Brito]

Tried both versions you have available for download on your site and none started - both gave error.

nLite works ok on my machine and I thought .NET 2.0 was working well too.

If you're just starting out this app - please consider using another platform - very little advantages in using a heavy .NET since delphi, autoIt and Visual C produce very small and standalone exe's that work on both old and new machines well enough. (just an opinion thought)

Thanks for this app!

[Kykc]

Nuno Brito can You give me some information about this error? About platform.. Yeah, .NET is huge and heavy, its true.. But it is heaven of the programmer simplest way to write GUI and manage Win Registry, etc.. Maybe I must try CodeGear C++ (Borland C++ Builder in new box).. Thank You for your interest

Edited December 2, 2007 by Kykc

[jcarle]

Not to mention that .NET is PART of Vista and the basis for the future of Windows programming. Unless you want to code for another platform, .NET is here to stay and will only become more and more widespread as more and more software is developed on it. Microsoft themselves is starting to develop their own software on .NET.

[Nuno Brito]

Kykc, here's the error outputed - hope it helps:

EventType : clr20r3	 P1 : updater.exe	 P2 : 0.6.5.0	 P3 : 47501f56
P4 : updater	 P5 : 0.6.5.0	 P6 : 47501f56	 P7 : 24	 P8 : 13	 
P9 : system.nullreferenceexception

I've uninstalled your program, restarted the machine and installed fresh again - same result.

----------------------

I'm using a Windows XP Home Edition x86 Portuguese with SP2 on Dual Core CPU with 1Gb RAM machine

.NET on my machine

Framework 1.1

Framework 1.1 hotfix (KB928366)

Framework 1.1 Portuguese Language Pack

Framework 2.0

Other .NET apps are running correctly.

------------------------

On my humble opinion I'd say that .NET is the future of Windows Programming because it was declared as standard..

With other coding platforms this Updater app would still run on Win9x, XP, ReactOS and Vista without these issues/dependencies.

[Glenn9999]

Not to mention that .NET is PART of Vista and the basis for the future of Windows programming. Unless you want to code for another platform, .NET is here to stay and will only become more and more widespread as more and more software is developed on it. Microsoft themselves is starting to develop their own software on .NET.

Yep I'm reminded that Microsoft sets standards "because we say". And I really have seen nothing from anyone that indicates that they don't jump like lemmings at everything Microsoft does. .NET is a perfect example. It's bloated, runs 10x slower (or more), adds complexity to both application development and debugging, and not portable (a deal breaker in and of itself). While I have the option to get .NET compilers and do it that way and I tried one, I don't simply because I see absolutely no advantage or benefit to .NET in any way, shape, or form. This error that was presented is a perfect example - how does kykc debug it? As far as he/she knows, it could be a problem in code, or a problem in .NET, or a problem in the system itself (virus, malware), or DLL Hell (.NET brings that problem in spades).

Is it better because it truly is better, or because Microsoft says so?

[Kykc]

So, I give a try to Borland C++. Have a very different feelings about that.. Result is here. Fully portable, no need for .NET