VistaLover

The initial implementation has issues correctly displaying emojis under Windows XP, e.g. on GitHub: https://github.com/win32ss/supermium/issues/333 A hack-y "fix" has been made available by the author: https://github.com/win32ss/supermium/issues/333#issuecomment-1982403569 (will ONLY render monochrome emojis in Win<8.1 )

There exists a project (now, seemingly, an "abandonware" ), last updated in June 2020, which offers "pdf.js" in the form of a "legacy" XUL extension: https://github.com/IsaacSchemm/pdf.js-seamonkey/releases/tag/v2.3.235 The release notes of the last version state that it's based on pdf.js-v2.3.200, so you got further than them ; the provided XPI file comes with l10n support , which was the main reason I had tested it back then in my "dirty" St52 profile ; after some days of testing, I bumped on some incompatibilities (the details of which evade me now ), so I ended up uninstalling it and reverting to the St52-embedded (English-only) "native pdf.js viewer" ...

(redacted) InitializeProcThreadAttributeList requires Vista SP2 as "minimum supported client" ... This crashpad crash under Windows XP has been fixed, for now in source code, only: https://github.com/win32ss/supermium/commit/08170feefcfbcd750b377d4c11a4efc67279ed9e No binary fix available yet; the next "hotfix" release should incorporate it, hopefully ..

Given that the current Google Chrome "stable" release is at v122.0 as I type this, it comes as no real surprise that sites are starting to "blacklist" our "legacy" Chromium browsers (360EEv13.x, KMB) via "User-Agent-Sniffin'", simply because they report a Chrome/86[/87] slice inside their default UA string... So far, they're not many , but this is expected to change in the future ... The most recent case I encountered is the one of "sciencedirect.com", after a Google Search result had pointed me to: https://www.sciencedirect.com/topics/computer-science/protected-storage I was "greeted" by: I'd have expected a "science-related" site to have implemented truly scientific means (i.e. feature-detection) to check whether "my" browser is able to display it properly, but, hey, even "scientists" must have "sold their souls" to Google and company (a figure of speech, surely, but ...) ... At this point in time, I've opted for a SSUAO rather than a "global" one via the " --user-agent" cmdline flag ; several extensions offer this functionality, I've chosen Custom UserAgent String ; you need the older v0.2.1, the last on MV2 : At last, I was then able to be "scientifically" informed using 360EEv13 ...

... Other people on XP SP3 have experienced that error, too : https://github.com/win32ss/supermium/issues/318 InitializeProcThreadAttributeList requires Vista SP2 as "minimum supported client" ...

... For those not closely following the development in GitHub , Supermium v122 has been publicly released: https://github.com/win32ss/supermium/releases/tag/v122 https://github.com/win32ss/supermium/discussions/316 The new installer (both 32 & 64-bit) promises WinXP compatibility; the portable distributions appear to be, again, behind a paywall: https://www.patreon.com/posts/supermium-122-99791603 https://www.patreon.com/win32/shop/supermium-plus-package-march-2024-30-day-138343

... Besides .\browser\!omni.ja\chrome\pdfjs\content\* ... I find some locale files are also relevant: .\browser\!omni.ja\chrome\en-US\locale\pdfviewer\* (St52) ; have these been taken into account while "testing" ?

... FTR, you did not say (rather, write ) the "no sense" part; you actually "said": ; the "no sense" "argument" was brought up by Anbima: ... and it was this "argument" by him the portion of my reply you quoted above was addressing ; just as a disambiguation ... ... If I'm not terribly mistaken , Mozilla were the first to do this thing in their own browser, Firefox, many years ago already: https://bugzilla.mozilla.org/show_bug.cgi?id=1269807 https://www.ghacks.net/2015/10/08/mozilla-announces-the-end-of-npapi-plugins-in-firefox/ https://support.mozilla.org/en-US/kb/npapi-plugins https://support.mozilla.org/en-US/questions/1270346 ... Unless you were referring to the Firefox-based forks "we here" use, which just consolidates my prior argument : Best regards ...

