MyPal 68

[feodor2]

@AstroSkipper

I take values from the system itself which do automatic rebase all the same. If you tell that 0x60000000 through 0x6f000000 is recommended why then the system set these different values?

I also tried rebase x64 version, but it failed  with "no rebaseables" so consider to do rebase for х32 only.

1 hour ago, UCyborg said:

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

Okey I try this too and compare with only xul rebase.

[AstroSkipper]

2 hours ago, feodor2 said:

If you tell that 0x60000000 through 0x6f000000 is recommended why then the system set these different values?

Counter question. Why does the libase tool automatically select the base address 0x6af00000 for xul.dll, which is exactly in the range from 0x60000000 to 0x6f000000?  In any case, this recommendation did not originally come from me, but from an article I found after a research via Google. Here is the decisive section as a quote:

Quote

The address range for an application that is not reserved by any version of Windows is from 0x00400000 to 0x80000000. The system DLLs for Windows are currently based in memory from 0x70000000 to 0x78000000 on the Intel processors and from 0x68000000 to 0x78000000 on the MIPS processors. Other standard DLLs (for OLE support) are apparently in the range 0x50000000 to 0x5f000000. When selecting base addresses for DLLs, Microsoft suggests that you select them from the top of the allowed address range downwards, in order to avoid conflicts with memory allocated dynamically by the application (which is allocated from the bottom up).

In conclusion, 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, but this is not the case taken into account by RebaseDlls application. The RebaseDlls application calculates preferred DLL base addresses within the address range of 0x60000000 to 0x70000000 (larger than the one proposed by Microsoft). The range allows to use up to 256 MB memory space for rebased DLLs.

This section can be found here: https://www.codeproject.com/Articles/35829/Modify-the-Base-Addresses-for-a-DLL-Files-Series
And as you see, @UCyborg also seems to prefer addresses inside this range for his DLL file series:

3 hours ago, UCyborg said:

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.

And I have also had good experiences with this base address range for DLL files. 

Cheers, AstroSkipper 

Edited September 16, 2024 by AstroSkipper
Update of content

[feodor2]

19 minutes ago, AstroSkipper said:

Why does the libase tool automatically select the base address 0x6af00000

No idea, the system sets 13000000 automatic

I have done a big rebase of the whole to 61D90000 - it take even lesser memory. I want explain why such not round values, why not 60000000?

Also I find gits rebase is defective after it the browser wont start at all, so I stick on psdks rebase only

 

[UCyborg]

1 hour ago, AstroSkipper said:

And as you see, @UCyborg also seems to prefer addresses inside this range for his DLL file series:

38 minutes ago, feodor2 said:

I have done a big rebase of the whole to 61D90000 - it take even lesser memory. I want explain why such not round values, why not 60000000?

That must have been the beginning of a free spot I found on my system when using XP x64. It's been a while since I selected it and don't recall what else was there between 60000000 and 61D90000. I can check tomorrow, but only if someone is very very curious about it.

Remember, Process Hacker is your friend.

The value is still pretty round in context of classic 4K pages of x86 architecture I think.

[AstroSkipper]

56 minutes ago, feodor2 said:

No idea, the system sets 13000000 automatic

Unfortunately, the idea is not to do what the system does, as without manually rebasing the RAM consumption of Mypal 68 is much higher. The system doesn't seem to automatically assign an optimal base address in terms of RAM usage. So, it is better to manually find a range where the RAM consumption is minimal and all is still working. And the range from 0x60000000 to 0x6f000000 really seems to be a suitable one for DLL files that do not belong to the system.

[AstroSkipper]

28 minutes ago, UCyborg said:

Remember, Process Hacker is your friend.

Yep, Process Hacker has been my friend for many, many years.  It is always running in the background automatically after system start. I also check the free spots with sufficient space by using the Memory tab.

[AstroSkipper]

12 hours ago, feodor2 said:

I want explain why such not round values, why not 60000000?

Start Mypal 68, open Process Hacker, right-click on the mypal.exe file and left-click on its Properties! Select then the Memory tab and check the base address range from 0x60000000 to 0x6f000000! If, for example, no other DLL file has the base address 0x60000000 and behind it is enough free address space for the DLL files to be rebased, then of course you can also start with the base address 0x60000000 for rebasing the DLL file series.

Edited September 17, 2024 by AstroSkipper

[dmiranda]

