UCyborg

Your certificate store is outdated, that's why MSFN isn't green, which it normally is, even on XP. Outdated store also means it doesn't have information about revoked certificates, so it could be showing green when it normally wouldn't. Windows normally pulls CA certificate from MS servers when you visit particular website, since that doesn't work on XP anymore, folks were updating them manually, which has a side effect that you get all CA certificates MS has, while you would only have a fraction of them normally, depending on what sites you visit. Common sites still seem to use compatible algorithms, so a good chunk of them still show normally. But when my bank still required certificate for personal identification few years back, all I got in 360Chrome was Chinese error when visiting the site, I couldn't copy it anywhere to see what it means, making the browser useless for banking, so it was Mozilla to the rescue. Back then there was only Russian repack of the 360Chrome if I recall correctly. This is the big reason why I thought for quite some time in my mind that there are better browsers out there, incomprehensible errors are off-putting to the end user and so are empty error pages with only a numeric code in URL bar.

I might, got latest Ungoogled Chromium 118 to launch, it loads web pages as well, but it normally crashes on resolving delay-imported function QueryUnbiasedInterruptTimePrecise, Win8.1 only has version without "Precise". Did a bit of reading on x64 calling convention, might explain why initial DiscardVirtualMemory hack wasn't as disastrous on 64-bit binaries, first four parameters of a function call are passed in CPU registers, not on stack. Patch for 64-bit chrome.dll version 118.0.5993.88: >chrome.dll 0000000000294616:48->EB 0000000000294617:89->13 0000000000294618:D6->CC 0000000000294619:48->CC 000000000029461A:89->CC 000000000029461B:CF->CC 000000000029461C:E8->CC 000000000029461D:2F->CC 000000000029461E:1B->CC 000000000029461F:44->CC 0000000000294620:0A->CC 0000000000294621:85->CC 0000000000294622:C0->CC 0000000000294623:74->CC 0000000000294624:1D->CC 0000000000294625:48->CC 0000000000294626:89->CC 0000000000294627:F9->CC 0000000000294628:48->CC 0000000000294629:89->CC 000000000029462A:F2->CC 0000000000299C77:48->EB 0000000000299C78:89->11 0000000000299C79:F1->CC 0000000000299C7A:4C->CC 0000000000299C7B:89->CC 0000000000299C7C:FA->CC 0000000000299C7D:E8->CC 0000000000299C7E:CE->CC 0000000000299C7F:C4->CC 0000000000299C80:43->CC 0000000000299C81:0A->CC 0000000000299C82:85->CC 0000000000299C83:C0->CC 0000000000299C84:0F->CC 0000000000299C85:84->CC 0000000000299C86:FA->CC 0000000000299C87:00->CC 0000000000299C88:00->CC 0000000000299C89:00->CC 0000000000299F38:4C->EB 0000000000299F39:89->0D 0000000000299F3A:F1->CC 0000000000299F3B:4C->CC 0000000000299F3C:89->CC 0000000000299F3D:E2->CC 0000000000299F3E:E8->CC 0000000000299F3F:0D->CC 0000000000299F40:C2->CC 0000000000299F41:43->CC 0000000000299F42:0A->CC 0000000000299F43:85->CC 0000000000299F44:C0->CC 0000000000299F45:74->CC 0000000000299F46:9A->CC 0000000005666C6E:48->EB 0000000005666C6F:89->0D 0000000005666C70:F9->CC 0000000005666C71:4C->CC 0000000005666C72:89->CC 0000000005666C73:F2->CC 0000000005666C74:E8->CC 0000000005666C75:D7->CC 0000000005666C76:F4->CC 0000000005666C77:06->CC 0000000005666C78:05->CC 0000000005666C79:85->CC 0000000005666C7A:C0->CC 0000000005666C7B:74->CC 0000000005666C7C:1D->CC 000000000BD5774C:50->00 000000000BD5774D:72->00 000000000BD5774E:65->00 000000000BD5774F:63->00 000000000BD57750:69->00 000000000BD57751:73->00 000000000BD57752:65->00 000000000BD58042:31->30 000000000BD5B02A:44->56 000000000BD5B02C:73->72 000000000BD5B02D:63->74 000000000BD5B02E:61->75 000000000BD5B02F:72->61 000000000BD5B030:64->6C 000000000BD5B031:56->41 000000000BD5B032:69->6C 000000000BD5B033:72->6C 000000000BD5B034:74->6F 000000000BD5B035:75->63 000000000BD5B036:61->00 000000000BD5B037:6C->00 000000000BD5B038:4D->00 000000000BD5B039:65->00 000000000BD5B03A:6D->00 000000000BD5B03B:6F->00 000000000BD5B03C:72->00 000000000BD5B03D:79->00

