VistaLover

I thought all the "about:" references were the culprit, however in the end they got through... Another suspect was the embedded imgur image link, or links native to the forum itself; however, the forum software errors sometimes do not follow a defined pattern and the full composed post just won't be submitted, for no apparent reason ; I had to do it by a real trial-and-error method, submitting single paragraphs (or even sentences), checking they went on-line and then editing post by adding another paragraph (or sentence), until my whole report was finally through... It was really a nerve endurance test...

I am running into a minor New Moon 28 bug, which has been persisting over several weeks; I can't tell how old it is, cause I started testing NM28 from v28.0.0a4; I was able to reproduce on a new clean profile, with no extensions added, using latest build 28.0.0b4 32-bit (buildID 20180720233208) STR In a new clean profile (happens in an old, "dirty" one, too), navigate to about:support; the "Application Basics" top section contains clickable links (in blue) to some internal (about:) pages; middle-clicking on all but one of these links (the "about:buildconfig" one) results in a blank (empty) new tab; so does right-clicking and selecting Open in a new tab, but left-clicking works as expected, opening the internal "about:" page in the same tab... I think this issue should be reported to Moonchild and be hopefully fixed; I do have a GitHub account myself, however, being on Vista, I can't run the official MC PM28 builds (Win7+) ; FWIW, Serpent 52.9.0, built on the same UXP platform, does not present this issue... [OT: I had a heck of a time trying to post this report, I did it literally line by line, as the forum software always responded with a Forbidden error message (must have received more than 20 of those...); I know this is a known situation, however it's getting worse to the point one can no longer post without being driven mad... ]

See also this I posted over at the Vista subforum...

It may well look as if Malwarebytes Anti-Exploit (MBAE) 1.12.1.90 be the last version to run on Windows Vista SP2; this was reported by a Vista user on their forum, several hours ago ; MBAE is a perpetual beta free software with all premium features turned ON for volunteers/testers; the new auto-update to v1.12.1.97 brought with it, alongside several serious issues with Chromium-based browsers on Win7+), loss of functionality on the Vista OS (XP too?), because of new functions missing in Vista's kernel32.dll Version 1.12.1.90 can be fetched navigating to vendor's official page here ; in the event that page changes, direct link to the setup is https://malwarebytes.box.com/s/hrxfh20wtbre7tfaimf56i5chlodia4z Special provision has to be taken not to trigger auto-update to the non-compatible 1.12.1.97 version, see: https://www.wilderssecurity.com/threads/malwarebytes-anti-exploit.354641/page-152#post-2770670 (courtesy of MSFN member @Sampei.Nihira)

Can you spot the oxymoron in the above statement with the following practice: IOW, you have excluded a browser process (FirefoxESR 52.9.0) from your Anti-Virus/Security Suite (MSE), which leaves you open for possible attacks while you browse/download (as an OS browser is the main app one accesses the web with and a perfect candidate vector for infection); I wouldn't do this myself, nor recommend it to others ; but, of course, you're the master of your own box ...

Hi . It appears the Tycho platform for Pale (New) Moon 27.x.x has been EOL'd, as per 5da550a So PM 27.9.4 will be (probably?) the last official stable (release) version on that platform (and the last to officially support Vista SP2 ). Since you were building New Moon 27.x.x not from the release branch 27.9_RelBranch but from the master branch, perhaps just recompile one final time, but you yourself update appVersion on the master branch to 27.9.5a1 (see c674a10) to make it more evident, beyond any doubt, that the code snapshot is some commits ahead of the last stable 27.9.4 release; just a humble suggestion for next weekend's eventual updates... I didn't have the slightest what TenFourFox is, so after searching I found out it is a fork of Mozilla Firefox for Power Macs that has significantly diverged from Mozilla code after the 45 ESR milestone; for transparency, are those changes the ones designated as M* and where exactly their details are to be found (somewhere inside https://github.com/classilla/tenfourfox perhaps?) ? Thanks for your ongoing hard work

According to this PAs.com comment : Electron framework requires Win7+ by definition ... and according to that thread, further code was removed by M$, hindering considerably stealth portabilisation of Skype 8 even on electron compatible OSes Nice find, many thanks!

