All Activity

Using: basilisk52-g4.8.win32-git-20260117-3219d2d-uxp-aace8fa8c0-xpmod.7z Crash report: AppName: basilisk.exe AppVer: 4.8.7.8956 ModName: mozglue.dll ModVer: 4.8.7.8956 Offset: 0000fba6 After several crashes while using eBay I've gone back to: basilisk52-g4.8.win32-git-20260110-3219d2d-uxp-3e9ca11775-xpmod.7z Ben.

Quite. See here - a newly opened Serpent 52.9 2026.01.16 (latest): only went to majorgeeks.com and then to msfn.org Forum and basilisk.exe in TaskManager is wildly going up and down 1 full CPU core usage and memory from 700MB to 1.5GB and back down to ~700 then CPU usage stops. First I noticed that also in my XP VM which I use to get me fresh prefs.js to compare with my normal one outside VM (all of 1.3GB of dedicated VM RAM went missing while on sapphiretech.com). Edit: in the before session imgur.com, there weren't any swings, just normal behaviour; RAM usage going up till ~1.2GB (even somewhat lower than with the previous version of 1.3GB). Edit2: Could it have something to do with: - htmlparser: break when infinite loop happens (8201dadf41) ? Edit3: On videocardz.com and again on msfn.org (new session after videocardz crash) Serpent crashed with stated mozjs.dll as the point of breaking. Faulting application basilisk.exe, version 4.8.7.8956, faulting module mozjs.dll, version 0.0.0.0, fault address 0x00293c73. Both times.

heard similar report on different websites but both of them are not reproducible here. EDIT: try translating in bing translator, and it does happen: > mozjs.dll!js::jit::BacktrackingAllocator::tryAllocateRegister(js::jit::BacktrackingAllocator::PhysicalRegister & r, js::jit::LiveBundle * bundle, bool * success, bool * pfixed, mozilla::Vector<js::jit::LiveBundle *,4,js::SystemAllocPolicy> & conflicting) Line 1395 C++ [Inline Frame] mozjs.dll!js::jit::BacktrackingAllocator::tryAllocateNonFixed(js::jit::LiveBundle *) Line 1221 C++ mozjs.dll!js::jit::BacktrackingAllocator::processBundle(js::jit::MIRGenerator * mir, js::jit::LiveBundle * bundle) Line 1291 C++ mozjs.dll!js::jit::BacktrackingAllocator::go() Line 835 C++ mozjs.dll!js::jit::GenerateLIR(js::jit::MIRGenerator * mir) Line 1928 C++ mozjs.dll!js::jit::CompileBackEnd(js::jit::MIRGenerator * mir) Line 1998 C++ mozjs.dll!js::HelperThread::handleIonWorkload(js::AutoLockHelperThreadState & locked) Line 1554 C++ mozjs.dll!js::HelperThread::threadLoop() Line 1918 C++ [Inline Frame] mozjs.dll!js::detail::ThreadTrampoline<void (__cdecl&)(void *),js::HelperThread *>::callMain(mozilla::IndexSequence<0>) Line 233 C++ mozjs.dll!js::detail::ThreadTrampoline<void (__cdecl&)(void *),js::HelperThread *>::Start(void * aPack) Line 227 C++ but javascript related changes only happened in https://repo.palemoon.org/MoonchildProductions/UXP/issues/2895 which doesn't look like what shows in malloc-trace shown above. and when memory usage is high (but not too high to be crashed), about:memory shows high heap-unclassified and later it gets reclaimed. hmm, so strange. EDIT2: another one to be suspected is expat library update: https://repo.palemoon.org/MoonchildProductions/UXP/issues/2889

Failed for me. If i visit https://www.bing.com/translator or click some internal links on rutracker.org - new moon make me "hdd stress test" and fill ram up to 2GB. I'm return to previous palemoon-28.10.7a1.win32-git-20260110-d849524bd-uxp-3e9ca11775-xpmod.7z

