VistaLover

Hi Roy Your efforts to breathe new life into the Moebius repo, deprecated by its maintainers since Mar 18th 2018, are highly appreciated and praiseworthy ; I understand it is a very tedious and time-consuming task to port-over security fixes from Mozilla... Although always a consideration, I'm not that paranoid about browser security as I am about browser features and continued functionality (acknowledging, as you state, Bk55/Moebius being "experimental" software ). I was one of the people to highly praise Basilisk(55)/Moebius during the time it was actively maintained by Moonchild, of course through your Vista compatible forks/builds, especially in comparison to the early releases of Basilisk(52) /UXP-T2, which then presented many issues; Bk55, on Vista at least, was/is more "fluid", had/has a better rendering engine and richer webextension APIs and its native theme has better integration with Vista's Aero. But then MC dumped Moebius, because it was no longer serving their original needs, and focused developing on Bk52/UXP; so I ultimately had myself to revert to your Serpent 52.9.0 builds (and accept its various shortcomings on Vista), if I was to use an actively maintained browser where existing bugs had some chance of a fix by MC... But I have kept a (portable) installation of Basilisk (now Serpent) 55 for tests; further down in this post I'm going to talk about my "adventures" with using your latest Serpent 55.0.0 offerings... (Web)Notifications bug: This was first reported by our Polish friend @kitaro1 in a now lost post; it was quite annoying especially because it used to affect this MSFN forum, too! The browser wouldn't save between sessions (browser restarts) notification exceptions (sites allowed to display webnotifications) and every time one logged in, one had to (re-)allow notifications for msfn.org (and, of course, other sites with the notification feature). FWIW, this bug was not present in the last official build of Bk55, Basilisk-55.0.2018.03.21-git-20180321-g6afc1c7.en-US.win32[buildID=20180321093734]. I had carried out regression tests (but sadly I never posted those) and determined that the bug was first introduced by you in Basilisk-55.0.0-git-20180308-g3da3c97-xpmod.en-US.win32[buildID=20180306151332] by updating NSPR to 4.18 and NSS, first to 3.35 and then to 3.36; in the profile, cert8.db changed to cert9.db and key3.db to key4.db. That bug was finally rectified with Basilisk-55.0.0-roytam1-git-20180616-gde24cec.en-US.win32[buildID=20180616141358], with the update of NSS to 3.36.4; cert9.db and key4.db reverted to cert8.db and key3.db again... But that fix came with a small price: I am not using a third party password manager, after the update from buildID=20180413153516 to buildID=20180306151332 I just found out all my stored login accounts (for ca. 15 sites) in about:preferences#security could not be read/recovered and I had to manually re-input them ; so, for those wishing to update from Basilisk-55.0.0-roytam1-git-20180413-gee7cd5f.en-US.win32[buildID=20180413153516] to a more recent build of Bk55, take care to first export/back up your saved login credentials! Extensions installed from AMO won't pick-up available updates/won't auto-update (according to your settings) This specific issue was recently reported in this thread by new member @ED_Sln I believe the real reason behind this bug is the one mentioned here: https://forum.palemoon.org/viewtopic.php?f=61&t=19273 Mozilla on AMO have switched to providing extension update manifests exclusively in JSON format, killing the XML format used in Basilik55; the MC team mitigated this change in the UXP repo (hence Serpent 52.9.0); owing to a similar root cause, current Bk55 (as offered by Roy) can't update other extensions not installed from AMO, but whose update manifests also come in the form of .json; one such example I am aware of is the GitHub hosted beta/RC versions of gorhill's uBlock Origin : https://github.com/gorhill/uBlock/releases whose update manifest URI is: https://raw.githubusercontent.com/gorhill/uBlock/master/dist/firefox/updates.json E.g. on Serpent 52.9.0, 1.16.11rc1 will update to 1.16.11rc2, but NOT on Basilisk 55.0.0 (has to be installed manually from Github). To fix this bug on Bk55, you'll have to back port code from the UXP repo! EME and Widevine CDM support on Vista OS This was already brought up by me here previously, sadly those posts have permanently vanished due to site's server crash/database corruption TL;DR: Yes, your Bk55 builds are compiled with the --enable-eme=widevine flag and while widevine on Windows XP is a lost cause (again, there was discussion/explanation in this thread that is now lost), on Vista the plugin does appear as loaded and enabled (v1.4.8.903) inside AOM (about:addons); FWIW, extensive tests by yours truly have shown that Serpent55+WV works as expected in WinOSes >=7, but not on Vista Explanation: Actually, neither MC team nor you are to blame for this! Widevine is a closed source plugin; from my many tests and online searching I have concluded that WV on a Mozilla type browser only searches for h264/aac decoders among the system codecs and implies a working WMF implementation in the browser; BK55 doesn't support Vista's WMF+WV, because that support was already removed by Mozilla in the source (53.0a1?) MC originally forked; MC didn't plan on their test bed browser working on Vista, so never bothered to reinstate Vista's broken WMF support (not the story with Basilisk52: in that case, Vista WMF+WV support was present in the forked source, MC team selectively removed it and you (Roy) reinstated it ; hence, Serpent 52.9.0 + WV works OK in Vista! ). Visiting https://bitmovin.com/demos/drm with Basilisk-55.0.0-roytam1-git-20180623-g0249f58.en-US.win32[buildID=20180623000710] on Vista I get: avc1 (h264) decoding support is achieved via your patched ffvpx lib, not by WMF; thus widevine (and other EME) are not supported! Similar results are produced when one visits https://demo.castlabs.com/ @roytam1 you'd have to install a Vista VM (fully updated with all Service Packs and Platform Update Supplements!) to reproduce; if your kind heart wishes to fix this, you'd have to bring back WMF on Vista; you can start by looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1324183 https://bugzilla.mozilla.org/show_bug.cgi?id=1329547 and possibly others... Non-working userstyles I have an eye condition and I can't stand bright colours for long, plus I tend to be on-line more during the night (yes, bad for my sleep patterns ); as such, on all of my browsers I install Stylish (or similar) and a group of "dark" userstyles to have a darker web experience! When I updated my previous Bk55 installation (Basilisk-55.0.0-roytam1-git-20180616-gde24cec.en-US.win32[buildID=20180616141358]) to the latest compile (Basilisk-55.0.0-roytam1-git-20180623-g0249f58.en-US.win32[buildID=20180623000710]), I was unpleasantly surprised to find that more than half of my installed userstyles quit working (while the rest remained functional!); my Stylish version is 2.1.1, the last (hybrid-)XUL version that still has access to the browser GUI (as I also use a number of userstyles to accommodate the GUI to my liking!). A brief list of userstyles that stopped working after the latest update is Addons Mozilla Firefox 2017 Dark Theme bing nightly Bitbucket Org Dark Dark style for (ftp|archive).mozilla.org Darker Facebook Darker IMDb DarkSearch for Google DuckDuckGo DeepDark GitHub Dark Userstyles DeepDark Website: cleaner - Mozillazine.org Forums YouTube DeepDark Material YouTube DeepDark Classic Findbar on Top Right (modifies Browser GUI) Some of them can be found on-line, others I have picked-up from various sources I now have no recollection of; it is noteworthy that while all but one are "dark" styles affecting the look of webpages, I have at least one that modifies the browser GUI itself (Findbar on Top Right) which is now broken... For the record, I have one "dark" userstyle, "Wikipedia - Dark, blue, simple", that is not broken and still works! To make matters worse, it looks as though the style hosting site https://userstyles.org is broken; when I visit, e.g. https://userstyles.org/styles/118959/darksearch-for-google and have that style installed, there's no indication on the site the style is indeed installed (or am I confusing this with greasyfork.org? ); in any case, don't hit that deceptive button "Install with Stylish"; you'll end up with the latest webextension version of Stylish that will mess things up for you... The relevant changelog is https://github.com/roytam1/basilisk55/compare/de24cec...0249f58 I hope something responsible for the userstyle breakage stands out for you... This new bug is a deal-breaker for me and I have switched back to Serpent 55.0.0 (2018-06-16) I hope you'll appreciate the detailed bug-report, my gratitude for your hard work remains unscathed regardless Best wishes to Hong Kong

