VistaLover

It wasn't like that at all, actually ... The Mozilla "plans" had been laid out long before, and it was to ape what Google had done already: Remove Vista support at the same time Windows XP support was to be removed ... Some sane voices at the time did point out that Vista support could well have been extended at least up to Firefox v54.0, but Mozilla devs were adamant: Vista was to be taken, alongside XP, to the FxESR 52 update channel when Fx53 was ready for general release, and then be left to rot after 52ESR becomes EOL; FWIW, it was Fx55 that contained lots of compiled Rust code, that required Win7+ to run on... The story is now repeated: Win7/8/8.1 will be soon moved to the FxESR 115 update channel and then be done with ... ... The deprecation of XP+Vista happened early on during the Fx-Nightly 53.0a1 development cycle, in mid-November of 2016, and it was then and there my Firefox Nightly Tester "days" abruptly ended ; I don't want to relive old history, I think I have detailed this somewhere inside the Vista subforums (so an advanced Forum search might yield relevant results ); from faint memory, I recall that the fork-point for Moebius was a Feb/Mar 2017 53.0a1 code snapshot; final 53.0 was released on Apr 19th, 2017 (as linked already...) .

FWIW, under the Releases section, precompiled (via PyInstaller) Windows executables are available : mozjarr32.exe : Compiled with CPython 3.8.8 (x86), requires Win7 SP1+ mozjarr64.exe : Compiled with CPython 3.8.8 (x64), requires Win7 SP1+ x64 mozjarr64_legacy.exe : Compiled with CPython 3.7.7 (x64), requires Vista SP2+ x64 mozjarrXP.exe: Compiled with CPython 2.7.13 (x86), will run on WinXP SP2+

... There's still some "volatility" surrounding this specific issue on the yt-dlp devs side ; they keep going back and forth between the old and the new Twitter APIs: https://github.com/yt-dlp/yt-dlp/commit/49296437a8e5fa91dacb5446e51ab588474c85d3 https://github.com/yt-dlp/yt-dlp/commit/b03fa7834579a01cc5fba48c0e73488a16683d48 https://github.com/yt-dlp/yt-dlp/commit/92315c03774cfabb3a921884326beb4b981f786b At the same time, yt-dl is fully broken on Twitter ... BTW, this sounds ominous: https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-v8mc-9377-rwjj ... Yes, it's the never-ending cat-and-mouse game between Google and the downloading apps; G keep changing their yt-player "signature" javascript code; when the apps fail to properly decode/decrypt it, this results in throttled Youtube downloads (ca. 50kbps), rendering those apps "unappealing"... FFmpeg is indeed an essential dependency of both yt-dl and yt-dlp for the majority of their users who (unlike you ) wish to end up with a standalone media file, compatible with a vast number of media players; additionally, FFmpeg isn't only used as a "merger", but 1) can be used as a downloader when [hlsnative] isn't specified and for downloading LIVE streams 2) as a multi-task post-processor (e.g. transcoding AAC/OPUS audio to MP3, webp images to jpg, webvtt subs to srt ones, etc.) and 3) as a media tagger, especially in the yt-dl builds provided by nicolaasjan ... The size of the resulting binaries relies on a variety of factors: The "vanilla" code of FFmpeg itself has grown quite a bit over the years, following probably Zawinski's Law ; it's now 2023, version n6.1-dev, not 2012 and v0.12 ... Over the course of years, support for many additional third party libs has been added, while some older libs have been deprecated and their support removed... Depending on the number of third party libs you compile FFmpeg with, the binary size can increase significantly (third-party-libs is a generic term, which encompasses decoders/encoders/muxers/demuxers/filters/etc.) ... The type of compiler used also plays a role: Cross-compilation in Linux using e.g. Cygwin results in bigger Windows executables compared to native compilers like MS Visual Studio or MSYS2... Binary sizes also increase if you're building for Windows x64... With disk storage and bandwidth today being relatively cheap , no-one really cares anymore about file sizes...

Nope! https://www.mozilla.org/en-US/firefox/53.0/releasenotes/ The Fx53 "installer" version won't install the browser under Vista SP2; the "zip" version of Fx53 can be made to run under Vista SP2 if the "subsystem version" string inside the main EXE's PE Header is lowered (with specialised tools) from 6.1 to 6.0; media capabilities of the browser will remain broken, though; the app does no longer have access to Vista SP2's WMF patented decoders (h.264, aac, mp3), because Mozilla devs had excised all support for Vista SP2's WMF version (which is inferior to Win7's WMF version, but this was already discussed in the (distant) past) ...

