언젠가 부터, 저는 DLL 을 minGW 에서 만듭니다.
하나의 소스로 Target 만 바꿔서 32bit, 64bit 모두 찍어 낼 수 있도록 환경을 만들어 쓰다 보니 이게 너무 편했던 것이죠.
그런데, 어느순간 제가 "정석" 을 따르고 있지 않음을 깨닫게 됩니다.
그 일이 이번에 DllMain() 함수가 불리지 않는다는 것.
이전에 C 코드를 짤떈 잘 쓰이던 것이 왜 이번에 이러지? 라는 의문이 든 것이 바로 이 결과 때문 입니다.
위 이미지만 봐서는 뭐가 문제인지 모를 것 입니다만 ..
아래 코드를 보겠습니다.
중요한 것은 바로 DllMain() 함수가 불리지 않는 다는것.
중복된 프로세스에서 사용되거나, 쓰레드에 사용될 경우 기본적인 처리를 해 줘야 할 DllMain() 이 호출 없이 사용된다는 점 입니다.
코드내에서 사실 DllMain() 없이도 구동 되도록 만들어 쓰던 것이 제 버릇이었습니다만, 이번의 경우는 중복된 프로세스에서 사용이 어렵도록 만들어야 하는 경우에서 이런 문제를 만나게 되는 것은 사실 어이 없으면서도 큰 실수가 됩니다.
지금 이 상황에서 제가 간과 한 것은 바로, 현재 컴파일이 C 가 아닌 C++ 이란 점 입니다.
이런 문제를 너무 간단히 모르고 있었던 제 자신이 참 부끄럽기 까지도 합니다만,
하나의 소스로 Target 만 바꿔서 32bit, 64bit 모두 찍어 낼 수 있도록 환경을 만들어 쓰다 보니 이게 너무 편했던 것이죠.
그런데, 어느순간 제가 "정석" 을 따르고 있지 않음을 깨닫게 됩니다.
그 일이 이번에 DllMain() 함수가 불리지 않는다는 것.
이전에 C 코드를 짤떈 잘 쓰이던 것이 왜 이번에 이러지? 라는 의문이 든 것이 바로 이 결과 때문 입니다.
위 이미지만 봐서는 뭐가 문제인지 모를 것 입니다만 ..
아래 코드를 보겠습니다.
중요한 것은 바로 DllMain() 함수가 불리지 않는 다는것.
중복된 프로세스에서 사용되거나, 쓰레드에 사용될 경우 기본적인 처리를 해 줘야 할 DllMain() 이 호출 없이 사용된다는 점 입니다.
코드내에서 사실 DllMain() 없이도 구동 되도록 만들어 쓰던 것이 제 버릇이었습니다만, 이번의 경우는 중복된 프로세스에서 사용이 어렵도록 만들어야 하는 경우에서 이런 문제를 만나게 되는 것은 사실 어이 없으면서도 큰 실수가 됩니다.
지금 이 상황에서 제가 간과 한 것은 바로, 현재 컴파일이 C 가 아닌 C++ 이란 점 입니다.
이런 문제를 너무 간단히 모르고 있었던 제 자신이 참 부끄럽기 까지도 합니다만,
DllMain 을 다음과 같이 extern"C" 로 정의 해 주면 해결 되는 문제 입니다.
가끔 이런 어처구니 없는 실수를 하는 것이 놀랍기 까지 하네요.
그래서 항상 사람은 언제나 노심초사 하는 것도 나쁘진 않는 듯 합니다.
아직 고수가 되려면 수억광년은 멀리 떨어진 일이 아닌가 하네요 .. ㅠㅠ
extern "C" {
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved);
}
가끔 이런 어처구니 없는 실수를 하는 것이 놀랍기 까지 하네요.
그래서 항상 사람은 언제나 노심초사 하는 것도 나쁘진 않는 듯 합니다.
아직 고수가 되려면 수억광년은 멀리 떨어진 일이 아닌가 하네요 .. ㅠㅠ