Thanks a mil for your patch and compiled executable If you had been following my previous posts (most of them now gone with the server crash ), you'd have known I am a fan of portable apps/installations; well, if one renames your Rufus executable so it ends in "*p.exe", it just turns itself into portable mode and saves its settings in an adjacent .ini file! Works like a charm on Vista SP2 x86 All in all, a sterling job for the Vista community

Yes, I downloaded latest "portable" executable, rufus-3.1p.exe, on my Vista SP2 x86 laptop; the EXE is UPXed, so I had to first decompress it to a 2.57 MiB file... Inspection with Dependency Walker reveals it calls two API functions in kernel32.dll that are missing in Vista's version (6.0.6002.24170) of that system file :

... OK, I finally caved in and installed the 30-day trial of Internet Download Manager (IDM) on my Vista machine, just to perform some tests... Latest version of the app is 6.31build1; the 3 available browser integration extensions are : idmmzcc.xpi => This is a legacy extension, current version is 7.3.110, its install.rdf mentions Firefox versions 1.5 - 26.0 and Pale Moon versions 3 -25 idmmzcc2.xpi => Legacy extension, current version is 6.27.7; install.rdf file mentions Firefox versions 27.0 - 52.x, but does not specify any Pale Moon versions; however, its chrome.manifest file has line overlay chrome://browser/content/browser.xul chrome://idm-mozilla_cc/content/overlay.xul application={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4} that application ID is for Pale Moon. idmmzcc3.xpi => Webextension format, current version is 6.31; manifest.json indicates strict_min_version": "53.0a1" (Firefox 53.0+) . I then tested those extensions with several of the "roytam1" browser forks... 1. New Moon 27.9.1a1 (fork/rebrand of PaleMoon_unstable 27.9.1a1) (32-bit), buildID=20180615115719 v7.3.110 can be installed via the Moon Tester Tool 1.1.6 palemoon extension, the installation is successful with IDM context menu entries being correctly populated, but the extension does not communicate with main IDM app, hence integration fails v6.27.7 installs successfully on its own (without MTT) and results in a fully working browser integration with New Moon (as it was reported...) 2. New Moon 28.0.0a4 (fork/rebrand of PaleMoon_unstable 28.0.0a4) (32-bit), buildID=20180615233117 v7.3.110 can be installed via the Moon Tester Tool 1.1.6 palemoon extension, the installation is successful with IDM context menu entries being correctly populated, but the extension does not communicate with main IDM app, hence integration fails v6.27.7 is itself incompatible with NM28, but can be forcibly installed via MTT; sadly, as reported already, the installation is successful, with IDM context menu entries being correctly populated, but the extension does not communicate with main IDM app, hence integration fails At this stage, I can't tell whether the blame is to be put on the extension or the (alpha state) browser... Perhaps it should be worthwhile to report it to the Moonchild devs (but say you tried it on official PM28) and emphasize IDM integration works with PM27... 3. Serpent 52.9.0 (fork/rebrand of current Basilisk/UXP-T2) (2018-06-18) (32-bit), buildID=20180618002732 v7.3.110 is incompatible with the browser and can't be installed! v6.27.7 is compatible and installs successfully; results in a fully working browser integration v6.31 (WE) is incompatible with the browser and can't be installed! 4. Serpent 55.0.0 (fork/rebrand of deprecated Basilisk/UXP-T1, aka Moebius) (2018-06-16) (32-bit), buildID=20180616141358 v7.3.110 and v6.27.7 (legacy XUL format) are both incompatible and won't install! However, v6.31 (webextension format) is compatible and installs successfully; results in a fully working browser integration There you go, if you are a paying customer of IDM, I have listed your working browser options as far as IDM integration is concerned... Serpent 52.9.0, built on the same platform as New Moon 28, has similar (dare I say better) rendering engine to NM28, so your "site" is bound to also load fine on Serpent 52.9.0 (probably on Serpent 55.0.0, too) ... With the Serpent forks, you get IDM integration as an added bonus...

