user57

interesting thats neither "atomic" in both 2 moves nor the non interrupt flag i wrote dietmar he might leave it out in a private message also it dont have the checks or the loop, and the cmp cmpxchg8b is not done correct maybe it just fulfills that functions needs that can be, instead of just replacing the function the function where written to its real needs so we didnt had to be so specific, just for the correct function reaction well done

roytam gave you the patch code, it are 5 changes lea ecx, sub_40078C <--- thats the first function that this replaced if it founds that cpuid number (ExInterlockedCompareExchange64) lea ecx, loc_4006F0 <-- next (ExInterlockedPopEntrySList) lea ecx, loc_400704 (ExInterlockedPushEntrySList) lea ecx, loc_400714 (ExInterlockedFlushSList) lea ecx, ExInterlockedAddLargeInteger last one is different it replace sub_402352 with ExInterlockedAddLargeInteger somebody can tell that the functions are at these places

well i would think a different offset is possible but if they are equal it exchange that offset with ECX and EBX (it overworks those) if you know about logical circuits you might know why but exactly this is why i wanted to say he dont need that command at least i dont see a reason for that the function itself seems to compare: "if (this offset 64 bit entry still has the same value as EAX and EDX) -> change that offset with ECX and EBX (then it actually has a 64 bit changed value there)" functions descriptions: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-exinterlockedflushslist https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-exinterlockedpopentryslist https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-exinterlockedpushentrylist "If there were entries on the specified list, ExInterlockedFlushSList returns a pointer to the first SLIST_ENTRY structure that was an entry on the list; otherwise, it returns NULL." this opens the question why they used this command to return an pointer offset to the first SLIST_ENTRY structure and changing that SLIST_ENTRY (what is a internal windows structure) about that "atomical" it "suppose to be" a "non interruptable doing" therefore dietmar probaly deleted the interrupt flag (so no interrupts - actually it still do that - but thats a other story) (the other is the "lock" command) the next question what comes to mind is changing 64 bit at once (non interrupt doing), not stepwise that that cmpxchg8b actually do (even tho its 32 bits - it just use 2 registers) BUT i never seen that to be needed for 64 bits, that far to small to have an interaction, not even interrupts if they are changed up (and those are constandly used) have that problem https://www.quora.com/What-is-the-meaning-of-atomic-in-programming we also talking about a function here , so the function itself might actually be "atomical" if it solves its job, because the function has a start and a end to solve this step we are not in c++ that might has a code "atom (this)" in assembly you have to write the real instruction that physical do so (if that was a problem we might have some more answers for now) dietmar just said that he wants to remove cmpxchg8b with a working alternativ code, it might be a little road but over time we will find this i highly suspect that list is for threading/multicore

i heared chappell died a few months ago, sad story we could still need him reading chappells writing it says that there once was a solution that dont use the command if not supported by cpu that dont neccesary say if you just use a different one from a different OS version that it just work - maybe - maybe not why would it has to be that other cmpxchg command the linux one is not perfect - depending on what the other routines do, the linux one might work, but certainly its not 100 % correct, while mine is the linux one looks almost the same to the one i posted up, but it dont compare the 64 bits for the false result (maybe the linux solution dont need, but again mine is correct the linux one is not) so why not "just the right one" doing it a other way cause more commands and maybe fixes, there are certainly multiple solutions https://www.felixcloutier.com/x86/cmpxchg the description might be wrong this time, the description here unlike cmpxchg8b it always compares EAX with the memory location the description actually dont tell that a other register then EAX can be choosen well this time your code might work but you rather trying to fix the results, the ZF non reaction is set to just go back that is ok but you have to do this in every function like this then also that makes 2 times locks xchg and 2 times lock cmpxchg you do cmpxchg for the atomic question ? if you have to change 64 bit at once then it might be atomic for the 64 bits, doing 64 bit in 1 step just having the lock prefix dont change it to a 64 bit mov

