VistaLover

Some potentially new trouble over the horizon, caused by upstream changeset below: https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499 As most of you know, official Basilisk no longer supports Web Extensions, because what limited support there was (somewhat inferior to the one present in Firefox ESR 52.9.x) was decided by MCP to be removed, purportedly for "security" reasons - that change was reverted by @roytam1 and so WE support in Serpent 52.9.0 has been kept. With WE support removed, MCP proceeded to also remove some latent e10s code still present in platform (UXP) level; this was UXP issue #1130, resolved by upstream commit git-19c0f5e Because "we" have kept WE support, that change was also reverted in Serpent 52, so that one can still force-enable e10s in that fork... At the time, I commented that perhaps the upstream change was favourable for implementation on New Moon 28 alone, because if one force-enables e10s on NM28, one will end up with an unresponsive browser and/or profile corruption (e.g. previous session is mangled ); this is because, and that was stated previously, PM28/NM28 as applications have no code at all to support multiprocess (e10s); Serpent 52, OTOH, does have such support, so force-enabling e10s there doesn't cause havoc... But, since the upstream change was at platform level, I was told it wouldn't be feasible to selectively implement it on NM28 but revert it on Serpent 52, so I didn't pursue this further... Having thought about it in a later instance, this is still feasible, perhaps not very practical: https://github.com/roytam1/UXP/ has two branches currently: 1) master, which in essence mirrors the upstream UXP master branch and 2) custom, which encompasses all @roytam1's custom changes and it's used to build both St52 and NM28, probably the Binary Outcast forks, too... One could create a third branch, e.g. NM-custom, initially as a custom branch clone, implement the upstream changes (19c0f5e + f7f7224) just there and use this branch to compile NM28, while the original custom branch can continue to be used for Serpent 52 compilations! The latest MCP change modifies two language pack files: toolkit/locales/en-US/chrome/global/aboutSupport.dtd https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499#diff-3f6259650a01247c84ac14224308b455 and toolkit/locales/en-US/chrome/global/aboutSupport.properties https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499#diff-7e2b1f36d16b447ed465c9f234751864 Since UXP/custom still supports force-enabling e10s, come next Saturday, the platform-wide upstream change must be reverted by @roytam1, because if not, Serpent users who have force-enabled e10s there won't have an easy indication it's being active, apart from chasing basilisk.exe processes in Task Manager - and there's an additional possibility the about:support tab in St52 won't load if the change isn't reverted (?).. If reverted, then future official Pale Moon language packs will cease to work with future New Moon 28 builds (because the official localisation team will soon remove those localised strings and about:support tab will get broken in NM28 with an official LP installed); I'm sure many non-English users of NM28 (I can think of several Polish speakers, one or two Italian speakers etc.) wouldn't want that to happen ... So, what will the course of action be? We've reached that place before in the past, when some people asked that WebRTC support be enabled in NM28 (it's non-existent in PM28), and in the end language pack users "won" (for lack of a better word, it was not a "contest" as such...); what will it be now? Mind you, this hurdle can be circumvented by the UXP 3-branch "method" I detailed above...

... No!

In the original repository, you probably mean the following code in the "about" box: https://github.com/binaryoutcast/binoc-central/blob/c6c62f93930f4809de4b63cd91ef83412e7e299f/projects/mail/base/content/aboutDialog.xul#L57-L59 <description class="text-blurb" id="communityDesc"> &community.start2;<label class="text-link" onclick="openURL('http://binaryoutcast.com/');" oncommand="openUILink(this.getAttribute('href'), event);">&community.mozillaLink;</label>&community.middle2; </description> Disclaimer: I'm not using MailNews myself...

... Wouldn't all this new hardware cost a fortune?

... However, inside file Install.bat it still reads (twice ) : title Unoffical RoyTam1 Browser Installer by i430VX v1.0 An omission?

Ditto here, with a slightly older build of New Moon 28.6.0a1 in Firefox Compatibility UA mode: uBlock Origin (legacy) latest, 1.6.4.11, no other content blockers...