... On my Vista laptop, I have kept a portable installation of Firefox ESR 24.8.1 (32-bit) (which is more secure than Firefox Release 25.0) with the following extension https://addons.mozilla.org/el/firefox/addon/preserve-download-modification/ installed, just for the same reasons as you... That particular Firefox version (also the last with a working toolkit download manager, "browser.download.useToolkitUI;true"), especially during the course of the last six months, has been failing to render properly many sites (e.g. github) and connect to several HTTPS sites, because of missing Cipher Suites (TLS 1.2 pref'ed on...); but it still works (with the addon) for that one particular site I download files from and want to be able to tell when they were first uploaded on their server...

... not "may" ; Pale Moon 28 (currently at version 28.0.0a4) is built on the UXP platform, which by design does not support NT < 6.1 (i.e. minimum OS version required is Win7); as such, official Pale Moon 28 builds don't/won't run on Vista; the official Pale Moon unstable channel has switched, for some weeks now, to v28, incompatible with Vista... For historical purposes, the last Pale Moon unstable build to run on Vista was PaleMoon_unstable-27.9.1a1-git-20180503-g57f668c.en-US.win32, buildID=20180503064227 (I have kept a zipped copy...) If you are an unstable-channel user on VIsta, you are cautioned not to update any further (the update server doesn't check your current OS, so you'll end up with a non-running 28.0.0a4 update), but you are advised to switch to the stable channel, currently at v27.9.3; this will continue to receive mostly security (plus selected performance) updates for some more weeks, though a definite EOL date hasn't been yet announced... Vista users can try the New Moon (fork/rebrand) 28.0.0a4 builds by roytam1, to be found in the eponymous Windows XP forum thread...

