VistaLover

@Ugh: What does your "old lady" use currently, BTW? Official FirefoxESR 52.9.x was never meant to be run on a non-SSE2 CPU; AFAIAA, no effort has been made public here to recompile it to run on a SSE-only machine; compiler optimisation is one thing, but the source-code itself is another ; if the latter invokes the SSE2+ instructions set, then the SSE-only optimised binary will crash when run on a SSE-only CPU... The last (official) Firefox that would run on a SSE-only CPU is FxESR 45.9.x; Roytam1 does maintain a fork of that, for the sake of very old H/W, but it's being rarely updated and offered (as ALL of his browsers) in English, only: http://o.rthost.win/gpc/files1.rt/firefox-45.9.34-20221210-b637891ad-win32-sse.7z Discussion of Firefox 45/52 tends to be academic nowadays, because Google, with their dominance on everything web-related , have restructured the Internet of 2020+ to be palatable mostly to the latest Chrom-e/-ium version (-20 versions, if lucky ...) and likewise with their stepchild, "Firefox Browser"... The "-sse" & "-ia32" variants of New Moon (27/)28 target nonSSE2 CPUs: New Moon 27.10 was originally forked from Pale Moon 27 (Vista+); its engine is inadequate for today's web, but it has recent TLS (HTTPS) implementation... https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20230408-f4385096ea-xpmod-sse.7z https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20230408-f4385096ea-xpmod-ia32.7z New Moon 28.10.6a1 tries to catch up/be better than latest Pale Moon 32.1.0 (Win7+) ; it's based on the UXP platform and has, together with Serpent 52, the best web compatibility of the offered XP-compatible browsers (but still inferior to mainline Chrome/Firefox): https://o.rthost.win/palemoon/palemoon-28.10.6a1.win32-git-20230408-d849524bd-uxp-b5e969b8a-xpmod-sse.7z https://o.rthost.win/palemoon/palemoon-28.10.6a1.win32-git-20230408-d849524bd-uxp-b5e969b8a-xpmod-ia32.7z Originally forked from FxESR 52, the "-ia32" variant of Serpent 52.9.0 will be the closest thing (to Fx52) that will run under XP+nonSSE2: https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20230408-3219d2d-uxp-b5e969b8a-xpmod-ia32.7z ALL above binaries will NOT autoupdate, thus you need to manually update/overwrite older builds with newer ones (they're released in weekly cycles, but, unless you have a special need that calls for it, you can update more infrequently); and, as stated, are only offered in English (so, here's hoping your client has at least some rudimentary command of English ) ... For updated builds, you may want to bookmark: https://rtfreesoft.blogspot.com/search/label/browser Best regards

... What app do you use to edit those? ... On Vista+, you can inadvertently associate a file type/extension with a program, if you use Explorer's Context Menu "Open With" => "Choose Default Program..." route ... I often went that path when one of the already present entries (inside "Open With") didn't suit me, or I simply wanted to open that file (just once) in another of my currently installed programs; but once you click that last option, you are presented with below window: Having used WinXP for some years prior, I'd simply move on to picking one of the apps inside "Recommended/Other Programs" area, completely failing to notice the already ticked () "Always use the selected program to open this kind of file" option, in small fonts (it's NOT ticked by default under WinXP...). Having fallen into that trap many a times, especially during my first "Vista" years , I wanted to "un-associate" mistakenly established file associations (to another program or, even, none) and, at the time, what my online search yielded was this little gem below: https://www.winhelponline.com/blog/unassociate-file-types-windows-7-vista/ FWIW, the URI back then was different: http://www.winhelponline.com/articles/231/1/An-Utility-to-Unassociate-File-Types-in-Windows-7-and-Vista.html but that old one now returns a 404, instead of redirecting to the new one ... I haven't searched for a more powerful app, replicating most of the features the WinXP wizard used to offer (e.g. changing the "icon" of a file to one different from the one the program it's "assigned to" provides), but, at least, the "un-associating issue" was fixed for me that way ...

... However, the program itself reports a version from 29.01.2023 :

