Leaderboard

1) Last fix mainly for x64, for W2003 and W2003/XP x64 we still don't have SP2 correct headers, so pre-v8 is far to be even "beta" I will update topic to include fix only for x32 XP 2) Assertion Fail on loaddsdt.c, line 488 for x64 builds (v8 update) This is x64 fix for semi-broken VirtualBox's ACPI BIOS tables, real systems don't have this problem

Have you tried this - https://github.com/JustOff/password-backup-tool

AstroSkipper, I agree with you 100% ! I'd also add simple mechanical failures due to the dried out motor bearings lubricant ! And/or dust inside (yes, dust inside of newly-made japs-made Toshiba/Hitachi) , jaclaz may just be too young to remember the DeathStar HDD from Toshiba, so let's not get too hard on him ... https://en.wikipedia.org/wiki/Deskstar

Unfortunately, you are wrong. There are indeed physical reasons for losing data. I'll give you a hint. It's called magnetism when it comes to HDDs. But even for SSDs, there are physical processes that can lead to data loss. Here is a German article to bring you a little closer to the subject: https://www.computerwoche.de/a/der-langsame-tod-von-festplatten-und-ssds,3549906 Use a translator if German is not one of your languages! Anyway! @UCyborg's concerns are fully justified and understandable. AstroSkipper

Yep, that's what I said. For transferring all passwords on the same machine and system, the file cert8.db is not absolutely necessary. BTW, I use a Master Password in my old, main NM profile, though. And the file cert9.db still exists, too.

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

This whole stuff: 1) makes no sense whatsoever 2) should it make sense in some very specific, niche situation, we don't have any meaningful, valid, data to support the method, let alone the frequency at which it should be implemented If you feel good refreshing your data, do it. If you feel good refreshing your data every year, do it every year, if you feel good doing it every 2-3 years, do it every 2-3 years. You will anyway lose some data before or later (or possibly you will never lose any) but there is no way to know in advance nor any way to know whether this strategy contributed in any meaningful way to the outcome (whatever that happens to be). Replicating data (having multiple copies, on different media and stored in different location) is an effective strategy, though it is difficult to implement, let alone maintain over the years. The only thing that promised (but has to be seen if they delivered) long enough data retention were (are?) M-DISCs: https://en.wikipedia.org/wiki/M-DISC jaclaz

I did have one crash, but couldn't reproduce it...other than that, the latest NM28 is working absolutely fine in XP SP3 x86 for me. Not sure if it correlates to the 'RegExpShared' issue, and I'm sorry if I can't be more helpful here, but in any event I want to thank Roy as always for his continued efforts...and all my best to everyone here, always.

Okay! No separate dom.getRootNode.enabled preference anymore! Sometimes, it is really a good idea to read the official UXP changes.

https://text-compare.com/ broke recently due to detroitchicago scripts, like the ones on https://www.winhelponline.com/. Updated palefill-1.26.2.xpi. Needs support for defining static stuff inside the class. Not sure if this is anywhere on the horizon at this time.

This line alone makes me want to NOT do the like! Why are so many MSFN Members so glued to that d@mn "like"? This is not a social media web site. Or did I just fall prey to the oldest trick in the book - "reverse psychology"?

