VistaLover

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...

Hi dencorso ; I suppose a "High Court Appeal" is out of the question then, am I right? Best regards from Greece (wait; you, too, can see the flags ... ) !

But doesn't security.csp.enable;false mean that for the sake of just blocking CSP reports, the whole CSP browser feature is being turned off? Having a read of the Content Security Policy (CSP) documentation, I think CSP is something we should keep enabled ; of course, I am not a security authority like yourself , so please share some extra knowledge on this... Kindest regards, keep safe and healthy (Saturday I'll get my first anti-Covid19 jab ) !

This depends solely on MCP (as I don't expect roytam1 to take this up on his own ), going by what is already known about them, they won't be jumping on that bandwagon very soon/if ever... Personally, I'm not that worried TBH, the article you linked to says:

Do you actually mean FirefoxESR 68 (I've never known a 64esr version to have existed; 60esr -> 68esr -> 78esr -> 91esr) ?

Sorry again, @Dave-H ; under latest Serpent 52.9.0/Vista SP2 32-bit, the "Country" section of Account Settings displays as below: Perhaps "View Members Flags" is only reserved for Mods now?

... Yes, thank you for the legible screenshot of Panda Dome's "about" window...

Sorry Dave, haven't seen the "flags" myself since many moons ago... They are certainly MIA on latest Serpent 52: I accept further discussing this here is OT ; there exists a now LOCKED thread I started in Feb 2020 in the Site & Forum Issues sub-forum where I pointed out last January that the flags had again vanished for good, but, as said, the thread was locked by a mod... If the flags are there for you (BTW, on which browser?) and you know of a way to bring them back for the rest of us, please come forth... Cheers