... Well, just for the heck of it , this afternoon I decided to revisit, more than a year ago since the last time, e10s on my St52 copy, putting to the test the most up-to-date release, i.e. v52.9.0 (2023-03-30) (32-bit) ... First, I made a full backup of my current, single-process, St52 profile; then, in about:config, I enabled below (hidden) pref: browser.tabs.remote.force-enable;true and toggled/modified prefs below: browser.tabs.remote.autostart;true extensions.e10sBlocksEnabling;false dom.ipc.processCount;2 After a proper browser restart, multiprocess was ON, with a maximum of 3 "basilisk.exe" processes inside Task Manager ; I used it that way for more than an hour, no dramatic changes in my configuration here (3GB of total RAM, 2 core CPU, 2007-era...), the browser was rock-steady overall ; but then I stumbled on a show stopper ; once inside an online post editor, like the one here on MSFN (I'm typing this on) or GitHub's issue/comment editor, the DEL and BACKSPACE keyboard buttons no longer work as expected there ... Say I type the word "test", and the caret (aka text cursor) is after the last "t": test| If I press BACKSPACE once, nothing happens; I would expect "t" to be deleted instead... Worse, if I press (inadvertently) the BACKSPACE button once more, the whole tab changes to the URL previously visited (in that tab), possibly resulting in typed content loss in the editor ... If I use the left arrow key (<-) to place the caret after "s": tes|t and then press the DEL button, again, nothing happens; I would expect "t" to be deleted instead, too... Both these annoyances can be worked-around via selecting the characters to delete with the mouse and pressing DEL button, but one has to be careful with the BACKSPACE button, plus one has to modify one's workflow (of years) to accommodate these e10s "bugs"... Are these shortcomings known to those that prefer multiprocess? Can they be mitigated? I've gone back to my single-process profile now, where both buttons in question behave as expected, still curious though ...

... Apart from dynamic module import that you referenced already, in my casual browsing I now find the most "mean" UXP villain to be nullish coalescing assignment ("??=") operator , for which UXP issue #2097 has been opened ... This is what causes discourse-based forums to break under UXP, and a "filter" for the "Modify HTTP Response" extension (by JustOff) has been kindly published by Pale Moon Forums member Kris_88 there ; however, you need to know both Javascript and RegExp to manually formulate such a filter, so this solution isn't for all ... I have a vested interest in opening https://venomissimo.notion.site/venomissimo/FFmpeg-86-3b484982448b485eaed6b687b2f67047 https://venomissimo.notion.site/4473a6dcc8494218be42fc504f67d5e0?v=7acc381ce8ef4a16bb95f14db710588e https://www.notion.so/34dc4ddf501a4b98b46ea9fb4f3470af?v=878345c5d88f4d21a6520db752b5c29f in St52, but all these URLs end up in blank tabs currently, because "*.notion.(site|so)" use the despicable "??=" operator since mid-January ... Can a kind heart offer some solution/filter for "Modify HTTP Response", please?

... Oh that ... I did pass by this post in the thread you linked originally, but must have not put 1+1 together at the time: In any case, I lost interest in whatever additional Artem had to say in that post, once the dreaded "WinXP is dead" was brought up ; which might be a true thing according to Microsoft, but, at the same time, gives out a lot about the app author's intentions towards EoS'ed WinOSes ... At the end of the day, hooray for WINE (on Linux) ! Of course, and no need to get defensive (if you did) ; I just pointed out that "I" can't read Russian and also included the "whatever" I used to translate it... All's fine ! Best wishes.

You might want to read this thread on AIMP Forum. ... Thanks, I can't read Russian , so I used: https://www-aimp-ru.translate.goog/forum/index.php?topic=69488&_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=el&_x_tr_pto=wapp Having read the translation, I did not find answers as to why Vista SP2 support has been reinstated (but I'm not complaining, obviously ); the thread basically talks about AIMP-v5.x's inability to integrate with the OS under WinXP (i.e., establish 1) media file associations and 2) access to Windows Explorer's Context Menu ); and I was also reminded of XP's excellent file association editor, one thing I strongly lamented when I moved to Vista (on Vista+, it's quite a PITA to remove/delete already established file associations; I had to resort to a third party app ...).

... I acknowledge this thread has a broader focus on "Software Running on XP", so it's still fine by me , however, since the last two posts seem to pertain specifically to Anti-Virus software (and in particular to ClamAV), perhaps further discussion on these should be better continued in "our" specific thread below: https://msfn.org/board/topic/177099-which-antiviruses-are-known-for-a-fact-to-be-working-on-xp-sp3-as-of-2019/ ... where I believe ClamAV was also recently mentioned ... Just my 2c, ofc ...

The download page still says Windows Vista - Windows 11 for current version 5.11.2427. Is that an error? Missing APIs? If you navigate to AIMP's Old versions page for Windows, you'll hopefully see that Vista SP2 support was withdrawn, starting with v5.01.2358 (Release date: 28.12.2021), so @WinClient5270 was right to pick out v5.00.2344 (Release date: 09.11.2021) as the Vista EoS one ; however, in a move quite rare these days, Vista SP2 support was re-instated, starting with v5.10.2418 (Release date: 21.12.2022) ...

... Well, e10s is a numeronym; "10" denotes the number of letters omitted between the first one, "e", and the last one, "s"; see also this article; for similar numeronyms i18n and L10n, Wiki has a separate entry here ...

