dencorso

+1! Not needed, and not really safe.

Open the case and pluck out the power cable from the hdd BTW: this thread is bidimensional already...

With all due respect: The only reason unofficial updates exist is because someone decided to create them or, more usually, port updates intended for other platforms to one that's now unsupported because the software house which created the -- now unsupported -- platform decided (fully within its rights) to stop supporting it, usually after having done so (viz. supporting the said platform) for a real long time, before dropping support, after repeatedly and laboriously warning (ad nauseam) everyone involved. That said, the reason support is dropped is because it's expensive and time-consuming to test -- exaustively enough for release -- every single update that proves to become necessary. So, by their own intrinsic nature, unofficial updates are much less well tested, and, of course, can give problems. It is expected from every user who decides (of his/her own free will) to apply such updates, that he/she take beforehand such measures as reasonably required (viz. making a full, know-to-be-good, backup) before actually applying any such update, in order to be able to recover from any unexpected problem that may arise from having applied such unofficial update. In fact, such preventive measures should ideally be taken even for the case of official updates, actually, although most users never even think about that. But, whatever the user decides to do, in regard to the application of unofficial updates, he/she must always be fully cognizant that, by going ahead and applying them he/she is also stating that he/she is doing it of his/her own free will (and not because anyone said to do it), solely on his/her own responsibility, and that he/she shall stand by this responsibility even if, after applying the unofficial update in question, his/her pc morphs into a purple mushroom and explodes, causing a 10-day worldwide blackout in the process. One's life is his/her own and one's decisions (and sole responsibility) likewise. Else one ought to take the blue pill, instead, and let unofficial stuff well alone.

Try again: reinstall but do not add the unofficial SP, then install KernelEx. Does all then work OK, or do you end up having the same problems? Sorry, but the only way to find out what went wrong is to factor the instalation process into smaller parts, or omit one of them per retrial, just as I'm suggesting you do, as you surely know.

For some reason, the Root Certificates Program KB931125 is beyond EoS. The link below always gives the most up-to-date Root Certificates, and they still install OK even on Win 98SE, as of today. Root Certificates Update (Direct Download) BTW... is there a similar permanent direct download link for rvkroots?

IE7 and IE8, as well as .NET 1.1 SP1 are almost the only ones intended for 2k3 x86 that can be ported OK to XP x86. Now, POSReady 2009 also gets those for IEx so, IMO, its far too dangerous to try to spoof *at the same time* both POSReady 2009 *and 2k3*... it's bound to go wrong. So, my take, spoof POSReady 2009 which seems to be safe, and wait for the few NET 1.1 SP1 to be ported by hand, before adding them. Many users don't even have .NET 1.x installed, so just relatively few need those. And for anyone who, like me, prefers reg files, here is the Myrrh-Sebijk-Harkaz trick in .reg form: Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WindowsEmbedded\ProductVersion]"FeaturePackVersion"="SP3"[HKEY_LOCAL_MACHINE\SYSTEM\WPA\WEPOS]"Installed"=dword:00000000[HKEY_LOCAL_MACHINE\SYSTEM\WPA\WES]"Installed"=dword:00000000[HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady]"Installed"=dword:00000001However (this is just an opinion), spoofing 2k3 x64 for XP x64 may, perhaps, be a way to go... N.B.: Superseded by the version on the 1st post. Use that one.

Because neither .NET 1.0 nor 1.1 are part of either WES, WEPOS or POSReady 2009. @ roytam1: we cross-posted. Sorry!

Not at all. .NET 1.1 is actually considered (by MS) part of Windows Server 2k3, and hence it's supported until the latter undergoes EoS (on July 14, 2015).

No, the Win Server 2k3 updates need more considerable .INF editing before they can be used in XP, so that those (mostly .NET 1.1 sp1) will continue to need porting by hand, sorry.

Because, it seems, real life is way stranger than fiction, in that, in fiction, there's just one Pierre Menard, while in RL there are several of them.

