VistaLover

I maintain my sister's (work) computer which runs Win7 SP1 x64; once I upgraded her from Fx 88.0.1 to 89.0, I was most unpleasantly surprised , appalled is the word I'd choose ; she wasn't thrilled by the change, either... Especially on Win7 with aero enabled, the new Fx GUI (fogged tab bar) doesn't blend at all with the OS... TBH, I've stopped getting informed about Mozilla's planned shenanigans some years ago; they did lose me as a user (and a Nightly tester) when they made the decision to drop support for my favourite OS (Vista) ; I only skim the Release Notes every time I update Fx on my sister's box, just to make sure nothing major has been broken (e.g. my sister was very upset when they removed the "Page Info" context menu entry in Fx 88 : she was used to it being there, to aid her get direct links to images on pages; FWIW, you now have to use CTRL+I, until, of course, they kill that too in a future "upgrade"). You are quite right that with every design change, Fx gets worse/crippled ; we are probably just old "geezers" ("advanced users" is the Mozilla term) who have known and appreciated the great Firefox of an era gone-by without return (i.e. when functionality/customiseability/users' wishes were top priorities), the mobile-oriented young Fx users of today are probably more impressed with "trendy" looks and over-simplification... Plus, Mozilla currently employ a small army of well-paid young web/app designers, they have to constantly "re-invent the wheel" GUI-wise, their moto is "fix it until it's broken"; if they stopped messing with Fx's UI, they would have nothing to work on and probably made redundant... Instead, Mozilla keep them on and force into retirement/let go all the highly talented/accomplished "old school" developers of their glorious past... The end is near...

Well spotted! The thing is I had the following rule in uB0's My Filters ! Block globally AdobeDTM SatelliteLib scripts ||adobedtm.com^$third-party,important ... since many months ago , so that's why I was able to load the referenced links in my previous post ... The crux of the issue is UXP's incompatibility with the SatelliteLib Adobe are including in their tracking scripts , so yes, ALL UXP- based browsers/forks are affected... In fact, if you search for "adobedtm.com" in the official PM forums, you'll discover many related cases: https://forum.palemoon.org/search.php?keywords=adobedtm.com I think the issue for me was first manifested on Oracle's site (see here) and I now remembered I actually sought help here in these forums about it ; solution was provided then by @UCyborg, further analysis by yours truly can be read here ... Nothing to do with the Windows XP OS per se (apart from the fact it won't run the latest versions of Chromium and siblings (including Firefox Browser), on which the Adobe tracking scripts are made/tested to work without issues...). Generalising is easy sometimes, but not necessarily the truth ... 360EE browser, based on recent versions of Chromium and made XP/Vista-compatible, has no issues dealing with the adobedtm scripts and, thus, with the sites that make use of it... But, being a Chinese product, it isn't easily endorsed by the XP community... Anyhow, 360EE is OT here and has dedicated forum threads (with some enhanced activity lately... ) Best wishes

First link: Second link: What errors/warnings does the Web/Browser console print? Have you tried loading those URIs in fresh browser profiles? All OK here,,,

... not the same thing at all, in fact a case of "Catch 22" if you ask me... It requires WS2008R2 SP1 (Win7 based Server equivalent) 64-bit as the host machine, on which you must first install Hyper-V (successor to Virtual PC); then you must install and configure the linked VHD (Virtual Hard Disk), which is a 180d trial of WS2008...

.NET Framework 4.6.1 will install out-of-the-box in WS2008SP2, but, as is the case with Vista SP2, won't be offered any updates via MU; please install .NET Framework 4.6 and let that get updated via MU until WS2008SP2's EoS (Jan 2020); the list of obtained updates can then be used to manually update a 4.6.1 installation... I'll be in your debt, if you do... Can you share some more details (without, hopefully, breaking Forum rules...) ?

