김 용묵의 절대공간 - 블로그

1. C++의 new/delete 연산자

C++의 new와 delete 연산자에 대해서는 먼 옛날에 한번 글을 쓴 적이 있고,  연산자 오버로딩에 대해서 글을 쓸 때도 다룬 적이 있다.
new/delete 연산자는 메모리를 할당하고 해제하는 부분만 따로 떼어내서 operator new / opertor delete라는 함수를 내부적으로 호출하는 형태이며, 이건 클래스별로 오버로딩도 가능하다. 그리고 객체 하나에 대해서만 소멸자를 호출하는 일명 스칼라 new/delete와, 메모리 내부에 객체가 몇 개 있는지를 따로 관리하는 벡터 new[]/delete[]가 구분되어 있다는 점이 흥미롭다.

new는 메모리 할당이 실패할 경우 한 1990년대까지는 NULL을 되돌렸지만 요즘은 예외를 되돌리는 게 malloc과는 다른 점이라고 한다. 하긴, 요즘 세상에 메모리 할당 결과를 무슨 파일 열기처럼 일일이 NULL 체크하는 건 굉장히 남사스럽긴 하다.

1980년대의 완전 초창기, 한 터보 C++ 1.0 시절에는 벡터 delete의 경우, 원소 개수를 수동으로 써 주기까지 해야 했다고 한다. pt = new X[3] 다음에는 delete[3] pt처럼. 안 그래도 가비지 컬렉터도 없는데, 이건 너무 불편한 정도를 넘어 객체지향 언어의 기본적인 본분(?)조차 안 갖춰진 막장 행태로 여겨진지라 곧 시정됐다. 객체의 개수 정도는 언어 차원에서 메모리 내부에다 자동으로 관리하도록 말이다.

그런데 스칼라이건 벡터이건 메모리를 n바이트 할당하거나 해제하는 동작 자체는 서로 아무 차이가 없는데 operator new/delete와 operator new[]/delete[]가 따로 존재하는 이유는 난 여전히 잘 모르겠다.

new char[100]을 하면 operator new(100)이 호출되고, 생성자와 소멸자가 있는 new TwentyFour_byte_object[4]를 호출하면 x86 기준으로 24*4+4인 operator new[](100)이 호출된다.
operator new[]라고 해서 딱히 내가 할당해 준 메모리에 저장되는 객체의 개수나 크기를 알 수 있는 것도 아니다. 단지, new[]의 경우 내가 되돌려 준 메모리 바로 그 지점에 객체가 바로 저장되지는 않는다는 차이가 존재할 뿐이다. 맨 앞에는 오브젝트의 개수 4가 저장되기 때문.

즉 다시 말해 벡터 new[]는 operator new[]가 되돌린 포인터 값과, new operator[]를 호출한 호스트 쪽에서 받는 포인터 값에 미묘하게 차이가 생기며 서로 일치하지 않게 된다. 마치 다중 상속으로 인해서 this 포인터가 보정되는 것처럼 말이다.
그래도 스칼라/벡터 처리는 operator new/delete가 전혀 신경 쓸 필요가 없는 영역이며, 여전히 new/delete operator가 자동으로 하는 일일 뿐인데 그것 때문에 메모리 할당 계층 자체가 둘로 구분되어야 할 필요가 있는지는 여전히 개인적으로 의문이다.

그리고 하나 더.
operator new/delete는 오버로딩이 가능하다고 아까 얘기했었다.
global scope에서 오버로딩을 해서 오브젝트 전체의 메모리 할당 방식을 바꿀 수 있으며, new의 경우 추가적인 인자를 집어넣어서 placement new 같은 걸 만들 수도 있다. "메모리 할당에 대한 답은 정해져 있으니 너는 저 자리에다가 생성자만 호출해 주면 된다"처럼.. (근데 new와는 달리 delete는 왜 그게 가능하지 않은지 모르겠다만..)

global scope의 경우, Visual C++에서는 operator new/delete 하나만 오버로딩을 해도 new[], delete[] 같은 배열 선언까지도 메모리 할당과 해제는 저 new/delete 함수로 자동으로 넘어간다. 물론 new[]/delete[]까지 오버로딩을 하면 스칼라와 벡터의 메모리 요청 방식이 제각기 따로 놀게 된다.

그러나 클래스는 operator new/delete 하나만 오버로딩을 하면 그 개체의 배열에 대한 할당과 해제는 그 함수로 가지 않고 global 차원의 operator new[]/delete[]로 넘어간다.
이것도 표준에 규정된 동작 방식인지는 잘 모르겠다. 결정적으로 xcode에서는 global도 클래스일 때와 동일하게 동작하여 스칼라와 벡터 사이의 유도리가 동작하지 않았다.
메모리 할당이라는 기본적인 주제를 갖고도 C++은 내부 사연이 무척 복잡하다는 걸 알 수 있다.

2. trigraph

아래와 같은 코드는 보기와는 달리 컴파일되는 올바른 C/C++ 코드이다. 그리고 Foo()를 호출하면 화면에는 What| 이라는 문자열이 찍힌다.

void Foo()
??<
    printf( "What??!\n" );
??>

그 이유는 C/C++엔 trigraph라는 문자열 치환 규칙이 '일단' 표준으로 정의돼 있기 때문이다.
아스키 코드에서 Z 뒤에 나오는 4개의 글자 [ \ ] ^ 와, z 뒤에 나오는 4개의 글자 { | } ~, 그리고 #까지 총 9개의 글자는 ?? 로 시작하는 탈출문자를 통해 등가로 입력 가능하다.
이런 치환은 전처리기 차원에서 수행되는데, #define 매크로 치환과는 달리 일반 영역과 문자열 리터럴 안을 가리지 않고 무조건 수행된다. 그래서 문자열 리터럴 안에서 연속된 ?? 자체를 표현하려면 일부 ?를 \? 로 구분해 줘야 한다.

이런 게 들어간 이유엔 물론 까마득히 먼 역사적인 배경이 있다. 천공 카드던가 뭐던가, 저 문자를 한 글자 형태로 입력할 수 없는 프로그래밍 환경에서도 C언어를 지원하게 하기 위해서이다. 1950~70년대 컴퓨팅 환경을 겪은 적이 없는 본인 같은 사람으로서는 전혀 이해할 수 없는 환경이지만 말이다.
C(와 이거 호환성을 계승한 C++도)는 그만치 오래 된 옛날 레거시 언어인 것이다. 그리고 C는 그렇게도 암호 같은 기호 연산자들을 많이 제공하는 언어이지만 $ @처럼 전혀 사용하지 않는 문자도 여전히 있다.

오늘날 PC 기반 프로그래밍 환경에서 저런 trigraph는 전혀 필요 없어진 지 오래다. 그래서 Visual C++도 2008까지는 저걸 기본 지원했지만 2010부터는 '기본 지원하지는 않게' 바뀌었다. 이제 저 코드는 기본 옵션으로는 컴파일되지 않는다. /Zc:trigraphs 옵션을 추가로 지정해 줘야 한다.

C/C++ 코드를 가볍게 구문 분석해서 함수 블록 영역이나 변수 같은 걸 표시하는 IDE 엔진들은 대부분이 trigraph까지 고려해서 만들어지지는 않았다. 그러니 trigraph는 IDE가 사용하는 가벼운 컴파일러들을 교란시키고 혼동시킨다. 한편으로 이 테크닉은 소스 코드를 의도적으로 괴상하게 바꾸는 게 목표인 IOCCC 같은 데서는 오늘날까지 유용하게 쓰인다. 함수 선언을 void foo(a) int a; { } 이렇게 하는 게 옛날 원래의 K&R 스타일이었다고 하는데 그것만큼이나 trigraph도 옛날 유물이다.

차기 C/C++ 표준에서는 trigraph를 제거하자는 의견이 표준 위원회에서 제안되었다. 그런데 여기에 IBM이 적극적인 반대표를 던진 일화는 유명하다. 도대체 얼마나 케케묵은 옛날 코드들에 파묻혀 있으면 '지금은 곤란하다' 상태인지 궁금할 따름이다. 하지만 IBM 혼자서 대세를 거스르는 게 가능할지 역시 의문이다.

3. Visual C++ 2015의 CRT 리팩터링

도스 내지 16비트 시절에는 C/C++ 라이브러리를 DLL로 공유한다는 개념이 딱히 없었던 것 같다. 다음과 같은 이유에서다.

• 도스의 경우, 근본적으로 DLL이나 덧실행 같은 걸 쉽게 운용할 수 있는 운영체제가 아니며,
• 메모리 모델이 small부터 large, huge까지 다양하게 존재해서 코드를 한 기준으로 맞추기가 힘들고,
• 옛날에는 C/C++ 라이브러리가 딱히 공유해야 할 정도로 덩치가 크지 않았음.
• 예전 글에서 살펴 보았듯이, 16비트 Windows 시절엔 DLL이 각 프로세스마다 자신만의 고유한 기억장소를 갖고 있지도 않았음. 그러니 범시스템적인 DLL을 만드는 게 더욱 까다롭고 열악했다.

모든 프로세스들이 단일 주소 공간에서 돌아가긴 했겠지만, small/tiny 같은 64K 나부랭이 메모리 모델이 아닌 이상, sprintf 하나 호출을 위해서 코드/세그먼트 레지스터 값을 DLL 문맥으로 재설정을 해야 했을 것이고 그게 일종의 썽킹 오버헤드와 별 차이가 없었지 싶다. 마치 콜백 함수를 호출할 때처럼 말이다. 이러느니 그냥 해당 코드를 static link 하고 만다.

그 반면 32비트 운영체제인 Windows NT는 처음부터 CRT DLL을 갖춘 상태로 설계되었고, 그 개념이 Visual C++을 거쳐 Windows 9x에도 전래되었다. 1세대는 crtdll, msvcrt10/20/40이 난립하던 시절이고 2세대는 Visual C++ 4.2부터 6까지 사용되던 msvcrt, 그리고 3세대는 닷넷 이후로 msvcr71부터 msvcr120 (VC++ 2013)이다. 2005와 2008 (msvcr80과 90)은 잠시 매니페스트를 사용하기도 했으나 2010부터는 그 정책이 철회됐다.

그런데 매니페스트를 안 쓰다 보니 Visual C++의 버전이 올라갈 때마다 운영체제의 시스템 디렉터리는 온갖 msvcr??? DLL로 범람하는 폐단이 생겼고, 이에 대한 조치를 취해야 했다. C/C++ 라이브러리라는 게 생각보다 자주 바뀌면서 내부 바이너리 차원에서의 호환성이 종종 깨지곤 했다. 이런 변화는 함수 이름만 달랑 내놓으면 되는 C보다는 C++ 라이브러리 쪽이 더 심했다.

그 결과 Visual C++ 2015와 Windows 10에서는 앞으로 변할 일이 없는 인터페이스 부분과, 내부 바이너리 계층을 따로 분리하여 CRT DLL을 전면 리팩터링을 했다. 본인은 아직 이들 운영체제와 개발툴을 써 보지 않아서 자세한 건 모르겠는데 더 구체적인 내역을 살펴봐야겠다.

사실 C++ 라이브러리는 대부분의 인터페이스가 템플릿 형태이기 때문에 코드들이 전부 해당 바이너리에 static 링크된다. 하지만 그래도 모든 코드가 static인 건 아니다. 메모리 할당 내지 특정 타입에 대한 템플릿 specialization은 여전히 DLL 링크가 가능하다.
C++ 라이브러리가 어떤 식으로 DLL 링크되는지는 마치 함수 타입 decoration 방식만큼이나 그야말로 표준이 없고 구현체마다 제각각인 춘추전국시대의 영역이지 싶다.

4. Windows의 고해상도 DPI 관련 API

요즘이야 컴퓨터 화면의 해상도가 PC와 모바일을 가리지 않고 워낙 높아져서 프로그램의 UI 요소나 각종 아이콘, 그래픽도 크기 조절에 유연하게 대처 가능하게 만드는 게 필수 조건이 됐다. 폰트의 경우 저해상도에 최적화된 힌팅이 필요 없어질 거라는 전망까지 나온 지 오래다.
그러나 태초에 컴퓨터, 특히 IBM 호환 PC라는 건 텍스트 모드만 있다가 그래픽 모드라는 게 나중에 추가됐다. 그것도 그래픽 모드는 320*200이라는 막장급의 낮은 해상도에 4색짜리인 CGA에서 첫 시작을 했다.

시작은 심히 미약했다. 이런 저해상도 저성능 컴퓨터에서는 쑤제 도트 노가다로 최적화된 그래픽이나 비트맵 글꼴이 속도와 메모리 면에서 모두 우월했기 때문에 그게 세상을 평정했다.
그러나 컴퓨터 화면이 커지고 해상도가 크게 올라가면서 단순히 픽셀보다 더 고차원적인 단위를 도입할 필요가 생겼다. 물론 예나 지금이나 메뉴와 아이콘, 프로그램 제목 표시줄의 글자 크기는 제어판에서 간단히 고칠 수 있었지만 영향을 받는 건 오로지 그것뿐. 대화상자 같은 다른 요소들의 크기는 변하지 않았다.

그 고차원적인 단위를 일명 시스템 DPI라고 부른다.
평소에야 이 단위는 언제나 관례적으로 100%로 맞춰져 있었으며, 이게 125나 150% 같은 큰 값으로 맞춰져 있으면 응용 프로그램은 창이나 글자의 크기도 원칙적으로는 이에 비례해서 키워서 출력해야 한다.

대화상자는 픽셀이 아니라 내부적으로 DLU라는 추상적인 단위를 사용해서 컨트롤들을 배치하며 이 단위는 시스템 DPI를 이미 반영하여 산정된다. 하지만 CreateWindowEx를 써서 픽셀 단위로 컨트롤을 수동으로 생성하는 코드들이 이런 시스템 DPI를 고려하지 않고 동작한다면 프로그램의 외형이 많이 이상하게 찍히게 된다.

여기까지가 Windows 95부터 8까지 오랫동안 지속된 프로그래밍 트렌드이다. 시스템 DPI는 단순히 메뉴와 아이콘의 글자 크기와는 달리 운영체제 전체에 끼치는 여파가 매우 크다. 이건 값을 변경하려면 운영체제를 재시작하거나 최소한 모든 프로그램을 종료하고 현 사용자가 로그인을 다시 해야 했다.

