1. WM_CREATE의 리턴값/타입에 의문
Windows에서 C/C++로 GUI 프로그래밍을 할 때 WM_CREATE 메시지는 기본 필수 0순위로 접하게 되는 물건이다. 메시지 번호부터가 WM_NULL 다음으로 당당하게 1번이다.
얘가 오면 윈도우 프로시저는 lParam의 값으로 날아온 CREATESTRUCT 구조체 내용을 참조하면서 자신에 대해 초기화를 하고, 필요하다면 자기의 위치와 크기도 변경하고, 내 밑의 차일드 컨트롤들도 적절히 생성하면 된다.
그런데 이 메시지를 처리하고 나서 되돌리는 리턴값은 약간 이상한 형태이다. 성공하면 0, 실패하면 -1을 되돌리라고 명시되어 있다. 윈도우 프로시저가 실패값을 되돌리면 CreateWindow(Ex) 함수의 동작도 실패하여 창이 생성되지 않으며, NULL이 돌아온다.
즉, WM_CREATE의 리턴 형태는 BOOL이나 마찬가지이다. 그런데 왜, 어째서 직관적인 TRUE (1) / FALSE (0)가 아니라 이것보다 1 작은 값 형태로 정해진 걸까? (0 / -1)
이 때문에 MFC에서도 CWnd::OnCreate는 리턴 타입이 int로 설정되었다. 하지만 얘는 성공/실패만 따지기 때문에 원래는 int가 필요하지 않다. 내가 실험해 보니 굳이 0이 아니어도 -1을 제외한 다른 모든 값들은 성공이라고 간주되기는 하더라.
WM_CREATE는 대화상자 프로시저(DialogProc)처럼 평소에는 BOOL을 되돌리지만 몇몇 소수의 메시지에 대해서는 예외적으로 정보량이 더 많은 리턴값을 직접 되돌려야 하기 때문에 불가피하게 INT_PTR 형태로 설계된 것도 아니다. 더구나 WM_CREATE의 전신격인 WM_NCCREATE는 평범한 BOOL TRUE/FALSE 형태인 것도 의문을 더욱 증폭시킨다.
이와 관련해 혹시 숨겨진 사연이 있는지 레이먼드 챈 아저씨가 블로그에서 한 번쯤 다뤘을 법도 해 보이는데 내가 검색한 바로는 의외로 없다.
"CreateFileMapping은 실패값이 NULL인데 CreateFile은 실패값이 왜 혼자 INVALID_HANDLE_VALUE (-1)인가요?"와 거의 같은 맥락의 내력 의문점인데도 말이다.
파일 API의 경우, 먼 옛날에는(16비트 시절?) CreateFile이 지금 같은 형태의 핸들값이 아니라 파일 식별자 번호를 되돌렸으며, 0도 특수한 용도이지만 올바른 파일 식별자 값으로 예약돼 있었기 때문에 실패값을 -1로 따로 정한 거라고 설명이 돼 있다.
그렇다면 WM_CREATE도 처음에 설계하던 당시에는 굳이 BOOL로 국한되지 않고 0을 포함한 다양한 범위의 성공 리턴값을 되돌릴 수 있게 만들었는데.. 그럴 필요가 없어지면서 결국 지금 같은 형태로 굳어진 게 아닌가 싶다.
2. NC 버전과의 관계, 창의 소멸
Windows의 메시지 중에는 클라이언트 영역의 바깥 테두리를 그리거나(PAINT, ACTIVATE) 거기 크기를 정하거나(CALCSIZE) 그 영역의 마우스 동작을 감지하는(MOUSE*, ?BUTTON*) 용도로 WM_NC*로 시작하는 것들이 있다. 여기서 NC는 non-client를 의미한다.
그런데 WM_CREATE와 WM_DESTROY에도 WM_NC버전이 있다. 이때 NC는 딱히 외관상으로 클라이언트 바깥의 테두리나 제목 표시줄 같은 걸 가리키지는 않으며, 다른 방향으로 의미를 갖는다.
소멸 버전의 경우, WM_DESTROY는 아직 자기 밑에 자식 윈도우들이 멀쩡히 남아 있을 때 호출된다. 즉, 호출되는 순서가 top-to-bottom이다. 그러나 WM_NCDESTROY는 WM_DESTROY가 전달되었고 자식 윈도우들이 모두 소멸된 뒤에 자식에서 부모 순으로 bottom-to-top으로 호출된다.
즉, 어떤 윈도우가 윈도우 프로시저를 통해 가장 마지막으로 받는 메시지는 WM_DESTROY가 아니라 WM_NCDESTROY이다. WM_QUIT은 아예 스레드의 메시지 큐 차원에서 Get/PeekMessage를 통해 전달받을 뿐, 특정 윈도우의 프로시저로 오지는 않으니까...
어떤 윈도우 핸들과 C++ 객체가 연결되어 있는 경우, WM_NCDESTROY에서 그 객체를 delete 해 주면 된다. 그 전 단계인 WM_DESTROY에서 delete를 해 버리면 아직 소멸되지 않은 자기 자식 윈도우가 부모 윈도우의 C++ 객체 같은 걸 여전히 참조할 때 문제가 발생할 수 있다.
사용자가 Alt+F4를 누르거나 창의 [X] 버튼을 누르면 그 윈도우로 WM_CLOSE 메시지가 전달된다. 시스템 메뉴에서 닫기를 누른 것도(WM_SYSCOMMAND + SC_CLOSE)도 디폴트 처리는 WM_CLOSE 생성이다.
그리고 이 메시지에 대해 윈도우 프로시저가 다른 처리를 하지 않고 DefWindowProc으로 넘기면 그때서야 이 윈도우에 대해 DestroyWindow 함수가 호출되고 WM_DESTROY와 WM_NCDESTROY가 차례로 날아온다.
DestroyWindow는 호출하는 주체와 동일한 스레드가 생성한 윈도우들만 없앨 수 있다. 프로세스/스레드 소속이 다른 윈도우는 없앨 수 없으며, 그런 윈도우를 상대로는 WM_CLOSE를 보내서 창을 없애 달라는 간접적인 요청만 할 수 있다.
악성 코드 급의 프로그램이 아니라면 이 요청을 무작정 거부하는 끈질긴 윈도우는 없을 것이다. 하지만 일반적인 프로그램의 경우, "이름없음 문서를 저장하시겠습니까?"라고 질문을 해서 사용자가 취소를 누르면 자기가 종료되지 않게 하는 처리 정도는 한다. 작업 관리자의 '프로세스 종료' 기능은 응용 프로그램 창에다가 WM_CLOSE부터 먼저 보내 보고, 그래도 말을 안 들으면 TerminateProcess라는 극약 처방을 하는 식으로 동작한다.
그런데 WM_DESTROY 메시지를 받았는데 자기 자신에 대해서 DestroyWindow를 또 호출하는 이상한 프로그램도 있는가 보다. 창을 없애라는 요청은 WM_CLOSE이고, 이때는 그냥 DefWindowProc만 호출해도 알아서 소멸이 된다. WM_DESTROY는 요청이 아니라 이 창이 없어지는 건 이미 정해졌고 피할 수 없는 운명이라는 통지일 뿐인데.. 이때 DestroyWindow를 호출하면 같은 창에 대해서 WM_DESTROY가 이중으로, 재귀적으로 전달되는가 보더라.
소멸 중인 윈도우에 대해서 DestroyWindow 요청은 가볍게 무시만 해도 될 듯하지만 이미 이런 식으로 정해지고 정착해 버린 동작은 호환성 차원에서 함부로 고치지는 못한다고 한다.
3. 창의 생성
소멸 얘기가 좀 길어졌는데...
생성 버전에 속하는 WM_CREATE와 WM_NCCREATE 짝은 소멸 관련 메시지와 같은 유의미한 차이가 없긴 하다.
자식 컨트롤들을 생성하는 건 그냥 WM_CREATE 때 하면 되지, NCCREATE 때 딱히 해야 할 일은 없다. 쟤는 그냥 NCDESTROY와 짝을 맞추기 위해 도입된 것에 가깝다.
어떤 창이 생성되면, CreateWindow(Ex) 함수가 실행되어 있는 동안 WM_CREATE만 오는 게 아니라 WM_GETMINMAXINFO, WM_NCCREATE, WM_NCCALCSIZE가 먼저 전달된다. CREATE말고 나머지 메시지들은 창 내부의 공간 배분과 관계 있는 것인데, 아주 특수한 형태로 동작하는 유별난 윈도우가 아니라면 그냥 다 디폴트로 넘겨도 무방한 것들이다.
그리고 앞서 살펴본 바와 같이, CREATE 계열 메시지들은 실패값을 리턴함으로써 이 창의 생성을 저지할 수 있다.
WM_NCCREATE의 실행이 실패한다면(FALSE) 이 창은 그 뒤로 곧장 WM_NCDESTROY만 날아온 뒤 소멸되어 버린다. 그러나 WM_CREATE에서 실패하면(-1) WM_DESTROY와 WM_NCDESTROY가 차례로 날아오면서 소멸된다.
그런데 여기서 유의할 것이 있다.
프로그램의 main 윈도우의 경우, WM_DESTROY를 받았을 때 대체로 main message loop을 벗어나고 프로그램 전체를 종료하기 위해서 PostQuitMessage를 호출한다.
이게 일단 호출된 뒤부터는 이 스레드에서는 다른 GUI 윈도우를 생성한다거나 message loop을 돌아서는 안 된다. 여기에는 에러 메시지를 출력하기 위한 간단한 MessageBox 호출도 포함된다.
main 윈도우의 생성이 WM_CREATE 단계에서 실패했다면(WM_NCCREATE은 무관) WM_DESTROY를 거치게 되며, 특별한 조치가 없는 이상 그 메시지의 handler에 있는 PostQuitMessage도 처리되었을 것이다. 이 상태에서
if(::CreateWindowEx( .... )==NULL) {
::MessageBox(L"프로그램 실행 실패");
return 1;
}
이런 식으로 코드를 쓰면 MessageBox 내부의 메시지 loop은 메시지 큐에서 WM_QUIT이 튀어나오기 때문에 곧바로 끝난다. 즉, 메시지 박스가 화면에 표시되지 않는다는 것이다.
그러니 에러 메시지를 찍을 거면 차라리 WM_CREATE 내부에서 -1를 리턴하기 전에 하는 게 낫다.
심지어 main 윈도우의 WM_NCDESTROY에서 MessageBox를 호출하려 시도하는 경우도 있다고 한다. 프로그램 실행이 다 끝난 마당에 무엇을 찍을 일이 있는지는 모르겠지만 이 역시 위와 동일한 이유로 인해 메시지 박스가 화면에 나타나지 않는다.
뭐, WM_DESTROY 대신 WM_NCDESTROY에서 PostQuitMessage를 요청할 수도 있겠지만 int main(int argc, char *argv[]) 대신에 char **argv만큼이나.. 익숙한 관행은 아니어 보인다.
이상. 이렇게 간단하고 익숙한 주제를 갖고도 지금까지 진지하게 생각하지 못한 것에 대해 할 말이 많을 때가 흥미롭다.
Posted by 사무엘
