user57

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

is someone making that test spoken of ? like j7n did with server 2003 x32 bit´s (its a XP based OS) someone has to disable the pagefile (because theoretical windows can also pass the 4 GB using a pagefile, a pagefile is just data on a harddrive/HDD/SSD) then someone has to use up more then 4 GB of ram, it would be a good indicator, but perfect would be to look of the pages are really in the upper 4 GB ram i meant to turn off the pagefile quite often - but then it didnt do that anyways the pagefile was still not offline maybe daniel k. should say something about this he wrote in a other post that in his opinion both ntoskrnl and hal has to be changed to make xp able to do the 64 GB (dibya said the oposite for example) - who knows who is right daniel k.writes that he modified hal and ntoskrnl (that suggest that that ntoskrnl´s and hal.dll are patched) also he mention symbol files - that also suggest that a ntoskrnl version and a hal version was used to do so you cant just select the patched ntoskrnl.exe and hal.dll by a symbol file searcher you have to figure out what version that ntoskrnl and hal are... then you have to force the disassembler to use the file from the non patched version the filecompare tool will find the changes if you have the right ntoskrnl and hal therefore also daniel k. wrote that he used the free space method for doing the patch this can be risky because some codes only access some free space sometimes, or on certain conditions (this often makes random crashes) a better solution is to add a section or increase a section - you have to know what you do here but - you quickly can kill the files like that if you dont know what you are doing are there more then 3 versions to do so ? its gambling around like "dibya´s" "the russian one" and the "daniel k. one"

well "4 GB is the ram limit for a 32 bit operating system" is finally busted i wonder why even big company´s are still making that fault: https://www.asrock.com/mb/Intel/B560M-C/index.us.asp "**Due to the operating system limitation, the actual memory size may be less than 4GB for the reservation for system usage under Windows® 32-bit OS. For Windows® 64-bit OS with 64-bit CPU, there is no such limitation." to explain the selector/segment or maybe segment selector in the past like 8 bit or 16 bit (sometimes both - aka having 8 bit instructions and 16 bit data) the combination of segment + offset = "real address" also the instruction pharser that read the next opcode, automaticly use the next segment selector (for continuous flow - without chucks) - why this would not be the case for 32 bits ? (it is a cs:eip combination (cs for code segment)) you could write a code either with a selector+offset or just the offset - for "just the offset "the cpu automaticly then choosed the next one (where it then just executes the next instruction) if that isnt doing it there would be still the explained instruction codes that concretly use a selector:offset combination either way if the cpu isnt doing the next segment selector automaticly you still could write a jump at the end of the the 4GB address(or just changing the selector to the next one) https://wiki.osdev.org/Segmentation for a data allocation this would also be of use you could get a DS(data segment) + offset , and directly you would have a 4 GB chuck thats why i always (in like the past i wanted to have a virtualalloc2 function that also gives out the selector) - but me writing that info forums (including microsoft ones) where just ignored the others where already explained , like 4 mb pages (instead of 4k), PSE, PAE - PDE´s , PTE´s and why there is a chuckwise solution (and why this chuckwise solution is useable for app´s/executables/modules)

