dencorso

Well... FF will drop XP at 53.0.0. So shall FF esr do, too. However, the last FFesr to support XP ought to be 52.8.0... ... then it moves on to 59.0.0 and tells XP: "hasta la vista, babe" ! Life's like this.

The updater does not work right for XP. Download from here the full installer for the actual version you want to install and run it, and it'll update your current installation, while keeping all your configurations. It just works! Any statements to de contrary are just FUD.

Please do tell her not to hold her breath, while waiting, OK?

Yes. And the latest possible build of the 2K3 driver used (preferably from the same KB as the XP driver being substituted or later), unless a good reason is found to use any previous version. And in any case, ideally just a very minimal number of files should be replaced in total. Of course, NTOSKRNL, HALMACPI and USBPORT are already known to be mandatory, but, even then, USBPORT is a simple transplant from 2k3, NTOSKRNL uses slight variations of the GC Patch, and nobody really agrees about the hal, except that it's fundamental... now build 1106 lacks lots of later patches but seems still better than a half-backed patch ov the later builds... but neither is really a good choice, from an ontologic point-of-view.

Long-term stability seems to be the main problem. Besides Geoff Chappell's info on this, the name to search for is Danila Galimov (aka Danil Galimov), who has performed the most extensive investigation on the matter, but whose reports are hard to come by.

It's complicated. The best alternative is to use all the most recent files, so that means the latest SP3 hal, kernel and ntdll files and use the Gavotte Rramdisk.sys (after disabling the paging executive ability to page on the OS-Kernel and Device-drivers area) to create a big ramdisk with all memory above ca. 3.3 GiB up to the top of memory. This is what I do on my machines (3 desktops and 3 notebooks), of which the most powerful is the one I'm posting from right now, an Asus P8Z68-V LX running a 3770K i7 with 16 GiB DDR3 RAM (of which XP sees 3.22GiB and the rest is a big 12,4 GiB ramdisk, containing all discardable things and the pagefile). This is the safe way to proceed. Now, suppose you *want* to cause XP to see all the RAM. Then you'll have to patch the ntkrpamp.exe v. 5.1.2600.7146, which is feasible and works OK, and change the hal.dll (which is, in this case a renamed HALMACPI.DLL) by the most recent (in fact only) SP1 version of that file (5.1.2600.1106), because to patch correctly the latest SP3 file (5.1.2600.5573) is not feasible at all (because MS yanked off code galore from 5.1.2600.2180 onwards). Dibya says v 1106 works OK among the SP3 and post-SP3 files. I have no reason to doubt him, but I did not (yet) test that myself. And, of course, this must be tested on bare-iron to make sense, not on a complacent VM. Well, now you know the facts in a nutshell (as I see them, of course). HTH.

I have checked as thoroughly as I was able to, and, by now, I'm quite convinced MS did not release any further update to: halmacpi.dll v. 5.1.2600.1106 (xpsp1.020828-1920), MD5 = 308709E92843DFF3A5CDCA069F6F5C61, released on Thu Aug 29, 2002 08:05:02 GMT, which is the version on the original SP1 (and on SP1a, of course), until they eventually released the SP2 package, of course, which includes: halmacpi.dll v. 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158), MD5 = DFCE51FD96909D1B97D4A1A72D060D77, released on Thu Aug 29, 2002 08:05:02 GMT, and while there are other varieties of hal.dll, halmacpi.dll is the one that's relevant to break the 3.XX GiB limit by activating PAE... And this means that the newest version that can be used is 5.1.2600.1106, and no other build exists after that and before SP2. Did I overlook any obscure MS hotfix?

While I don't think its developers think of ReactOS as a dead project, and while I, too, have always hoped it might blosom into a viable successor for XP, I fear I have no choice but to agree the ReactOS project is deeply comatose and seems to have no prospects of awakening in the near future, so that, even if it does come to eventually, it'll be far too late to make any difference anymore. And while I'm not exacly a fan of unix, I do think the best candidate to become a viable alternative to Windows is TrueOS, a very mature distro of FreeBSD. ... the rest ...is ...silence.

