Leaderboard

... Probably not, so let me summarise the gist of what @j7n was talking about in his recent posts: 1. The H.264 codec is probably the best choice when you're about to playback video on a system with low H/W resources (weak CPU, low-end GPU) and a legacy OS like Win7 SP1; the decoder is natively supported by the OS (not the case in XP SP3) and via implementations like WMF/MSE, an MP4 video can be played back within a compatible browser with hardware acceleration and hardware decoding (not the same things); most Win7-era graphics cards have H.264 decoding support built-in, so even when the MP4 video is being played back in a standalone media player, video decoding is performed by the GPU, not CPU... 2. Google have recently started producing their h.264 (aka avc1) youtube encodes at very low video bitrates, even for "high" resolutions, such as 720p/1080p; thus, while the h.264 YT encodes should be preferred for downloading (because they need less computer resources to be played back once downloaded), the stingy bitrate results in sub-optimal visual experiences (blurry moving images, video artifacts of various sorts, etc.). 3. OTOH, Google continue to produce their VP9 YT encodes at exceptional bitrates, especially for the FHD/UHD resolutions (>=720p); these are large files to download, to begin with, but, once downloaded, playback on low-end machines puts a heavy toll on the CPU, because VP9 is being software-decoded; I've not researched this properly, but graphics cards with integrated, native, VP9 decoding support (aka VP9 hardware decoding) only came in the later 2010s, as part of mostly Win10 machines... TL;DR: To have the best visual experience, j7n has to fetch the VP9 YT encodes, but these are detrimental to his under-resourced machine (mostly the CPU is being utilised for video playback, resulting in excess heat and energy consumption, etc.).

So did I now: https://developer.paypal.com/tools/sandbox/ so probably NOT what you're after ; if you're limited to using UXP-based browsers (on Windows XP SP3?), then am afraid they're now dead in the water with regards to PayPal; the issue needs to be escalated upstream by users of the "official" UXP browsers (Pale Moon and Basilisk, on Win7SP1+), in the hope upstream can come up with a solution, but the relevant PMForum thread hasn't seen any further activity since July 30th... OT for this thread, but you may also appeal for help to Feodor2 in MyPal's GitHub issue tracker ; if still on XP, you might try how the Supermium browser fares on PayPal these days; might prove your only recourse...