... The "optimizejars.py" script is contemporary with the Firefox ESR 17 release, i.e. late 2012 (!) : https://dxr.mozilla.org/mozilla-esr17/source/config/optimizejars.py https://hg.mozilla.org/releases/mozilla-esr17/raw-file/tip/config/optimizejars.py Until that period, it was actually part of Mozilla Firefox's (open) source code... Later on, Mozilla deprecated that script and opted to use (non-public) omni.ja optimising routines built inside their compilers' infrastructure ... So, the publicly available optimising script is a reflection of how omni.ja optimisation was done in 2012, but I find is an acceptable approximation for, at least, the FxESR 52 era (2017) ... I haven't actually followed the rest of that story on Firefox versions > 52.9.0, because Mozilla dropped support for my OS... This all regarding the official Pale Moon browser is quite a different story ; for "normal" omni.ja archives, in order to extract them successfully with 7-zip without the header warnings, you first have to de-optimise them, as already reported by @DanR20 : Place "omni.ja" adjacent to the script, then (with py2.7.18 installed) run: python optimizejars.py --deoptimize ./ ./ ./ Then extract the de-optimised archive with the program of your choice... As for "palemoon.res", this is indeed a renamed "omni.ja" file, but Moonchild, in an attempt to protect his copyrighted resources, decided to pack it with a custom encryption/optimisation, utilising the Brotli compression encoder, in a way to specifically thwart normal extracting applications ; if you ask me, it was just to vex those advanced PM users who were accustomed to making special modifications to the browser by modifying code extant inside omni.ja itself... I have kept records and the "encrypted"/un-extractable omni.ja archives first appeared in: PaleMoon_unstable-29.0.0a6-uxp-master-git-20201114-g511ac54-pm-master-git-20201114-g07d3f0a.win32[buildID=20201114181134] omni.ja was renamed to core.dll at that time; the final renaming to palemoon.res was implemented in the next unstable build: PaleMoon_unstable-29.0.0a6-uxp-master-git-20201116-g241f06b-pm-master-git-20201117-g86b6cb4.win32[buildID=20201117182045] The first stable PM version with its "omni.ja => palemoon.res" archives made un-extractable was v28.16.0; there were some complaints in their forum, but soon all was forgotten ; if you'd care to read, some links (there are more ) : https://forum.palemoon.org/viewtopic.php?p=204401#p204401 https://forum.palemoon.org/viewtopic.php?p=204337#p204337 https://forum.palemoon.org/viewtopic.php?p=216675#p216675 https://forum.palemoon.org/viewtopic.php?p=229232#p229232 ... The great JustOff to the rescue: https://github.com/JustOff/mozjarr/tree/master However, I have no intention of upsetting MC and co. at all ; this tool exists, but JustOff's traces are currently lost ; that fact alone makes the tool itself probably an "abandonware"; besides, this community here is not in need of it, because @roytam1 has not followed MCP's path and "omni.ja" files in all of his UXP releases remain user-readable/extractable ; in any case, under normal conditions, a simple user shouldn't even mess with those archives: https://mike.kaply.com/2013/05/06/dont-unpack-and-repack-omni-jar/ (the latest case where the maintainer himself posted instructions necessary to fix the "about:addons" bug in latest St52 is just an exception to that rule ...)

... I trust you'll find the article below quite enlightening : https://whatsoftware.com/edit-files-inside-firefox-4-omni-jar-to-auto-save-password/ ... specifically this part: Later additions: 1. MDN entry for file omni.ja, saved via the WA: http://web.archive.org/web/20210620190432/https://developer.mozilla.org/en-US/docs/Mozilla/About_omni.ja_(formerly_omni.jar) Mozilla, in their infinite wisdom , have annihilated that article in the autumn of 2021... 2. Relevant "discussion" in an old (2013) thread of the 7-zip Support Forum (hosted by Sourceforge): https://sourceforge.net/p/sevenzip/discussion/45797/thread/dab0da38/ Pinging @UCyborg ...

... You need the zip CLI of the Info-ZIP utility; Windows binaries courtesy of the German developer Dirk Paehl: https://www.paehld.de/open_source/?Old_programs___ZIP_UNZIP I myself use the 3.1d26+beta version ... 1. Place zip.exe adjacent to extracted directory "omni" 2. CD in the Windows Command Prompt to inside the "omni" DIR; then: "..\zip" -qr9XD "..\omni.ja" * Archive omni.ja created besides the zip.exe binary; NB: this archive is still "un-optimised", so it then needs to be additionally "optimised"... 3. Place the py2.7 script "optimizejars.py" next to zipped archive "omni.ja" 4. With py2.7 installed, execute: python "optimizejars.py" --optimize ./ ./ ./ A copy of that script has been uploaded here ...

Correct links below: https://o.rthost.win/basilisk/basilisk55-win32-git-20230701-7ec514b57-xpmod.7z https://o.rthost.win/basilisk/basilisk55-win64-git-20230701-7ec514b57-xpmod.7z