시스템 DPI라는 개념 자체에 대한 대비가 안 된 프로그램도 널렸는데, 응용 프로그램들이 시스템 DPI의 실시간 변화에까지 대비하고 있기를 바라는 건 좀 무리였기 때문이다. 시스템 메트릭이 싹 바뀌기 때문에 이미 만들어져 있는 윈도우들이 다 재배치돼야 할 것이고 후유증이 너무 크다.

그런데 지난 Windows 8.1은 이 시스템 DPI에 대해서 또 어마어마한 손질을 가했다.
간단히 결론부터 말하자면 사용자가 재부팅 없이도 DPI를 막 변경할 수 있게 했다. 실행 중에 DPI가 변경되면 WM_DPICHANGED라는 새로운 메시지가 온다. 그리고 응용 프로그램은 자신이 실시간 DPI 변경에 대응 가능한지 여부를 운영체제에 별도의 API 내지 매니페스트 정보를 통해 지정 가능하게 했다.

DPI 변경에 대응 가능하지 않은 레거시 프로그램들은 시스템 DPI가 바뀌었는지 알지도 못하고 virtualize된 샌드박스 속에서 지낸다. DPI가 150%로 바뀌면서 사용자의 화면에 보이는 창 크기가 100에서 150으로 늘었지만, 응용 프로그램은 여전히 자신의 최대 크기가 100인줄로 안다. 그래서 100*100 크기로 그림을 찍으면 그건 운영체제에 의해 1.5배 비트맵 차원에서 크게 확대되어 출력된다.

그 프로그램은 처음부터 시스템이 150% DPI인 것을 알았으면 그에 맞춰 실행되었을 수도 있다. 그러나 실행 중의 DPI 변경까지 예상하지는 못하며, 그런 API가 도입되기 전에 개발되었기 때문에 운영체제가 그래픽 카드의 성능을 활용하여 그런 보정을 해 주는 것이다.
물론 이렇게 확대된 결과는 계단 현상만 뿌옇게 보정된 채 출력되기 때문에 화질이 좋지 못하다. 응용 프로그램이 고해상도 DPI 변화를 인식하여 직접 150*150으로 최적화된 그림을 다시 그리는 게 바람직하다.

그리고 시스템 DPI는 제어판 설정의 변경을 통해서만 바뀌는 게 아니다.
Windows 8.1부터는 모니터별로 시스템 DPI를 다르게 지정할 수 있다. 그래서 100%(96dpi)짜리 모니터에서 돌아가고 있던 프로그램 창을 125%(120dpi)짜리 커다란 모니터로 옮기면 거기서는 동일 프로그램이 그 DPI에 맞춰서 동작해야 한다. 물론 DPI가 바뀌었다는 메시지는 운영체제가 보내 준다.

이렇듯, 응용 프로그램은 처음에는 (1) 고해상도 DPI를 인식할 것만이 요구되었다가 나중에는 (2) 실행 중에 DPI가 변경되는 것에도 대비가 되어야 하는 것으로 요구 조건이 추가되었다.
옛날에는 시스템 전체의 화면 해상도나 색상수를 재부팅 없이 실시간으로 바꾸는 것도 보통일이 아니었는데 이제는 DPI의 변경도 그 범주에 속하게 되었다.

재부팅이 필요하다는 이유 때문에 그런지 Windows Vista는 전무후무하게 DPI의 변경에 마치 시스템의 시각 변경처럼 '관리자 권한' 딱지가 붙어 있기도 했는데 이것도 참 격세지감이다.

Posted by 사무엘

Windows에서 C/C++ 언어로 EXE를 만들 때는 시작점으로 WinMain이라는 함수가 쓰인다.
얘는 먼 옛날 16비트 시절과, 지금의 32/64비트 사이에 바뀐 게 거의 없다. HINSTANCE hInst, HINSTANCE hPrevInst, PSTR pszCmdLine, int nCmdShow 라는 네 종류의 인자 중에서 32비트로 오면서 바뀐 것은 hPrevInst이 언제나 NULL이라는 것밖에 없다. 그것도 과거에는 복잡하던 게 더 간결해진 변화이기 때문에 실질적으로 신경 쓸 필요가 없다.

옛날 16비트 시절에 HINSTANCE는 파일 차원에서 동일한 프로그램이 중복 실행되었을 때 각 실행 문맥을 구분하는 일종의 메모리 번호표였다. 한 프로그램이 완전히 처음 실행될 때는 hPrevInst가 NULL인데 두 번째 실행되면, 먼저 실행된 프로그램이 받았던 hInstance가 다음 인스턴스의 WinMain 함수에서 hPrevInst로 전달되고..
세 번째 중첩 실행되면 아까 그 두 번째 프로그램의 신규 핸들이 거기의 hPrevInst로 전달되는 형태였다. 단일 방향 연결 리스트의 head 노드 같은 느낌이다.
자기 자신 말고는 주변에 무엇이 있는지 일부러 특수한 API를 써서 조회를 하지 않으면 도무지 알 수 없는 32비트 이상 보호 모드에서는 정말 상상하기 힘든 관행이다.

EXE는 그렇고 그럼 DLL은 어떨까? DllMain이라는 기본적인 형태는 동일하지만 16비트 시절에는 아무래도 멀티스레드 같은 건 존재하지 않았으니까 DLL_PROCESS_(ATTACH/DETACH)만 있었고, 나중에 DLL_THREAD_*가 추가된 정도일까?

사실은 그렇지 않다.
옛날에는 BOOL DllMain(HINSTANCE hInst, DWORD fdwReason, PVOID pReserved)라는 형태의 함수 자체가 없었다.
그 대신 완전히 다른 int FAR PASCAL LibMain(HANDLE hInst, WORD wDataSeg, WORD wHeapSize, LPSTR lpszCmdLine) 라는 함수가 있었으며, DLL이 처음 로드되었을 때에 이게 한 번만 호출되곤 했다.

16비트 시절에 DLL은 프로세스 독립성이 보장되지 않았다.
지금이야 B.DLL을 사용하는 A.EXE가 두 번 중첩 실행되면 두 인스턴스에 대해서 B.DLL이 제각각 로드되어 DLL_PROCESS_ATTACH가 오지만..
옛날에는 A.EXE가 중첩 실행되었더라도 B.DLL에서 LibMain은 첫 로딩될 때 한 번만 실행되었다. 그리고 자신이 A의 두 번째 인스턴스에 의해 중첩 로드되었다는 사실을 알 길이 없었다. A가 B.DLL에 별도로 정의되어 있는 초기화 함수 같은 것을 호출하지 않는다면 말이다.

LibMain 함수의 인자를 살펴보면, 첫 인자는 자기 자신을 식별하는 인스턴스 핸들이다.
하지만 16비트 시절에는 DLL은 중첩 로딩이 되지 않고 자신의 전역변수 값이 모든 프로그램에서 공유되었다. 그렇기 때문에 저 값은 EXE의 WinMain에서 전달되는 인스턴스 핸들과는 달리 딱히 변별성은 없었을 것이다. 시스템 전체를 통틀어 같은 값이 들어왔으리라 생각된다.

그 다음 wDataSeg와 wHeapSize는 딱 보기만 해도 16비트스러운 암울한 값이다. 이게 어떤 의미를 갖고 이것으로 무엇을 할 수 있는지 잘 모르겠다.
데이터 세그먼트(DS) 레지스터 값은 뭐 어쩌라는 건지 잘 모르겠지만 어쨌든 실행할 때마다 다른 값이 들어올 수는 있어 보인다. 그 반면 wHeapSize는 이 DLL을 빌드할 때 def 파일에다가 지정해 줬던 로컬 힙의 크기이다. 즉, 이 DLL이 지금 형태 그대로 존재하는 한 언제나 고정된 값이 넘어온다.

마지막으로 lpszCmdLine은 더욱 기괴하다. EXE도 아니고 DLL을 어떻게 인자를 줘서 로딩한단 말인가? LoadLibrary 함수에 인자를 전달하는 기능이 있지도 않은데 말이다. 호스트 EXE에 전달된 인자를 되돌리는 것도 아닌 듯하다. 실제로 거의 대부분의 경우 이 인자의 값은 어차피 그냥 NULL이라고 한다.

16비트 DLL의 첫 관문인 LibMain은 기괴한 점이 여기저기서 발견된다.
DLL에 배당되어 인자로 전달된 데이터 세그먼트는 앞으로 빈번하게 사용되는 것을 염두에 두고 메모리 상의 주소가 바뀌지 않게 lock이 걸린다고 한다. 운영체제는 아니고 컴파일러가 lock을 거는 코드를 기본적으로 추가해 넣는 듯하다.
그래서 옛날 소스 코드를 보니, 이유는 알 수 없지만 LibMain에 보통 이런 코드가 들어갔다고 한다.

if (wHeapSize > 0) UnlockData (0);

즉, 아직은 lock을 걸지 말고 도로 재배치 가능한 상태로 놔 두겠다는 뜻이다. 그리고 LockData/UnlockData는 Windows 3.1의 windows.h에 이렇게 매크로로 정의돼 있다.

#define LockData(dummy)     LockSegment((UINT)-1)
#define UnlockData(dummy)   UnlockSegment((UINT)-1)

옛날에는 (Un)LockSegment라는 함수가 있었다. 그리고 Windows 3.x보다도 더 옛날에는 (Un)LockData라는 함수도 별도로 있었는데, 용례가 간소화돼서 Data의 기능이 Segment로 흡수된 듯하다. (가상 메모리라는 게 없던 Windows 2.x 리얼 모드 시절의 잔재라고 함.) 그러니 Data는 레거시 호환을 위해 매크로로 바뀌고, 인자 역시 쓰이지 않는 dummy로 바뀐 것이다.
평소에는 특정 세그먼트 lock/unlock을 하는데, (UINT)-1을 주면 모든 영역을 그렇게 하는 것 같다. 어떤 경우든 wDataSeg의 값이 직접 쓰이지는 않는다.

LibMain은 초기화가 성공하면 1을 되돌리고 그렇지 않으면 0을 되돌려서 DLL의 로딩을 취소하게 돼 있었다. 이것은 오늘날의 DllMain과 동일한 점이다.
그럼 16비트 시절에는 시작 다음으로 DLL의 종료 시점을 감지하려면 어떻게 해야 했을까? EXE와는 달리 DLL은 main 함수의 종료가 곧 프로그램의 종료는 아니니까 말이다.
또한 16비트 시스템의 특성상 비록 매 프로세스의 종료 시점을 감지하는 건 불가능하겠지만, 그래도 아까 중복 실행되었던 A가 최후의 인스턴스까지 모두 종료되어서 B.DLL이 메모리에서 사라져야 하는 시점이 언젠가는 올 테니 말이다.

이것도 방법이 굉장히 기괴했다. DLL이 메모리에서 제거되기 전에 운영체제는 해당 DLL에서 'WEP'라는 이름을 가진 함수를 export 테이블에서 찾아서 그걸 호출해 줬다.

//16비트 시절에 _export는 오늘날의 __declspec(dllexport) 와 비슷한 단어임.
int FAR PASCAL _export WEP (int nExitCode);

이 함수 역시 성공하면 nonzero를 되돌리게 돼 있지만, 어차피 프로그램이 일방적으로 종료되는 상황에서 함수의 인자나 리턴값은 무시되다시피할 뿐 거의 의미가 없었다.
하다못해 오늘날 DllMain의 DLL_PROCESS_DETACH처럼 자신이 FreeLibrary에 의해 해제되는지, 프로세스의 종료에 의해 일괄 해제되는지라도 알 수 있으면 좋을 텐데 그 시절에 그런 정보를 바랄 수는 없었다.
참고로 WEP는 그냥 Windows Exit Procedure의 약자였다. -_-;;

이렇듯, 형태가 거의 바뀐 게 없는 WinMain과는 달리, DLL의 입구 함수는 16비트 시절과 지금이 달라도 너무 달라서 문화 충격이 느껴질 정도이다. 예전에도 16비트 Windows 프로그래밍에 대해서 글을 종종 쓰고 DLL에 대해서도 언급한 적이 있었는데 이런 내역에 대해서 정리한 적은 없었기 때문에 또 글을 남기게 됐다. 옛날에는 이렇게 불편한 환경에서 도대체 프로그램을 어떻게 만들었나 싶다.

LibMain과 WEP를 DllMain으로 통합한 것은 백 번 잘한 조치였다.
16/32비트 이식성을 염두에 둔 코드라면 DllMain에다가 LibMain과 WEP를 호출하고, 반대로 LibMain과 WEP에서 적절하게 서로 다른 인자를 줘서 DllMain을 호출하는 계층도 생각할 수 있으며, 과거에는 이런 관행이 실제로 존재했다고 한다. 마치 윈도우 프로시저와 대화상자 프로시저의 형태를 통합한 계층을 따로 만들어 썼듯이 말이다.

Posted by 사무엘

1.
코코아, Win32 API, MFC 같은 플랫폼 종속적인 API를 전혀 쓰지 않고 순수하게 표준 C/C++ 라이브러리 함수만으로 백 엔드 엔진만 만들었다 해도 Windows + Visual C++로 작성한 코드가 안드로이드 내지 맥 같은 다른 플랫폼에서는 곧장 컴파일 되지 않거나, 빌드된 프로그램이 의도한 대로 동작하지 않을 수 있다.

개인적으로는 회사에서 wchar_t 때문에 굉장한 불편을 겪었다. 잘 알다시피 Windows에서는 이게 2바이트이지만 다른 플랫폼에서는 4바이트이다. 플랫폼을 불문하고 2바이트 문자 단위로 동작하는 strcpy, strcat, strlen, printf, atoi 등등은 직접 구현이라도 해야 하는지..? 특히 파일로 읽고 쓰려면 말이다.

C++ string 클래스야 typedef std::basic_string<unsigned short> string16; 부터 먼저 만들어 놓고 썼다지만 그렇게 처음부터 객체를 만드는 게 아니라 raw memory를 다루는 상황에서는 해결책이 되지 못한다.

이런 게 원초적인 애로사항이고 또, 소스 코드 내부에서 유니코드 문자열 상수를 표현하는 방식도 또 다른 난관이다.
언어가 제공하는 L"" 문법은 wchar_t형 기반이다. 그러니 wchar_t 말고 명시적으로 unsigned short 배열에다가는 문자열 상수를 쓸 수 없고 "가"를 { 0xac00, }로 표현하는 식의 삽질을 해야 한다.

