I never needed to do CreateThread(), so I doubt it is needed?
I would add printf debugging statements to see when things are happening.
Since Windows processes do not normally have the concept of stdout however,
you do have to write them to a file instead of "the console", which is not
there by default.
On Sun, Nov 10, 2024 at 9:52 PM rudeus greyrat <rudeusquagmir...@gmail.com>
wrote:
> Thanks, it works now.
>
> I was missing the CreateThread in DLL Main
> ```
>
> case DLL_PROCESS_ATTACH:
> // Initialize once for each new process.
> // Return FALSE to fail DLL load.
> {
> MyThreadParams* lpThrdParam = (MyThreadParams*)malloc(sizeof(
> MyThreadParams));
> lpThrdParam->hinstDLL = _hinstDLL;
> lpThrdParam->fdwReason = _fdwReason;
> lpThrdParam->lpReserved = _lpReserved;
> HANDLE hThread = CreateThread(NULL, 0, MyThreadFunction, lpThrdParam, 0,
> NULL);
> // CreateThread() because otherwise DllMain() is highly likely to deadlock.
> } break;
> ```
>
> Plus yeah testing with rundll32 was not adequate. I created a process that
> attach the DLL.
>
> There is still one point I am missing is why DllMain deadlock if I don't
> run my function in a new thread ? Is it because I am not using goroutines ?
>
> Le dimanche 10 novembre 2024 à 21:42:44 UTC+1, Jason E. Aten a écrit :
>
>> I would suggest divide and conquer next. This is a classic approach to
>> debuggging.
>>
>> First get something working in C, solely on Windows.
>>
>> Can you build a pure C host and pure C DLL that loads and shows your
>> window?
>>
>> I note that I never had much luck cross-compiling to windows, so I would
>> recommend, initially, building and running your C host and C DLL on windows
>> exclusively. This will also cut down on the number of moving parts.
>>
>> Also, I would not use rundll32.exe to test, since it is 32 bit only and
>> its docs say that it can only be used with DLLs that were specifically
>> built for it: "Rundll32 can only call functions from a DLL explicitly
>> written to be called by Rundll32."
>> Rather build your own host/main C program that imports your DLL.
>>
>> The I would incrementally move towards your end goal. If you haven't
>> realized the issue yet, then move to cross compilation without Go. If that
>> works, then add in the Go code.
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/ok8f90k2otg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/golang-nuts/34c33139-984c-4f5e-8f7d-ef07f28c367fn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/34c33139-984c-4f5e-8f7d-ef07f28c367fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/CAPNEFAb6N16DUkKNi2Br8C%3DqZVps-bdS05E%2BidZNyX6JaATurA%40mail.gmail.com.
