VistaLover

Hi ; this is a well known and documented limitation of said extension: https://github.com/JustOff/ca-archive#compatibility-and-installation => The author (@JustOff) is a member of the Moonchild dev team, this addon was primarily conceived to be installed in Pale Moon and/or Basilisk; the former does not inherently support electrolysis (e10s code present inside the UXP platform has been willfully crippled by Moonchild team for "application/palemoon"), while the latter does not officially support e10s (nor have any tests for it been performed with multiprocess mode turned on...). However, the same author appears to be somehow affiliated with the Waterfox browser project, they are the ones kindly providing hosting space/bandwidth for all legacy extensions catalogued inside CAA. Current Waterfox (a 64-bit only browser) requires Win7+, so am not in a position to try it (Vista SP2 x86 user); it comes with e10s turned ON by default, hence CAA issue #2 was submitted; the extension author came up, in v1.2.2, with a "dirty hack" to deal with e10s in Waterfox: https://github.com/JustOff/ca-archive/commit/a565810 What this hack in effect does is, instead of generating the Multi-process mode is not supported now, please disable it and restart Waterfox pop up notification, upon clicking CAA's toolbar icon, it spawns a second non-e10s Waterfox window, where CAA can function properly (i.e. Waterfox can interpret the caa: protocol). I have inspected the "new" code inside linked commit and, after local experimentation, have found out that implementing the same "dirty hack" for multiprocess Basilisk/Serpent is as simple as substituting the string "Waterfox" in https://github.com/JustOff/ca-archive/blob/a5658100f67aafe1ee140545a6ab7397cdc1ec78/bootstrap.js#L169 (this is in file bootstrap.js) with the string "Basilisk": - if (e10s && Services.appinfo.name != "Waterfox") { + if (e10s && Services.appinfo.name != "Basilisk") { Be sure to first close the non-e10s window after you're done with it, i.e. simply browsing the CAA lists or having just installed something from CAA, prior to restarting the browser (to complete legacy addon installation) ... Hope it works for you as it did for me (though I am inclined to run Serpent 52.9.0 in its default configuration, with e10s OFF => less RAM consumption )

I recollect posting this before, but for people reading this latest discussion about JRE 8u191 (CPU release) vs JRE 8u192 (PSU release): and from there: https://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html You are then, of course, free to make your own individual choice...

It's probably a CDN thing; I just tried the link for the ActiveX setup here (UTC+02:00) and it correctly fetched the 32.0.0.114 version; content on their US distribution servers (UTC-08:00 to UTC-05:00) will update soon, methinks...

@Tamris It's totally fine , I never implied you should have frequented the rest of the XP forums; I just posted that piece of info to let people here (in the Vista subforum) know how "I" was informed of the existence of the unofficial 2.49.5 builds; I hope it's clear now...

