PE Tool for creating patches WildBill's post-EOL patches for Windows 2000 are here.
Posted 23 October 2011 - 12:55 AM
This post has been edited by tomasz86: 23 October 2011 - 12:56 AM
Posted 23 October 2011 - 02:31 PM
This post has been edited by WildBill: 23 October 2011 - 02:32 PM
Posted 23 October 2011 - 07:48 PM
Rather than spend more time trying to analyze this, I'm willing to risk implying what may be a stupid question here (because you presumably can answer it off the top of your head). Please forgive me if I should have posed it somewhere else
Posted 23 October 2011 - 09:11 PM
It fixes the MS10-046 security vulnerability relating to LNK files.
Thanks for the speedy response. I understand what 2286198 does, it's just not clear to me that this also addresses what 967715 fixes (i.e., that the assertion that the former supersedes the latter is correct: that assertion appears in bristols' Win2K SP4 update list, so - as I said - forgive me if this is not the right place to ask about it).
Posted 23 October 2011 - 11:02 PM
Unfortunately there's no difference with c5i
2286198 does supersede 967715. If you look at the file version of Shell32.dll, you'll see that the one from 967715 is 5.0.3900.7155 and the one from 2286198 is 5.0.3900.7158. Basically newer versions are based on older ones so the changes done to Shell32.dll by 967715 are also present in 2286198. Now, file version is not everything. There are also changes done to the registry. If you check update.inf files of both of these updates it'll be clear that they both add the same things to the registry.
However, you do have the point here because indeed there are two mistakes on bristols' page.
1. 967715 is superseded by 2286198. <- Correct.
2286198 is said to be superseded by 2479628 so 2479628 should supersede both 967715 & 2286198. <- False
Actually the current version of 2479628 does not supersede 2286198. The shell32.dll file is newer but the registry changes added in both 967715 & 2286198 are not present in 2479628! I prepared a corrected version of it.
Now it really supersedes 967715 & 2286198.
2. 2079403 is said to supersede 955069. In reality it does not. The problem is the same as above - the registry changes done by 955069 are not present in 2079403.
Here is a fixed version:
I prepared also an another additional update:
MS10-005: Vulnerability in Microsoft Paint could allow remote code execution
- mspaint.exe 5.1.2600.5918
I have decided to add -UU- for "Unofficial Updates" and "-HBR-" for hotfixes (by request) to filenames from now on so it should be much easier to know what kind of an update it is.
I hope everything is clear now
I've changed the filename of KB978706 to KB978706-v2 in order to distinguish it from the original KB978706. You must not use both official KB978706 and unofficial KB978706-v2 when slipstreaming in HFSLIP because the newer paint.exe won't be copied in such a case.
This post has been edited by tomasz86: 24 October 2011 - 02:54 AM
Posted 23 October 2011 - 11:45 PM
It surprised me that 2286198 was itself superseded without any mention in its own slot - perhaps because it (and similarly 2296011 and two other unofficial updates that apparently didn't supersede earlier official updates) was superseded only by an IE-specific update rather than by a system update. Just tracking what replaces what must be non-trivial, and since it shouldn't do any harm to apply earlier updates unnecessarily I guess the only real reason to try to avoid that may be the size limitations of a CD (though perhaps not even that, given how the CD is likely created).
Edit: I've wondered whether the HFSLIP command file keyed off alphabetical order to make sure that newer files in SOURCESS weren't overwritten by older ones, but I guess your new naming conventions make it clear that it doesn't.
This post has been edited by billtodd: 23 October 2011 - 11:51 PM
Posted 24 October 2011 - 12:46 AM
Actually it may cause problems (in some cases) if you have both newer and superseded updates in HF folder. As for newer files, there are no problems because HFSLIP always slipstreams only the newest ones (=newest by their date, not version) but it may be problematic when both updates change the same registry entries. In such a case the newer one must be processed after the older. That's why I add the "z" after KB in KB2* to ensure that they are listed after the older ones starting with KB8* or KB9*.
I used to keep both superseded official updates and newer unofficial ones in my HF folder but recently I've removed all the superseded ones to prevent any potential errors from happening. Actually I have two separate HFSLIP folders now - one with official updates only and the other one with unofficial ones included (and superseded official updates removed). Thanks to that I can easily check and compare them anytime I want.
This post has been edited by tomasz86: 24 October 2011 - 01:02 AM
Posted 26 October 2011 - 11:30 AM
2511455 is said to supersede 980232 but it does not because there's no rdbss.sys in it. If you slipstream 2511455 and don't include 980232 at the same time, you'll get a BSOD during Windows setup.
I prepared a fixed version where I added the rdbss.sys from 980232:
Posted 26 October 2011 - 08:04 PM
Of course you can use both 980232 & 2511455. It's just (in my opinion) that the fewer updates, the better
Posted 27 October 2011 - 01:36 PM
Uxtheme.dll seems to cause problems with .NET Framework based applications. I tried both versions - one from OldCigarette and the other one from BlackWingCat but unfortunately it's always the same. There's an error when trying to launch .NET based programs.
Posted 28 October 2011 - 12:17 PM
Windows2000-UU-MSRDP7-x86-ENU.exe <- MS Remote Desktop 7.0 (quite experimental but works)
Windows2000-UU-WIC-x86-Global.exe <- Windows Imaging Component (WIC)
Both of them rely on DLLs coming from either BlackWingCat's KDW or directly from Windows XP.
I'd also like to add one important information. Starting from this moment I'm going to test updates only in a system with (at least) BlackWingCat's kernel v5 installed. They may work without the kernel but don't have to. I'm sorry to say it but I just haven't got the time to test them in a configuration without unofficial kernel installed
The kernel is also required for applications written in Visual Studio 2010 so I think using it is just inevitable.
This post has been edited by tomasz86: 28 October 2011 - 12:23 PM
Posted 29 October 2011 - 11:40 PM
This is modified version of OnePiece's .NET 3.5 True AddOn for XP/2K3. I fixed the dependencies to make it work smoothly in Windows 2000. The files used to fix them come either from BlackWingCat's KDW or directly from Windows XP. You must install OnePiece's .NET 2.0 True AddOn together with one!! When slipstreaming in HFSLIP, both of them should go to HFAAO folder.
This post has been edited by tomasz86: 29 October 2011 - 11:41 PM