With limited testing on v112.3.4.3, the only time I witness any odd connections is when "secure DNS" is enabled - making me NOT TRUST this so-called "secure" DNS. It is better to set up your Operating System to use "secure DNS" than it is to rely on any web browser to perform that task for you, once that is "embedded" into the web browser, it can make ANY connection it wants to! There are some embedded "always accept cookies" web sites but I've not seen them create cookies so long as you do not visit those web sites. The embedded list is easily removable in chrome.dll - but I'm left with an "empty" web site instead of a none-added note, so still investigating.

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20230415-de147fa3-uxp-75bef7b73-xpmod.7z BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20230415-de147fa3-uxp-75bef7b73-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/boc-uxp/tree/custom * Notice: the profile prefix (i.e. parent folder names) are also changed since 2020-08-15 build, you may rename their names before using new binaries when updating from builds before 2020-08-15. -- New build of HBL-UXP for XP! Test binary: IceDove-UXP(mail) https://o.rthost.win/hbl-uxp/icedove.win32-20230415-id-656ea98-uxp-75bef7b73-xpmod.7z IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20230415-id-656ea98-ia-93af9a0-uxp-75bef7b73-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/icedove-uxp/tree/winbuild https://github.com/roytam1/iceape-uxp/tree/winbuild for UXP changes please see above.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20230415-3219d2d-uxp-75bef7b73-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20230415-3219d2d-uxp-75bef7b73-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20230415-3219d2d-uxp-75bef7b73-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.6a1.win32-git-20230415-d849524bd-uxp-75bef7b73-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.6a1.win32-git-20230415-d849524bd-uxp-75bef7b73-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.6a1.win32-git-20230415-d849524bd-uxp-75bef7b73-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.6a1.win64-git-20230415-d849524bd-uxp-75bef7b73-xpmod.7z Official UXP changes picked since my last build: - Issue #1361 - Follow-up: Merge dom.getRootNode.enabled pref into dom.webcomponents.enabled. (8182d08b1) - Issue #252 - Move getElementsByName from HTMLDocument to Document (b2d750411) - Issue #252 - Follow-up: Include a null check against mDocument (7c759b2c2) - Issue #2197 - Part 1a: postMessages should have transferable as [] by default (438cdbd91) - Issue #2197 - Part 1b: Transferables should be arrays of objects (47147d58b) - Issue #2197 - Part 2a: Implement StructuredSerializeOptions for MessagePort (fd982fd29) - Issue #2197 - Part 2b: Implement StructuredSerializeOptions for Worker (158784cbe) - Issue #2197 - Part 2c: Implement StructuredSerializeOptions for ServiceWorker (4d58139fe) - Issue #2197 - Part 2d: Implement PostMessageOptions for Window (4174037d8) - Issue #2197 - Part 3: Implement self.structuredClone() (ef6b8db1d) - Issue #2197 - Part 4: Expose structuredClone in Sandbox (bbcfb6275) - Issue #2197 - Follow-up: Remove GC debug assertion on sandbox (8e6d73046) - Issue #595 - Implement window.event (31283d993) - Issue #2053 - Part 1: Performance should be an EventTarget (995f3117b) - Issue #2053 - Part 2: Update PerformanceMeasure to User Timing L3 (23519e0c2) - Issue #2053 - Part 3: Update PerformanceMark to User Timing L3 (3b57ba141) - Issue #2053 - Part 4a: Align IsPerformanceTimingAttribute to user-timing spec (4fc9cde7c) - Issue #2053 - Part 4b: Fix measure name to timestamp conversion (a0d52c009) - Issue #2053 - Part 5: Throw a DOMException instead of a JS exception for some errors (ef8e3b541) - Issue #2053 - Follow-up: Make the default ResourceTimingBufferSize larger (7823439b1) - Issue #2053 - Follow-up: Re-enable navigation timing now it's to-spec. (e51a63852) - Use nsAnonymousTemporaryFile for clipboard cache (42723b163) - Increase size of data over which we write the data to disk rather than keep it around in memory (af613ef24) - [network] Improve checks while parsing MIME parameters. (c9d961633) - [devtools] Don't allow sourcemap URLs to redirect (47bcca168) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes since my last build: - Issue UXP#2053: fix deprots (5a74c0114) - mailnews: follow-up rev c9d96163, fix build (6beccbf6c) - Bug 1159003 - setResourceTimingBufferSize shouldn't affect user timing, but we should clean user markers if we have memory pressure, r=bz (bc3eb89de) - Bug 1159003 - Remove Performance::GetAsISupports(), r=bz (16a1923c3) - Bug 1378537 - Store PerformanceEntry objects in AutoTArray; r=smaug (75bef7b73) Update Notice: - You may delete file named icudt*.dat inside program folder when updating from old releases. * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

You naughty data-hoarder

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

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