So? AFAIK, Serge_Humpich has since moved on, and nowadays works on IT, in France.

BTW, could you please update jumper's batch to work with XomPie 0.4a ? I think it was a great optional, but it wasn't updated from 0.2 up to now...

Try the Intel 6.14.10.5398 XP drivers. They may just work, but they may also require some igxp32.inf tweaking. And Dibya is right. UNIATA ought to work. But you need to use the F6 method or slipstream it. Look for how to do that, and you're all set!

Just launch the new exe installer, it'll work OK. Latest Flash works OK on XP... direct download links: npapi - active-x. Enjoy! Merry Christmas! and Happy New Year for you and yours, too!!

GhostBuster, maybe?

File is not available anymore. You can zip and attach here custom txtsetup.oem and custom .INFs, as well as any other plain text configuration files. As long as no executable files are included, it's OK.

Now you know firsthand what you were told before. There's no known Intel HD 4000 driver for XP. You're on a wild goose chase.

Delenda Cortana! Long live 7 of 9!

Windows 2003 x86 drivers should install OK on XP, with just the most minimal .inf adjusting. I bet if you try you'll succeed quite fast.

@all participating in our XP mega-hijack: I intend to move all the XP-themed posts and related posts from this thread to "Windows XP is still king" sometime at the week-end. I hope nobody objects to this move, but if so, please, do speak now or forever hold your peace.

So you solved it by falling back to the SP1 hal (and that's the halmacpi [= ACPI 1.0 / APIC / MP] variant, of course!). Good to know it still works OK with much later versions of all the rest of the system core files and the appropriate patched kernel.

@Dibya, with all due respect: everybody and their cousin here knows you love the PAE hack. Notice it was unveiled by Geoff Chappell a long time ago, and it works beautifully for Vista+ and 2k. XP and XP SP1 don't need it, nor do the x86 Server NT OSes. However, no matter how strongly you may wish to the contrary, it's unstable for XP SP2 and SP3, and none of the patches available does anything to restore to the hal the code extricated from it by MS, which results in unfixable instabilities, only part of which are solved - somewhat - by using a bunch of Server 2k3 drivers. OTOH, the Gavotte Rramdisk is free, safe, *stable*, reasonably easy to set up, and just works! It goes without saying that it doess not hamper the attainment of multimonth uptimes.

Give it the Gavotte ramdisk (v. 1.0.4096.5, of 20081130) to throw your discardable files (Temporary Internet Files, Cookies, and other browswer's caches) as well as the pagefile into. It takes some calisthenics, like setting UsePAE=1 and DisablePagingExecutive=1, but sure puts all that otherwise unused RAM to good use!

@glnz: Yes. 9. (10 actually, but more below). My main machine didn't become a purple mushroom and explode! So I guess you may wish to take the plunge. @all: There's also available the "November, 2016 Security and Quality Rollup for .NET Framework 3.0, 4 on WES09 and POSReady (KB3189598)", from MS16-120. @heinoganda: Thanks for the feed-back! I stand corrected.

No. The only way to do it reliably would be by interpreting the executable, and that amounts to machine-disassembling [ca. 100% correctly] and then machine-interpreting the resulting code. It can be done by hand, of course, since the start of time... but automagically? no, not yet, and don't hold your breath waiting for it, either...

Just for the record: capacity: 40 kB (viz. ca. 20,000 UNICODE characters); write once / read many times; proven to remain readable after 2700 years, insensitive to both fire and water (they are made of ceramic, after all); weight: ca. 110 lbs (not exactly portable, in truth).

In my time, we used clay prisms (which still exceed by far every other media in what regards data retention and robustness to failure) ... ... and we liked 'em!