... and: @roytam1 : It's probably caused by UXP #21 and the commits by FranklinDM you backported to our tree... NM28 behaves fine, because it uses the (old) TychoAM those commits target, but "our" Serpent 52.9.0 (unlike the official Basilisk 52.x.x.x) still uses the WebExtensions AM and thus broke ; so, those commits would either have to be reverted for St52 or somehow modified to accommodate St52's WE AM ... Thanks in advance for any fix for this (going back to previous build of St52 as things stand ) ...

... But, did you first try the DRM test page I referenced already? If not successful in getting the video to play, what exact error was produced, if any? Have you tried to inspect the Widevine CDM dll shipped with Google Chrome (x64) with Dependency Walker x64 under Vista SP2 x64+ExtKernel? ... That's a telltale sign of Widevine CDM either 1. Being completely broken under your OS+browser combination 2. Its web requests to the Spotify Widevine licence server not being authorised/approved, due to a variety of reasons [blacklisted a) version of the CDM itself, b) browser version the CDM is installed in c) device/hardware type, which includes - but is not limited to - OS the browser+CDM are installed] ... Please, which exact version of Google Chrome x64 was that and which exact version of the WV CDM? TL;DR: Informing us the Spotify web player doesn't (absolutely) work is one piece of info (no doubt useful to those willing to try it in the first place ), but doesn't offer any clue to the more inquisitive among us as to WHY it doesn't work ... FWIW, I'm on Vista SP2 32-bit, so can't perform those tests myself...

... 99.9% of Spotify audio(+video) content is behind full blown DRM and requires the most-up-to-date version of the Widevine CDM (v4.10.2652.0); Widevine CDM (itself basically a DLL file) has abandoned Vista SP2 support at least 3 years ago, and will probably move out of supporting Win7 before the end of the year (WV is owned by Google and they have stopped supporting Win7 in Chrome, of which WV is a component, early in 2023) ... @Scarf32 should probably first test if his browser of choice under Vista's Extended Kernel does have a working EME/DRM implementation (via Widevine) at below test page: https://bitmovin.com/demos/drm The CDM sends hardware/platform/OS details to the configured licence servers, in order to receive a response with the content decryption keys; because all that takes place inside a so called black-box (the OS and the browser have no access to it at all), it's hard to tell beforehand if the Spotify WV lic servers will whitelist decryption key requests originating from a Vista+ExtKernel "system"; assuming, of course, that the ExtKernel itself enables the "correct functioning" of the Widevine CDM to begin with ...

... Actually, it uses Web Assembly (aka wasm) to do it : https://github.com/zamfofex/jxl-crx#readme ... Disgust echoed in the "archive.org" reviews/comments: ... And one thing mentioned in that quote above that seems to be the new "vogue" among app authors is the deprecation of 32-bit binaries (latest Paint.NET runs exclusively on Win10/11 64-bit), a development I face all the more lately when searching for Windows binaries (of various software) compatible with my x86 OS... I mainly blame MS and their latest OS, available solely as 64-bit ...

See UXP #993 ...

Yep, St52 does have that, too: As one can see, there's duplication inside the "value" column, but only "image.http.accept" mentions webp ...

As I wrote in my previous post, MS serve IE a somewhat different version of their Bing Search (home)page, compared to Fx-based browsers: IE9: NM28: So, they're not using UA-sniffing just to determine what image format to serve, rather which page flavour to serve ; it just so happens (and, as you said, this is no coincidence ) that the flavour targeting IE is being served JPEG instead of WebP... Actually, that was the first thing I tried before I ended up using a SSUAO "trick" for Bing Search homepage, and I can tell you it just doesn't work there ... FWIW, it doesn't even work in St52 if: a. You disable the native WebP decoder, by toggling "image.webp.enabled" b. Modify "image.http.accept" in the way you suggested... Best regards ...

... And quite recently, Microsoft themselves adopted Google's webp image format on their "own" webpages/services ... I have https://www.bing.com/ as one of my pinned tabs, and on that the background image changed format from ".jpg" (classic JPEG compression) to ".webp"; UXP-based browsers have no issue with webp, fortunately, but the old Firefox ESR 52.9.1 doesn't support the format: For the time being, MS still serve JPEG to their deprecated IE browsers, so changing the UA to, e.g., an IE9-based one will get the Bing background image back (on a slightly different GUI, tailored for IE): general.useragent.override.bing.com;Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0) NB: FxESR 52 doesn't support SSUAO natively, only via extension(s), however I had restored SSUAO support in it via a method made public years ago (search the forums here, if interested ) ...

That's most excellent news! ; If I may kindly ask , on which version of Microsoft Visual Studio? Because earlier I had speculated you had been using up-to-now either 2015 or 2017 ...