The off-line windows 32-bit installer (file jre-8u181-windows-i586.exe) continues to function properly on this old Vista SP2 32-bit laptop; I suppose this is of no consolation to XP users of this thread, just reporting it as a FYI here; the GUI during installation (which itself took quite long, ca. 5min on this old, under-resourced, machine) was slightly redesigned to be of a more elongated rectangular shape; but it did include a link to the following Oracle article: Release Notice a message the XP users are unlikely to see, due to the installer being broken on that OS Regards

You do realise you can't/shouldn't stay put for ever on a specific browser code snapshot just for the sake of an extension, however valuable it might be for you . Pale Moon 28, at this stage of its development, is constantly evolving - it is expected that some things will break (including extensions) while other things (e.g. page rendering) and/or various bugs are being ironed out... In fact, even when PM28 reaches a stable/release status (early autumn 2018?), we don't expect full 100% compatibility with the Pale Moon 27 ecosystem ; this is due to huge changes in the underlying platform (Tycho [Mozilla 38] -> UXP [Mozilla 52]). I only made the jump from PM27 to NM28 last week and spent several days to tailor it according to my liking; some of the extensions that were working on 27 quit on 28, so upgrades/replacements had to be found; most of all, I mourned over the breakage of my favourite complete theme, FT Deep Dark v9.5.4, but then I moved on to a similar, but 28 compatible, one, Dark Moon 2.0.3 ... But I digress In what exact way does dTa! work badly? More importantly, what version have you got installed? Please see relevant PM forum thread: https://forum.palemoon.org/viewtopic.php?f=44&t=19494 If still on 2.0.18.1, try upgrading to the stable 3.0 branch (i.e. v3.0.8): https://addons.mozilla.org/en-US/firefox/addon/downthemall/versions/?page=1#version-3.0.8 You can also try the nightly 3.0 branch (v3.0.9pre): https://code.downthemall.net/nightly/dta-3-0/ or even the nightly 3.1 branch (3.1.1pre): https://code.downthemall.net/nightly/trunk/ You need Moon Tester Tool Pale Moon extension to install above dTa! versions... (As a precaution when testing new things, always back up your NM profile first ) Regards OT: Nice to see the forum is usable again , after 3 days of serious issues...