New build of post-deprecated Serpent/moebius for XP! * Notice: This repo will not be built on regular schedule, and changes are experimental as usual. ** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions. Test binary: Win32 https://o.rthost.win/basilisk/basilisk55-win32-git-20250823-69d606e5d-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk55-win64-git-20250823-69d606e5d-xpmod.7z repo: https://github.com/roytam1/basilisk55 Repo changes: - ported from UXP: Issue #2837 - Implement `prefers-reduced-motion` media query. (df3b2134) (796fbddde) - ported from UXP: Issue #1899 - Remove MDN docs tooltip and link code from devtools. (842cc607) (748599a3f) - ported from UXP: Issue #1843 - Clean up WindowsVersion.h (7af71cb3) (513b16251) - import from UXP: Issue #2847 - Extend `-moz-os-version` media query with win11. (72318013) (721e8343a) - ported from UXP: Issue #2258 - Part 1: Support XCTO:nosniff when navigating. (e56e5d6c) (7c405cfe3) - import from UXP: Issue #2258 - Part 2: Move XCTO:nosniff check into sniffers. (cca20ae1) (fb7674759) - import from UXP: Issue #2258 - Part 3: Allow sniffing with XCTO:nosniff + empty MIME type. (707c3e3f) (d1fd2e3b3) - import from UXP: Issue #2258 - Part 4: Clean up unused pointers. (bd734f79) (a3d299d64) - import from UXP: Bug 1875345 - Report 24 instead of 32 as the colorDepth (and pixelDepth) on Linux (assuming 8 of 32 bits are for the alpha channel). (e3de626c) (780aa8768) - import from UXP: Issue #2850 - Alias `:focus-visible` to `:-moz-focusring` (6d47d819) (98b67440c) - nss: update certdata and bump ckbi version to 2.80 - Bug 1974511 - Add SwissSign 2022 Roots to NSS r=jschanck - Bug 1972391 - Add TrustAsia Dedicated Roots to NSS r=jschanck - Bug 1961848 - Remove expired Baltimore CyberTrust Root r=jschanck - Bug 1978677 - remove expired explicitly distrusted DigiNotar lookalike root r=nss-reviewers,jschanck (9815f4533) - import from UXP: [gfx] Guard against possible race via gfxFontEntry::GetFontTable. (7cadc57d) (5748e6157) - import from UXP: [js] Error-check pthread calls (425f38ff) (2bf79a7ff) - import from UXP: [NSS] Avoid leak in pkcs12 decoder. (fe21538d) (69d606e5d)

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20250823-3219d2d-uxp-e5ea29554a-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20250823-3219d2d-uxp-e5ea29554a-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20250823-3219d2d-uxp-e5ea29554a-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20250823-d849524bd-uxp-e5ea29554a-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20250823-d849524bd-uxp-e5ea29554a-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20250823-d849524bd-uxp-e5ea29554a-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20250823-d849524bd-uxp-e5ea29554a-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20250823-d849524bd-uxp-e5ea29554a-w7plus-avx2.7z Official UXP changes picked since my last build: - Issue #2837 - Implement `prefers-reduced-motion` media query. (df3b213459) - Issue #1899 - Remove MDN docs tooltip and link code from devtools. (842cc60707) - Issue #1843 - Clean up WindowsVersion.h (7af71cb345) - Issue #2847 - Extend `-moz-os-version` media query with win11. (723180132d) - Issue #2258 - Part 1: Support XCTO:nosniff when navigating. (e56e5d6cb1) - Issue #2258 - Part 2: Move XCTO:nosniff check into sniffers. (cca20ae131) - Issue #2258 - Part 3: Allow sniffing with XCTO:nosniff + empty MIME type. (707c3e3fa8) - Issue #2258 - Part 4: Clean up unused pointers. (bd734f795c) - Bug 1875345 - Report 24 instead of 32 as the colorDepth (and pixelDepth) on Linux (assuming 8 of 32 bits are for the alpha channel). (e3de626c1f) - Issue #2850 - Alias `:focus-visible` to `:-moz-focusring` (6d47d819fa) - [gfx] Guard against possible race via gfxFontEntry::GetFontTable. (7cadc57d49) - [js] Error-check pthread calls (425f38ff84) - [NSS] Avoid leak in pkcs12 decoder. (fe21538da4) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - nss: update certdata and bump ckbi version to 2.80 - Bug 1974511 - Add SwissSign 2022 Roots to NSS r=jschanck - Bug 1972391 - Add TrustAsia Dedicated Roots to NSS r=jschanck - Bug 1961848 - Remove expired Baltimore CyberTrust Root r=jschanck - Bug 1978677 - remove expired explicitly distrusted DigiNotar lookalike root r=nss-reviewers,jschanck (f5307ea861) Update Notice: - You may delete file named icudt*.dat inside program folder when updating from old releases. * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

@kuja killer , follow up: Some 2 hours after my previous post, my modem-router had to be restarted (details that necessitated that are OT here), so my ISP assigned a new IP address to my internet connection; whether this is somehow relevant or a sheer coincidence, I have no idea ... Today, after reading your latest reply, I tried to re-access https://www.paypal.com/signin (as I had done yesterday) with the same NM28 copy as before; and guess what? I was hit by the same breakage you reported: I additionally have a page header instructing me to: "Please enable JS and disable any ad blocker" but JS is enabled and uBlock Origin (legacy) completely disabled; as you detailed in your post, sliding the blue button to the right (to "prove you're a human") turns it for half a second into green (with a white tick), but then the "you've been blocked" (in Greek, in my case) page appears... It is then impossible to access the proper sign-in page ... I opened Dev Console (which PayPal detected and did NOT like ) : but nothing stands out there for me... On the same machine (with the same IP address), browsers like r3dfoxESR-115.13.0 (or even the most current, r3dfox-140.0.4) will also be presented with the human verification challenge, but is then successfully passed, after which a redirection takes place to the sought-after sign-in page... So, PayPal have started requiring "a feature" (JS, CSS, both) that is to be found on relatively (more) recent Firefox incarnations, but isn't found currently in UXP browsers (and MyPal); this is based on feature detection, so a SSUAO won't work, as noted... And yes, PayPal are using their "own" captcha: https://geo.ddc.paypal.com/captcha?..... Further researching this, Google have provided an alternative sign-in page, https://www.sandbox.paypal.com/us/home => https://www.sandbox.paypal.com/signin which loads for me straight away in both NM28 and St52; as said already, I don't have valid credentials to test whether one can successfully log-in, hopefully it'll work for you (assuming that signing-in to "www.sandbox.paypal,com" logs you, too, to "www.paypal,com") ... Regards ...

