MacLover Posted October 24, 2011 Posted October 24, 2011 Billtodd - It fixes the MS10-046 security vulnerability relating to LNK files.
billtodd Posted October 24, 2011 Posted October 24, 2011 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 Posted October 24, 2011 Posted October 24, 2011 (edited) 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.exeUnfortunately 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. <- FalseActually 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.exeNow 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.exeI prepared also an another additional update:MS10-005: Vulnerability in Microsoft Paint could allow remote code executionWindows2000-UU-KB978706-v2-x86-ENU.exeWindows2000-UU-KB978706-v2-x86-PLK.exeThis 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.5918I 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 EDITI'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. Edited October 24, 2011 by tomasz86
billtodd Posted October 24, 2011 Posted October 24, 2011 (edited) 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. Edited October 24, 2011 by billtodd
tomasz86 Posted October 24, 2011 Posted October 24, 2011 (edited) 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. Edited October 24, 2011 by tomasz86
WildBill Posted October 24, 2011 Author Posted October 24, 2011 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 Posted October 25, 2011 Posted October 25, 2011 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 Posted October 26, 2011 Posted October 26, 2011 I've just tested it but still no difference unfortunately
tomasz86 Posted October 26, 2011 Posted October 26, 2011 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 Posted October 26, 2011 Posted October 26, 2011 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 Posted October 27, 2011 Posted October 27, 2011 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 Posted October 27, 2011 Posted October 27, 2011 (edited) the fewer updates, the betterSure, but that's not the only consideration.Thanks tomasz86. Edited September 14, 2012 by bristols
tomasz86 Posted October 27, 2011 Posted October 27, 2011 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 Posted October 28, 2011 Posted October 28, 2011 (edited) 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. Edited October 28, 2011 by tomasz86
tomasz86 Posted October 30, 2011 Posted October 30, 2011 (edited) I added:OnePiece_Microsoft.NET_Framework_v3.5.30729.3644.4_True_AddOn_ENU_W2K.7zThis 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. Edited October 30, 2011 by tomasz86
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now