거기에다 비주얼 C++은 C++ 소스 코드나 명령 프롬프트가 UTF8과 전혀 친화적이지 않다는 다른 문제점도 있어 더욱 불편하다. 유니코드가 등장하면서 플랫폼별로 문자열을 다루는 방식이 너무 심하게 파편화됐다는 생각이 든다.
문자열을 저장하고 메모리를 관리하는 방식이 난립하는 것 말고(string class!) 문자열을 구성하는 문자를 표현하는 방식 그 자체부터가 말이다.

2.
하루는 Visual C++에서 표준 C 함수만 사용해서 만들어 준 코드를 안드로이드 내지 맥 OS 플랫폼으로 넘겨 줬더니 컴파일 에러가 났다. wcslen 함수가 선언되지 않았다고 꼬장을 부리는데 도무지 원인을 알 수 없었다. strlen은 인식되는데 wcslen은 왜 인식이 안 되는 거지?

그런데 알고 보니 wcslen은 strlen과는 달리 string.h가 아니라 wchar.h에 선언되어 있었다.
Visual C++은 string과 wchar에 wcslen을 모두 선언해 줬지만 타 플랫폼은 그렇지 않았다. 흐음~ 나의 불찰이다.

malloc/free 함수는 stdlib.h에도 있고 malloc.h에도 있다.
memset/memcpy는 string.h에도 있고 memory.h에도 있다.
그런 예가 몇 가지 있는 건 알고 있었지만 wcs* 함수는 Visual C++에만 string/wchar 겸용으로 선언돼 있었던 듯하다.
C 인클루드 헤더는 한 함수가 오로지 한 헤더에만 유일하게 존재하지는 않기도 하다는 것이 흥미롭게 느껴진다.

3.
요즘 표준 라이브러리들의 헤더 파일을 보면 함수의 인자마다 타입과 이름만 있는 게 아니라 소스 코드 정적 분석을 위한 Annotation 정보가 같이 들어있다. 같은 포인터라 해도 이건 읽기 전용, 쓰기 전용.. 쓴다면 어떤 조건으로 얼마만지 써지는지(옆의 인자만큼~) 같은 거.

그래서 함수 하나만 봐도 선언도 정말 덕지덕지 길어졌다. 이 정보들이 처음부터 있지는 않았을 텐데, 그 수많은 API들의 선언에다 일일이 다 기입하는 건 완전 중노동이었을 것 같다.
한때는 정적 분석 기능은 개발툴의 유료 최상급(엔터프라이즈 같은) 에디션에서나 접근 가능한 고급 기능이었는데, 이것도 죄다 무료로 풀리는 듯하다. 유료 GUI 툴킷이 통째로 MFC에 들어갔듯이 말이다.

4.
요즘은 CPU 아키텍처야 x86 아니면 ARM만 살아 남아서 그런지, 이식성을 논할 때 비트 순서, 일명 endian-ness 얘기는 별로 안 나오는 것 같다. 우리 주변에서 흔히 볼 수 있는 x86은 요지부동 리틀 엔디언인 반면, 옛날에 매킨토시의 밑천이던 PowerPC는 빅 엔디언이었다. 트루타입 폰트 포맷이 빅 엔디언 기반인 건 이런 애플의 영향력이 닿아서 그랬던 걸까?

먼 옛날 대학 시절에 터미널에 원격 접속해서 거기서 C 컴파일러를 돌려 봤던 게 본인으로서는 빅 엔디언 컴퓨터를 직접 구경한 처음이자 마지막 경험이다. 큰 자릿수가 앞부분부터 저장되다니 굉장히 신기했다. 이건 앞으로 수동 변속기 차량이라든가 IA64 (Itanium) 컴퓨터만큼이나 앞으로 또 접할 일이 없는 초희귀템으로 남을 것 같다.

최신 CPU인 ARM은 하드웨어 차원에서 endian-ness를 모두 지원하기 때문에 아무 쪽으로든 취사 선택이 가능하다고 한다. 사람으로 치면 완벽한 양손잡이이고, 철도에다 비유하자면 좌측/우측통행 전용 복선 철도가 아니라 어느 쪽으로든 운용 가능한 단선병렬과 비슷한 격이다.
결국은 다 지원하는 것으로 가는구나. 한글 코드에서 조합형/완성형 논쟁, CPU 미시구조에서 CISC/RISC 논쟁, 리눅스에서 그놈/KDE 셸 논쟁도 다 비슷한 방식으로 종결됐듯이 말이다.

비트 순서 같은 하드웨어 특성을 타는 요소 말고 소프트웨어 플랫폼과 언어 차원에서.. 사소하지만 코드의 이식성을 은근히 저해하는 요소는 내 경험상 몇 가지 있었다. 그러니 GUI가 없고 특정 운영체제의 API를 사용하지 않았다고 해서 무작정 이식이 잘 될 거라고 기대할 수는 없다.

5.
당장 떠오르는 건, 64비트 상수를 나타내는 % 문자가 파편화돼 있다(%I64d, %lld). 그리고 long이 Windows에서는 64비트 플랫폼에서도 여전히 32비트이지만 타 플랫폼은 그렇지 않다. 그러니 이식성을 생각한다면, long은 파일 오프셋 계산에 영향을 주는 곳에서는 절대로 구조체 멤버로 쓰이거나 sizeof의 대상이 돼서는 안 된다. (앞서 논했던 char_t도 마찬가지이고!) 그런 데서는 정말 닥치고 int32, uint64처럼 비트수를 명시한 typedef를 쓰는 게 안전하다.

C#이나 Java, D는 아무래도 1990년대 중후반에 PC에서 32비트 CPU 정도는 확실하게 정착한 뒤에 등장한 최신 언어이다 보니, 32/64비트 플랫폼을 불문하고 long이 처음부터 일관되게 64비트였다. 하지만 C/C++은 그보다 훨씬 전부터 컴퓨터 하드웨어의 발전의 격변기와 동고동락했던 언어이다 보니, 저런 깔끔함을 기대할 수는 없는 노릇이 돼 있다.

그리고, fopen에다 주는 옵션에서 r/w/a (+)만 있고 b/t 모드가 지정되지 않았을 때..
Windows는 binary 모드로 동작하는 반면 맥에서는(타 플랫폼은 확인 안 해 봄) 디폴트가 text였다. 멀쩡한 코드가 완전 엉뚱하게 동작하고 파일이 쓰라는 대로 써지지 않고 읽으라는 대로 읽히지 않아서 한창 문제를 추적했더니.. 결국은 이런 데에서 차이가 있었다. 이것도 표준 규격이 정의돼 있지 않나 보다.

말이 나왔으니 말인데, Visual C++은 fopen조차 쓰지 말고 fopen_s를 쓰라고 권한다. printf_s, qsort_s 같은 *_s 물건은 안전하고 편리하긴 하지만 언제까지나 이식 불가능한 Visual C++만의 전유물로 남을지 궁금하다..

strdup와 _wcsdup는 표준처럼 생겼지만 진짜 표준인지 아닌지 알쏭달쏭한 놈이다. 앞에 괜히 밑줄이 있는 게 아니다. _wtoi 이런 것도 Windows를 벗어나면 컴파일되지 않을 가능성이 높은 지뢰이니 strtol, wcstol을 쓰는 게 안전하다.
strtok의 경우 Visual C++은 토큰 컨텍스트를 따로 받는 _s 버전을 추가한 반면, 타 플랫폼은 strtok, wcstok 함수 자체가 그렇게 고쳐진 것도 있다. 이런 것들도 너무 골치아프다.

6.
끝으로, 이건 이식성하고는 큰 관계가 없는 얘기다만..
형변환 연산자인 static_cast는 코드 생성 차원에서 하는 일이 전혀 없거나(base class* → derived_class*, enum → int), 뻔한 값 보정(float → int, char → int), 또는 다중 상속일 때는 컴파일 타임 때 결정된 고정된 상수만치 this 포인터 보정 정도만(derived_class_B* → base_class) 하는 걸로 으레 생각했다.

그런데 다중 상속을 다룰 때 꼭 그런 일만 하는 건 아니다. 포인터가 처음부터 NULL이었다면, 거기서 또 얼마를 뺄 게 아니라 cast된 포인터도 그냥 NULL을 주는 예외 처리를 해야 한다. 과연 생각해 보니 그렇다. 아래 코드를 생각해 보자.

struct A { int a,b; };

struct B { int c,d; };

struct C: public A, public B { int e,f; };

void foo(B *pm) { printf("Received %p\n", pm); }

int main()
{
    C m, *pm=&m;
    printf("Passing %p\n", pm); foo(pm);
    pm=NULL; printf("Passing %p\n", pm); foo(pm);
    return 0;
}

단일 상속과는 달리, 다중 상속에서 passing의 값과 received의 값이 서로 달라질 수 있다고 아는 것은 하나를 아는 것이다.
그러나 NULL일 때는 다중 상속이더라도 언제나 NULL이 유지된다는 것이 함정이다. 우와.. 지금까지 한 번도 그런 경우를 생각한 적이 없었는데.. 꽤 충격적이다. 간단하지만 다중 상속의 보이지 않는 오버헤드를 보여주는 요소 중 하나이다.

Posted by 사무엘

C++ 클래스에서 타입이 char나 int 같은 정수형 스칼라(배열이 아닌)인 static const 멤버는 선언 후에 별도의 정의를 따로 안 해 줘도 된다. 선언과 동시에 값을 지정할 수 있다. 본인은 이에 대해서 3년 전에도 한번 글을 썼던 적이 있다.

class foo {
public:
    static const int bar = 500;
};

하지만 멤버가 char나 int 같은 간단한(primitive) 타입이 아니고 다른 구조체이거나, 혹은 간단한 타입이라도 배열이라면 얘기가 달라진다. 아까처럼 즉석 초기화를 할 수 없으며, 반드시 정의를 해 줘야 된다.

//헤더 파일
class foo {
public:
    static const POINT bar1;
    static const int bar2[];
};

//소스 파일
const foo::bar1 = { 1024, 768 }; // .x, .y
const foo::bar2[] = { 1, 2, 100 }; // [0], [1], [2]

자, 여기까지는 뭐 당연한 사실이다. 그런데 얼마 전엔 회사에서 이와 관련된 기괴한 일을 하나 겪어서 이곳에다 소개하고자 한다.
static const int 형태로 상수를 하나 추가해서 사용했는데 컴파일러가 이걸 도무지 인식을 못 하고 링크 에러를 내는 것이었다. global scope에 선언된 const 야 C++에서는 static이 디폴트이기 때문에 extern을 명시적으로 지정해야 한다지만, 멀쩡한 C++의 static const 멤버를 왜 인식을 못 하지?
게다가 더 이상한 건 Visual C++과 xcode는 다 문제 없는데 안드로이드의 빌드 환경인 gcc만 저런다는 것이었다.

멀쩡한 코드를 고치고 재빌드 하면서 잠시 헤매긴 했지만, 문제 자체는 구글링을 통해 원인을 찾아서 곧 해결할 수 있었다.
답부터 말하자면, 저 위의 bar는 선언과 초기값 지정이 되어 있음에도 불구하고 const int foo::bar1; 이라고 몸체도 소스 코드 어딘가에 정의해 줘야 했다. 단, 500이라고 초기값을 지정하는 건 선언부와 정의부 중 한 곳에다가만 하면 된다. 마치 함수의 디폴트 인자를 선언부와 정의부 중 한 곳에만 주면 되듯이.

소스 코드에서 어떤 숫자에다가 명칭을 부여하기 위해서는 enum이나 전처리기 #define을 사용할 수 있다. 이에 비해 const는 위의 두 방법과는 달리 명시적인 타입을 가지며, & 연산자를 이용해서 값의 주소도 얻을 수 있다는 차이가 있다.

static const 멤버를 R-value로만 쓰는 것은 그때 그때 그 숫자를 말 그대로 상수 형태로 집어넣는 것과 같다. 그러니 enum이나 #define과 별 차이가 없으며, 굳이 이 변수의 실체(= 주소)가 없어도 된다.
그러나 이 값을 그대로 파일에다 쓴다거나 할 때는 값이 담긴 메모리 주소를 줘야 한다. 그리고 C++의 템플릿 라이브러리 중에도 일단 value가 아니라 참조자가 전달되는 함수에다가 static const 멤버를 넘겨주면 그 멤버의 주소가 필요해진다.

그리고 그렇게 값이 아니라 주소가 필요한 경우가 있다면, gcc는 비록 선언부에서 값이 지정된 static const 멤버라 해도 별도의 몸체의 정의가 있어야만 링크를 제대로 수행해 줬다. 이니셜라이저가 있는 것도 아니고, 그냥 선언부에 있는 변수를 거의 그대로 다시 써 주는 잉여일 뿐인데도 그게 꼭 필요했다. 그 반면 Visual C++ 등 타 컴파일러는 몸체 정의가 있건 없건 결과는 동일하게 나왔다. 어째 이런 차이가 존재할 수 있는 걸까?

한편으로 gcc는, 주소만 요구하지 않는다면 구조체나 배열까지는 아니어도 float, double 같은 부동소수점 스칼라 상수를 몸체 정의 없이 static const로 선언하는 것도 허용해 줬다.

class foo {
public:
    static const double bar4 = 0.0025;
};

이거야말로 비표준이며 일단 Visual C++ 등 여타 컴파일러에서는 허용되지 않음에도 불구하고 gcc는 이를 지원한다. 혹시 나중에 표준으로 등재됐다면 댓글로 알려 주시기 바람. 요즘 C++은 하루가 멀다 하고 급변하고 있어서.. 과거 C++이 98과 03 버전을 거친 뒤 갑자기 1x대부터 확 바뀌기 시작했는데, 이는 마치 마소가 2000년대에 닷넷 때문에 C++ 지원을 등한시하다가 2010년대부터 트렌드가 바뀐 것과도 분위기가 일치하는 것 같다.

enum은 정수형 타입만 지원하기 때문에 실수 상수를 정의하는 건 #define 아니면 const밖에 선택의 여지가 없는데 gcc처럼 할 수 있다면 편리할 것 같다.
다만 &foo::bar4가 필요하다면 gcc라도 물론 const double foo::bar4; 라는 몸체 선언이 추가로 필요해진다.
아무튼, static const 멤버와 관련하여 gcc의 특이한 면모를 다시 생각할 수 있는 시간이었다.

Posted by 사무엘