... and what, may I ask, is this: @dencorso: This is all over the place: 1. In its own thread, linked to above: https://msfn.org/board/topic/179433-rare-winxp-patch-most-important/ 2. In the @roytam1's browsers thread: https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/?do=findComment&comment=1167128 3. In the POSReady 2009 updates thread (the most suited place for it, IMHO...): https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1167126 You are free to leave things as are , but I humbly think some housekeeping is in order! (... and I don't mean to belittle poster's efforts in the slightest, just don't like things scattered everywhere; probably an OCD of mine... ).

... I'm sorry to say this (thus slightly disagreeing with you), but whatever "one" (as in an XP fork maintainer ) does will never be sufficient to keep Matt A. Tobin at bay or make him revisit his opinions/change his behaviour towards the XP forks people... Just consider that @Feodor2 has taken the steps to fully rebrand his forks, yet he's still being treated as trash by the Tobin person ; don't be fooled, he's the kind of people that want your arm and shoulder too, when you're simply extending your hand to them...

This has been taken care of upstream: https://github.com/MoonchildProductions/UXP/issues/1152 https://github.com/MoonchildProductions/UXP/commit/f46e7a46cc16260d9c346016db43cf920cc6706a ... and speaking of "upstream", the stable PM channel has had a 28.6.0 release https://github.com/MoonchildProductions/UXP/releases while the unstable PM channel (from which NM28 is forked) has just had a version bump to 28.7.0a1 https://github.com/MoonchildProductions/UXP/commit/c794a79d87a64425c3c23af78f4234833fb9bd79 (... that version bump may cause language-pack breakage in next Saturday's New Moon 28.7.0a1 builds; as always, you should check out for updated packs at https://github.com/JustOff/pale-moon-localization/releases )

