VistaLover

As always, thank you for the fixes you post here ; what I want to ask is, are you using a "one-size-fits-all" polyfill for "winhelponline.com", "text-compare.com" and "przedszkolowo.pl" (to fix "static") or does each one of them require specific code? If the former, would you be so kind as to post that standalone polyfill? I tend now to leave Palefill disabled in St52 and would much rather use a "userscript" implementation of your "static" polyfill, much like in the case of your "structuredClone()" one ... Thanks in advance

I can easily reproduce in my (latest) St52 (32-bit) copy here ; on ebay.de, crazy CPU consumption lessens somewhat if I "pause" the main/centre "carousel"; but commerzbank.de will fry both my CPU cores at a constant rate of 97-100% ; after a short while, the whole, single-process, browser becomes unresponsive and has to be killed via Task Manager (and upon relaunch, you are "greeted" with the "session restore" message, if you have that enabled...); their whole web design is dire BTW , endlessly-scrolling with embedded videos in between, typical of the web design of the era that mainly targets handheld mobile devices with vertical screens ...

I'm pretty certain this "term" has been mentioned and explained numerous times over the course of time in "these" threads... When upstream (MCP) had to finally move away from the Tycho application platform (fork of Mozilla 38esr) Pale Moon 27 was built on, "they" first opted to rebase their platform on a Mozilla 53.0a1 (Nightly) code snapshot, with few bits here and there from 54.0 & 55.0; that "experimental" platform was given the codename "moebius" (aka UXP Take 1); the test browser application "they" built on top of it was baptised Basilisk; the original Basilisk was given an appVersion of 55.0.0 for purely "sensationalistic" reasons, as it had very little to do with Fx55, codewise... Roy's fork of that one was, of course, Serpent 55.0.0 ... After a while, "upstream" discovered (the hard way) that this experimental platform they called moebius was not good for their intent and purposes (i.e. build Pale Moon 28 on top of it), so they ditched it altogether and started from scratch on developing a second platform candidate, that one forked from Mozilla 52.6.0esr; the result of those efforts is UXP (Take 2), the test browser application built on top of it was, again, Basilisk (but this time its version had the "52.9.year.month.day" format) - Pale Moon (in its v28) was successfully migrated from Tycho to UXP, where it continues to build on now; MCP had said back then that it's impossible for them to rebase PM's platform to a Mozilla platform > 52.x.x, but who knows what the future will "dictate" ... When MCP moved away from MS's GitHub (because it stopped being compatible with the browser they were developing - and MS had no intention of keeping backwards compatibility with "legacy" browser engines ), MCP removed completely the moebius source code from there; but Roy had kept a fork of it, which he continued to sporadically maintain, with code fetched from other "upstream"; he would then post monthly builds of Serpent55/moebius... In more recent times (thanks to additional spare time due to pandemic lock-downs ), an effort was undertaken to bring the "old" moebius platform "closer" to the UXP platform currently developed by MCP and the release cycle has become weekly... I occasionally test St55, but I am a St52 "person" myself... St55 has slightly better Web Extension support (inherited from Fx53.0a1), slightly better Tab Containers support, probably (slightly) better e10s support and a better GUI for its standalone media player; all of these "features" are there on a "use-at-your-own-risk" state, because no-one maintains those aspects of St55 code... And its JS engine isn't 100% on par with UXP's, still... But whatever anyone prefers ...

Does the one hosted on AMO not work for you? https://addons.mozilla.org/en-US/firefox/addon/saveasebook/versions/ It does install in latest St52, but haven't tested its proper function there ... ... Which files? From a quick look, one should only pack to ZIP(=>.xpi) the contents of: https://github.com/alexadam/save-as-ebook/tree/master/web-extension

... The last version of which is v1.70, from 2020... The app is tailored to work best with official Mozilla Firefox, properly installed in the system... For XP x86, you obviously need to DL the 32-bit flavour - localization file needs to be separately downloaded/extracted and placed alongside the main executable... Once launched, don't fear if the window ends up being empty : Top Menu => File => Select Folders => Profile Folder Path: ... and paste there the full (absolute) path to the browser profile directory holding the account credentials you wish to extract/back-up; as you might have figured out already, the app also works for "portable" browser installations! FTR, just used it on latest St52 (32-bit), so it definitely works on UXP-based browsers ...

Just to add to this, that specific URL also loads successfully in Chr69-based 360EEv11, so the reason it doesn't do so under UXP (which I can't pinpoint now, sadly ) shouldn't be a recent "Googl-ism"... OTOH, https://przedszkolowo.pl/ requires at least the Chr86-based 360EEv13 (v11/12 don't work, much like UXP) to load fully, so that one requires something "more recent" UXP should implement to handle it... The term "recent" is used tentatively here , because, sadly, Chromium-86 should no longer be considered "recent", WebCompat-wise ... Later addition: The "why" it doesn't work was posted below: Needs support for defining static stuff inside the class What perplexes me a bit is that the linked MDN article mentions, under Browser compatibility, that "static" was implemented in Chr49/Fx45 ...

