We're slowly recovering from the shock. Two things are apparent to us at this point:

  1. Microsoft won't re-evaluate.
  2. Those who use AutoPatcher, love it.

Allow me to use this opportunity to do a little brainstorming. It will be a long post, but it might give you some insight or even food for thought...

I have been hearing quite a few concerns about this being connected to WGA. Let me try to explain some things:

AutoPatcher uses administrative (a.k.a. network install) updates. This way AutoPatcher is portable (like the administrative updates) while being fast and friendly (like Windows Update). The nature of these updates is that you only need to download them once, and then deploy them to any number of systems. As you probably know, some downloads are only available after validation (WGA). The validation, however, was only done on the system where the update is downloaded -- not the one where it is installed. This holds true to this day.

Back in August 2005, I had stated that administrative updates had effectively become a circumvention method of WGA, by Microsoft's WGA itself!. I also wondered, at the time, why they didn't just add the WGA check on the updates' installation routine. In my eyes, they created a big mess on the download site, the made downloading painful and above all, totally incompatible with everything. Had they added the WGA check in the installation routine, they would have certain (to my eyes important) advantages -- namely: 1. The download center would still be clean and compatible 2. The WGA check would be done on each and every machine it was installed on. (I'll talk about this a little more)

The fundamental problem about the validation process is that it is not so much an algorithmic function. It's not something a computer can do on it's own. It's web-based. If the system has no Internet connection, the check just won't be done. This has it's share of advantages, but it is probably one of the reasons why Microsoft chose to do this the way we see it today. Forcing a check on the download page makes for 1 check. Forcing a check on the installation routine could make for 1000s. But since it can only be online, those could even be 0 (if none of the systems are online). So the right question is why didn't they implement the WGA check on both [the download process and the installation routine].

That is of course if WGA was meant to be a 100% solution. However, as Microsoft has said, WGA was never intended to be a 100% solution against piracy and was merely an educational tool. Microsoft believes that a lot of those who own pirated Microsoft software are actually unaware of this fact.

Now let me address some other concerns I have heard over the past few days.

It seems Microsoft's concern is a security one. And I have read comments from people who believe that Microsoft did well to put an end to this, because they just don't trust AutoPatcher.

Fair enough. It's is a little funny however, that they take sides when they have never used or even seen AutoPatcher. And I can't help to wonder if they are just some kids who think they know everything, hoping to grow up as self-proclaimed administrators of some sort.

In any case, AutoPatcher has had its own security features for years now. You should keep in mind that we are above all, users. We hate malicious software just as much as everyone here does. AutoPatcher has been a hobby for us. Not a job. We never relied on AutoPatcher for income. We have had our share of offers from companies who seek to bundle their dodgy software in freeware utilities. We have always ignored these. Not only have we kept a good name for almost four years (which is obviously because we used Microsoft's original patches and never did any hacks on them) but we have done our very best to ensure that nobody else can use our monthly releases to spread their own malicious software. We are proud to say that we have kept a clean sheet :)

AutoPatcher's "target-group" (I hate marketing, so excuse the term) is rather interesting. Though I have seen it be used by ordinary people, I believe the real value can only be seen when used by techies or real-life administrators.

You see, I have been the "techie" for years and friends regularly called in with all kinds of problems. Frequently I had to go over and clean up their PCs and download updates. Only problem was, they had a 56k connection.

AutoPatcher was started around the time of the so called Blaster worm. It was actually quite a shocking point in the history of the Windows platform. Any Windows XP computer connected to the Internet was almost-instantaneously infected and required an update. Trouble was, how we you to get this update when connecting your computer to the Internet would trigger a nasty restart count-down? Yes, those who knew the where-abouts knew they could abort the restart sequence, but that's not something that the average Joe knows.

Right now my biggest concern is that people around the globe will start writing their own custom modules and start redistributing their own releases. AutoPatcher will automatically flag them as unofficial (one of the security features). But if we were to stop AutoPatcher, there would only be unofficial releases. And if end users can only choose between unofficial releases, it is very easy for one of them to actually spread malicious software.

The truth of the matter is, we don't want this to happen. And one easy way to stop that from happening, is to continue our work on AutoPatcher. Maybe not in its current shape and form, but still, we will be back soon (that much I guarantee).

I'd like to close this post with the following news:

  1. Lyndon Brown, a member of the AutoPatcher team for the past 2+ years will be starting college, so he will be leaving the team. Lyndon has played an important role in AutoPatcher by maintaining the releases for Windows XP, 2003 and 2000, as well as taking care of translation packs, documenation, site and server related issues and so much more. We wish him the best of luck. We will sure miss him!

  2. We will be working on a web-oriented solution which we hope will give use two great benefits: easier and more efficient upgrades and easier "all-in-one" creation. Since I'm in the middle of exams, I will probably start coding in about a week from today. Although we can't really provide an estimate on when the next AutoPatcher will be available, we will do our best to have everything ready (and above all Microsoft-free) just in time for an October release.

It was a long post, so if you read it, thank you for your time. We will appreciate your comments on this.

Best regards, Antonis Kaladis