VistaLover

@soggi : Each of the above packages contains an application.ini file: BNavigator: [App] Vendor=OpenSource Name=BNavigator RemotingName=bnavigator CodeName=Browser Version=0.9.7608a1 BuildID=20201106041532 ID={a3210b97-8e8a-4737-9aa0-aa0e607640b9} MailNews: [App] Vendor=OpenSource Name=MailNews RemotingName=mailnews Version=52.9.7608a1 BuildID=20201106032451 ID={3550f703-e582-4d05-9a08-453d09bdfdc6} So, there you go! NB: The "7608" part of the version strings is actually build number, so expect it to change in future builds (when full "clobber" is done...)

@soggi : A small inconsistency I'm seeing at your "mirror" : The link to Serpent 55/moebius 64-bit package should be modified accordingly (to be uniform with the rest of the links to 64-bit browser packages ...) ; other than this, many thanks for carrying the torch...

AutoCopy 2 is still available on ATN: https://addons.thunderbird.net/en-us/firefox/addon/autocopy-2/versions/ => https://addons.thunderbird.net/firefox/downloads/file/431692/autocopy_2-1.2.91-sm+tb+fx.xpi

Just thought the following would interest people using the UXP forks: It is the personal goal of upstream developer M.A.T. (but also backed-up by Moonchild himself) to completely debilitate all Firefox-targeting "legacy" extensions from being installable in official UXP browsers like Pale Moon/Basilisk... Already, unstable Pale Moon 29.0.0a6 official builds come without the buildconfig option "--enable-phoenix-extensions", which means already installed compatible Firefox XUL extensions will be disabled , with no option to re-enable , while "new" ones (e.g. from CAA) can no longer be installed ... One way to circumvent that artificial block is to manually edit the add-on's install.rdf file to include a Pale Moon specific <em:targetApplication> section... Or, for a more automated/user-friendly procedure, install and use JustOff's MTT: https://github.com/JustOff/moon-tester-tool/ A confrontation between M.A.T and JustOff has been brewing for some months now (on several levels), let's just say that M.A.T wasn't enthused by the CAA extension nor the recent update of the MTT one ... In a recent post: What future M.A.T. refers to is tracked in official UXP issue #1659 and work on it has already started: https://repo.palemoon.org/MoonchildProductions/UXP/commits/branch/xpiprovider-work I'm not implying, though, that official devs have any ill intent; their view on things is that they should (forcibly) migrate their users from long-deprecated, "insecure", no-longer-maintained Firefox specific legacy extensions (e.g the ones provided by CAA) - despite the fact they are currently working OK - to PM-exclusive format and extensions, forks of the original ones, with current maintainers sourced from the UXP communities (and elsewhere) ... Lofty as it may sound, the net result is yet another wave of plain user inconvenience... Should we be concerned? I'm not yet sure... I don't know what fate awaits the --enable-phoenix-extensions buildconfig flag; if the supporting code stays put, then we should be OK with regards to Fx XUL add-ons; however, in due course, upstream extensions and their repositories will move to the new format, which we'll have to somehow support too, if we are to make use of (or abuse of, as upstream claim ) ... Is supporting both formats (old: install.rdf, new: install.json) in the core browser a possibility, even? I'm no coder, so can't say myself... But, definitely, this part of the official UXP development is one our maintainer @roytam1 should keep a close eye on... Best wishes, stay safe

... For consistency, the issue "was" archive.org's embedded book reader not loading in NM28 (among a few other browsers) and the "resolution" is to toggle about:config pref media.webspeech.synth (from its default false to true) ...

Is this about Mypal or New Moon (per attached image) ? I wasn't using NM27 that far back (as in v27.5.1; official Pale Moon 27 still supported my OS, Vista, I switched to NM28 when PM28 was released) ... Can you please post a link to that NM 27.5.1 package? If you also supply the details of what should be corrected/added, I might take a look at it... No promises yet...

For clarification, Iceweasel-UXP is Hyperbola's fork of Basilisk/UXP (well, broadly speaking... ).