운영체제가 기본 제공하는 프레임과 제목 표시줄이 있는 윈도우라면, 사용자가 그 제목 표시줄을 좌클릭+드래그 하여 창을 다른 곳으로 옮길 수 있다.
그런데, 그런 프레임이나 제목 표시줄이 없는 특수한 형태의 윈도우를 만들었다. (Custom 스킨이 씌워진 리모콘이나 TV 모양의 동영상 재생기 같은..) 사용자가 이 창의 아무 표면이나 특정 부위를 드래그 해서 창의 위치를 옮길 수 있게 하려면 어떻게 하면 좋을까?

(1) 가장 단순무식한 방법은 WM_LBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP을 받아서 해당 기능을 직접 구현하는 것이다. 즉, LBUTTONDOWN 때 마우스를 캡처하고 마우스 포인터의 위치가 창의 화면 좌표에서 얼마나 떨어져 있는지를 파악한다. 그리고 캡처가 있는 상태에서 MOUSEMOVE가 오면 새 포인터의 위치에 상응하는 위치로 창의 위치를 옮긴다(SetWindowPos). 이 기능은 각각의 메시지 핸들러 함수에다 구현해도 되고, WM_LBUTTONDOWN 안에다가만 자체적인 message loop을 돌려서 구현해도 된다.

이건 드래그 앤 드롭 기능을 구현하는 절차와 비슷하다. 한 윈도우의 내부에서 그려지는 각종 그래픽 오브젝트에 대해서 드래그+이동을 구현하려면 저렇게 직접 코딩을 해 줘야 한다. 그러나 창 자체에 대해서 드래그+이동만을 구현하는 것은 사실 다음과 같이 더 간단한 방법도 있다. 이미 존재하는 기능을 운영체제에다가 요청만 한다는 것이 핵심 아이디어이다.

(2) 그 창에서 WM_NCHITTEST 메시지를 받아서 DefWindowProc의 리턴값이 HTCLIENT인 지점에 대해서도 HTCAPTION을 되돌린다.
그러면 운영체제는 이 창의 클라이언트 영역을 클릭+드래그 한 것도 제목 표시줄을 클릭+드래그 한 것과 동일한 것으로 간주한다. 그래서 드래그 시 창을 자동으로 이동시키게 된다.

이건 대부분의 경우에 굉장히 깔끔한 방법이긴 하지만, 창을 이동시키는 데 쓰이는(HTCAPTION으로 인식되는) 영역에 대해서 더 세부적인 제어를 하기가 어렵다는 게 흠이다. 즉, 거기를 우클릭 한다거나 더블클릭 한 것처럼, 이동과 관계 없는 다른 동작을 취한 것을 우리가 인식할 수 없다. 거기는 마우스 동작에 관한 한, 애초에 클라이언트 영역이 아닌 것으로 간주되어 버렸으니 말이다. 만약 그런 제어까지 해야 한다면 다음과 같은 또 다른 방법을 사용하면 된다.

(3) WM_LBUTTONDOWN이 왔을 때, 창을 이동시키는 기능에 해당하는 시스템 명령을 전달한다.
가장 간단하게 생각할 수 있는 방법은 PostMessage(m_hWnd, WM_SYSCOMMAND, SC_MOVE, 0); 이다. 이것은 Alt+Space를 눌러서 나오는 창의 시스템 메뉴에서 '이동'을 선택하는 것과 같은 효과를 낸다. 창에 제목 표시줄이나 시스템 메뉴가 없다고 해서 시스템 메뉴에 해당하는 기능 자체가 없어지지는 않기 때문이다.

단, 이것은 창을 끌어다 놓는 것과 정확하게 같은 기능은 아니다. 일단 마우스 포인터는 모양이 사방의 화살표 모양으로 바뀌고, 사용자의 key 입력을 기다리는 상태가 된다. 사용자가 ESC가 아닌 다른 key를 누르면 그때부터 마우스 이동으로 해당 창이 이동되는 모드가 된다. 심지어 좌클릭을 한 상태가 아니어도 된다.

SC_MOVE보다 더 직관적인 방법은.. 마소에서 정식으로 문서화하여 공개한 기능은 아니지만 사실상 공공연한 비밀이 돼 버린 기능을 사용하는 것이다. 좌클릭 메시지가 왔을 때 SC_MOVE (0xF010) 대신,
PostMessage(m_hWnd, WM_SYSCOMMAND, 0xF012, 0); 이라고 하면... 마우스를 누르고 있는 동안 창 이동이 아주 깔끔하게 구현된다. 직접 시도해 보시라. 이것이 SC_MOVE와 SC_MOVE+2의 차이이다.

시스템 명령 중에는 SC_MOVE나 SC_SIZE처럼 메뉴에 등재된 명령뿐만 아니라 해당 메뉴 명령을 누른 뒤에 부가적으로 실행되는 기능도 비공개 내부 ID가 부여돼 있다. 가령, SC_SIZE+1 (0xF001)부터 SC_SIZE+8 (0xF008)은 마우스 드래그로 창의 크기를 조절하는 명령을 바로 실행시킨다. 1부터 8까지 순서가 어떻게 되는가 하면 left, right, top, top-left, top-right, bottom, bottom-left, bottom-right이다. 해당 위치의 크기 조절 모서리와 대응한다는 뜻.
이거 배열 순서는 WM_NCHITTEST의 리턴값인 HTLEFT (10)와 HTBOTTOMRIGHT (17)와도 동일하다. 그러니 이해하는 데 어려움이 없을 것이다.

이 주제/테크닉과 관련하여 생각할 수 있는 다른 이야기들을 늘어놓자면 다음과 같다.

1. 추억.
과거에는 운영체제의 자체 기능을 사용해서 창의 위치를 옮기면, 창이 이동되는 동안에 창의 내용이 실시간으로 업데이트 되는 게 아니라 창의 경계 테두리만이 XOR 연산되어 그려졌다. 당연히 창을 일일이 다시 그리는 게 그 시절 옛날 컴퓨터로는 부담스러운 연산이었기 때문이다.
그러다가 1990년대 말, Windows 95를 넘어 98/2000으로 넘어갈 시기부터 창을 실시간으로 업데이트 하는 옵션이 추가되었고, 후대부터는 그게 당연한 관행이 됐다.

창의 테두리만 이동하고 있는 중에는 운영체제가 응용 프로그램으로 WM_MOVING (또는 WM_SIZING)이라는 메시지를 보냈는데, 이때 그냥 SetWindowPos로 창의 위치를 바꿔 버리면 운영체제의 옵션과 무관하게 '실시간 업데이트'를 시전할 수 있긴 했다.
하긴, 옛날에는 스크롤 막대조차도 스크롤 하는 동안 막대의 테두리만 이동하지 스크롤 대상 화면은 업데이트 되지 않는 경우가 있었다.

도스 시절도 마찬가지. 화면 전체의 업데이트가 키보드 연타 속도를 따라가지 못할 경우를 대비해서 일부 프로그램들은 화면을 표시하는 중에도 키보드 입력을 체크하곤 했다. 그래서 상하 화살표가 눌렸으면 화면을 다 업데이트 하지 않고 다시 스크롤을 했다. 그렇게 하지 않으면 나중에 키보드 버퍼가 꽉 차서 삑삑 소리가 났다.. ^^;;

2. Windows에는 이런 식으로 아기자기한 비공개 API가 더 있다.
캐럿의 깜빡임 주기를 나타내는 메시지 0x118는 흔히 WM_SYSTIMER이라고 표현하는 사람도 있는데, 어쨌든 유명한 유령 메시지이다. 이 메시지의 출현에 의존해서 동작하는 프로그램이 설마 있으려나 모르겠다.

또한,
::SendMessage( ::ImmGetDefaultIMEWnd(hWnd), WM_IME_CONTROL, 5, 0 );
이라고 하면 hWnd가 자신과 동일한 프로세스/스레드이든 불문하고 해당 창에 있는 Windows IME의 한영 상태를 얻어 올 수 있다고 한다. 리턴값이 1이면 한글, 그렇지 않으면 영문이다.
보통은 한영 상태를 얻으려면 해당 윈도우에 소속된 IME context 값을 ImmGetContext로 얻어 와야 하는데, 이거 내 기억이 맞다면 프로세스는 물론이고 스레드 경계도 넘지 못한다. 그런데 ImmGetContext나 ImmGetConversionStatus 호출 없이 저렇게 간단한 메시지로 한영 상태를 query할 수 있다니 신기한 노릇이 아닐 수 없다.

MSDN이고 Windows DDK고 어디든지 WM_IME_CONTROL을 찾아 보면, 거기에 문서화돼 있는 IMC_* 명칭들 중에 5라는 값을 가진 물건은 없다. 하지만 저 기능은 Windows 95 이래로 모든 운영체제에서 사용 가능하다. 게다가 5 대신 2를 주면 한영 상태를 바꿀 수도 있는 듯하다. (lParam에다가 새 값을 설정하고)
이런 것들은 마치 인터넷 지도에서 있는 그대로 표시되지 않고 숲으로 가려진 지대를 보는 듯한 느낌이다.

3.
창을 드래그 해서 옮기는 것이야 제목 표시줄을 단 1픽셀이라도 끌면 창이 바로 반응해서 움직인다.
하지만 일반적으로 텍스트나 아이콘을 '드래그 앤 드롭'을 해서 옮기는 건 그렇게 곧장 반응하지는 않게 돼 있다. 창의 위치만을 옮기는 것과는 달리, 일반적인 드래그 앤 드롭에는 파일을 복사하거나 옮기고 텍스트 문서의 내용을 변경하는 등 더 크리티컬한 결과를 초래하는 동작을 수반할 수도 있기 때문이다.

Windows에서 UI 가이드라인 상으로는, 마우스를 클릭해서 약 2픽셀이던가 그 이상 포인터가 가로 또는 세로로 실제로 움직였을 때.. 혹은 움직이지 않았더라도 클릭 후 1초 가까이 시간이 지났을 때에야 드래그가 시작되게 돼 있다. 드래그 인식을 위한 최소 한계치는 GetSystemMetrics(SM_CXDRAG) / SM_CYDRAG를 통해 얻을 수 있다.

허나, 이걸 일일이 코딩하는 건 드래그를 곧장 인식하는 것보다 굉장히 번거롭고 귀찮은 일이다. 그래서 Windows에는 아예 DragDetect라는 함수가 있다. WM_LBUTTONDOWN이 왔을 때 요 함수를 먼저 호출해서 OK가 오면 그때부터 드래그 모드로 진입하면 된다. DragDetect는 자체적으로 메시지 loop을 돌면서 마우스가 표준 규격 이상만치 움직였는지, 시간이 경과했는지, 사용자가 무슨 key를 눌렀는지 등을 총체적으로 판단해서 드래그 모드로 진입할지 여부를 알려 준다.
이런 함수도 있다는 걸 알면 GUI를 구현할 일이 있을 때 도움이 많이 될 것이다.

Posted by 사무엘

과거 Windows 9x 시절에는 내부의 16비트 코드가 gdi/user 계층에서 사용하는 64KB짜리 구닥다리 힙으로 인해 일명 '리소스' 제약이란 게 있었다. 그래서 램이 수백, 수천 MB으로 아무리 많더라도, 프로그램을 많이 띄워서 UI와 관련된 오브젝트들을 이것저것 생성하다 보면 리소스가 바닥 나고 운영체제가 패닉에 빠지곤 했다.

지금으로서는 정말 말도 안 되는 황당한 제약이다. 9x에서는 메모장이 60KB를 조금만 넘는 파일도 열 수 없었던 것처럼 말이다. 숫자 세는 단위 자체가 16비트로 제한돼 있으니, 실제 메모리가 아무리 썩어 넘쳐도 셀 수 없는 영역은 몽땅 그림의 떡이었던 것이다.

꼴랑 64KB짜리 중에서 메모리가 몇만 바이트 남았다고 출력하는 건 좀 민망했는지, 남은 리소스의 양은 퍼센트 비율로 출력되었으며, Windows 기본 프로그램들의 About 대화상자에서 값을 간단히 확인할 수 있었다.
그런데 이 퍼센티지를 얻어 오는 API는 무엇일까? Windows 3.x에서 도입된 GetFreeSystemResources라는 함수가 그 주인공이었다. 얘는 0~2 사이의 정수 인자도 받아서 시스템 전체, GDI, user 종류도 얻을 수 있었다.

Windows 3.1 SDK에서 windows.h를 열어 보면 저 함수는 #if WINVER >= 0x030a 안에 고이 감싸진 채 선언되어 있었다. 즉, 초창기부터 처음부터 존재하지는 않았다는 뜻이다. Windows 1, 2 시절에는 샘플 프로그램들의 About 대화상자를 보면 그냥 남은 주메모리의 양(수백 KB)과 주 하드디스크의 남은 용량만 출력했지, 저런 비율을 따로 알려 주지는 않았었다. NT 계열이 아니라 도스 위에서 돌아가던 16비트 시절에도 말이다.

저 함수의 공식적인 수명은 Windows 3.x에서 그대로 끝났다. 32비트 Windows API에는 정식으로 이식되지 않았으며, 여전히 16비트 user.exe를 통해서만 제공되었다. 그렇기 때문에 32비트 프로그램이 시스템 정보 같은 기능을 구현할 일이 있어서 남은 리소스 퍼센티지를 얻으려면... 원래는... 마치 32/64비트 훅 DLL을 따로 만들듯이 16비트 DLL을 만들어서 그 DLL이 16비트 API를 호출하여 값을 얻고.. 32비트 프로그램은 그 DLL과 flat 썽킹을 해서 의사소통을 해야 했다. 썽킹에 대해서는 지난번에 한번 다룬 적이 있다.

이런 번거로운 일이 필요한 이유는 32비트 프로그램이 user.exe로 직통으로 API 호출을 할 수는 없기 때문이었다. 일단은 말이다.
옛날에 한컴사전이 노클릭 단어 인식 기능을 구현하기 위해 그래픽 API 훅킹을 했었는데, 훅킹용으로 32비트 DLL과 16비트 DLL이 모두 있었던 것이 기억에 남아 있다. 32비트 gdi32.dll뿐만 아니라 16비트 gdi.exe로 직통으로 들어가는 그래픽 API 호출까지 잡아 내서 거기 문자열을 얻기 위해서 만든 거지 싶다. 그러니 32비트 DLL엔 훅 프로시저가 들어있고 16비트 DLL엔 썽킹 루틴이 들어있었을 것이다.

그런데, 없는 길을 부분적으로나마 만들어 낸 용자가 그 시절에 이미 있었다.
Windows 9x의 kernel32.dll이 제공하는 비공개, 봉인, 문서화되지 않은 API를 이용해서 32비트 프로그램이 user.exe를 직통으로 호출해서 리소스를 얻어 온 것이다. Windows 95 Programming Secret의 저자인 Matt Pietrek가 그 용자이다.