Just replacing "DiscardVirtualMemory" with "VirtualAlloc" in opera_browser.dll (or equivalent in other browser ) doesn't make much sense, they're different functions and have different number of parameters, leaving VirtualAlloc to be called in place of DiscardVirtualMemory corrupts the stack after function returns, plus it'll receive some other values in the stack in place of its 3rd and 4th parameter, so it can't know what it should do exactly. When I got 32-bit Opera 104.0.4944.33 running with just that string replaced, it didn't take long for the tab that opened on first launch to crash. Chromium uses DiscardVirtualMemory in its memory manager, it's a faster way to do one specific operation that could be done with VirtualAlloc with MEM_RESET flag pre-Win10. There is still fallback to VirtualAlloc in place, so easiest way to get it going correctly is to simply skip the code that would call DiscardVirtualMemory. I think they used to check if function exists before dropping pre-Win10 OS, might have to check older revisions to be sure. Obviously, we still have to replace the string "DiscardVirtualMemory" in the import table so the loader is happy when it loads the DLL. Here's the full patch that can be applied with x32dbg (included with x64dbg), this is only for opera_browser.dll of 32-bit Opera 104.0.4944.33, started with this one as I'm more at home with x86 code. The text file usually has *.1337 extension. I was working with a very recent version of x32dbg, it's compatible with Windows 8.1. >opera_browser.dll 000000D0:89->EA 000000D1:E9->78 000000D2:E4->E5 032BD3CB:57->EB 032BD3CC:56->11 032BD3CD:E8->CC 032BD3CE:24->CC 032BD3CF:79->CC 032BD3D0:2D->CC 032BD3D1:06->CC 032BD3D2:85->CC 032BD3D3:C0->CC 032BD3D4:75->CC 032BD3D5:08->CC 0448C04F:53->8B 0448C050:8B->7C 0448C051:7C->24 0448C052:24->04 0448C053:08->E9 0448C054:57->80 0448C055:E8->00 0448C056:9C->00 0448C057:8C->00 0448C058:10->CC 0448C059:05->CC 0448C05A:85->CC 0448C05B:C0->CC 0448C05C:75->CC 0448C05D:7A->CC 0448C05E:8B->CC 0448C05F:54->CC 0448C060:24->CC 0448C061:08->CC 0448C062:8B->CC 0448C063:5C->CC 0448C064:24->CC 0448C065:0C->CC 0448C066:8B->CC 0448C067:7C->CC 0448C068:24->CC 0448C069:10->CC 0448C06A:E9->CC 0448C06B:E5->CC 0448C06C:FE->CC 0448C06D:FF->CC 0448C06E:FF->CC 0448C0C2:56->8B 0448C0C3:8B->7C 0448C0C4:7C->24 0448C0C5:24->0C 0448C0C6:10->EB 0448C0C7:57->38 0448C0C8:E8->CC 0448C0C9:29->CC 0448C0CA:8C->CC 0448C0CB:10->CC 0448C0CC:05->CC 0448C0CD:85->CC 0448C0CE:C0->CC 0448C0CF:75->CC 0448C0D0:2F->CC 0798707E:53->EB 0798707F:57->09 07987080:E8->CC 07987081:71->CC 07987082:DC->CC 07987083:C0->CC 07987084:01->CC 07987085:85->CC 07987086:C0->CC 07987087:74->CC 07987088:2F->CC 0A7FCF04:44->56 0A7FCF06:73->72 0A7FCF07:63->74 0A7FCF08:61->75 0A7FCF09:72->61 0A7FCF0A:64->6C 0A7FCF0B:56->41 0A7FCF0C:69->6C 0A7FCF0D:72->6C 0A7FCF0E:74->6F 0A7FCF0F:75->63 0A7FCF10:61->00 0A7FCF11:6C->00 0A7FCF12:4D->00 0A7FCF13:65->00 0A7FCF14:6D->00 0A7FCF15:6F->00 0A7FCF16:72->00 0A7FCF17:79->00 When importing it into x32dbg, say yes to both prompts that appear. You have to at least open opera_browser.dll before and "launch" it before you can right-click->Patches (or CTRL+P)->Import, then Patch File to save the patched copy on the disk. I like things to look clean so it's not the most minimalistic...back in the day I went out of my way to leave no empty gaps, now that makes it super annoying for someone who would want to compare changes afterwards! About "api-ms-win-core-localization-l1-2-2.dll" error, you don't get it if you actually use DWrite.dll from Windows 10 Build 9926, but with many newer versions, they're linked to "api-ms-win-core-localization-l1-2-2.dll" rather than "api-ms-win-core-localization-obsolete-l1-2-0.dll". The latter is supplied with Windows 8.1. Still, I used DWrite.dll from my daily driver Win10 installation, so I just created a hard link of system "api-ms-win-core-localization-obsolete-l1-2-0.dll" named as "api-ms-win-core-localization-l1-2-2.dll" to satisfy DWrite.dll's dependencies without having to modify DWrite.dll, as some have apparently done in the past. Dixel's suggestion about "api-ms-win-core-localization-l1-2-0.dll" is redundant, the one supplied with Windows 8.1 already satisfies the other dependencies of newer DWrite.dll, related to localization APIs and most importantly, doesn't contain any API that "obsolete" version does. To put it simple, there's just one lone function that was exported through "api-ms-win-core-localization-obsolete-l1-2-0.dll" at one point on Windows 8.1 and early Windows 10 builds, but got moved to "api-ms-win-core-localization-l1-2-2.dll", so that's what newer DWrite.dll references. Today's Windows 10 and 11 no longer use stub DLLs, it's all handled internally by the loader, so even when there's no actual DLL referenced (despite being called DLL), the special name with the help of the logic in the loader makes a link to real DLL where particular function implemented. Just read the bloody docs...those who actually want to learn something. It still has to be run without sandbox, which I hear is pretty much Win10 exclusive in its current form.