Minutes ago, I tried logging into my GitHub account using New Moon 28.6.0a1 (I'm on a slightly older build with buildID=20190530233318), a process I've successfully completed countless times over the past year or so using NM28; but M$ owned GitHub wouldn't let me in this time ; nothing was changed on my part since yesterday, when I had a successful log-in using the same browser version and profile... To proceed, I had to supply a 6-digit security code, to properly verify my device (??????) ; the code was contained in the following e-mail: Let me just clarify I don't consider any Microsoft employee as my "friend", but this is obviously a discussion topic for another board/site... I went ahead and submitted the code and, fortunately, I managed to log in ; but what baffles me is why my initial attempt failed? FWIW, I don't employ a SSUAO for GitHub in NM28, because it was not needed (until now?) ... Any GitHub members here with a similar experience running New Moon 28 on XP/Vista?

Matt A. Tobin spewing venom again at @feodor2, the maintainer of MyPal and Centaury XP forks: https://forum.palemoon.org/viewtopic.php?p=169823#p169823 ... Some things (or individuals...) never change!

Reading Windows Update Datastore.edb File which, again, leads to a NirSoft product: http://www.nirsoft.net/utils/ese_database_view.html (not tested here on Vista...)

The WinUpdatesList app, referenced previously in this thread, does provide the option (among others) to save all history in HTML format: Menubar -> View -> HTML Report - All Items PrimoPDF can successively concatenate (or, rather, append) each printed page to the previous one, too, but I guess what @Dave-H refers to is one still has to launch the virtual printer 150 successive times; time consuming it is, but if you're really up to it, you can divide the task among several days...

@roytam1 has always published updated browser builds on a Saturday; when updates on a specific Saturday are not going to happen because of reasons personal to Roy (e.g. extra work, trip, national holidays etc.), he usually says so beforehand... "Mid-week" updates as such are infrequent and only as a response to a reported serious bug, affecting only one or even more browser types... Apart from this very thread, all important "links" are being also published in Roy's blog

@~♥Aiko♥Chan♥~ Avant Browser is actually a tri-core browser (much like Lunascape): 1. It can use the Trident rendering engine of the OS available Internet Explorer version; on fully updated Vista SP2, that would be IE9. 2. It can use Mozilla Firefox (Gecko) rendering engine. 3. It can use Chromium (webkit) rendering engine. Their downloads page offers choices for fetching the Lite version (Trident engine only) or the Ultimate version, with all 3 engines; that last one is also available in a USB (portable) flavour... I suspect the version you tested under Vista was the "ultimate" one... As you said, gecko.exe in latest AB build (2019 build 2, 5.18.2019) is of version 66.0.5.7070, based on Quantum 66 code, thus incompatible with Vista (and XP, of course...); if you try to manually launch gecko.exe, you'll get a "not a valid Win32 application". So the Gecko rendering engine CAN'T be used in Vista... The WebKit engine is of version 74.0.3729.131 and, unlike the case of Chinese browsers, isn't patched for XP (and Vista) compatibility; if you try to manually launch webkit.exe under Vista, you get "The procedure entry point TryAcquireSRWLockExclusive could not be located in the dynamic link library KERNEL32.dll"; in other words, that engine too is incompatible with Vista... From the above one can easily conclude only the Trident engine is usable under Vista; the frontend (GUI) of Avant Browser does run under Vista, but somehow the browser defaults to the Chromium web engine, with the behaviour you reported; but the GUI behind the error pop-ups is still responsive and one can use the Options wizard to set the default RE to IE9 standards: After that setting, you can properly launch AB under Vista and it will use Trident (IE9), but, and Vista users are already aware, IE9's engine is pretty dismal when it faces the web standards of 2019; our own MSFN Vista subforum is rendered very poorly: And because webkit.exe is still being called by the AB GUI (for several secondary functions), when you exit AB (even when Trident is the default RE), you're still gonna get webkit related popups, which you'll have to kill via Task Manager... Summary: Avant Browser under Vista? A lost cause, TBH; only the Lite version can be installed and properly launched, but I see no real reason to, as you're in essence just getting a "re-skinned" IE9 with all its shortcomings with regards to browsing the web in the year 2019 (and beyond) ...

... For the duration you can still display your Windows/Microsoft Update History in IE8, I guess you can use a virtual PDF printer to archive those IE8 pages to a handy PDF file; just a thought you should entertain IMHO ... EDIT: Beaten to it by mere seconds! (Great minds think alike, yada, yada... )

Binisoft, the company behind Windows Firewall Control (WFC), was bought out by Malwarebytes: https://www.zdnet.com/article/malwarebytes-acquires-windows-firewall-control-firm-binisoft/ https://www.binisoft.org/ https://www.binisoft.org/wfc On the current iteration of the WFC home page, no archived versions of the app exist , only a historical changelog ; v4.9.6.0 (Vista+WS2008 EoS) was released on Mar 26th 2017 and at a time when the "free" version had several limitations compared to the registered (paid for) one... I can't help commenting on the author's "rush" to drop Vista (but also WS2008) support with version 4.9.7.0, just days after MS ended Vista's Extended Support on April 11th 2017: FWIW, .NET FW 4.6 was/is officially supported on Vista, so what was the rush to drop Vista? Fortunately, the Web Archive has salvaged the download link for WFC v4.x.x.x: http://www.binisoft.org/download/wfc4setup.exe The Mar 1st 2017 snapshot will get you v4.9.4.0 (Vista compatible): http://web.archive.org/web/20170301124512/http://www.binisoft.org/download/wfc4setup.exe but, sadly, there's no WA link for v4.9.6.0 . I have managed to track down a saved copy of v4.9.6.0 in a Czech software portal, and that's because they had actually archived it on their servers (and not just redirect to author's download link): https://stahnu.cz/firewall/windows-firewall-control/download/6 I've scanned the setup locally with Kaspersky Internet Security (with latest defs) and it appears legit and clean; virustotal also gives it a clean bill: https://www.virustotal.com/gui/file/6dc5106c7018567adc4e5473ed0676b7d9acfe0312f3eb0578b9f9954848b1c1/detection NB, you do need .NET FW 4.5.x+ to run the app; screengrab of the setup running just before actual installation: Enjoy...

... If you thought 360/Qihoo had shown scandalous behaviour (in the past?), what do you call QQ's one ? https://citizenlab.ca/2016/03/privacy-security-issues-qq-browser/ https://www.quora.com/Is-QQ-safe-to-install ... And, as mentioned elsewhere, I simply hate it that the latest breed of Chinese Browsers (e.g. Maxthon and QQBrowser) auto-associate themselves with Word and PDF documents, including media (audio+video) files... I had once Maxthon 5 installed in its portable mode, but even then it kept hijacking document and media file associations; I had a terrible time ridding my laptop's disk and registry of many of its remnants ...

@Jiger ... Really worth reading : https://www.askvg.com/download-ccleaner-slim-installer-and-portable-version/ and from there: https://www.ccleaner.com/ccleaner/builds

11.0.2116.0 has only been a minor version update; actually, there have been several released after version "2031" : 11.0.2031.0 => 11.0.2052.0 => 11.0.2086.0 => 11.0.2116.0 and all of them remain XP/Vista compatible, all based on the same Chromium 69.0.3497.100 source code . There's a "General Discussion" thread over at the XP forums you might want to follow: with contributions even from Vista users (including several from yours truly... ). Latest version (in an "unofficial" portable installation) running on my Vista SP2 32-bit laptop:

@foxzzy First, I want to welcome you to the MSFN forums ... However, and any forum admin will probably agree with me, it's not polite or even compliant with forum rules to have your second post be a slightly reworded version of your first one, asking about the exact same thing... You made your first post here: <thread link invalidated because of thread merge: it's the 1st post on this thread, now> and @Mathwiz was kind enough to provide you with links to the main MSE thread, where your query should have been answered, beyond any doubt... Did you ever bother reading the relevant posts (found in the "last-ish" thread pages...) ? You obviously didn't like the answer you received and you opted to come back with this duplicate query/thread... This is a real faux pas... MSE/XP is dead; first, M$ made its engine non-XP compatible; an interim mitigation was applied, but the final end was imminent: M$ also changed the "format" (for lack of a better term) of the actual definitions to be only compatible with the updated (non-XP compatible) engine; any attempt to patch those files will invalidate their file signatures/HASHes and render them "corrupt", unable to be used even with the old engine... What you're asking is for someone to deeply patch official Microsoft files (both engine DLL and definition files); even if some able person manages this, it wouldn't be allowed to post here "hacked" Microsoft files... FWIW, MSE is kept going by M$ only for the sake of Windows 7 (and they are being gracious to those few Vista users, too); once Win7 reaches EoS in several months, the future is unclear for "legacy" MSE (replaced by updated WD in Win8+)...

Vista SP2 users can manually install provided patch(es) for WS2008SP2: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0948 https://support.microsoft.com/en-us/help/4503273/windows-server-2008-update-kb4503273 https://support.microsoft.com/en-us/help/4503287/windows-server-2008-update-kb4503287

Welcome to the MSFN forums Might I ask what this tutorial is all about? Since WD is a native/integral Windows OS feature first introduced in Vista (IIANM, on XP is a standalone/separate download...), perhaps posting it on the main Windows Vista forum looks appropriate ; but a forum admin may think otherwise...

... Extremely grateful to you on both counts...

I can definitely report that on my 11 year old Vista SP2 32-bit install (with WS2008 updates up to Oct 2017 and .NET FW 4.6.1 manually installed), the app completes the scan successfully: I'd be much obliged if you forwarded this to your Malwarebytes connections/devs, so they could hopefully be prevented from taking a lighthearted and quick decision, based solely on one reported "issue"; we understand (but certainly not approve...) they don't want to support Vista anymore, but they should not artificially block the software from running on "compatible" (?) Vista configurations: If it works, don't break it! If it doesn't work to begin with, no support should be requested; then everyone's happy... Thanks in advance for alerting the Malwarebytes people... PS: Just a thought/question of mine I wanted to publicly voice: Why is it that "Security/Anti-Malware" software decide to jump the boat once dear ol' Microsoft terminates "official" support for one of their OSes? A sane, everyday, person would think that such software is rendered all the more necessary on said OS (one the vendor stopped patching); just look at what happened with XP: M$ killed for good its MSE solution, so die-hard XP users turned to third party paid apps still supporting XP (which means added profit for the authors of these apps...); but the conspiracy-theorist inside me mumbles that M$ actually bribes those third-party app authors to discontinue support, in order for Windows users to be forced to cough up their hard-earned money towards new hardware+WinOS...