Admittedly, I have been remiss in revisiting this thread, but to the extent it concerns my personal usage, I don't consider Vista's native Windows Defender an urgent matter (as explained previously, I'm only running it and try to keep it updated for "legacy"/sentimental reasons ) ... In any case, Microsoft have been really hopeless in their - still advertised - NT 6.0 support for the off-line WD standalone updater (file mpas-fe.exe); "Previously on Dynasty", I had reported that series 1.323.xxxx.0 of installers became Vista incompatible, because it introduced engine file mpengine.dll of version 1.1.17400.5, not NT6.0-compatible; that series ended with version 1.323.2309.0, digitally signed (SHA2) Oct 1st 2020. During the course of the 1.323.xxxx.0 series, Vista users could update manually their WD by 1. Manually downloading mpas-fe.exe from 32-bit: http://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe 64-bit: http://definitionupdates.microsoft.com/download/DefinitionUpdates/amd64/mpas-fe.exe 2. Extracting from it (with 7-zip) the two *.vdm files (the actual definitions; the smaller-sized is a binary diff one) 3. In Windows Explorer, navigating to the Updates folder of their WD default installation, e.g. for Vista 32-bit it's in: "C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Updates" 4. Dropping inside that directory the extracted *.vdm files (overwriting files, if present); in a matter of ~ 20 seconds, the newer defs will be auto-installed! NB: Step 4 implies a Vista compatible engine file (e.g. v1.1.17300.4 from the previous 1.321.xxxx.0 series) is still in place in "C:\ProgramData\Microsoft\Windows Defender\Definition Updates\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}" (the alphanumeric string changes into a new random value with each update) Then, in the docs.microsoft.com URL provided by @Vistapocalypse, there was a link to a newer engine file, v1.1.17400.7, digitally signed Sept 3rd 2020, which was indeed NT 6.0 compatible; sadly, that file was only circulated "internally", while on-going series 1.323.xxxx.0 was still shipping to end users incompatible engine 1.1.17400.5 ... FWIW, the very few Vista users with access to "fixed" mpengine.dll v1.1.17400.7 could finally upgrade past v1.1.17300.4 by placing it, as with the *vdm files, inside: "C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Updates" On Oct 2nd 2020, series 1.325.xxxx.0 was released (with 1.325.10.0) and it introduced new engine mpengine.dll v1.1.17500.4 that reinstated NT 6.0 compatibility; Vista users could, once again, update their WD app by simply running file mpas-fe.exe It would appear all was hunky-dory for Vista users, but, once again in a very short while, Microsoft people goofed up big time On Oct 22nd 2020, while series 1.325.xxxx.0 was still on-going, Microsoft released mpas-fe.exe v1.325.1199.0; the file still contained the compatible engine v1.1.17500.4, but trying to run said file under Vista you get: Probing the file itself with specialised tools revealed that it as well as the inner file MpSigStub.exe, though both remained NT 6.0 compatible functions-wise, had been compiled with a Subsystem 6.1 PE header, thus they couldn't be run under Vista in their default state ... Of course, trying to mess with the PE headers (and I had no clue how to modify the internal .exe's one ) would invalidate Microsoft's SHA2 code/file signatures, "bricking" the mpas-fe.exe for updating purposes... Series 1.325.xxxx.0 ended on Oct 29th 2020, with v1.325.1653.0 (the breakage still not fixed); if Vista users wanted to update their WD past v1.325.1177.0 (issued on Oct 21st), could follow the procedure outlined above (by selectively extracting *.vdm files, etc). On Oct 30th 2020, series 1.327.xxxx.0 was released (with 1.327.7.0), introducing new engine mpengine.dll v1.1.17600.5; I am happy to report that a. The new engine remains NT 6.0 compatible b. Files mpas-fe.exe & MpSigStub.exe both have their Subsystem PE headers "fixed" to 6.0 IOW, business as usual (file mpas-fe.exe launches and updates WD's definitions as expected!) Given MS's previous record on this , I'd say the next f**k-up is imminent...

UXP (Unified XUL Platform) is the name of the platform on which several upstream and downstream (forks) projects are built... Organisation: Moonchild Productions (MCP) UXP applications: Pale Moon 28 (+29), Basilisk (52.9.*) Organisation: Hyperbola (unofficial abbreviation: HBL) UXP applications: Iceape-UXP+Icedove-UXP Organisation: Binary Outcast (offical abbreviation: BinOC, unofficial abbreviation: BOC) UXP applications: Borealis Navigator+Interlink Mail & News Thus, Basilisk/UXP -> Serpent 52.9.0 Basilisk/Moebius -> Serpent 55.0.0 (*) Pale Moon 27/Tycho -> New Moon 27.9.x (*) Pale Moon 28[/29]/UXP -> New Moon 28.10.x Borealis Navigator/UXP -> BNavigator Interlink Mail & News/UXP -> MailNews The Hyperbola forks are meant to run only on said Linux distro, but roytam1 has forked them to compile and run on WinXP+... (*): The Tycho and Moebius official platforms have long been deprecated (and also purged completely from official repositories ) , roytam1's forks currently use code from other projects to get updated...