@kuja killer Paypal-related issues have also appeared in the upstream forum: https://forum.palemoon.org/viewtopic.php?f=61&t=32581 https://forum.palemoon.org/viewtopic.php?p=264391#p264391 Mixed reports from various users there, probably depending on their physical location; PayPal are conducting various A/B tests, it seems (read e.g. this PMForum thread ); user at the second link I posted thinks that it's NOT CloudFlare, but a PayPal-specific recaptcha (security check) that is NOT compatible with UXP-based browsers ... Can you try again with a fresh NM28 profile, where you block nothing? FWIW, with my ISP's Greek IP, I can access https://www.paypal.com/signin in NM28 at this very time without issue, but, as I don't have an account with them, can't proceed any further...

If it fails, don't give up, try NtCreateKey. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-zwcreatekey

You're very welcome! Let us know the result, what finally worked for you. Thanks.

For lower OS in SHELL32 SHGetPropertyStoreForWindow replace with SHGetStockIconInfo

In NTDLL NtOpenKeyEx needs to replaced with just NtOpenKey, it's even safer this way, why would they need the extended variant!?!

My trust in you has no bounds, I had no doubts you would find.

Yes, I saw, but with the already ported version 136 we could do just fine for about two years, as you see, Thorium and Supermium only started to completely fail after two years from the initial version 111 (which in my humble opinion they are based on). My PC also sucks by the modern day standards, its CPU is very similar to the severely outdated CPU used by NotHereToPlayGames.

For Windows 98 Realtek made gigabit drivers only for PCI cards. And for some reason... drivers made for PCI gigabit cards do not work with PCI-E cards. On the other hand the NDIS2 universal driver is supposed to work with the entire gigabit line no matter what model. I have used many times Realtek NDIS2 drivers. RTGBND.DOS works with DOS, Windows 3.11, 95OSR2 and 98. In Windows 98, you should install this driver from control panel and let Windows make all the configuration changes, like in this video (@ minute 21 is the actual installation of Realtek 8111 PCI-E in Windows 98SE)

Strangely, that redirects to http://fe2.update.microsoft.com/microsoftupdate. That trailing period looks wrong and the link just gives a server error page. (That may have been the original problem, but I couldn't see the error because IE's https: handling hid it from me.) But if you remove that trailing period (i.e., http://fe2.update.microsoft.com/microsoftupdate), it works! (BTW, MU takes way longer to scan than WU, but that makes sense because I have Office 2010 and I think one of its cumulative updates triggers the old "scans forever" bug. Oh, well; at least I can get to the scan now!) I'd still love to know why the MU link on the WU page worked a few days ago but doesn't now, but since removing the trailing period works, I'll just bookmark the link that way and not worry about it. Yes I copied your config.ini entries from your screen shot earlier. They work fine but didn't solve the MU problem, since the redirect on M$'s server is apparently wrong (has that extra period as shown above). If you want to have a working Microsoft Update shortcut in your start menu you have to add http://update.microsoft.com in trusted zone of IE (security level must be high) and to modify config file of ProxHTTPSProxy in the way I described above. Without these modifications I had problems to open MU site randomly using Microsoft Update shortcut in my start menu. For me it is now working flawlessly. Look at my screenshot! https://imgur.com/2Nr0xEi

I agree to @xpandvistafan. You have to avoid https-links to open Microsoft Update. If you want to access MU directly try http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de (I am German), for you http://fe2.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=en. And you have to check config.ini of ProxHTTPSProxy. Under section [SSL No-Verify] I added fe2.update.microsoft.com and deleted update.microsoft.com under sections [SSL Pass-Thru] and [BYPASS URL]. This is working for me although I use predominantly HTTPSProxy. If wanted I can provide my config file of ProxHTTPSProxy.

wmic.exe is a WMI command-line program. Maybe you have to set a path to where it is located in your system (path command). I have it twice in c:\WINDOWS\system32\wbem\ and c:\WINDOWS\system32\dllcache\. Usually these paths already exist.

In my opinion this cmd file is not working properly. So I decided to disable sfc to do it manually where the batch file fails. You can do registry manipulation by reg file (copy the section in cmd file to reg file) and apply all patches which were executed. I did it and it works. I think this file has to be executed as admin.