@MaterSystem wrote: > idmmzcc2.xpi (pack .zip) no version compatible with New Moon 28 ... Have you actually tried the link I pointed you at? https://getidmcc.com/#howto This is a legacy (XUL) addon that should install in PM28, it has installed without issues on NM 27.9.1a1 (32-bit) [buildID=20180615115719]; but I don't have actual IDM installed on this machine , so can't verify the extension works as intended... > Hope in the near future, new version idmccz2 are compatible with New Moon 28 > Or alternative solution for "idmcc" on New Moon 28 As I see it, IDM being a proprietary payware, they are/will be only developing/supporting extensions for just the few big browser brands, namely current versions of Google Chrome, Mozilla Firefox (Quantum) and Edge/IE; none of these currently supports the legacy XUL extension model supported by Pale Moon 27/28; and I think, once Fx ESR 52.9.x goes EOL in a few months, even the legacy IDMcc extension will be removed from the page linked... So, don't hold your breath for an official solution covering New Moon 28... > I do not use Basilisk but want to use New Moon (Pale Moon) ... I understand, but the gist of your post was about a working implementation of IDMcc in a modern browser supported by your Windows XP OS; both Basilisk52 and PaleMoon28 are built on the same platform (UXP), however Basilisk has some support (Bk55 > Bk 52.9.0) for webextensions, whereas Palemoon will never have; hence my suggestion to try the WE version of IDMcc on Bk55... If your hardware (CPU+RAM) supports it, I urge you to try latest Bk 52.9.0 instead of NM28; it's more feature-rich and more mature, while PM 28.0.0.0a4 is, in its developers' words, still in alpha state... Best regards

Hi I'm not an IDM user/customer; however, a bit of searching has led me to: https://getidmcc.com/ The green button labelled "Install for Firefox 52 and older" links to an XUL extension, IDM integration v6.27.3; on the site it says "Compatible with Firefox versions 49, 50, 51 and 52", but the install.rdf file says minVersion 27.0a1 maxVersion 52.* You can try installing that on latest New Moon 28.0.0.0a4, provided by Roy ; if it doesn't properly work, then you'll have better chance installing and trying it on latest Basilisk (Serpent) 52.9.0/UXP. The Webextension version of the extension, green button "Install for Firefox 53 and newer" => IDM Integration Module v6.30.9.1, requires Fx 53.0a1+, so it might work on latest Basilisk (Serpent) 55.0.0/Moebius (which is a reforked Fx 53.0+ under the hood...); however, that browser has been deprecated by its developers and builds kindly offered by Roy, in an infrequent fashion, are mainly used for third-library tests... Hope I've helped... Note to site admins: The Forum Software wouldn't let me post/edit, if I included the install.rdf file extract inside XML code tags ; possibly related to yesterday's outage?

@dencorso and @heinoganda Please read: https://support.globalsign.com/customer/portal/articles/2169296-windows-code-signing-hash-algorithm-support XP SP3 and Vista SP2 can't validate file digital signatures (code signing certificates) with SHA256 file digest (i.e. hash algorithm) ; Win7 SP1 upwards can! Other useful reads: https://blogs.technet.microsoft.com/pki/2010/09/30/sha2-and-windows/ https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility

Another one bites the dust ; sadly, this is not a song reference https://gitlab.com/mbunkus/mkvtoolnix/issues/2201 Commiserations (I use mkvtoolnix extensively for media file manipulations...)

Search engines are your friends, you know ... https://en.wikipedia.org/wiki/Server_Name_Indication

Some interesting articles people here should read: https://github.com/client9/sslassert/wiki/IE-Supported-Cipher-Suites https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/ https://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx for XP: https://msdn.microsoft.com/en-us/library/windows/desktop/aa380512(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa380124(v=vs.85).aspx (though SSL2/3 should be disabled due to deprecation/vulnerabilities...) In addition to ECC & SNI missing in XP, that others have already mentioned in this thread, recent cipher suites used in TLS 1.1+ are also missing... That site uses TLS 1.2, TLS_RSA_WITH_AES_256_CBC_SHA256 (suite unavailable in XP); it does open fine in Vista's IE9 with the addition of TLS 1.2 support; likewise, the following site https://mpv.srsfckn.biz/ won't open even in IE9 on Vista, because, in addition to TLS 1.2 and SNI (which IE9 on Vista does support), it requires any of the following missing suites: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) (source: Qualys SSL Labs - SSL Server Test) OTOH, @dencorso posted here that they do for him: I don't have XP to test, but have you deleted the "OSVersion" subkeys in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.1 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2 ? What would be indeed awesome is for someone to devise a way to add to the system (schannel) missing cipher suites...