Still going STRONG! thx Steve!

Aliasing https://en.wikipedia.org/wiki/Aliasing

The background images are all JPG files and already locally stored while installation.

And without veering too far into OT Land, the install of v23 on XP, which technically was only a stub to download and install v22, that stub downloaded four or five PNG files in addition to the EXE installer. Only the PNG files/connections were logged in HTTPSProxy, not the EXE. I find this interesting because AstroSkipper's installation (one of two partitions) is missing the wallpaper images (which I have not looked into but I have to wonder if they are PNGs). ie, the PNGs came from a server that needed to pass certificate chains but the EXE did not (ie, the offline/stub did originate from an HTTP address, not an HTTPS). ie, Panda's installation communications have http connections to pull in an EXE but have https connections to pull in PNGs. I would claim that Panda is doing that because it makes it VERY EASY to log every IP Address that requested the EXE. Server logs for the website (https) and PNGs (https) would be a MILE LONG. Server logs for the EXE would only fill one 8-1/2 x 11 per day or week.

That would certainly make sense and explain things. Version 21 presumably uses IE's proxy settings, and version 22 (and presumably 23) do not, which is why I had to manually set version 22 to use the proxy to get access to my account in its interface.

I have. Before browser "forks" came along, browser "shells" were common (Sleipnir, MyIE2, Maxthon, SlimBrowser, GreenBrowser). They all used the IE "engine" and "iexplore.exe" could be prevented from launch or network access by way of firewall rules but the "shell" would still have access through IE's "proxy". The earlier versions of Panda are basically acting as a "shell" to the Internet Explorer (and/or Edge) "engine". The question that this begs is can Panda be activated on systems where firewall rules wholly and completely block IE/Edge (not only the browser but the "engine" also)? ie, did the activation throw a firewall nag? or did it just "connect" because there was already a firewall rule "allowing" IE/Edge?

Agreed. The earlier versions of Panda seem to use INTERNET EXPLORER's proxy settings (which you proxified when setting the proxy to run "system-wide").

It seems so. I've never had a scenario like this before. But one thing is clear. Panda must have used the proxy connection. No chance without it.

That's right, but does Panda Dome therefore use the proxy even if its proxy settings aren't set up to do so? And there were no Panda server accesses recorded in the proxy console.

when you were running the proxy system-wide in the background. Right? On both of my Windows XP partitions, Panda Dome was definitively not able to activate the account without ProxHTTPSProxy. Neither for version 21.01.00, 20.02.01 nor 18.07.04.

Thank you very much, sir.

