VistaLover

That fetches a .CSV file, inside which: ia64 Windows Server 2008,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Hal.dll,6.0.6003.20489,"428,264",21-Mar-19,1:32,IA-64,None,Not applicable File name,Ia64_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_0726f69c1b902d52.manifest,,,,,, File version,Not applicable,,,,,, File size,"1,655",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),3:40,,,,,, Platform,Not applicable,,,,,, x86 Windows Vista,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Halacpi.dll,6.0.6003.20489,"137,960",21-Mar-19,1:53,x86,None,Not applicable Halmacpi.dll,6.0.6003.20489,"169,704",21-Mar-19,1:53,x86,None,Not applicable File name,X86_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_072552a61b922456.manifest,,,,,, File version,Not applicable,,,,,, File size,"2,244",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),3:57,,,,,, Platform,Not applicable,,,,,, x64 Windows Vista and Windows Server 2008,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Hal.dll,6.0.6003.20489,"230,632",21-Mar-19,1:41,x64,None,Not applicable File name,Amd64_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_6343ee29d3ef958c.manifest,,,,,, File version,Not applicable,,,,,, File size,"1,656",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),4:15,,,,,, Platform,Not applicable,,,,,, So, though not specifically mentioned, the KB does update HAL related files to v6.0.6003.20489

This is just a guess, but since I see no sse/ia32 part in the package's filename, I suspect it's been compiled to expect at least SSE2...

... YES; remove the LAV dlls adjacent to basilisk.exe, exit browser, relaunch browser and test: http://demo.nimius.net/video_test/ https://tekeye.uk/html/html5-video-test-page http://camendesign.com/code/video_for_everybody/test.html http://www.html5videoplayer.net/html5video/mp4-h-264-video-test/ https://ophi.org.uk/test-html5-video/ These DLLs have been updated by roytam1 on Sep 25th, 2021 ; they are based on FFmpeg 3.4.9 Those were based on FFmpeg 3.1.1 What does that even mean? What type of CPU are you on? If it supports SSE2 instruction set, download the default package; if it supports up-to SSE, download the ia32 variant; for even older CPU, give the noasm variant a try... The links are for the 32-bit architecture; the extracted DLLs must be placed adjacent to palemoon.exe (for NM27) / arcticfox.exe (for ArcticFox-Win); the browser has to be restarted to successfully load the DLLs...

... Serpent 52.9.0 on WinXP doesn't rely on LAV dlls for h264/aac decoding (i.e. playback); it uses a modified ffvpx third-party library; just make sure media.ffvpx.enabled is in its default value of true (FWIW, under Vista SP2 and higher, St52 defaults to using WMF system - OS - codecs; it can be configured to use ffvpx there, too, by disabling media.wmf.enabled; do note that ffvpx doesn't use H/W h264 decoding (Win7+), if your gfx card supports it, that is...). TL;DR: You should remove LAV dlls from within the Serpent 52 application directory! LAV dlls for NM27 (and related forks) were recently updated: https://o.rthost.win/palemoon/lav-dll-lite-3.4.9.7z https://o.rthost.win/palemoon/lav-dll-lite-ia32-3.4.9.7z https://o.rthost.win/palemoon/lav-dll-lite-noasm-3.4.9.7z Download the variant that is compatible with your CPU...

Clean Flash Installer repo moved, for now, to GitLab: https://gitlab.com/cleanflash/installer/-/releases/34.0.0.192 If Adobe are really determined, the future of that second repo might also be uncertain... PS: If on WinXP, to load that GitLab page you need a UXP browser by roytam1, along with the very latest version of github-wc-polyfill extension by JustOff; any flavour of 360EE will also do...

Web Archive scavenged links to CleanFlash_34.0.0.192_Installer.exe : https://web.archive.org/web/20210923173744/https://github.com/CleanFlash/installer/releases https://web.archive.org/web/20210923173709/https://github.com/CleanFlash/installer/releases/tag/v1.5 https://web.archive.org/web/20210923173709/https://github.com/CleanFlash/installer/releases/download/v1.5/CleanFlash_34.0.0.192_Installer.exe

The latest release of CleanFlash_34.0.0.xxx_Installer.exe WAS based on Chinese Flash v34.0.0.192 ; I wrote "WAS", because https://github.com/CleanFlash/installer An issue has been filed: https://github.com/darktohka/clean-flash-builds/issues/4

@roytam1: https://forum.palemoon.org/viewtopic.php?p=220472#p220472 https://www.basilisk-browser.org/releasenotes.shtml http://archive.palemoon.org/source/basilisk-2021.09.27-source.tar.xz Have the above been taken into account already? Thanks for all you do for these communities here!