... Well, the relevant info has been already posted inside Supermium's official GitHub issue tracker, https://github.com/win32ss/supermium/issues/127#issuecomment-1868304931 so its author should be aware already ; given that the linked comment hasn't received yet any reaction or subsequent reply , one can assume that the "CastLabs route" isn't being considered, at least not at this point ...

... That's NOT accurate to say ; while both OSes are NT 6.0, per your linked documentation: Windows Vista SP2 x86 & x64 Official Extended Support was EoL'ed on Apr 11th, 2017 : https://learn.microsoft.com/en-us/lifecycle/products/windows-vista It is indeed true that the WS 2008 SP2 targeting updates released some two years after Vista's official End of Extended Support can be installed manually on the OS and bestow SHA-2 support on it, but this practice isn't considered "official" by either the vendor (Microsoft) or the rest of the third party vendors (Norton in this case ) ... Kindest regards ...

... I launched my Kafan MiniBrowser (KMB) copy (Chromium 87 based) on my Vista SP2 x86 OS with below command-line argument: --user-agent="Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" Then I navigated to: https://chromewebstore.google.com/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=en Guess what? Yes, the previous banner: no longer displayed, but ONLY to be replaced by a new banner, stating: WT... ?

@rereser : I only posted my newer screenshot (of "new" CWS) above as an indication that Google's wording has changed in the interim since my previous screenshot of Feb 15th, 2024, when they offered a (non-working ) alternative choice: "... visit the legacy store" ... As for your posted mitigation in the shape of a userscript, I've already talked about it (and its shortcomings ) in my post of Feb 15th: Kind regards ...

However, clicking on the "Visit legacy store" area (JS-controlled button) will only start a vicious circle , resulting in that same "new CWS" page ... Well, it's March 1st in my timezone already , and the "in-page info banner" no longer offers the alternative of "visiting the legacy store" :

... I don't want to "burst your bubble" , but even if you manage to sort out all dependencies of the DLL under NT 5.1, the CDM will be practically non-functional on most popular DRM'ed services (e.g. Netflix, Amazon Prime, Hulu, Spotify, Apple Music, Tidal, etc.) ; since years now, Google (owners of Widevine CDM) have implemented the Verified Media Path (aka VMP) security feature: https://www.expressplay.com/products/google-widevine-drm/ In layman's terms, this means that the application within which the CDM is run (Supermium in your case) must've been previously whitelisted/sanctioned by Google ; this process involves acquiring special certificates from Google, for DRM purposes only, and signing various browser components (e.g. "chrome.dll") with said certificates; when the CDM is requesting decryption keys (aka "licence") from a Widevine lic server, it first sends (obfuscated) a payload with extreme detail of the environment it's currently running on; this detail includes exact browser specifics, as well as the OS/device the browser is running on; the WV lic server can reject the licence request if the CDM version/browser/OS/device is not to Google's liking; browser applications are being accepted if they have been signed with that special VMP certificate, and this fact limits the selection to ones offered by the major vendors, ONLY (Google Chrome/Mozilla Firefox and a few Chromium variants) ... Supermium hasn't been granted VMP compliance (being a one-man, open-source, project) and even if its author (win32) applied for such, it could well take several years for this to materialise, if at all ... In addition to VMP, you said you manually edited the DLL: This fact alone changes the CDM's hash value/invalidates its file signature (which is SHA-2, BTW, incompatible with XP) and when the CDM identifies itself to the WV lic servers (yes, it does send its hash inside that obfuscated payload I mentioned earlier), it "screams": "I've been tampered with, just ignore me", thus no decryption keys are delivered to it ... FYI, some Supermium issues relating to its DRM (Widevine) support: https://github.com/win32ss/supermium/issues/127 https://github.com/win32ss/supermium/issues/169 https://github.com/win32ss/supermium/issues/242 FWIW, Widevine related documentation used to be publicly accessible until a few years ago, when evil Google decided to put it behind corporate gmail accounts, for media-enterpises members only, who also have to sign strict NDAs ... At this point in time, it seems DRM-savvy private individuals are to be found only inside private discord servers, no more open to "outsiders"; I used to be part of such a server back in the day, but got kicked-out because I wasn't "active enough" (at least according to the server's owner ) ...

