VistaLover

Complete about:buildconfig from latest St52 x86:

Thanks for that info and much obliged in advance ; waiting hasn't hurt anyone, I guess ; thanks in advance to Roy , too, for when the backport gets merged "here"... OT1: Today's Bing Search homepage image was a dense set of buildings/flats, the info about it told it was a night view of Hong Kong: https://www.bing.com/th?id=OHR.WorldPopDay_ROW3908629060_1920x1080.jpg @roytam1, are you able to spot your own flat there ? OT2: @basilisk-dev : I honestly hope you're not located in those parts of The States afflicted by record high temperatures... If you are, I can surely empathise, since from July 12th a very intense and prolonged heatwave, originating from Northern Africa/The Sahara Desert, will find its way towards my area of the world... Anyone still thinking "Climate Change" is safely many years to come?

https://repo.palemoon.org/MoonchildProductions/Pale-Moon/releases/tag/32.3.0_Release This was actually PM#1925 (and PM#1926) ; could this be, hopefully, backported to also cover Serpent 52.9.0, please?

... Thanks for the confirmation!

... Just a short while before you posted this, I had finished applying your fix locally ; unfortunately, this, again, involves messing with the omni.ja archive... The file to be patched according to the GitHub commit resides in: "<St52-appDir>\!omni.ja\modules\DownloadUtils.jsm" (! = expanded) After you've finished patching the file, locate "<St52-appDir>\!omni.ja\jsloader\resource\gre\modules\DownloadUtils.jsm" and DELETE it; this is a compiled version of the (original) file in the previous location; by deleting it, you'll force St52 to load the edited raw source file rather than the compiled one (minute performance degradation to be expected ). Once finished, repack (and re-optimise) to an omni.ja file, overwriting the original... So far, so good ...

Laptop was waken up from sleep, another vicious circle happened in latest St52, this time trying to download an .EXE file : The same display as above, but with the Downloads Window extension disabled: This is extremely frustrating for me, to the point I'll downgrade to previous weekend's St52 - but, for how long ? Is no-one else seeing something similar? Later addition: FTR, I have below, downloads-related, prefs modified from their default values: browser.download.panel.shown;true browser.download.saveZoneInformation;0 browser.download.useDownloadDir;false privacy.cpd.downloads;false

Hi @Proteus ; let me assure you you're not imagining things here ; there's definitely something broken in the downloads API of the latest batch of the UXP releases , as I've found myself when updating to the latest St52 (32-bit) ... For starters, something has reset the user-set default download action based on file-extension ; clicking on a link to a zip file, I was presented with below "choose window": For years, my default DL action was "Save File" ; I had to set this anew ... I'm also using the "Downloads Window" legacy extension, which approximates the old, Fx24-era, "toolkit" DL window, but that shouldn't matter, because the extension hooks directly to the "Library=>Downloads" interface... Immediately after saving the zip file shown above, the DLs Window appears completely empty (as reported): When I invoked that window a second time (via the toolbar DL button), only the latest DL entry of the session appears, and even that without its details (size, domain, time): Scrolling down in that 1-entry window makes previous entries magically appear, again without their DL details: The only way to fix those DL "oddities" is a browser restart, after which things return to a "normal" state: Previous St52 x86 build did not suffer from these bugs... @roytam1 , in your "DL-manager-extensions" related post you cited the new IntlAPI commits as the probable culprit, do you think that: [network] Prepare for requiring Authorization in CORS ACAH preflight and: [XPCOM] Win: Update executable extension list could have also played a part towards the DL breakages? Thanks in advance for any insight ...

... Thanks a lot for your test ; this, in turn, "pushed" me to run a second set of testing, this time with fresh/clean St55 profiles... TEST 1: Latest St55 x86 package, i.e.: basilisk55-win32-git-20230708-fe0a96ad1-xpmod I loaded a pristine St55 profile and then visited the DRM test page, i.e.: https://bitmovin.com/demos/drm I let St55 "download and install necessary components" (ca. 5min, for good measure ), then I restarted it; result: The Widevine CDM populates the plugins list inside "about:plugins", as well as the plugins list in "about:addons => plugins": This means I have to debug my current St55 "dirty" profile as to why WV CDM is absent in both these lists ... However, the end result is the same as reported by @Mathwiz ; EME/DRM/Widevine doesn't work as intended on the browser side: NB: On that screengrab above, I have also highlighted the "glitches" the default theme exhibits under Vista's Aero... TEST 2: Downgrade St55 x86 to the March 30th 2019 package, i.e.: basilisk55-win32-git-20190330-09b851794-xpmod Load with it the same clean-ish St55 profile created in TEST 1 and, again, visit the same DRM test page; the "story" now is very different: 1. The "DRM" icon does appear in the URL bar 2. EME/DRM/Widevine work as intended on the browser side, but DRM licence acquisition fails on the WV server side, because the CDM version requesting it has been revoked... NB2: One can also visually confirm in the screengrab above how "well" the default St55 theme blends with the Vista OS and its Aero feature ... ... Not "moot point" for me though , because when the Widevine implementation in Serpent works (it currently does in 52, does not in 55), it will alert me that the media service visited employs DRM, thus I'll have to view the content on a sanctioned browser, on a sanctioned OS... If I had to put my money on it, I'd claim: 1. St55's default theme under Vista has been broken by: port most of XP related hunks from iceweaselXP-53 2. As posted already, Widevine in St55/Vista+ has been broken by: ported change from iceweaselXP-53: Restored eme-adobe plugin support for Windows XP systems. Do you see it? It was "iceweaselXP" (Widevine wasn't "meant" to work under XP, and, likewise, XP doesn't support "Aero"...). Probably very difficult to fix both now...