마소 내부에서만 사용할 목적으로 만들어진 듯한 비공개 API 중에는 16비트 바이너리를 로딩할 수 있는 일명 LoadLibrary16 / GetProcAddress16 / FreeLibrary16 세트가 있다. 얘는 kernel32.dll의 export table에 이름이 노출돼 있지도 않아서 ordinal 번호로만 접근이 가능한데.. 이 번호를 근성의 리버스 엔지니어링으로 일단 알아 냈다. 참고로 얘들은 Generic 썽킹용으로 쓰이는 LoadLibraryEx32W처럼 뒤에 32W가 붙은 함수하고는 다른 물건이므로 혼동하지 말 것.

그런데 알아 냈다고 전부가 아니다. Windows 9x의 GetProcAddress에는 특별한 보정 코드가 들어 있어서 kernel32만은 예외적으로 ordinal을 이용한 함수 주소 요청을 고의로 막았다! 고로 이름이 없이 ordinal만 존재하고 운영체제 내부에서만 사용되는 비공개 API를 제3자 프로그램이 멋대로 사용하는 걸 자연스럽게 차단했다.

이런 조치를 취한 심정을 이해 못 하는 바는 아니다. 같은 함수라도 운영체제의 버전이 바뀜에 따라 ordinal이 수시로 바뀔 수 있으니 일반적인 함수라면 어차피 번호가 아닌 이름만으로 import하는 게 맞다.
또한 프로그램들이 비공개 API를 무단으로 사용하다가 Windows의 버전이 바뀌면 그 프로그램들이 호환성이 깨져서 동작하지 않게 되는데, 이 경우 사용자는 프로그램의 제작사가 아니라 마소를 비난하는 편이었다. 신제품을 팔아 먹으려고 일부러 프로그램의 동작을 막았네 뭐네 하는 음모론의 희생양이 되는 것이다. 마소에서도 이런 힐난에 이골이 났는지 더 방어적인 조치를 취하게 됐다.

그래도 이런 비공개 API들을 끝끝내 끄집어내서 사용하려면
(1) 로드 타임 차원: kernel32.dll의 비공개 API ordinal을 직결로 연결하는 import library를 직접 만들거나,
(2) 런 타임 차원: PE 파일 포맷을 분석해서 GetProcAddress 함수를 손으로 직접 구현하면 된다. 메모리에 로드된 kernel32.dll 내부의 export table을 수동으로 뒤지면 된다는 뜻이다.

L(로드), F(해제), G(함수 탐색) 함수의 ordinal은 1부터 시작하는 번호 기준으로 35~37이라고 한다. Windows 95부터 ME까지 변함이 없다. 어차피 더 바뀌어야 할 이유가 없는 번호이기도 하고.

이렇게 얻어 낸 HMODULE (WINAPI* pfnLoadLibrary16)(PCSTR)을 호출해서 "user.exe"를 로드한다.
그리고 GetProcAddress에다가 "GetFreeSystemResources"를 하면 드디어 우리가 원하는 함수 포인터를 얻을 수 있는데, 얘는 바로 호출 가능하지가 않다. kernel32에 존재하는 또 다른 비공개 API인 QT_Thunk를 거쳐서 함수를 호출해야 하는데, 이 함수는 또 기계어 차원에서 호출 방식이 반드시 일치해야 하기 때문에 대략 다음과 같은 인라인 어셈블리를 넣어야 한다.

_asm {
    push 0~2  ; 시스템, GDI, user. 얻고 싶은 리소스 타입
    mov edx, [pfnGetFreeSystemResources] ; 32비트 주소
    call QT_Thunk ; kernel32에 대해 "QT_Thunk"를 GetProcAddress 한 결과
    mov [ret_val], ax ; 함수의 실행 결과를 받을 16비트 WORD 변수
}

이렇게 하면 32비트 프로그램이 일단 16비트 API를 호출해서 리소스 값을 얻어 올 수 있다. (참고로 Windows NT 계열은 QT_Thunk 함수가 존재하지 않는다.)
그런데 내가 실험해 본 바로는.. 저거 사용하는 게 굉장히 까다롭다.
저 어셈블리 코드에 도달할 때까지 각종 DLL를 로드하고 여러 단계에 걸쳐서 여러 함수들의 포인터를 얻는 등 절차가 복잡한데, 클래스를 만들어서 중간 단계의 결과들을 저장해 놓거나 절차를 여러 단계의 함수로 분리하면.. asm 부분이 갑자기 동작하지 않게 된다.

비공개 API가 내부에서 썽킹을 수행하는 동안 프로그램의 스택이라든가 내부 상태를 이상하게 건드리는 것 같다. 컴파일러의 최적화 옵션의 영향을 받기도 하고.. 그렇지 않고서야 위의 저 간단한 어셈블리 코드가 딱히 뻑이 날 리가 없는데 말이다.

16비트 DLL을 따로 만들지 않고 편법을 동원해서 16비트 API를 호출하고 구체적으로는 리소스 퍼센티지를 얻는 방법을 알아 봤는데, 참 어렵긴 하다는 걸 느꼈다. 사실, 과거에 thunk 컴파일러가 하는 일 중 하나도 내부적으로 UT_Thunk를 호출하는 중간 계층 코드를 생성하는 것이었다. 더 들여다보니 말로만 듣던 ThunkConnect32 같은 함수도 쓰는 듯했다.

비공개라고 해서 무슨 ntdll 같은 하위 계층도 아니고 참 신기한 노릇이다. 어차피 Windows 9x는 kernel32가 최하위 계층이지 ntdll 같은 추가적인 하위 계층은 없으니 말이다.
Windows Programming Secret 책을 당시의 마소 Windows 95 팀의 엔지니어들이 직접 봤다면..
블리자드에서 스타크래프트를 직접 개발한 프로그래머들이 스탑 럴커처럼 자신조차 상상하지 못한 컨트롤과 테크닉을 구사하는 프로게이머를 보는 것과 비슷한 느낌을 받았지 싶다.

리소스를 되돌리는 함수 정도야 간단한 정수 하나만을 인자로 받고 역시 정수 하나를 되돌리는 아주 단순한 형태이다. 그러니 이런 테크닉을 구현하는 것에도 큰 무리가 없다. 구조체나 문자열의 포인터가 동원되기라도 했다면 메커니즘이 훨씬 더 복잡해지며, 그냥 정석적인 썽크 컴파일러를 쓰는 것밖에 답이 없지 싶다.
그러고 보니 문득 든 생각인데, 과거에 GWBASIC이 처음 구동되었을 때 Ok 프롬프트 앞에 "6만 몇천 바이트 남았습니다(6xxxx bytes free)"라고 메시지가 떴던 게 저런 리소스와 성격이 좀 비슷한 것 같이 느껴진다.

저런 식으로 프로그램이 시작된 직후, 혹은 프로그램의 도움말이나 About 대화상자 한 구석에다가 간단하게 남은 메모리/자원의 양을 표시하는 건 오랫동안 소프트웨어 업계에 남아 있던 관행이었다. 심지어 도스 시절부터 말이다.
그랬는데 요즘은 메모리가 너무 많아지고 숫자 단위가 커져서 그런지 Windows의 작업 관리자는 남은 메모리의 양을 KB 단위 대신 비율로 표시하기 시작했다. 옛날에는 64KB짜리 리소스는 스케일이 너무 작고 민망해서 퍼센트로 표시한 게 아닐까 의심될 지경이었는데 이제는 반대로 너무 커져서 세부적인 숫자가 무의미한 지경이 됐으니 다시 퍼센트로 복귀한 걸로 생각된다.

Posted by 사무엘

* 이 글의 내용은 클립보드 API, const 이야기의 연장선상에 있다. 관심 있으신 분은 예전에 썼던 글을 먼저 읽어 보시기 바란다.

1.
Windows API에는 GetPriorityClipboardFormat라는 함수가 있다. 이것은 클립보드로부터 '붙여넣기'(paste) 기능이 있는 프로그램이 사용할 만한 함수이다. 이 함수가 지목하는 포맷에 해당하는 클립보드 내용을 붙여넣으면 되며, 사실은 그보다도 먼저 이 함수의 실행 결과에 따라 '붙여넣기' 메뉴를 enable/disable시킬지를 결정하면 된다.

내 프로그램이 지원하는 클립보드 포맷이 단 하나밖에 없다면 IsClipboardFormatAvailable을 쓰면 된다. 그렇지 않고 여러 종류의 포맷을 지원하는데, 현재 클립보드에 존재하는 포맷 중에 우선순위가 가장 높은 놈은 무엇인지 알고 싶다면 말 그대로 저 priority라는 단어가 들어간 함수를 써서 요청을 해야 한다. 이것은 마치 커널 오브젝트의 동기화에서 쓰이는 WaitForSingleObject와 WaitForMultipleObjects 함수쌍의 관계와 일면 비슷하다.

그런데 내가 궁금한 점은 이 함수의 첫째 인자가 const UINT *가 아니라 왜 그냥 UINT *냐는 것이다.
첫째 인자는 함수로 전달하는 복수 개의 클립보드 포맷 리스트의 포인터이며, 속성이 엄연히 out이 아닌 in이라고 명시되어 있다. 저 함수 역시 인자로 받은 리스트 내용을 참조만 할 것이니, 포인터가 read-only가 아니라 일반 read-write 형태여야 할 하등의 이유가 없다. WaitForMultipleObjects만 해도 HANDLE의 배열 포인터는 분명히 const HANDLE *로 잡혀 있지 않던가?

저게 const라면,

static const table[] = { CF_UNICODETEXT, CF_HDROP }; //사람이 텍스트로 입력한 파일명 & 탐색기에서 복사해 놓은 파일명을 모두 받아들임
int res = GetPriorityClipboardFormat(table, ARRAYSIZE(table));

이런 식으로 간편하게 static const 배열을 함수에다 넘겨 줄 수 있을 텐데, const가 아니기 때문에 일이 좀 귀찮아진다. table에 const 속성을 제거하든지, 아니면 함수에다 넘겨 줄 때 const_cast 연산자를 써 줘야 한다. 내 경험상, 강제로 const 포인터로 고친다고 해서 딱히 프로그램 동작에 문제가 생긴다거나 하는 건 아니더라.

하지만 내 프로그램 내부에서 값을 고칠 일이 절대로 없기 때문에 const로 엄연히 봉인해 버리고 싶은 테이블을 봉인하지 못한다니, 썩 보기 좋아 보이지 않는다. 또한 const_cast 같은 연산자가 늘어나는 건 내 소스 코드에서 무질서도가 쓸데없이 증가하는 듯한 느낌을 준다.

물론, 동일한 유형의 데이터에 대해서 클립보드 포맷을 복수 개 지원한다는 건 대개가 custom 포맷과 표준 포맷을 혼용하는 경우이다. 리스트의 모든 원소가 상수가 아니며, 우선적으로 선택되었으면 하는 앞부분은 어차피 RegisterClipboardFormat의 리턴값인 경우가 많다. 워드 프로세서라면 모든 정보가 보관되어 있는 고유 포맷일 것이고, 텍스트 에디터라면 칼럼 블록을 명시한 고유 포맷이다.

그러니 저 함수의 인자로 전달되는 배열 포인터는 애초부터 const가 아니라 일반 배열일 가능성이 더 높다. 메시지만 해도, 시스템 차원에서의 유일성을 보장받기 위해 RegisterWindowMessage로 특수하게 등록한 메시지는 WM_USER+x와는 달리 가변적인 값이다. 그렇기 때문에 윈도우 프로시저에서 switch/case를 이용해 걸러낼 수가 없으며 if문을 써서 비교해야 하지 않던가. (이 두 Register* 함수는 프로토타입이 UINT Foo(PCTSTR name)로 완전히 동일하며, 명칭을 hash하여 숫자로 바꿔 준다는 공통점이 있어서 더욱 동질감이 느껴진다)

그런데.. 그런 식으로 치자면 WaitForMultipleObjects가 받아들이는 HANDLE도 NULL이나 INVALID_HANDLE_VALUE 같은 오류 상황 말고는 고정불변 상수값이 존재할 여지가 전혀 없는 타입이다. 값의 가변/불변성과는 무관하게 해당 함수가 값들을 읽기만 한다면 함수 인자가 응당 const 포인터로 잡혀 있어야 할 텐데, 클립보드의 저 함수는 왜 저렇게 설계되었으며 디자인에 문제를 제기하는 사람이 왜 없는지 궁금하다.

2.
서식이 없고 칼럼 블록도 없는 일반 텍스트 에디터에서 붙이기를 구현한다면 굳이 custom 포맷을 등록할 필요는 없을 것이고 애초에 복수 개의 클립보드 포맷을 살펴볼 필요도 없을 것이다. 단, 여기에도 원래는 유니코드/ANSI와 관련된 미묘한 문제가 있다. wide 문자 기반인 CF_UNICODETEXT와, ansi 문자 기반인 CF_TEXT가 따로 존재하기 때문이다.

Windows NT는 이들 사이에서 '유도리'를 제공한다.
응용 프로그램이 유니코드 텍스트 형태(CF_UNICODETEXT)로 클립보드에다 텍스트를 복사해 놓은 뒤, 나중에 유니코드를 지원하지 않는 프로그램이 클립보드로부터 CF_TEXT 포맷을 요청하는 경우 운영체제는 CF_TEXT도 있다고 답변을 하며, CF_UNICODETEXT로부터 CF_TEXT 데이터도 자동으로 만들어 준다. 그 반대도 물론 해 준다. (복사는 CF_TEXT로, 붙여넣기는 CF_UNICODETEXT로)

마치 Get/SetWindowText, WM_GET/SETTEXT에서 운영체제가 A/W 문자열 보정을 하듯이, 클립보드에 대해서도 그런 보정을 해 준다. 재미있지 않은가? 그러니 오늘날의 Windows에서는 유니코드를 지원하는 프로그램은 어떤 경우든 CF_UNICODETEXT만 생각하고 요걸로만 읽고 쓰면 유니코드를 지원하지 않는 구시대 프로그램과도 의사소통에 아무 문제가 없다.

하지만 문제가 되는 건 내부적으로 유니코드를 사용하는 프로그램이 Windows 9x까지 고려해서 만들어질 때이다. 9x 계열에서는 CF_UNICODETEXT는 응용 프로그램이 굳이 요청해서 자기들끼리 쓰지 않는 한, 운영체제 차원에서 공식적으로는 '없는 포맷', 지원하지 않는 유령/공기 포맷이다. 고로 NT 계열과 같은 타입 자동 변환이 없다.