New build of post-deprecated Serpent/moebius for XP! * Notice: This repo will not be built on regular schedule, and changes are experimental as usual. ** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions. Test binary: Win32 https://o.rthost.win/basilisk/basilisk55-win32-git-20260117-aa5eeba9b-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk55-win64-git-20260117-aa5eeba9b-xpmod.7z repo: https://github.com/roytam1/basilisk55 Repo changes: - ported from UXP: Issue #1636 - Part 1 - Decouple Gio from GConf and always build it with GTK (fc78eec9) (522108f71) - ported from UXP: Issue #1636 - Part 2 - Disable Gconf by default (990f2568) (cb5b1cf63) - ported from UXP: Issue #1636 - Part 3 - Remove Gconf (b04e3d93) (c7c7666f8) - import from UXP: - Issue #2895 - Part 1: Replace XorShift128+ with Xoroshiro128++ (d4341ea0) - Issue #2895 - Follow-up: Fix JIT code generator for 32-bit targets. (d6e9c4d8) - Issue #2895 - Part 1b: Update license block. (d23afa84) - Issue #2895 - Part 2: Remove incorrect debug asserts. (5a0f1901) - Issue #2895 - Part 3: Add manual test. (75ec48bc) (1ba1395ca) - import from UXP: - Issue #2889 - Part 0: Relocate Mozilla-specific files from Expat source. (b81b97ee) - Issue #2889 - Part 1: Prepare Mozilla's changes and extensions for Expat 2.6.4. (95676016) - Issue #2889 - Part 2: Import Expat 2.6.4 source. (9ade98b4) - Issue #2889 - Part 3: Apply Mozilla's patches to Expat 2.6.4. (0b9e221b) - Issue #2889 - Part 4: Fix build and runtime issues. (a2f8e661) - Issue #2889 - Follow-up: Avoid conflicts with system version of libexpat (e0f8acdd) - Issue #2889 - Follow-up: void methods shouldn't return a value. (8956c611) - Issue #2889 - Part 5: Rewrite patches for Expat 2.7.3. (a730f838) - Issue #2889 - Part 6: Import Expat 2.7.3 source. (d2acec73) - Issue #2889 - Part 7: Apply patches to Expat 2.7.3. (ca2ef518) - Issue #2889 - Follow-up: Allow generate_hash_secret_salt to be used. (acefed74) - Issue #2889 - Follow-up: Adjust Expat 2.7.3 local patches for removal of 3rd patch. (034eeaff) - Issue #2889 - Follow-up: Remove fix for BZ 569229. (493169e2) (ee15f2005) - application: remove gio from MOZ_EXTENSIONS_DEFAULT (d7440fac8) - htmlparser: break when infinite loop happens (c016f9cc6) - import from UXP: [gfx] Be more explicit when converting to cairo formats. (f6d18c7d) (7094d3f22) - import from UXP: [gfx] Use better types for cairo image surface manipulations. (6ca8cf78) (efc7747c2) - import from UXP: [DOM] Check worker script size (d8f72029) (a480b4db2) - import from UXP: [Auth] Only set GSS_C_DELEG_FLAG flag when we confirm server supports delegation. (5321363a) (4149b3514) - import from UXP: [NSS] Update NSS (464b24c6) (3381dabad) - import from UXP: [XPCOM] Add hashkey helper classes for future use. (7b9eda3f) (c627d5f28) - import from UXP: [gfx] Add some additional sanity checks to cairo surface creation. (3aff60e4) (aa5eeba9b)

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20260117-40a79c75-uxp-aace8fa8c0-xpmod.7z BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20260117-40a79c75-uxp-aace8fa8c0-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-20260117-id-656ea98-uxp-aace8fa8c0-xpmod.7z IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20260117-id-656ea98-ia-c642e3c-uxp-aace8fa8c0-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/icedove-uxp/tree/winbuild https://github.com/roytam1/iceape-uxp/tree/winbuild

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260117-3219d2d-uxp-aace8fa8c0-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260117-3219d2d-uxp-aace8fa8c0-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-20260117-3219d2d-uxp-aace8fa8c0-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.7a1.win32-git-20260117-d849524bd-uxp-aace8fa8c0-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260117-d849524bd-uxp-aace8fa8c0-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260117-d849524bd-uxp-aace8fa8c0-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260117-d849524bd-uxp-aace8fa8c0-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260117-d849524bd-uxp-aace8fa8c0-w7plus-avx2.7z Official UXP changes picked since my last build: - Issue #1636 - Part 1 - Decouple Gio from GConf and always build it with GTK (fc78eec911) - Issue #1636 - Part 2 - Disable Gconf by default (990f256885) - Issue #1636 - Part 3 - Remove Gconf (b04e3d93c9) - Issue #2895 - Part 1: Replace XorShift128+ with Xoroshiro128++ (d4341ea07a) - Issue #2895 - Part 1b: Update license block. (d23afa84e5) - Issue #2895 - Part 2: Remove incorrect debug asserts. (5a0f190104) - Issue #2895 - Part 3: Add manual test. (75ec48bc41) - Issue #2889 - Part 0: Relocate Mozilla-specific files from Expat source. (b81b97ee47) - Issue #2889 - Part 1: Prepare Mozilla's changes and extensions for Expat 2.6.4. (9567601675) - Issue #2889 - Part 2: Import Expat 2.6.4 source. (9ade98b4fc) - Issue #2889 - Part 3: Apply Mozilla's patches to Expat 2.6.4. (0b9e221b14) - Issue #2889 - Part 4: Fix build and runtime issues. (a2f8e66162) - Issue #2889 - Follow-up: Avoid conflicts with system version of libexpat (e0f8acddc7) - Issue #2889 - Follow-up: void methods shouldn't return a value. (8956c61187) - Issue #2889 - Part 5: Rewrite patches for Expat 2.7.3. (a730f838c8) - Issue #2889 - Part 6: Import Expat 2.7.3 source. (d2acec73f7) - Issue #2889 - Part 7: Apply patches to Expat 2.7.3. (ca2ef5184a) - Issue #2889 - Follow-up: Allow generate_hash_secret_salt to be used. (acefed74fe) - Issue #2889 - Follow-up: Adjust Expat 2.7.3 local patches for removal of 3rd patch. (034eeaff97) - Issue #2889 - Follow-up: Remove fix for BZ 569229. (493169e227) - Issue #2895 - Follow-up: Fix JIT code generator for 32-bit targets. (d6e9c4d85b) - [gfx] Be more explicit when converting to cairo formats. (f6d18c7d78) - [gfx] Use better types for cairo image surface manipulations. (6ca8cf782b) - [DOM] Check worker script size (d8f7202951) - [Auth] Only set GSS_C_DELEG_FLAG flag when we confirm server supports delegation. (5321363a1b) - [NSS] Update NSS (464b24c608) - [XPCOM] Add hashkey helper classes for future use. (7b9eda3f69) - [gfx] Add some additional sanity checks to cairo surface creation. (3aff60e443) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - application: remove gio from MOZ_EXTENSIONS_DEFAULT (69c17afbe0) - htmlparser: break when infinite loop happens (8201dadf41) Update Notice: - You may delete file named icudt*.dat and icu63.dll 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.

