MyPal 68

[UCyborg]

1 hour ago, feodor2 said:

The question if this is such a good thing why mozilla do not apply this for the firefox?

Because it's irrelevant since Vista and ASLR enabled executables are a thing. The OS always picks random base address for ASLR enabled executables and is smart about it to not duplicate it in memory across multiple processes that share the same executable binaries.

[feodor2]

Uh didn't know that, if ASLR for vista+ then no point to care of enable.

[we3fan]

17 hours ago, feodor2 said:

rebase, I try next. The question if this is such a good thing why mozilla do not apply this for the firefox?

Hi feodor2, thanks for all your hard work with Mypal 68 and making browsing a better experience for everyone.

I don't know if the same applies for Mypal 68, but some users experienced crashes with rebased 360Chrome:
https://msfn.org/board/topic/182876-360-extreme-explorer-modified-version/?do=findComment&comment=1245550

Again, not sure if the same would apply for Mypal 68, but we also have report that rebased 360Chrome starts slower after reboot or hibernate:
https://msfn.org/board/topic/185049-arcticfoxienotheretoplaygames-360chrome-v1352044-rebuild-2/?do=findComment&comment=1254336
https://msfn.org/board/topic/184266-arcticfoxienotheretoplaygames-360chrome-v1351030-rebuild-7/?do=findComment&comment=1238407

In the case of rebased vs non-rebased, there will always be users who prefer non-rebased and users who prefer rebased.

If you want to give rebasing a try, I suggest to make 1 version rebased (we will see the feedback), and keep the other update versions at "default" (non-rebased) and maybe include additional info in the 'Readme' that the user can rebase if he wants to.
Of course this is only a suggestion and the final decision is yours.

Be safe and all the best.

[RamonUn]

I tried on Windows server 2003  the proposed rebase at address 0x6af00000. However at it does not change anything for me and the dll is still loaded at the same address (0x1240000), Is it just me? Anyway rebasing cannot really hurt anything. If Windows is unable to respect the preferred base it will determine some address that works so even if it does not benefit me it will at least benefit others and wont hurt anyone.

I tested 0x2000 0000 and it works fine for me. as there is a large gap  between mozglue.dll at 0x1000 0000 and hnetcfg.dll at 0x5F27 0000

I am not sure why this is the case but I thought it might be maybe more research can be done and a better value that fits everyone could be found.

Also there are other dlls that cannot get loaded at their base address of 0x1000 0000:

namely: freebl3.dll, freebl3.dll, nssckbi.dll,  nss3.dll, nssckbi.dlland softokn3.dll;

Again this in on my system.

[NotHereToPlayGames]

14 minutes ago, RamonUn said:

maybe more research can be done and a better value that fits everyone could be found

I went through this with 360Chrome.  It's unlikely that a value will be found that works for "everyone".

[UCyborg]

Regarding slower initial load, I think it happens when high address is used, memory mapping at higher addresses is slower.

[feodor2]

On 9/9/2024 at 11:00 AM, we3fan said:

I don't know if the same applies for Mypal 68, but some users experienced crashes with rebased 360Chrome:

So far it less crashes, because of less memory consumption, also otherwise no freeze after hibarnate

 

I selected other files values plain what would you say

freebl3.dll        14300000
lgpllibs.dll        8d0000
mozavcodec.dll        38000000
mozavutil.dll        30580000
nss3.dll        fe0000
nssckbi.dll        16f90000
softokn3.dll        12b80000

[AstroSkipper]

5 hours ago, feodor2 said:

I selected other files values plain what would you say

freebl3.dll        14300000
lgpllibs.dll        8d0000
mozavcodec.dll        38000000
mozavutil.dll        30580000
nss3.dll        fe0000
nssckbi.dll        16f90000
softokn3.dll        12b80000

Since I was the one who brought the rebasing of the xul.dll file from Mypal 68 into play and have been doing this for a long time, I would like to know what criteria you used to select the base addresses of the other DLL files.  I had suggested the following:

On 8/28/2024 at 8:06 PM, AstroSkipper said:

Rebasing is not a panacea. But I have had great experiences with rebasing the chrome.dll file in the 360Chrome browser. On my hardware, I was able to solve a BSOD problem caused by another programme and reduce the RAM memory consumption by more than half.  Whether rebasing is necessary or useful depends on how the corresponding DLL files are compiled. Keyword: ASLR. If a browser such as Mypal 68 consumes too much RAM, I always experiment with rebasing the main DLL file, in this case the xul.dll file. However, the base address of 0x6af00000 is a default address selected by the tool libase if this is not changed in its INI config file by the user. Here is the command line command for rebasing with the tool libase:

libase xul.dll

And here is the content of my libase.ini file:

[Generated bases]
62a00000=CHROME.DLL
6da00000=CHROME_CHILD.DLL
6af00000=XUL.DLL
63e00000=ICU63.DLL

For a DLL file in Windows, the default base address is 0x10000000 for 32-bit images. After a research in the internet, the most suitable address range for DLLs is from 0x60000000 through 0x6f000000. Microsoft proposes to reduce the range further to 0x60000000 through 0x68000000 in order to accommodate with MIPS processors, too. Another tool for rebasing is Microsoft's Rebase which is part of the Microsoft Windows SDK for Windows 7 and .NET Framework 4. Here is the command line command for rebasing with the tool Rebase::

rebase -b 0x6af00000 xul.dll

However, it is a game of trial and error to check, whether rebasing has an effect, and to find a suitable base address.  Experience to date has shown that Mypal 68 is stable and uses slightly less RAM when the xul.dll file has been rebased.  No crashes here. At least, on my hardware when using Mypal 68 in multiprocess mode.

The recommended and most suitable address range for DLL files is actually from 0x60000000 through 0x6f000000. Did you already test the additional rebasing of the other DLL files from Mypal 68? What kind of further positive effects did you observe then? 

Edited September 15, 2024 by AstroSkipper

[NotHereToPlayGames]

8 hours ago, AstroSkipper said:

Since I was the one who brought the rebasing of the xul.dll file from Mypal 68 into play and have been doing this for a long time

I brought it up way back here but only as a reference and that it was then and remains now of "no use to me".  Nobody took the bait until you jumped in, so thanks for that.  

For x64 (including XP) systems, rebasing always had TERRIBLE consequences on "cold-boot first-launch" browser load times.

[UCyborg]

I brought it up in the fist place in 360Chrome thread. Somehow long-term hardcore XP fans had no idea about it, but I, who had moved on from XP a long time ago, has. The irony.

24 minutes ago, NotHereToPlayGames said:

For x64 (including XP) systems, rebasing always had TERRIBLE consequences on "cold-boot first-launch" browser load times.

You're probably the odd one here considering that is super terrible compared to consequences during runtime.

[NotHereToPlayGames]

Agreed on both counts.  I did do a "site:msfn.org" search for when rebasing first came up, and by whom, I knew it was a VERY long time ago.

I did not find any "before and after" Mypal or New Moon reports, but the recent AstroSkipper post is the only one that actually performed the rebase.

I myself did not spend the time to rebase Mypal or New Moon.  I didn't search long enough to see if anybody actually did.

AstroSkipper caught feodor's attention, so that is a good thing for Mypal.

Yes, the cold-start versus RAM-saved is a trade off.  The slow and ancient pieces of sh#t that need to be concerned with RAM never have more than ONE tab open.

As mentioned in the past, we have only ourselves to blame when we think a 20yr old computer should be able to browse twenty tabs.

And same here, I've moved on from XP (for the most part) and Life has Improved by Leaps and Bounds.  I only had myself to blame for "sticking to my guns" and staying on XP for as long as I did.

But I do not run "stock" Win10 either!  Technically, I never ran "stock" XP as far as that goes.

[UCyborg]