Fortunately, that one has been salvaged by crx4chrome : https://www.crx4chrome.com/crx/299038/

... With respect , you did not make an effort, it seems, to follow what I have already posted in a previous post ; whether a PDF on-line URI will generate a "Save As" file download prompt (case 1 in your previous post) or the PDF file will be auto-downloaded in the background and rendered+displayed inside the browser's Native PDF Viewer (case 2 in your previous post) is something beyond the user's (initial) control, in fact it's a server-side configuration: the PDF file on the hosting server has been configured with a content-disposition value, by the server admins... In case 2, the value is "inline"; this (alongside a suitable Content-Type header) instructs the browser to handle the PDF file "in-line", i.e display it inside a tab via the native viewer (or via a PDF reader plugin, where applicable); in case 1, the value is "attachment"; this instructs the browser to simply "download" the PDF file to disk, for storage. I have already mentioned an extension in my previous post which changes the "attachment" Content-Disposition value to "inline", but the problem with such an extension is it's not specific to PDF files; other types of files you may want to download to disk (e.g. images, audio, video, etc.) will attempt to be displayed directly in the browser (if the browser is able to render them natively); that's why I said I only enable that extension at will...

As an addendum to my previous post, Mozilla do host (on GitHub) "on-line" editions of their PDF.js lib, one targeting "current" browser engines: https://mozilla.github.io/pdf.js/web/viewer.html and another targeting "legacy" browser engines: https://mozilla.github.io/pdf.js/legacy/web/viewer.html Neither of the two works on Ch86/87-based browsers (and on St52) to display the "C0801E.pdf" file, https://mozilla.github.io/pdf.js/legacy/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf https://mozilla.github.io/pdf.js/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf while BOTH do when loaded in Ch121-based latest Supermium-v121-hf ... Yes, the browsers "we" use here are more "legacy" than what Mozilla even thought of ...

... Indeed ; as the web console portion of the first image I posted previously reveals, the "enganchesaragon.com" site are self-hosting v3.0.279 of the pdf.js library; according to the GitHub repo for it, tag 3.0.279 was cut on 2022-10-29 ; ... The library inside the latest Serpent 52 build is of version "1.7.348-git-754c4bd", committed on 2017-03-04, i.e. 5 1/2 yrs older (!) ... It would then seem that v3.0.279 (from 2022) requires platform features not fully compatible with UXP ... I'm uncertain as to how to proceed to find the version of the pdf.js (equivalent) lib inside 360EEv13.5 and/or KMB; Chrome 86 stable was released on 2020-10-06, 87 stable on 2020-11-17; Google probably don't use the same lib Mozilla maintain ; as discussion here has proved already, Ch86/87 (autumn of 2020) don't support the much "younger" Mozilla pdf.js v3.0.279, that came two years after those browsers were released... After my analysis, one "probable" answer why "enganchesaragon.com" choose to self-host an instance of the Mozilla PDF.js lib to display the PDF files "they" serve is: "They" prefer it over the native-PDF-viewer implementation on users' (mostly Chrome-based) browsers... Don't know what else to think of ...

... Couldn't agree more ; but, "no sense" is probably only "applicable" to frequenters of these threads, on "legacy" browser engines ; I can assure you that the web designers of that Spanish site did NOT, even for a mere second, think of "backwards compatibility" ; they're probably "trained" to expect each and every eventual user of their service to be running the latest Chrome/Firefox/Safari, where the original "issue" you reported (and generated many additional posts here) is simply non-existent - it works right away and the user "there" doesn't notice any issue; he/she just moves on with the browsing; the comparison between "sensical" and "non-sensical" never crosses his/her mind ... It is us here inside the MSFN "older OS" forums who harbour a mentality of being "the centre of the IT universe", whereas, in fact, we're just one dying old star which has practically extinguished all of its fusion-able material ...

OT ... I use a userstyle for that : @-moz-document domain("msfn.org") { body.ipsApp article.ipsComment div[data-quotedata*='roytam1'] div.cPost_contentWrap p { max-height: 300px !important; overflow-y: auto !important; } } ; I've named it: msfn.org @roytam1 "long" posts fix ...