So older Windows 10 builds and Windows 8.1 for instance still use those pseudo/stub DLLs. I compared DWrite.dll from my Win10 20H2 install and Win8.1 ISO, latter updated till December 2017. Win10's DLL is linked to a function implemented in Vista era LCIDToLocaleName under api-ms-win-core-localization-l1-2-2.dll (points to kernelbase.dll), no other functions are linked to under that contract name while Win8.1 DLL uses the name api-ms-win-core-localization-obsolete-l1-2-0.dll pointing to the same function and the DLL where it's implemented. Maybe using system copy of api-ms-win-core-localization-obsolete-l1-2-0.dll renamed to api-ms-win-core-localization-l1-2-2.dll would work. Link to DWrite.dll from the video is dead BTW.

If only object.hasOwn is an issue...

Because it's not a DLL, it's an API contract name. https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets CRT may have had pseudo DLLs for runtime compatibility with older Windows, VC Redist 2015-2019 was (is?) compatible with XP at some point, which knows nothing about API sets. No such thing for core Windows API functions, if Win8.1 doesn't recognize the contract name, the referenced API function likely isn't implemented on it.

360Chrome isn't your standard Chromium fork, hence some things are missing or don't work or work differently. For example, not sure if it reads Group Policies either or if there's a different key they're read from, if I remember correctly, chrome://policy page doesn't work either, so you wouldn't be able to check which policies are active. Unless you fancy its distinct characteristics, Kafan MiniBrowser would be closer to standard Chromium when it comes to XP compatible browsers. Though NPAPI support, which 360Chrome has, would be nice in mainstream browsers in general...why can't I have full-featured PDF reader in a browser tab, it was standard back then. And ignoring some unique traits of 360Chrome, for Windows 7 and later especially, I'd also say there are better options out there IMHO. Widevine is a separate proprietary module with its own requirements, so no backport fork of a browser to XP will make it work there. Widevine just decodes the video stream, everything else, the player is just HTML, CSS, JavaScript. JavaScript calls Widevine to do the decoding part, it's usually used to implement interactivity with the player interface as well.

