batteryshark

Ah thanks crazyc! I saw that change originally and 3AM I completely forgot to add it! I just had cursor merge the change and then tested it to make sure it's still working. I also updated the binaries on github as well. @gho if the mingw approach is causing issues, I'm more than happy to reintroduce the msvc build process as well as an alternate compilation method. I just work so much in gcc world these days and some of the mingw changes make the code a little more explicit which I kinda like if...

Ah thanks crazyc! I saw that change originally and 3AM I completely forgot to add it! I just had cursor merge the change and then tested it to make sure it's still working. I also updated the binaries on github as well. @gho if the mingw approach is causing issues, I'm more than happy to reintroduce the msvc build process as well as an alternate compilation method. I just work so much in gcc world these days and some of the mingw changes make the code a little more explicit which I kinda like if...

Hey so it's been a million years and I realize this may no longer be relevant but I recently cleaned up the old 9xheap code and made a few changes: Everything builds with mingw now - way easier than forcing msvc The heap emulation appcompat code is now a static library with essentially the ms code - this means if we have to make compatibility changes in the future you don't have to screw around with recompiling the appcompat code, it's just ready to go. I took some notes from what others have done...

Hey so it's been a million years and I realize this may no longer be relevant but I recently cleaned up the old 9xheap code and made a few changes: Everything builds with mingw now - way easier than forcing msvc The heap emulation appcompat code is now a static library with essentially the ms code - this means if we have to make compatibility changes in the future you don't have to screw around with recompiling the appcompat code, it's just ready to go. I took some notes from what others have done...

its probably shim.c https://github.com/batteryshark/9xheap_public/blob/main/shim.c I'm making inline hooks for those functions and the win7 functions may have different sizes, prologues, or names. Since this code was written, Ive been more apt to use polyhook2 instead for cross compatibility.

Ill dig into my patch tomorrow and see if i can spot the issue. I'm away at the moment eith no access to my desktop for another two days, but I might be able to point out why.

And if you wanna go really psycho, you can make naked functions or cdecl and asm your own syscalls and bind against nothing, LOLOL https://github.com/batteryshark/ghostdmp/blob/955a03ac8f5fe5e1ab9a5fbc4724d405f4b1cd79/NtDirect.cpp

No worries! I generally only use nodefaultlib if im not binding against kernel32 but it still goes against ntdll, but you can go even more stripped if you want. When I was working on pdx, I used this as a guide: https://hero.handmade.network/forums/code-discussion/t/94-guide_-_how_to_avoid_c_c++_runtime_on_windows You do lose Dllmain though so you have to specify your entrypoint in the project config if you go that route :)