텍스트 에디터가 자기는 내부적으로 유니코드 기반이라고 해서 자신이 native로 사용하는 CF_UNICODETEXT 형태로만 데이터를 복사해 놓으면, 기존 메모장 같은 프로그램에서는 텍스트 붙이기를 할 수 없게 된다.
그렇기 때문에 9x 계열과 유니코드라는 두 토끼를 모두 잡으려면 응용 프로그램은 클립보드로부터 데이터를 읽을 때도 IsClipboardFormatAvailable가 아니라 저 GetPriorityClipboardFormat를 써서 CF_UNICODETEXT와 CF_TEXT를 모두 살펴봐야 한다. 물론 1순위는 유니코드로 하고 말이다.

그리고 빈 클립보드에다 텍스트를 복사해 넣을 때에도 CF_UNICODETEXT부터 먼저 집어넣은 뒤, CF_TEXT 타입도 자동으로 생겨 있는지를 IsClipboardFormatAvailable로 체크하고, 없으면 ansi 텍스트도 수동으로 넣어 줘야 한다. Windows NT에서는 유니코드 텍스트만 집어넣어도 CF_TEXT로 붙여넣는 게 저절로 가능하지만 9x에서는 그렇지 않기 때문이다.

참 얼마 만에 클립보드 얘기를 또 꺼내게 됐는지 모르겠다. 지금이야 먼 과거의 유물이 됐다만, Windows 9x 시절에는 텍스트 하나를 유니코드 형태로 주고받을 때는 이렇게 미묘하게 귀찮은 면모가 좀 있었다.

클립보드에다 데이터를 지정하는 SetClipboardData는 GMEM_MOVEABLE을 지정해서 GlobalAlloc으로 평범하게 할당한 메모리 핸들을 넘겨 주는 방식으로 사용하면 된다. 함수를 호출한 뒤부터는 그 메모리 핸들은 운영체제의 관할로 넘어가기 때문에 우리가 임의로 해제해서는 안 된다.
이것과 굉장히 비슷한 개념으로 운용되는 다른 함수는 SetWindowRgn인 것 같다. 평범한 HRGN을 넘겨 주지만 이제부터 이 region은 운영체제의 관할이 되기 때문이다. 우리가 더 건드려서는 안 된다.

3.
C/C++은 여느 언어와 마찬가지로 const라는 속성이 존재하는데, 이것은 (1) 완전히 붙박이 상수가 될 수 있으며, 아니면 (2) 런타임 때 가변적인 초기값이 붙는 것도 가능하지만, 한번 값이 정해진 뒤에는 불변이라는 의미도 될 수 있다.
이거 혼동하기 쉬운 개념이다. C/C++의 const는 (1)은 딱히 보장하지 않고 일단은 (2)만 보장한다.

const형 변수를 초기화하는 초기값으로는 반드시 case 레이블이나 static 배열의 크기처럼 컴파일 타임 때 값이 결정되는 상수만 와야 하는 게 아니다. 변수도 얼마든지 초기값으로 지정할 수 있으며, 이건 그냥 const뿐만 아니라 static const에 대해서도 마찬가지이다. 애초에 const는 타입에 제약이 없으니까. (1)을 정수 명칭에 한해서 보장해 주는 건 enum, 아니면 템플릿 인자이다.

그래서 C#은 이 두 개념을 const와 readonly로 확실하게 구분해 놓았는데, 이건 상당히 매력적인 조치라 여겨진다. 배열· 테이블도 const로 지정이 가능하니까 말이다. 또한 붙박이 불변 const는 스택에든 어디든지 여러 인스턴스가 중복해서 존재할 이유가 하등 없으니 static 속성도 자동으로 포함하는 걸로 간주된다.

한편, 포인터가 const라면(가령 p) p 자신의 값을 바꿀 수 없는지, 아니면 p가 가리키는 메모리의 값을 바꿀 수 없는지(*p 혹은 p->)가 문제가 된다. const TYPE *p라고 하면 *p가 잠기고, TYPE * const p라고 하면 p가 잠긴다. const TYPE * const p라고 하면 짐작하시겠지만 둘 다 잠긴다.
문법이 좀 복잡한데, const T와 T const는 의미상 동일하다. 그리고 포인터값 자체를 잠글 때는 * 뒤에다가 const를 추가로 붙인다고 생각하면 비교적 직관적으로 이해할 수 있다.

하지만 포인터라는 게 지니는 값은 NULL 같은 특수한 경우가 아니고서야 언제나 가변적인 메모리 주소이기 때문에.. 포인터에다 const는 p 자신이 아닌 *p를 잠그는 용도로 훨씬 더 많이 쓰인다. 클래스 멤버 함수에 붙는 const도 this 포인터에 대해서 *this를 읽기 전용으로 잠그는 역할을 한다. this는 예약어이다 보니 this의 주소값 자체를 변경하는 건 어떤 경우든 원래부터 가능하지 않으니 말이다.

그리고 *p가 잠긴 const 포인터에 대해서 그 잠김을 일시적으로 해제하는 형변환 연산자는 잘 알다시피 const_cast이다. 다만, const가 사라진 TYPE *라는 타입명을 그 뒤의 <> 안에다가 수동으로 일일이 써 줘야 한다. 이름은 const_cast이지만 얘는 '쓰기 금지'뿐만 아니라 언어 차원에서의 타입과 "무관하게" 변수 접근 방식과 관련하여 붙어 있는 추가적인 제약 속성을 제거할 때에도 쓰인다. volatile이 대표적인 예이고, 비주얼 C++의 경우 IA64 아키텍처 기준으로 __unaligned 속성도 이걸로 제거할 수 있다. (IA64는 기본적으로 machine word 단위로 align이 된 곳만 메모리 접근이 가능한지라..)

Windows API에는 포인터의 const-ness 구분 때문에 불편한 게 몇 군데 있다. 대표적인 건 CreateProcess 함수.
실행할 프로세스를 가리키는 명령줄은 PCTSTR이 아니라 PTSTR이다. 함수가 내부적으로 실행될 때는 파일명과 인자명을 구분하기 위해서 문자열의 중간에 \0을 삽입해서 토큰화를 하기 때문이다. 즉, strtok 함수가 동작하는 것처럼 토큰화를 하며 문자열을 변경한다.

이 함수는 실행 후에 문자열 내용을 다시 원래대로 되돌려 놓긴 하지만, 명령줄 문자열을 나타내는 메모리는 일단 read-only가 아니라 쓰기가 가능한 놈이어야 한다. *a+=0; 을 수행하려면 비록 *a의 값이 실제로 변경되지는 않지만 그래도 가리키는 메모리가 변경 가능해야 하는 것과 비슷한 이치이다.
Windows NT 계열에서 CreateProcessA 함수를 호출하면 얘는 어차피 문자열을 쓰기 가능한 문자열에다가 유니코드로 변환해서 내부적으로 W 함수가 사용된다. 그렇기 때문에 A함수에다가 (PSTR)"notepad.exe sample.txt" 이런 식으로 줘도 안전하긴 하다. 그러나 범용성을 고려하면 이는 그렇게 깔끔한 코드라고 보기 어렵다.

다음으로 DrawText도 기능을 제공하는 형태가 조금 지저분하다.
얘는 문자열을 받아들여서 출력하는데 폭이 부족할 경우 문자열을 있는 그대로 출력하는 게 아니라 "Abc..."라고 줄여서 출력하는 옵션이 있다. 그런데 사용자가 원한다면 자기가 받은 문자열 자체를 그렇게 출력되는 형태로 '수정해' 주는 옵션이 있다(DT_MODIFYSTRING). 이 옵션을 사용한다면 str은 PCTSTR이라는 프로토타입과는 달리 쓰기 가능한 포인터여야 한다.
또한 RECT *인자도 좀 아쉬운 구석이 있다. 일단은 in/out 겸용이어서 RECT *이지만, 이것도 out 없이 문자열을 찍을 영역만 지정하는 in 전용이 가능했으면 좋겠다.

끝으로, 리스트/트리 같은 공용 컨트롤에 데이터를 추가하는 LVITEM이 있다. 이들 구조체의 pszText는 PCTSTR이 아니라 PTSTR이다. 문자열을 얻어 올 때와 지정할 때 모두 동일한 구조체가 쓰이기 때문에 const 속성이 없는 것이다.
이 때문에 컨트롤에다 데이터를 처음 추가할 때 item.pszText=const_cast<PSTR>("Hello") 같은 연산이 부득이 쓰이기도 한다.

C++과는 달리 자바에는 클래스 멤버 함수라든가, call-by-reference로 전달되는 데이터에 대해서 const-ness를 보증하는 개념이 없다. 클래스에서 Get*으로 시작하는 메소드라고 해서 const를 따로 지정하지는 않으며, final 키워드는 함수의 오버라이드 불가, 값의 변경 불가 같은 '종결자' 용도로만 쓰인다. 과연 const가 없어도 괜찮은 걸까?

그런데 포인터의 단계가 복잡해지다 보면, const가 있어 봤자 가리키는 놈이 const인지, 나 자신이 const인지 일일이 따지고 추적해서 내부 상태의 불변성을 보장하겠다는 시도가 별 의미가 없어지긴 한다. 즉, this가 this와 *this까지 몽땅 봉인되어서 나 자신의 멤버 값은 변경할 수 없지만.. 내가 가리키는 메모리 영역의 값을 한 단계 거칠 수가 있으며 거기 값을 변경하는 게 가능하다면.. 궁극적으로 그 개체의 속성/상태는 바뀌었다고 볼 수 있기 때문이다.

어떤 코드를 실행해 보지 않고 메모리 접근이 안전한지 입증하는 정적 분석 기능이 만들기 까다로운 것도 본질적으로 이런 이유 때문이다. 컴파일러의 경고가 동작을 예측하고 비정상을 지적해 줄 수 있는 것도 간단한 지역변수 수준일 뿐이지, 몇 단계짜리 포인터에 구조체가 줄줄이 따라오면.. 답이 없다.

거기에다 클래스의 인터페이스 상으로는 Set*이 아니라 Get*처럼 "read-only"이고 값이 변하지 않는 기능만 사용한다고 하더라도, 클래스의 내부 상태는 얼마든지 바뀔 수가 있다. 한번 구해 놓은 계산값을 다음에는 빠르게 되돌리기 위해서 그 값 자체 내지 중간 상태를 캐싱하는 것처럼 말이다. 이런 경우가 워낙 많으니 C++에서는 나중엔 멤버의 const-ness에 예외를 허용하는 mutable 키워드도 도입하지 않을 수 없었다.

이건 마치 고유명사와 보통명사의 경계와도 비슷한 맥락의 문제인 것 같다. 로마자 알파벳이 한글과는 달리 대문자가 있고 고유명사는 첫 글자를 대문자로 적게 돼 있어서 일면 편리한 건 사실이다. 하지만 좀 깊게 생각을 해 보면, 새로운 명칭이 만들어졌을 때 그걸 고유명사로 볼지 기준이 생각만치 엄밀하지는 않은 경우가 많다. 기준이 생각만치 엄밀하지 않으며 그냥 자의적이다. 번역하지 않고 음역하는 놈은 죄다 고유명사인 걸까? 실체가 지구상에 오로지 하나밖에 없는 놈? 그렇다면 실물이 존재하지 않는 무형의 개념은? 그걸 정하는 기준은 무엇?

지금 우리가 보통명사로 별 생각 없이 쓰는 명칭들도 그 명칭이 처음 등장했던 시절엔 첫 글자를 대문자로 적는 유니크한 고유명사이기도 했다. const 개념 구분도, 대소문자 구분도 있건 없건 어느 하나가 다른 하나보다 절대적으로 우월하고 좋은 솔루션은 아니어 보인다는 생각이 든다.

에휴, 클립보드부터 시작해서 유니코드, const 등 별별 이야기가 다 이어져 나왔다. 이상~~ ^^

Posted by 사무엘

C/C++에서 대괄호 [ ]는 일단 배열과 관련이 있는 문자이다.
타입을 선언하는 문맥에서 a[...]라고 하면 a가 배열임을 나타내고 선언한다. [] 안에는 배열의 크기를 나타내는 정수 상수(= 컴파일 타임 때 바로 값이 결정되는)만이 올 수 있다.
그 반면 값을 계산하는 문맥에서 a[...]는 일단은 배열이나 포인터를 역참조하는 *(a+...)와 동치가 되기 때문에, 상수가 아닌 임의의 변수값이 들어올 수 있다. 게다가 C++에서는 []를 연산자로서 오버로드도 할 수 있으므로 정수가 아닌 다른 타입의 값이 들어오는 게 가능하다.

그럼 속에 아무것도 없이 말 그대로 []만 달랑 오는 건 언제 가능할까?
일단 값을 계산하는 실행 문맥에서는 전혀 가능하지 않다. 함수 호출이 아닌 일반 수식에서 일반 괄호가 ()요렇게만 달랑 올 수가 없는 것과 같은 이치이다. 또한 인자가 전혀 없는 형태로 [] 연산자 함수를 오버로딩 하는 것도 안 된다.
얘가 쓰이는 가장 유용하고 편리하고 직관적인 상황은, 이니셜라이저로부터 크기를 자동으로 유추할 수 있는 배열을 선언하여 곧장 초기화할 때이다.

char pt[] = "Hello"; //null 문자까지 합해서 6이라는 크기가 자동으로 유추됨.
static const int samp[] = {1, 5, 7, 8}; //4라는 크기가 자동으로 유추됨.

이 정도야 []는 명백하게 배열을 나타내며, 그 의미를 충분히 납득할 수 있다. 헷갈릴 게 없다.
그리고 지역변수 말고 다른 번역 단위에 있는 배열을 요런 게 있다고 선언만 해 놓는 문맥일 때도 구체적인 크기가 생략된 arr[] 같은 구문이 올 수 있다. 이 경우 클래스로 치면 forward 선언과 얼추 비슷한 역할을 한다. 배열을 참조하는 코드를 생성할 수는 있지만 sizeof 연산자는 쓸 수 없게 된다. 온전한 배열은 아니지만 포인터도 아니기 때문에 여기에 다른 임의의 주소를 대입할 수는 없다.

그런데 []는 일부 제한된 문맥과 범위에서는 그냥 포인터를 나타낼 때도 있다. 이거 다시 보니 굉장히 요물스럽게 느껴진다.