... My contribution was very small, the credit goes to our Roytam1. ... According to "upstream", you both should be hanged in the village square: https://forum.palemoon.org/viewtopic.php?p=202420#p202420

@siria : https://udn.realityripple.com/ https://udn.realityripple.com/docs/Archive Salvaged documentation for pre-WE (aka "legacy") add-ons: https://udn.realityripple.com/docs/Archive/Add-ons/Add-on_SDK ... Thus, you can relax a bit now...

Works OK here in NM28 32-bit (Vista SP2 x86); direct link for KB4092483 32-bit: http://download.windowsupdate.com/d/msdownload/update/software/secu/2018/09/mso-x-none_852c8f4c16a121d662c070374553e1ffe159779a.cab

In this case "Nightly" is the default app name in unofficial Firefox branding; Roytam1's offering is an unofficial (unbranded) fork of Mozilla's Firefox ESR 45 branch...

A number of Jetpack SDK extensions can be force-installed (but non-guaranteed they'll function as designed) in NM27 via the Moon Tester Tool extension (v1.0.2 should be preferred in NM27, because it also supports Firefox Complete Themes and Mozilla dictionaries ; both were dropped in recent Pale Moon 28.1x.*/29.0.0a6, thus latest MTT 2.0.1 also axed support for those... ) https://repo.palemoon.org/MoonchildProductions/UXP/issues/120 was the upstream UXP issue that tracked this for the transition Pale Moon 27/Tycho -> Pale Moon 28/UXP

(NB: OT content, NPP related ) It's probably Notepad++ bug #8010 on XPSP3/2003SP2, which started with NPP v7.8.3 Notepad++ bug #8010 was closed as WONTFIX; dail8859, a member of NPP's organisation, plainly states that XP is not supported anymore:

... Another (English writing) reviewer noticed that:

Unfortunately, the youtube SSUAO method has ceased working many weeks ago, whether you impersonate Google Bot or a relatively old Firefox (etc.) version ; more finer "machinery" is currently needed for Youtube in order to access their non-polymer layout, the process involves URL and Request Header manipulation (to specifically request from the server a late July/early August version of the embedded youtube player, as mentioned by @RainyShadow here ), plus some additional HTML/CSS fixes may be needed to be applied on the generated "Classic" youtube page... This is basically what the two Firefox WEs discussed previously actually do... WE need a "legacy" type extension for both New Moon 27+28 to regain Classic YT ; NM28, with its more advanced platform and engine, stands better chances of having such an add-on created for it, not least because it also supports jetpack extensions... Another possible solution would be to write a usescript duplicating the functions of those WEs and installing it on NM27/28 via "Greasemonkey for Pale Moon" This subject, but for official Pale Moon 28, was first brought up in the official support forum: https://forum.palemoon.org/viewtopic.php?f=46&t=25030 but the developers there, despite having the know-how to write such an extension, vehemently refused to do so, sayin' it isn't worth their time and effort on developing something that may get obsoleted any day now... I do note, however, that we have a "coders corner" here at MSFN: https://msfn.org/board/forum/99-coding-scripting-and-servers/ ...perhaps it wouldn't hurt asking over there...

7-zip has an (advanced) setting under Tools -> Options -> Editor where you can input the full path to your preferred code editor's main executable, and from then on "text-like" files inside an opened archive will open with said selected editor; very handy indeed, does not involve OS-wide file type (i.e. extension) associations... A similar (advanced) setting exists inside WinRar, too: (Apologies, but I currently have a Greek-only installation of latest WinRar 5.91, I guess you still get the idea, hopefully ) PS: The code editor of my choice...

@Mr.Scienceman2000 : You need to have previously installed (and probably also fully updated) .NET Framework 4 for Kaspersky Labs Products to run on XP and beyond; the last "series" of Kaspersky products to not require .NET4 was the "2013" one... Do you actually have .NET4 on your XP Pro SP3 machine?

Window's Notepad is unsuitable for editing code ; as @nicolaasjan suggested, use for such tasks a dedicated code/text editor, with coloured syntax themes; proper code editors will automatically identify syntax errors (e.g. missing brackets, commas, etc.) and alert you about them (e.g. by highlighting the error block in a different colour or poping up a notification, etc...) [Another thing to consider when using Notepad is the encoding format when saving a modified file; usually Notepad saves a file as ANSI, but several code files need to be saved as Unicode/UTF-8 instead...]

The Firefox add-on is of a type called Web Extension (Mozilla's attempt to ape Chromium extension format; search for more info...); Pale Moon, of which New Moon 27/28 is an unofficial fork, has never supported Web Extensions (by choice of its developers), thus 'Good Old Youtube' can't be installed in New Moon... Try Serpent 52.9.0 (the ia32 build should run on non-SSE2 CPUs, if you fall into that category) ... Sadly, at this very moment, Roytam1's binary repository is DOWN, so you may have to kindly ask for that among members here...

So sorry to hear about this but, to be honest, was kind of expecting it to happen, if one takes into perspective their previous record: o.rthost.cf was taken down on ca. Oct 21st 2018; o.rths.cf was taken down on ca. Oct 8th 2019; and (not surprisingly) o.rths.ml has been taken down on Oct 22nd 2020... ... As you can tell, they are being consistent, allowing you a free domain for the duration of (approximately) a whole calendar year (and, as I recall, a maximum of 3 [free] domains can be granted to a free "freenom" account holder) ...

Latest version of G-O-YT, 1.15.2, installs and functions perfectly fine in St52 as long as the correct modification to its manifest.json file has been performed, which is probably where you messed-up... @vikmin : Since Serpent 52 does not observe extension-signing, you can also do away fully with the META-INF directory... Those not confident modifying source code files, may switch to Old Youtube, which was updated to v2.1.1 (I prefer myself the G-O-YT one because it's more failproof than O-YT ). NB: Serpent 52 does NOT currently search AMO for WE updates, so you must yourself do so (e.g. bookmarking both extensions' "versions" pages on AMO and visiting periodically...). Do keep in mind both extensions are just "hacks", they may break at any time, when Google completely obliterate the classic GUI's files from YT servers...

Related upstream support forum thread: https://forum.palemoon.org/viewtopic.php?f=29&t=24993&p=197006 The website admins basically write code targeting very recent Javascript engines and/or Chrome-specific web technologies (e.g. ShadowDOM, part of Google Web Components); latest New Moon 28 should function correctly with WBM's timeline bar ; as for getting this to work under NM27, I can only guess it'd be an extremely difficult task, if at all achievable... Best greetings

@roytam1's Pale Moon fork does not target Windows XP exclusively; it can run very well on Windows OSes past XP, i.e. Vista, 7, 8, 8.1, 10; "our" maintainer has, among other things, extended upstream support "below" the officially sanctioned Windows OSes, to include Vista/XP/2k (probably with "Extended Kernel" installed); I see no reason to remove support for OSes other than XP (this would be plainly selfish coming from XP users), since our UXP fork has already diverged enough from upstream to be a separate platform... I am aware of people (several of them here on MSFN) on Win7+ using New Moon 28 and/or MyPal 28 because they prefer them to the upstream offering... Divergence is more pronounced on the Serpent 52 fork, e.g. it has retained WebExtentions support, thus a person on, say, Win8.1 can't use official Basilisk if said person wants a "legacy-style" browser with additional WE support; e.g., recent discussion about WEs restoring "classic" Youtube layout comes to mind... Denying people the ability to appreciate @roytam1's offerings on OSes other than Windows XP is an OS-discriminatory stance akin to the one exhibited by upstream, denying their applications to Vista/XP users ; and I stand to be corrected, but Win8-specific codepaths in the platform won't even load when the application is launched under XP, so I wouldn't call "Start Menu Tiles" support in the platform/app code a "feature" that has "crept"... The majority of people here that have stayed on Win<7 are tied to some older hardware which, for a wide variety of reasons, don't want/can't make parts with... Each one's (older) hardware combination (motherboard, CPU, GPU, etc.) is probably unique, so it might be unwise to generalise on overall performance going just by one's own particular setup(s)... Thankfully, Roy tries to maintain a wider variety of forked browsers to accommodate most older setups, the key here is what works best for "you" (your H/W, S/W, workflow, etc.). I'll refrain from commenting on your "security" views, I said recently that this is a (mostly) democratic community, thus all opinions are welcome/heard (to the point they don't violate forum rules); FWIW, we have here proponents of both extremes on the subject of "security"... Best regards