AstroSkipper

@Mathwiz! In which way did you set ProxHTTPSProxy as a systemwide proxy in Windows XP?

@NotHereToPlayGames! Nice to see that you followed my suggestion to offer a special version for Windows XP users after all. Although I no longer need this version and have already rebased the chrome.dll file in my installation of 360Chrome 13.5 build 1030, I'm sure other users here will be happy about a RAM-friendly version for Windows XP. Or did you do other changes except rebasing the chrome.dll file?

I use different profiles for all my browsers. No sharing of profiles anymore for years. In the past, I made bad experiences with shared profiles which became suddenly corrupted. And I always keep backups of important profiles to be on the safe side. Happy New Year, too

The information I researched was actually intended for @UCyborg relating to the browser and our conversation here. So on-topic, unlike so many other posts here. You are welcome to post the problem on the WiseVector StopX forum, but it is not official and therefore not really helpful. But, as I explained in my last post, for me personally, the problem is already solved after rebasing the chrome.dll file. And BTW, the culprit of my BSOD was not my computer. Maybe, you should read my posts again. I think you missed something.

My mainly used browsers in Windows XP are the @roytam1's browsers New Moon 28, Serpent 52, Serpent 55 and @feodor2's browser Mypal 68. Additionally, I use @NotHereToPlayGames's modified browser 360ChromePortable 13.5.1030 rebuild 6 with a chrome.dll rebased by me, only if the others fail on a specific website.

@UCyborg! I removed all exclusions made for 360Chrome v13.5 build 2022 in WiseVector StopX. Running again this browser with the rebased chrome.dll does not cause a BSOD anymore. Therefore, my assumption that rebasing chrome.dll might avoid such conflicts is presumably correct. q.e.d.

This is a quotation from https://www.mandiant.com/resources/blog/six-facts-about-address-space-layout-randomization-on-windows: Important parts are marked by me in bold type.

I thought Windows XP wouldn't be able to rebase dll files in its memory due to the lack of the ASLR feature and would always load these files to their predetermined addresses.

I had only BSODs in the past when starting one of the 360Chrome browsers which had a conflict with WiseVector StopX. Only a total exclusion of all 360Chrome installations in WiseVector StopX helped to avoid further BSODs. And I never had any other BSODs before. My system is flawless, so to speak, at least there are no discernible problems. I assume that rebasing chrome.dll might avoid such conflicts. In any case, I will test this again. BTW, I never said that rebasing is a culprit of whatever. Quite the opposite! I think you have misunderstood something.

@NotHereToPlayGames! As I reported weeks ago, I observed BSODs on my Windows XP system when starting one of the 360Chrome versions, caused by WiseVector StopX. Now, I checked the used memory addresses in my system and found out that WiseVector StopX loads the file WiseVectorHelperOne_X86.dll at the default address 0x10000000 of chrome.dll. I think that was the reason for the BSODs. Therefore, a rebasing of chrome.dll is mandatory for those Windows XP users who use WiseVector StopX.

My suggestion to offer a special rebased version for Windows XP users is due to the fact that this thread only targets the version 360Chrome 13.5 build 2022. This version is rather a poor choice for Windows XP users on old, low-powered hardware. Therefore, a rebased version of, say, 360Chrome 13.5 build 1030 would be more suitable for these users. So only one additional version would have to be provided. All Vista users do not need a rebased version, they have the ASLR feature. And all users of Windows 7 and higher do not need this browser anyway. Anyway! Ultimately, it is solely your decision. I personally switched to the version 360Chrome 13.5 build 1030 which I already rebased.

I have also already downloaded the ReBase tool from the Windows SDK. When I have time, I will try that out as well.

