Jump to content

PE Tool for creating patches


WildBill

Recommended Posts

I found that changing the IE version number to 6.0.2800.1106, in the registry locations above, allowed 2479628 to install correctly. Browseui.dll installed as expected. However, the icon glitches I mentioned above remain. :(

I know what ought to be done to get it to work with FDV fileset.

But I need to do some tests myself before uploading the fixed version ;)

That's great. :) But I guess my ongoing problems with 2479628, as a user of FDV's Fileset, should be posted in the HFSLIP forum. Why the fileset sets IE's version number as 6.0.2900.5512 I have no idea. At the moment I'm thinking that there is at least some problem with the fileset (or with my use of it), because I found that even my IE5-based HFSLIPped system has IE's version number in the registry as 6.0.2900.5512 (rather than 5.00.3700.1000 or 5.0.3862.1500).

Edited by bristols
Link to comment
Share on other sites


Well, I think I found out why HFSLIP does not slipstream the file when FDV fileset is used.

What I managed to do so far is:

1. By changing the checking mechanism it is possible to make the new browseui.dll being installed on a running Windows 2000 system regardless of the registry settings. It can be done by changing the update.inf settings to check .dll file versions instead of checking the registry.

2. Slipstreaming still does not work. Why? The problem here lies in the HFSLIP itself. This is the reason:

IF EXIST HFCABS\_IE6_HFSLIP.CAB SET VERSIONIE=2KIE6&SET IE6SLIP=PASS

IF EXIST FDVFILES\WIN2K SET VERSIONIE=FDV

IF "!VERSIONIE!"=="2KIE6" (
(...)
IF EXIST TEMP\xpsp2_binarydrop MOVE/Y TEMP\xpsp2_binarydrop\*.* TEMP >NUL

HFSLIP changes IE version to FDV and this is why files placed in xpsp2_binarydrop folder do not get copied. They get copied only when IE version says 2KIE6.

I can fix is easily but it would require to edit the HFSLIP .cmd file itself...

It also means that the IE6 version shlwapi.dll from KB900725 is not copied when using FDV fileset.

I believe there is a way to have it done but the problem needs to be approached from a totally different perspective :< I have something in mind but I'm not sure whether it will work. I want to avoid editing the HFSLIP source. What I can do now is to upload the updated version which can be installed (but not slipstreamed) in a system where FDV fileset was used.

Edited by tomasz86
Link to comment
Share on other sites

It'll be a very hard task to get everything to work by just changing the update (2479628) :}

The structure of the newest version (6a) is exactly the same as the official Microsoft's one used in 900725. HFSLIP and FDV fileset is the problem here, not the update.

Ideally, the one to be modified should not the update but rather HFSLIP and FDV fileset. But the reality is different :(

I'm trying doing my best to get it to work but I'm not sure if it's possible now.

Link to comment
Share on other sites

WildBill,

Some time ago you started to put *.map files in your unofficial updates.

The problem is that HFSLIP treats them exactly the same as all other files and SLIPSTREAM (copy) them into i386 folder. In order to avoid it, they have to be put in a different folder, ex.

H37mH.png

If would be nice if you could do it when making future updates :)

Edited by tomasz86
Link to comment
Share on other sites

We're back to the v4 time but it's probably the only way to get it work without any problems, including FDV fileset.

Windows2000-KB2479628-v7-IE5-x86-ENU.exe (3.12 MB)

Windows2000-KB2479628-v7-IE6-x86-ENU.exe (3.69 MB)

I also fixed the cosmetic issues, ie. moved *.map files to the separate folder so they are not copied by HFSLIP anymore and also added the additional tags (-v7-IEx) to the update name so they are easier to distinguish now.

HtXUa.png

Edited by tomasz86
Link to comment
Share on other sites

WildBill,

Some time ago you started to put *.map files in your unofficial updates.

The problem is that HFSLIP treats them exactly the same as all other files and SLIPSTREAM (copy) them into i386 folder. In order to avoid it, they have to be put in a different folder, ex.

H37mH.png

If would be nice if you could do it when making future updates :)

Sure, I can put them in separate folders. I include those to help anyone else who wants to patch those files.