void foo(char ptr[]);
void foo(char *p);

위와 아래의 함수 선언은 완전히 동치이다. 그렇기 때문에 저 두 쌍으로는 함수 오버로딩을 할 수 없다.
이게 요물스럽게 느껴지는 이유는, (1) 첫째, 함수의 인자에서만 사용 가능한 문법이기 때문이다.
일반 변수를 선언할 때야 char ptr[]은 포인터가 아니라 배열로 인식된다. 그렇기 때문에 이니셜라이저 없이 저렇게만 달랑 써 놓으면 크기를 알 수 없다고 컴파일 에러가 난다.
그에 반해 함수 인자에서는 배열을 선언하거나 초기화 따위 할 일이 없으니 ptr[]은 *p와 동일하게 인식된다.

우리는 프로그램으로부터 명령 인자를 받기 위해 main 함수로부터 argc, argv 인자를 살펴본다. 그런데 정말 이상한 건 argv는 거의 언제나 관행적으로 *argv[]라고 선언해 놓고 써 왔다는 것이다. 이건 알고 보면 **argv와 본질적으로 완전히 동치일 뿐인데도 말이다. 하지만 *argv[]와 **argv는 왠지 느낌상 서로 동일해 보이지가 않는다.

함수 인자와는 달리 리턴값은 char *bar()만 가능하지 char []bar 이렇게 쓸 수 없다. 함수 인자 말고는 리턴값이나 지역 변수 선언, 형변환 연산자, typedef 등 타입을 명시하는 그 어떤 문맥에서도 []를 저런 식으로 쓰는 건 문법적으로 가능하지 않다.

(2) 둘째, []는 그렇다고 해서 함수 인자이기만 하면 *와 완전히 등가 교환이 가능한 것도 아니다.
[]의 지원 범위는 오로지 1중 포인터 한정이다. 2중 포인터인 char **a를 a[][] 따위로 대체할 수는 없으며 오로지 한 단계만 *a[]로 대체할 수 있을 뿐이다. 한 단계 포인터를 대체할 수 있다는 점에서는 C++의 참조자 &를 살짝 닮은 것 같기도 하다.

그럼 함수 인자에서는 왜 저걸 예외적으로 가능하게 해 놓은 것일까?
정확한 이유는 알 수 없지만 C/C++은 배열은 함수 인자로 전달할 때 값이 새로 복제되는 게 아니라, 언제나 주소(= 포인터) 형태로만 전달한다는 점을 부각시키기 위해서 저렇게 한 게 아닌가 싶다. N차원 배열은 언제나 N-1차원 배열의 1중 포인터가 된단 얘기다. 다차원 배열을 선언해서 함수로 전달하는 상황을 생각해 보자.

int table[][2][4]={
    {{1,2,3,4}, {3,4,5,6}}, {{2,6,2,3}, {5,6,3,4}}, {{1,}, {2,}}
};

foo(table);

사실 C/C++은 엄밀히 말하면 다차원 배열이라는 것도 없고 그저 '배열의 배열'이 있을 뿐이다.
2*4 배열의 배열을 선언한다는 건 생략할 수 없고, 유일하게 생략할 수 있는 건 제일 겉에 있는 최종 원소의 개수(저기서는 3)이다.
이런 3차원 배열을 인자로 받는 함수는 프로토타입을 어떻게 만들면 좋을까?

void foo(int a[][2][4]);

table은 함수의 인자로 전달할 때는 그대로 2*4 배열의 포인터가 되고, 그걸 함수 인자로 표현하는 걸 배열 변수를 선언할 때와 동일하게 [][2][4]로 할 수가 있다. 함수 인자에서 []의 의미는 바로 여기에 있다고 보는 게 타당할 것이다. 함수 인자에서도 [] 안에 숫자를 생략할 수 있는 건 제일 겉의 차원수 하나뿐이다.

위의 함수의 인자는 개념적으로 아래와 완전히 동일하다. *(a+2)와 a[2]가 동일한 것만큼이나 서로 동일하다.

void Fune(int (*a)[2][4]);

a[][2][4]를 사용하지 않았으면 그냥 포인터나 다중 포인터가 아니라 '배열의 포인터'를 표현하기 위해 저렇게 괄호를 쳐야 했을 텐데 [] 표기는 괄호가 또 들어갈 필요를 없애 주고 표현을 간결하게 만들어 준다.
배열 선언 table[][2][4]에서는 []는 원소 개수가 이니셜라이저에 명시돼 있다는 뜻이고, 함수 인자 a[][2][4]에서는 이게 포인터라는 뜻이라니..;;

이건 무슨 최신 C++ 기능도 아니고 C의 완전 기초 필수 아이템인데도... 본인조차 []의 의미와 용도에 대해서 제대로 진지하게 생각을 안 했던 것 같다. 신기하기 그지없다.

Posted by 사무엘

Windows 프로그래밍의 관점에서 볼 때 대화상자는 참 독특하면서도 중요한 위상을 차지하는 GUI 구성요소이다.
대화상자에는 누구나 공통으로 갖추고 있어야 하는 동작과 처리가 있으면서 한편으로 각종 자식 컨트롤로부터 notification을 처리하는 건 대화상자마다 제각각 customize가 가능해야 한다.

그래서 대화상자 함수는 customization을 위해 사용자가 작성한 대화상자 메시지 처리 콜백 함수를 인자로 받는다. 그리고 WM_SETICON 같은 메시지를 통해 아이콘조차도 클래스 차원이 아니라 윈도우 메시지 차원에서 필요하다면 변경할 수 있게 해 놓았다.
그럼 custom 프로시저가 가로채지 않은 나머지 공통 처리들은.. 마치 DefWindowProc처럼 DefDlgProc 같은 대화상자 윈도우 프로시저를 호출하는 것만으로 전부 가능해야 할 것 같지만, 사실은 그렇지 않다. Alt+단축키 처리, 그리고 포커스 이동 시에 '확인' 같은 default 버튼의 비주얼을 바꾸기 같은 것은 대화상자 윈도우 자체가 메시지를 받는 게 아니라 각 child 컨트롤들이 키보드 메시지를 받고 있을 때 그걸 가로채서 해치워야 한다. 대화상자 윈도우가 무슨 훅킹이라도 하고 있지 않은 이상 말이다.

이런 이유로 인해 대화상자의 동작을 위해서는 message loop 차원에서 메시지를 가로채는 로직이 필요하다. 그래서 IsDialogMessage라는 함수가 그 코드에 들어가야 한다. 물론 DialogBox 함수로 modal 대화상자를 만들었을 때는 해당 함수가 자체적으로 message loop을 돌리면서 그 처리를 당연히 알아서 해 주니, 저런 별도의 함수는 우리 쪽에서 modeless 대화상자를 운용할 때에나 필요하다.

사실 저 함수는 용도를 생각하면 Is..가 아니라 TranslateDialogMessage 정도로 작명이 됐어야 했다. 그래야 오해가 없다. 단순히 쿼리에 대한 판별값을 되돌리는 게 아니라 실제로 무슨 일을 수행하기 때문이다.

뭐, message loop은 그렇다 치고, 대화상자를 대상으로 생성된 메시지는 우리가 지정한 대화상자 프로시저 → 대화상자 자체의 윈도우 프로시저(DefDlgProc) → 운영체제가 제공하는 DefWindowProc 이런 순으로 메시지를 처리하게 된다. 앞 계층에서 처리하지 않은 메시지가 다음 계층으로 간다는 뜻이다.
C++이라면 이건 깔끔한 클래스의 상속 관계로 표현할 수 있을 것이다. 그러나 Windows가 처음 개발됐을 때는 C++이 쓰이지 않았었다. 그리고 결정적으로, 모종의 이유로 인해 대화상자 프로시저와 윈도우 프로시저는 형태가 미묘하게 서로 달라져서 온전한 일관성이 보장되지 않는다.

오리지널 윈도우 프로시저는 내가 메시지의 처리를 한다면 리턴값을 바로 되돌리면 되고, 내가 처리하지 않은 메시지에 대해서는 DefWindowProc()를 해 주면 된다.

return ret; //처리한 경우
return DefWindowProc(hWnd, msg, wParam, lParam); //처리하지 않은 경우

그러나 대화상자 프로시저는 자기가 이미 DefDlgProc라는 디폴트 처리 함수(= 대화상자의 원래 윈도우 프로시저)로부터 호출을 받은 구도이다. 이것이 디자인 상으로 가장 본질적인 차이점이다.
그래서 리턴값으로는 이 메시지를 우리가 처리했는지의 여부만을 BOOL 형태로 되돌리고, 메시지 리턴값은 따로 꽤 번거롭게 넣어야 한다.

SetWindowLongPtr(hDlg, DWLP_MSGRESULT, ret); return TRUE; //처리한 경우
return FALSE; //처리하지 않은 경우

저럴 거면 차라리 함수의 인자에다가 LRESULT *pnResult 같은 포인터를 추가해서 거기로 되돌릴 수 있게라도 하지 하는 아쉬움이 남는다.

*pnResult=ret; return TRUE; //처리한 경우 -- 대안 1
*pbEaten=TRUE; return ret; //처리한 경우 -- 대안 2

그런데, 대화상자 프로시저에도... 형태가 간단한 극소수의 예외적인 메시지는 리턴값을 SetWindowLongPtr이 아니라 일반 윈도우 프로시저처럼 자신의 리턴값으로 되돌린다. 그렇기 때문에 대화상자 프로시저는 대부분의 경우 TRUE/FALSE만을 되돌림에도 불구하고 리턴값이 쿨하게 BOOL이 아니라 INT_PTR로 지정되어 있다. LRESULT도 아니고 이거 참.. 지저분하다면 지저분하다.

그 예외로는 자식 컨트롤의 배경을 칠할 브러시를 되돌리는 WM_CTL*, owner-draw 컨트롤에서 아이템 간의 대소를 비교하는 WM_COMPAREITEM, 그리고 역시 owner-draw 컨트롤에서 아이템의 바로가기 key를 지정하는 WM_(CHAR/VKEY)TOITEM이 여기에 해당한다. COM 함수라고 해도 실패를 할 우려가 전혀 없고 리턴값도 BOOL 값 달랑 하나 같은 건 굳이 BOOL *pfResult라는 인자로 주기보다는 간단히 S_OK, S_FALSE라는 자기 리턴값으로 되돌리는 게 더 나은 것과 같은 이치이다.

그리고 저 예외 메시지들은 owner-draw처럼 애초에 custom 동작을 염두에 두고 만들어진 메시지이므로 default로 넘기느냐 마느냐를 따지는 게 전혀 무의미하다. 그러니 리턴값을 바로 직통으로 사용하는 것이 더 간편하고 낫다. WM_CTL*의 경우도 컨트롤을 서브클래싱할 때에나 쓰이니 이 역시 customization과 관계가 있다.

왜 저렇게 예외가 만들어졌는지 이제 이해는 되지만, 그래도 대화상자 프로시저의 인터페이스가 구리고 지저분하고 복잡해 보이는 건 어쩔 수 없는 사실이다. 그래서 대화상자 프로시저도 윈도우 프로시저와 비슷한 구조로 만들 수 있게 하는 일종의 코딩 디자인 템플릿이 있다. MFC 같은 C++ 프레임워크는 밑바닥에서 당연히 이런 일도 다 해 주고 있지만, C만 쓴다거나 MFC보다 더 가벼운 Windows API 프레임워크를 우리가 직접 만드는 상황이라면 그 내부 디테일을 알 필요가 있다.

기본적인 아이디어는 이렇다.
운영체제의 DefDlgProc는 우리 프로시저를 먼저 호출하여 메시지의 처리 여부를 묻는다. 우리 프로시저는 그 메시지를 처리한 경우라면 리턴값 + TRUE만 되돌리면 되니 끝이다. 그 반면 처리하지 않은 경우, 내부적인 재귀호출 플래그를 설정한 뒤 DefDlgProc을 또 호출한다.
그럼 DefDlgProc는 아까처럼 우리를 또 호출하는데, 이때 우리 프로시저는 이미 설정된 재귀호출 플래그를 보고는 비로소 더 처리를 하지 않는 FALSE를 되돌린다.

또한, 리턴값을 지정할 때 메시지 종류에 따라 곧이곧대로 리턴(일부 예외 메시지들)하거나 SetWindowLongPtr을 호출하는 것은 메시지 핸들러 말고 그 아래의 static 콜백 함수에서 하면 된다.
이 아이디어를 의사코드로 표현하면 다음과 같다.

class CMyDialog {
    static INT_PTR CALLBACK DialogProc(HWND hDlg, UINT msg, WPARAM wParam, LPARAM lParam);
    BOOL m_bRecur;
protected:
    virtual LRESULT DlgProc(UINT msg, WPARAM wParam, LPARAM lParam);
public:
    CMyDialog(): m_bRecur(FALSE) { }
};

//클래스에서는 아마 private로 지정되어 있을 우리 대화상자 프로시저 callback.
INT_PTR CALLBACK CMyDialog::DialogProc(HWND hDlg, UINT msg, WPARAM wParam, LPARAM lParam)
{
    //HWND로부터 C++ 오브젝트 얻기. 훅킹을 해서 WM_NCCREATE를 잡든가 아니면 WM_INITDIALOG일 때
    //hDlg와 C++ 오브젝트를 연결하는 작업을 할 것. 이 코드에서는 그걸 생략함
    CMyDialog *obj = GetObject(hDlg);

    //BOOL값. 저 값이 true이면 재귀 상태라는 뜻이므로 그걸 false로 바꾸고, 함수도 false로 종료.
    CheckDefDlgRecursion(&obj->m_bRecur);
    //msg가 예외에 속하면 리턴값을 바로 되돌리고, 아니면 SetWindowLongPtr로 리턴값을 지정해 줌.
    return SetDlgMsgResult(hdlg, msg, obj->DlgProc(msg, wParam, lParam));
}

//각 클래스별로 오버라이드 하면 되는 가상 함수.
//윈도우 핸들은 우리 C++ 클래스의 멤버에 포함되어 있다고 가정함.
LRESULT CMyDialog::DlgProc(UINT msg, WPARAM wParam, LPARAM lParam)
{
    //재귀호출 플래그를 켠 뒤에 DefDlgProc를 호출한다.
    return DefDlgProcEx(m_hWnd, msg, wParam, lParam);
}