Very nice discussion. I use basilisk (form most work related and some casual surfing), mypal (for social media) and supermium (for whatever doesn't work in the other two). I have been playing with some of the ranges proposed here and in the supermium thread) and the following combination works well in my setup. As this discussion makes clear, free ranges may vary depending on your setup and the apps you run.

Basilisk, I'm testing the range proposed by @AstroSkipper for mypal, 0x6af00000

Mypal, I'm testing the range proposed by @feodor2, 61D90000

Supermium, I'm testing the range proposed by @UCyborg somewhere in the supermium thread, a while ago, 10040000.

So far, so good, much better than the addresses chosen by XP SP3 when left alone.

Cheers!

 

 

[RamonUn]

as a side-note the big re-base at 0x61D90000 works also for me on Windows server 2003 x32

I did not realize you could pass several dlls to rebase at once, this is sure convenient.

[UCyborg]

Yeah, the idea is to have them all together in one spot.

[AstroSkipper]

13 hours ago, AstroSkipper said:

16 hours ago, feodor2 said:

I want explain why such not round values, why not 60000000?

Start Mypal 68, open Process Hacker, right-click on the mypal.exe file and left-click on its Properties! Select then the Memory tab and check the base address range from 0x60000000 to 0x6f000000! If, for example, no other DLL file has the base address 0x60000000 and behind it is enough free address space for the DLL files to be rebased, then of course you can also start with the base address 0x60000000 for rebasing the DLL file series.

For testing purpose only, I have rebased the DLL file series to the base address 0x60000000. As I already assumed, it works in the same way as with the other addresses. Here is a screenshot:



I should still mention that I checked the base address range before rebasing. The range from 0x60000000 to 0x66700000 was not occupied by any other DLL file.

Edited September 17, 2024 by AstroSkipper
Update of content

[feodor2]

I think the sequence of the big rebase is matters, finally I select this, qipcap rather not necessary, it is zero chance it will be used.

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

[AstroSkipper]

In the case of Mypal 68, however, the effect of rebasing its DLL files is only sustainable in multiprocess mode as the main problem with most browsers is, among other things, the release of memory when tabs are closed. The browser is not inherently prepared to release the amount of memory that a tab requires to load when this tab is closed again. In the course of a browser session, more and more RAM is therefore used that is not actually required but is no longer available to the system and can usually only be released if the browser is closed or restarted by the user. Unfortunately, the effect of rebasing fizzles out very quickly in single-process mode. And even in multiprocess mode, it is necessary to do more than just change the base address of its DLL files to fully enjoy the effect of rebasing in the entire browser session. Especially on systems equipped with a small amount of RAM where every single megabyte counts. 
In any case, I have managed to configure my installation of Mypal 68 so that the memory occupied by tabs is almost completely released when they are closed again. Of course, without restarting the browser and being a tab hoarder.  

Edited September 18, 2024 by AstroSkipper
Update of content

[dmiranda]

13 hours ago, feodor2 said:

I think the sequence of the big rebase is matters, finally I select this, qipcap rather not necessary, it is zero chance it will be used.

The range proposed (maybe also the order/sequence of dlls, it doesn't hurt anyway) works well for me. It really makes a difference taming RAM peaks on launching (multiple pages) and together with other tweaks discussed in this (but also in @roytam1's) thread in preventing crashes and keeping browsing much more satisfying than otherwise. In my case, an altogether improvement.

Cheers!

PS: I run my profiles and swap fromRAM (8gb). Since rebasing I haven't seen an out of virtual memory crash anymore, so far (I've been playing with different ranges for the last month or two in all the browsers I use.

Edited September 19, 2024 by dmiranda

[egrabrych]

Information:

From time to time (irregularly) I used the website: https://polskieradio24.pl/ Recently, instead of the content of this page, the following message began to be displayed: Application error: a client-side exception has occurred (see the browser console for more information). During my "investigation" I determined that the cause of this state of affairs is the setting of the value "false" for the configuration variable: geo.enabled . Since I have had the value "false" set for this variable for many years (earlier - in the Firefox browser), and the website: https://polskieradio24.pl/ was displayed correctly not so long ago, I suspect that the cause lies in some change recently introduced in Java Script. The problem described above does not depend on the browser version and occurs not only in MyPal68, but also in the current latest version of Firefox (130.0.1). This problem disappears after changing the value of the configuration variable geo.enabled to "true" (this is the default value of this variable in the current latest version of Firefox). This problem does NOT appear (after setting geo.enabled to "true") when we block the display of requests for current location in the browser settings (MyPal68, Firefox):

I am posting this information here because MyPal68 in the current version 68.14.4b has the configuration variable: geo.enabled set to "false" by default - so someone else may also encounter the same problem.