Official Pale Moon requires at minimum Win7, so support requests for it should be better directed/placed in the respective OS forums... Be that as it may, if users of PM wish to install "legacy" Firefox-only targeting extensions, against the wishes of PM's makers, the method to go by is probably the one below: 1. First enable the setting pointed out by @nicolaasjan, i.e. PM won't block any blacklisted add-ons (the same setting can be achieved via about:config, by disabling the blocklist completely, extensions.blocklist.enabled => false or, alternatively, render it ineffective by setting extensions.blocklist.level => 3 2. Install in PM the latest version of JustOff's Moon Tester Tool: https://github.com/JustOff/moon-tester-tool/releases/tag/2.1.3 3. Have the "legacy" Fx-only targeting add-on available in the form of an .XPI file, saved on disk; the latter can be obtained from CAA, other online repositories or, possibly, copied from the profile of another application where that add-on was already installed (limited to extensions that were not unpacked during installation) ... 4. Use the .XPI file(s) to install in PM with the aid of MTT (Moon Tester Tool); the extension(s) will appear inside PM's add-on manager (AOM) with a [TEST] prefix; those extensions won't be auto-updated, but this isn't an issue for unmaintained legacy Fx extensions, completely forsaken by their original authors... However, I don't see the reason myself why you should choose official PM if on Win7+ over either Mypal/New Moon; these two browsers do not impose any restrictions upon legacy Fx add-ons and, to the best of my knowledge, will launch and run without issues on OSes other that XP...

I couldn't help noticing that the app (EasyBCD) can use .NET FW 2.0 or 3.5; 2.0 is native to Vista, 3.5 is offered as an update to native 3.0; so, good chances are, the app would have launched for @Nandor IF no .NET FW4 was installed; it looks like the (crooked) installation of 4.8 prevented EasyBCD from falling back on either 3.5/2.0; notice also how stricter are .NET FW4 requirements, the range of 4 versions is limited to 4.0-4.6 ... While having no .NET FW4 installed would have (probably) allowed EasyBCD to work, HandBrake 1.0.7 (EoS for Vista) does need it... You are certainly welcome ; so, despite my initial claim, I did manage to help you... BTW, are you really running a copy of WS2008 32-bit (it says so underneath your avatar...) ? Is this machine connected to the web and does it have a working Microsoft/Windows Update currently (several specific KBs are needed to enable access to the SHA-2 WU endpoints currently in place, I hope you're aware...) ? After you installed .NET Framework 4.6 (the last officially supported by Microsoft Update), were you offered any updates for it? It should be possible to fetch all available 4.6 Security & Quality Rollups at least until Jan 2020, when WS2008's Extended Support came to an end... I'm asking this as a possible continuation to a related query of mine in another thread... Thanks in advance for any additional feedback...

That function requires at least Win7: https://docs.microsoft.com/en-us/windows/win32/api/processtopologyapi/nf-processtopologyapi-setthreadgroupaffinity While you can install 4.8 (with "workarounds") on Vista SP2, I'm not convinced myself it works flawlessly all of the times and for all .NET FW 4 requiring apps... I can't help you, sadly, all I can testify is that Handbrake 1.0.7 (2017040900) - 32bit launches fine here on my Vista SP2 x86 machine with .NET FW 4.6.1 (32-bit):

Well, for future reference: 1. Mozilla do not currently check whether a WebExtension (WE) hosted on AMO works as expected with older Firefox versions ; https://addons.mozilla.org/en-US/firefox/addon/vandal-navigator/versions/ reports that "Works with firefox 48.0 and later", but this is an automated setting generated by AMO infra based on the sheer fact it's a WE add-on... Considering this is a very recent extension, I seriously doubt its author has checked its proper functioning outside of latest release Firefox (88.0.1) and, possibly, latest FirefoxESR (78.x.x)... 2. If you plan to install a WE add-on on Serpent, first make sure it properly works in FxESR 52; if it does, then proceed to install on St52 (with "workarounds" if it's of the id-less type), but even then it's not a given it'll properly work under St52, because of a crippled set of WE-APIs there... This is something I highlighted already in my previous post Well, it isn't like you committed a major mischief , I simply wanted (again) to spare members here of undesired consequences should they follow the much easier (but perilous) route of profile transplantation between different browser applications... I was very active in these threads [now renamed "My Browser Builds (Part 1)"] at an era I witnessed the mass exodus (of XP/Vista users) from the deprecated FxESR 52.9.0 to the then current versions of Serpent 52/55, and, against my own due warnings, people chose easiness over was what the "proper" thing to do: they simply migrated their FxESR52 profiles to St... - and then I would be "summoned upon" to troubleshoot very "weird" issues that, in the end, were due to this improper profile migration; that at a time when there was even closer proximity between FxESR52 and St52 of 2018... Both are forks of the same upstream application, MCP's Pale Moon, but differ as to what development channel they fork; Mypal uses the release (stable) PM channel and NM uses the unstable (dev) PM one... But one should make no mistake: the apps, especially in recent versions, are different enough under the hood that I'd never suggest myself they share the same profile; as you say, it might be much safer to share profiles between Mypal 27 and NM27 but as you move towards more recent codebases, it ceases to be so (e.g., I wouldn't move a Mypal 29.2.0 profile over to NM 28.10.3a1 and vice-versa) ... Of course, it is a trait of the human nature to prefer the easiest/shortest path, so I might sound like "preaching" here ... But, once you've made your own choice, whatever that is, be prepared to suffer any eventual consequences... Best regards