47 minutes ago, NotHereToPlayGames said:

AstroSkipper caught feodor's attention, so that is a good thing for Mypal.

Yup.

47 minutes ago, NotHereToPlayGames said:

I myself did not spend the time to rebase Mypal or New Moon.  I didn't search long enough to see if anybody actually did.

I did, but going from memory, I only brought it up once casually with both browsers, in context of Mypal, I think I mentioned it along with a workaround with applying IgnoreException shim for another issue with Compatibility Administrator. But no one else was curious about these things so it was forgotten.

Time flies, must have been 3 or 4 years since when 360Chrome 13 was all the rage and people here were super excited to have a way to make it consume less RAM on XP!

Edited September 16, 2024 by UCyborg

[NotHereToPlayGames]

25 minutes ago, UCyborg said:

Time flies, must have been 3 or 4 years since when 360Chrome 13 was all the rage

Yep!  Was a fun ride, to be honest.  I am thankful to have played a role.  But those that truly followed, I stated from very early that 360Chrome was only a stop-gap, to buy some time, and that none of us should expect to stay on XP "forever".

My life really has improved by LEAPS AND BOUNDS now that I finally "let go".  I still drive a SEVENTY YEAR OLD CAR, but nope, no longer see the 'need' to run 20yr old computers.

[AstroSkipper]

In fact, it was uCyborg who first suggested (in Dezember of 2022) rebasing the chrome.dll file in 360Chrome as a measure to curb this browser's hunger for memory and pointed to the tool libase: https://msfn.org/board/topic/184135-arcticfoxienotheretoplaygames-360chrome-v1352022-rebuild-3/?do=findComment&comment=1232976
On my hardware, rebasing the chrome.dll was a complete success and actually resulted in a significant reduction of 360Chrome's RAM consumption. Since then, I have been experimenting with rebasing browser DLL files. For Chrome/Chromium based browsers it was the chrome.dll, for UXP browsers and for Mypal 68 the xul.dll file. However, it was indeed me who casually remarked here first that rebasing the xul.dll file has a significant, positive effect on the RAM consumption of Mypal 68:

On 8/25/2024 at 1:48 PM, AstroSkipper said:

I should mention at this point that I use all your releases with an xul.dll file rebased on the base address of 0x6af00000 to try to improve the terrible memory hunger of Mypal 68.

 

[UCyborg]

Oh, so it'll be only 2 years in December. It's been about a decade since a deeply disturbing discovery about my past has occurred and considering how forward the realization of passage of time since then came, maybe that inflated my sense of how long it's been since making that post about rebasing without explicitly finding it first to be sure. So that's what I get when trying to rely on my brain.

6 hours ago, NotHereToPlayGames said:

I still drive a SEVENTY YEAR OLD CAR, but nope, no longer see the 'need' to run 20yr old computers.

How does one just drive a car of such age? You must be good self-taught mechanic.

My family keeps asking me from time to time when I'll throw that smartphone away, when I'll buy a new computer. While I can appreciate technological progress since then and I'd be probably happy with a new computer, maybe even more than with current one, there's this attachment to the old one. There's a conflict between missing out on new stuff and retiring old stuff that still does all the important things. So I do nothing.

1 hour ago, AstroSkipper said:

for UXP browsers and for Mypal 68 the xul.dll file

I mostly recently used rebase.exe like this for Mypal 68:

rebase -b 61D90000 freebl3.dll lgpllibs.dll libEGL.dll libGLESv2.dll mozavcodec.dll mozavutil.dll mozglue.dll nss3.dll nssckbi.dll nssdbm3.dll qipcap.dll softokn3.dll xul.dll

Might rebase all while you're at it. Of course, one should lookup Memory tab of browser process' properties in Process Hacker to determine the free spot with sufficient space.

libase.exe just uses DLL name to guess fittable spot without conflicting with other DLLs you rebased. I think its default config doesn't take into account the huge size of DLLs involved in this case.