Leaderboard

Same here. I've been running Fedora (Linux) due to hardware compatibility issues (no drivers) since 2016. I've been eventually using Linux for anything that XP wasn't able to do and whenever I had to use Windows (an updated one) for encoding or coding (Visual Studio 2017 etc) I fired up my second VM with Windows 10. For the records, I also have VMs with Win98 and Android. Anyway, I think I'm gonna stay as I am right now: XP for casual usage, Fedora for everything that XP can't do and Win10 for work. Eventually, I'll begin to use Fedora more and XP less 'till it's going to be inevitable. It's been a good journey, guys, but as I said before, don't cry for what it's not going to be, smile for what has been... :') (Not my picture):

@Dibya, I change 3 Byte. Look at acpi.sys with Hexeditor and replace 75F87414FF -> 75F8EB14FF 84C07508FF -> 84C0EB08FF 59597C21A1 -> 59597C00A1 thats all. It overcomes some stupid tests from acpi.sys in DSDT table in Bios (for example checksum). This was the breakthrough for full ACPI support in XP on all newer motherboards Dietmar

Adobe Flash Player 32.0.0.171 has been released today (confirmed working with Windows XP SP3/Windows XP x64 SP2) Internet Explorer ActiveX: http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.171/install_flash_player_ax.exe Mozilla Firefox NPAPI (also for Opera Presto/Google Chrome 44 and earlier): http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.171/install_flash_player.exe Google Chrome 45 through 49 PPAPI: http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.171/install_flash_player_ppapi.exe

Very sad to see this come to an end, but as others have said, software compatibility is more important than software updates. The thing that I would be most concerned about now is the time remaining before Microsoft Update v6 goes offline forever. This is a very real scenario as this is could possibly be the last patches any version of XP will ever receive, meaning it can be closed. Windows Update v4 was closed in 2011 which IIRC handled NT, 95, 98, ME, and 2000 >SP4. Support for 98 and ME ended in 2006, but there was info regarding a version of NT that was supposedly supported until 2011. We can't really know for certain when it will go offline, perhaps tomorrow, or in 5 years, but when it does, installing and updating W2K and XP will only get more difficult from then on.

In fact, once XP SP3 is inside VirtualBox, one can keep using it forever for Text Processing and Spreadsheets on Office 2003 and Graphics (I use Origin 6.0, never yet had any reason to buy a license to any later version of it). There'll always be some way to convert the next .doc(x)(y)(z)* format to plain old Word 97 .doc, and keep going. Same with .gifs, .jpgs, .pngs, and the like. As for browsing, one can always do it right on debian, and there's ESET for additional security at the OS level, pi-hole for crappy ads and Open-WRT firewall at the head of the LAN (and *NO* Wi-Fi whatsoever connected to it). Until Hell freezes over, Long Live XP!

Since tomorrow...

Even with the 5400 RPM HDD and 512 MB of RAM, XP SP3 was solid on my T41. Of course I could have used more RAM but for the older games I ran on it, I never ran into issues. And not only has it been exactly 5 years to the day since the loss of stock XP support, we are also counting down to the last POSReady 2009 update; one day to go. And of course, the OS will still be up to date until May 14, when Server 2008 and up get their new security updates. Those POS machines at my school were still running XP on Friday. I wonder how long they'll take to update.

Since nothing came up today (EOL), I make listing to recap the updates of XP and .NET framework after last Service Pack applied. XP SP3 (no MCE/TPC) .NET 1.0 SP3 .NET 1.1 SP1 .NET 3.5 SP1 .NET 4.0 XPNETpostSP.txt

I'm almost sad to report, all 14 installed without incident. sniff sniff...I'm going to miss the excitement of troubleshooting these things with you guys.

I think it's less a matter of updates than of software. You can put an XP system behind an external firewall and make it very tough for a hacker to compromise, but if Web sites start using ECMAScript 2018/2019 features in their JavaScript and there isn't a compatible Web browser that runs on XP, then it'll be game over for a lot of folks. That's what eventually killed Win 98 for most intents and purposes. There have also been a lot of non-browser software packages that have stopped supporting XP in the last several months. PotPlayer was the most recent example. But that doesn't drive obsolescence the way the Web does. Older versions of other software don't gradually stop working over time the way Web browsers do.

This is the link: https://www.microsoftedgeinsider.com/en-us/download/

Found a problem (don't know if I'd call it a bug, but it's a problem for me): the installer uses wget, and wget doesn't use system proxy settings. As a result, downloads fail on my work PC and I just get an empty folder. (Of course I can download the "old-fashioned" way just fine, since my browsers do use system proxy settings.) Luckily there's a simple workaround, by setting some environment variables. The following batch file does the trick for me: set http_proxy=http://127.0.0.1:8079 set https_proxy=http://127.0.0.1:8079 "Roytam Browser Installer.exe" Of course, others will need to change the http/s_proxy settings according to their own needs. (Actually I think the installer just uses http, so the set https_proxy line probably isn't needed; but just in case....) HTH

EoS is nothing more than End of Support... XP Forever!

