VistaLover

In NM28 (32-bit) buildID=20230310122857, I toggled layout.css.report_errors (to true), then loaded: https://www.lner.co.uk/ and witnessed it not rendering properly (and that particular site was also mentioned in these forums in the past, but somewhere inside the 360EE subforums... ); opening Web Developer Tools => Web Console, I see it's flooded with below (CSS) warnings: Missing closing ‘)’ in negation pseudo-class ‘,’. Ruleset ignored due to bad selector in: https://d13w9pwhlf25to.cloudfront.net/dist/css/homepage.css?v=638199212840000000&cdnv=2727 Searching for that warning, the second entry Google returns is: https://github.com/less/less.js/issues/3021 i.e. the site in question uses a CSS selectors Level 4 feature (), ":not()" with a selector list, first implemented in Fx84 and Chr88 (hence the site doesn't render in any 360EE version ): https://caniuse.com/css-not-sel-list More about that feature below: https://developer.mozilla.org/en-US/docs/Web/CSS/:not Returning to the changelog between working & non-working NM28 builds, I'd say it's UXP #2137 : Modify :not() selector to accept a complex selector list - Issue #2137 - Part 1: Modify :not() selector to accept a complex selector list (82fa9fb80) - Issue #2137 - Part 2: Implement SelectorParsingFlags and use it to pass info around (3bb3c193d) - Issue #2137 - Part 3: Don't always use the internal pseudo-class for handling negations (b257a71cc) - Issue #2137 - Part 4: Fix namespace regression (ef36c5659) I hope this answers satisfactorily your original query ...

Thanks for your prompt reply and further actions ; it is rather unfortunate that "youtube-dl.exe", in contrast to "yt-dlp_x86.exe", doesn't provide any indication at all, when invoked in verbose ([debug]) mode, of the code snapshot it's been built from ... ... If I'm counting right , on top of yt-dl's master branch, your yt-dl compiles also include PRs #29318, #29581, #29593, #30998 , plus enabling of Lazy Extractors; am I missing anything else? ... Not system wide, i.e. in %PATH%; I usually place ffmpeg.exe+ffprobe.exe adjacent to youtube-dl.exe or specify their specific directory via the " --ffmpeg-location" command line (or config) option: [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['--ffmpeg-location', '.\\FFmpeg', '--external-downloader-args', '-v 8 -stats', '-v'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2023.05.25.19419 (single file build) [debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015 [debug] exe versions: ffmpeg n6.1-dev-804-N-110688-g1aeefc4, ffprobe n6.1-dev-804-N-110688-g1aeefc4, phantomjs 2.1.1, rtmpdump 2.4 [debug] Proxy map: {} Usage: youtube-dl [OPTIONS] URL [URL...]

Hi @nicolaasjan, I do hope you're well - RL issues prevent me from visiting MSFN as often as I used to ... Might I inquire what exact source code is your latest youtube-dl.exe offering (linked in your forum signature) built on? The binary's version states May 21st: youtube-dl -v => [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-v'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2023.05.21 [debug] Lazy loading extractors enabled [debug] Python 3.4.4 (CPython 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.0.2d 9 Jul 2015, -) [debug] exe versions: none [debug] Proxy map: {} Usage: youtube-dl [OPTIONS] URL [URL...] youtube-dl: error: You must provide at least one URL. Type youtube-dl --help to see a list of all options. ... whereas yt-dl's master repo is currently at commit d1c6c5c from May 11th ... Many thanks for any insight ...

... Just a small FYI: St52 (unlike official Basilisk) has kept Fx52-level WebExtension support, so a WE Mozilla "theme" (a "persona" in WE format) will actually install (and appear inside "Extensions", not "Themes"), but will not visually apply...

TL;DR: a) Roll back to a previous firmware, b) use a Chromium-based browser to access your Fritz!Box's GUI, c) change your router's model... https://forum.palemoon.org/viewtopic.php?f=70&t=28995 https://github.com/martok/palefill/issues/83