Dear @IXOYE vandal-1.1.0-fx.xpi is yet another Firefox-targeting Web Extension that will not install on Serpent, because it's a type of WE called an "id-less" one... I have in the past, over many occasions, explained ad nauseam the "why" and "how-to" install such WEs on Serpent... https://msfn.org/board/search/?&q=id-less&search_and_or=or&sortby=relevancy For a more technical analysis on the "why", https://msfn.org/board/topic/177125-my-browser-builds-part-1/page/147/?tab=comments#comment-1164701 For a more "practical" read, https://msfn.org/board/topic/177125-my-browser-builds-part-1/page/100/?tab=comments#comment-1159013 https://msfn.org/board/topic/180462-my-browser-builds-part-2/page/133/?tab=comments#comment-1189182 perhaps could be of help... Bottom line is, you have to edit the extension's manifest.json file so as to add a gecko-id block; repackage and then it'll install in St52... St52 != FxESR 52.9.0, especially with regards to WE APIs, so installing in St52 won't guarantee perfect functioning... And, please, DO NOT follow the advice given by my friend @ArcticFoxie ; transplanting a Fx profile onto St52 (or, worse, to St55) is a sure recipe for profile corruption, often times beyond repair! People, for the millionth time since I've been a member of this community, FIREFOX 52.9.x and SERPENT 52.9.0 are two different applications that have diverged so much over time, that their profiles are NOT INTERCHANGEABLE anymore (without risk of data corruption); just don't do it! Always start with a fresh St52 profile and only transfer vital parts such as bookmarks and, where applicable, passwords... Re-install crucial extensions as needed...

@burd : Many thanks for that second screengrab of yours The list transcribed from the image is: KB4040973 KB4041778 KB4578963 KB4597239 KB4600945 KB5001848 However, and this is something I had completely forgotten about , these KB numbers ARE NOT DIRECTLY indexed (and thus findable) inside MUC, because they constitute parts of larger bundles/RollUps... For instance, it would appear that the last ever Security Only Update for 4.6 on Vista before its EOL (in April 2017) was KB4014558; searching for that in MUC doesn't return any result; but that update was/is part of KB4014988 (released on Apr 10th 2017): April, 2017 Security Only Update for .NET Framework 2.0, 3.0, 4.5.2, 4.6 on Windows Vista SP2 and Server 2008 SP2 (KB4014988) inside of which is found as file "ndp46-kb4014558-x86_dc321d638ffa0c672a555b9e8e37e52994c71253.exe" ... So, while that list of 6 installed updates is, no doubt, something to go by, it won't be that easy/quick to locate (inside MUC) the bundles they belong to... Yes, KB4040973 was part of 2017-09 Security and Quality Rollup for .NET Framework 2.0, 3.0, 4.5.2, 4.6 on Windows Server 2008 SP2 update i.e. KB4041086; even M$ themselves confused WS2008SP2 with WS2008R2SP1, as the following depicts: ... I have "access" to a friend's Win7 SP1 64-bit older laptop, that she hardly uses any more; I had her purposefully freeze the .NET FW installed there on version 4.6.1, which was/is supported by WU on that OS of hers; I instructed her to do pretty much the same thing I kindly asked @burd, below is the produced screengrab: Despite the similarities with Vista, this is actually on Win7 SP1 x64, where 4.6.1 was never updated further (WU is currently offering 4.8 for installation) and which has a working WU, minus, of course, ESU for Win7 SP1... So, it appears, at least on that specific machine, that 4.6.1 was never offered through WU any more updates (outside of ESU that is) past KB4040973 (Security and Quality Rollup) in Sep 2017... When I find some extra time in the coming weekend, I might try to track down MUC links for the rest 5 updates in @burd 's list...

