VistaLover
Content Type
Profiles
Forums
Events
Posts posted by VistaLover
-
-
14 minutes ago, Mathwiz said:
the Serpent 55 build from Feb. 8, 2024 (i.e., earlier this month);
... Erh
, you mean "previous" month ...
14 minutes ago, Mathwiz said:if it works with 55, it works with 52 as well.
... That's probably true
, but the other-way-round isn't a given; not the whole of UXP has been backported to St55 (but. at the same time, St55 has some vestiges inherited from Fx53.0a1); please also try, if you will, 2.16-"legacy" on UXP (probably won't work there, too, but...) ...
1 -
8 minutes ago, Mathwiz said:
and by implication, the last version that does work is 2.15.349.
... Is it the "standard" or the "legacy" dist(ribution) for current UXP?
0 -
3 hours ago, DrWho3000 said:
how do you clear cache and cookies for a "specific" website ?
... There exist several "caches" in Chromium-based browsers: Browser Cache, App Cache, ShaderCache, GrShaderCache, Code Cache, GPUCache (this list from my KMB profile; Ch87-based
); I'm not aware of a "method" to clear browser cache on a "per-site" basis (probably exists, just not aware of it ) ...
As for the second part of your question, it seems to be a recurring one
:
... and an answer from "yours, truly":
Then again:
... and an answer from NHTPG:
For your convenience
, it might be best to use the Bookmarks feature on your browser ...
Cheers
...
2 -
12 hours ago, modnar said:
I use SumatraPDF (v3.1.2 XP-last) on my systems sometimes with built in ST viewer.
... Apologies for asking, but your statement isn't quite clear to me
... SumatraPDF is a standalone application that can handle (local) PDF files, how can it be used "with" Serpent 52's native (built-in) PDF viewer (pdf.js, written in Javascript) ? Do you actually mean that for PDF files on your system, you sometimes use SumatraPDF and other times you use St52 (as a PDF viewer) ?
FWIW, SumatraPDF used to come with a NPAPI plugin that could be configured to handle PDF files inside a supported browser (St52 is one
), but that NPAPI plugin was removed, starting with SumatraPDF-3.0 
; apparently, there's a hacky way to keep using the last available plugin version (2.5.2) with newer versions of the SumatraPDF application, but this is an unsupported configuration, i.e. "you're on your own":
Quote... and Firefox will remove support for most NPAPI plugins by the end of 2016: NPAPI Plugins in Firefox
For those reasons, we stopped including the plugin since version 3.0.
That being said, we won't be deleting/disabling it, so if you really want it,
you can install 2.5.2 from the Previous versions page and then upgrade, which will preserve the plugin.1 -
On 3/6/2024 at 2:46 AM, dmiranda said:
(even without installing the NotoEmoji.font that comes with the installer).
Nevertheless, I still placed it in windows/fonts. It shouldn't hurt to have itThe 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
)
2 -
On 3/6/2024 at 3:00 AM, Mathwiz said:
Edit: I got it sorted and am up to version 2.5.207 from June 1, 2020. This is the last version with the traditional UI; version 2.6 has a "Photon-like" UI. 2.5 has a couple more buttons but it looks and acts pretty much the same.
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" 
...
2 -
21 hours ago, VistaLover said:23 hours ago, dmiranda said:
and also a debug message:
"[ERROR:crashpad_client_win.cc(476)] InitializeProcThreadAttributeList (size): The specified program requires a newer version of Windows. (0x47E)"
(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
..
3 -
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 ...
2 -
1 hour ago, dmiranda said:
and also a debug message:
"[ERROR:crashpad_client_win.cc(476)] InitializeProcThreadAttributeList (size): The specified program requires a newer version of Windows. (0x47E)"
... 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"
...
1 -
... 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
2 -
15 hours ago, Mathwiz said:
replaced path
chrome/pdfjs/content in omni.ja
with that "newer" (by 1 month) code.
... 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" ?
0 -
20 hours ago, Mathwiz said:
But that's not quite what I meant when I said it made "no sense" for a Web site to host pdf.js on their site.
... FTR, you did not say (rather, write
) the "no sense" part; you actually "said":
On 2/26/2024 at 3:32 AM, Mathwiz said:But I still can't understand why one would host pdf.js on a Web page
; the "no sense" "argument" was brought up by Anbima:
On 2/26/2024 at 5:33 PM, Anbima said:In my opinion, it makes no sense to integrate a separate PDF viewer here.
... and it was this "argument" by him the portion of my reply you quoted above was addressing
; just as a disambiguation ...
20 hours ago, Mathwiz said:it broke any NPAPI plugins their Firefox users might be using
... 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
:
On 2/26/2024 at 6:29 PM, VistaLover said:only "applicable" to frequenters of these threads, on "legacy" browser engines
Best regards
...
1 -
10 hours ago, Zorba the Geek said:
and make some recommendations to the Supermium developer.
...
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 ...
1 -
9 hours ago, Dixel said:
Vista and Server 2008, they both support SHA-2 officially.
... That's NOT accurate to say
; while both OSes are NT 6.0, per your linked documentation:
Quotewe have changed the signing of Windows updates to use the more secure SHA-2 algorithm exclusively. This change was done in phases starting in April 2019 through September 2019 to allow for smooth migration (see the "Product update schedule" section for more details on the changes).
Customers who run legacy OS versions (Windows 7 SP1, Windows Server 2008 R2 SP1 and Windows Server 2008 SP2) are required to have SHA-2 code signing support installed on their devices to install updates released on or after July 2019. Any devices without SHA-2 support will not be able to install Windows updates on or after July 2019. To help prepare you for this change, we released support for SHA-2 signing in starting March 2019
...
Starting in early 2019, the migration process to SHA-2 support began in stages, and support will be delivered in standalone updates. Microsoft is targeting the following schedule to offer SHA-2 support.
...
April 9, 2019Stand Alone update, KB4493730 that introduce SHA-2 code sign support for the servicing stack (SSU) was released as a security update.
Windows Server 2008 SP2
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
...
2 -
9 hours ago, mina7601 said:
I also noticed that the banner disappears if spoofed as Chrome 109,
and that's the minimum version to not have that banner.... 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:
QuoteTo add this item to Chrome, please update your browser Learn more
no longer displayed, but ONLY to be replaced by a new banner, stating:
QuoteItem currently unavailable. Please check the troubleshooting guide View guide
WT... ?
2 -
@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:
On 2/15/2024 at 3:01 AM, VistaLover said:This third party userscript, when installed (requires a userscript manager, e.g. Violentmonkey, Tampermonkey, etc.), will make the "Add to Chrome" button active again, however its functionality will now be limited, in that it will only enable a .crx file download to disk, not proper installation (as was the case with the "old CWS"); after saving to disk, the user has to drag-n-drop the saved file onto the "chrome://extensions/" internal tab, for the installation to proceed...
The problem with that userscript is that the "name" of the downloaded extension always comes up as "undefined" (the "version" comes up correctly), so some renaming is in order after the download (perhaps one savvy person here could fix the script in that regard?
) ...
Kind regards
...
2 -
On 2/15/2024 at 3:01 AM, VistaLover said:
Google
staff seem to have a perverse sense of "humour" , because after the auto-redirection has been completed, in non-supported Chrome versions, a new in-page banner is being displayed, stating:
QuoteTo add this item to Chrome, please update your browser or visit the legacy store. Visit legacy store
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" :
2 -
... 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/
QuoteThe Verified Media Path (VMP)
Another important aspect to consider is the Google Widevine DRM Verified Media Path (VMP). The Widevine DRM Desktop Browser Content Decryption Module (CDM) includes support for VMP, which provides a method to verify the validity of the browser framework. All Widevine DRM browser-based integrations (platforms and applications) must support VMP, but VMP support is not available for Linux platforms.
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:
6 hours ago, Zorba the Geek said:so I have changed the entry for kernel32.dll in the widevinecdm.dll import table to the OneCore API xpspkernel32.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
) ...
2 -
On 2/25/2024 at 7:09 PM, VistaLover said:
you want the older v0.0.4, which is still at MV2, for 360EE...
Fortunately, that one has been salvaged by crx4chrome
:
2 -
45 minutes ago, Anbima said:
Is it possible to set all of them to be displayed in 360Chrome?
... 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...
2 -
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 ...
2 -
On 2/26/2024 at 1:36 AM, UCyborg said:
It's not their own, it's the same thing Mozilla Firefox ships with, maybe different version, it's called pdf.js, indeed written in JavaScript.
... 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 ;
23 hours ago, Mathwiz said:So, presumably, St (52/55) use an older version of the same thing,
... 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...
23 hours ago, Mathwiz said:But I still can't understand why one would host pdf.js on a Web page,
since Firefox and Chromium already have the needed functionality built in.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
...
1 -
58 minutes ago, Anbima said:
In my opinion, it makes no sense to integrate a separate PDF viewer here.
... 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
...
3 -
OT
19 minutes ago, NotHereToPlayGames said:then I have always felt that roytam's very very very long scroll-scroll-scroll then scroll some more should always be done that way.
... 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
...
3
My Browser Builds (Part 5)
in Browsers working on Older NT-Family OSes
Posted · Edited by VistaLover
... It's probably this one
:
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/getTransform
Requires Fx70+
, Ch68+ ...