... This was also linked to by @roytam1 in the corresponding XP thread: The thing is, I had previously landed in that "repo" some weeks after 2.49.4 became EoS (or rather the Mozilla ESR 52.9.0 platform it builds on...), but I was dismayed to find out that only win64 builds were offered... ; so I was pleasantly surprised to discover a win32 build is now available: Not an official build, surely; these are being compiled and offered by a dev named Bill Gianopoulos (of Greek descent), he states himself that: It comes with ChatZilla, DOM Inspector and Lightning extensions pre-installed (as system addons), too (PS: I couldn't help noticing the increase in size for file xul.dll, from 53.1 MB in official 2.49.4 32-bit (compiled with Visual Studio 2015) to 61.7 MB in latest "nightly" (compiled with Visual Studio 2017 )) ...

... I can reproduce; I had to temporarily switch to the default theme (am using Dark Moon 2.3.0 otherwise) to notice it more clearly: for a fraction of a second, the embedded search bar (in the middle of about:home) appears truncated (i.e. shorter) when about:home is loaded for the first time, but then auto-resumes its normal length... NB that when DDG is set as the default search engine (which is the default setting), the search bar is shorter, because it is prepended by the DDG icon (at least in the default theme); when other search engines are user-selected, these come with no icon and an elongated search bar... The changelog between buildID=20181221223321 and buildID=20181228225818 (for 32-bit) is: https://github.com/MoonchildProductions/UXP/compare/ba81aaf...83cd966 The one relevant commit that easily stands out appears to be: [PALEMOON] Initialize the search service asynchronously from 'about:home' and 'about:newtab' : https://github.com/MoonchildProductions/UXP/commit/cb2f0f614362d3e986d585d6d1b4a2eaa20a1365 Hope your query is answered

Many thanks indeed for letting us know ; I decided to give Otter Browser v1.0.01 a shot Main site: https://otter-browser.org/ GitHub source repo (+ issue tracker): https://github.com/OtterBrowser/otter-browser SF Windows binaries repo: https://sourceforge.net/projects/otter-browser/files/ At this time, no installer (setup) is available for latest (stable) version; one exists for previous RC, "otter-browser-win32-0.9.99.3-rc12-setup.exe", though... It appears that the binaries (setup.exe/.7z packages) meant for Win7+ have been compiled with Qt 5.10.1 (which requires Win7+), while the "*.xp.zip" packages have been compiled with the older Qt 5.6.2 framework, still compatible with both XP+Vista... From my brief encounter with otter-browser-win32-1.0.01-xp.zip, I can safely say this is far from being an alternative to both of roytam1's referenced browsers... At best, this is a project under development, a long distance away from maturity - despite the recent "stable" label, with very little customisation capabilities, no support yet (that I can see) for any browser extensions and, worse yet, the Vista compatible build has some additional shortcomings, due to the older version of Qt used in that... The Qt 5.10.1 versions (Win7+) of Otter have the "mediaservice" directory with wmfengine.dll inside it, this suggests Otter is capable of accessing WMF (system) decoders in Win7+; the Vista version (built on Qt 5.6.2) doesn't have this wmfengine.dll but instead has a "lib/gstreamer-1.0" subdirectory, which suggests that the build can't access Vista system codecs and media decoding is delegated to gstreamer instead ... Perhaps I am missing something obvious to experienced Otter users (e.g. the need to install gstreamer for Windows?), but I was unable to play ANY youtube video on my Vista SP2 laptop; in fact, when visiting www.youtube.com/html5 this is what I get: I wasn't willing to try installing gstreamer for fear it messes up with already installed codec packs, FWIW Vista isn't officially supported either: https://gstreamer.freedesktop.org/documentation/installing/on-windows.html So, for me at least, Otter will remain just a "curiosity" project I may check upon from time to time, not a match to New Moon 28.3.0a1 that I'm currently using for my main browsing needs...

According to Qualys SSL Labs, that domain resolves to two IPv4 (104.28.10.185, 104.28.11.185) and two IPv6 (2606:4700:30:0:0:0:681c:ab9, 2606:4700:30:0:0:0:681c:bb9) addresses: https://www.ssllabs.com/ssltest/analyze.html?d=robotbirds.co.uk Looking closer at the log for, say, the first IPv4 server (104.28.10.185), https://www.ssllabs.com/ssltest/analyze.html?d=robotbirds.co.uk&s=104.28.10.185 if one scrolls further down to the Handshake Simulation section, one can see that Google Chrome 49 on XP SP3 is unable to establish the secure connection due to handshake failure: Google Chrome 49 (unlike Gecko type browsers) relies on the system installed certificate store and system available cipher suites, on XP SP3 the supported cipher suites are shown in: https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP SP3&key=136 (I believe additional cipher suites should be available if POSReady updates installed); but the server at robotbirds.co.uk does not support any RSA suites, so no go for Chrome 49... Also, the site requires SNI support in a browser, hence IE8 is also excluded; use FirefoxESR 52, New Moon 28, Serpent 52.9.0 to access; or use @heinoganda's ProxHTTPSProxy with Chrome 49...

Happy New Year to all members here (and since timezones were exchanged, mine is UTC+02:00 ) ! I was away from home during the past few days, internet connection was iffy and expensive, so not very practical to post here at MSFN... @roytam1 May you be blessed and continue, during 2019, to provide us with XP/Vista compatible builds of your browsers; your efforts, altruism/kindness are immensely appreciated... @CoRoNe I think I have a solution to your predicament; what it boils down to is: 1. Use a browser capable of displaying the "consent.talpanetwork" page; I used New Moon 28 with uBlock Origin temporarily disabled on that page (this is needed for the cookie consent dialogue to appear; with uBO ON, it doesn't ); now we know you can't yourself use any of the UXP/moebius browsers, since they require an SSE2+ capable processor; one solution would be for you to do this on a friend's/relative's box... 2. Your "YES" cookie consent is stored in browser cookies, locally; the idea behind my solution is to export those "kijk" consent cookies from the third browser (NM28 in my case) back to the (SSE compatible) NM27 browser you're using... You need install in both browsers the CookieKeeper legacy extension I mentioned some pages back Get yourself somehow familiarised with the addon, its settings and its usage (you'd agree that my intent here wouldn't be to teach you how to use it... ); after you agree to the cookie dialogue presented by the "consent.talpanetwork" domain, you should be auto-redirected to the main "www.kijk.nl" domain; of the cookies stored for that domain, you need to export (via CK addon) only 3 of them, 706b604c-184a-4235-899c-a744921ce65ccconsent 706b604c-184a-4235-899c-a744921ce65ccconsent (same cookie name, different value) CONSENTMGR Export saves them in a .json file, easily transferable between computers. Now, on your copy of NM27 (with CK installed), import the .json file (prior to navigating to "www.kijk.nl"); once successfully imported, load your Dutch media site and this time you won't be redirected to the (NM27 incompatible) consent page, the main site will immediately load: Addendum 1 If you don't have easy access to a second machine with New Moon 28 installed, I think my own .json file will work: { "method": 3, "cookies": [ { "isSecure": false, "value": "BOZwbEeOZwbEeADABANLAEAAAAAE54EfETAAQgAAHAA", "isSession": false, "isProtected": true, "expires": 1580146974, "path": "/", "name": "706b604c-184a-4235-899c-a744921ce65ccconsent", "host": ".kijk.nl", "isHttpOnly": false },{ "isSecure": false, "value": "BOZwbEeOZwbEeADABANLB_-AAAAjCAcAAiABUAC4AIAAZABEgCaAJ4AWwAxABuAD8AIAARgApQBXADvAIQARaAjgCOgEuAJ2AVkAuoBgQDiAHugP0A_YCCg", "isSession": false, "isProtected": true, "expires": 1580146974, "path": "/", "name": "706b604c-184a-4235-899c-a744921ce65ceuconsent", "host": ".kijk.nl", "isHttpOnly": false },{ "isSecure": false, "value": "ts:1546450972680|consent:true|c1:0", "isSession": false, "isProtected": true, "expires": 1547660574, "path": "/", "name": "CONSENTMGR", "host": ".kijk.nl", "isHttpOnly": false }], "date": 1546451392562, "storage": [] } Copy the code in a proper text editor and save it as "kijk-consent-cookies.json" ; then use that to import in CK. Addendum 2 Those 3 imported cookies are not session but permanent ones, they expire at a time indicated by their "expires" attribute (UNIX timestamp, roughly in 6 months' time); you can use CK's editing mode to extend that default expiry further...

Merry Christmas to you Your "interface language selection" on old.reddit.com is stored in the form of session browser cookies ; as their name suggests (and in accordance with your findings), they remain valid for the duration of a browser session; once the browser is exited, they auto-expire... If you want your selection to persist across browser sessions, you have to somehow turn the controlling cookie(s) from session to permanent ones... The above can be accomplished via developer tools, but it's a lot easier via the use of cookie-editing extensions... I personally use CookieKeeper 1.9.3.1 (on New Moon 28.3.0a1): this specific extension is capable of editing cookie properties as well as "protecting" cookies from browser deletion; in the screenshot that follows, I have indicated for you the session cookies (that store language selection) that need to be edited and "protected": Before: After: You can find and install CookieKeeper via Classic Add-ons Archive (I posted about it a few pages back), usage info for CK can be retrieved easily online...

@Tamris The version of Audacity that was patched by @FranceBB to run on XP belongs to the alpha development channel, as such it is only available in the default en-US localization ; exact version is 2.3.1a-git-20181022-g72fbf1b (reported as Audacity 2.3.1-alpha-Oct 22 2018 in the app's GUI), the download link for the ZIP package - for those on Vista+ - is at: https://www.fosshub.com/Audacity-devel-old.html => https://www.fosshub.com/Audacity-devel.html?dwl=audacity-2.3.1-alpha-72fbf1b.zip So there's no way to change the GUI's locale via Edit => Preferences => Interface => Display => Language Only options there are System/English ... Luckily for you, there have been only minimal string changes between the release channel version 2.3.0 and the alpha channel pre-release (patched for XP compatibility), so what you can do is 1. Download the official ZIP package for release version 2.3.0: https://www.fosshub.com/Audacity.html?dwl=audacity-win-2.3.0.zip 2. Extract from it the Languages directory; at this stage, you can optionally remove locales you are never to use in the future... 3. Place the Languages directory inside the same root folder where (patched) Audacity.exe is located. 4. Launch the app and now the option to change to a different (to default English) GUI language should be present; select as desired... 5. Restart the app for full localization: 6. Enjoy... BTW/FYI, release channel version 2.3.1 is scheduled for Dec 28th, 2018...

... I can confirm that the most current release (v7.6.1) continues to be Vista SP2 compatible: Notepad2-mod hasn't been updated in a long while; its github repo is marked as archived, last commit was pushed on Aug 15, 2017. So it is safe to assume that this project has become "abandonware", with the latest official release v4.2.25.998 becoming in essence the very last (final) one (still compatible with Windows XP SP3 + Vista SP2): As you say, NotePad3 does not officially support the Vista OS (and the new owners, Rizonesoft, also dropped WinXP support): However, the last stable release v4.18.512.992 apparently runs fine on Vista SP2: Most sadly, the rosey story ends up here ; during the autumn, the dev team moved on to a new compiler with revised compiler settings/kernel optimisations so that the new branch 5 released builds (currently in the Release Candidate dev stage) are not capable of being launched under Vista, due to missing API calls: So, version 4.18.512.992 should be marked as the last Vista compatible one ; obviously, the maintainers themselves have no intention of restoring Vista support to the app, but it is my gut belief - without, that is, browsing the code itself - that, again, we may have to deal with an artificial Vista block; the app is open source, so hopefully the code could be recompiled targeting again the Vista OS... Here's hoping...

... I am curious as to why it was not suggested in this thread already, but why was the solution of running WinXP (and MMJB on it) in a Virtual Machine (e.g. free VirtualBox) hosted in one of @Roffen's recent hardware+OS boxes not given a thought? Perhaps one of the savvy good-hearted people here could hand-guide him (e.g. via TeamViewer) to set up the VM with XP in it? Also, it would be interesting to know the exact version of the audio software concerned; Wikipedia has a nice entry on Musicmatch Jukebox ; it's stated that Version 10 builds can still be found in oldapps ; after that, the product was acquired by Yahoo! (versions 10.1+)...

It can be retrieved by installing the Classic Add-ons Archive XUL extension (mentioned previously in this thread, as I recall ): https://github.com/JustOff/ca-archive/#compatibility-and-installation After successful installation, open "caa:addon/empty-cache-button/versions" in a tab; you would need latest "Version 2.7.1-signed.1-signed"; download the .xpi file to disk (storage of the file kindly provided by the Waterfox project) and manually install to New Moon 28 / Serpent 52.9.0 (both on the UXP platform) by dragging the file onto "about:addons"; you will be asked to restart browser to complete the installation; just a usage tip: be sure to close the caa:addon/* tab prior to restarting, else it would take quite a lot of time for the browser to reload post restart... Yes, Version 3.4 (WE format) does install and function correctly in latest Serpent 55.0.0/moebius, but does not install/work in Serpent 52.9.0/UXP, because it requires WebExtension APIs not present in[/backported to] the UXP platform... PS: if you like the "metro" style of the icons used in this WE version 3.4 of "empty-cache-button" (which, as said, can't be installed in either NM/Bk52), I have taken the liberty of "patching" the XUL version 2.7 (linked-to above, GLGPLv3 lic ) so as to include the "metro" icons (instead of the default "3D" ones); ergo empty_cache_button-2.8-pm27-28.xpi

... There was a recent identical thread over at the Vista subforum: Read my detailed reply here... or TL;DR: 1. Use Basilisk52[Serpent 52.9.0] with a SSUAO for Discord to pretend you're using FirefoxESR 60 on Win7+, or 2. Use FirefoxESR 52.9.0 and change its default UAO for Discord, with the aid of extensions, to the one of FxESR 60 (on Win7+). New Moon (27 or 28) won't work at all, because of no support for WebRTC (used by Discord's voice chat feature).

... Spoken too soon, am afraid... Latest New Moon 27 win32 build [Version: 27.9.1a1 (32-bit) (2018-12-14), buildID=20181214153010, package filename: palemoon-27.9.1a1.win32-git-20181215-c581f09b3-xpmod.7z] on Windows Vista SP2 32-bit. 1. First bug: When the browser sidebar is open (displaying Bookmarks in my case), the site header is shrunk to include a "hamburger" menu button on the far right; clicking that button does nothing in the case of NM27 [FWIW, when the sidebar is closed, the site header displays OK]... Sidebar visible: Sidebar hidden: 2. Second bug: All images+thumbnails on the site are displayed as blurry: Page Info => Multimedia Tab reveals that, e.g., the Discourse Dark style preview is loaded from https://imageproxy.openusercss.org/50x/https://github.com/StylishThemes/Discourse-Dark/raw/master/images/Atom-after.png which is a tiny 50x35 pic... When loading https://openusercss.org in FirefoxESR 52, the site is being rendered correctly: ... and in that case the Discourse Dark style preview is loaded from https://imageproxy.openusercss.org/540x/https://github.com/StylishThemes/Discourse-Dark/raw/master/images/Atom-after.png which is a medium sized 540x373 pic... So it appears that NM27 is unable to load and display the proper resolution thumbnail/picture ... @roytam1, would you be so kind as to investigate those two bugs? Would it be possible to backport Mozilla code (from Fx versions > 38ESR ) to, hopefully, fix them? As ever, much obliged for your on-going support

... This is, of course, off-topic (as this concerns XP), but it appears on Vista that feature is ON by default: [Provided merely as a FYI for others reading - I'm not on XP (any more), but still following this thread ... ]

... Yes, I know This issue was first reported last July in the official PM forum; according to Moonchild himself: Broken userstyles.org on Tycho was another reason that expedited the release of (stable) PM28 on the UXP platform... Thank you both for your suggestions ; this improves considerably over what I have been doing thus far and may possibly also cure the userstyles' (auto-)updating issue... E.g. for https://userstyles.org/styles/31267/global-dark-style-changes-everything-to-dark the direct URI to the userstyle (via either suggestion) is found to be : https://userstyles.org/styles/31267/global-dark-style-changes-everything-to-dark.css Then I can install it in Stylem 2.2.4 via the "Install from URLs..." feature (so no need to copy the entire CSS code and "Write New Style" ). However, the main flaw of this procedure, as already pointed out by the both of you, is: meaning the need for a (second) browser, able to render correctly the site (which could then be browsed/searched normally for userstyles) isn't alleviated... I'm still hopeful that this specific PM27 bug will be properly addressed in due course... Thanks, I am well aware; site always visited with uB0 ON, some personal "cosmetic" filters also added (to negate their endless plug for the android version of their adware/spyware version of WE Stylish): ! https://userstyles.org/ userstyles.org##.overlay_background userstyles.org##.android_button_banner userstyles.org###top_android_button userstyles.org##.android_button_button userstyles.org##.head userstyles.org##.body userstyles.org##.footsteps userstyles.org##.shadow userstyles.org##.x_button ||userstyles.org/ui/images/icons/close-icon.svg$image ||userstyles.org/ui/images/280x294.png$image userstyles.org##div.us-stylecard--short:nth-of-type(3) userstyles.org##div.us-stylecard--short:nth-of-type(5) userstyles.org##div.us-stylecard--short:nth-of-type(12) userstyles.org##.navigation The thing is, Stylem (a fork of [XUL] Stylish 2.0.7 made by a member of the official PM community) hasn't been updated in a while and has little support for userstyle "portals" other than the original one (userstyles.org, supported in Stylish); even that support is currently lagging, as Stylem can't install correctly configurable styles (e.g. YouTube DeepDark Classic , with the "Customize Settings" button); that issue has been properly reported here, but the developer hasn't yet acknowledged it or come up with a fix Also, due to the shady practices of SimilarWeb, current owners of userstyles.org, many style authors are switching over to other infrastructures, e.g. OpenUser.CSS (loads fine in NM27, BTW), and a new "format" of userstyle called usercss (which is configurable post-install); Stylem has 0 support for these ; this new "usercss" type of userstyle and the new "OUCSS" repo are fully supported in the userstyle manager called Stylus , but this is a WebExtension, not installable in New Moon 27/28 (and only certain versions of it can be installed - with some manifest.json modifications - in Basilisk52/UXP). OT: Yes I know, another long-winded post I am afraid, but hopefully with info useful to the MSFN community

... With GitHub now fully functionable in New Moon 27, the only deal-breaker for me currently is Tycho's inability to load userstyles.org , hence I am unable to install user styles from there with Stylem 2.2.4; if that were to be remedied , it would be a tremendous enhancement! FWIW, the workaround I have to currently apply is 1) first install the user style in one of the UXP browsers (or FxESR 52.9.0/Serpent 55.0.0), 2) copy its full CSS code and 3) manually install it [via "Write new style"] in NM27; some of these "locally" installed styles don't receive future updates (so the process above has to be repeated when an updated style has been released) ...

More info here: https://github.com/mtrojnar/stunnel/blob/master/INSTALL.W32 ... and I found some kind of a Russian fork, stunnel-msspi, but of the v5.50 32-bit released binaries : stunnel-5.50-msspi-0.135_windows-386.zip only the CLI (stunnel-msspi-cli.exe) would run in my Vista laptop, whereas the GUI (stunnel-msspi.exe) probably requires Win7+ (the EXE makes API call to K32getModuleFileNameExA not to be located in Vista's kernel32.dll ) ...

... Perhaps you inadvertently selected (Ctrl+I) the Italics font in the post's editor? (bolded capital I, next to bolded capital B, top left in the editor's "ribbon"?

Found it: Update application startup with proper error messages. (28 Jul 2015) Reverted 6 months later in Remove POSReady sanity check. (28 Jan 2016) ... with a more transparent commit title...

That's pretty much what I hinted about, thanks dencorso ; if the original code he forked contained, by default, parts that would enable it to compile and run on XP/Vista, he would meticulously excise those parts to make sure his fork is not compatible with said (older) OSes; you said he considers those parts as bloat (which can be indeed the case, but who really knows what's inside that person's head? ), I merely emphasised the result of him removing that "bloat": Another aspect which isn't clear in my previous comment is build-time-compiler-optimizations: targeting strictly Win7+ kernel when building his forked code, so that the officially released binaries be non-executable on XP/Vista... Moonchild et co. have a precedent on that: When they were releasing (between Nov 2017 and Mar 2018) official binaries of Basilisk 55 (on their now deprecated moebius platform), compiler opts were such that a simple lowering of the subsystem version string (from 6.1 to 6.0) in the EXE's headers would enable the Basilisk.exe binary to run on Vista (with only few flaws, namely disabled WMF features...). When apps (Basilisk 52 and Pale Moon 28) on the UXP platform started being officially released, the binaries were built under revised compiler optimisations; previous "hack" wouldn't now work, because at least 8 (new) API function calls were introduced in various app DLLs/EXEs that are not present inside Vista's versions of important system DLLs (kernel32.dll, user32.dll, psapi.dll etc)... If you ask me, that was not a coincidence As for adding code to their tree that is knowingly WinXP incompatible, the Moonchild team has already done that by switching over their ffvpx library to using FFmpeg 4.0+ source; to be fair though, it's safe to assume they didn't do it out of spite for eventual XP users on forks; they simply just don't support XP or Vista, so these OSes have been totally left out from any coding considerations on their part...

@mockingbird Thanks , but it was already posted by roytam1 himself, last Saturday I believe :

It would appear that the image hosting service (prntscr.com) doesn't like my current IP address issued by my ISP, or my ISP's IP pool in general ; by running my UK VPN service (which gives me a virtual UK IP address), I can access the screengrab URI directly and, as expected, the image shows up as embedded in the mentioned thread post... Go figure!