Wikipedia is editable by anyone; that bit you reference, was only added mere hours ago, https://en.wikipedia.org/w/index.php?title=Windows_Vista&oldid=1025080050 https://en.wikipedia.org/w/index.php?title=Windows_Vista&diff=prev&oldid=1025080050 however I can't form an opinion on the validity of the added info, obviously only Chinese Vista users might offer a clue on this...

@burd Thanks , but please change the "Views" setting to "Details" (and then arrange by "Program"), afterwards you can simply "Snipping Tool" just the .NET FW 4.6 ones; on my 32-bit machine, here's a glimpse of what was manually installed for 4.6.1 (including pre-releases) up until Oct 2017 (I, then, simply couldn't be bothered anymore... ) :

Somewhat OT, but since you brought this up here... @burd , could you be a sport and do this Vista community some additional good? Please, go to Windows Update => Installed Updates => Sort by "Program" => Microsoft .NET Framework 4.6 (x) and then make a list of ALL the updates your restored WU fetched and successfully installed for .NET FW 4.6 ? If possible, you can divide them chronologically into three groups : 1. Till Vista SP2's EOL 2. Till WS2008SP2's EOL 3. Currently installed ones under WS2008SP2 ESU (i.e. including those for Apr 2021) The produced list can then be used to easily fetch the same updates from MUC and update manually a Vista SP2 .NET FW 4.6.1 install ... Thanks in advance to anyone willing to undertake this! Best regards

Yes, if you decide to use the CleanFlash installer, you should update .NET FW 4 to the very last version issued for WinXP, i.e. 4.0.3; however, if you don't want to install .NET FW 4 at all, the .bat based CleanFlash setup should suffice...

Server 2008 SP2 = Server 2008 + SP2 I think you just confused it with Server 2008 R2 (and Server 2008 R2 SP1), which is Win7 (and Win7 SP1) based...