... This has been covered previously, but both "??" and "?." are operators and operators can not be polyfilled (what palefill strives to achieve with UXP-incompatible JS code), only transpiled... Palefill itself won't work fully/at all on sites that demand such operators, unless the application platform (UXP in this case) carries native support for said operators... UXP has had native support for "??" and "?." since many months ago: "?.": May 2022, "??": June 2022, the fact you can now use, e.g., GitHub without palefill is largely due to Web Components support (finally) landing...

... I've been wrong about file cert8.db, which seems to contain NSS security certificates; but I've always known that itself and key3.db file are interlinked (the same is true for key4.db+cert9.db used in recent Firefox versions). key3.db is indeed the file that stores the password decryption key in UXP-based browsers; logins.json is the one that stores the encryptred credentials (this format was first implemented in Fx32+, previously other formats/filenames were used: signons.txt, signons2.txt, signons3.txt, signons.sqlite; all these, plus logins.json, require key3.db to work). https://support.mozilla.org/en-US/questions/1210914 I've never used one myself, but it's the implementation of a Master Password by the user that will make it impossible to transfer stored account credentials to a different machine... http://kb.mozillazine.org/Master_password As for key4.db, I'm adamant it's NOT currently used in UXP-based browsers; my dirty St52 profile does NOT contain it, my dirty St55 profile does NOT contain it, my semi-fresh NM28 profile does NOT contain it! As a further test, I just launched a pristine/fresh NM28 profile [version is 28.10.6a1 (32-bit) (2023-04-13)]; that fresh profile only contains a key3.db (& cert8.db) file, NO SIGN of a key4.db one... If I then store a single account there (e.g., my MSFN forum credentials), no sign, again, of a further key*.db file: Transferring just key3.db+logins.json from my St52 dirty profile to the NM28 "fresh" one was sufficient here to migrate all my accounts...

Although details about this procedure have been posted numerous times, let me refresh it once more: a) "my New Moon profile": Are we talking about NM27 or NM28? I'll assume it's NM28 the case here... b) In the "old"/existing installation of NM28: Launch the browser, then 1. Load "about:support" => Application Basics => Profile Folder => click "Open Folder" button A Windows Explorer window should open, displaying the contents of the currently used NM28 user profile. 2. Proceed to exit the browser, but do NOT close the profile dir window opened in previous step... 3. On a removable disk media (e.g. a USB stick), create an empty folder (the name of which is irrelevant, e.g. "oldNM28prof"), inside which you should copy and transfer ALL the contents of the profile dir "window" (of step 1) c) In the "new" machine (Win7 SP1 x86), you should have already installed the exact same NM28 version present initially in the XP SP3 x86 machine - slightly newer NM28 versions can be excused, as the profiles are forward compatible, but - in general - backward compatibility isn't guaranteed (i.e. transferring a profile touched by a newer version to an older browser version). 1. Launch just once NM28 in the Win7 machine, so as to allow the creation of a new profile there... 2. With a procedure similar to b1, locate and open the NM28 profile dir, then exit the browser (but, again, keep the profile window open) 3. In that open profile window, DELETE all the extant dirs+files, but continue to leave the window open. 4. Connect the USB stick in the Win7 machine, then open the folder (e.g. "oldNM28prof") with the saved contents of the old NM28 profile; select and COPY ALL the contents of that folder. 5. In the open window of step c3, PASTE ALL copied content in step c4. 6. You can now close all unwanted explorer windows, detach the USB stick and proceed to launch NM28 in the Win7 machine; if all was done correctly, then you should now have a "mirror" of the XP SP3 NM28 profile... Since the two machines are not identical hardware-wise (or are they?), some small differences are to be expected between old/new profiles inside about:config, but extensions (and their settings)/bookmarks/visited sites/download history/site account credentials, etc. should be identical... Actually, UXP-based browsers are no longer using the key4.db file; they did for some brief period, maybe two years ago, but the files associated with password storage are now cert8.db, key3.db and logins.json I routinely copy St52/NM28 whole profiles between my Vista SP2 x86 laptop and sister's Win7 SP1 x64 laptop and account credentials transfer fine between the two - I don't have an XP machine available currently, but I don't expect it to behave differently... I've stopped following Firefox's demise past version 52esr, so am not sure what they have later implemented with regards to profile migration between different machines ... What you described is indeed true for Chromium-based browsers like all 4 360EE variants known to this community, because password encryption/decryption is tied to the machine the password has been created on (to make matters worse , not even installed extensions of a 360EE profile are transferrable across different machines) ... Best regards

... That post has been already posted by @Humming Owl on the exact day (Mar 22nd) "his" builds were "updated": https://msfn.org/board/topic/182876-360-extreme-explorer-modified-version/?do=findComment&comment=1241679 BTW, I enclosed updated in quotation marks because, IIUC, nothing new web-compatibility-wise was introduced, instead some core DLLs were given the "rebase" treatment so as to reduce RAM consumption under Windows XP... So, respectfully, one concludes you must've missed that "notification" post you asked for ... Best Easter wishes

... Which I've already drawn attention to in my post of Apr 4th : BTW, could you possibly offer some help towards: Thanks in advance ... OT: Happy Easter Sunday to all those that observe it today (it's on Apr 16th in my parts ...).

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