Running the latest 32-bit compile from roytam1 (v55.0.0, buildID 20180113120315, git-0257d77) on Windows Vista SP2 32-bit (fully patched), I'm not seeing the issue reported by r3muxd; and this is with no less than 42 active addons (5 of which are webextensions), a custom Greek language pack and a custom mod of the FT DeepDark complete theme (based on version 14.4); I have not experienced any crash whatsoever since installing it yesterday; I know this is little consolation for r3muxd, but may indicate it's an issue particular to his setup... Also, the Moebius devs are recently streamlining the codebase and since they're officially only supporting Win7+, they have begun gutting out all remnants of NT<6.1 - I've seen GUI files renamed to *-win7* and/or *-preWin10* etc., which just means it'd be even harder in the future to maintain compatibility with XP/Vista in roytam1's builds @r3muxd you need to troubleshoot this further; does your issue happen when launching Bk in Safe Mode? Are you indeed on XP SP3 32-bit? (I can't check the behaviour of Bk on that OS currently...). Have you tried to disable Hardware Acceleration? Have you, by any chance, enabled multiprocesses (e10s) ? If yes, revert to single process... Does your issue happen in a new clean profile? Do note Basilisk is a test application in alpha state, radical internal changes take place with each update, little compatibility exists currently with Firefox (<= 55) profiles... When "basilisk.exe" crashes, do you get any additional info on which part of the app provokes the crash? As stated, the official builds don't run on Vista, by choice ; another thing is their releases are few and far between... The last one is 55.0.2018.01.05 (buildID 20180105004734); I have patched all official executables (by lowering subsystem version from 6.1 -> 6.0) and have successfully run the official win32 build on Vista; runs absolutely fine on my system (no issue with typing in the URLbar), except for the fact WMF h.264/aac decoders don't work; this is because the WMF code in the official build selectively excludes VIsta (and, of course, there's no WMF decoders for XP). (official builds only, on supported OSes =>) Official Basilisk forum: https://forum.palemoon.org/viewforum.php?f=61 GitHub issue tracker: https://github.com/MoonchildProductions/moebius/issues