... I don't even have Adobe Primetime CDM installed in my Serpent 55 profile - never needed it on Vista SP2, TBH ; but, I do have the Cisco Systems OpenH264 video codec v1.6 installed (and disabled), which correctly displays inside about:addons and about:plugins; widevine doesn't in either ; in my St55 profile, I have: media.eme.enabled;true media.gmp-widevinecdm.autoupdate;true media.gmp-widevinecdm.enabled;true media.gmp-widevinecdm.visible;true and the CDM correctly installed. When I downgrade St55 to a build before Apr 2019, in that same profile, then WV CDM is correctly recognised and additional prefs: user_pref("media.gmp-widevinecdm.abi", "x86-msvc-x86"); user_pref("media.gmp-widevinecdm.autoupdate", true); user_pref("media.gmp-widevinecdm.lastUpdate", 1549772952); user_pref("media.gmp-widevinecdm.version", "1.4.8.903"); appear inside my profile's pref.js file... Update St55 and these prefs are NOT read! Am afraid I've given all pertinent detail I found at the time; FWIW, I suppose you can troubleshoot DRM/Widevine issues in St55 on a Win7 OS too, probably no immediate need to install a Vista VM (a necessary step to troubleshoot the default St55 theme issue reported though, because under Win7 all looks fine); might be worth to inspect how St52 does it, as there both Adobe Primetime and Widevine can happily coexist... (Apologies, it's finally bed time here, so I'll be unavailable for quite a while ...) Edit: See further tests and discussion here ...

... This is not accurate, though, because roytam1 did restore the bits of code that implement native Vista SP2 WMF support that Mozilla (and MCP) had originally removed... Yes, that's true, support for patented decoders aiming the XP OS (and Vista without PUS[Platform Update Supplement]) had been realised via modifying the ffvpx library, which uses ffmpeg code... Latest St55 (32-bit) comes with both media.wmf.enabled;true media.ffvpx.enabled;true and if I disable ffvpx, the app can still play back MP4 files via Vista's WMF ; the only major advantage of Vista's WMF over the ffvpx lib is that WMF allows for H/W decoding of h.264 video, provided your GFX card supports it; mine doesn't , so ffvpx stays turned ON... On the Vista side of things, however, two "things" at least remain broken ... a. The default St55 (complete) theme renders unsatisfactorily in the caption buttons (minimize/maximize-restore/close) area; it was all fine in the first St55 builds, below is a snapshot from a March 2018 St55 build: (which shows good rendering around the caption buttons area), but at some later point (I think it was one tenfourfox backport?) it broke in the same manner the default St52 theme renders under Vista: b. While St55 is still being built with "--enable-eme=widevine", its EME/WV implementation has been broken since many years ; by "broken" I don't mean that the WV CDM "can't properly decrypt DRM'ed content", this is to be expected if Widevine worked in the first place , because St55 inherited WV v1.4.8.903 from Mozilla, and that very old version has been deprecated by Google many years ago ... The actual problem/bug is that currently St55 doesn't even recognise the WV CDM when correctly installed and it doesn't display it at all inside the about:plugins list (provided "Play DRM content" has been enabled in preferences); this is a long standing issue I never bothered to report, because I normally use St52 to detect DRMed online media content ... Unlike the default theme issue above (a), I had kept records of the manifestation of this bug, here it goes: Last GOOD build: basilisk55-win32-git-20190330-09b851794-xpmod (buildID=20190329133942) First BAD build: basilisk55-win32-git-20190406-4d70836fa-xpmod (buildID=20190405065215) Regression window: https://github.com/roytam1/basilisk55/compare/09b851794...4d70836fa Probable culprit: ported change from iceweaselXP-53: Restored eme-adobe plugin support for Windows XP systems. So, in order to supply Windows XP users with an additional way to play-back MP4/m4a files in St55 (via the Adobe Primetime CDM, already familiar with in FxESR 52/St52), Widevine CDM became broken for Vista+ users ... Widevine CDM v1.4.8.903 for St55 (32-bit): https://www.mediafire.com/file/jrjkcqazh1xz6ce/gmp-widevinecdm.7z/file (The file should be extracted as a "gmp-widevinecdm\1.4.8.903\*" dir tree and placed inside your St55 profile directory); testing should be done on, e.g., https://bitmovin.com/demos/drm on fully updated Vista SP2 onwards, with up-to (and including) "basilisk55-win32-git-20190330-09b851794-xpmod": Later versions of St55 will just report:

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 ...