DllMain optimization
codecheck01 opened this issue · 4 comments
@rollraw
@danielkrupinski (I would like your input on this matter)
https://github.com/rollraw/qo0-base/blob/master/base/core.cpp
References
DllMain:
- https://docs.microsoft.com/en-us/windows/win32/dlls/dllmain
- https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices
- https://docs.microsoft.com/en-us/previous-versions/windows/desktop/mscs/implementing-dllmain
DisableThreadLibraryCalls:
- https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-disablethreadlibrarycalls
- https://books.google.com/books?id=GbNCAwAAQBAJ&pg=PT448&lpg=PT448&dq=Inside+Windows+debugging+DisableThreadLibraryCalls&source=bl&ots=mryQSoOEvZ&sig=ACfU3U3fsI-Me-zj_8IfgJXUzlwkt794sw&hl=en&sa=X&redir_esc=y#v=onepage&q=Inside%20Windows%20debugging%20DisableThreadLibraryCalls&f=false
- https://microsoft.public.development.device.drivers.narkive.com/JYxBPTOn/proper-msvc-dll-usage-in-port-monitor-print-driver
CRT:
You should never call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
It should be deleted or at best moved in top of OnDllAttach function.
https://github.com/rollraw/qo0-base/blob/101e504a4cebdc9851502463ad7df46dbbb5b116/base/core.cpp#L196-L201
Do not call this function from a DLL that is linked to the static C run-time library (CRT). The static CRT requires DLL_THREAD_ATTACH and DLL_THREAD_DETATCH notifications to function properly.
Investigate if DisableThreadLibraryCalls is suitable for our DllMain implementation.
It think it should be deleted as our DLL is linked to the static CRT (ucrtbase.dll, VCRUNTIME140.dll)
(every base is blindly calling this function without even knowing what it does...)
https://github.com/rollraw/qo0-base/blob/101e504a4cebdc9851502463ad7df46dbbb5b116/base/core.cpp#L193-L194
This discussion is here to discuss the best DllMain implementation possible.
Thank you in advance for your interest.
It should be deleted or at best moved in top of OnDllAttach function.
why? it doesn't have any sense where we will do that
It think it should be deleted as our DLL is linked to the static CRT (ucrtbase.dll, VCRUNTIME140.dll)
(every base is blindly calling this function without even knowing what it does...)
i don't think you understand what static crt means here, and no it ain't static currently, project settings -> run-time library -> /MDd (debug) and /MD (release)
in case you really want best practice of dllmain for cheat making.. you doesnt need it at all, same with CRT
why? it doesn't have any sense where we will do that
Indeed, but in my case (not yours), it allows me to not have user32.dll as a dependency, by calling MessageBox in the OnDllAttach function, then called directly on CreateThread (using MessageBox by having the user32 DLL already loaded into the memory).
i don't think you understand what static crt means here, and no it ain't static currently, project settings -> run-time library -> /MDd (debug) and /MD (release)
You are right again, I made a mistake, we are not linked to the static CRT here, but does having ucrtbase.dll as a dependency could cause some issues with the DisableThreadLibraryCalls function.
I know that our binary is linked by imports against ucrtbase.dll (mine is MSVCRT.dll), and so it is not
linked statically against C runtime.
But still is the DisableThreadLibraryCalls really suitable for our DllMain implementation?
Indeed, but in my case (not yours), it allows me to not have user32.dll as a dependency, by calling MessageBox in the OnDllAttach function, then called directly on CreateThread (using MessageBox by having the user32 DLL already loaded into the memory).
same as #170, we still have enough exports even without it
But still is the DisableThreadLibraryCalls really suitable for our DllMain implementation?
literally from what you referenced and from the comment above it - yes
fixed with the new v2 version and now available under 'master' branch.