@AstroSkipper @roytam1 is providing a tremendous service to the XP community with his xpmod builds of PaleMoon 27.7.0a2 (which, for legal reasons, have to be rebranded to NewMoon); actually, the Vista community too owes a lot to him for his xpmod builds of Basilisk (officially supported only on Win7+); when PaleMoon (28.x.x ?) is ported over to the Moebius platform (that Basilisk is built upon) sometime during this year, I assume PaleMoon will drop official Vista support at that time, since that platform officially supports Win7+; so I, a Vista fanatic, will be also relying on his xp-vista-mod PaleMoon builds... roytam1 is compiling his builds off code from the unstable PaleMoon channel, IOW from the master branch of the github development repository at https://github.com/MoonchildProductions/Pale-Moon/commits/master . His patches don't touch the GUI strings at all, so if your installed LP fails, it's nothing to do with his modifications... You shouldn't expect him to be also responsible for providing compatible and always up-to-date language packs each time he's releasing a new compile of NewMoon; even Moonchild Productions don't offer LPs for their "unstable" channel (PaleMoon 27.7.0a2). If you absolutely must use a PaleMoon xpmod on your native tongue, then I suggest you switch to the other option available from Feodor2; he's building on the release channel of PaleMoon, for which official LPs do exist... If you (and others) like to stick with roytam1's builds, then 1. The point of reference for language packs is JustOff's repo at https://github.com/JustOff/pale-moon-localization/releases (and I have posted about it several pages back in this thread). This repo is only updated from time-to-time, as need arises/if deemed necessary by the dev (and depending on the work committed by the respective LP contributors...). If after a NewMoon (manual) update (with a LP installed) you find that: 1. You can't start/load/access the main GUI (infrequent but plausible), then start NewMoon in Safe Mode and disable/uninstall your LP; restarting, you'll end up in the working default en-US locale... 2. If the browser starts OK but parts of the GUI turn out broken, then, and depending on the part broken, do as advised in case #1 (if only unimportant parts are broken, I can easily live with that for some days...). When your localised browser GUI breaks, this means upstream changes have taken place in the default en-US locale with the new update, changes which, of course, are not reflected in your installed (rendered outdated) LP... If you're not savvy enough, then the only thing you can do is stay with the default en-US locale and revisit JustOff's repo often, in the hope an updated LP is posted; no use in pestering roytam1 about the (temporary) breakage... E.g., the issue reported by @AstroSkipper is now rectified by installing updated LP 27.7.0_RC6 ; people, patience is really a virtue! Addendum For those impatient that are not faint at heart but are a tad on the savvy side, there's always the possibility to update yourself your failing LP; you need: 1. Your (outdated) language pack downloaded on disk; it's an xpi (renamed zip) file. 2. 7-zip (installed / portable) 3. A proper text editor (not notepad|wordpad; I use PSPad, though I understand Notepad++ is very popular) 4. Very basic knowledge of GitHub and git version control. 5. Some familiarization with the internal structure of Mozilla browsers' language packs. Latest roytam1's NewMoon build is based on commit git-d74da28, while his immediate previous one was built off commit git-40aa3cc ; the changelog during the update can be viewed in the following GitHub URL: https://github.com/MoonchildProductions/Pale-Moon/compare/40aa3cc...d74da28 (it's the list he posted here) 23 commits were pushed; now change focus to the "Files changed 41" tab and search for changed files with " browser/locales/en-US/" in their path: browser/locales/en-US/chrome/browser/aboutHome.dtd browser/locales/en-US/chrome/browser/baseMenuOverlay.dtd browser/locales/en-US/chrome/browser/browser.dtd browser/locales/en-US/chrome/browser/browser.properties browser/locales/en-US/chrome/browser/migration/migration.dtd browser/locales/en-US/chrome/browser/preferences/preferences.dtd browser/locales/en-US/chrome/browser/preferences/security.dtd browser/locales/en-US/chrome/overrides/settingsChange.dtd By clicking on those links you'll see the changes committed on each file (which are responsible for the breakage of your installed LP). E.g. the "Security" (Sicherheit) tab in the Preferences window broke in the LP v27.7.0_RC5 because file "preferences/security.dtd" was changed as seen here: <!ENTITY passwordExceptions.accesskey "x"> +<!ENTITY autofillPasswords.label "Automatically fill in log-in details"> +<!ENTITY autofillPasswords.accesskey "A"> + <!ENTITY useMasterPassword.label "Use a master password"> <!ENTITY useMasterPassword.accesskey "U"> i.e. three new lines were inserted into previous code. You have to unpack your local copy of de.xpi v27.7.0_RC5 with 7-zip, locate inside all those locale files (8) that were changed according to the github URL (and the list I posted) and patch each one of them manually with your editor (according to the online diffs for them); then you have to translate any new en-US strings to your language, German in this case; double and triple check you have done everything as it should be done, save your changes and repack your edited LP into an .xpi file; finally, install to NewMoon via drag-n-drop, restart and you should be good to go; takes time, yes; but you then begin to appreciate all the labour spent by translators (though, to be fair, they have automated tools for their job and only rarely things have to be done in a harder manual fashion...). @roytam1 May I voice a personal request: Could you create a special, dedicated thread for your xpmod of the Basilisk web browser (which is currently only a test-bed for the Moebius platform, but may survive as an application even after PM is ported to the new platform)? This thread has sort-of become a mixed bag now, actually three distinct browsers are currently being featured/discussed, I feel it'd be better for everyone following this thread if three separate new ones are created, each one with a single browser (New Moon = Pale Moon XP / Nightly = Basilisk XP / KM-Goanna) as subject; a moderator could hopefully transfer older posts to the correct new respective thread... Thanks a million for all that you do for older (but not necessarily inferior) Windows OSes !

Hi - Facebook has phased out the use of the Adobe Flash NPAPI plugin months ago; to view FB vids you need a HTML5/MSE capable browser; please refer to post #1 of this thread and review the section "Q: Can't play H264 clips?" Please also make sure that you have enabled "MSE" and "MSE for MP4 video" inside New Moon's Options/Content/Video... Default language for New Moon 27.6.0a1 is en-US; head over to localization releases, you should pick your corresponding language pack (it?) from the latest release 27.6.0_RC2; just click "it.xpi" and allow the installation to take place; then open about:config?filter=useragent.locale in a tab and modify the value from "en-US" to "it"; finally, restart NM and once it loads the GUI should be in Italian!

