This code works
import winim/com
proc mainThread(hModule: HINSTANCE) =
AllocConsole()
discard stdout.reopen("CONOUT$", fmWrite)
while true:
echo "Hello World YEY", hModule
proc NimMain() {.cdecl, importc.}
proc DllMain(hMo
@Shucks ive found out, using nim threads is what causes the issue, try creating
the new thread with winim directly
That’s a way to do it, but I think I know what’s wrong with the first example,
(which is the most convenient one imo too), add the dynlib pragma to
entryPoint, I bet that’s what was happening
I guess I've found a workaround to access the library handle:
import winim/inc/[windef, wincon, winbase]
proc getCurrentModule: HINSTANCE =
discard GetModuleHandleEx(
GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS or
GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
Also since I'm currently working with the emitting dllmain, does someone know
if there are risks calling NimMain and then spawn a thread for the maincode?
I could imagine that the gc isn't running anymore or isnt aware of that I
spawned Nimcode with windows' CreateThread
@Recruit_main707 meow is me. However that again will cause timeout issues for
injectors once your code base gets bigger.
@Yardanico I know but thats not I've asked for. The issue is that I need to
pass the first argument (hinstDLL) from dllmain to my main function and AFAIK
nim's default entry point doesn't spawns a thread for the main code. That
causes issues in some cases because a injector for example waits for
Ok thank you :)
" cpu:i386 is specified to compile the dll as 32bit" \- of course, yes, that's
what it means.
"And if yes, do you know if it is actually needed or it’s just for convenience
of some type?" \- maybe the game itself is 32-bit, then the DLL should be
32-bit as well
That’s really nice, I didn’t know that. Do you know if, in the url I sent,
cpu:i386 is specified to compile the dll as 32bit? And if yes, do you know if
it is actually needed or it’s just for convenience of some type?
Yes, exactly - Nim is sometimes smarter than people think - with --app:lib on
Windows Nim automatically makes a DllMain entry-point which calls into your
starting code. There's no need to add it manually at all
@Shucks I have made a little research, this guy doesnt seem to have any
problems using winim functions, and another method to do things, have a look at
it also
[https://guidedhacking.com/threads/internal-with-nim.15281](https://guidedhacking.com/threads/internal-with-nim.15281)/
Thats because you disnt define DllMain, rename entryPoint to DllMain
That code snippets I've coded are ofcourse compiled with --noMain. However the
"nim" way didn't produces a valid dllmain. The emitting one does but I wan't to
keep my code on nim.
You can define DllMain and compile your code with —NoMain so that there are no
issues, however I did have problems when using winim functions, I think it was
because it tried to load kernel32, even though it was already loaded (in the
injected process)
So this got asked [here](https://forum.nim-lang.org/t/3190) already. How to
define a DllMain Entrypoint without emitting raw c code? My example doesn't
works. Looking at the raw cache .c file it also doesn't looks correct at all.
import winim/inc/[windef, wincon]
proc mainT
16 matches
Mail list logo