... Yes, I've been following this in the upstream repos ; it's part of their struggle to split large DLL files (e.g. xul.dll and icudt63l.dat) inside the platform/application core into smaller ones... ... The numbers below refer to comparisons between last Saturday's and today's St52/St55 (32-bit) released builds: Serpent 52, buildID=20230324153850: xul.dll sized 44.8 MiB icudt63l.dat sized 11.4 MiB Serpent 52, buildID=20230330030628 (xul.dll split into:) xul.dll (32.5 MiB) gkmedias.dll (6.48 MiB) mozjs.dll (5.57 MiB) (icudt63l.dat exchanged for:) icu63.dll (13.9 MiB) If you do the math, we actually end up with an increase in total filesizes of +2.50 MiB (!) Serpent 55, buildID=20230324154343 xul.dll sized 64.6 MiB Serpent 55, buildID=20230330025402 (xul.dll split into:) xul.dll (40.9 MiB) gkmedias.dll (6.46 MiB) mozjs.dll (5.60 MiB) icu63.dll (13.9 MiB) Again, if you do the math, we actually end up with an increase in total filesizes of +2.26 MiB... I guess Lavoisier's (chemistry) law of total mass conservation doesn't apply here ...

... That MB Forum poster never mentioned WinXP himself, TBH , but he did write: in his original post; "legacy systems with Never Expiring License" do comprise WinXP, though, hence the rise of interest here ... In one of his subsequent posts, "he" made it clear "he" was running 3.5.1. on Vista and Win7; it's relatively easy to tell from the screenshot in his OP that it's been taken from one of his Win7 systems... ; I wouldn't do that myself; for all they know, the admins of that support forum live under the impression "That version (i.e. 3.5.1) no longer has updates."; tipping them that their impression is not true currently will only result in them tipping, in turn, those involved, who, no doubt, would turn a (perhaps forgotten?) switch to OFF even sooner ... BTW, I see no reason now for further posts about MBAM Legacy updating its definitions/pattern signatures on either XP or Vista ; ; what would be "post-worthy", no doubt, is the time it stops doing so permanently (on either OS) ...

... Like I said: "We" have built resilient communities here at MSFN, consisting of people on, so called, "legacy" Windows OSes their vendor no longer supports (or, even tries to sabotage nowadays ), but outside of such communities hostility, FUD, fake facts, etc. is the rule ... That's why I find it useless now in 2023 to "argue" with app authors about extending/continuing their support on older OSes; I did do it in the first years after Vista's EoS (2017); even at that time, most of them (especially on GitHub) were under a firm conviction my Vista laptop had already become part of the botnet... And, as you said, there's no way you could talk them out of such convictions... Alas, we have to help each other now ...

@lmacri: At the time of this writing, MBL 3.5.1.2522 can still successfully update its malware definitions on-line, both when installed on WinXP SP3 ("Premium" version, see here, here and here), and Vista SP2 ("Free" version, see here) ...

... "They" seem to have moved your post to its own standalone thread now: https://forums.malwarebytes.com/topic/296406-windows-xp-does-not-have-lifetime-support/ You should probably edit that first post, to include a link to the originating thread, so it doesn't look out of place on its own ; truth be told, I don't think you can achieve much there, except for venting a bit ...

... Many thanks for testing this ; so, it proves it can still successfully update its definitions, the same way as on WinXP ... But this finding of yours contradicts with the linked discussion in the MB Support Forum ; not that sterling of a "support", is it? I bet no-one there actually tried that "legacy" 3.5.1 version on either XP/Vista - yet, they were quick to disseminate what they were probably trained to say: "Every WinOS below Win10 is a security menace" (and what I found particularly distasteful was their suggestion below: ; I'm not a native English speaker, but, surely, "by crook" doesn't imply pirated versions, does it? ) ...

XP (and Vista) users should really keep an eye on that thread ; things look grim ... The opening post there displays a picture of what Dave described in a previous post here: However, this time the MB staff aren't interested in "resolving it"; according to the reporter (and confirmed by a staff member), Malwarebytes Premium Legacy 3.5.1.2522 can no longer receive def updates under Vista/Win7 - thanks to user feedback in this thread, we do know XP installations still receive these ; but all the MB staff can, apparently, do is endlessly recite ad nauseam the "inherent perils of running Microsoft unsupported Windows versions like XP/Vista ; as per @lmacri's post 3hr ago, MB staff have started wiping out Forum references to "Malwarebytes support for legacy Windows XP and Vista Operating Systems"; what comes next ? OT: @mina7601; Since you seem to have a Vista SP2 VM installed, could you be so kind as to try MB Legacy 3.5.1.2522 there and check whether its defs can be updated? Thanks in advance ...