https://github.com/e3kskoy7wqk/Firefox-for-windows-7/releases/tag/149.0a1 Run on W8.1

Okay, that explains it. I *never* use a REAL email address for these types of things. *NEVER* v23 would CONNECT (through HTTPSProxy) but then fail account creation saying the email account was unreachable. I tried EIGHT different "temporary email" services, Panda could not "reach" any of them. ie, has them all blacklisted, not uncommon [MSFN accounts can also not be created with temp emails, something that *ticks me off* but "is what it is"]). v21 would not even try to connect to the "temporary email" services [direct, no proxy] (which is inline with your statements). Just the way I do things, Panda will *NOT* get my email address. But I could create a "throwaway" Gmail and activate that way if I opt to keep Panda.

You must have misunderstood something. Panda only needs ProxHTTPSProxy to activate the Panda account. After that, the proxy settings in Panda can be deleted and the proxy closed.

I'm pretty sure that my Panda Dome 21 did activate without using HTTPSProxy, even though I have it installed, and it accessed my Panda account fine too. Version 22 again activated fine as a free version, and updated fine when my Essentials activation code was put in. The only thing it would not do until I put the proxy settings into it was access my Panda account, which 21 had done fine apparently without the proxy.

Here -> https://web.archive.org/web/*/www.microsoft.com/windows/downloads/bin/* But you will probably have to try the files and try from snapshots of different dates because it usually happens that not all files are archived well...

Here is a quotation from my main article: And I should add that it is very important to delete all dummy cerificates in the Certs folder when the cacert.pem file has been updated. And you won't lose anything. The dummy certificates will be generated the next time when connecting to servers. BTW, you are using the proxy system-wide. That was what I asked you in an earlier post. I personally do not.

I can't get it to ACTIVATE on 100% Native XP+POS. The ACTIVATION may be where HTTPSProxy becomes a must.