I am sorry to report that yet another application moves out of Vista support mpv is a CLI media player, a recent fork of MPlayer (itself a fork of mplayer2); while it is mostly known/used on non-Windows OSes, it does support Windows too codewise and win32/win64 executables (mpv.exe) can be compiled via, e.g., MSYS2 native Windows compiler (but, sadly, MSYS2 now requires Win7+ and preferably the x64 architecture ). Power Windows users may be already familiar with mpv when using it with other CLI applications like the stream-downloaders livestreamer (now defunct), its maintained fork streamlink and youtube-dl; but perhaps others may know mpv as the media engine driving the front-end SMPlayer (this can also use the original MPlayer under the hood, but from experience has worse performance compared to using mpv). The mpv devs have made it clear from the start of the fork (ca. 2012) that they'll be dropping support for very old systems... Windows XP was accidentally dropped in November 2015, but then the devs decided to do nothing to restore its support. Most unfortunately, we're now seeing a repeat of that with regards to Windows Vista; you can read about it in this GitHub issue . Though the breakage was indeed unintentional, there'll be no effort spent by the devs towards restoring Vista support As you'd expect in such cases, the same ol' "Microsoft’s extended support has ended" mantra was recited but, in all fairness, the dev did acknowledge that as The justification of "Vista not registering in my download statistics: https://mpv.srsfckn.biz/stats.html" I found quite lame, TBH; what it all comes down to is While he obviously could, the main dev providing the Windows executables said The only options offered by the devs to Vista users (cross compile in a Linux VM or install Linux in the Vista machine and dual-boot) are far from realistic for most Vista users on old-ish hardware, not to mention the huge learning curve required to master Linux at first and the cross-compiler itself after that... So, on the Windows builds page the very last Vista compatible binary is the one marked as 2017-04-23, which is in fact mpv-v0.25.0: https://mpv.srsfckn.biz/mpv-i686-20170423.7z https://mpv.srsfckn.biz/mpv-x86_64-20170423.7z versions 0.26+ will simply not run on Vista; to be exact, this is only valid for the pre-compiled binaries offered by the main dev in his repo; in theory, code newer than v0.25 could be compiled with modifications to the crypto lib used so as to restore Vista support; I, for one, don't possess neither the hardware nor the know-how to even attempt such a task...

FYI, latest language pack (27.6.0_RC1) released by JustOff also targets unstable builds 27.6.0a1 natively, so no longer the need to manually hack the install.rdf file of the pack

... Just go to Pale Moon localization and save to disk latest language pack v27.5.0_RC8 that suits you (this is an .xpi file, i.e. a .zip file); modify the install.rdf file inside it (e.g. with 7-zip) and change maxVersion from 27.5.* to 27.6.* ; save your changes and then install modified language pack in PM 27.6.0a1 (install from file in the add-ons manager or simply by drag-n-drop in a tab). This is how I got the Greek locale myself on PM unstable in the screenshot posted previously So, you can easily enjoy PM 27.6.0a1 in German, if you so wish! PS: After installing the LP, you'd have to go in about:config, filter general.useragent.locale and modify the default en-US to the language of choice, e.g. de; restart PM for the change to take effect; tada!

Congratulations @roytam1 That was it! Your xpmod now loads successfully on this old Vista laptop: And with your "portable" LAV Filters DLLs, MSE+H.264 works too (without the need to install system-wide)! I think my old (2007) Intel CPU (Core2 Duo T5250 @ 1.50GHz) can only go as far as SSSE3... Will better check tomorrow how your build compares to the "official" one on Vista SP2 x86 - and of course you're a true gem for people still on XP... Cheers!

Hello @roytam1 I was reading your posts in the Pale Moon forums (not a member there, just a frequent lurker) and decided to come and follow you here, too I am currently using the official unstable (x86) Pale Moon builds (latest is 27.6.0a1 buildID 20171001090158) on my Vista SP2 32bit laptop and out of pure academic curiosity I wanted to check whether your latest xpmod would actually run on Vista, too... However, as others have stated, it will refuse to load a GUI (though there's a palemoon.exe process running in Task Manager at ~ 29MB of memory) and Windows informs of a crash: Problem signature: Problem Event Name: APPCRASH Application Name: palemoon.exe Application Version: 27.6.0.6483 Application Timestamp: 59d1184b Fault Module Name: mozglue.dll Fault Module Version: 27.6.0.6483 Fault Module Timestamp: 59d1183f Exception Code: c000001d Exception Offset: 000034c5 OS Version: 6.0.6002.2.2.0.768.3 Locale ID: 1032 Additional Information 1: 98b2 Additional Information 2: e55896255cd32d51a93c767d394c7c40 Additional Information 3: 4946 Additional Information 4: 85d6476da8052e18313817c31a393122 I can confirm (though I suppose it's irrelevant in this XP-targeted thread) that Feodor2's 27.5.0 x86 compile will load and run fine on Vista (but MSE+h.264 doesn't work - I haven't installed LAV Filters system wide to check, either...). Keep trying and thanks for your efforts