LOCK CMPXCHG [EBP], EAX <-- that already makes a change if that was the case but it actually need the 64 bit compare, before making any changes because if both 32 + 32 bits are not the same it dont do that thats the first mistake again that other part has no decision, it both jmps on ZF 1 and ZF 0 .data:004762D5 jz short loc_4762E1 .data:004762D7 jmp short loc_4762E1

.text:8013CEA0 ExInterlockedPopEntrySList proc near ; CODE XREF: CcScheduleReadAhead+2BB�p .text:8013CEA0 ; sub_80108058+10�p ... .text:8013CEA0 push ebx .text:8013CEA1 push ebp pushf cli .text:8013CEA2 mov ebp, ecx .text:8013CEA4 .text:8013CEA4 loc_8013CEA4: <-- this seems to has a jump to ; DATA XREF: .text:loc_80140E17�o .text:8013CEA4 mov edx, [ebp+4] .text:8013CEA7 mov eax, [ebp+0] .text:8013CEAA .text:8013CEAA loc_8013CEAA: // valid ; CODE XREF: ExInterlockedPopEntrySList+1C�j .text:8013CEAA or eax, eax .text:8013CEAC jz short end_of_ExInterlockedPopEntrySList // has to be changed .text:8013CEAE mov ecx, edx .text:8013CEB0 add ecx, 0FFFFh .text:8013CEB6 .text:8013CEB6 loc_8013CEB6: <-- seems to have some jumps at too ; DATA XREF: sub_80140AF4:loc_80140AFD�o .text:8013CEB6 ; .text:80140D28�o .text:8013CEB6 mov ebx, [eax] cmp eax, [ebp+0] jnz loc_fail // something we did cmp edx, [ebp+4] jnz loc_fail // again mov [ebp+0], ebx mov [ebp+4], ecx jmp loop_check_ExInterlockedPopEntrySList // the loop check loc_fail: mov eax, [ebp+0] mov edx, [ebp+4] .text:8013CEB8 loop_check_ExInterlockedPopEntrySList: .text:8013CEBC jnz short loc_8013CEAA // valid but need fix to that or eax,eax loop .text:8013CEBE .text:8013CEBE loc_8013CEBE/end_of_ExInterlockedPopEntrySList: ; CODE XREF: ExInterlockedPopEntrySList+C�j sti popf .text:8013CEBE pop ebp .text:8013CEBF pop ebx .text:8013CEC0 retn .text:8013CEC0 ExInterlockedPopEntrySList endp ------------------------------------------------------- well data refs dont make sence at these spots, bug view ? at 8013CEA4 it says it get 1 or more jumps and says from 80140E17 is 1 of the jumps - since the pushf and cli changed the offset 2 bytes therefore the jump is gambled if not location fixed it would be common to see some jumps into different functions and oposite location 8013CEB6 seems to bejumped at _80140AF4:loc_80140AFD�o .text:80140D28�o (you should look at least that 3 spots for this jump) looks ida disassembler to me you at best search for that address where they get jumped from the jz at 8013CEAC has to be fixed to jump at the end that is sti / end_of_ExInterlockedPopEntrySList .text:8013CEAC jz end_of_ExInterlockedPopEntrySList .text:8013CEAA loc_8013CEAA: that one is valid, but since we have more code the jump that do this is a bit bigger but that one is shown in the visable code at 8013CEBC jnz short loc_8013CEAA .text:8013CEAC is valid but also need a adjust to reach the (loc_8013CEBE/end_of_ExInterlockedPopEntrySList) if you want you can try to remove sti,cli popf pushf (but have to be all 4) --------------------- you actually could also use a different method cmpxchg8b has 4 bytes of opcode jnz short has 2 aka 6 bytes you need 5 that makes jmp at your location + 1 nop cmpxchg8b qword ptr [ebp+0] jnz short loc_8013CEAA those to you replace with your memory location , use jmp + nop you memory location then do cmp eax, [ebp+0] jnz loc_fail2 // something we did cmp edx, [ebp+4] jnz loc_fail2 // again mov [ebp+0], ebx mov [ebp+4], ecx jmp the_check // the loop check loc_fail2: mov eax, [ebp+0] mov edx, [ebp+4] the_check: jnz short loc_8013CEAA // this one conditional jmp to that loop (or eax, eax) // now you just have to jump back jmp to (.text:8013CEBE loc_8013CEBE/end_of_ExInterlockedPopEntrySList) / just backwards as if the command has happend i dont know if that NT version can be used for XP they might have used a different behavior