The same person who released FlashPatch (which, as you noted, requires Vista+) has been now releasing CleanFlash, a "sanitised" version of Chinese Flash, currently at version 34.0.0.155; the original distribution is batch-file based, so it should be XP-compatible (but I can't test this here...); the second distribution is installer-based, to run it under XP you need .NET FW 4.0+ It is advertised that ALL Chinese telemetry has been removed, along with geo-limitations ("flash.cn" provided files are meant to run in mainland China, only... ) Enjoy!

The Browser Extension "they" provide for "Firefox" is of the WebExtension format, so will only install in FxESR 52.9.x and Serpent 52.9.0/55.0.0; it doesn't run in KM and it won't install/run in New Moon 27/28, because these browsers do NOT support WEs...

@erpdude8 : Most of "us" guys (you probably mean fans of the Windows Vista OS) are probably already aware of M$'s .NET FW deprecation plans... No panic actions should be called for, just some preservation plan in advance... First thing to do is probably download from M$ and archive somewhere the Full standalone (off-line) installers for .NET FW 4.5.2/4.6/4.6.1 ... 4.5.2 https://download.microsoft.com/download/E/2/1/E21644B5-2DF2-47C2-91BD-63C560427900/NDP452-KB2901907-x86-x64-AllOS-ENU.exe 4.6.0 https://download.microsoft.com/download/C/3/A/C3A5200B-D33C-47E9-9D70-2F7C65DAAD94/NDP46-KB3045557-x86-x64-AllOS-ENU.exe 4.6.1 https://download.microsoft.com/download/E/4/1/E4173890-A24A-4936-9FC9-AF930FE3FA40/NDP461-KB3102436-x86-x64-AllOS-ENU.exe Then, someone on a clean Vista SP2 install will have to restore a functioning WU (while it's still possible - at least one solution is known to work, but its "legality" is grey... ) and then (first) install 4.5.2 and let WU fetch all applicable updates up to Vista's EOL and then, additionally, up to WS2008's EOL - finally, make a list of those updates and share it for others to fetch and archive manually from M$'s Update Catalog... The same will have to be done for 4.6.0; as correctly pointed out, that's the very last WU supports officially on Vista; the list of updates that'd be produced for 4.6.0 is also applicable to 4.6.1, which is the last one to install out-of-the-box on Vista SP2 (but updates for it must be downloaded and installed manually) ... I'm afraid I'm not allowed to discuss 4.5.2/4.6.0 updates past WS2008's EOL, since those are governed by ESU plan and reserved only for paying customers... It is my understanding the ESU cycle will end on Jan 2023, so that probably means 4.6.0 on WS2008 will reach deprecation as planned on Apr 2022, some 8 months before the OS's ESU cycle ends... Unless, of course, M$ make an exception and continue releasing security-only updates for 4.6.0/WS2008, for the duration of those 8 months... Even if they don't, my experience so far has shown that the "family" of 4.6.x .NET FWs gets updated by the same (or, mostly, compatible) "update" files; so if a 4.6.2 security-only update is released come May 2022 for Win7 SP1, there's a good chance it will install on (ESU-eligible) 4.6.0/WS2008... https://docs.microsoft.com/en-us/lifecycle/faq/dotnet-framework The above quotation isn't 100% clear, but to me it sounds like .NET FW 4.6.0 (> 4.5.2), the last to be officially supported on ESU WS2008SP2, should be eligible for security-only updates until the end of ESU support for said OS... How do others read this?

@Vistapocalypse : By searching I landed here: https://code.videolan.org/videolan/vlc/-/milestones?sort=due_date_desc&state=closed and then here: https://code.videolan.org/videolan/vlc/-/milestones/113 which does suggest a 3.0.15 milestone is currently in the works, cut-off date for its official release being July 30th 2021 ...

So, a c*ck-up on their part proved your prediction wrong... But, do you know of an official timetable as to when, in fact, the VLC 3 branch will become deprecated for good?

@yoltboy01 : Make sure not to link any of your endeavours here, else you'll get summarily BANNED... (FWIW, I'm not even sure that "site" you simply "mentioned" will go down well with the mods here... Just friendly advice, nothing more... )

This has been indeed asked multiple times here , the most recent one was just six pages back in this very thread... : https://msfn.org/board/topic/182647-my-browser-builds-part-3/?do=findComment&comment=1199196 Answered previously by roytam1 on Feb 8th: https://msfn.org/board/topic/180462-my-browser-builds-part-2/?do=findComment&comment=1195399 My own answer from back in February: https://msfn.org/board/topic/180462-my-browser-builds-part-2/?do=findComment&comment=1195384 (NB: Not meant to offend anyone ... ) TL:DR: appVersion numbers simply don't tell the whole story and people should not just stick to them... Latest NM 28.10.3a1 has all the code found inside unstable official Pale Moon 29.3.0a1, minus portions of the official code it was decided we shouldn't adopt, plus code we have kept but upstream have gotten rid of... And since you're anxious about Web Components implementation, upstream haven't made any leaps towards that goal, there's a dedicated issue in their tracker https://repo.palemoon.org/MoonchildProductions/UXP/issues/1361 coupled with https://repo.palemoon.org/MoonchildProductions/UXP/issues/1344 where you can monitor their progress (or lack of... ); until recently bounty material, if/when something is added there, be sure it'll find its way into New Moon, too, irrespective of its advertised version number... Is it clear for you now? Best wishes!

Their script starts its "job" once you start typing the reCAPTCHA in the input box... On FirefoxESR 52.9.1, they successfully detected an association with the Telegram desktop app (i.e. Fx can handle ".tg" links...); FWIW, I had only tested the app some years ago, currently it doesn't even support Vista (or XP) ...

OTOH, it doesn't find anything here in latest Serpent 52.9.0 (portable installation) with uBO-legacy: I've given them more than five minutes...