Evil Microsoft have removed that package (VCForPython27.msi) last April (2021) ... Fortunately, WebArchive have salvaged it below: http://web.archive.org/web/20210414074322/https://www.microsoft.com/en-us/download/details.aspx?id=44266 http://web.archive.org/web/20210106040224if_/https://download.microsoft.com/download/7/9/6/796EF2E4-801B-4FC4-AB28-B59FBF6D907B/VCForPython27.msi Digitally signed (SHA1, WinXP compatible) on Sep 29th, 2014 ...

... Hopefully the following indispensable Chrome extension https://chrome.google.com/webstore/detail/get-crx/dijpllakibenlejkbajahncialkbdkjc will continue to work as designed in the "ungoogled" flavours... I use it routinely to manually download and archive .CRX files directly from CWS (not crx4chrome and similar... ), because my experience so far of using various 360EE variants in my Vista laptop has proved that any of my already installed extensions a. may suddenly disappear completely from CWS, for various reasons... b. be updated to a version not working correctly/at all with a specific 360EE version; this is often true for 360EEv11 (Chromium 69 based) and 360EEv12 (Chromium 78 based), but I expect to hit similar issues in the near future even for 360EEv13 (Chromium 86 based), because most Chrome extensions are developed/updated to target current Chrome (v92?) and declared backwards compatibility in CWS is often just a joke... It's too late if I first update an extension but then discover it's broken, because CWS, unlike AMO, doesn't host previous version(s) of an extension... Below is an excerpt of a previous edit (saved in an e-mail notification) of https://msfn.org/board/topic/182993-360-extreme-explorer-arcticfoxie-versions/?tab=comments#comment-1205088 I've been mostly using the Russian RePacks of 360EE variants and while I was always able to add Chrome extensions directly from CWS, never have I observed one automatically update... One can perform a simple test to verify: Browse crx4chrome or similar third party Chrome extension archives, search there for and download the .CRX file of a previous version of an extension extant in CWS (all crx4chrome hosted files were originally retrieved from CWS) ; manually install by dropping the file on the Extensions tab (chrome://extensions/) ... No matter how long you give it (hours, days, etc,), the extension won't be auto-updated to the latest version found inside CWS; often times, this is a blessing in disguise, because, despite CWS saying the opposite, the updated version won't "like" your version of 360EE (being sourced from an older Chromium codebase...). However, in the event you do want to update an installed extension, again this is not straightforward ; visiting the CWS entry for the extension, you're only given a choice to "Remove from Chrome", not "Update Extension"; to "update", you have to actually first "remove", but this means losing all extension custom settings/modifications... Several Chrome extensions offer the choice of backing-up settings/configuration prior to removal (with the option of importing back in a fresh installation), which makes updating them in 360EE somewhat less cumbersome...

... I'm not following closely the developments in this thread (am notified via e-mails, though ), but are you people here aware of https://github.com/NeverDecaf/chromium-web-store ? It is supposed to re-enable CWS functionality in Ungoogled-Chromium, perhaps it can also be used in your "ungoogled" 360EE flavours?

If you're a user of JustOff's "GitHub/GitLab Web Components Polyfill" extension, this has been very recently updated to v1.2.4, to mitigate mainly GitLab introduced breakage... https://github.com/JustOff/github-wc-polyfill/releases/tag/1.2.4 For those not in the know, this extension is indispensable to users of UXP-based browsers (official ones and forks) to enable them to work properly on these two popular web-hosted code repositories... After Microsoft acquired GitHub some time ago, they let go the old team of developers and quickly turned that platform (github.com) to target mainly their new "child" of a browser, Chromium-based Edge ("affectionately" also called ChrEdge...); support for "legacy" browser engines was dropped like a hot potato, their introduction of Web Components necessitated the creation of said extension for GitHub (because the venomous upstream devs couldn't port Google's WC APIs to UXP...). GitLab resisted more the implementation of WC on their codebase, but it has been steadily happening over the course of 2021; the extension was extended (pun intended ) to also cover gitlab.com pages on UXP browsers... In a move reminiscent of the pair Mozilla Firefox and Google Chrome, GitLab is now in hot pursuit of GitHub: not only are they embracing WC for everything (even emojis ...), they have recently dropped support for Firefox < 78.x.x (breaking GitLab compatibility with WaterFox Classic, SeaMonkey and, of course, UXP-based browsers ) ; in doing so, they introduced RegExp with Named Capture Groups (a subset of V8 regexp code), which is only found on Fx >= 78.0 ; the latest extension update to v1.2.4 tries its best to remedy above changes... JustOff also extends an invitation to our "own" @roytam1 to consider porting RegExp with Named Capture Groups to our UXP fork, since a WaterFox Classic developer already did it there... But, without being a coder, I fear this task presents serious challenges, because WFC is Fx56-based, while UXP only Fx52-based; plus, there's a lot of code to be tested and merged as it is... Usability details: Those with the extension already installed in Serpent 52.9.0 should have been already auto-updated; those who want to install it for the first time on Serpent should install it directly from GitHub; those using New Moon 28 must first download the updated .xpi to disk and manually modify its install.rdf file (to target New Moon 28 proper versions) prior to installing it; I have explained all this in detail in relevant previous posts... The extension works as intended on fairly recent versions of UXP (older versions of Serpent and NM28 - recently put in the spotlight for generating better benchmark results - lack needed APIs to sustain the correct functioning of GitHub/GitLab pages). In the not-so-distant past, the extension could be force-installed on FxESR 52.9.x to restore some percentage of GitHub functionality, but M$ have broken it so much during these last three months, that such an installation is now moot... Affected in the same manner is Serpent 55.0.0; its web engine is considerably behind UXP (but better than FxESR 52.9.x's), force-installing the extension there will now only achieve very few github.com parts working as intended...