It might be another sign of things to come. Remember how structuredClone appeared on MS Edge download page? Later, it shows up on another website you're visiting and it turns out the implementation that has landed in UXP in the meantime isn't even good enough for it. OT: I don't use much stuff from MS Store. Not sure what my bank is cooking up, they have a new Android app (needs Android 6 instead of 5 like old one, so I'm still 1 version ahead), they might cancel the old one in the future, comments on Google Play say it's worse (for banking tasks) and if/when they bump up requirements or if I won't be able to activate if/when they cancel the old one (running custom OS, which can be problematic for picky apps), I might switch to Windows app to be able to access their web interface. I tried it in the past, but stuck to mobile app, because I have no idea how to backup Windows' app data in case of reinstall/migration to another PC and it's more likely for me to tear my Windows apart and start over compared to my phone. I can backup the data in its folder, but it's tied to the original Windows user account somehow. Even making new account and going out of the way to change SID to the old one doesn't help. Maybe that Protect folder or wherever the heck Windows keeps crypto stuff is involved...haven't tried, I think I only ever read something about it later, maybe even on this forum regarding how Chromium ties certain data in the user profile to Windows user account. The idea of having a dedicated virtual machine also crossed my mind, but didn't feel like bothering with that. I much preferred the old way when you had your personal certificate in the browser and that was it, but no, we're forced to use these stupid apps. The other thing I experimented with that is obtainable through MS Store were the new Media Foundation codecs. Chromium can be set to use them with MediaFoundation for Clear flag (chrome://flags/#enable-media-foundation-clear or edge://flags/#edge-mf-clear-playback-win10 in case of MS Edge), they can be more performant than the ones it normally uses, though there are glitches, eg. forget leaving YouTube playing in the background. Not much is written about the flag, but on my low-end laptop from 2014, Windows 10 + Chromium with that flag is the only way to have smooth 1080p @ 60 FPS video in a browser. I must have experimented with combinations of Pale Moon, Firefox, Windows 8.1, Linux in the past, but didn't find as good performance with mixing those. Though for H.264 codec, which I stick with on the laptop, no additional codec has to be installed, unlike for VP9 or AV1. What they're cooking with Win11, no comment...what would happen if no 3rd party devs were working on restoring good functionality, would anyone even notice?

@dmiranda While I think I'm careful, I'm not super careful, though when it comes to computer security, it's been my experience that probability of an awful incident is very low, low enough at least that I don't have to be paranoid about it. And if I can't have few nice things in this cursed existence, then to hell with everything!

