dencorso

In XP/2k3/2k, when one runs an update/hotfix file with the /x command-line option one gets to the actual files installed by the update, without actually applying the update, and it can be done on any one of those three OSes regardless of which of them is the update/hotfix intended to. Now, when using the correct extract/msdelta/mspatcha/dpx I can, by running: C:\>expand -F:* Windows6.0-KBNNNNNNN-x86.msu D:\MyFixDir obtain a set of files, including a .cab and a .xml, all inside D:\MyFixDir, but that seems to me to be some kind of delta-files and related materials... So, how on Earth can I cause those fantabulous .msu files to cough up the actual files? Can it be done outside Vista? Can it be done even on XP? Please advise. Thanks in advance.

Now we know that Bulletin #7 == MS14-030 and Bulletin #6 == MS14-031 (and, BTW, Bulletin #5 == MS14-032) and that all my senseless hazarded guesses turned out to be right (and below I list which updates belong to which bulletins, including MS14-034 == Bulletin #3, the one that apples to MS Office Compatibility Pack SP3): KB2878233 MS14-036 Ogl.dll 12.0.6700.5000KB2957503 MS14-036 GdiPlus.dll 5.2.6002.23386KB2957509 MS14-036 Usp10.dll 1.420.2600.6557KB2957689 MS14-035 IE8 componentsKB2880513 MS14-034 Wordcnv.dll 12.0.6700.5000KB2939576 MS14-033 Msxml3.dll 8.100.1055.0 Msxml6.dll 6.20.2503.0

But... then, why would MS even release those "Advance Notifications", if not for people to nitpick over them and/or hazard conflicting guesses, based solely on the meager info bits they provide?

I'd rather prefer not seeing that. The energy liberated by the Tunguska Event has been estimated as not more than 30 Mton... which would be 2000 times the energy liberated by the atomic bomb dropped on Hiroshima on August 6, 1945, or 15% of the total yeild of the 1883 eruption of Krakatoa. Other impacts, like the Chicxulub impact, are said to have been much worse, however.

No reason to be so negative, though... now that Bakuchris knows how to do it, it's just a matter of doing it again, to the new files... a small nuisance, but nothing serious.

On a finer reading we have: Bulletin #7 ("Tampering") surely is not even applicable to XP (since it's not applicable to Vista and both Servers 2k3 and 2k8) Bulletin #6 probably doesn't apply either (because it's not applicable to Server 2k3). So we're left with just 3 updates that apply. OTOH, Bulletin #3 applies to Microsoft Office Compatibility Pack Service Pack 3, so it may be useful for those using Office 97 or higher.

MS SB Advance Notification for June is out... there's 5 of them for Windows (but not necessarily all may apply to XP).

Sorry, no. You must expand them, because they're "Intra-Package Deltas-Aware Packages" (see KB828030), so they just contain the deltas (hence, 7-zip does not actually fail in showing their contents!) and the files used to update the system are actually created during what passes for "expansion".

Is there any more info about that blorked MSE update? I know it's been solved already, but the eweek hardly gives any finer details...

@player_1: I'd say the 2k3 way is one's best bet at lifting the RAM limit without losing system stability. Of course, since it was meant to be a server, conversion to desktop will require more than just a little tweaking, but should result in a lean, zero-bloat desktop, which I think is quite good. And there's a good guide to start from (which link I provided in a previous post). By creating a library of system images, and imaging the system regularly, and before each major tweaking session, of course, one can easily fall back from most mistakes, without having to restart from scratch. Moreover, this way one can do things in two or more different ways, while starting from exactly the same point, and compare results, when in doubt. But, be aware, it definitely won't be anything like "instal and forget"... I believe you're well aware of that, but it must be said, anyway, for the benefit of any other user who happens to wander into this thread in the future.