Sadly, above links produce 404s and need to be changed/fixed... Same is true for similar links found on https://rtfreesoft.blogspot.com/2021/09/weekly-browser-binaries-20210918.html Just as a FYI ...

I'm not sure whether @roytam1 or other members here became aware, BUT: The story thus far: 1. MCP, effectively spearheaded by M.A.T.'s actions/decisions, forced the Centaury & MyPal forks into brutal extinction (sudden death I'd call it in sports terms...) 2. "Some person" (perhaps one supporter of those killed projects?) "flagged" M.A.T.'s GitHub account: https://forum.palemoon.org/viewtopic.php?p=220044#p220044 The story from now on: Chapter: Revenge of the enraged beast(s) 1. The UXP platform in its current form shall be NO MORE; the GitHub mirror of UXP (infrequently updated by M.A.T. after major Pale Moon releases) https://github.com/MoonchildProductions/UXP has been hidden/removed... 2. The main UXP development repo, hosted on Moonchild's own Gitea instance, has been archived and moved to https://repo.palemoon.org/mcp-graveyard/UXP 3. Development repos of applications Pale Moon and Basilisk have also been archived in https://repo.palemoon.org/mcp-graveyard/Pale-Moon https://repo.palemoon.org/mcp-graveyard/Basilisk 4. The development of the "new" Platform (tentatively named "Platform Codebase"), as well as that of the "new" Browser application pushed out by MCP (rebrandings are to be announced) WILL FOLLOW THE PATTERN OF BINARY OUTCAST APPLICATIONS, i.e. all code repositories SHALL BE PRIVATE (like the Interlink and Borealis Navigator ones are currently ), Source Code will only accompany the releases of executable forms (i.e. binaries). https://forum.palemoon.org/viewtopic.php?p=220136#p220136 (I don't want to publicly voice my opinion here, as, most probably, forum filters will censor it... ) The above effectively puts the New Moon 28/UXP and Serpent 52/UXP forks out of commission, and with 0 hopes of a new fork based on future MCP iterations... A most sad day, indeed...

Hi there. What'd be the equivalent for basilisk? On my system, I'm successfully using general.useragent.override.addons.basilisk-browser.org;Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101 Goanna/4.8 Firefox/68.0 Basilisk/52.9.2021.07.19 NB that official Bk is a 64-bit only release on Windows 7+...

Thanks, but how is this better to browsec-3.16.16 (and 3.16.16.2_unofficial) ? I visited the link posted (and used machine translation to read it ), that post doesn't make it clear for me... I then went on to try it in latest St52 [v52.9.0 (2021-08-20) (32-bit)] ; clicking the toolbar button just toggles the extension (and connection) ON/OFF, there's no apparent way I can choose one of the four available "free" locations (NL, SG, UK, US), as the extension always defaults to the Dutch (NL) server...

Posted link yields: 404 Not Found Correct link should be: https://o.rthost.win/palemoon/palemoon-28.10.4a1.win32-git-20210821-ba47fad4d-uxp-4ac28d1d4-xpmod.7z (... and I suspect links to the rest of the NM28XP variants should also be corrected... )

... Because it appears you're using on NM28 a (modified) NL Pale Moon language pack, isn't it so my friend?

M.A.T. has responded, apparently: https://forum.palemoon.org/viewtopic.php?p=218855#p218855

Wrong on both counts... Vista's End of Extended Support came in April 2017 (2017-04-11); WS2008's End of Extended Support came in January 2020 (2020-01-14) ... WS2008 updates released after Apr 11th 2017 (Vista's EoS} can be manually downloaded from MUC (Microsoft Update Catalog) and installed in Vista SP2 (with select few exceptions), practically "extending" its "Extended Support" up to January 2020... Additionally, M$ provide, under a fee, continued (paid) support for WS2008 (for Enterprises, only ) with security-only updates for an additional 3-year period, i.e. until Jan 2023; the Vista user community has come up with tools/ways to also install these ESU (Extended Security Updates) to Vista itself, prolonging its "Extended Support" up to Jan 2023; the morality/legality of applying this set of ESU updates on Vista is grey/questionable at least, so I won't elaborate more on this... Sadly, I'm not applying WS2008 ESU updates on Vista, but if M$ did release this annoying "security feature" for Adobe Flash in IE11 ("last March" signals it was an ESU update for Win7 SP1), it's highly probable a similar update was issued, under the ESU plan, for WS2008's IE9... ... Not one of those few , in fact IE9/Vista SP2 is practically worthless for most sites of 2021 , including MSFN, but I suspect IE11/Win7+, now deprecated itself, has still some residual "life" into it, if one cares to browse the web of 2021 with it ...

Direct download link, without an Oracle account : https://javadl.oracle.com/webapps/download/AutoDL?BundleId=245061_d3c52aa6bfa54d3ca74e617f18309292

With respect @we3fan, I believe the answers to ALL this second wave of your questions are to be found inside my previous post to you ; I know you did thank me for it, and you're welcome, of course, but have you actually took the time to digest it? Was my "language" too "techy" for you? If yes, I do apologise, but I assume this community of XP die-hards to be more savvy than the average Joe ... To re-iterate: Firefox 52 ESR on Windows XP, no matter the SP level: Zero h264=avc=avc1 native decoding support for HTML5 MP4 video/HTLM5 AAC audio This means that if you disable native webm support by setting media.webm.enabled;false , on YT there'll be no way to play any video. NB, that webm is actually a media container, NOT a codec; webm is a subset of the matroska container and can contain VP8/VP9 video codecs, as well as opus/ogg audio codecs... Firefox 52 ESR on Windows XP 32-bit SP2 => no known way to implement h264/aac decoding support on such a setup (h264=video, aac=audio) Firefox 52 ESR on Windows XP 32-bit SP3 => implementation of h264/aac decoding support is possible via installation of the Adobe Primetime CDM (which, once more, requires XP SP3). - So, no need to demand further testing from @nicolaasjan ... - Firefox 52 ESR on fully updated Vista SP2 32-bit (and more recent WinOSes) => by default h264/aac decoding support enabled, without additional action on behalf of the user; the browser uses, via WMF, patented decoders already present in the OS level... As a Vista SP2 32-bit user on actual hardware, I can assure you that FxESR 52.9.x 32-bit on a fully updated Vista OS does have working h264/aac decoding support, without any need for AP CDM; however, I'll agree with you that some "quirks" are indeed present in that support, in the sense that some MP4 videos with highly unusual DAR (e.g. "perpendicular" video shot with a mobile phone) fail to decode with Vista's WMF decoder...

... This is Windows XP SPx you're still talking about , official Mozilla Firefox builds NEVER supported natively the h264 proprietary decoder in HTML5 video; the decoder is patented and its native inclusion in a browser requires the browser authors pay a "handsome" fee to the patent owners (the MPEG4 consortium). Google are rich enough to afford that fee, so Google Chrome comes bundled with that decoder (AVC=h264) and hence it's capable of native h264 playback under Windows XP... When Adobe Flash Player was around, it itself came with bundled h264/aac decoders (again, because Adobe are rich), so MP4 video streams could be played, via that plugin, even in browsers (like Firefox) without that decoder built-in (and XP users, like yourself, were "happy"...). When many video sites abandoned Flash and instead started using HTML5 embedded web players, the lack of h264 decoder in Firefox rose to the surface, again for Windows XP users ONLY... Your favourite OS is deficient in this sector because the vendor, Microsoft, did not equip it originally with that patented decoder, nor a provision was made to add it in a later stage via an update... You see, Mozilla, instead of paying the h264 patent fee, decided to shift the "issue" to the OS itself, so that Firefox could make use of the h264 decoder already present in the OS (as Microsoft had already paid that fee themselves); unfortunately for you, h264 dec is only present in Vista SP2+Platform-Update-Supplement and higher - the way for Firefox to use it is through Microsoft's WMF (Windows Media Foundation) framework, so you can't bring h264 support to Firefox under XP via installing Codec Packs (these are used for DirectX media players, like WMP). The Adobe Primetime CDM (content decryption module) came with a bundled h264 decoder (patent fee paid by Adobe) and as a side-effect (its primary purpose was DRM) it can be used as an HTML5 h264 decoder in versions of Firefox that supported the CDM (off the top of my head, I think it was v47.0-51.0 officially, but v52.0 also works) - again, this is solely for XP... Regarding Roytam1 browsers: New Moon 27 doesn't support h264 natively (on any OS), but you can "install" such support by downloading an additional "package" (lav), extracting it and placing some DLLs adjacent to "palemoon.exe". The UXP-based browsers, like New Moon 28 and Serpent 52, come with a special "kludge", i.e. h264 decoding support is included in the ffvpx third party library (for XP's sake only, the UXP-based browsers can still use WMF's native decoder, if on Vista SP2 and up...). Lastly, HTML5 video decoding in a browser under XP is S/W only, so the video watching performance you get depends, among other things, on the video codec selected to begin with and your CPU; some codecs are taxing your CPU more heavily than others; the higher the resolution/bitrate/framerate, the more your CPU suffers; performance of the youtube webpage alone (which is a literal beast of JS and CSS code currently) depends on the browser engine, CPU, GPU, available bandwidth, CDN you are served from, content blockers, etc. so, while I find these "stats-for-nerds" logs to be of some substance, they have little statistical weight when compared between different setups... The Adobe Primetime CDM requires SP3 for Windows XP... His "log" mentions the av01 video codec, aka av1/AOM, do note AOM != AVC, official Firefox ESR 52 never supported that codec; the codec is, however, supported in UXP browsers via a pref: media.av1.enabled;true but decoding taxes heavily your CPU... PS: @UCyborg 's post appeared in the middle of writing this , he's right, of course, but my post expands on what he kindly posted...

... Continued here, as being OT for this thread...

... Picking up from a "relevant" WinXP thread/post The first (v13.0.1) of the v13 series is also the last built on .NET FW 4.6.2, so with 4.6/4.6.1 installed on Vista SP2, I expect this specific (portable) version of ShareX to have the best compatibility with such an "installation scenario" (i.e. Vista SP2+.NF461) ; as noted previously, you'll have to modify the ShareX.exe.config file (adjacent to ShareX.exe) for the app to even launch: v13.0.1 sports a new dark theme (over previous v12.4.1) and generally, in my limited testing, works as expected (including update checks); one thing that doesn't work is the ffmpeg.exe binary auto-download (you should get a confirmation dialogue when selecting "Tools -> Video thumbnailer"), because versions before 13.2.1 were hardcoded to fetch from the now defunct Zeranoe builds repo (see attachment) ... In any case, that Zeranoe ffmpeg build was not Vista-compatible ; to rectify these issues, download manually a Vista-compatible ffmpeg.exe binary and place inside the following directory: "PortableRootDir\ShareX\Tools\" On launch, the app should pick up the existence of the binary and an entry should be created inside file "PortableRootDir\ShareX\Tools\ApplicationConfig.json", in my case, it's "FFmpegOptions": { "OverrideCLIPath": false, "CLIPath": "G:\\PortableApps\\ShareXPortable\\ShareX-13.0.1-portable\\ShareX\\Tools\\ffmpeg.exe", Because I was feeling adventurous , I decided to also test the latest ShareX version, i.e. v13.5.0; as @Vistapocalypse correctly pointed out here, this is built on .NET FW 4.7.2 (not 4.6.2), so I was quite curious to explore the possibility of it running on already installed 4.6.1 ; after, again, modifying ShareX.exe.config file (4.7.2 -> 4.6.1), I was surprised but pleased to discover the app did launch : Update checks do still work (the app reports it's up-to-date), as most other aspects of the program, but I must admit I haven't tested extensively... In contrast to 13.0.1, ffmpeg.exe auto-download works (it is now fetched, as a zip file, from a dedicated ShareX GitHub repository), but installation fails under my setup , because the extraction of the ffmpeg.zip file is delegated to functions only found on .NET FW 4.7.2+; the downloaded (zipped) binary is a saved copy of a ffmpeg-4.3.1-win32-gpl Zeranoe build, not launching under Vista (because of libx265 NUMA code), so it wouldn't accommodate even if extraction succeeded ; the "manual" installation route has to be followed here, too... What was the initial reason the devs dropped official Vista (and XP) support? Well, "they" had stated that on Vista update checks wouldn't be possible... So glad the Vista community proves them wrong!