... Unless things have changed from 2019 : https://msfn.org/board/topic/177125-my-browser-builds-part-1/?do=findComment&comment=1169577 [ https://msfn.org/board/topic/177125-my-browser-builds-part-1/?do=findComment&comment=1170787 ] The OS is definitely Win7 SP1 x64, with ample RAM... As for MS Visual Studio, either 2015 or 2017, nothing newer ... I believe VS2017, up-to-a-version (?), would've allowed to install the v141_xp toolset (enables compilation of apps that can run on XP+; the default for VS2017 is NT 6.0, I think ) ... https://stackoverflow.com/questions/49516896/how-to-install-build-tools-for-v141-xp-for-vc-2017

@j7n : It was dom.forms.button.standards_compliant Toggle that to false and then restart Serpent 52 (this is important); you should then be able to invoke the image-related CM entries I talked about ; NB: Use of an adblocker is advised on Discogs; when I was testing in Safe Mode, I noticed increased CPU consumption ...

... Mine's 1280x800, so bigger by a small margin (2008 era Toshiba laptop) ... Mine looks different because I'm using a third-party complete theme (Photonic, modified to display correctly on Vista; the original targets Win7+); I'm also using an extension, Menu Icons Plus 3.2.1-signed.1-signed, which itself further alters the appearance of the context menu; complete theme + extension DO NOT interfere with the actual correct functioning of the browser's Context Menu, though... ... But sites often make sure "we don't always get what we want" ... Please, try with a clean Serpent 52 profile ; in some minutes, I'll update this post with screengrabs from a fresh St52 profile and its behaviour on the discogs URL you linked to previously... Later additions: On a fresh St52 profile, I have no issue with middle-clicking the small image on the top-left and loading: https://www.discogs.com/release/2872133-London-Starlight-Orchestra-Once-Upon-A-Time-In-The-West/image/SW1hZ2U6NTE2NDE5OQ== However, when I try to invoke the context menu by placing my cursor on top of the "bigger" image, I now get what you described: I then switched to my "dirty" St52 profile, but this time I loaded it in "Safe Mode" (to get add-ons out of the way); first difference I noticed is that my cursor, when placed on top of the "bigger" image, now turns into a small magnifying glass with the "+" sign, something that doesn't happen in the fresh profile; right-clicking produces a Context-Menu inside which image-related options are available: So, I have something(s) modified inside my about:config settings that restores the image-related context-menu entries; but, which something(s) ???

In St52, if in site settings I specify: then, upon visiting the URL you referenced, https://web.lloydsdirect.co.uk/sign-up/create-account, my IndexedDB storage isn't populated with data from "lloydsdirect.co.uk"; however, the same is true for cookies set from that hostname, which isn't useful on a log-in page, obviously ; as you said, site data (indexedDB) and cookies are interlinked under the "Cookies" moniker... Have you considered the "Allow for Session" setting? FWIW, you'd be auto signed out once you restart your browser session... Edit: I tried myself the "Allow for Session" setting; unfortunately, on page load I do get a "https+++web.lloydsdirect.co.uk" directory created inside my storage folder, however that directory isn't wiped out once I restart Serpent 52 ...

How small a screen are you talking about here? In any case, "hiding" artwork behind iframes is a known technique the sites employ... On St52, I middle-clicked on the Clint Eastwood "thumbnail" and in an adjacent tab it loaded: https://www.discogs.com/release/2872133-London-Starlight-Orchestra-Once-Upon-A-Time-In-The-West/image/SW1hZ2U6NTE2NDE5OQ== Carefully placing my cursor near one of the four image corners, I find the "context menu" is enabled, through which I can either copy the image URI, https://i.discogs.com/u7OohGushz9n7OLJKxejCKnTplWEFK2ZCqgRQgYZ3D0/rs:fit/g:sm/q:90/h:600/w:600/czM6Ly9kaXNjb2dz/LWRhdGFiYXNlLWlt/YWdlcy9SLTI4NzIx/MzMtMTMwNDk4MTgz/NS5qcGVn.jpeg or directly save the image on disk:

... there's always the adjective Hellenic , which is actually the preferred one (i.e. how "foreigners" should refer to everything Greek) among "Greeks" of today... (OT, I know, but I'm not the one who first committed that crime here .. )

... Well. "I" took that to mean he's offering to facilitate any infrastructure migration of the Roytam1 projects, should the existing infrastructure (GitHub repositories, binaries hosting server, etc.) becomes blocked by the HK regime; not as contributing actual code to those projects; but, of course, I'm not basilisk-dev ... ... And if I may say so myself, quite several of the last posts here seem to revolve around Mypal68; well, we do have a dedicated thread for it (possibly more than one), don't we?

... In addition to the above, basilisk-dev has no plans at all (and this has been specifically communicated here ) to invest development efforts on a browser that would run on anything below Win7 SP1 (current minOS requirements of official Basilisk) ... Best regards