Apologies I'm not participating in this discussion as much as I would've hoped ; dealing with solicitors/lawyers/civil servants/government employees/etc. over inheritance issues in RL currently, all that "torture" sucks the life (and serious money) out of you and, consequently, spare time to devote on internet forums... In the background, I've been doing my own research, too ... ... Oh yes, the drawbacks of on-line/web installers and the very reason I detest them vehemently ; they become worthless when the stuff they're supposed to fetch vanishes into thin (digital) air ... I have several archived KFA19 web installers on a spare external HDD that were downloaded at the time the app was current (mid-2018 to mid-2019), which correspond to different localisations/Kaspersky patch levels (e.g [a.b], [a.b.c.d]); download links for these I now simply lost or (the ones I have bookmarked) return 404s... Kaspersky did publish a FULL offline installer (which, sadly, I haven't archived) for KFA2019 around its initial release, but soon they moved on to a web-installer-only scheme, a practice still kept for the subsequent KFA releases (kfa20, kfa21, targeting Win7SP1+; these two seem to have been remodeled, based on a newer "Cloud" engine/product: Kaspersky Security Cloud, KSC). Of those stub KFA2019 installers, one (kfa19.0.0.1088ab_en-gb_14833.exe) produced below message: I guess the same one @mina7601 encountered ... But another one (kfa19.0.0.1088abcd_en-US_fr-CA_es-US.exe) ended up with a different message: however, that was a misleading error ; unable to retrieve the now missing files for KFA19, it proceeded to download a web installer of KFA20 (v20.0.14.1085.0.6449.0), which, when executed, threw the error about the incompatible OS - all this was found out via inspecting the log file generated inside %TEMP% ... A third stub installer (kfa19.0.0.1088a_en-gb_14166.exe) produced, yet again, a different error: In that last case (resolved by inspecting log files), the stub installer proceeded to fetch a second stub installer of KFA21 (v21.3.10.391.0.2008) which, predictably, failed to install.. My research has also unearthed a 2018 malwaretips post, in which it was documented that the KFA2019 web installers of the era (for en-GB locale) would actually download below list of files/archives: KFA 2019: http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/corebases.cab http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/corebasesx64.cab http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/corebasesx86.cab http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/instx64.z http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/instx86.z http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/productbases.cab http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/common.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/coreproductnogdpr.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/coreproductgdpr.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/coreproduct.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/coreproductx64.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/eula_en-gb.txt http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/ipm.cab http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/ksde_ksn_en-gb.txt http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/product.cab.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/product.msi.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/rdp_en-gb.txt http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/startup.exe http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/x64.cab.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/ztuu.z http://dm.kaspersky-labs.com/kleaner/InteractiveNew/Global/kleaner.cab The "http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/*" dir appears to be still alive today, as well as access to last archive kleaner.cab, but, as already posted by others, dir "http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/*" has been now purged ... Some savvy people had concocted self-made "full" (off-line) installers at the time, based on lists similar to the above; I myself have an archived "RePack" which I won't share, because it's only in the Russian locale and made by, well, a Russian repacker (LcHNextGen) of that era... I haven't yet tested Astroskipper's repacked RePack (), hopefully we'll soon hear results from mina7601 (many thanks BTW ) ... It might not be the case after all ... During my research, I found some posts inside the nsaneforums forum (due to the "dubious" nature of said site, I won't provide exact links), an installation scenario might involve the following procedure: 1. Download the off-line installer for KIS2019 (Kaspersky Internet Security): https://arc-products.s.kaspersky-labs.com/homeuser/kis2019/19.0.0.1088abcd/english-INT-0.5887.0/3137353438307c44454c7c35/KIS19.0.0.1088_en_full.exe 2. Install the application as required (decline any offers to install newer versions; no other AV suite should be present, all H/W and S/W requirements for KIS2019 should have been observed/applied). 3. After the necessary OS restarts post initial install, try (for good measure) to update the Virus Definitions - you can only do so once without a valid licence; the app may or may not be activated now with a trial (30d) licence, this is at Kaspersky's discretion - if you do get a trial licence, you may continue to use the product fully until the trial ends - else (or after the trial expires): 4. Proceed to uninstall the application; if my "sources" were correct, one of the options offered during uninstall is to "turn the application into Kaspersky Free 2019"; if you select that, upon OS restart you'll end up with a KFA2019 installation; if you don't now have a 365d worth "free" key, you should first create a "My Kaspersky Account" to then get one (YMMV - my sources are from 2019 ) ...

... Thanks for that kind offer ; unfortunately, my memory betrays me these days. ... I've managed to locate a certain post by @Vistapocalypse where he, in fact, makes a mention of what I've spoken about, however I was not successful at locating those exact reports... Kaspersky themselves no longer offer downloads for KFA2019 (Kaspersky Free Antivirus 2019, aka Kaspersky Antivirus Free (KAF) 2019 or just 19), but "neowin" have archived a stub (web/on-line) installer for it: https://products.s.kaspersky-labs.com/homeuser/kfa2019/19.0.0.1088/english-gb-0.57.0/kfa19.0.0.1088en_14173.exe Since mina7601 keeps a Vista SP2 VM, perhaps an attempt to install it there could be made? For best results, that VM should be first updated all the way to Vista's EoL, plus select WS2008 updates enabling SHA-2 signature support should also be installed; additionally, KFA2019 requires .NET FW 4.x.x installed; for NT6.0, Microsoft have last year produced a 4.6.2 installer that works out-of-the-box (whereas in the past, only 4.6.1 would work) ... All this talk is, of course, OT for this (XP) thread , but since an offer was made to clarify things once and for all, why not accept it? Perhaps even attempt an installation of KFA19 on a fully updated XP SP3 system (with .NET FW 4.0.3) while one's at it?

... Well, according to below support article, last reviewed on Aug 13, 2019, min WinOS version targeting KAV19 is Windows 7 Starter SP0 : https://support.kaspersky.com/KAV/2019/en-US/43520.htm It's totally unknown to me whether KAV19 could be installed on Vista SP2 (let alone on XP SP3) 32-bit, provided all the rest software/hardware requirements were met (and there were several ) ; still, I have a very faint recollection of someone posting back then in the Vista subforums, claiming to be running KAF19 (Kaspersky Antivirus Free 19) under Vista (but NOT XP!), but am too tired now to search for that post, sorry ...

Indeed, the provided link: https://dl.dropboxusercontent.com/s/77c6ftwujel4v7l/yt-dlp_x86_Windows-XP.zip isn't valid ; obviously, something must've gone awry there... Try below links, which I have archived locally (and it turns out it was a good idea to do so ): https://dl.dropboxusercontent.com/s/f2q5v92qgq0fawp/youtube-dl.zip https://dl.dropboxusercontent.com/s/xmrpypozf7wf9us/youtube-dl_20230430.zip The second link will fetch a yt-dl build with (experimental) "Lazy Extractors" support turned ON, specifically for older H/W; you should definitely try it (both links were provided initially by nicolaas, the second one via his GitHub account) !

... People ... Do you know the Bible quote: "seek, and ye shall find" ? With some perseverance (which always pays out, mind you ) and my mediocre searchengine-fu, it took me less than 10min to locate an official (by AVG) direct download link to the XP_EoS offline installer of AVG Free Antivirus product: https://install.avcdn.net/avg/iavs9x-xp/avg_antivirus_free_setup_offline.exe This fetches a 292MiB sized file, which has been dual-signed (sha1 file sig compatible with XP and sha256 sig compatible with Vista/WS2008 SP2 and later) on Nov 15th 2018:

... Well, "Dwm" stands for Desktop Window Manager, and that one is only present on Vista+...

Thanks for your investigation ; https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields#browser_compatibility says that this JS syntax feature has been implemented in Chr72+/Fx69+ (so, a long time ago ); "upstream" now have an open UXP issue about it, opened just 2 months ago by @martok (the maintainer of palefill): https://repo.palemoon.org/MoonchildProductions/UXP/issues/2142 This is being worked on currently, so, fingers crossed, "we" may see a positive outcome/resolution soon-ish ... Slightly OT: I was puzzled by the fact my 360EEv11 copy, Chr69-based, was able to display images inside https://www.winhelponline.com/blog/disable-full-row-select-explorer-windows-7/ since the "feature" was only implemented as of Chr72, but then I realised I had, since long ago, enabled the "Experimental JavaScript" flag in that build (chrome://flags/#enable-javascript-harmony); mystery solved, as that flag enables a "draft" version of public class fields already in Chr69!

... Still, someone on XP will have to verify whether v7.4.2 does launch there (and was hoping you'd be the one ...) ; and just because it did download the 2022-10-10.1 (cloud) database in my Vista SP2 32-bit machine, it doesn't necessarily mean it will do so under XP; AFAICT, the app uses Windows' native APIs to connect to its (cloud) server; my Vista OS has WS2008 updates installed, which gave it TLS v1.1+v1.2 support, plus associated cipher suites that are not present even in a POSReady updated XP machine... As always, "the proof is in the pudding" ...

This article below by MB: https://support.malwarebytes.com/hc/en-us/articles/360039579393-Windows-XP-and-Vista-compatibility-with-Malwarebytes-AdwCleaner hints that "Versions before 8.0 may still work on a Windows XP", emphasis (mine ) put on "may"... FWIW, I have local records kept that indicate that the XP_EoS version of Malwarebytes AdwCleaner is/was v6.047 : There doesn't exist a GUI button to update the "database", only an "option" to use the "local" or the "server" one: I did perform a quick scan with the default setting of "server"; I had to open the log file to, sadly, find out that only the extremely outdated "local" database was used for the scan: # AdwCleaner v6.047 - Logfile created 26/04/2023 at 00:25:03 # Updated on 19/05/2017 by Malwarebytes # Database : 2017-05-19.1 [Local] # Operating System : Windows Vista (TM) Home Premium Service Pack 2 (X86) # Username : (redacted) # Running from : (redacted)\adwcleaner_6.047[XPEOL].exe # Mode: Scan # Support : https://www.malwarebytes.com/support I don't have an XP machine available currently to check whether v7.4.2 does, indeed, launch there ; that version does launch under Vista SP2 x86 - incidentally, it offers to update the app to v8.4.0, but that offer should be declined, as (consistent with the article I linked above) that one doesn't launch under Vista (so why offer it in the first place? ) ... Like its predecessor, v7.4.2 has a default setting of "Automatically using the cloud database if available": I performed a second scan with v7.4.2, its log file now reads that it used a "database" from Oct 10th 2022, i.e. a stale one from 6 1/2 months ago (!) : # ------------------------------- # Malwarebytes AdwCleaner 7.4.2.0 # ------------------------------- # Build: 10-21-2019 # Database: 2022-10-10.1 (Cloud) # Support: https://www.malwarebytes.com/support # # ------------------------------- # Mode: Scan # ------------------------------- # Start: 04-26-2023 # Duration: 00:00:35 # OS: Windows Vista (TM) Home Premium # Scanned: 32074 So, I don't know what to make of that , certainly can't answer whether that is considered as "definitions still provided for it" ; "use at your own risk" would be my advice ...

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