dencorso

At the very least, the OP? Here (in the dark ) I have SP2 (with a number of "selected" updates and/or mods/tweaks) The reason being that I never found the time and/or a real reason to update to SP3: simple, straight, not tortuous, nor contrived explanation . Welcome to this thread, jaclaz! I really like your reason.

SP3. The (really few) users of previous SPs may give you many contrived and tortuous explanations (with all due respect) as to why they use SPn (with 3 > n >= 0), but none of them resists the light of day. Using just SP1's halmapi.dll instead of a patched SP3 one for access of RAM > 4 GiB (on machines having > 4 GiB and PAE), at least while the patch to the latest halmapi.dll is still experimental, is understandable. Then again that same memory can be accessed safely with a ramdrive, and pagefile.sys created in it so that XP x86 can use it anyway. -- All those who went x64 OSes please don't even think of stopping here and posting to ask why keep x86 because such a discussion is tiresome and pointless! Such posts shall be deleted without previous notice. -- That said, if any one comes here and posts "I use SPn because I can, while considering any issue that may cause me fun to solve. I do it because I find it fun."... well, that I'd sure consider a totally valid reason. Then again, I've never seen anyone come forward and say it (even in a much more toned down version).

It's awfully cloudy here, too! But, in any case the total eclipse should start about 20 min hence, so better visibility is yet to come. cnn has a live feed of it on this page.

At RLoew's. US$11.

Hats off to you, RLoew! It actually is a SATA-300 HDD (which must work at SATA150, because of the southbridge limitation)! Here's a detailed description of the dis- and re-assembly of an Acer Aspire One AOA150 having a 120 GB HDD (a SATA one, for sure). So... RLoew's SATA patch will be needed, besides (and, in fact, on top) od LLXX's modded ESDI_506.PDR. There's no avoiding it.

Well, Tripredacus was talking about one he remembered seeing in the '90s... that's why I said "another". In fact, there was one total in Aug 17, 1989 and another, also total, in Dec 9, 1992, plus two more, on Apr 4 and Sep 27, 1996, all of them visible from the US!

I probably can locate the main thread it was discussed in... Edit <some time later>: the jump-back link at the right upper corner in the quote below works as intended and will get one to the quoted thread if clicked upon. This other thread also has a little more info, which boils down to: the recommended source for those utilities remains BHDD31.

So, brace yourself and prepare for a memorable night, since we're going to have another one tonight!

No, but as disk maintenance tools don't work correctly above 120GB it's preferable to limit partitions to that size. And anyway if we are speaking about a drive connected to a SATA controller, all the LBA48 talk is irrelevant to the issue. Which tools? FORMAT. SCANDISK and the Ranish Partition Manager all work OK up to about 1TiB (where DOS itself has a subtle bug). Hence up to 1TB (not 1 TiB), those three tools, at least should be safe to use. Norton/Symantec Ghost from 2003 to 11.5.1 are also safe to use in those conditions.

Great!

SATA? Are you sure? The Acer Aspire One AOA150 is based on a ICH7-M, for sure, so it might have a SATA150 or a Ultra-DMA 133 or 100 HDD. The early Asus EeePCs all came with PATA from factory...

If this is the case, the latest version of that file is in KB2868038 (Usbvideo.sys v.5.2.3790.5198) and should be preferred.

It does work. It's time-proven. You must be installing it wrongly in some way. How are you installing the patched ESDI_506.PDR? I'm keeping at it because, with all due respect, it's not optative. It's the same world, and this world is controlled by physics, not magic, so: If it works for me, it must work for you. What happens where I am, happens the same way where you are. Unless we're doing different procedures, because different procedures can yield different results. Then again, the same procedure must cause the same results.

Of course I am. "It didn't work" doesn't work... what did you do and what didn't work? Of course LLXX's patched files work! But before you go into that, neither the BIOS does recognize the right size of the HDD, isn't it so? Now, that's not good. You need either an official updated BIOS that is able to recognize the HDD, or a modded BIOS, or else a DDE. Rloew has a DDE, but it's not for free. The BIOS needs to recognize your boot disk right, or you're dealing with an unstable system, and that's an inviable task.

It's alright! Take your time. But do it when it's convenient for you, and then, please do report it in this thread, OK? BTW, when you do test scdeny's patch, do test it with VPCNetS2.sys present , too. Both crash instances were related to networking, after all...

Read link to the right of my signature.

Fully remove ACPI. While "setup /p i" is only useful in a reinstall, my instructions are for removing ACPI from an already installed system.

@roytam1: Great find! Thanks for the link, Are you currently trying scdeny's XP64G patch, are you back to XP SP1 halmacpi or are you still using the patched hal generated from my universal search hexstring? I think scdeny's XP64G patch ought to be tested, alright.

While you should not use MS-DOS 8.0 as a stand-alone MS-DOS, you sure can do it with MS-DOS 7.1. So you might as well install WIn 95, then replace all DOS files by those from 98SE (and some from ME) and then add the various fixes to IO.SYS (I believe RLoew released a freware patcher for IO.SYS, IIRR). In this aproach, you'd not only have the LOGO, but also all the benefits from the most up-to-date MS-DOS version in existence. Of course, this is lateral thinking, and you might proceed in the quest for extracting (and even recompressing) the LOGO from inside IO.SYS. This is just my 2¢, of course.

What about adding a common garden-variety VIA VT6105 PCI add-on card? Should be enough to solve the issue for you and costs less than the handling & postage needed for it to reach you...

I said this before, and nobody got interested... which really surprises me because XXCOPY is freeware. Please do you all kindly give a good look at XXCOPY and Reparse Points... I think it can solve the problem of WinSxS automagically during simple a NTFS to FAT32 copy.

Well, Andre sure has a point! Yes. Update the drive first. If the BSOD's go away, fine. If not, then fall back to the XP SP1 halmacpi.dll, at least to help us determine whether the problem is with the patched halmacpi.dll or not.

Here's what I think: kondra's patches to ntkrpamp.exe are well understood and tested up already and the 2k3 usbport.sys is safe, so if anything may be wrong, whatever it is, it must be with the much more recent friendship7's patch to halmacpi.dll... so... try falling back to your copy of XP SP1 halmacpi.dll, and let's see what happens: if no more BSOD's, you're good for now, and we must look deeper into the patching of halmacpi.dll...

So... the above shows that, contrary to your belief, you did not install successfully at all, but instead, with all due respect, created a bootable mess... Best solution is to wipe, reformat and make dos bootable the internal HDD, then copy the install folder from the Windows Install CD to an arbitrary subdirectory in the internal HDD. Then remove all removable media, boot to DOS and start the windows installation from the subdirectory where you put the windows installation. That's how you do it. But... after all that work, you'll hit the exact same wall that made you give up 95. Therefore, were I you (whom clearly I'm not), I wouldn't even start. There are two greaphics drivers for the EeePC: VBEMP and SNAP. There's no other option. Contumacy against the facts is futile.

Here's its entry in the NASA eclipse database: <link> Do make a point of watching it... it sure seems it'll be very beautiful, provided the sky where you are be clear at the time.