POSReady and WEPOS at the very least. Yes, but the .INF requires considerably more editing.

Just a friendly warnining: modifype is problematic for anyone working on Vista to 8.1 ... I strongly recommend using, instead, the reliable n7epsilon's pechecksum.exe v. 1.4 for the mandatory checksum correction. To follow my advice, simply replace the line: modifype update.exe -c by this one: pechecksum -c update.exe and that's all! In fact, pechecksum also works on XP, so I don't use modifype anymore.

@harkaz: are you posititve the problem lies with update.exe and not at all in the interaction of symevent.sys with the .NET optimization service?

12.9.5.2, AFAIK, is the latest for x64... you've got it right, for x86 the latest actually is 12.8.6.38 (which, in fact, actually installs a symevent.sys v. 12.8.6.37, just to add some more confusion to it all).

Why don't you try it yourself? It is a rather straightforward experiment. It's not true! Thanks a lot for the test files! You rock!

I think that CRC-32 has the following interesting property: if the CSC-32 of an arbitrary binary "fileA" is 0xFFFFFFFF and that of another arbitrary binary "fileB" is 0xFFFFFFFF, then the CRC-32 of "fileC", resulting from: copy /b fileA+fileB fileC will also be 0xFFFFFFFF. Is this true? And, BTW, what about the "undocumented command-line switch" "-xx" ? Myth or fact?

I know, I just wanted to let you know that I dont care if you site or now. Maybe you meant "I don't care whether you cite them or not"? @enxz: Welcome back! While we disagree, it's good to have diversity of opinions around. Not wishing to rekindle an old discussion at this point, I still remain firm on my main vision that no matter how good the security included, no OS is or can ever be really secure, because what man does, man can undo (or what one human being closes, another human being can pry open, to put it on a more "politically corret" form, which is the norm, nowadays...). And I also remain firm on my belief that, as Flasche most aptly has already put, PEBCAK (or unsafe user behavior) is more relevant as a source of insecurity than any software/hardware protections that can be added to the OS, so that XP is not so insecure as you insist it is (which is much different from considering it secure). We do, however, have irreconciliable beliefs, from an ontological POV: you (as I'd expect from a security professional) believe it is possible -- and eventually will actually be implemented -- to have an OS keep secure despite the user, whereas I consider that impossible to be done by physical means alone (and hence resticted to the domain of sci-fi). Even more, to deny an user the ability to engage in risky behavior is actually to deprieve him of freedom, on a more philosophic take on it, so I'd really dread such a future, not dream about it. One must be careful what one wishes...

This post elsewhere may be of interest in that it lists which .NET versions ship with which OSes.

True enough. Then again, the Acer Aspire One AOA150 already uses a SATA/300 HDD, so no adapter is needed for it to connect to SATA HDDs... AFAIK, BTW, the Acer Aspire One AOA150 has only SATA ports onboard, so that no IDE to SATA adapter can possibly be used on it, and that's the only type of adapter that would obviate the use of RLoew's patch. The reverse adapter, the one that connects a IDE HDD to a SATA port onboard is useless for that, because it makes an IDE HDD effectively SATA (and it's even more rare as an adapter, nowadays).

Sure they do. Look at this.

True enough. One patch caters for as many SATA disks as there are ports to connect them to the motherboard, whereas, if adapters are used instead, each disk needs its own adapter.

Well, that one is actually quite easy: it's because we're inside the Asylum. See:

No. Since any application (I use the great Cody Batt's HashTag, but any other that calculates CRC-32 by the book will do) not aware of ExclCRC and AutoCRC does reach the target value of 0xFFFFFFFF, when calculating the CRC-32 of those images, it cannot be an "area to exclude". ExclCRC must instead be a fudge-factor included in the CRC-32 calculation, adjusted so that it gives the target value of 0xFFFFFFFF. Four bytes is all that's needed to fudge the CRC-32 seven ways to Sunday, as the little application HackCRC32 found on this page can nicely illustrate.