... The "more" correct way to do it is: 1. click the code button (</>) in the MSFN editor toolbar 2. In the opened popup, change the code syntax to "Javascript" (bottom right) 3. Paste the code (you copied directly from TM) in the main box 4. Click the "Insert into post" blue button 5. (Optional) Preview your embedded code (far right button of the MSFN toolbar)

... Indeed (and pardon the slight OT ), the "online-PDF-viewer" URI: https://storage.enganchesaragon.com/public-websites/ecommerce/pdf_viewer/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf does load in last week's Serpent 52, but the pages are rendered blank there : If one downloads directly the PDF file via: https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf (it's 10.4 MiB in size) and then tries to view it in St52, all's fine : Yes, the PDF file specs have evolved over time and full backwards-compatibility isn't guaranteed ; the file in question is of version 1.7 and I had better luck than you in that it opened in my Adobe Reader X (aka 10) copy: Though, do note that it is stated in the above screenshot that PDF v1.7 should be compatible with Adobe Reader/Acrobat 8.0+, so there may be something off in your case ...

That's how I've been doing it so far. But I thought it might be easy to get around this. One other approach I use myself is to let the browser handle itself the online PDF files (without a prior download to disk and then drag-n-drop ) and display them via its native PDF viewer; however, in the case discussed, https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf the file has an "attachment" content-disposition and loading that URI will generate a "Save File" download prompt; that's why I have also installed: https://chromewebstore.google.com/detail/undisposition-racle-fork/bbppejejjfancffmhncgkhjdaikdgagc and I enable it as needed - you want the older v0.0.4, which is still at MV2, for 360EE... Below is KafanMiniBrowser loading the referenced PDF URI in its default viewer, via "undisposition" extension :

... This is probably just a simple oversight , but these two packages are being served through plain HTTP, while the page they're on (MSFN) is served through HTTPS ; recent Chromium versions block by default such scenarios as "mixed-content" and won't let you download the files out-of-the-box (a security warning is issued, can be ignored/overridden at user's discretion); I experienced this myself as I was testing latest Supermium-v121-hf-x86 on those links... Not a big thing , but perhaps the links could be edited to HTTPS, too (as are all the links to the rest of this weekend's packages ) ... Many thanks!

Interested members can find needed files on SourceForge: https://sourceforge.net/projects/winscp/files/WinSCP/6.1.2/ The "WinSCP-6.1.2-Portable.zip" is the one you need under WinXP (unpack and launch the .exe file); the problem arises if you want the app localised , because that zip archive ONLY comes with the default, en-US, locale (embedded into the .exe) . The installer, "WinSCP-6.1.2-Setup.exe" comes with multi-language support, but it's built with an InnoSetup version that requires at least Win7 . To get the localisation files out of it you need use a tool capable of extracting Innosetup installers; my two "loved-ones" are just CLIs, innounp (at v0.50) and innoextract (at v1.9) ; however, if you are a GUI type, you can use the much larger app UniExtract2, which contains those two above CLIs as internal components (this extracting "suite" has been mentioned and linked before by AstroSkipper). Once you have successfully unpacked "WinSCP-6.1.2-Setup.exe", you should have access to a "Translations" dir, with numerous "WinSCP.*" files; pick the one that has a file extension denoting your desired locale (e.g., for German it should be "WinSCP.de") and place that adjacent to the WinSCP.exe main executable inside your originally unzipped "portable" archive; launch the app (it'll still be in English) and through the app's configuration (Options -> Preferences -> Environment -> Languages) you can now select your preferred locale: An app restart is then required for the change to take effect ... If you don't mind your "portable" app being in the much acclaimed PAF format, the people over at "portableapps.com" have prepared a "special package just for XP users", who have now been deprived of future WinSCP updates: https://sourceforge.net/projects/portableapps/files/WinSCP Portable/WinSCPPortableLegacyWinXP_6.1.2.paf.exe/download That package has all available localisation embedded ... PS (and OT): This time, the WinSCP devs did not put Vista SP2 32-bit in the same boat as WinXP - the latest release as of writing this, 6.3.1, again via the "portable" distribution, launches and runs fine there () ... Just as a FYI...