@kitaro1 The Polish Language Pack I linked to targets New Moon v28.0.0b2 and newer: <em:minVersion>28.0.0b2</em:minVersion> <em:maxVersion>28.0.*</em:maxVersion> You are still on an older a4 version, as per your screenshot... Please update to the latest b2 build kindly offered by @roytam1 and the pack will install (but may break with coming weekend's release... ): (And BTW, 95% of what I post about has been proof-read and tested as being valid at the time of posting... )

Duplicate post deleted I have run into serious issues today trying to browse/login/post/edit posts in this forum Links clicked take ages to load, more often than not giving a "500 Error" page... Login in can require two or three attempts, writing a post seems to work OK, but when clicking the "Submit/Save" button it just stalls there ad infinitum (and then you may end up with a duplicate post...). I have no script-blocking extensions installed, all cookies are allowed for the "msfn.org" host , fully disabling uBlock Origin doesn't seem to matter... While it's a high probability this is site-related (let's hope it gets sorted soon without other loss of data), I couldn't help noticing that the browser I was using, NewMoon 28.0.0b2 (2018-06-29) (32-bit) was more prone to producing those forum errors compared to, say, FirefoxESR 52.9.0

Draft language packs for Pale Moon 28 (on UXP) have been announced here: https://forum.palemoon.org/viewtopic.php?p=144777#p144777 which takes us at: https://github.com/JustOff/pale-moon-localization/releases/tag/28.0.0_RC1 As noted, These are of course installable on @roytam1's New Moon 28 builds (PM28XP pre-release builds), but be warned that because Pale Moon 28 is still undergoing many GUI changes, they (Language Packs) are prone to break with any future release . After the installation, remember to modify the value of pref general.useragent.locale accordingly and restart the browser, in order for the pack to be used... In the event of a future break 1. If the browser is able to start and AOM is accessible,, disable the language pack (in about:addons) and restart, to go back to the default (en-US) localisation. 2. If the browser GUI is totally broken and won't start, then start in safe mode and permanently disable/remove the culprit LP. Or locate in Windows Explorer your NM28 profile and manually delete file "./extensions/langpack-[x]@palemoon.org.xpi", where [x] is the code for your language (e.g. en-GB), then start the browser normally... You should keep an eye on the linked GitHub page for newer, fixed, releases... @kitaro1 : Polish LP for NM28

... This isn't so... Cyberfox 52.9.0 (officially supporting Win7+, but can be hacked to run on Vista SP2, too...) had just been released mere days ago, the buildID of the x86 binary was 20180626222034; but they made a big blunder there : Cyberfox is distributed together with a full set of language packs (91 to be exact), but they had forgotten to change the maxVersion string in their install.rdf files (from 52.8.0 - there never was a 52.8.1 release, unlike FxESR - to 52.9.0), so their browser was only available in en-US locale... The Australian developer was forced to rush release a new "fixed" version with working (embedded) language packs, hence the version bump: https://github.com/InternalError503/cyberfox/commit/7fd07cc BuildID of new x86 binary is 20180629141022; security wise, Cyberfox 52.9.1 is on par with FirefoxESR 52.9.0. If/when there'll be a FirefoxESR 52.9.1 chemspill release, Toady will follow soon after, but, of course, never release in advance of Mozilla...

I had been otherwise occupied all day long, so only recently skimmed through the numerous MSFN e-mail notifications on this subject... My input: Moonchild wrote: Really? English is not my mother tongue, but doesn't "should continue" imply they are currently able to run on Vista? This is the furthest thing from the truth! Lots of places inside their forum; I did a quick search and I came up, amongst others, with: https://forum.palemoon.org/viewtopic.php?f=1&amp;t=15806 This was when Moebius/UXP-T1 was forked from a Mozilla Platform 53.0a1 code snapshot; that snapshot was already devoid of any residual XP/Vista OS support, as the good () guys over at Mozilla had already excised all relevant code... MC team did absolutely nothing to restore at least partial Vista support... https://forum.palemoon.org/viewtopic.php?p=114825#p114825 https://forum.palemoon.org/viewtopic.php?f=61&amp;t=18253 (Basilisk and Windows Vista; I urge you to read the entire thread , but I've selected the following part:) Officially released Basilisk 55.x.x.x was never compatible with Vista; by pure luck (or negligence on their part), the compiler flags were such that lowering the subsystem value of the executables (6.1 -> 6.0) would allow for them to run on the Vista kernel, but OS integration was suboptimal; non-existing code targeting Vista resulted in WMF (and possibly other parts, e.g. EME, aka Widevine DRM plugin) being broken! https://forum.palemoon.org/viewtopic.php?p=132054#p132054 And when in the start of spring this year they ditched Moebius in favour of UXP-T2 (now just UXP), they forked a Mozilla 52 ESR platform with full XP+Vista support and what was the first thing they did? Meticulously removed all that support (as it's always easier to delete existing code than write new one...). Are we to believe that MC has just now had a sudden change of heart and he's willing to devote precious coding time to undoing the Vista massacre? I'm not that gullible... What's worse, in official Basilisk 52 + Pale Moon 28, they have amended their compiler flags/optimisations to fully ignore NT 6.0 (Vista/Server 2008); this has been already documented previously in this thread by esteemed member @WinClient5270, but it was also the result of my own tests weeks ago, when the first official builds were publicly released... Unfortunately, it's more than those... Inspecting latest (official) PaleMoon_unstable-28.0.0b1.en-US.win32[buildID=20180625093249] package with dependency walker, I am disheartened; focusing on just xul.dll module, this has calls to 6 missing functions in kernel32.dll GetCurrentProcessorNumberEx K32EnumProcessModules K32GetModuleFileNameExW K32GetProcessImageFileNameW K32GetProcessMemoryInfo K32QueryWorkingSet and to 2 missing functions in shell32.dll SHGetPropertyStoreForWindow SetCurrentProcessExplicitAppUserModelID Main executable (palemoon.exe) has lesser issues, of course I wasn't bothered to check other DLLs... Similar results are obtained with official Bk52 releases... And I emphasise again, it isn't only compilation configuration that needs to be changed to target Vista, it's actual browser code that needs to be rewritten to accommodate a fully functional, Vista compatible, application... Will Moonchild deliver? I think not... (and until PM 28 "stable" gets released in the final quarter of 2018, Vista user-base will have dropped even lower to merit his support considerations...) @WinClient5270, if memory serves right, I recollect you having registered previously in the Pale Moon forums (about an issue with Visual Studio 2013 dlls affecting PM 64-bit, that I had identified for you...); perhaps the best way to clear the FUD once and for all would be to post in the linked thread (by Jody) and ask plain and simple what MC's definitive decisions are; not his thoughts/intentions, but if he's actually determined to support Vista in PM28 (at least in the same level he supported Vista in PM27); please don't hesitate to convey some of my reservations/points I raised here ; full WMF+MSE support on both 32-bit/64-bit Vista architectures would be a must; UXP (unlike Tycho) is suitable for that, if they're willing to undo the damage they did to it concerning Vista; these days, noone wants a browser that won't play back embedded audio-visual content... Here's hoping...

Hello ! UAS isn't needed, strictly speaking, because Basilisk (both 55/moebius and 52/UXP), unlike Firefox ESR 52.x.x, has support for Site-Specific-User-Agent-Overrides (SSUAO); for example, if you set the following "string" preference (in about:config), general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0 when visiting AMO they'll think you are using Fx 52 (the deprecated 52.0 or ESR 52.x.x); but if you feel more comfortable adding one more extension, be my guest ; in any case, most of these installation problems from AMO can be overcome, for the time being, by navigating to the "classic desktop site" version of the extension page (scroll all the way down, then click on "View classic desktop site"; a session cookie is set (mamo); you should be again able to install from the "legacy" installation page) ... I have toyed with various UAOs for the "userstyles.org" site in Bk55, and the issue I reported doesn't seem to be UA related (but, of course, I might be wrong...). This reply was made by using latest Bk 55.0.0 (2018-06-23) (32-bit) on WinVista SP2 x86; as you can see, I had no problem quoting excerpts from your two recent posts; please start in safe mode or (better) create a new clean profile to test; if everything works as expected, it's some extension or user preference that interferes; only you know how you've configured things; on my side, things are working pretty fine . Regards

Hello again Roy I did update back to the latest build, Basilisk (Serpent) 55.0.0 (2018-06-23) (32-bit) (buildID=20180623000710) and toggled the mentioned pref: SUCCESS All previously non-functional userstyles now work as expected! Cheers for finding the culprit! And I saw you've already pushed the necessary change to your forked Bk55 repo: https://github.com/roytam1/basilisk55/commit/81899e5 But (sadly, there's always a but... ) : ... this issue is still there, in an annoying fashion . Userstyles.org have made it all the more difficult to install a userstyle they host, if 1) you're not running one of the major browser brands, notably latest versions of Chrome/Quantum, and 2) you're not running the latest webextension version of Stylish. They do not provide an interface to install a specific style on its page, as I said the "Install with Stylish" button is just a lure to force Stylish WE 3.1.1 down your throat . With New Moon and Serpent browsers (Stylish 2.1.1), I have found clearing the browser cache and reloading the page several times will finally get you the "install style" pop-up prompt... But the detection of an installed style is a very handy feature that doesn't work in Bk55; if I visit https://userstyles.org/styles/94667/selected-tab-blue-font-color-for-ft-deepdark with latest Bk55 (buildID=20180623000710) with that userstyle installed, I get: In the case of latest Basilisk (Serpent) 52.9.0 (2018-06-23) (32-bit) (buildID=20180623010357), with the same userstyle installed and active, detection succeeds: Possibly some javascript code which only works in Bk52/UXP but not in Bk55/Moebius Can you please come up with a solution for this? FWIW, it would appear that the detection of an installed userstyle also fails in both NM 27 [27.9.1a1 (2018-06-15) (32-bit)] and NM 28 [28.0.0a4 (2018-06-23) (32-bit), so this bug isn't unique to Bk55! I think you meant a working WMF+EME (Widevine) Vista implementation - thanks for not throwing in the towel beforehand I see this has already been taken care of in https://github.com/roytam1/basilisk55/commit/7042385 We'll have to wait for your next builds over the weekend to test As ever, lots of Regards

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&amp;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