UCyborg

Off-topic, but you can actually use Dropbox to share these things (rhetoric question)? I used to share something using it, but after some time, my link errored that the account's public links are generating too much traffic. I wonder if the limits these days are the same than they were few years back. On-topic, is there a changelog for official builds? What's the difference between 1030 and 2022 and why would one be slower than the other, both being Chrome 86?

Interesting piece of malware: Report on VirusTotal This guy ran it under built-in Administrator account. I tried it in a virtual machine in XP under the restricted user account in Users group, it failed to do much, it errored out that it's corrupted. Buggy virus!

Same in official Pale Moon, works in SeaMonkey.

I did notice it months ago, just thought it was funny compared to 64-bit Edge on my Win10 install, brushed it off to ancient OS + Made in China browser combo and didn't think about it further. I'm not sure there's a good reason to have two versions, I don't think rebased version would offer any disadvantages on NT 6.0+ compared to non-rebased. And for those opposed to using software that caters to the lowest common denominator on the API level on newer OS, especially NT 6.1+, I suppose this browser wouldn't do anyway if they find something else that suits their needs.

Alright, tested the load time of browser again after Windows startup and after the other startup programs have loaded. All on already good warmed up PC, well, as warm as it can get when the ambient temperature is about 15 degrees Celsius or so does my thermometer say. I can confirm approximate 4 to 5 seconds delay with rebased DLL here after 3 tries. Very curious. Now who can explain that? I save load of RAM with rebased DLL, if I take 14 same tabs, we're talking total RAM consumption of the entire system of 1,4 GB vs 3 GB. Chrome loves multiplying its core process you know, it's not just the first 800 MB and some, assuming you open a bunch of tabs. Funny you mention walking to the other higher end PC @NotHereToPlayGames, what about boot time of that PC or are we talking about PC that's already on? BTW, I got chrome.dll at 0x3E1C0000 now. LOL, this whole thing feels like DOS all over again.

I suspected it's something like that. So this browser is just two versions away from Manifest V3 (https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html).

Only those that have DLLs loaded in other applications. It might be unrealistic to be able to make public release with the "perfect" alignment, I think avoiding the popular 0x10000000 is good enough start, you basically want to avoid that huge DLL from being rebased by the OS, it has to be first to occupy its space. If you use some debugger, you could pause it at the point chrome.dll is loaded and see what's free. With public releases of software in general, it's probably unavoidable that a DLL there or there is rebased, but the issue is smaller with smaller DLLs. AFAIK GCC for Windows uses some own logic to choose address for DLL when building, eg. compare DLLs of T-Clock Redux, one version with built GCC, another with Visual C++, latter has MSVC default address while the other has it in the high range 0x60000000. NVIDIA's driver DLLs (at least I checked OpenGL one) for instance also has a high address in 0x60000000 range, but I doubt NVIDIA used libre compiler, so must have chosen their own / put it with others through REBASE.EXE with high starting address or something, who knows, not much about rebasing written or I haven't searched thoroughly enough. Mentioning because I rebased DLLs of the other browser and forgot about WebGL initially, which loaded OpenGL driver, so my first chosen address ended up in a conflict with the driver DLL, which had to be relocated. I actually went with a bit lower address for chrome.dll, I can post it when I get home. There might be something about loading delay with high address and big DLL here too, not sure, my XP is more sluggish on some days at startup than others. Since YouTube often comes up in these browser discussions, neither the new test version of ImprovedTube extension nor current version of Enhancer for YouTube are compatible. Funny thing about ImprovedTube, not sure it's legacy OS thing / something missing in them (who knows what...), but even the last working version has an issue that buttons labels in main menu are missing and the picture buttons are bigger because of it.

