Leaderboard

brought back manifest v2 extension support. Cool! https://github.com/e3kskoy7wqk/Chromium-for-windows-7/releases/tag/140.0.7275.1

im not certain, it would requie to read out all the stuff that has been done related to this patches the /3GB is known to have some problems too, i dont know the problems with it j7n maybe has some knowledge here ? if its a problem with the /3GB switch there would be also the /USERVA switch to set a different value (between 2048 and 3072 (3 gb)) https://learn.microsoft.com/en-us/windows/win32/memory/4-gigabyte-tuning the one from dibya only use a small patch - maybe that would be worth a shot daniel k.´s patch use more of changes, maybe static offsets - that would be a reason why they dont work together also the method daniel k. described could trigger a crash not certain what "the russian patch" do to solve this problem is at the moment to much things around, i might can tell the norm´s, talks, idea´s a debug analize for example would take some time but if it comes to new work im busy at the moment sorry i also dont have the function test for dibya´s patch (aka if it passes the 4 gb limit) there should be someone to try these patches with the method j7n did to do so is simple just disabling the pagefile, then starting up app´s/executables that eat up more then 4 GB of ram if that is possible that patch is likely to work

hmmm in the past we had often a discussion about "32 bit is the 4 gb limit" or = 32 wires 32 bits can form 2^32 bits therefore 4´294´967´296 what represents 4 GB the problem with that is that even in 8 or 16 bit´s there are so called selectors those do actually still exits in 32 bit too also very important is that these 4 GB of possible "addresses" are not converted into that rather the representing PTE´s and PDE´s represent to a 4 KB page (in old normal 32 bit style) so going with that if you have 4 GB/ 4 k pages you end up in only using 20 bits ! (20 bits * 4k = 4 GB) a idea (very similiar to the discussion about 4 k sectors and 4 MB sectors with the harddrive(hdd/ssd)) would be just to increase the 4 K pages to 4 MB pages that would be 1024 times as much RAM the discussion about this are elder thats why that bit (PSE (page size extension)) was 1 candidate to pass that 32 bit limit the other candidate was the PAE bit (physical address extension) here is 1 catch PSE can extend the 4 GB by increasing the page size (even with a 32 bit PDE´s and PTE´s) in PAE mode PDE´s and PDE´s are 64 bit (yes even in 32 bit mode), that´s one of the reasons why PAE can address more then 4 GB of ram (to be more precise paging are mechanism´s there also some more things they play a role the CR3 register (also called the page directory base register) or the GDT, it would be to long to explain all but lets stay like this for now) so let us take the next important step in the old 32 bit system without PSE,PAE or "concrete use of segments", an app/executable had to use up the 4 GB ram because there was a user-mode (ring3) and a kernel-mode (ring0) there had to be a part in kernel mode and a other part in user-mode offsets are not a problem (as you can map a address like 0xFFFFFFFF to page 0 if you wanted) deviding the kernel mode and user mode is important, if that would not be the case every crash on a normal app/execuble would be a entire OS crash (BSOD or wrose) so the solution was simple usermode 0x00000000 - 0x7FFFFFFF - kernelmode 0x80000000 - 0xFFFFFFFF thats how the eldest 32 bit norms work it is not to bad to have kernel mode ram because many modules actually need space in memory (its not like an app is just made out of the app itself the app consits of many modules that also use ram internal) - also the video frame buffer often has a kernel mode area that takes memory for example so here we finally have our split 0x00000000 - 0x7FFFFFFF (2 gb) + 0x80000000 - 0xFFFFFFFF (2 gb) = 4 GB the app/executable now has the problem that it cant directly use the kernel mode offsets (it certainly use them but rather passiv (its some memory you need less in your app)) for this microsoft then made the /3 GB option in this one usermode has 3 GB and kernelmode 1 Gb (0x00000000-0xBFFFFFFF) + (0xC0000000-0xFFFFFFFF) = 4 GB but now the important part those offsets are not physical addresses ! actually you can map every of that "offset´s" to different places in memory (including the ones above 4 GB RAM) so thats why multiple applications/executables can use up the entire 64 GB of RAM (in j7n example he had 20 GB of 64 GB possible) thats more then 4 GB of ram and the proofes XP 32 bit can do it that way now we also have to mention the ramdisc solution, if you have like 20 GB of data and map then into the physical ram then the ramdisc use a chuck-wise solution it then maps for example 1 GB of that 20 GB data into an offset (that goes like fast) (when it wants the next part it just maps the next part - but it is chuckwise) now we have to mention the pagefile, in the pagefile windows stores memory data on the harddrive (HDD/SSD) when windows wants it use exactly that trick (it loads the data from the harddrive into that virtual offset) but this time there is an important differenz - the data is not from a RAM memory - it has to load that from the harddrive (and that is slow) for a SSD its faster - but still not as fast as it would be in memory so i guess some have reconized the increase in speed with SSD`s ? now you have a little more precision why this is the case so now to the part why a "normal app/executable" actually dont pass that 4 GB ram ram limit i already explained why it is rather like 2-3 GB ram + some kernel mode memory that is rather used like passiv but now the reason why it actually dont go beyond the 4 GB ram in "just one application/executable" here you have to know that all compilers form the past-now dont use segment selectors to pass that 4 GB ram i never seen a compiler that would be able to do so. probaly windows xp (even up to win10) dont have code for this either. but here is the thing normally in a code flow of a debugger you see a offset (or better called vitual offset this time) for the code flow it use a register called EIP (instruction pointer) - the E stands for 32 bits - for example only IP for 16 bit and REIP for 64 bit (R means 64bit) but here is the next catch ... the most common debuggers dont show the selector but for the code flow the CPU use a combination of a segment selector + virtual offset (the one you see in a debugger for example) this is called the CS:EIP combination - where CS is the segment selector (called the CODE SEGMENT(short CS) selector) EIP E for 32 bit and IP for instruction pointer now might be a good time to call out a wiki page about that: https://wiki.osdev.org/Segmentation that CS selector is 16 bits wide (in 32 bits) and 16 bits means 65536 possible selctors ... so the combination 16:32 or CS:EIP would be 65536 * 4 GB - that would be theoretical 262144 GB that it could select (+ you have 6 of segment selectors all in range 0-65536) but here is the catch windows (either xp - 10) dont use this to pass the 4 GB limit the only things windows actually did with these registers is that they point to small pieces of memory (like the EPROCESS structure) that is possible - but it leaves out the use to pass the 4 GB of ram limit by just using a few kilobytes with that method ... here is an example where microsoft accesses a small piece of ram using a selector : https://devblogs.microsoft.com/oldnewthing/20220919-00/?p=107195 (the problem with the way this is used, it not used that to pass the 4 GB ram limit, rather is use that as small memory storage) so the next step: back to the app/executable as mentioned there is no compiler that actually generate the useage of segmentation ... therefore you would need a specific app/executable that can do so - and that means chrome still would not pass the 4 GB ram limit (because it cant use segmention) (and then you also would need the windows operating system code also to control this kind of memory managment) also to mention is the FPU unit even the elder ones are 64 bit (or bigger) in modern cpu´s they are 512 bits (AVX) so actually you can make 64 bit moves in 32 bits or calculations, compessions like h.265 do so also some routines are written in the FPU, for example cpu intense sort mechanism´s - you might heared MMX, SSE ect. so in short 32 bit has 64 bit commands that it can use over the FPU unit (what is actually done sometimes) it can pass the 4 GB of ram over multiple app´s/executables it cant pass more then 4 GB of ram with just one app/executable - unless it use a chuckwise method (like the ramdisc) - the segment registers are actually not used to pass the 4 GB ram limit(that also goes for win10 32 bit) so i tryed my best to explain this as simple as i could

Are you sure???????? https://en.wikipedia.org/wiki/V8_(JavaScript_engine) Excerpt from Wikipedia. "V8 is a JavaScript and WebAssembly engine developed by Google for its Chrome browser. V8 is free and open-source software that is part of the Chromium project and also used separately in non-browser contexts, notably the Node.js runtime system. Other server-side JavaScript runtimes use alternative engines, such as Bun and Hermes. Wikipedia Developer(s) Google Initial release September 2, 2008 Written in C++"

It's well hidden: Settings / Privacy and Security / Manage V8 Security (near bottom of page - scroll down) / Don't allow sites to use the V8 optimizer (This will slow down Javascript) Really old Chromium versions (360EE) don't have V8 and so are (presumably) not vulnerable

*facepalm the vista experiment among id*** if i have to write it like so ...

I personally use SAB for deskband support (as well as small taskbar).

https://github.com/advisories/GHSA-mj9c-f5v6-7665 Severity: High (8.1/10) https://chromereleases.googleblog.com/2025/06/stable-channel-update-for-desktop_30.html Manual mitigation, at the expense of performance, if you don't want to update: https://github.com/Alex313031/thorium/issues/1024#issuecomment-3038992237

New release 132.0.6834.226 R5. This release was expedited to cover critical vulnerability CVE-2025-6554 (#1486). Some other changes were made: (#1480) - "Web Scrobbler" extension should now work on Windows XP, as well as other extensions that create notifications (#1473) - Favicons should no longer slide out of tab bounds when dozens of tabs are open in a given window (#1483) - Support for custom tab and new tab button shapes that are derived from an scs file are disabled by default after some users experienced performance declines after their introduction. This functionality is now gated behind the --enable-advanced-customization switch. Unless someone tells me that CVE-2025-6554 (#1486) is really important, I think I'll pass on this one.

off topic: after using for 5 years and wrote ~90TB, my SN750 1TB lost from system first time. following experience from last time, I grabbed my unconnected idle 970evo+ and did a quick clone and let SN750 idle without electricity instead. time to find another m.2 stick with DRAM.

Brita https://nameberry.com/b/girl-baby-name-brita

Fritz

Prize

Bride

brine

trick

Crack

Tracy

Share