I got both D3D9 and WebGL 2 running here (as slow as on roytam1's browsers) with enabling webgl.disable.angle and layers.prefer-d3d9. ANGLE is useless on my end as even something as old as Lights by HelloEnjoy errors out. It works on old Firefox 6 through ANGLE though. Testing on multiple operating systems made me believe Chromium still remains the only decent option for running WebGL content at high performance, as high as it can get inside a web browser at least, just not on a legacy system like Windows XP. No crashes of the browser in other areas here, though I still have this shim in place for mypal.exe: Haven't checked if it's still actually needed with the latest version, but in the past, it would definitely prevent crashes in certain cases, if I remember correctly, WebAssembly content was prone to crashing in particular. Only browser crashes, no BSODs ever here on my XP x64, both multi-process and OMTP enabled as well.

Bitmovin has to say "widevine", if it says "No DRM", you're watching plain unencrypted stream, so Widevine isn't working.

Specifically, WidevineCdm folder taken from fresh install of latest Windows 7 compatible 32-bit Chrome 109 and put into 360Chrome's "components" folder as "widevine12" will work, at least it should on Windows 7+ at the time of this writing. Don't have ready Win7 install anywhere, but it worked on 10. I also tried period correct Widevine version from Chrome 86, this one does not work anymore, got SOURCE_ERROR on https://bitmovin.com/demos/drm.

In 360Chrome, it should work through SwiftShader, so no GPU used at all, which is very slow, but could be tolerable for more static content. If you visit chrome://gpu page, it might contain the hint why it doesn't work. But it won't be obvious, messages about nothing being hardware accelerated are just the way things are on XP. Yup, that's normal, general web stuff still runs OK on CPU and Chromium is quite performant unless the hardware is very dated. Though GPU assistance would still be obvious on systems with weaker CPU/better GPU. There's graphical content out there that doesn't use WebGL, just plain HTML5 + JavaScript, where the difference between using CPU alone versus putting GPU into the mix is more obvious (https://www.kevs3d.co.uk/dev/). But it seems to me that normal websites simply benefit from Chromium being able to handle huge loads of JavaScript, which by itself relies only on CPU, particularly those websites that don't show anything with JavaScript disabled. Literally toggling everything WebGL might not be the best idea, but in case of Firefox forks, diagnostic info is on about:support page. In that case, would be best to continue this conversation in roytam1's thread. And don't forget doing things on the GPU in XP era in web browsers was a novelty. More advanced multimedia on the web was more or less delegated to Flash Player, which only got 3D rendering capabilities on the GPU with version 11.0, which was released in 2011, just 3 years before XP's EOL date and already 2 years into extended support period. Normal 3D games on the other hand, AFAIK, software rendering option started disappearing around late nineties.

Yay, another broken website: https://apps.microsoft.com/ SyntaxError: await is a reserved identifier Edit: So much issues reported on the Web Compatibility forum on Pale Moon. You know, people on these rotten planet really should slow down and take a good look at where bloody hell they are. But no, they're like hamsters on the spinning wheel. Just keep on spinning and spinning. They smell the cheese and keep chasing it.

My bank requires dedicated 2FA app, either HID Approve or bank's own Android app. HID Approve is available for Windows 10+ in addition to Android version. You have to confirm login with the code you've set when you've setup the app after you try logging in with user name and password. Another bigger bank here only has a smartphone app as an option to access the web interface and consequentially to do any online banking at all. Accessing the web interface is super convoluted from what I've seen, after you enter user and pass, you put in the one-time password generated by the app, then you have to confirm with two other codes...at least I think there were two. What I remember the app has two types of code, normal OTP and another signing code, which works by the principle of challenge-response, get one code on one end and enter it in the app to get the final code. But you only have to deal with one numeric code (password) you've set at the beginning if you do everything from the smartphone app. Edit: I'll just add correction here about the bigger bank instead of editing inaccurate original writing due to not remembering exact details, on the website, you're prompted for a user name and one-time password (no normal password here) from the mobile app, when you're in, the site gives you a numeric code, which you input into the app to get the final code. The only caveat, each time the mobile app is about to give you any code, you have to confirm with the code you normally login to the app.

wceisvista.inf is fine and is used by default on later Windows systems. Assuming something's not messed up in the OS. That .inf pulls in netrndis.inf. Maybe something's messed up in that direction. My XP x64 update state should be-up to 2011, plus an odd newer crypt32.dll update I don't recall.

Stirring the pot much? ALSR flag (aka. Dynamic Base) was enabled over a decade ago, as is pointed out in the status of linked bug report, which, from the quick glance, is more related to how Mozilla built their browser over a decade ago. Better question would be how Chinese built this browser and what have they done with the sandbox? Too bad the flag doesn't do anything for XP users in either case. Or maybe it's a good thing? Nothing better than per-process instance DLL duplication/relocation and extra memory consumption that comes with it, huh? As a regular consumer of WebGL content, I wonder how come I've not been hacked yet? Though visiting Shadertoy on Vista pretty much DoSed the 360Chrome on my end and support of WebGL on the remaining XP browsers on XP leave much to be desired (total no-go for Chromium variants), troubles of legacy operating systems belonging in a museum are hardly a concern to me as a regular Windows 10 user, where I use nothing less than 64-bit Chromium variants (important for effectiveness of ASLR) with High Entropy VA flag enabled on all executable modules.

@NotHereToPlayGames It's posible this only started with enough system uptime or hibernate/resume cycles. Since there are longer periods between messing with older systems, memory gets fuzzy. Last fresh boot of Vista was in January 2023 while I put the 360Chrome there in December 2022, from that point backwards, it was months since last fresh boot, it could be that I'm remembering the issue from between December 2022 and January 2023. What I do remember clearly is trying to see if Vista is any more resilient in that regard on my system with my usage patterns and it turned out eventual reboot is in order, like with newer MS OS. It takes 2 or 3 months easily on any OS before something odd happens, so can't say any system is better or worse than the other. It's not something I attempted with XP because this OS starts getting on my nerves in less than a single afternoon due to certain technical limitations. I have 360Chrome running for 1 hour now and sound still works...played a bit of Quake III (the web version) against the bots. This is interesting, I thought it was supposed to be skipped anyway as otherwise you couldn't ungoogle it or do any mod of the executable files.

I honestly don't rememember exactly. Must have been at least 1h. 2022

I've always had delays after cold boot with bigger software, regardless of Windows version. Vista and 10 (presumably 11 as well) seem more dedicated at preloading everything they can in RAM, so if you've got the prefetcher trained to load the right files, it could be faster when you launch it if you wait a while after boot/resume from hibernation. Vista+ will always pick another base address for executables with ASLR flag, the process in this case is simply more intelligent as base address will be shared among same module in case of multiple instances of the process that loads said module so it won't waste extra memory like in XP. Allocating memory at higher addresses tends to be slower than allocating at lower addresses (architecture thing?), this likely applies to memory-mapping files in memory, which would explain higher delay when manually rebasing DLL at higher address. I didn't have this error when messing with 360Chrome on Vista. But when using that browser, audio eventually died system-wide and I had to restart Windows Audio service. It gets old after a while.

So the year is 2023 and MS Edge still seems to be the only Chromium-based browser that follows Windows settings for font-rendering and so those damned thin fonts are easily avoided. There's hardcoded SK_GAMMA_CONTRAST value in the source code here, so as the workaround for other browsers, especially closed-source ones or even stock *Chromium, I wonder if there's a trick to find this value in its massive binary and change it according to the user preference. If I read this right, it seems there are two occurrences of this particular value, in /third_party/skia/src/core/SkScalerContext.cpp and /third_party/skia/src/text/gpu/DistanceFieldAdjustTable.cpp. Maybe it would be easier with debugging symbols, but I doubt they're published anywhere. I'm aware extension can change the text after it's rendered, but I'd prefer if it was rendered with set parameter from the start, this should also work for browser's GUI. [*] Takes a decent PC, disk space and time to figure out and compile this monster from source code. Edit: I haven't scanned for unique occurrences of 0.5 yet, will attempt later.

Ungoogled Chromium has a flag for this (chrome://flags/#disable-search-engine-collection).

Is there a website with the same issue that doesn't require login? Someone could let the upstream know, but they'll prefer to see the issue reproducible on their own browser, preferably on a publicly accessible website not requiring login. What do user scripts have to do with browsers running on old Windows NT specifically? Similar for that UXP extensions thread.

I know, he could try it in 360Chrome.

There's an old Ant Video Downloader in Classic Add-ons Archive, for downloading videos off various sites. You may replace original yt.js, located in /chrome/content/grabber/prov/yt.js, with this one, may make it work for YouTube again: https://gist.github.com/UCyborg/318f4e28fc94b6c7b4735592be038935 The extension changes tab bar appearance for some reason, also back-forward cache will be disabled even on sites where it usually works, means no instant-navigation with back/forward buttons when it normally occurs, unless handled specially like YouTube. Also downloading off YouTube is still finicky, maybe it shows the wrong video title, maybe it doesn't show it, just navigate forward/backward, should get something, even if you have to rename it in the end since it picked the one you viewed before.