If you uncheck Hide free regions, it shows free spots and I noticed on my system there was cca. 17 MB free region between rebased chrome.dll at 0x62A00000 and wow64.dll. Though I didn't keep the browser open long enough to notice rsaenh.dll loading a bit later, which has preferred base address set to 0x68000000 (you can check that with Tools->Inspect executable file...BTW, it's possible that thing will erroneously show 64-bit hex number on XP x64, despite looking at 32-bit DLL, if I'm not mistaken, if you cut it in half and look at the first part, that should be correct), which then had to be relocated since part of its space was occupied by huge chrome.dll, which wouldn't have to be otherwise. Your screenshot shows chrome.dll made it to default 0x10000000, so the issue with big consumption doesn't occur. If you go really nitpicking, I think you'd ideally want DLLs crammed somewhere together to reduce address space fragmentation, in the 90s, you could have those DLLs all over the place at higher addresses and it wouldn't be a problem since address space (4GB - 2 GB usable) was huge compared against available RAM capacities, but today, you can easily consume it all, but again, in this case we're dealing with Chromium that splits itself in multiple-processes...does single Chromium process ever start to consume as much in practice that it would become the problem? I know it looks weird when you look at it at first, but basically every 32-bit process has 4 GB virtual address space to play with where its data in RAM are mapped, executables not marked with Large Address Flag are capped at 2 GB, though practically utilizable numbers are smaller. If I remember correctly, these things are explained in Windows Internals, one cool and long book about Windows technicalities. Oh, the REBASE.EXE I mentioned, it's the tool that was bundled with older Microsoft Visual C++ IDE (Integrated Development Environment), maybe also older Microsoft Visual Studios (individual suites for each language (C++, Visual Basic...) were later combined into one Visual Studio, well, the tools are still separate, there's just one big program from where you open project files and edit code).

Do as you want. I've rebased chrome.dll with REBASE.EXE to be closer to wow64.dll on 64-bit XP, 17 MB gap before it was reduced to somewhere below 1 MB, so went from 0x62A00000 to 0x63A00000. Good enough for me and those occasional boots to XP, no side effects. No comment on 14s delay, first time I hear of it, maybe rebase to the address the OS chooses itself when it has to relocate the DLL from default 0x10000000?

See if --disable-windows10-custom-titlebar changes it.

I guess what I was getting at is how much work is there in the background for providers to set things up. Because maybe where PlayReady is supported, it'll last longer before it stops working on Windows 7. I also saw those functions you mention and they're definitely not in vanilla kernel32.dll of Vista SP2. So Widevine can't work on vanilla Vista since they're hard dependencies and the lack of those functions would result in failure loading Widevine DLL.

Seems videos originate from YouTube, at least that's what it seemed after checking few. You just reminded me of my previous computer, it was all sluggish 'til it warmed up. Seems to be Chromium 75 based indeed. I guess update URL was cleared from the binaries, so browser doesn't pick the current version, but latest Widevine from Chrome 108 works with it on recent enough OS. I wonder if Netflix and such require Widevine specifically. Would PlayReady CDM also work or does it have to be supported specifically (from little searching it could be the case)? Because on that test site, PlayReady from Edge 94 still works.

Plus Widevine is one of those ugly Google things built with an expiration date, sooner or later it stops working and you need a new version. Look on the bright side, that way, you are liberated from those POS streaming services.

Installed software can influence whether chrome.dll will make it to 0x10000000 address or not, eg. I have number of programs which DLLs load in most processes - Actual Window Manager, HardLink Shell Extension, VirtualMIDISynth, Office 2010 - all of these have DLLs that compete for 0x10000000 spot.

Newer Nextcloud versions using Unicode property escapes work with the new UXP additions . @roytam1 Please consider looking into rebasing your browsers' DLLs. XP and older systems cannot optimize memory usage when it has to relocate DLLs in memory like ASLR supporting OS do (I haven't checked if the memory usage woud also creep up with ASLR off on Vista+, so with dynamic base flag turned off in executables and DLLs and using default base address). This will save memory, especially with multiple instances of the browser process. https://msfn.org/board/topic/184135-arcticfoxienotheretoplaygames-360chrome-v135-build-2022/?do=findComment&comment=1232976 You could try LiBase utility for the hint what addresses to use, but then use linker's /BASE argument to specify it for each DLL when they're built. Check if that argument doesn't invalidate default /DYNAMICBASE setting, which sets the flag to enable ASLR on Vista, which I think is OK to keep. If linker clears it for some reason from resulting executable, then I guess there's a way to configure somewhere in the build environment to run LiBase as post-link step on the built DLLs or have the BAT or similar to run it manually at the end.

It was packed with UPX, which can also unpack.

Packed executables are smaller on disk, but have to be uncompressed at runtime.

DLLs sometimes have to be relocated anyway due to how things end up in the process address space, it would definitely be a good idea to take care of the rest of Chrome DLLs, at very least those with default 0x10000000 base address, which libegl.dll and libglesv2.dll still use. I don't see how that could happen except in cases where file was digitally signed and the program checks its own signature.