... Yes, I've been following this in the upstream repos ; it's part of their struggle to split large DLL files (e.g. xul.dll and icudt63l.dat) inside the platform/application core into smaller ones... A propos, I want to ask you a relevant question: Issue #61 - Reinstate buildability with shared gkmedias dll Issue #61 - Place Skia in libxul Unlike the platform's default setting (and the obvious selection on WinXP), under Vista SP2 32-bit I prefer content to be rendered by skia, not cairo, thus I have the below user-set pref: gfx.content.azure.backends;direct2d1.1,skia,cairo (FWIW, "direct2d1.1" requires Win7+); does this new "moving around" by upstream still allow my current setting, or will it break once skia has been moved out of xul.dll? Upstream say they're only using skia "for canvas anyway", so they're probably not checking scenarios where skia is used for content, too... Any additional insight will be highly appreciated ...

Hi Nico ; I run St52 as my daily driver basically, "File upload" via the VT modern GUI works fine here in my "dirty" profile: I then launched latest NM28 in an almost fresh profile (no extensions, only slight GUI customisation ), and "File upload" via the VT modern GUI also works as expected there: So I believe it's something in your current NM28 configuration that prevents the VT File upload from functioning as expected ... Kindest regards

... Noted and original post of mine edited accordingly... It was just the level of your coding expertise that probably made me think you're coding for a living ... This thread (and the forums in general) needs more "coding-apt" members, beyond the "average mass" of just "browser users", of which mass I, too, constitute a part ... Hence, your erudite contributions are always welcome here ...

... Dear Astroskipper , my true goal was not to prove you were wrong, especially on such a trivial matter, what good would that do in the broader scheme of things? It was more a proof to myself actually , because (I thought) I had a very vivid recollection of your post in question... As I wrote recently, "I may be wrong as much as anybody else", and I have been wrong in the past, and, no doubt, I'll be wrong again in the future - it's human nature, of course, to be wrong sometimes ("errare humanum est"), more so as age progresses , and it's something I deal with constantly in real life; errors/misjudgments committed either by me or my immediate circle (of relatives/friends, etc.); as long as someone else, preferably impartial, exists to point us towards the "right", we should learn from our mistakes, philosophise a bit and move on ... But I'm going off-topic... Cheers

No worries here, too ; but I can assure you it did not contain that screenshot "when it went live the first time"; as I've posted in the past in this thread, I'm subscribed to this thread and have the MSFN forum software configured in such a way so as to send me e-mail notifications whenever new posts are being published in this thread - the software sends an initial e-mail ONLY when a post goes first "live", later edits by a post's author do not trigger further e-mail notifications ; thus, I have to visit the thread through my browser to become aware of additional in-same-post content... FTR, below is a screenshot of your post the very first time it went live, as it appeared inside my e-mail client: That e-mail was received at 202303280017GMT; and I'm extremely lucky, dare I say , that Bing's cache has saved your initial post just two minutes after it went live, https://cc.bingj.com/cache.aspx?q=https%3a%2f%2fmsfn.org%2fboard%2ftopic%2f184051-my-browser-builds-part-4%2fpage%2f74&d=3263078889977&mkt=en-WW&setlang=en-US&w=ur8pG3tLReOOvMj2Ov9a9kvf_SOCrEvI and it indeed first appeared without an image attachment: "Case closed" for me ... As ever, best wishes!

... Well, I commented very shortly after your own post went "live" , then put the laptop to "Sleep" and went myself to bed ; when I first read your post and composed my own comment/reply to it, your post hadn't been edited yet, no screenshot had been attached at that time ...

... Did you remember to also toggle "dom.getRootNode.enabled" to "true"? These prefs are actually a "wedded couple", so to speak - if one is set to true, the other has to be set to true, too - and vice versa ... ... FWIW, both I and @UCyborg mentioned, here in this thread, it's not the case ; my own advice came after the recommendation issued by upstream not to simultaneously enable both (i.e. palefill+nativeWC): UCyborg (a "hobbyist" coder, BTW by profession ) later posted additional input: ... He specifically cites GitHub above, but palefill does also include code pertaining to VirusTotal, e.g.: https://github.com/martok/palefill/commit/657b2b1 https://github.com/martok/palefill/commit/6001e31 Kind regards

Thanks to extensive coding work carried out by upstream developer FranklinDM, "Web Components Slots" are now supported in UXP natively ; last Saturday's UXP-builds by Roy come with that support backported ; as such, now the "modern GUI" version of VirusTotal can be successfully rendered and used in NM28/St52 without disabling the native WC implementation and without excessive CPU consumption (YMMV, here it was OK ) : https://www.virustotal.com/gui/home/upload