[tomasz86]

First of all, without /SOS there's no normal boot screen. It's just a dark blue progress bar on a black background so I can't really say if it's 80% or 100% but still monitors goes off at the similar moment.

[WildBill]

Ah-ha. I think I found the reason why you weren't getting a boot screen with /SOS off. Also, I have a hunch as to why it' dying at 80%. Here's another test:

Windows2000-KB2393802-v1-early-c5i-x86-ENU.exe

[tomasz86]

The normal boot screen is back but the 80% problem persists. Interestingly, when /SOS is enabled the progress bar goes up to 100% but after that monitor goes off as usually.

This post has been edited by tomasz86: 23 October 2011 - 12:56 AM

[WildBill]

Almost there Here's another one that changes how it tries to load the bootskin image from disk to use a lot less stack space. Even if you have bootskins off it was still allocating a lot of stack space and maybe that was a problem.

Windows2000-KB2393802-v1-early-c5j-x86-ENU.exe

This post has been edited by WildBill: 23 October 2011 - 02:32 PM

[billtodd]

A cursory look at 2286198 as superseding 967715 leaves me wondering whether it really does (the latter dealing with autorun/autoplay functionality and the former not obviously having anything to do with that - nor apparently claiming to supersede any of the previous patches in that area).

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

Thanks,

- bill

[MacLover]

Billtodd -
It fixes the MS10-046 security vulnerability relating to LNK files.

[billtodd]

MacLover, on 23 October 2011 - 09:04 PM, said:

Billtodd -
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).

- bill

[tomasz86]

WildBill, on 23 October 2011 - 02:31 PM, said:

Almost there Here's another one that changes how it tries to load the bootskin image from disk to use a lot less stack space. Even if you have bootskins off it was still allocating a lot of stack space and maybe that was a problem.

Windows2000-KB2393802-v1-early-c5j-x86-ENU.exe

Unfortunately there's no difference with c5i



billtodd,

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.

Windows2000-UU-KBz2479628-v9-x86-ENU.exe

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:

Windows2000-UU-KBz2079403-v2-x86-Global.exe


I prepared also an another additional update:

MS10-005: Vulnerability in Microsoft Paint could allow remote code execution
Windows2000-UU-KB978706-v2-x86-ENU.exe
Windows2000-UU-KB978706-v2-x86-PLK.exe

Quote

This is MS Paint from Windows XP. It has an advantage over the one from Windows 2000 that you can save files as jpg, png, etc. while in the original one only bmp is available.

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


EDIT

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

[billtodd]

Thanks for such a clear and complete explanation. The main reason I questioned whether 2286198 actually superseded 967715 was because the Microsoft 'replaces' information for the former did not appear to recognize that it superseded the latter (nor did the descriptions of the problems addressed appear similar). I would have taken a closer look at what was going on had I not assumed that the question could be answered off the top of someone's head, so apologies (and further appreciation) if you had to do more than that.

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

[tomasz86]

KB2479628 isn't an IE-specific update per se. It was just that initially there were problems when it was installed in an IE5 system. That's why separate versions were created and bristols still keeps them on his page. Starting from 2479628-v8 there are no problems regardless whether you use IE5 or IE6. Only if you happen to use IE6+FDV fileset, you must use HFSLIP 1.7.10 beta J v5 or newer to get this update slipstreamed correctly.

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

[WildBill]

Hmm. There aren't many things left to try. Here's one that adds guards around the palette code:

Windows2000-KB2393802-v1-early-c5k-x86-ENU.exe

[tomasz86]

WildBill,

I've been having some problems with my computer and don't have access to my 2K system at the moment

I'll try to test your patch as soon as possible.

[tomasz86]

I've just tested it but still no difference unfortunately

[tomasz86]

I've found one more mistake on britols' page and this one I'd call critical.

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:

Windows2000-UU-KBz2511455-v2-x86-Global.exe

[bristols]

Thanks tomasz86.

Aside from rdbss.sys, did you add anything else to 2511455?

If not, I guess it's OK to continue using 980232 together with the existing 2511455 by WildBill. Is that right?

[tomasz86]

No, the only thing I added was rdbss.sys It's different in case of 2479628 & 2079403 where changes are related strictly to the registry.

Of course you can use both 980232 & 2511455. It's just (in my opinion) that the fewer updates, the better

[bristols]

tomasz86, on 26 October 2011 - 08:04 PM, said:

the fewer updates, the better

Sure, but that's not the only consideration.

Thanks tomasz86.

This post has been edited by bristols: 14 September 2012 - 10:11 AM

[tomasz86]

I've removed KB908536.

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.

[tomasz86]

I added two updates:

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

[tomasz86]

I added:

OnePiece_Microsoft.NET_Framework_v3.5.30729.3644.4_True_AddOn_ENU_W2K.7z

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