File version check

[check-user]

Hi folks,

I suppose that a lot of you have heard of Gurgelmeyer's Hotstream/USP5 project. In short, Gurgelmeyer collected hundreds (more than 400) official Microsoft hotfixes and patches for Windows 2000. He collected those patches and developed a method to safely slipstream then into Windows 2000 like an official Service pack.

Since Gurgelmeyer - who unfortunately has not been seen for a year now - spent a lot of time and diligence in this pack, it is still worth keeping it as a base on which the newer updates (from Feb. 2006 on) can be applied.

This sounds great but recently I discovered a major problem:

Apparently Microsoft themselves do not know about their own development progress. Obviously Gurgelmeyer had access to patches and fixes - of course only official Microsoft files - which are not known by some of their developers

Why is this a problem? Because newer fixes (I count about 40 to be added on top of USP5) contain files which are in fact outdated, compared with those already included in USP5!

According to my testings, Hfslip does overwrite those USP5 files with the older versions from added hotfixes. I had a look at a few of those hotfixes and they sometimes contain only a few newer files but old versions as well.

The only possible solution is that Hfslip checks the fileversion (Build-number) and compares it if there are different versions of the same file. This requires the cab-packed files of the USP5 to be unpacked first. Because Gurgelmeyer has not been seen for a long time it seems to be unlikely that he might return and update his USP5 - only Gurgelmeyer can do this because he has developed the necessary tools.

[Tomcat76]

I see your point, but it may be difficult to work around it because HFSLIP is slipstreaming USP5 like a Service Pack. Also, HFSLIP generally assumes that a source (with or without Service Pack) contains files that may be overwritten so there is no date check performed when copying hotfix binaries into the new source. This is OK for regular Service Packs because hotfixes are always made for a certain Service Pack level. But, as you noticed, this is not OK for USP5 because it contains unofficial hotfixes too.

For the file dates to be taken into account, HFSLIP would have to treat USP5 as a giant hotfix. I'll have to see if that is at all possible. However, I think most people won't like the thought of HFSLIP treating it as a hotfix because then it would need to be done every time you run HFSLIP which kind of defeats the purpose of USP5. It would've been better if Gurgelmeyer separated the non-official hotfixes into a separate package, or made two versions of USP5...

[check-user]

I see your point, but it may be difficult to work around it because HFSLIP is slipstreaming USP5 like a Service Pack. Also, HFSLIP generally assumes that a source (with or without Service Pack) contains files that may be overwritten so there is no date check performed when copying hotfix binaries into the new source. This is OK for regular Service Packs because hotfixes are always made for a certain Service Pack level. But, as you noticed, this is not OK for USP5 because it contains unofficial hotfixes too.

For the file dates to be taken into account, HFSLIP would have to treat USP5 as a giant hotfix. I'll have to see if that is at all possible. However, I think most people won't like the thought of HFSLIP treating it as a hotfix because then it would need to be done every time you run HFSLIP which kind of defeats the purpose of USP5. It would've been better if Gurgelmeyer separated the non-official hotfixes into a separate package, or made two versions of USP5...

As you pointed out correctly, we need some kind of special treatment for USP5. An idea might be to slipstream USP5 as a normal service pack (not to treat it as a giant hotfix) but include the filelist of USP5 in HFslip and countercheck every hotfixes' file with it.

But you see, this is a real problem. At first I thought it is not but on closer inspection, nearly every new hotfix contains outdated files. This means that with every new patch integrated we destroy some of Gurgelmeyer's work because unofficial but newer files are overwritten.

[check-user]

Any chance to see a solution soon?

[jimmsta]

Why not download all those new hotfixes, and compare the file versions, then create a new topic (or add to one of the stickies) a list of hotfixes that are 'safe' to use on USP5?

On the same subject, I'm thinking that if I can figure out what Gurgelmeyer did, I'd be happy to try my hand at updating the USP.

[Tomcat76]

Any chance to see a solution soon?

I don't think you'll see one any time soon. I want to fix the problems caused by having a hyphen in the HFSLIP folder path first.

[fdv]

Maybe everyone knows this, and if so, sorry.

All of those updated files in the USP5 that get overwritten by hotfixes are non-regression tested and only available for download by folks having specific issues.

For example. The USP5 has newer USB files that are not in hotfixes. These are special files only for people who had problems with USB devices. Are these files better? Probably, and MS devs do know about them. MS just won't issue them officially because they don't want to test them since they were modified only to deal with specific issues that only some users had.

Now multiple this by all of those new files. Part of Gurglemeyer's work was, us, "conning" Microsoft into giving him the download links to all of these 'special' files only intended for people in need of fixing specific issues. Again, are they better? Probably. It's not really possible to know. It was a great effort on his part getting them, but he had some health problems and is focusing on life away from the computer ;-) We wish him all the best but he kept his method closed-source. It can be duplicated, but he didn't leave his "notes," special MS-only tools*, and individual file collection behind.

We all wish him well. Unfortunately USP5 hits a dead-end due no one having access to his original material, and there's no real way around that.

* For example, he was known to use compression tools that MS did not release for public use.

[atolica]

* For example, he was known to use compression tools that MS did not release for public use.

Exactly. What tools does MS use to create MS cabs including folders and sub-folders with files in them? Sometimes I really need to create cab files and can't do because of the limitation of cabarc and makecab tools that are public.

Does anyone have an idea?

Edited March 5, 2009 by atolica

[fdv]

Sure. The main file you want is msimsp.exe, unfortunately only available to Windows Installer Developers in an SDK just for them. It also has a companion DLL, patchwiz.dll. That's what Gurgelmeyer used. I will bet you a can of Grape soda that you won't be able to find this, though.

[tommyp]

I'll take the Stewarts. Thanks.

[atolica]

I'll take the Crush. Thanks.

[James_A]

From the documentation:

To generate a patch package, it is recommended that you use a patch creation tool such as Msimsp.exe and Patchwiz.dll. Patchwiz.dll version 4.0 is compatible with packages and patches that were authored using earlier versions of the Patchwiz.dll.

I'll take the Welch's because I know I can get that round here...

[submix8c]

NEHI is good - beats the K-pop and if it's free (+ shipping and handling ) on the bet... Still available from MS (the Server SP1 is v3.1; the XP SP2 is v2). Heck, any one of them Purples is better!