Of course, as reported by Sebijk in post #72, PosReady=1 is enough to get WU/MU working again and cause it to serve the POSReady 2009 updates, alright. However, when just that key is added, there appear some "Key Not Found" errors in the update logs, as reported by -X-, in post #76. So, harkaz found out which additional keys should be added, just to suppress those errors in the logs, and updated this thread's 1st post with that info, in .INF format. However, .INF format is less confortable, IMO, than .REG format, so that I added the same info, now converted to .REG format, to post #100, for it to be available for those who, like me, rather prefer to merge .REG files to the registry. Notice that both WES and WEPOS keys are set to 0. Just one of them ought to be set to 1, and POSReady is the best option. HTH.

@egrabrych Thanks for the feedback!

Do you have any way to test it? I mean can you outline a reproducible procedure that causes the error 0×80090326 on XP SP3? If so, then it's possible to find out whether the 2k3 SP2 files work on XP SP3 or not. If, however, that's not the case, I think it'd be better to postpone such determination till the moment someone finds out such a handy test case, before trying to port those 2k3 SP2 to XP SP3. There are already too many chestnuts in our plate to chew, at the moment, so to say.

Try to do it as the SYSTEM user (use PAExec, PsExec or RunAsSystem to run cmd and then run regedit, or use one of them to run regedit directly). It should be enough. If not, then do it offline, from Win PE.

+1 Of course, using the "Manual" mode is the way to go. Even if not WGA, there's still many ways things can go wrong. However, I, for one, will henceforward make one full backup of the system partition, before adding any offerings each new patch Tuesday brings, and then, do it on "Manual" mode only, of course. But, for me, that represents no change, because that already was the way I always did it. Better safe (or, at least, as safe as possible) than sorry.

Then again, it may simply be a question of uncertainty of measurement, both 29% and 36% actually representing the fact that circa one third of all Windows desktops are XP machines, and nothing more. Overinterpreting data seems to be more common each day... stats are great, but one must always keep in sight how little we do really know (= how big the uncertainty of measurement is).

Please do take care! Messing with the ProductSuite has been reported to hose the system by Myrrh on this thread and this other thread, both at MDL.

No. I've got it with two different machines in which I didn't yet add the POSReady, etc. trick to the XP registry. Moreover, one of them is a double-boot with 7 x64, and GenuineCheck.exe balks there, too. I didn't actually try to run GenuineCheck.exe from a 7 x86 machine, because I happen to have none on hand, right now. But that sure would be an interesting experiment to try, right now.

It's broken again! This time, however, instead of saying: ... it's giving a different message, one that has not been seen since 2008, AFAIK: BTW, for what it's worth, "Error code: 0x8004026f" means INTERNET_NAME_NOT_RESOLVED **** Much later edit: **** Just for the record, what truly happened is that MS has quietly shut the Windows Genuine Advantage program down for good early this year (just as they had already shut down silently the Office Genuine Advantage program way back in December 19, 2010). So, while GenuineCheck does not generate codes anymore, they aren't required by MS for any download anymore either, as -X- had found out and reported in the post following this one.

OK. I've now fixed the original post for harkaz. Thanks for the heads up!

Partition Saving - Damien Guibouret Powerful and free.

No. Sorry.

The one with the larger connector

Of course, it goes without saying that both plugging and unplugging HDDs should be done with the machine turned off (after waiting for at least one minute to ensure all capacitors have already fully discharged), and, preferably, with the cord disconnected from the wall outlet, too, just in case. That said, just the power cable is enough, there's no real need to also disconnect the HDD's data cable.

Of course! Yes, I think RLoew's just hit jackpot! So, let me change my previous suggestion of what to do, at this point: if the 128 GiB patch used is LLXX's, and the uSP, The_Guy's, then I think you should install on PATA with SATA disabled, the uSP, then install LLXX's 128 GiB, and install last RLoew's SATA patch. After all that is done, enable SATA, and, having confirmed all is working OK, create a full backup. Then add KernelEx (and maybe KeX extensions). This should work.