Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won

  • Donations

    0.00 USD 
  • Country


VistaLover last won the day on June 14 2023

VistaLover had the most liked content!

About VistaLover

Profile Information

  • OS
    Vista Home Premium x86

Recent Profile Visitors

30,619 profile views

VistaLover's Achievements



  1. Another Supermium 124 release made it to the GitHub Releases Section: https://github.com/win32ss/supermium/releases/tag/v124 Though it is still labelled as "Pre-release", the author claims it's "the main release of Supermium 124"; among the Release Notes: The distributions bundle (official) progwrp.dll-v1.1.0.5018 ; and before any member of the known "family" asks anew, no, the "not-possible-to-disable-the-CH-API-on-Sm122+" issue hasn't yet been addressed (else, it would surely have been mentioned inside the Release Notes ) ... Kind regards to all ...
  2. ... But it did work in my posted test; FWIW, 127 just made it to the Windows BETA channel: https://chromereleases.googleblog.com/2024/07/chrome-beta-for-desktop-update.html The emphasis on my previous post was on "current Cr version", I didn't specify a Cr channel, did I? (... Why is it my distinct impression you just posted with an intent to discredit me? Please, don't answer, since I won't answer back myself...) @66cats: I don't know what to tell you , with the default Cr86 UA I get this (Vista SP2 x86):
  3. Hi Dave ; I wish I were over at your part of the planet, where you currently have a pleasant 18C, while here we're in the middle of a never-seen-before July heatwave, about to last at least until the 27th (to get an idea, it's 23:34 now and the outside temp is at 35C ! ) ... Back on topic: Your ex-colleagues are simply blocking the version of 360EE you're using (on XP) due to the User-Agent-String it broadcasts; I suppose you're using one of the @NotHereToPlayGames's mods, so inside its loader you'll find the cmdline switch below: --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36" They outright block Chromium 86, so when the browser tries to load that page, it gets served an "errorcode337" and the tab ends up blank... This is a bad practice altogether, since Cr86 is perfectly capable of loading+rendering that site; to circumvent their block, just spoof a current Cr version: --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36" ... and Bob's your uncle: ... Might I also add that the page has a sub-optimal web design, not fit for desktop browsers and without any consideration for older, low on resources, hardware (e.g., it contains in its top part a constantly animating huge video/gif that consumes far too many CPU cycles on OSes without native H/W decoding, via GPU) ... Apologies for the rant, cheers and best wishes ...
  4. ... Do you have to be signed-in for this "bug" to occur? FWIW, replicating the search you referenced for that same item ("Shimano CS-HG41") with last WE's St52 (32-bit) build proceeded normally, as displayed below: Apologies if I'm missing something and "your" bug is actually a different one ... BTW, are you on a SSE-only CPU?
  5. Hi Dave ; I think a distinction should be made, so that other readers aren't being confused ... The "wrapper" library component of Supermium (which the Thorium author has also got permission to bundle with his browser, to make it XP+Vista compatible) comes originally from win32ss (win32 here at MSFN), it consists of only one DLL (named progwrp.dll) and the file version is currently in the 1.1.0.xxxx range... As you wrote already, the installer for Sm-v124-pre comes with v1.1.0.5016; that one apparently causes issues for some non-standard XP SP3 x86 installations, hence GitHub #686 was filed; inside that thread, win32ss has uploaded, as of this writing, six (6) iterations of progwrp.dll-v1.1.0.5017 and one (first) iteration of progwrp.dll-v1.1.0.5018 here which, technically, is the latest official offering ... OTOH, versions 1.2.0.xxxx belong to the alternate, let's call it "unofficial", "wrapper" library implementation by @IDA-RE-things ; at this time, this implementation consists of up to 3 separate DLLs and is mainly targeting Low-End (as in H/W) XP SP3 x86 older setups (slow HDDs, limited RAM, slow by today's standards CPU, etc.): https://github.com/IDA-RE-things/Chrome-xp-api-adapter/releases As posted by 66cats, the latest version of this alternate lib is ... Judging by your own (relatively powerful) H/W Dave, do you really need to use this alternate implementation? Can you spot noticeable differences between official and unofficial ? Cheers ...
  6. ... Read these GitHub comments, if one's after the x86 binaries: https://github.com/win32ss/supermium/issues/686#issuecomment-2183203030 https://github.com/win32ss/supermium/issues/686#issuecomment-2183230334
  7. ... Let me remind readers of this thread that the actual issue discussed here has been already reported to UXP-"upstream" (i.e. MCP: Moonchild Productions) by @UCyborg some three weeks ago: https://forum.palemoon.org/viewtopic.php?f=62&p=251950&sid=14291391b8552d3afe8f153cf401c56c#p251950 but. as you can probably see for yourselves , nothing has even budged there so far ...
  8. ... A more in-depth analysis of the term: https://en.wikipedia.org/wiki/Portable_application A "portable" app installation is also called "stealth" when the portable app is being launched from an external (to the host) storage media (e.g. HDD) but when the app is exited and the media detached from the host computer, NO TRACE whatsoever related to the app is left on the host's file system and registry; I guess you can also call the app "stealth" even when "installed" on an internal (host) disk, when it doesn't leave any of its 1. associated files outside of its assigned "portable installation" directory 2. associated registry keys on the host OS once exited... Many apps can be made "portable", but it takes a lot of effort to additionally make them "stealth"; sometimes, that isn't possible at all, even with app virtualisation (e.g. Microsoft Office and most of the Adobe Suites); in those difficult cases , the application is very complexly intertwined with the OS it runs on ...
  9. https://www.virustotal.com/gui/file/96585bab134e3011bb25b7310243e5d384575e76408fb8adfd036f045b1013a0/detection BTW, this is with latest Supermium 122-R6 32-bit release ...
  10. Good News for Windows XP SP3 users ? https://www.patreon.com/posts/lsc-application-105275497
  11. ... Would you be so kind as to enlighten me/us towards that very goal? I have a vested interest myself into making this work in latest Th/Sm (Chromium-122 based), but: Google have long ago removed any CH-related flags from within "chrome://flags/"; I am aware of the "--disable-features=UserAgentClientHint" command line argument, but it appears it no longer works for Chrome 122 ... That same flag currently works as expected with KafanMiniBrowser (Chromium 87 based), which had a "draft" CH implementation; I used the test site: https://user-agent-client-hints.glitch.me/ and KMB indeed leaks its Chromium version (87) through CH: But launched with "--disable-features=UserAgentClientHint" it doesn't: OTOH, latest Thorium 122 (.169) 32-bit SSE3 with the same cmdline argument continues to leak its Chromium version (122): This is rather unfortunate because at least one of my UA-spoofing extensions (Custom UserAgent String v0.2.3) in Th122 fails to work properly on some sites (which take into account the Chrome version sent via CH and not the one via the "classic" UA-string spoofed by the extension) ... I'm not entirely sure, but I think the "flag" used to work with Supermium 121, but now it doesn't with either Th/Sm 122 ... If anyone can come up with a tested/working solution for these, please chime in (FWIW, a cursory web search on Google did not produce a way to fully disable ClientHint in recent Google Chrome versions ) ...
  12. When I follow the link in that post, it leads me to another post discussing the Modify-HTTP-Response addon. No userscript there. ... The userscript I mentioned is inside the body of the exact MSFN post I (searched and) linked for you ; if clicking the link above doesn't get you exactly to: ... then something's gone awry in your browser's behaviour ...
  13. ... Discourse-based forums fixing userscript below: https://msfn.org/board/topic/184051-my-browser-builds-part-4/?do=findComment&comment=1258499 ... and a revised version of the uBO (legacy) custom filter having the same effect : https://msfn.org/board/topic/185966-my-browser-builds-part-5/?do=findComment&comment=1258536 NB: Both above mitigations are "universal", whereas the Modify-HTTP-Response based solution you opted for (it was the recommended solution on the official PM Forum at a time the UXP platform was missing support for those villainous operators, "?." & "??" ) requires manually modifying its "filter" every time you come across a discourse forum NOT covered already by the filter's existing RegExp... ... Are you saying you tried to properly use the editor's code tag (</>), select Javascript under coding language options, paste the "code" inside the designated input field and when you hit the "Insert into post" button the "Forbidden..." error popped up? Or was it that the code was properly inserted into the post while in Edit/Preview mode and the error hit after you clicked the "Submit Reply" button?
  14. Nah... "They" were "bad" to begin with ... Updating their code frameworks to target Google Chrome 125+ (which "they" expect every single one of their users to be on at the moment ) is what distances all these services further away from what UXP can (reasonably) digest ...
  15. ... You're using St55, so the wording there (about:profiles) is still "Restart with Add-Ons Disabled" ; in St52, MCP have reworded that to "Restart in Safe Mode", to more accurately indicate what happens when you click that button... As you've found out already: "Restart with Add-Ons Disabled" != "disable every add-on manually and restart" http://kb.mozillazine.org/Safe_Mode
  • Create New...