I'd like to point out that today officially marks 5 years since Microsoft dropped support for Windows XP SP3. It still runs like a champ on my T41 with the 7K60 7200RPM drive!! I'm also using Office 2003 with the 2007 Office System File Format Compatibility Pack (FileFormatConverters.exe).

Hi Tomcat76, Thank you for your donation of $50.00. We look forward to improving the forums and stay online with your donation. Thanks MSFN

It wouldn't surprise me if Primetime requires considerably more CPU horsepower than the built-in ffvpx decoder. If so, ffvpx would be the preferred choice unless you're having issues with it.

@glnz: did you get yourself a full-body Velostat vest already? If not fetch one fast: you must be ready for when, precisely 24h after April the 9th, a horde of 6.02214086 × 10²³ raving-furious hackers drop into your machine, after all, isn't it?

New New Moon 27 Build! 32bit https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190406-4ed6f4941-xpmod.7z 32bit SSE https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190406-4ed6f4941-xpmod-sse.7z 32bit noSSE https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190406-4ed6f4941-xpmod-ia32.7z 64bit https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190406-4ed6f4941-xpmod.7z source repo: https://github.com/roytam1/palemoon27 repo changes since my last build: - import change from rmottola/Arctic-Fox: - further pointer style tweak for patching (90943bf7a) - Bug 1137910 part 1. Don't lose track of the original 'this' object in THIS_SAVEDFRAME, so we can actually do things based on the principal of the object we're working with. (0c6bf89dc) - Bug 1137910 part 2. Give chrome callers that are indirectly (e.g. via nsIStackFrame) poking at content-captured stacks the content view of the stack. (9b9d8981d) - more pointer style to pach easier (210ef0c78) - even more pointer style (8dad567c6) - Bug 1130576 - Rename JSPropertyOp -> JSGetterOp and JSStrictPropertyOp -> JSSetterOp. (0714aa290) - Bug 1083359 - Part 1 - Add the asyncCause and asyncParent properties to the native SavedFrame object. (1c99ec1bc) - more pointerstyle (21148a28d) - Bug 1135827 - Don't root more times than necessary in js::SavedStacks::insertFrames. (904461ae0) - comment fix (9401372c6) - Bug 1083359 - Part 2 - Allow C++ code to provide an async stack when calling a JS function. (e5ce833fa) - Bug 1133081, part 1 - Switch from js::PropDesc to JSPropertyDescriptor for all users of js::StandardDefineProperty (mainly Object.defineProperty/Properties and the corresponding Debugger.Object methods). (4754703df) - pointer style (58e1befc2) - Bug 1133094 - Object.defineProperty() on scripted proxy incorrectly sets {[[Configurable]]: true} if it's missing. (c4da7e6c6) - Bug 1133081, part 2 - Switch from js::PropDesc to JSPropertyDescriptor for js::StandardDefineProperty implementation. (07efac725) - Bug 1133081, part 3 - Switch from js::PropDesc to JSPropertyDescriptor for more odds and ends. (119b5711e) - more pointer style (b2c2a8383) - Bug 1133294 - Object.getOwnPropertyDescriptor(obj, key) must always return either undefined or a complete property descriptor, even if obj is a proxy. (39bc723a7) - Bug 1133081, part 4 - Reimplement the remaining PropDesc methods and delete PropDesc. (3b447fb7b) - Bug 1130537 - Reimplement js::SetPropertyIgnoringNamedGetter to follow ES6 draft rev 32 9.1.9 [[Set]]. (7a681465a) (e1ef2cd0b) - import change from rmottola/Arctic-Fox: Bug 1133081, part 5 - Remove non-asserting PropertyDescriptor accessors in favor of the new PropDesc-inspired asserting accessors. (9da3866fa) import change from tenfourfox: #399: null check in FindNearestCommonAncestorFrame from PM 978 (23f303460) (d83c58e95) - nss: update nss to hg rev e5e10a46b9ad with vc2013 hackfix (c532d18da) - import change from rmottola/Arctic-Fox: - some pointerstyle (5eafc4481) - even more pointer style (8b1c94dd0) - Bug 1138984 - Allow 'new' template objects to have dynamic slots (31cff4565) (593d1c056) - import change from rmottola/Arctic-Fox: - revert apparently PaleMoon specific change to CreateLazyScriptsForCompartment, so later FF patches apply smoothly (ed89197ec) - Bug 1140428 - Warn when __noSuchMethod__ is used. (976c93809) - Bug 1133759 - Always shrink GC buffers at the end of a shrinking GC, even if we don't compact (5d9fadcfa) - pointerstyle tweaks again (26426837a) - Bug 1125101 - Incrementalise compacting GC by zones (9badc2329) - Bug 1136597 - Mark all relevant cross compartment debugger edges when sweeping. (Adapted) (964373773) - some pointerstyle updates (1ff2d78b7) - more pointer style (be38e9b5c) - Bug 1135100 - Don't bother to check if things we don't relocate have been forwarded (8da001057) - Bug 1135100 - Remove Cell* versions of various GC methods forcing callers to use correct type (a1d09d1fa) - pointer style (6f7d4091e) - Bug 1137573 - OdinMonkey: Alignment Mask Analysis (fd86305f3) and removed addTelemetry hunk from rev 976c93809 (4ed6f4941)