Hello @NotHereToPlayGames! Since I was the one who discovered and documented the abnormal RAM consumption of the 360Chrome browser in Windows XP, for which I received extremely friendly comments in this thread at the beginning, then called for further investigations and researched the causes, I will now take a look at the state of play. First, the good things. For all Windows XP users who really need this browser, i.e. who want or need to run old, low-powered hardware for which this Windows OS is the last compatible one, the method of rebasing the chrome.dll is an excellent stroke of luck to put an end to the memory hunger of this browser. Thanks again to @UCyborg and @mixit for their tips! I have now rebased the chrome.dll file in all my 360Chrome installations. I was able to reduce the RAM consumption of 360Chrome 13.5 build 2022 by almost 85%. That is truly enormous. It's almost beyond belief! Now, the bad things. For me, the time it takes to start a browser is totally unimportant and frankly irrelevant. What is much more important is the loading behaviour of websites in general when the browser has already been started. And that's where this browser doesn't look good at all. Many websites take eternities for being loaded if at all. It is not uncommon for the endless loading process to end in an error page. Not comparable to @roytam1's UXP or moebius browsers at all! That would be much more of a cause to be concerned. Anyway! If I were you, I would leave all 360Chrome editions for users of Windows Vista and higher as they were. For Windows XP users, however, I would offer a separate version in which the chrome.dll file has been rebased in any case. The reason for such a procedure is the ASLR feature, which all Windows versions from Vista onwards have, but unfortunately Windows XP lacks. On the subject of rebasing, you can certainly test which address is best suited for this procedure. Personally, I have done it automatically with libase. And that seems to be sufficient, at least for me. However, I hardly think that this will improve the loading behaviour of websites on old, low-powered hardware. In any case, I couldn't notice any improvements in the loading behaviour of websites on my system. This is probably more of a browser-specific problem which presumably can't be solved without further measures as for example recoding, code changes or code optimizations. And I doubt that 360Chrome 13.5 build 2022 is the best suited version for Windows XP. For example, 360Chrome 13.5 build 1030 seems to be better suited as far as I can observe in my case, according to the 360Chrome rule: the newer, the worse.

My Windows XP system runs like a charm without any errors. We have an interesting range of working browsers which are constantly being further developed, and a lot can be done on such a system. Windows XP is a perfect Windows OS for old, underperforming computers. I hope this OS will live forever.

Dito!

The worksround for translate.google.com is to set the dom.enable_performance_navigation_timing preference to false.

You forgot to mention which browser you are referring to.

The last days, the website of Legacy Update had an certificate error and couln't be accessed. This seems to be fixed now.

Try again! The last days, their website was unavailable due to a certificate error. It seems to be fixed now. BTW, there was and is no need to open a new thread for an error with Legacy Update, actually. We already have two threads about WU/MU. Specifically for Windows XP: And for Windows in general: Kind regards and Merry Christmas, AstroSkipper

The quotation is from here: http://www.jsifaq.com/SUBJ/tip4800/rh4851.htm (no longer available, only via archive.org). To fix such errors, you can try to replace the file ntdll.dll in both folders, System32 and dllcache, by a fresh, working one! Your existing file is most likely corrupted due to any reason (bad image, scratched or badly copied CD or DVD, and so on). Anyway! Your installation medium is probably corrupted, and I wouldn't trust in any case. If one file is corrupted, there still might be more. Therefore, try to create a fresh medium maybe by using a different computer!

Glad it finally worked for you! But in terms of Windows XP, my guide "General and specific solutions for problems regarding AU/WU/MU in Windows XP" is completely sufficient. And by the way, I personally have a complete, offline update archive with all updates for Windows XP. For the German edition, of course! I don't like relying on Microsoft's update servers, where everything concerning abandoned Windows operating systems could be deleted at any time.

Hello @UCyborg! I compared your chrome.dll to my rebased one. The sizes are the same but the hashes are different. I thought libase uses the hash from the original dll file for rebasing. So why are the hashes different? Is it also dependent on the system? Or did you perform the rebasing manually with specific addresses?

I already did that. Version 1030 runs more smoothly on my old system than version 2022. Both versions are consuming very little RAM.

I think it was the chrome.dll from the version 360Chrome v13.5 build 2022 rebuild 3. I also downloaded @UCyborg's rebased chrome.dll to compare it to mine. The sizes (of original and rebased chrome.dll) match in any case, and it works.

And again, you are absolutely right! In some special cases, it's better to use old programs on old systems what you may call "period correct". They were developed for these anchient OSs, and one can avoid problems that much more modern programs can cause. I have often experienced this on my old computer.