i dont know but the name "ntkrln64g" sounds like it is a wrapper, maybe a kernel extender ? if not there like many versions of ntoskrnl´s you have to find the right version in that case the searched patches show 7 changes 138-13a is probaly the checksum, that checksum is a "elder driver signature" - if that one isnt currect the system driver (in this case the important ntoskrnl) is not loaded as you may reconized that patch did not touch that ntkrpamp.exe, you should check what ntoskrl was loaded (there are only 3, ntkrnlpa, ntoskrnl and ntkrpamp to check if it use up more then 4 gb ram you should repeat the test from page 7, there is also a page-file that actually can pass that limit you might turn that one off while doing that test

something like this

if /PAE is on windows dont load NTOSKRNL.exe windows then load NTKRNLPA.exe it often sounds like that the things are like very simple, like it can be done within 5 mins but rather often these projects are big. you cant just do like many of them i would be happy if that would be the case, but rather teamwork is required, one person doing all of these isnt possible rather if someone would try he would just have to much to do (and in the end probably no problem was solved) - thats why i didnt want to join a other project then xp for example - we have still a lot to do with xp this one is also not a small one if you dig into the paging system - there are books that describe that mechanism´s and norms (assembly books for example) + getting these into the ntoskrnl before boot the bios also prints out "i have 8 gb ram" the message in the first post also just shows windows saying it have that, but there is no confirmation that it actually is doing that to look for what the patch actually changed there are file compare app´s this is a free one : https://www.file-upload.net/download-15511527/fc.exe.html a small patch theoretical could do it just like that, that´s in range of possibilities with the file compare tool you can look the disassembled code, so you can see with what the patch(es) interferes so thank you to all that help with us, a testing maybe loading multiple apps/executables would be a good idea these running app´s actually should use up more then 4 GB in total, maybe some chrome instances that would tell us more about the functionality of this patch a bit more just 1 app/executable cant pass the 32 bit limit without a selector/segment selector, except maybe there would be the switch option (like the ramdisc is doing) however what the patch maybe could do is that different apps can be mapped to higher ram then 4 GB that only require the right pages that represent the higher area over 4 GB into different executables/app´s to say is that like 99,99 % of app´s/executables dont use selectors, and i never have seen them (also in win7-10) for the purpose to pass more then 4 GB ram the switch solution (like a ramdisc do) works a bit different you can store like 16 gb of ram, thats not the problem - but each time you want to access a certain ram you have to remap that data to an certain virtual offset (thats what a ramdisc is doing, that is very fast but its a piece wise solution) - that solution dont use a selector but - i dont think windows can do that yet but again over multiple executables there we dont have that problem - 4 GB for each running application sounds not bad

that video from reboot12 just shows a very slow interacting opening windows for the "WinXPPAE 3.5 patch" for the other video it shows fast interacting for opening windows not using "WinXPPAE 3.5 patch" it actually dont show a "out of memory problem" is that patch doing something else ? the patch changes you can see with a file comparer i cant dig into a new project, because im already doing one but i would look what this patch actually is doing i remember a elder discussion but, it was either the first release of xp or the second where the "LARGE PAGE" discussion apeared and the "LONG MODE" in the past it has only 4K pages in the norm so that XP discussion claimed to use the large page where the discussion was about instead of 4K paged, was changed to 4 MB pages they called it "the long mode" so here might be a possible catch, that 4 MB pages where in that discussion said to be buggish and slow in interaction ... while AMD claimed to be able to use these 4 MB pages without any speed loss do someone might remember that discussion ? i only remember that this version then quickly got removed, later /PAE apeared (and claimed to use 4k pages in PAE, and having faster speed) what i wrote about the long mode and large page should be considered as discussion (it might not be correct, or need fixes , i just try to point out a elder discussion - for example if i google "long mode" now it just says "thats the x64 bit mode" - but thats not what was discussed that day from the past)

one way i could think of would be to check the PTE´s and PDE´s if the physical ones actually point to the higher physical ram for this you need to write a tool that reads out the PTE´s and PDE´s for each running app/executable that with the physical ram is simple to understand, app´s/executables have "offsets", these offsets then have a "virtual offset" that offset then can be "mapped" to everywhere in the ram like in lets say 64 gb of RAM into the 60 GB part of the ram to see if the upper parts higher then 4 GB are used you probaly have to start enough of app´s/executables that use up the 4 GB ram if so some of these app´s/executables should have PTE´s and PDE´s pointing to higher physical ram then 4 GB another way would be to look the source code the ntoskrnl is likely to control that and the WRK is like open source (once published by microsoft for students to study) it would requie to look these codes if they are doing it - it´s some work to dig into this but we dont know exactly what this version of ntoskrnl in that WRK can do - but in the past there was the LARGE PAGE discussion and the so called "LONG MODE" in "LONG MODE" pages are not 4k they are 4 MB (that was one possible way to pass the 4 GB limit because the bits representing the physical connection are then 1024 times more) to explain all the things in paging i would have to write a bit to much now, its like an entire book, as mentioned there are 3 PSE,PAE,PAGING lets just say for PAE PAE (in 32 bit) consits of 64 bit PTE´s and PDE´s, not all of the bits are where the page is, for a better explaination i suggest to look that here: https://wiki.osdev.org/Paging not having 64 bits is not a problem because the pages are to be multiplyed by the page size as mention like from 4k to 4 MB also its a combination of PDE´s and PTE´s depending on the mode what was set also the norm of the PTE´s and PDE´s are changing so on the osdev wiki website you look for the 64 bit entrys, above is a 32 bit entry explaination, 64 bit entrys are not to confuse with the 64 bit mode (that a x64 OS has) it just describe the size of the PTE´s and PDE´s, they have been 64 bit of size in a 32 bit OS since PAE was around (PAE came with the NX flag, then having that 64 bit entry for the first time) here you read out where the physical pages point to, therefore you then have the information if ram over 4 GB was used

i forgot the about RAMDISC that AWE was already used in the past with RAMDISC´s (and used more then 4 GB of ram in xp in the past like this) but it has the problem i described before, it can fill more then 4 GB of ram (or the upper parts past of 4 GB physical ram addresses) but then you have to "remap" that pages into a virtual offset - that goes fast but its a small step to do (you have to make it in pieces then) for an app/executable that might be different, because multiple apps/executables mean more virtual offsets for each app/executable therefore the app´s/executables then would be able to use 4 GB of ram in every executable (every app can be seen as a extra virtual offset) - in this case windows then just maps the higher physical ram (for example physical ram addresses from 5-8 GB) - that is possible thats because useally you only see the "virtual offset" - it is not a physical address so then you would have 4 GB each app/executable to mention a other problem, chrome or an application are not always "flawed" either, they actually have bugs for example i have a win7 machine where a memory crash always apear after some time bigger app´s dont useally have a own controlment for its memory, they use a engine - in this case probaly a memory managment engine that win7 chrome is bugged with a "untouched download" from chrome for me so it not neccesary has to be always a error of the backport for example to windowsXP well about that patch - i havnt worked on it so its hard for me to say if it is really doing its job what i can see but is that this patch dont show its connection for the PTE´s and PDE´s - that would be a neccesary thing it must can handle (the patch is incredible small) let´s say it cant, then it might print out "i have 16 GB of ram", but the progress might not be done maybe the patch just works - that would be possible the patch should be tested, or maybe someone comments if he already has tested that patch, maybe someone has knowledge what dave wrote sounds a bit like that it actually dont work chrome make multiple apps/executables - and if its doing that it has at least 2 GB of ram for each app 2 GB should be enough for one TAB by like a far if that out of memory error apears when a lot off app/executables apears it would be an indicator that the patch dont work because it cant handle the PTE´s PDE´s or maybe other parts of that progress (that handle the controlment of physical pages above 4 GB) then it would try to use the first piece of the 4 GB ram and that error would apear so hard to say, but i would try multiple apps/executables that actually use up more then 4 GB ram

the website still exits https://catalog.update.microsoft.com/home.aspx keyword is "Microsoft .NET Framework Version 1.1" the others are upgrades you have to first use the main installer what is around 24 mb

the most upgrades use the a installer the older ones are made via InstallShield (suspection is that these are made with VC6/VS6) the newer ones seems to be made with the InstallShield from VS2010 they have 1 important thing in common both create a .inf file for .inf files microsoft has a "installer engine" like "CopyFiles" or "AddReg" therefore you can combine all the upgrades using that "installer engine"/"inf installer". that engine can do multiple things but the most 2 things are registry and filecontrolment this has a problem that engine is not very fast - it is probaly made for smaller installers these .inf engine then use very windows common functions to control the registry and the files like MoveFileEx, RegOpenKey ect. there is also a famous bug with some of the registry entrys: office 2010 create context menu entrys that context menu is controled by explorer.exe (where office made entrys) but at some point the deeper function cant handle the corrupted Heap RtlAllocateHeap then is failing, it is failing because the Heap got currupted, RtlAllocateHeap is called by every alloc function that bug can be considered a windows error because RtlAllocateHeap should not fail just because the Heap got corrupted

maybe it would be possible over this what microsoft calls AWE https://learn.microsoft.com/en-us/windows/win32/memory/address-windowing-extensions however it seems to give control over physical pages but it is connected to a virtual address but it is not using a selector going with only 1 executable, that means you might can map more then 4 GB of data piece wise but always when you want to access that RAM/data you have to remap it to a virtual offset and just thinking around if that AWE is used by internal functions of windows - thats maybe how windows xp passes the 4 GB limit - in a post before i wrote its possible to map the other ram (higher then 4 gb) in a 32 bit system (or with a different name "pages") thus xp could map ram above 4 GB in multiple applications (that sounds very similiar to what i wanted to point out) having the "multiple app/executable" solution is not that bad so you actually use up the 8 GB 16 GB or whatever you have installed in your computer chrome is the best example right now i have 24 open executables of chrome (with 3 times google started up)

there are 3 that can exceed the 4 GB limit PAE PSE PAGING lets say this patch works, it dont exceed the normal 4 GB limit what rather is like 2 GB per running executable/app - this is because the usermode useally takes 0-7FFFFFFF addresses the rest is in kernel mode (80000000-FFFFFFFF) so somewhat somehow it can use that 4 GB per app, but its split apart (2 gb usermode memory and 2 gb kernel mode memory) to have a little more userspace, there is a smaller solution to pass that 2 GB limit to a 3 GB limit https://learn.microsoft.com/en-us/windows/win32/memory/4-gigabyte-tuning then the usermode limit is 0-BFFFFFFF and kernel mode is C0000000-FFFFFFFF (3 gb usermode, 1 gb kernelmode) but back to that important answer, normal apps dont use for example segments to exceed that 2 GB/maybe 4 GB limit but there is actually a different reasoning why the 64 GB are use anyways and that reason is that you dont have just 1 app/executable running on XP those different apps then can point to a different spot in memory (aka passing the 4 GB limit) so having multiple applications (for example google use a lot of extra/or restarting applications/executables) is also a solution to use the 64 GB ram have the patch ever tryed to be functional ? norm-wise it is certainly possible, someone might actually run a lot of big applications and check what physical memory pages are mapped out to make a paging example there are segments https://en.wikipedia.org/wiki/X86_memory_segmentation but XP barly use these segments (nor do 7 8 or 10 - and if they do they are not used to pass the 4 GB limit) for example in a older normwise app there is this segment (often called a selector) that is using the CS:EIP combination to execude the code flow, while the data access DS selector can access a different part in memory - but that wasnt happening - both DS and CS where made to point to the same memory in like win98-win10 OS`s the ES segment for example could be a choice to pass the 4 GB limit over the segment solution a even simplier idea would just to use the next counter for CS but if you then disassembly the applications you can see that the executables/apps are not using that - that goes for 99 %+ of apps/executables - also they cant if the OS/kernel mode dont have a controlment for this the most applications/executables dont have the selector being used but you can write an access with like a code using "cs:offset" instead of just "offset" besides the software, also a role plays if the hardware can do it, some still have 32 wires, then the CPU might be able to do so, but the motherboard dont have enough wires

have you tryed with XP ? it is said to not have this problem, but im not certain either