at the moment 3 makers are (image called the .avif) AOM SVT-AV1 rav1e one called the HEIC/h.265/x265 by hardware (for example nvidias NVDEC) all of those say that they are new hevc (h.265 codecs) is there a proof ? hardware might be faster at the moment but not better (1:12 or 9:29 the mountain in the background) software is a lot more clear, SVT both P3 and P6 are better: https://youtu.be/5rgteZRNb-A?t=72 another candidate for pictures is JXL https://www.youtube.com/watch?v=w7UDJUCMTng but we have to consider what settings where used, that actually makes a big difference while others even tell something about a h.266 codec https://de.wikipedia.org/wiki/Versatile_Video_Coding there should be a real comparison, always going for the best settings the encoder offers , both picture and motion video (also looking b frames, because often some pictures that are secondary are just stronger compressed - in this case the first picture might look good, but the second rather looks blured)

public ExInterlockedPopEntrySList .data:004762F2 ExInterlockedPopEntrySList proc near ; CODE XREF: sub_40E06D+1DAp .data:004762F2 ; sub_41159B+8Ap ... .data:004762F2 push ebx ; ExInterlockedPopEntrySList .data:004762F3 push ebp pushf cli .data:004762F4 mov ebp, ecx loc_jumper_unknown: .data:004762F6 mov edx, [ebp+4] .data:004762F9 mov eax, [ebp+0] .data:004762FC .data:004762FC loc_4762FC: ; CODE XREF: ExInterlockedPopEntrySList+17j .data:004762FC or eax, eax .data:004762FE jz short loc_end .data:00476300 lea ecx, [edx-1] loc_jumper_unknown2: .data:00476303 mov ebx, [eax] .data:00476305 loc_jumper_unknown3: cmp eax, [ebp+0] jnz short loc_4762E5 cmp edx, [ebp+4] jnz short loc_4762E5 .data:004762ED mov [ebp+0], ebx .data:004762F0 mov [ebp+4], ecx .data:004762F3 jmp loop_check .data:004762E5 mov eax, [ebp+0] .data:004762E8 mov edx, [ebp+4] loop_check: .data:00476309 jnz short loc_4762FC .data:0047630B .data:0047630B loc_47630B: / loc_end: ; CODE XREF: ExInterlockedPopEntrySList+Cj sti popf .data:0047630B pop ebp .data:0047630C pop ebx .data:0047630D .data:0047630E .data:0047630F retn .data:0047630F ExInterlockedPopEntrySList endp for the c++ code you just have to look the translation that the c++ compiler did , if equal good for this other function there is a jmp to "mov ebx, [eax]" from 40a7470 (this means if change is changed that jump has to be adjusted to there (if not bsod from other part of this code) (since you added assembly commands in the start (we could make rid of pushf, cli , sti and popf) to keep that location at place (that is extra jump missing in your 3 post of code too) it has 3 jumps that has to be fixed from other parts 0040B0DE jz short loc_40B0EB (has to be adjusted) it has more code below now the others i have wrote locations, i think you can solve this tell me if this works that command dont work in my VM so i actually cant see how it reacts if i could that would it make a lot easier

happy to see you had a good result is it working now ? do this one work ? the jumps have to fixed to the right locations .data:004762B2 public ExInterlockedFlushSList .data:004762B2 ExInterlockedFlushSList proc near ; CODE XREF: sub_45F0DF:loc_45F0F7p .data:004762B2 push ebx .data:004762B3 push ebp pushf cli .data:004762B4 xor ebx, ebx .data:004762B6 mov ebp, ecx .data:004762B8 mov edx, [ebp+4] .data:004762BB mov eax, [ebp+0] loc_1: .data:004762BE or eax, eax .data:004762C0 jz short loc_end (004762F7) .data:004762C2 mov ecx, edx .data:004762C4 mov cx, bx .data:004762C7 .data:004762C8 .data:004762C8 .data:004762C8 .data:004762C9 .data:004762CE .data:004762D0 .data:004762D1 .data:004762D1 .data:004762D1 .data:004762D7 .data:004762D9 .data:004762DB ; --------------------------------------------------------------------------- .data:004762DB ; emulation of CMPXCHG8B .data:004762DB .data:004762DB cmp eax, [ebp+0] .data:004762DE jnz short loc_4762E5 .data:004762E0 cmp edx, [ebp+4] .data:004762E3 jnz short loc_4762E5 .data:004762E5 .data:004762E5 .data:004762ED .data:004762ED mov [ebp+0], ebx .data:004762F0 mov [ebp+4], ecx .data:004762F3 jmp loop_check (004762F3) .data:004762E5 mov eax, [ebp+0] .data:004762E8 mov edx, [ebp+4] .data:004762EB .data:004762ED .data:004762ED .data:004762ED ; end emulation of CMPXCHG8B .data:004762F0 ; --------------------------------------------------------------------------- loop_check: .data:004762F3 jnz short loc_1 (004762BE) loc_end: .data:004762F7 sti .data:004762F8 popf .data:004762F9 pop ebp .data:004762FA pop ebx .data:004762FB retn .data:004762FF ExInterlockedFlushSList endp

you making the same mistake that command sets flags, and react if the compare was correct or not there 2 problems i can certainly tell in the first step cmpxchg can have 2 results (if equal it makes the mov if not it makes the mov to a register) (and it should not do that because it has to compare 64 bits) if you have 32 bits with the compare it reacts already to the 32 bits (the other 64 bit are ignored) then the following happens : the flags are lost and the reaction - for equal 32 bit already reacted or not then you do the code again but here sits the same problems now the flags get changed a second time (and it should not) the compare depending if equal reacts to the next 32 bit (while igoring the first 32 bit) if that compare was equal it sets the values and if not it sets no values (but you need the 64 bit) the flag registes (ZF) is that readed as if the first 32 bits are not there with other words the results are gambled up the solution looks not that hard to me you need 2 compares to see if the wanted to compare 64 bits are equal before you set the 64 bits reactions if those 2 compare where equal you set the values at the memory location, in the other case you need an extra reaction to set the other case the reaction stores them into EDX and EAX (the flag should still be activ, unless you start to use a command that affect flags) cmp edx and eax (destination operand) if equal store ECX EBX to destination operand (The destination operand is an 8-byte memory location) // CMPXCHG8B should be removed and followed by this code: // CMPXCHG8B - 32 bit emulator cmp dword ptr [ebp],eax // eax suppose to be the low part jne skip_and_load_edx_eax cmp dword ptr [ebp+4], edx // edx suppose to be the high part jne skip_and_load_edx_eax // 64 bits where equal, change with ECX and EBX mov dword ptr [ebp], ebx // suppose to have the low part mov dword ptr [ebp+4], ecx // suppose to have the high part jmp end_of_CMPXCHG8B // they where not equal do as the command is described and load those to EDX and EAX skip_and_load_edx_eax: mov eax, dword ptr [ebp] // suppose to be the low part mov edx, dword ptr [ebp+4] // suppose to be the high part end_of_CMPXCHG8B: // CMPXCHG8B - 32 bit emulator end // normal code continue this emulation for the 1 line of CMPXCHG8B, it also should have the correct flag jumps might need a adjust to their usual locations // notice i could not test that command if the order is right (like upper and higher parts) it might said something about the upper and lower part but as i remember right you never can be exactly certain about this (in memory if you have 11223344 - the 44 are the bits that control the high values (very old architecture stores that differently too - but in this case we dont have that problem even in a 486) if that dont work i certainly can fix this, i need a test to make certain the command reaction after that i can see its exact behavior the command description however says EDX and ECX contain the high part https://www.felixcloutier.com/x86/cmpxchg8b:cmpxchg16b if the high order is different then just the spot change from ebp to ebp+4 and ebp+4 to ebp (or change the registers assigned to that ebp locations) : // CMPXCHG8B - 32 bit emulator cmp dword ptr [ebp],edx // if different edx suppose to be the low part jne skip_and_load_edx_eax cmp dword ptr [ebp+4], eax // if different eax suppose to be the high part jne skip_and_load_edx_eax // 64 bits where equal, change with ECX and EBX mov dword ptr [ebp], ecx // if different ecx has the low part mov dword ptr [ebp+4], ebx // if different ebx has the high part jmp end_of_CMPXCHG8B // they where not equal do as the command is described and load those to EDX and EAX skip_and_load_edx_eax: mov edx, dword ptr [ebp] // suppose to be the low part mov eax, dword ptr [ebp+4] // suppose to be the high part // your 55667788 example say so end_of_CMPXCHG8B: // CMPXCHG8B - 32 bit emulator end

well you certainly can translate this command to a 32 bit variant code you already have used the "cmpxchg" assembly command but it actually should do the wrong job sometimes because that compares up only 32 bits (and then already react to the 32 bits) (if that compare was the same or not already changed the result because it can already react to either the first 32 bits or the next 32 bits) (.data:004762D5 jnz short near ptr loc_4762BE+1 - that done again erased the first 32 compare results and only react to the next 32 bits compare) but you need the result for 64 bits compare! it seems to me that you can also solve this problem by : making 2 compares "cmp" commands for the flags/reaction now it is about not to make the same mistake (if you do just the 32 bit compare again it reads the next 32 bits and ignored the first 32 bits from the first compare) you need a reaction to the first compare (if that was the case) and making the "cmp" command again and react a second time if both compares was correct you make the reaction just as described (else the other described reaction) : https://www.felixcloutier.com/x86/cmpxchg8b:cmpxchg16b that command description actually dont say something about exchanging the values it just says that if the 64 bit compare was equal it says "if the compare was equal the values in it stores the data in ECX and EBX in other case in EDX EAX (what dont look a exchange for me) - maybe the description lacks (what i useally do then i try it out and take looks) // if it would be an exchange it would be: (later reading the code i dont see a common exchange a common exchange would be if eax would be changed to edx - eax having eax and edx having eax): 4 assembly "mov" commands (2 for the destination and 2 for the source) or: 2 times the "xchg" command // but ! looking the assembly code from you it seems different to me i dont see a exchange (just let me say im not entire certain here, but it might helps to talk about that): the cmpxchg8b command seems to compare registers EDX and EAX for equal and then changing an offset to a memory location (stack register two "EBP") (qword ptr [ebp+0]) (qword useally describes a 64 bit movement (word * 4 (16 bits * 4)) if that result was equal it should store EAX and EDX to that offset (otherwise it probaly loads that values to EDX EAX) the next command is "jnz" that command still has the results from this compare, if they was equal it jumps back to "Efls10" (what seems a loop to me) if not it continues the end and and this function seeing your code again "lock cmpxchg [ebp+4], eax" dont have a reaction but it might need (as said before it need a reaction to both of the 32 bits) if that was not the case it need to end this (not always just continue) done that way the first 32 bit can have a false result - and if the next 32 bit are right - then it just still do the job - while it should not --------------------- if the 64 bit guys apear, that is not neccesary needed if you have to use more then 32 bits there are severial methods you can solve this (to name a few) 1: one is using 2 registers and just create its behavoir for that there is a such 32 bit assembly command that is used for that ( CDQ - Convert Word to Doubleword/Convert Doubleword to Quadword ) 2: an offset to somewhere in memory that is bigger then 32 bits and control it as 64 bits 3 (even more is possible with a offset location): if you have more then 64 bit flags you just need an offset to a location , where you actually control the flags/ or data 4: for file movements there is for the REP command the CPU actually can see that it has to move a certain amount of data, and the cpu can translate the filemovement to something it actually can progress the FSB (quad pumped) to the RAM is doing a such thing unlike the 64 bit guys might would think you dont need a 64 bit offset for this a other example would be the CACHE, HDD´s use a CACHE to fill up the data that data can then be progressed differently - like with 2 bit(wires), 4 bit, 16, 32, 64 or even more (it rather comes down what the physical cable/wire can do)

my "DOS" got a little old, but i remember that "going to DOS mode" from windows often resultet in a non "well-working" DOS i also remember you had to press the menu button ( i think it was F8 before windows starts) , and select the DOS boot (instead of windows) then you had a nativ DOS , where most DOS apps actually then function in the windows to dos not all DOS apps worked so this one fix this problem ?

Dr. Stone

right youtube unlike in the past much look like a commercial tv channel the idea however was different it was a plattform for users that tube (you) - tube it was a challenger against exactly this there where no ad´s, there where no odd filters i remember the makers had a such discussion about this in the past and denied to "connection" to the common others but slowly it more and more got into that direction the same happens to google search at the moment, it find nothing anymore in the past youtube also had challengers like veoh and other video plattforms it looks hard to me to find a replacement for youtube at the moment - but if youtube continue that way it might be the only option to go to a other plattform one challenger the commercial tv wont get rid of the is the smartphone, it basicly has replaced the common tv i gone away from google search already, here we have alternativ plattforms

if its based of the "gdi chromium project" i might have a guess , im not certain but if i remember right that problem with the sometimes a bit missplaced fonts apeared by release there was a small routine from google for gdi to sort the font, that he actually no longer used i a older release (that was not public) it still had that code it is only a a guess - im not certain at all - it takes me 7 days to compile chrome 1 time

that would make sence too, but then again , exactly this existing already in the past and then we have the same answer "every exception handler can do this - not only the except_handler4_common"

how you actually write your vista driver ? when you have the code open source we might actually can make a new driver you didnt say the other part so clear, did you make a vista radeon driver of a new version ? like 2024+ ?

well the one-core-api has this function, it could be added to that msvcrt.dll there some ways to do so but it useally dont end with just one function but since chrome is open source why not just adding an exception handler at the place where chrome wants to have one it might can be ignored either, if that problem apears the app useally crash anyway - even with an exception handler

that thread function just set attributes if i see it directly without going into detail i would suspect it´s predecessor is CreateThread and createthread has higher tier function after that called ZwCreateThread or NtCreateThread // attributes : InitializeObjectAttributes(&ObjectAttributes, NULL, 0, NULL, SecurityDescriptor); // the thread function : Status = ZwCreateThread(&Handle, THREAD_ALL_ACCESS, &ObjectAttributes, ProcessHandle, &ThreadCid, &Context, &InitialTeb, CreateSuspended); that _except_handler4_common is a exception handler an exception handler apears when a bad memory access has happend (what not must even happen) any exception handler (and xp has this so do win98 or win2000) can be used for that we dont need that certain version ... for processes it´s Createprocess here the same thing happens we actually dont need the vista structure what maybe has 1 difference (startupinfo to startupinfoex) those 1 extra field is for misc stuff, not for its purpose (just to start a new app/process) - that can be done without that too chrome probaly use it to create new open "tabs" , nor it need that function InitializeProcThreadAttributeList to function that is probaly just a check if that function was set , then returning a error - that certainly can be reprogrammed again this extra info is not needed to start a such tab

well according to microsoft more then 4 GB ram is possible in 32 bit: https://devblogs.microsoft.com/oldnewthing/20090706-00/?p=17623 the microsoft guy even says how however it seems the other links are deleted from microsoft for whatever reason - is there something to hide ? he says CreateFileMapping can create 4 GB fragments (he isnt saying segments what is kinda correct) he also mention the 2GB to 3 GB extension, but 3 GB is a bit small when you actually want to more then 4 GB CS:EIP is a combination CS has 16 bits and the EIP (called the code segment(cs) and instruction pointer (IP)) for data there would be a way to use an extra DS (data segment) , that would give 2 (segments or with the ms guy´s words to fragments of 4 gb address room) the EIP pharse the instrutions , 4 GB for instructions is actually a lot DATA is unspecific but you guys can tell what that is , a RGB buffer, a FILE, a GAMES 3d object, a VIDEO - those are not instructions those are just memory or "DATA" DS is actually in use but even then why not ES (extra segment) or maybe making a better use of the GS (global segment) i tryed to ask if the 128 GB patch actually really works, i think it do - but actually i dont seen a proof the other already mention 2 approaches where the PAE and PSE not to forget the PDBR/CR3 (that is what points to a different app) and then the PTE/PDE ect. can point to different ram - so over that also more then 4 GB of ram would be possible the PDBR/CR3 solution is app limited, but having unlimited amounts of 4 GB app´s is not that bad

well x64 needs more ram then 32 bit but there more things involved that play a role - i dont know all either maybe it is time for a little discussion ... the instruction code is a such example, when you ask for a offset that is greater or in a higher area of 4 GB that questions is hit for example a other thing is coding a int 32 is 32 bit big (and so stored like this in memory) a int 64 need 64 bit memory thats a important reason that the offsets need to store instead of 32 bit 64 bits this "offset size, int size, register size" question follow you in many times i made a screenshot of a x64 app (regeedit.exe) , os is win7 x64 the app is shown as x64 in pe editor as in taskmanager BUT! it use x32 bit instruction sets ! as shown in IDA so in reality thats rather an 32 bit app when i compiled some apps up i saw a increase in file size not 100 % but like 50 % and if i rememberright (in some older x64 apps i meant to see they tryed to avoid this problem in only using 34 bits, that probaly dont work all the time)

you actually may not need a fast grafic card for an old game either, some just give a old card they no longer need - because often they get thrown into the trash bag even the prices are often like very low maybe 5 dollars, thats affordable

well unlike nvidia the radeon card´s have a different driver on the radeon´s website actually dont find any information what the latest drivers for certain OS´s are and what grafic cards they actually support that is better solved with nvidia, there at least for the moment you find that information i think the right status about that radeon driver is not having a well solution at the moment but again you might buy a nvidia card if you need windows xp as operating system radeon lost a possible customer that would pay them money ... the other only quick way would be to find the lastest available radeon driver, and buy a older radeon card (but thats not a good solution in my opinion) here is a such discussion https://www.majorgeeks.com/files/details/amd_radeon_video_card_drivers_for_windows_xp.html if you just missing a driver for XP for that card the kernelex patches actually dont solve all the problems (the one core api also has some) therefore your question would actually change, you dont have a OS problem anymore you have a missing driver problem, due a unsupported grafic card some games actually dont work on certain operating systems, i think Resident Evil 1 needed windows 95, and the dos c&c 1 version needed a nativ DOS bootet, and did not work on windows xp either in that case the one core api dont fix the missing functions either - coming from an ask that a newer grafic driver just installs on xp the current kernelex dont have enough functions for a newer driver ---- that with the driver signs i had actually that problem too (win7 actually also has different versions with 2 different driver sigs) my usb drive was blocked and i wondered why it did that with with an upgraded win7, while the non upgraded win7 did work no problem the solution is simple while boot up you bring up the boot screen via holding F8 when the first menu apears you hit F8 again , and there you can disable that driver signature after that my usb driver installed without any problems ... ( i still use a digital camera, useally not smartphones) you should have been told that the most games actually dont run not having a grafic card driver, makes sence after all

well it is actually hard to say if your problem is a driver problem for xp we have this one that support new grafic cards: https://msfn.org/board/topic/181454-official-driver-supporting-gtx-970-and-up-found/ your card seems to be a desktop card, there should be drivers ---- in lap-tops some companys use a trick to hide the grafic card they use for example they use a different name for their card like instead of "gtx 970" they use "gtx 970 hps" this make the common driver that would work not install but you actually can add that driver into the .inf file (then the driver finds thecard) in the driver installation you also can choose a driver that you want to install for this card you can force to install that driver, that also works but thats for lap-tops using that "trick" ----- what games are these actually ? xp has a well balance between backwards and forwards compatibility that win7 + (use xp modus) is useally not working often a placebo that trys to make people think win7 can do what xp can do (for marketing like "oh win7 can do xp, buy win7, buy win10") (what in reality it can 99 % it can not) to fix your problem we should take a look on the game or game(s) itself beginning with the question what game you first wanna use then we should know if that games or games work in a nativ xp machine or not (xp dont have 100 % backwards compatibility either - xp might have a lot here but not the absolution) the "one core api" is not for old games, it actually is for new applications and games that have functions that xp useally dont have the one core api therefore is for new games, therefore it dont make sence to use one core api on a old game if you have a dos game it might dont work, dos games often need a nativ 98 machine bootet into dos commander and conquer 1 (dos version) would be a such example, there are windows versions too but ---------------------------------- to the 8 GB problem i can say this there are page table entrys (that leads to the physical ram) , those can addresse more then 8 GB however for example the EIP 32 bit for example can only address 4 GB then however that EIP - can with a different application (games are applications) address different memory - therefore having multiple applications/games/executables/processes (is always the same thing) can theoretical address more RAM but here is the next problem the OS not always seems to use that (xp dont i heared, with the 128 gb ram patch it suppose to do it) a other thing i have to point out are segments, and maybe the PDE/PTE´s a segment is a selector for a specific amount of ram since we have 32 bit (what are 4 gb ram) every segment actually could point to 4 GB ram but applications dont use segments (what you can see with a disassembler every common app dont use segments) these segments are in 32 bit protected mode 16 bit wide therefore 16 bits = 65535 and that times 4 GB = 65535 * 4 GB ram https://en.wikipedia.org/wiki/X86_memory_segmentation a other problem can be the hardware lets say the CPU only got 32 wires , then the software could use more then 4 GB ram but the cpu actually can not use more then 4 GB ram but here kick in the segment question again the CPU actually can translate that segment to the next segment (the first segment is 4 GB ram) - again with 65535 possibilites (4 gb * 16 bit (65535)) so the 32 bit protected mode actually has not 32 bit, the 32 bit protected mode theoretical got 48 bit (32 bit + 16 bit) but as i said, neither the operating system the software (such as segment selectors) (applications/games/executables/processes) or maybe even the hardware (such as cpu wires, or even the "manufactor logic" on the chip itself) dont/cant do that what the hardware can do is translate a segment/page table entry/page directory entry just into a next access somewhere into more of the 4 gb ram as said the os, software, and hardware have to do so ... (in 8 bit and 16 bit times segments where very common instead of 65kb ram (16 bit) you could then use 1mb (20 bit))

i had some time to look at it his function is bugged up basicly he write it himself "// hacky but works: small number is command id, large is submenu (a pointer)"" that indicates he tryed to trick it and had to do "hacky solutions" he use a endless while true loop with ends escapes and continues, also goto´s,calls to the same functions in a function, and then seperators for his menu to fix how he called it "bad seperators" this ended up in a os specific solution you useally dont do that because the operating system can might change the relevant codes over time (such as 7 to 10, or 98 to nt) - something like this already happend in the past but the solution to this problem is possible as the author use multiple fixes all over around (probaly to compensate the problems) it is easy to add that fix - anyways it actually was a bit weird to find it out in win10 its just a flag, that was found like very quickly - but no in xp it didnt do that and gave very weird results even turned off xp was working ok while on 10 it did what it suppose to do - it was turned off as the code suppose to was changed to let me know if it works now! the .avif file (and heic) format dont work for me, neither on xp nor on 10 nor on 7 (both unchanged from the official download page and the changed version) https://www.file-upload.net/download-15277606/SumatraPDF_WINXP_3.5.2_3.zip.html https://www.mediafire.com/file/a4mtyf33ozs6q63/SumatraPDF_WINXP_3.5.2_3.zip/file