Link to comment
Share on other sites

WildBill,

I have one suggestion for you :) It's just a cosmetic thing but still ;)

In strings section there is something like this (example taken from 2479628).

HelpLink = "http://support.microsoft.com?kbid=2479628"
URLInfoAbout = http://support.microsoft.com

How about changing the URLInfoAbout from MS to "

I did it for my HBR Mini Rollup:

HelpLink = "http://www.msfn.org/board/topic/151551-hbr-mini-rollup/"
URLInfoAbout = http://www.msfn.org/board/topic/151551-hbr-mini-rollup/

Edited by tomasz86
Link to comment
Share on other sites

I added a string to HFSLIP which solves the issue with FDV files and updates which use the xpsp2_binarydrop folder.

I'll make it it public after having done some more tests :)

Link to comment
Share on other sites

You all shouldn't use the so called "friendly names" for links expected to survive all IPB updates. Use instead the base form of the links:

http://www.msfn.org/board/index.php?showtopic=146529 
and
http://www.msfn.org/board/index.php?showtopic=151551

which work no matter what.

Link to comment
Share on other sites

I made a 2a version of KB981852. The changes I made are only cosmetic - the catalog file from 979683 was added so WU won't ask for it when 981852 is installed, and I also fixed the name to make it clear which version it is.

Actually the catalog from 979683 is present also in v2 but its name was changed to KB981852.cat. Now there are two catalogs inside - the original one from 981852 (XP version) and the one from 979683 :)

Windows2000-KB981852-v2a-x86-ENU.exe

A0pP5.pngRcK0k.png

@edit

I did the same thing to 2079403. The catalog file from 955069 was added.

Windows2000-KB2079403-v1a-x86-ENU.exe

@edit 2

And 982214. The catalog from 971468 added.

Windows2000-KB982214-v1a-x86-ENU.exe

Edited by tomasz86
Link to comment
Share on other sites

I did the same thing to these updates:

2124261 - added the catalog from 917537

2387149 - added the catalog from 924667

2360937 - added the catalog from 970238

2476687 - added the catalog from 978037 and moved WildBill's *.asm files to a different folder (so they won't be slipstreamed by HFSLIP)

2507618 - added the catalog from 980218 and moved WildBill's *.asm & *.map files to a different folder


Windows2000-KB2124261-v1a-x86-ENU.exe
Windows2000-KB2360937-v1a-x86-ENU.exe
Windows2000-KB2387149-v1a-x86-ENU.exe
Windows2000-KB2476687-v2a-x86-ENU.exe
Windows2000-KB2507618-v1a-x86-ENU.exe

I also got a new (well, used but still) monitor so comparing two update.infs in WinMerge is much easier now than before on an old 17' CRT 1024x768 ;) The current one is still a CRT but a 22' one with a diamontron tube :)

Edited by tomasz86
Link to comment
Share on other sites

v8 of 2479628 is ready:

Windows2000-KB2479628-v8-x86-ENU.exe

Changelog:

- added the catalog from 923191 (as 2479628 replaces 2296011 which supersedes 923191)

- suitable for both IE5- and IE6-based systems*

- fixed compatibility with FDV fileset**

* requires the newest beta (J v5) of HFSLIP (available to download at Mim0's site) when using with FDV fileset (thanks Mim0 for applying the fixes)

** IE6 files are slipstreamed correctly when using FDV & IE6 and also can be installed manually in a system which used FDV fileset (thanks BlackWingCat because I learnt how to do it by analising your KB989898)

Edited by tomasz86
Link to comment
Share on other sites

Wow, you've been really busy. Sorry I haven't updated the master list -- would an admin mind doing it if I can't get to it? I've been trying to port MS11-020, and every time I think I have it I have to pull something else in from XP -- first it was srv.sys, then i found I needed matching security features from srvsvc.dll (from KB2345886), but those require CancelIPChangeNotify() which means upgrading iphlpapi.dll, and *that* means upgrading tcpip.sys to add support for the function (and then there's more stuff to add that srvsvc.dll needs). By the time I'm done this will wind up being a micro service pack.

Edited by WildBill
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...