UCyborg

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.

Yes, but it's almost 800 MB on the same machine on XP x64 SP2.

Did you guys just make a bunch of assumptions about me using proxy? I use Proxomitron, mostly for modding the web application I use at work. Would have to ditch Pale Moon there completely if it wasn't for Proxomitron replacing one bad JS file developers introduced for their own convenience / consistency with other code, nothing but syntactic sugar for having definitions for some objects on the client-side (JavaScript) close to the definitions on the server-side (C#). That thing still has few glitches, like one dialog opens with 1,5-2s delay if certain option is set in it and another draggable dialog made with jQuery, since certain version, has a funny glitch, the dialog has few drop-down menus, one with a lot of entries has the scrollbar and if I try to drag the scrollbar, thw whole dialog is dragged instead... I also have to unset a bunch of redundant CSS properties on the menu bar, because at least one of them is causing another bizarre glitch, when something changes on the page, it causes menu bar's height to change. It's funny to watch when you open the hardware page where you can open the status of any working connected controller, which refreshes once per second and then every second menu bar's height increases, so it would eventually expand down over the entire screen. And other pages may open with the wrong bar height. Of course, nobody notices because system requirement is "latest and greatest" Firefox / Chrome. Edit: Maybe, there are other members here who can confirm or refute my theory. I would be very interested! I've got AMD with only 4 real cores, no difference in RAM consumption between running Chrome on all cores or just a single one, except responsiveness takes a noticeable hit running on one core (affinity setting). Edit2: Right, reading again, I don't qualify for the test.

Oh, looked everywhere but there...it's enabled in default config (starting out with empty User Data). Edit: BTW, --use-gl=desktop is presumably deprecated in recent Chrome versions since there's an error about not allowed implementation on chrome://gpu (tried on work laptop with latest Chrome) and I get the same error in XP in this 360Chrome build about that missing WGL function, like on Vista. There goes the idea of having functional HW accel through OpenGL.

I think I found the bug...or is there a setting for it? The browser ignores Windows proxy settings: Coming off Russian 13.0 something build, I forgot the exact build number, but there it worked. Neither the ticked checkbox in the screenshot is effective, nor the very last one (which forces proxy to be used unconditionally). Using regular buid, not ungoogled.

140 MB without extensions and 220 MB with extensions. Vista x64, BTW. Back in 2012, you could fit 40 tabs in 620 MB of RAM or less! Well, at least according to the test the good guys at Tom's Hardware did. And 620 MB figure was in Opera, the worst in that aspect at the time. Yup, all updated. I figured I can't use --disable-gpu-driver-bug-workarounds because then I don't get actual webpage compositing acceleration despite the green status on chrome://gpu, so videos lag. --use-angle=gl gives me slow (not SwiftShader slow, but slow nonetheless), but fully functional WebGL and no webpage compositing acceleration (so laggy videos again). It just occured to me that there are two distinct flags specifying how graphics / WebGL is handled (didn't do enough reading), until recently, I thought --use-angle=gl is just the new --use-gl=desktop and that the latter is not relevant anymore, but that is not the case, works differently internally. --use-gl=desktop gives me an error about missing wglCreatePbufferARB on chrome://gpu page...dang it, another dead end, so again no HW accelerated compositing and WebGL through very slow SwiftShader. Though wglCreatePbufferARB is very old function and seems doubful that the driver would lack it. I'd rather bet on the nice personality.

I recently setup this browser on my Vista SP2 installation. HW compositing only works via D3D9(Ex) (using chrome://flags/#ignore-gpu-blocklist), but WebGL does not, so I left it disabled , there are errors in D3D9 mode and D3D11 mode doesn't init at all (with --disable-gpu-driver-bug-workarounds since D3D11 is also blocked via that bug list), even OpenGL mode requires D3D11 (error DXGI_ERROR_INVALID_CALL during init), probably D3D11 Win7 got with updates is required. Still, HTML5 videos at decent resolutions are watchable here despite non-functional GPU video decoding. Interestingly, the load on both CPU and GPU is less than on recent Serpent 52, same video codec (h.264) and resolution (1080p60). The GPU doesn't have to switch from the lowest frequency and there's a difference in temperature by 2 degrees celsius in favor of Chrome. It's very interesting because when I go from 1080p60 to 1440p60, it's not watchable on Chrome anymore, but remains watchable in Serpent (with hiccups). Skia Renderer is reported as disabled by default, enabling it in chrome://flags prevents tons of errors from popping up on chrome://gpu page otherwise while browsing. Some people use Skype or Teams in the browser, the latter seems popular in business environment (both WANT you to use Chrome, obviously one can forget official Electron based clients on legacy OS), this browser still loads both, I can only tell that microphone (or at least its port) exposed through Windows recording devices is detected (both on XP and Vista), though couldn't test if the sound goes through since don't have am actual mic at hand. Also found an extension dealing with font contrast if anyone's interested - Chrome Font Super Enhancer, obviously can only mess with CSS properties, but uses some formula to determine the values. Late edit: WebGL1 works partially.

I'd call your version simply a ZIP version since it doesn't imply anything else.

I don't consider it an issue. I only accept https://portableapps.com/about/what_is_a_portable_app, anything else is lies, deception, fake news...or a bug. Of course, I also accept portability in a different context as outlined here. Interesting, I haven't run x86 SP2 since forever.

Crazy RAM consumption only happens on XP it seems. Who knows, I only debugged simpler stuff, might be another compromise to have it running on XP. Only by specifying it with a command-line parameter, eg.: --user-data-dir="%LOCALAPPDATA%\360Chrome\Chrome\User Data" I don't know if it still applies, but there was a quirk with an older ArcticFoxie version that you had to have the default user data files in the target location on the first launch if you were starting with fresh profile, otherwise, it didn't launch properly (got stuck and you couldn't click anything). I always launched 360chrome.exe directly, not with 360Loader.exe (mentioning it just in case there's unexpected behavior if you have the loader pass the argument...).

No, no, I don't post stuff on YT, I simply thought about using 1 GB of RAM over a decade ago in the old computer and found a video about using 1 GB of RAM today.

This post is going to be a bit random, but...playing games on Windows 10 with 1 GB of RAM:

It used DDR RAM, the computer was bought in 2002 or early 2003, had a talking ASUS P4B533 motherboard (ASUS POST Reporter). Can't try 360Chrome on it as I don't have that computer anymore. Would be interesting to try, but that thing was cursed with worst Maxtor HDDs, first one was a 60 GB model, second, which had to replace the previous one, was 80 GB. Both lived a short life and went out with a click of death. Then the new computer was bought in 2009 (form which I'm typing now) and no more investments were made in the old one. I did run 360Chrome on the current computer on XP x64 and it also consumed about 800 MB of RAM with an empty tab. I didn't check the RAM usage on newer OS last time I tried, but I also remember the game DOOM 3 consuming more RAM on XP x64 than newer OS with same settings / mods (Sikkmod at the time). Either way, your experience tells usage doesn't decrease when there's less RAM available and slight variation in the kernel (5.1 x86 vs 5.2 x64) also probably doesn't make much, if any difference.

Hey, I ran Vista on an old XP era PC with 2 GHz (overclocked to 2,5 GHz) Celeron and 1 GB of RAM. It also played 3D games, those that were happy with D3D7 anyway as it used cheap NVIDIA GeForce4 MX 440. Wouldn't be possible with the original 256 MB RAM stick. I can't imagine running Chromium on it though. I could with another GB of RAM.

Something to do with handling of local / session storage (https://app.bountysource.com/issues/94137785-discussion-dom-storage-next_gen).