Works as expected here with Serpent 52.9.0 2019.03.23 (32-bit) in a new/clean profile, even without the preference in question (i.e. privacy.userContext.longPressBehavior;2): Works also in my heavily "dirty" Serpent 52 profile, but I don't have any tab-bar modifying extensions (actually, I do have Classic Theme Restorer, if that counts...). In your screengrab it looks as though you are using an extension which makes the tab-bar render in a vertical fashion (is it Tree-Style Tabs?), so the "new-tab-button" offered by that extension lacks the "Container Tabs" functionality exhibited by the original "+" button in the native tab-bar; IOW, @Mathwiz is right:

It looks like you may be using an extension which alters the operation of the "+" button. Try disabling it and see if long presses start working. If so, your only hope is to let the extension developer know about the issue. It wouldn't surprise me if (s)he didn't even know about the container tabs feature! BTW (I'm pretty sure the OP already did this, but just for the benefit of others): the privacy.userContext.longPressBehavior pref doesn't exist by default; you have to create it with right-click / New / Integer. Then enter the new pref name (privacy.userContext.longPressBehavior) and value (2). Long-pressing the "+" will then bring up the "New container tab" menu so you can easily choose a container for your new tab.

Was the message something like "Windows Product Activation can't check the activation status of winlogon.exe" after attempting to logon? I've gotten that after messing around with the OS identifier of NT 5.2 x86 VLK (Server to Professional). Perhaps applying fcwin2k to winlogon.exe would have caused this. I don't think Yandex could affect WPA in any way. if so, you can still access Windows in safe mode, where you can delete all the associations made by fcwin2k. If not, a backup of the registry that dates back to before using fcwin2k should fix it. P.S. this method should also work on Windows Server 2003 (x86 and x64). This program must be one of many that block NT 5.2 (or Server 2003 specifically).

New New Moon 27 Build! 32bit https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190330-d86d78c8b-xpmod.7z 32bit SSE https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190330-d86d78c8b-xpmod-sse.7z 32bit noSSE https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190330-d86d78c8b-xpmod-ia32.7z 64bit https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190330-d86d78c8b-xpmod.7z source repo: https://github.com/roytam1/palemoon27 repo changes since my last build: - partly ported change from tenfourfox: - chemspill: M1537924 M1538006 (backported to ESR45) (b22dfbd77) (161cf6eb4) - import changes from rmottola/Arctic-Fox: - Bug 1140586 part 1. Add some asserts about us not caring too much about the parents of native functions. (dd735591e) - Bug 1140586 part 2. Stop passing non-null funobjArg to js::NewFunction and js::NewFunctionWithProto. (b4d148f53) - Bug 1137180 - Only mark inner scripts as having failed a bounds check after bailing out (22ded5bd9) - Bug 1140582. Remove the parent argument from JS_NewObjectWithUniqueType. (a49a25f88) - Bug 1139993 - Add VectorBase::ConstRange that gives out |const T&| entries. (409317be0) - Bug 1136906 part 1. Stop passing parents to JS_NewObject in ctypes code. (14412c561) - Bug 1136906 part 2. Stop passing a parent to JS_NewObject in xpconnect code. (e5769c27d) - Bug 1136906 part 3. Remove the parent arg from JS_NewObject. (98f1b9c37) (ee2d17418) - import changes from rmottola/Arctic-Fox: - Bug 1140670 part 1. Just use the global, not the proto's parent, as the default parent in NewObjectWithGivenTaggedProto. (d2ef7ee90) - Bug 1140670 part 2. Just use the global as the parent in js::CreateThis and js::CreateThisForFunctionWithProto. (025d25703) - Bug 1140670 part 3. Add an assertParentIs() for asserting the parent is something specific and use it in various places to eliminate getParent() calls. (d814a6344) - Bug 1140573 part 1. Drop the parent argument from JS_NewFunction. (d657e25c7) - Bug 1140573 part 2. Drop the parent argument from JS_NewFunctionById. (2259f4027) - Bug 1140573 part 3. Drop the parent argument from js::NewFunctionWithReserved. (84ab2d944) - Bug 1140573 part 4. Drop the parent argument from js::NewFunctionByIdWithReserved. (a10821f1a) - Bug 1142266. Remove the parent argument from js::NewObjectWithProto. (efe9144e3) - Bug 1142241. Stop using getParent() in js::GetObjectEnvironmentObjectForFunction. (b04a4a38e) - some pointer style for better patching (608e1a6ad) (c1ae338ae) - import change from rmottola/Arctic-Fox: - Bug 1133085 - PropDesc::initFromPropertyDescriptor should understand JSPROP_GETTER without JSPROP_SETTER and vice versa. (d83f16200) (d86d78c8b)

I released v3.0a for English. http://blog.livedoor.jp/blackwingcat/archives/1980734.html