@AstroSkipper ReBaseImage updates the timestamp inside PE header, which also effects calculated checksum, also written in the header, so only these two fields will differ if everything else is identical. So, TimeDateStamp field of IMAGE_FILE_HEADER and CheckSum field of IMAGE_OPTIONAL_HEADER (https://0xrick.github.io/win-internals/pe4/). Hm, LiBase's default config assumes DLL that is not bigger than 1 MB (relevant for putting multiple DLLs through the process). Edit: Actually, the function takes that timestamp as the parameter. LiBase just uses the result of standard time() function with NULL as the parameter, so current time. But if you pass 0 to ReBaseImage, it will increment the currently stored timestamp in the executable by one second.

Thanks, I'm an old cat (MEOW!) who knows some tricks...took me a while to remember though. Hello @mixit! You are absolutely right! I also tried to rebase the chrome.dll of 360Chrome 13.5.1030 rebuild 6 and failed. Only after removing the file signature with your recommended tool delcert, I was able to rebase this chrome.dll, too. Thanks for your tip! Yes, most work is done by ReBaseImage function, which checks for digital signature and bails out if it exists. It's logical when you think about it, when you digitally sign the executable, you seal it for release and don't change it anymore afterwards. It's possible to write own function for rebasing if you like to crunch through the executable manually. I think it was the chrome.dll from the version 360Chrome v13.5 build 2022 rebuild 3. @NotHereToPlayGames's rebuild 3, regular build, here's the ungoogled one. I'm sure @NotHereToPlayGames will include the rebased version in next rebuild. I would assume it should be. Hold on, have to get back home from work, lunch and so on, I'll check it later.

I can upload my chrome.dll for others to try. It should make the difference in case you currently see chrome.dll in orange in Process Hacker when you open 360chrome.exe and go to Modules tab (should no longer be orange with the old new DLL). At least the chance is very low that it still fails to load at its new address, if it does fail, it'll be orange again (bad!).

I'm not very talkative. Hm, I've had the impression there's been this tension in the air in recent years that wasn't there before, at least not like that or as much as now, especially after COVID-19.

Seems chrome.dll needs to be rebased. It uses the default preferred base address used by MS build tools (which is constant) and is unable to be loaded at its preferred base address on my XP and the DLL itself is huge, so it seems logical if the OS has to duplicate huge chunk of it in every chrome.exe process to be able to fix-up addresses inside, that would be costly in terms of memory. I did rebasing when I patched old games (at least those I've spent most time working on) that used DLLs, which were small and these games don't spawn multiple processes. Back then I found the tool that chose the address based on the name of the DLL with optional INI file to specify base address and separation (how much apart they should be in the address space). I think the idea is to line up DLLs of your application at higher addresses, preventing conflicts with each other or another system softwares' / utilities' DLLs so OS doesn't have to rebase them at load time. Having them loaded in upper portion of the address space should leave large contiguous space for memory allocations. Some interesting reading here and here. There's the hint why you don't see the issue on Vista+. Anyway, here's the tool (libase.zip), it's in the Release subfolder, have both chrome.dll (from Chrome\Application\13.5.2022.0 folder) and libase.exe in the same folder, open CMD, cd to that folder and run: libase chrome.dll Copy chrome.dll back, launch the browser and check the memory consumption. No idea where the tool was originally published and who wrote it, I think it came only in source code form and I wrapped it inside Microsoft Visual C++ 6.0 (another dinosaur) workspace file and compiled it. Microsoft has their own tool in their compiler suite that can also rebase executables and DLLs (reference). So it's an issue that is easily fixable, but not many people seem to pay attention to such details. Rebasing other browser's DLLs should also save a little bit of memory. Well, I do assume things at times.

1809 was the first I used seriously and didn't seem to have anything that bothers me much. I went to 20H2 on home desktop just out-of-curiosity and left it at that version since I didn't find very compelling reason to bother going back to 1809, though Explorer got weirder when combined with QTTabBar - I think the glitch started with 1903 already if I remember correctly when you have one or more regular folders opened and you try to open the Control Panel, new window with Control Panel opens which also forces the other window with folders to close (or it forces those tabs to close on existing window). bigmuscle's Aero Glass is fully functional on 1809, but I can live with solid appearance, one machine runs 32-bit 1809 on which AG also doesn't run since it's 64-bit only. Not opening Control Panel every day, so whatever on that part I guess. I noticed 20H2 shows more accurate refresh rates in screen settings and DWM is supposed to handle multiple screens that aren't on the same refresh rate better (smoothness), I'm not sure from messing around if it's noticeable here, have over a decade old screens, the bigger one runs at TV refresh rate, so 59 point something at native resolution while the small one can do 75 Hz at native resolution, but I prefer to keep them both at 59/60 for consistency. Still on 1809 version on 2 out of 3 machines.