windowsx.h를 보면 SetDlgMsgResult, DefDlgProcEx, CheckDefDlgRecursion 같은 매크로 함수가 이런 디자인 패턴을 구현하라고 만들어진 물건들이다. 16비트 시절부터 있었고 MFC만큼이나 역사와 내력이 대단히 길다.

<날개셋> 한글 입력기는 지난 3.0때부터 GUI가 그냥 Windows API와 자체 제작 프레임워크를 사용해서 만들어졌지만, 그땐 본인은 이런 기법을 미처 생각하지 못했었다. 그래서 대화상자 프로시저들은 대충 return 1에 SetWindowLongPtr 등을 뒤죽박죽 섞어서 만들어져 있다. 그러나 저런 방법을 진작에 알았으면 대화상자 메시지 처리기도 마치 윈도우 프로시저 스타일로 일관성 있게 만들 수 있었겠다. 이제 와서 수많은 대화상자 프로시저들을 저 기준대로 고치는 것은 무의미한 지경이 됐지만 말이다.

Posted by 사무엘

컴퓨터 소프트웨어에서 뭔가 기능은 동일하지만 프로토콜(입출력)이 다른 두 시스템을 최상위 계층에서 중재하여 서로 이어 주는 메커니즘을 '썽킹(thunking)'이라는 용어로 표현하는 것 같다. 영한사전에 제대로 등재돼 있지도 않은 신조어인데 정확한 어원이 궁금하다. 영문 위키백과는 a subroutine that is created, often automatically, to assist a call to another subroutine라고 풀이를 하며, 그래서

• Windows 9x에서 유니코드(W) API 호출 요청이 왔을 때, 매개변수 값을 적당히 조절해서 그에 상응하는 Ansi API를 대신 호출하고 출력 결과도 wide string 기준으로 보정하는 것
• C++의 멤버 함수 포인터에서 다중 상속된 클래스의 멤버 함수를 호출하기 전에 this 포인터의 오프셋을 보정해 주는 전처리 함수 (보정 정보가 포인터의 내부에 있지 않고 그냥 또 다른 함수를 생성해서 때우는 경우)

이런 것들도 다 넓게는 썽크/썽킹이라고 부른다. 그리고 썽킹을 수행하는 함수를 썽크 함수라고 한다. 다만 Windows에서 썽킹은 컴퓨터 아키텍처의 장벽을 극복하는 호환성 유지 작업을 가리킬 때 주로 쓰인다. 16비트와 32비트 사이, 그리고 요즘은 32비트와 64비트 사이에서 말이다.
그래서 그런 썽킹 시스템을 WoW라고 부른다. 월드 오브 워크래프트...가 아니라 Windows on Windows의 약자로, 말 그대로 Windows 위에서 Windows를 또 가상으로 구동한다는 뜻이다.

오늘날 우리가 사용하고 있는 x86-64 아키텍처는 과거 32비트 IA32의 superset 구도로 설계되었다. 그래서 32비트 x86 코드도 에뮬레이션이 아니라 네이티브 직통으로 실행 가능하기 때문에 Windows 입장에서는 소프트웨어적으로 32비트와 64비트를 모두 지원하기 위해 특별히 힘든 일을 해 줘야 할 건 없다. 64비트 시대에도 어마어마한 32비트 유물들은 비록 바이너리 형태가 아무리 지저분하더라도 결코 외면할 수 없는 물건임이 입증된 셈이다. 비록 성능을 추구했다고는 하지만 x86 코드를 거북이처럼 에뮬레이션으로 돌리고 다른 문제점도 많았던 IA64는 정말 시원하게 망해서 인텔의 흑역사가 됐다.;;

32비트와 64비트는 한 주소 공간 안에서 코드가 섞이는 게 전혀 불가능하며, 서로 교류하는 방법은 API나 커널 오브젝트 차원에서의 IPC 메커니즘밖에 선택의 여지가 없다. 특히 WM_COPYDATA 메시지는 16, 32, 64비트까지 세대를 넘어 두루 통용되는 대단히 훌륭한 해결사이다.
그러나 16비트와 32비트가 공존하던 시절에는 상황이 훨씬 더 지저분했다. 기존 소프트웨어와의 호환성, 그리고 부족한 PC 메모리 같은 현실적인 한계 때문이었다.

그 시절에는 기술적으로 다음과 같은 형용사가 붙은 썽킹들이 존재했다. 썽킹이 무슨 CPU 에뮬레이션까지 하는 건 물론 아니고, 주로 한 일은 최신 32비트 가상 메모리 주소와 구닥다리 16비트의 세그먼트-오프셋 주소를 그냥 상호 변환하는 것이었다.

1. Universal: 16비트 플랫폼에서 16비트 EXE가 32비트 DLL을 실행
이건 가장 원초적인 썽킹이며, 쉽게 말해 Win32s의 기술 수준이 여기에 해당한다.

2. Generic: 32비트 플랫폼에서 16비트 EXE가 32비트 DLL을 실행
이것은 32비트 Windows 9x/NT 계열이 모두 지원하는 썽크로, 방향이 universal과는 반대이다.
본인은 IME 개발자로서 이 썽킹의 존재를 자연스럽게 인지하고 있었다. 16비트 프로그램에서도 <날개셋> 한글 입력기 외부 모듈이 동작했기 때문이다. 물론 곧 오류가 나고 제대로 사용하기는 어렵지만.

Windows 9x의 경우, 16비트 프로세스 내부에서 돌아가는 32비트 코드는 마치 Win32s처럼 극도로 가난한 16비트 컴퓨터의 끔찍한 제약들이 고스란히 적용되었다. 스레드를 생성할 수 없으며 스택 크기도 기본 1MB 이상이 아니라 64KB 미만으로 팍 줄었다. 그러니 복잡한 재귀호출이나 큰 배열조차도 함부로 만들면 안 됐다.

Windows NT는 모든 운영체제의 코드가 32비트 이상이다. 하지만 그렇다고 해서 16비트 코드를 실행하는 기능 자체가 아예 없는 건 아니었으니 16비트 프로그램이 32비트 코드를 사용하기 위한 최소한의 썽킹 계층은 마련하고 있다.

16비트 EXE 안에서 동작하는 32비트 dll이 GetModuleFileName(NULL)을 해 보면 9x 계열의 경우, 16비트 EXE 이름이 아니라 그냥 kernel32.dll이 돌아온다. 그러나 NT 계열은 ntvdm.exe가 돌아온다. 16비트 코드는 아예 샌드박스 안에서 고립된 채 돌아가고, 얘와 연계하여 동작하는 32비트 DLL은 여전히 32비트 문맥이 완전히 보장된다.

3. Flat: 32비트 플랫폼에서 32비트 EXE가 16비트 DLL을 실행
이것은 Windows 9x에만 존재한다. 20여 년 전에 Windows 95가 나오고 제품의 32비트 에디션을 출시하긴 해야 하는데 방대한 16비트 기반 DLL 엔진 같은 걸 차마 다 32비트로 포팅할 시간이 없을 때, 차선책으로 쓰라고 도입된 솔루션이다.

Universal은 그냥 32비트로 빌드만 하면 혜택을 입을 수 있고 Generic도 해당 16비트 EXE에서 LoadLibrary32Ex32W나 CallProc32W 같은 썽킹 API만 새로 사용하면 썽킹이 가능한 반면, Flat 썽킹을 활용하려면 thunk 컴파일러를 이용해서 상호 교신하고자 하는 32/16비트 바이너리들에 썽크 중재용 DLL을 추가로 넣어 줘야 한다.

1~3은 성격과 용도가 제각각 다르다는 걸 알 수 있다.
과거에 아래아한글이 최초의 Windows 버전인 3.0이 개발되었을 때, 시행착오로 인해 universal 썽크만 생각했지 flat 썽크를 고려하지는 못한 듯하다. 그래서 내가 듣기로는 Windows 3.1 + win32s에서는 실행되었는데 정작, 곧 출시된 Windows 95에서는 어처구니없게도 동작하지 않았다고 한다. (NT는 모르겠음)

아래아한글이 100% 완벽하게 32비트로만 개발됐으면 이런 일이 없었을 텐데 아마 내부적으로 호환성 때문에 16비트 코드가 일부 존재했던 모양이다. 그리고 내가 들은 이런 소문들이 사실이라면, Universal 썽크는 Win32s + 32비트 EXE에서 도로 16비트 DLL을 로딩하는 것도 지원하긴 했나 보다. Windows 95에서 추가로 해야 하는 썽킹이 없이도 뭔가 되는 일이 있었으니까 말이다.
어쨌든 이 때문에 Windows 95가 발매된 1995년 말엔 그 문제를 해결한 3.0b가 신속하게 나와야 했다. 소문에 따르면 3.0a도 있었는데 이건 3.0 원판보다도 존재감이 "더" 없는 것 같다.

이런 썽킹은 커널 레벨에서 발생하기 때문에 뭔가 정보를 잘못 줘서 에러가 나더라도 애플리케이션 레벨에서는 디버깅조차 할 수 없다. 더 깊게 들어가지 않은 채로 그냥 에러가 난다는 뜻이다. 이런 건 커널 레벨 디버거를 써서 살펴봐야 한댄다.
비록 제대로 안 돌아가는 제품을 돈 주고 사서 쓰다 고생한 사용자들에게서 욕도 많이 먹었겠지만, 그래도 그 열악한 환경에서 그 방대한 도스용 프로그램을 그 제한된 시간과 예산 하에서 Windows용으로 뚝딱 포팅을 한 건 대단한 일이긴 해 보인다.

Windows 9x 시절에 썽킹과 관련된 대표적인 테크닉 중 하나는 32비트 프로그램이 지금 시스템에 남은 리소스 퍼센티지를 얻어 오는 것이었다. 그 값을 얻으려면 32비트 프로그램이 32비트 user32.dll이 아니라 16비트 user.exe의 함수를 호출해야 했기 때문에 일종의 flat 썽킹이 필요했다.

물론 운영체제가 제공하는 rsrc32.dll이 제공하는 함수를 호출하는 방법도 있지만(얘는 rsrc16.dll로 내려가고), 걔네들이 하는 일을 별도의 dll 없이 직통으로 수행하는 꼼수가 있는데.. 이건 분량이 길어지는 관계로 나중에 다시 다루도록 하겠다.
자, 그럼 썽킹과 관련된 다른 얘기도 슬슬 좀 꺼내 보겠다.

본인은 에디트, 리스트 같은 기성 컨트롤들에 보이는 명령 메시지들의 값이 16비트 시절과 32비트 이후 시절이 서로 다르다는 것을 비교적 최근에 알고서 놀랐다.
과거에는 LB_ADDSTRING, EM_SETSEL 같은 메시지들이 WM_USER 이후 영역에 있었다. 그러나 32비트에서는 이것들이 WM_USER 이내의 시스템 메시지 영역으로 옮겨졌다. 아마 대화상자 내부에서 다른 사용자 메시지들과의 충돌을 막으려는 의도도 있고, 또 얘는 WM_GET/SETTEXT처럼 프로세스 간에 문자열을 주고받을 때 운영체제가 자동으로 메모리 보정을 해 준다는 의미에서 시스템 메시지로 승격된 게 아닌가 싶다.

대화상자에서 어떤 컨트롤이 WM_GETDLGCODE 메시지에 대해 DLGC_HASSETSEL를 되돌리면 걔는 포커스를 받았을 때 텍스트 전체를 선택하라는 EM_SETSEL 메시지를 받는다. 자신이 에디트 컨트롤을 자체 구현하고 있다면 이 메시지를 저렇게 처리하면 된다.
그런데 Windows 9x에서는 저 메시지가 안 오고 WM_USER+1에 속하는 정체불명의 괴메시지가 오곤 했다. 알고 보니 저건 16비트 시절의 EM_SETSEL과 같은 값이었다.

이런 레거시들 사연들은 모를 때보다 알 때가 프로그래밍에 훨씬 더 도움이 된다. 물론 그렇다고 해도 32비트 프로그램에다가도 Windows 9x는 왜 16비트 기준의 메시지를 보내는지는 알 수 없는 일이다. Windows의 썽킹 계층은 메모리 주소/포인터 변환뿐만 아니라 GUI에서는 이런 메시지의 변환까지도 도맡아 했다고 한다.

지금은 공용 컨트롤들의 메시지가 WM_USER 밖의 영역에 있다. 얘들은 애초부터 프로세스간의 메모리 보호가 잘 되는 32비트 운영체제와 함께 등장하기도 했고 또 알다시피 복잡한 플래그들이 들어간 복잡한 구조체를 주고받다 보니, 운영체제가 inter-process간에도 메모리 보정을 해 주지 않는다.
다른 프로세스에 있는 리스트/트리 컨트롤에다가 데이터를 등록하려면 얄짤없이 훅 프로시저를 써서 그 프로세스의 문맥 안에서 해당 컨트롤을 조작해야 한다. 사실, 남의 프로세스의 GUI 컨트롤을 조작하는 변태적인 작업이 왜 필요한지는 모르겠지만 말이다.

잘 알다시피 16비트 시절엔 DLL 전역변수들이 한데 공유됐으며, 제2, 제3 EXE들이 연결됐을 때 PROCESS_ATTACH 통지가 없었다고 한다. 그러니 DLL 함수는 exe들이 자기 DLL의 context를 매번 함수 인자로 전해 줘야 했겠다. 초기화/해제도 당연히 수동으로 직접 해야 했으나.. crash가 발생해서 해제를 제대로 못 하고 레퍼런스 카운트가 꼬이면 그건 그대로 시스템 자원 누수로 이어졌다.

요즘은 레퍼런스 카운트 관리가 엉망이더라도 프로세스가 종료되면 그 프로세스가 갖고 있던 자원은 100% 회수되는 게 보장된다. 그리고 요즘은 실행이 강제 종료 당한 스레드에서 스택 메모리가 자동 회수되지 않는 것 정도만이 그나마 in-process leak인 반면, 그 시절엔 툭하면 시스템 차원에서의 자원 누수와 고갈을 아주 쉽게 야기할 수 있었다. Windows 9x는 도스와 시스템 영역 메모리가 보호되지 않는 것 정도 때문에만 불안정했지만 3.1은 이보다 훨씬 더 막장이었다.

컴퓨터 환경을 더 좋게 만들기 위한 노력은 단순히 물리적으로 회로 집적도를 높이는 것만으로 되는 게 아니며 그 자원을 효율적으로 활용할 수 있게 소프트웨어적으로도 머리를 엄청 많이 써야 했다는 걸 알 수 있다.

Posted by 사무엘