2010-03-15 5 views
3

Windows에서 표준 DLL 진입 점의 이름은 DllMain입니다. 두 번째 매개 변수는 DWORD, ul_reason_for_call입니다.DLL_PROCESS_VERIFIER 플래그로 DllMain을 호출 할시기는 언제입니까?

MSDN에서이 두 번째 매개 변수에 사용할 수있는 값을 조회했습니다. 다음 명백하다 :

DLL_PROCESS_ATTACH: 
DLL_THREAD_ATTACH: 
DLL_THREAD_DETACH: 
DLL_PROCESS_DETACH: 

그러나 약 :

DLL_PROCESS_VERIFIER 

이 때 진입 점은이 플래그로 호출됩니다? DLL의 '정상적인'작동 중에 걱정할 필요가 있습니까? 난 단지 비주얼 스튜디오 2005에서 헤더 파일에 DLL_PROCESS_VERIFIER를 참조

참고하지 2008 년

답변

5

나는 이론적으로 마이크로 소프트가 새로운 용도 및 플래그 그들이 새로운 하나를 필요로 느낄 수있는 시간을 발명있을 것 같아요. 따라서 간단한 규칙은 코드에서 예기치 않은 값을 허용하는지 확인하는 것입니다. 즉, 처리해야하는 사례를 처리하도록 작성하고 나머지는 무시하고 0을 반환합니다.

+0

동의. 현재 내 코드는 입니다. {case DLL_PROCESS_VERIFIER : default : return 0; } 그러나 내 질문은 언제/왜 이것이 현재 일어날 지와 관련이 있습니다. – Konrad

+0

일반적인 합의는 Application Verifier가 측정하는 프로세스에서 dll이 호출 된 결과로 보입니다. Visual Studio의 일부로 제공되는 Im이므로 어떤 종류의 로깅 코드를 넣고 있는지 테스트 해보는 것이 "쉽다". 정상 작동 중에? 분명히. –

+1

switch 문에서 @Whyam을 명시 적으로 언급하는 것에 대해 조언합니다 *. 그것은 당신이 프로그램이 그 가치를 어떻게 다루어야하는지 생각 해낸 잘못된 인상을주었습니다. 왜냐하면 그것이 무엇인지를 모르기 때문에 분명히 가질 수 없었을 때입니다. 코드에이 코드를 포함시킴으로써 앞으로의 코드 유지 보수 담당자에게 무엇이 필요한지 묻습니다. 그러면 시간과 시간이 낭비됩니다. 그것이 존재하지 않는다고 가장하는 것이 가장 좋습니다. –

0

Application Verifier을 실행하면 값을 가질 수 있다고 생각합니다. 짐작의 종류 :

1

이것은 정말 애매합니다. the SDK에 문서화되어 있지 않으며 SDK 헤더 파일에도 나타나지 않습니다. Google은 단 몇 번의 조회를 생성하며 대부분의 사이트는 다운되었거나 신뢰할 수 없습니다. 괜찮은 히트를 얻으려면 XBox 코드 만 선언하면되지만 실제로 사용하지는 않습니다.

저는 이것이 정규 Windows 프로그램에서 만날 수있는 실제 코드라고 충분히 확신하지 못합니다.

+0

msdn 링크 +1. 내가 실제로 'DLL_PROCESS_VERIFIER'로 검색 중이기 때문에 나는 실제로 그것을 보지 못했습니다. 내가 헤더 파일에서 주위를 샅샅이 뒤 졌기 때문에 내가 그걸 발견 한 유일한 이유가있다. – Konrad

관련 문제