user57

so just using the right paragon driver solved it up ? thats good news that the /pae question related to that problem would be finally closed

i dont think that will work in this case you litterally asking to write a driver for that specific device, without having knowledge of that device (like that company that created it has) if its not a open source driver sounds a close to mission impossible to me porting an existing driver is not easy either you are likely to create all the missing functions that win8 driver lacks in windows xp - what actually is a lot of work also you could ask their driver devlopers if they are doing that - but normally they ignore a such request

i do not know python but if its like a normal compiler it searches for a main() or winmain(), the next error talks something about __main__ looking these 2 lines might be of interests it seems to be some kind of call "PyInstaller.__main__" a import useally is a function that a modules exports (such as a dll (or dllmain()) or in case of executable winmain) combined it says in "PyInstaller" + "__main__" was not found or pyinstaller was not reconized as "package" File "C:\Users\Admin\Documents\GitHub\xl-converter\misc\pyinstaller\PyInstaller.py", line 15, in <module> from PyInstaller.__main__ import run "ModuleNotFoundError: No module named 'PyInstaller.__main__'; 'PyInstaller' is not a package [end of output]" one way i could think of this is happening is that winver in the peheader is set to 6 or higher (6 are vista and 10) in this case a executable caller (such as createprocess) cant open the module - also from consideration the answer from compilers can sometimes not be very precise, it also could be a small type error/syntax error near that area aka PyInstaller at spot __main__ however i do not know the syntax in python

the answer from the developer is not bad, but he also say he dont know it so exactly either but i would have to go with close to nothing to just write something to this connections are made via winsock - here TCP/IP procolls and TLS (aka the named openssl) can be involved if its a winHTTP request the HTTP request also sends what OS you are on - some actually then refuse the connection if they see this that would be changeable the idea going to a changed python yea - i also said that - even tho i had much less useful detail´s a other small idea is to look if the same code work for a other OS, if so its likely the internals (the functions that come next) somehow mess up thats also what the python devloper said with other words the openssl problem might be possible to determinate by just trying a different OS - if it has the same code then its not openssl a problem i can see here that this rely´s on script functions (low level) the next tier functions are deeper (like the named winsock) if its somewhere at this spot you need to debug these functions - and see why they are breaking up this is the other problem i talked about - if you would have a normal c++ style you could see the most internal functions (instead of only "connection failed" or something like "urllib3.connection.HTTPSConnection object at 0x032F9910>: Failed to establish a new connection")

wasnt that dietmar´s terretory ? it is nice to have a kernel extender that provide these missing functions or maybe a missing piece that might be a solution there is maybe a different approach to solve this problem - a driver from that company today´s OS such as win10 provide standart functions to solve this for a device - then something like this project just works without having a own driver the problem we faced here is that win10 has newer codes in the relevant drivers - its like a standardized code to control certain devices the problem with that is that this is not very OS-independant the most drivers/or and devices useally define 3 basics: writes control read these are somewhat somehow written into that standardized code a driver from the company could also provide the same thing - they neither have to bind a such driver to windows 10 functions it would be doable - then they might would have a few more customers if lets say a XP see their product he could see "xp driver present" or something like that and buy it up like that it is like limited to win10 maybe you could ask in their forums about this

im not someone who programs in python but they say its intensional to drop support for python 3.9 the commits say that they could support it still (so also that devloper says there) ... but they dont want to and that error says it has to do with "urllib3" of python - what is part of their removement in newer python versions they say everything below "urllib3" is dropped urllib3 would be the thing to look for, like what functions of other then XP they used here - and if you can make this version compatible with xp

that´s a important thing to talk about again often newer app´s depending on side things, like runtimes(c-runtime, sdt), they require cmake, they require a new c++ style (not only the ones that allow new types of writings, rather something like "currentpath" - this is going into a direction of a script rather then a language (in java a scriptish language that is for example the case)), they requie a new version of compiler like vs2019 or even vs2022, they require a engine like "cuda, like dwrite, like LAV", MinGW,maybe also a second programming language like masm thats only to name a few ! it rather are even more those rather also are already bond to win10 or win11 like directx11 is for example so this is a problem you have today if only one of these things break up (in this case python) it might be a direct end - if more break up you have a even bigger problem the reason behind this are scriptish languages (what c++ in newer styles is also going into that direction) - and its going very into that direction a elder style is very independed of it´s operating system, like something "currentpath" would have a own code rather then somewhere in the code "std:CurrentPath" -> that might looks small but its not - that code is getting translated to a "real next code" what then up uses windows functions ... - its not faster it´s like an illusion that looks small and the knowledge is getting lost how these functions actually work - so a new programmer will always come up with the std:CurrentPath (or whatever std´s, c-runtimes, engines) there now are ... in a bigger program there are then many of these things - you cant just unbound all of them - a older compiler would not compile them, and a newer compile (translate) them to win11 functions ... so it might be better to have a solution in a normal c++ style - then you are fully independed of all these things - they cant just release a new phyton version that you have to fix - then you have the control about your code ffmpeg in the past was relativ independed today it´s going a different direction it begin to use engines rather then having own routines that can do the things today ffmpeg is rather like a command line - and internal it already started to use many engines and these use win10 functions, drivers, dependencies - up to some point i found ffmpeg a very nice tool, today im a bit disapointed of it a few years ago i mentioned that problem - now we face it again

i would suspect that paragon driver is a filter driver filter drivers are something between the OS and the HARDWARE it can perform the same actions as the OS can do with the hardware there are those IRP requests where filter drivers often would be if the controlment is taken from that spot the paragon driver has the control so putting things right, the paragon driver actually could handle the harddrive instead of the OS (in this case xp) then interact with the OS and show it as if the harddrive can control more then 2 TB of discspace this might have a problem but, it needs that paragon driver in that case to figure out what the inner XP code is doing is more of work, that require a lot of debugging - i think we might have candidates to do that

someone should correct me if im wrong but PAE is something for memory managment, is actually involved ? for a disc it dont have a 32 bit offset so directly, rather it makes use of 3 register of 16 bit size LBAlo - 16-bit LBAmid - 16-bit LBAhi - 16-bit = LBA48 https://wiki.osdev.org/ATA_PIO_Mode#Registers (the 8 bit are longly outdated - they are now always 16 bit) after these are set (LBAlo,LBAmid,LBAhi) it just use a I/O code - it dont use a 32 bit offset - it rather tells the disc where to write its data over these 3 filled registers its a bit like with memory paging, the old norm where 4k pages what are normed with a 32 bit PTE entry (and maybe a PDE) -> then PSE (page size extension (similiar to PAE)) apeared and made these 4 k pages to 4 MB pages thus for 4k you need less bits in 32 bit norm (20 bits to represent the highest 4 GB page) (4 k * 20 bit = 4 GB) for a 4 MB page it would be only 10 bit´s (4 mb * 1024 = 4 GB) to represent the highest 4 GB page, the rest of 4 MB pages would point to the upper pages above 4 GB i heared for PAE its only the half, they said its because PAE has the NX bit that means -1 bit = 2 MB pages, this is the result they often describe (also they say the 4k pages are ignored, aka PSE is always on) https://en.wikipedia.org/wiki/Physical_Address_Extension#/media/File:X86_Paging_PAE_2M.svg i do not know it exactly for that PAE mode, but even if it would be like that i could programm it like that the thing with the sector-size for a HDD/SSD/drive is very similiar if you have a 4 k sector instead of a 512 sector you have 8 times as much data it might not be the PAE extension itself, it might be the licence check like starter, home, pro - but that is only a guess just trying to make things better, if someone have knowledge let me know i also can improve myself

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