Source: Description of Software Update Services and Windows Server Update Services changes in content for 2017 Thursday, August 17, 2017 New non-security content: Update for .NET Framework 4.6, 4.6.1 on Windows Server 2008 SP2 (KB4038923) Support link: KB4038923 , catalog link: KB4038923 Prerequisites: 1. .NET Framework 4.6/4.6.1 2. D3D Compiler Update for WS2008 SP2 (KB4019478) (Should be already installed since July 2017) Note: Installed without issues on this fully patched (Vista EOL + WS2008 updates) Vista Home Premium 32bit laptop. Next regular Patch Tuesday is following Tuesday, September 12th, 2017.

Nice find . It was file Windows6.0-KB4034786-x86.msu, Microsoft Knowledge Base Article for that was on this link, which now returns a 404 type error (Try searching for what you need - This page doesn’t exist.). And it's nowhere to be found on catalog either ... Who knows what... (Un)fortunately, I never jump to install MS updates the first day they become available (for fear they have screwed up things... ), I patched my system on the 11th, i.e. after KB4034786 pulled a disappearing act...

There has been some discussion recently over at the BleepingComputer.com Forum's similar thread about the prerequisite update KB4019478. My personal findings are: 1. When KB4024848 was first released in July, it was included in the .NET FW update bundle labelled as KB4032116 ; when one accesses the catalog link, its prerequisite KB4019478 (x86 flavour) is offered as file "windows6.0-kb4019478-x86_246d86dae3b75ce3ee0180a18db1f04992a14c1b.msu". That file has a size of 1.434.955 bytes and a digital signature of "Thu Apr 13 2017 19:47:38 UTC". This is the file I installed myself... 2. When KB4033990 was released this August (that replaces KB4024848), it was part of the .NET FW update bundle labelled as KB4035039 ; when you go to that catalog link, the prerequisite is again (?) included and labelled as KB4019478, but the x86 flavour is now downloaded as file "windows6.0-kb4019478-x86-custom_83098465b9ee0b4b39e02fa8f6853fe196966a26.msu". That August file has a size of 1.435.558 bytes (slightly bigger) and a digital signature of "Thu Apr 13 2017 10:53:14 UTC", which means the August file (updated one?) has a dig sig almost 9 hours prior to (i.e. it's older than) the previous July file for KB4019478 I don't know what to make of the above . Obviously, these are different files for the same "D3D Compiler Update for WS2008 SP2", which is, no doubt, related to this KB article and KB4019990. In the BC thread, the thread maintainer (Sardoc) has successfully installed this second (but according to my examination) older file on top of the previous, July, one... I am still undecided, leaning to hesitant... Take your peak... (I really have no idea how "amicable" is MSFN towards BC; I do know that some MSFN members ( @JodyT and recent @Ruan ) are also members there; participants in that similar BC thread are perplexed wrt to the newly introduced TLS 1.1/1.2 support in Vista/WS2008; see here onwards... Perhaps a kind soul here can refer them to my previous MSFN post . Thanks in advance )

I have! But in all honesty, it's not a browser I can use as my main Vista browser: 1. It's focused on Privacy and Security, thus it doesn't store any browsing/download history (gets wiped out upon exit - no way to override that... ); plus, it won't allow you to resume a previous tabbing session 2. Has a nasty bug when trying to open a bookmarks folder placed on the bookmarks toolbar (won't let you inspect the content of the folder, is only able to open all bookmarks within the folder in equal number of tabs. 3. Its WMF/MSE support on Vista SP2 is broken (much like Firefox 53); so it can't use system codecs for h.264/aac playback, either as standalone MP4/m4a files or AV streams encoded in h.264/aac; you can also perform the youtube HTML5 test where you'll discover both "H.264" + "H.264 & MSE" are disabled (red). 4. The real deal breaker is that Epic Browser doesn't accept ANY EXTENSIONS from Google store, including themes, thus its overall functionality (as a Chrome 58 based browser) is severely limited to basic web browsing... Its own webstore (only viewable with Epic Browser) currently only lists 7 (security related) extensions! Quite frankly, the only feature I found semi-useful was its built-in Epic (encrypted) Proxy, which, among making you more invisible on the net - plugins disabled for that, it does allow for accessing geo-filtered content...

Yes, I have tried that; has some minor issues, though... But it's based on Chrome 50.0.2661.102 code, so quite old already from a performance and security standpoint... Even if the (Chinese?) devs are actively patching security holes, 50.0.2661.102 is/was the last version of Chrome that would run on Vista SP2, this fact alone makes me pessimistic about future Vista compatibility/support... The Slimjet devs dropped Vista support when they had to move to Chromium > 53 codebase, the Russian devs of Yandex Browser managed to keep Vista support even when their code was based on Chromium 57 (last version of Yandex Browser that supported Vista SP2 was 17.4.0.2461, code based on Chrome 57.0.2987.137); Yandex no longer supports XP/Vista