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

<날개셋> 한글 입력기는 잘 알다시피 16년 전에 개발된 1.0과 지금의 8.6이 요구하는 운영체제 사양(그리고 사실상 하드웨어 사양도)에 차이가 전혀 없는 좀 사기급의 프로그램이다. 32비트 에디션은 Windows 95/NT4 이상에서도 돌아간다. Win95쯤은 안드로이드 스마트폰 내부에서 가상 머신으로도 돌리는 지경이 됐는데도 말이다. 뭐, 내 프로그램은 게임처럼 딱히 최신 사양빨을 타는 분야의 프로그램이 아니며, 한글이 무슨 한자처럼 처리하는 데 메모리가 엄청 많이 든다거나 아랍· 태국 문자처럼 내부 메커니즘이 복잡한 것도 아니기 때문이다.

Windows는 API 함수들이 유니코드를 표방하는 2바이트 문자열을 취급하는 버전(W 함수)과 비유니코드 일명 'ANSI 인코딩'을 표방하는 1바이트 문자열을 취급하는 버전(A 함수)으로 나뉘어 있다. 맥이나 리눅스 같은 타 운영체제에서는 찾을 수 없는 독특한 형태이다. 물론 문자 집합이라는 건 굳이 인코딩 단위에 얽매여 있지는 않으니, 1바이트라는 단위는 그대로 놔 두고 UTF-8만 사용해도 유니코드 지원은 가능했다. 하지만 Windows는 호환성 때문인지 문자 집합과 함께 인코딩까지 완전히 바꿔 버리는 방식을 채택했다. 그래서 wchar_t도 4가 아닌 2바이트이며, UTF-16을 유난히 좋아한다.

Windows NT는 W가 기본이고 A도 호환성 차원에서 지원하지만 Windows 9x는 메모리 부족 문제로 인해 A만 지원하고 W는 아예 제공하지 않았다. 그러니 일반적으로는 Windows 9x를 지원하려다 보면 유니코드를 지원할 수 없어서 깨진 문자 크리 때문에 프로그램의 국제화에 애로사항이 꽃폈으며, 반대로 W 함수만 사용하면 가정에 NT 계열보다 더 많이 보급돼 있던 9x 계열 운영체제를 지원할 수 없었다.

이 딜레마를 해소하는 방법은 일단 프로그램은 W 함수 기반으로 개발한 뒤, 9x에서는 특별히 W 함수 진입로에서 함수 argument를 변환하고 나서 A 함수를 호출하는 일종의 훅/thunk DLL을 구동하는 것이었다. <날개셋> 한글 입력기는 이 테크닉을 사용한다.
훅 DLL의 소스 코드는 동작 방식의 특성상, import table상의 함수 이름 문자열과 거기에 대응하는 훅킹 함수 포인터를 명시한 테이블을 갖고 있다. 또한 기존 Windows API 함수와 프로토타입이 동일하지만, 하는 일에는 살짝 차이가 있는 함수도 즐겨 사용한다.
이런 걸 구현할 때는 C/C++ 언어에 존재하는 다음과 같은 기능들이 유용하게 쓰였다.

1.
함수 훅킹 테이블을 만들 때 #define과 더불어 #(문자열화)와 ##(토큰 연결)라는 전처리기 연산자를 즐겨 썼다.
_FUNC(SetWindowTextW) 하나로 { "SetWindowTextW", (FARPROC)My_SetWindowTextW } 요걸 표현할 수 있으니 전처리기 연산자를 써서 매크로를 정의하는 게 완전 딱이지 않은가?
C언어는 전처리기의 단항 연산자는 # 1개로, 이항 연산자는 # 2개로 표현해서 나름 직관성을 추구했다. 그리고 안 그래도 전처리기 연산자는 C/C++의 고유한 연산자와는 섞여서는 안 되는데 굳이 # 말고 다른 기호를 끌어다 쓰지 않아서 형태 구분이 잘 되게 했다.

그런데 여기서 문제가 하나 있다.
문자열화 연산자는 매크로 전개를 한 놈을 문자열로 바꾸는지, 아니면 언제나 주어진 인자를 문자 그대로 문자열로 바꾸는지를 본인은 엄밀하게 생각을 하지 않고 지냈다. #define ToString(a) #a라고 정의해 주면, ToString(SetWindowText)은 "SetWindowText"로 바뀌는지, 혹은 "SetWindowTextW"나 "SetWindowTextA"로 바뀌는지 궁금했다.

이에 대한 정답을 먼저 말하자면, # 연산자는 그 자체로는 매크로 전개를 전혀 하지 않는다. 그렇기 때문에 저 문제의 정답은 "SetWindowText"이다.
만약 W/A가 붙은 놈을 얻고 싶으면 매크로를 한 단계 더 거쳐 줘야 한다. #define ToString_Expanded(a) ToString(a)를 선언한 뒤, ToString_Expanded(SetWindowText)라고 명령을 내리면 그제서야 "SetWindowTextW"(또는 A)가 얻어진다.

물론 딱히 매크로가 없는 인자를 넘기면 ToString_Expanded는 그냥 ToString과 동일한 결과가 나온다. 이런 차이가 있다는 걸 근래에 알게 됐다.

C/C++ 코드에는 검증과 디버깅을 위해 assert 부류의 매크로를 볼 수 있는데, C 언어 표준 매크로 상수와 연산자들은 상당수가 얘를 구현하기 위해 만들어진 게 아닐까 싶을 정도이다.
상식적으로 생각해 봐도, 실행 파일 내부에 "result > 0이라는 수식의 assertion이 실패했습니다. 아무개.cpp n째 줄입니다." 정도의 검증 명령이 삽입되려면 딱 봐도 __FILE__, __LINE__이 들어가야 했을 것이고 검증 대상 수식은 # 연산자에 의해 문자열로 바뀌었을 거라는 걸 알 수 있다.

파일명과 줄번호는 바이너리 형태의 디버그 심벌에도 포함되긴 하지만, result > 0처럼 대놓고 코드를 구성하는 문자열은 # 연산자 없이는 답이 없다. 이런 사기급의 전처리 기능은 C/C++ 외의 다른 언어에서는 유례를 거의 찾을 수 없지 싶다.

2.
또한 decltype이라는 연산자가 있는 줄을 난생 처음 알았다. 연산자이긴 하지만 되돌리는 게 어떤 값이 아니라 타입 그 자체이다. typeid처럼 RTTI와 관계 있는 기능도 아니며, 컴파일 타임 때 결정되는 고정 타입이다. 그래서

auto x=3.4f;
decltype(3.4f) x = 3.4f;
float x=3.4f;

는 의미가 모두 동일하다. auto와도 어떤 관계인지 바로 알 수 있을 것이다.
sizeof는 값 또는 타입을 모두 받아들여서 값(크기. 고정된 정수)을 되돌리는 반면, decltype은 값을 받아서 타입을 되돌린다는 차이가 있다. 또한 sizeof와 decltype 모두 그 값을 실제로 실행(evaluate)하지는 않는다.

auto는 타입과 동시에 변수값 초기화를 할 때 번거로운 타이핑을 줄여 준다. decltype은 값을 동반하지 않고 타입 자체만을 명시할 때 매우 유용하다. 템플릿 인자를 명시하거나 형변환을 할 때, 길고 복잡한 namespace나 함수 포인터의 프로토타입을 쓰는 수고를 덜어 준다. typedef를 하자니 번거로운 이름을 떠올려야 하는데.. 그럴 필요도 없어진다. 가령,

CAPIPtr<int (*)(int flags, WPARAM wParam)> pfnAbout(hNgsLib, "ngsAbout");

라고 쓸 것을

CAPIPtr<decltype(&::ngsAbout)> pfnAbout(hNgsLib, "ngsAbout");

로 간편하게 대체 가능하다. 함수의 이름만으로 그 함수의 포인터의 프로토타입을 간단히 명시할 수 있으니 얼마나 편리한가? API 훅킹 라이브러리를 만들 때도 이런 문법이 매우 유용할 수밖에 없다. 훅킹 대상인 Wndows API들이야 헤더 파일에 프로토타입이 다 선언돼 있으므로 그걸 decltype의 피연산자로 주면 되기 때문이다..

또한, 과거에는 클래스에서 함수 포인터 형변환 연산자 함수를 선언할 때는 C++ 문법의 한계 때문에 반드시 그 함수 프로토타입을 typedef부터 해야 했다. 하지만 decltype은 여기서도 그런 번거로움을 응당 없애 준다. 아래 코드를 보면 차이를 알 수 있다.

class CMyTable {
    static int _Func();
public:
    //과거
    typedef int (*PFN)();
    operator PFN() { return _Func; }

    //현재
    operator decltype(&CMyTable::_Func)() { return _Func; }
};

decltype 연산자는 Visual C++ 2010부터 지원됐다. 함수 포인터에다가 람다를 바로 대입하는 건 2010은 아니고 2012부터 지원되기 시작했다. 물론 캡처가 없는 람다에 한해서. 람다는 함수 포인터보다 더 추상적인 놈이기 때문에 calling convention은 컴파일러가 알아서 다 해결해 준다.

C++은 잘 알다시피 A *B와 A B(), (A)+B 같은 문장이 A와 B의 정체가 무엇인지에 따라(타입? 값?) 파싱 방식이 완전히 달라진다. 템플릿이 추가된 뒤부터는 <와 >조차도 이항 연산자 vs 타입 명시용의 여닫는 괄호처럼 해석이 달라질 수 있게 되었고, 21세기에 와서는 템플릿 인자를 이중으로 닫을 때 굳이 > > 안 하고 >>로 써도 되게 문법이 바뀌었다. 저게 제대로 돌아가려면 값과 타입의 구분이 더욱 절실히 필요하다.

이런 특성 때문에 템플릿의 컴파일 편의를 위해 typename이라는 힌트 키워드가 도입되었으며, auto와 decltype도 동일한 용도는 아니지만 비슷한 맥락에서 type과 관련된 기술을 돕기 위해 등장한 게 아닌가 싶다.

3.
유니코드 API 훅킹 DLL을 만든다면, SetWindowTextW라면 WCHAR 문자열 형태로 전달된 인자를 char 문자열로 바꾼 뒤 A 함수에다 전달하고, GetWindowTextW라면 먼저 내부적으로 char 버퍼를 준비해서 A 함수를 호출한 뒤, 그걸 WCHAR로 변환해서 사용자에게 되돌리는 형태로 전달한다.

물론 용례가 무궁무진한 메시지를 주고받는 함수라든가 GetOpenFileName처럼 입· 출력 겸용 복잡한 구조체를 운용하는 함수, SystemParametersInfo처럼 PVOID 하나에 온갖 종류의 데이터를 주고받는 함수라면 훅킹 함수를 만들기가 아주 까다로워진다. 하지만 그 함수가 제공하는 모든 기능에다 일일이 변환 기능을 넣을 필요는 없다. 다양한 플래그와 기능들 중에서 내 프로그램이 실제로 사용하는 것에 대해서만 변환을 하면 된다.

그런데 훅킹 함수 중에는 의외로 아무 변환 없이 인자를 그대로 A 함수로 넘기기만 하고 리턴값도 아무 보정 없이 그대로 되돌리는 것도 있다. 훅킹 함수 단계에서 딱히 할 게 없다고 말이다.

그 대표적인 예로는 리소스를 리소스 ID가 아니라 메모리 포인터 차원에서 저수준으로 읽어들이는 DialogBoxIndirect와 LoadMenuIndirect가 있다.
얘들이 인자로 받아들이는 DLGTEMPLATE와 MENUTEMPLATE 구조체는 내부에 PCTSTR 같은 게 없으며, 애초에 A/W 구분이 없다. 왜냐하면 저 구조체는 메모리가 아니라 디스크에 저장되는 리소스 데이터 포맷을 기술하기 때문이다. Windows 9x용이든 NT계열용이든 실행 파일이야 서로 완전히 동일한 포맷이며 리소스들은 모두 유니코드 형태로 저장된다. 그러니 인자가 동일한데 저 두 함수도 원론적으로는 굳이 W/A 구분을 할 필요가 없다.

그럼에도 불구하고 이런 함수에도 굳이 A/W 구분이 존재하는 이유는 얘들이 내부적으로 대화상자와 메뉴 윈도우를 생성할 때 사용하는 CreateWindowEx 함수가 A/W 구분이 존재하며, 9x에서는 W 버전이 존재하지 않기 때문이다. 비록 리소스 데이터 상으로는 원래의 언어 텍스트가 들어있지만, 운영체제가 관리하는 윈도우의 텍스트 버퍼는 ANSI 기반이니 그걸 운영체제의 표준 기능만으로 제대로 표시할 방법도 없다.

그렇다면.. Windows 9x에서는 DialogBoxIndirectW나 LoadMenuIndirectW가 호출 됐을 때,
SetLastError(ERROR_CALL_NOT_IMPLEMENTED); return FALSE / NULL; 을 하지 말고..
return DialogBoxIndirectA( ... ) / LoadMenuIndirectA( ... ); 를 해도 되지 않았나 하는 의문이 남는다. 직통으로 A로 포워딩하는 거 말이다.
그럼 9x에서는 현 ANSI 인코딩으로 표현되지 않는 문자들은 비록 깨져서 출력되겠지만 최소한 메뉴나 대화상자가 뜨고 동작은 하지 않겠는가?

하지만 그건 별 의미가 없다고 생각돼서 조치를 취하지 않은 것 같다. GetOpenFileNameW, CreateFileW, CreateWindowExW, GetMessageW, SendMessageW 등등.. Windows 프로그램의 근간을 이루는 함수들이 유니코드 버전은 몽땅 동작하지 않는데 저런 것만 살려 놔서 뭘 하겠나? Windows 9x에서는 최소한의 유니코드 문자를 찍는 GDI 함수만이 제 기능을 하며, MessageBoxW는 인자들을 char 형태로 변환해서 예외적으로 지원해 주고 있다. 최소한의 에러 메시지를 찍고 종료하는 기능만은 유니코드 API 직통으로 동작하게 말이다. =_=;;

Posted by 사무엘

오늘날 Windows에서 실행되는 모든 프로그램들.. exe, dll 따위는 잘 알다시피 portable executable이라는 형식으로 만들어져 있다. 하지만 이 파일 포맷도.. 처음 만들어지던 당시에 여전히 컴퓨터에서 현역이던 도스와 최소한의 호환성을 유지할 필요가 있었기 때문에, 맨 앞에 MZ로 시작하는 16비트 도스 헤더를 여전히 갖추고 있다.

호환성이란 게 딴 게 아니고, 도스에서 Windows용 프로그램이 실행됐을 때 컴퓨터가 다운되는 게 아니라 "이 프로그램은 도스용이 아닙니다" 같은 짤막한 에러 메시지라도 뜨게 하는 것 말이다.

옛날에 Win32s가 제대로 설치되지 않은 상태에서 32비트 프로그램을 Windows 3.1에서 실행했더니.. "상위 버전에서 실행해 주십시오 / Win32s를 다시 설치해 주십시오" 이런 말이 메시지 박스 형태로 뜨는 게 아니라 황당하게 This program cannot be run in DOS mode라고.. 지금 시스템이 아예 Windows가 아닌 듯한 자비심 없는 메시지가 도스창에 떴다. 20여 년 전에 그 인상이 무척 강렬했었다. 요즘은 32비트 OS에서 64비트 exe의 실행을 시도해도 에러 메시지가 그 정도로 막나가는 형태는 아니다.

Windows용 프로그램들은 빌드할 때 그렇게 도스에서 잘못 실행됐을 때를 대비해 짤막하게 대신 실행해 줄 도스용 일명 "stub" 프로그램을 링크 옵션으로 지정할 수 있다. 이름하여 /STUB. 이걸 지정하지 않으면 아까 같은 저런 짤막한 에러 메시지 한 줄만 찍는 기본 stub 프로그램이 들어간다.
16비트 시절에 Visual C++ 1.5x를 보면 그 예제 stub 프로그램 자체가 winstub.exe라고 있었다. 하지만 그 이후부터는 디폴트 stub 프로그램은 그냥 링커 내부에 내장되어 버렸는지 그런 게 따로 있지는 않다.

프로그램을 특수하게 빌드하면 그런 stub을 아예 전혀 집어넣지 않는 것도 가능하다. 맨 앞에 MZ, 그리고 0x3C 오프셋에 PE 헤더가 있는 지점만 들어있으면 되고 나머지 칸은 몽땅 0으로 채움. 심지어 PE 헤더가 0x3C 오프셋보다도 전에, 도스 EXE 헤더가 있어야 할 지점에서 바로 시작하는 것도 가능하다.

미래에 마소에서 빌드하는 EXE/DLL들은 번거로운 This program cannot be ... 메시지를 떼어내고 이렇게 만들어져 나올지도 모른다. 물론 이런 프로그램은 Windows 환경에서 실행하는 건 문제 없지만 만에 하나 어느 레트로 변태 덕후가 그걸 굳이 도스에서 실행해 보면 컴퓨터가 어찌 되는지 책임 못 지는 상태가 될 것이다.

반대로 기본 stub 대신에 꽤 규모 있는 16비트 프로그램을 집어넣어서 동일 EXE가 도스에서도 그럭저럭 기능을 하고 Windows에서도 GUI를 띄우며 제대로 실행되는 프로그램을 만든 경우가 있다. Windows 9x 시절엔 레지스트리 편집기가 그러했다. 이건 Windows에서 보기 드문 하이브리드 universal binary 형태의 프로그램인 것 같다.
16비트 프로그램이 자기 자신 EXE를 열어서 PE 헤더를 파싱해서 리소스 같은 걸 읽어들이는 코드가 같이 빌드되었다면.. 도스 파트가 나중에 합쳐진 Windows 파트와 더불어 한 리소스를 공유하는 형태로 실행될 테니 이 역시 무척 흥미로울 것이다.

이 시점에서 문득 궁금해졌다.
링커가 얹어 주는 기본 stub 프로그램은 명령어가 겨우 몇 바이트밖에 되지 않는다. 얘들은 무슨 의미를 갖고 있는지, 혹시 옛날 16비트 NE 시대와 지금의 PE 시대에 stub 프로그램에 차이가 있는지..?
그래서 오랜만에 도스 API와 8086 어셈블리 명령어 레퍼런스까지 찾아서 stub 프로그램을 분석해 봤다.

stub 프로그램의 코드는 이게 전부이다.

(1), (2) 맨 앞의 PUSH와 POP은 데이터 세그먼트를 코드 세그먼트의 값과 맞추는(DS=CS) 일종의 초기화이다. 스택에다가 CS 값을 넣은 뒤 그걸 DS로 도로 가져오는 거니까.
지금 이 프로그램은 화면에다 찍을 에러 메시지도 기계어 코드와 정확하게 같은 영역에 있으므로 저건 수긍이 가는 조치이다.

(3) 그 다음으로 DX 레지스터에다가 16진수로 0xE, 즉 14를 기록한다. 저 stub 프로그램은 길이가 정확하게 14바이트이다. 이 값은 프로그램의 시작 지점을 기준(0)으로 해서 그로부터 14바이트 뒤에 있는 문자열을 가리킨다.

(4) AX 레지스터의 high byte에다가 9를 기록한다.

(5) 이렇게 기록된 AX와 DX 레지스터 값을 토대로 0x21 인터럽트를 날려서 도스 API를 호출한다. 도스 API 중 9는 DX가 가리키는 주소에 있는 문자열을 화면, 정확히는 표준 출력에다가 찍는 기능을 수행한다.
그런데 굉장히 기괴한 점이 있는데.. 얘가 받아들이는 문자열은 null-terminated가 아니라 $-terminated여야 한다!

믿어지지 않으면 아무 Windows용 EXE/DLL이나 헥사 에디터로 열어서 앞부분의 에러 메시지 텍스트가 무슨 문자로 끝나는지를 확인해 보시기 바란다.
왜 그렇게 설계되었는지 모르겠다. 파일이나 디렉터리 이름을 받는 도스 API들은 당연히 null-terminated 문자열인데 말이다.

(6) 그 다음, AX 레지스터에다가 0x4C (high)와 0x1 (low)을 기록하고..

(7) 또 도스 API를 호출한다. 0x4C는 프로그램을 종료하는 기능을 하며, 종료와 동시에 low byte에 있는 1이라는 값을 에러코드로 되돌린다. 정상 종료는 0인데 1은 뭔가 오류와 함께 종료되었음을 나타낸다.
사실, 도스 API 레퍼런스를 보면 AH 값으로 0도 프로그램을 종료시키는 역할을 하는 듯하다(도스 1.0때부터 최초). 하지만 모종의 이유로 인해 그건 오늘날은 사용이 별로 권장되지 않으며 0x4C가 원칙이라 한다(도스 2.0에서부터 추가됨).

이렇게 분석 끝. 정말 간결 단순명료하다.
참고로 도스 EXE에서 헤더를 제끼고 기계어 코드가 시작되는 부분은 0x8~0x9 오프셋에 있는 unsigned short값에다가 16을 곱한 오프셋부터이다. 가령, 거기에 04 00 이렇게 적혀 있으면 0x40 오프셋부터 디스어셈블링을 해 나가면 된다. EXE는 헤더에 고정 길이 구조체뿐만 아니라 가변 길이인 '재배치 섹션'이 나오고 그 뒤부터 코드가 시작되기 때문이다.

그럼 과거 16비트 Windows에서 쓰이던 stub은 어떻게 돼 있었을까?
거의 차이가 없긴 한데, 문자열이 들어있는 위치와 얘의 주소를 전하는 방법이 달랐다.

(1) 맨 먼저 JMP도 아니고 웬 CALL 인스트럭션이 나온다. 기계어로 표기할 때는 인자값이 0x53이어서 3바이트짜리 자기 자신 인스트럭션 이후에 0x53바이트 뒤로 가라는 뜻이 되는데, 영단어로 바꿔서 표기할 때는 자기 자신 원래 위치 기준으로 0x56바이트 뒤가 된다. 이 위치는 그냥 바로 다음 (2) 명령이 있는 곳과 같다.

(2) 함수 호출을 했는데 RET를 하는 게 아니라 스택을 pop하여 DX 레지스터에다 가져온다. 그렇다. 아까 그 call에 대한 복귀 주소에 문자열이 담겨 있으니, 아까 같은 하드코딩이 아닌 요런 방식으로 문자열 주소를 얹었다.

(3) (4) 이제부터는 아까처럼 DS = CS 해 주고,

(5)~(8) 아까와 동일. 문자열을 찍은 뒤 프로그램을 종료한다.

이런 초간단 초미니 프로그램은 exe가 아니라 com 형태로도 만들지 말라는 법이 없어 보인다. com은 그 어떤 헤더나 시그니처도 없이 첫 바이트부터 바로 기계어 코드와 데이터를 써 주면 되는.. 정말 원시적이기 그지없는 바이너리 덤프일 뿐이기 때문이다. 빌드 날짜, 버전, 요구하는 아키텍처나 운영체제 등등 그 어떤 부가정보도 존재하지 않는다.

요즘 프로그래밍 언어들이 기본 제공하는 런타임들의 오버헤드가 너무 크다 보니, 이에 대항하여 세상에서 제일 작은 "Hello world" 프로그램 이런 것에 집착하는 덕후들이 있다. Windows 프로그램의 경우 프로그램을 특수하게 빌드하여 CRT 라이브러리는 당연히 떼어내고, 코드와 데이터도 한 섹션에다 우려넣고, 거기에다 후처리까지 해서 단 몇백 바이트만으로 MessageBoxA(NULL, NULL, "Hello, world!", 0) 하나만 호출하는 프로그램을 만든 예가 있다.

그러나 이런 것들도 com 앞에서는 몽땅 버로우 타야 한다. 얘는 아예 파일 포맷 자체가 없으니까. 이 이상 더 줄일 수가 없다. com 형태로 만든 Hello world 프로그램은 겨우 20몇 바이트가 전부이다.
무슨 명령어를 내렸는지 기억은 안 나지만 컴퓨터를 재시작시키는 com 파일이 있었는데, 얘는 크기가 겨우 2바이트에 불과했다.

com은 exe처럼 코드/데이터 세그먼트 DS=CS 따윈 전혀 신경 쓸 필요 없이, 바로 본론부터 들어가면 된다. 그 대신 com은 16비트 단일 세그먼트 안에서 코드와 데이터 크기 한계가 모두 64K라는 치명적인 한계를 갖는다. 메모리 모델로 치면 그 이름도 유명한 tiny 모델 되겠다. 애초에 exe가 16비트 CPU에서 저 한계를 극복하고, 또 멀티태스킹에 대비하여 재배치도 가능하게 하려고 만들어진 포맷이기도 하다.

아, 아주 중요한 사항이 있다. com에서는 첫 256바이트, 즉 0x100 미만의 메모리 주소는 시스템용으로 예약되어 있어서 사용할 수 없다. 내 코드와 데이터는 0x100부터 시작한다. 그렇기 때문에 저 프로그램의 코드 크기는 12바이트이고, 문자열은 0xC 오프셋부터 시작하긴 하는데 거기에다가 0x100을 더해서 DX에다가는 0x10C를 써 줘야 한다.

Windows PE에다 비유하자면 0x100이 고정된 base address값인 셈이다. 그리고 DX의 값은 그냥 VA이지 RVA가 아니다.
과거에 굴러다니던 exe/com 상호 변환 유틸리티들이 하던 주된 작업 중 하나도 이런 오프셋 재계산이었다. 그리고 com에서 exe라면 모를까 더 넓은 곳에서 좁은 곳으로 맞추는 exe -> com은 아무 exe에 대해서나 가능한 게 물론 아니었다. (단일 세그먼트 안에서만 놀아야..) 과거 도스에 exe2bin이라는 외부 명령어가 있었는데 걔가 사실상 exe2com의 역할을 했다.

아무튼, 저 바이너리 코드와 문자열을 헥사 에디터를 이용해서 입력한 뒤, 파일을 hello.com이라고 명명하여 저장한다. 이걸 도스박스 같은 가상화 프로그램에서 도스 부팅하여 실행하면 신기하게도 Hello, world!가 출력될 것이다.
고급 언어를 사용하지 않고 컴파일러 나부랭이도 전혀 동원하지 않고 가장 원초적인 방법으로 나름 네이티브 실행 파일을 만든 것이다. 사용 가능한 코드와 데이터 용량이 심각하게 작다는 것과, 요즘 64비트 Windows에서는 직통으로 실행조차 할 수 없다는 게 문제이긴 하지만. (네이티브 코드라는 의미가 없다~!)

이런 식으로 컴퓨터에 간단히 명령을 내리고 램 상주 프로그램이나 바이러스 같은 것도 만들기 위해 옛날에는 debug.com이라는 도스 유틸리티가 요긴하게 쓰였다. 간단한 어셈블러/디스어셈블러 겸 헥사 에디터로서 가성비가 뛰어났기 때문이다. edlin 에디터의 바이너리 버전인 것 같다.

오늘날 어셈블리어라는 건 극소수 드라이버/컴파일러 개발자 내지 악성 코드· 보안· 역공학 같은 걸 연구하는 사람들이나 들여다보는 어려운 물건으로 전락한 지 오래다. 하지만 이것도 알면 디버깅이나 코드 분석에 굉장한 도움이 될 듯하다.
디스어셈블리 자체는 주어진 규칙대로 바이트 시퀀스를 몇 바이트씩 떼어서 명령어로 분해해 주는 비교적 간단한 작업일 뿐이다. 파서(parser)가 아니라 스캐너(scanner) 수준의 작업만 하면 된다.

하지만 디스어셈블리가 골치 아프고 귀찮은 이유는 코드의 첫 실행 지점을 정확하게 잡아서 분해를 시작해야 하며, 그래도 어느 게 코드이고 어느 게 데이터인지가 프로그램 실행 문맥에 의해 시시각각 달라지고 무진장 헷갈리기 때문이다. 데이터는 백 날 디스어셈블링 해 봤자 아무 의미가 없고, 오히려 코드의 분석에 방해만 된다. 이런 역공학을 어렵게 하기 위해서 디스어셈블러를 엿먹이는 테크닉도 보안 분야에는 발달해 있다.
하긴, 코드와 데이터가 그렇게 경계 구분 없이 자유자재로 변할 수 있는 게 "폰 노이만 모델 기반의 튜링 기계"가 누리는 극한의 자유이긴 하다.

Posted by 사무엘

1. 도움말 시스템

Visual C++ (지금의 Visual Studio)이 개발된 이래로 IDE가 제공하는 도움말 및 API 레퍼런스 시스템은 다음과 같이 변모해 왔다.

• 1세대 1.x~2.x: 그냥 평범한 WinHelp 기반 hlp
• 2세대 4.x, 5: 리치 텍스트(RTF) 기반의 자체적인 도움말 시스템이 IDE 내부에 통합되어 제공. 같은 컴퓨터 사양에서 RTF 기반 엔진은 이후에 등장한 IE+HTML 기반 엔진보다 텍스트 표시와 스크롤 속도가 훨씬 더 빨랐다.
• 3세대 6: RTF 대신 HTML 기반의 외부 도움말로 갈아탐. MSDN이라는 명칭 정립.
• 4세대 200x (.NET ~ 2008): HTML 기반이지만 CHM 말고 다른 컨테이너를 사용하는 Document Explorer. 도움말을 IDE 내부에 구동할 수도 있고 외부에 구동할 수도 있음. 융통성이 생겼다.
• 5세대 201x: Help Viewer 도입. 버전도 1.0부터 리셋 재시작.

하긴, 비주얼 C++의 프로젝트 파일 포맷도 이와 거의 비슷한 단계를 거치며 바뀌어 왔다. vcp(1세대), mdp(2세대), 3세대(dsw/dsp), 4세대(sln/vcproj), 5세대(sln/vcxproj)의 순. 단, 비주얼 C++ 5는 2세대 도움말 기반이지만 프로젝트 파일은 예외적으로 3세대 6.0과 동일한 dsw/dsp기반이다.

본인은 지금의 일명 5세대 도움말 시스템을 별로 좋아하지 않았다.
일단 5세대 시대를 처음으로 시작한 Visual Studio 2010은 후대 버전은 안 그런데 얘만 유독 무겁고 시동 속도가 무척 느렸다.
그리고 같이 내장된 Help Viewer 1은 '색인' 탭으로 가면 심한 랙이 걸려서 몹시 불편했다. 재래식 4세대 도움말에 비해 기능 차이는 별로 없는데 느리고 무거워지기만 해서 학을 뗐다.

그나마 2012부터는 IDE가 가벼워지고 도움말의 랙도 없어진 듯하다. 그 대신 2010에는 없던 다른 사이드 이펙트가 생겼다.
첫 구동되어서 Help Viewer 스플래시 화면이 뜰 때 마우스 포인터가 움직이지 않을 정도로 컴퓨터가 잠시 stun(멈칫)된다. 구닥다리 내 컴에서만 그런 줄 알았는데 회사의 초고성능 최신식 컴퓨터에서도 동일한 현상이 발생한다.

먼 옛날의 불안정한 유리몸이던 Windows 9x도 아니고 엄연히 7~10급의 최신 OS에서 하드웨어를 도대체 어떻게 건드렸길래 마우스 포인터조차 움직이지 않는 상태가 되나?

잘 알다시피 요즘 Visual Studio IDE는 평범한 Win32 API로 GUI를 만드는 게 아니라 닷넷 + Windows Presentation Foundation 기반으로 특수하게 하드웨어 가속도 받으면서 아주 뽀대나는 방식으로 그래픽을 출력한다.
글자를 찍는 계층도 뭐가 바뀌었는지, 텍스트 에디터에는 트루타입 글꼴만 지정되지 FixedSys 같은 비트맵 글꼴을 사용할 수 없게 바뀌었다. '굴림'은 트루타입이니 사용은 가능하지만 embedded 비트맵이 대신 찍히는 크기에서도 ClearType이 적용되어 색깔이 살짝 바뀌어 찍히며, 같은 글자끼리도 폭이 좀 들쭉날쭉하게 찍힌다.

이렇듯, 재래식 GDI API로 글자를 찍었다면 절대로 나타나지 않을 사이드 이펙트들이 좀 보인다.
그런 특수한 그래픽/GUI를 사용하기 위해서 마치 게임 실행 전처럼 하드웨어 초기화가 일어나고, 그때 마우스 포인터가 살짝 멈추는가 하는 별별 생각이 든다.

2. GDI API 설명은 어디에?

요즘(2010년대) Visual Studio의 MSDN 레퍼런스엔 왜 GDI API들이 누락돼 있는지 궁금하다. BitBlt, SetPixel 같은 것들. desktop app development에 해당하는 몇백 MB짜리 도움말을 분명히 설치했는데도 로컬 도움말에 포함되지 않아서 저것들 설명은 느린 인터넷 외부 링크로 대체된다.

VS 2010에서는 GDI 관련 API들이 색인으로는 접근 가능하지만 목차에서는 존재하지 않아서 접근불가였다. 그리고 MFC 레퍼런스도 단순한 API wrapper의 경우(가령 CDC::MoveTo) See also 란에 자신의 원래 API 함수에 대한 링크(가령 MoveToEx)가 있는데, 요건 내부 링크가 아니라 인터넷 MSDN 사이트의 외부 링크로 바뀌어 있었다.

즉, 그때부터 GDI API의 설명은 제외될 준비를 하고 있었던 듯하다. 그 뒤로 2012인가 2013 이후부터는 그것들이 색인에서도 제외되고 완전히 없어졌다. 2015도 마찬가지인 걸 보니 GDI의 누락은 단순 지엽적인 실수가 아니라 의도적인 계획인 것으로 보인다.

kernel32, user32, advapi32 등 나머지 API들은 다 남아 있는데 왜 GDI만 없앴는지, 얘는 정말로 완전히 deprecate 시킬 작정인지 알 길이 없다. Windows NT 3.1 초창기 때부터 20년이 넘게 운영체제의 중추를 구성해 온 놈인데 그걸 호락호락 없애는 게 가능할까? 게다가 BeginPaint, GetDC처럼 GDI를 다루지만 실제로는 USER 계층에 속해 있는 기초 필수 API조차 언급이 누락된 것은 좀 문제라고 여겨진다.

이런 것 때문에 본인은 Visual Studio는 옛날 Document Explorer 기반이던 200x도 여전히 한 카피 설치해 놓고 지낸다.
옛날에는 또 Visual C++ 2005의 MSDN만 TSF API 레퍼런스도 없고 뭔가 나사가 빠진 듯이 컨텐츠가 왕창 부실해서 내가 놀랐던 기억이 있다. 2003이나 2008은 안 그랬고 걔만 좀 이상했었다.

3. 프로젝트에 소속되지 않은 소스 코드도 심층 분석

Visual C++. 2013인지 2015인지 언제부턴가 프로젝트에 등재되지 않은 임의의 C/C++ 소스 코드를 열었을 때도 이 파일을 임시로 파싱해서 인텔리센스가 동작하기 시작했다. 이거 짱 유용한 기능이다.
전통적으로 프로젝트 소속이 아닌 파일은 문맥을 전혀 알 수 없으며 빌드 대상도 아니기 때문에 IDE에서의 대접이 박했다. 정말 기계적인(문맥 독립적이고 명백한) 신택스 컬러링과 자동 들여쓰기 외에는 자동 완성이나 인텔리센스 따위는 전혀 제공되지 않았다. 전혀 기대를 안 하고 있었는데 이제는 걔들도 miscellaneous file이라는 범주에 넣어서 친절하게 분석해 준다.

4. Spy++

Visual C++에는 프로그램 개발에 유용하게 쓰일 만한 아기자기한 유틸리티들이 같이 포함돼 있다.
'GUID 생성기'라든가 '에러 코드 조회'는 아주 작고 간단하면서도 절대로 빠질 일이 없는 고정 멤버이다.
옛날에는 'OLE/COM 객체 뷰어'라든가 'ActiveX 컨트롤 테스트 컨테이너'처럼 대화상자가 아닌 가변 크기 창을 가진 유틸리티도 있었는데 OLE 내지 ActiveX 쪽 기술이 인기와 약발이 다해서 그런지 6.0인가 닷넷 이후부터는 빠졌다.

그 반면, 기능이 제법 참신하면서 1990년대부터 지금까지 거의 20년 동안 변함없이 Visual C++과 함께 제공되어 온 장수 유틸리티는 단연 Spy++이다.
얘는 제공하는 기능이 크게 변한 건 없었다. 다만 아이콘이 초록색 옷차림의 첩보요원(4.x..!), 분홍색 옷차림(6.0~200x), 검정색 옷차림(2010~현재)으로 몇 차례 바뀌었으며, 운영체제의 최신 메시지가 추가되고 도움말이 hlp에서 chm으로 바뀌는 등 외형만이 최소한의 유지보수를 받아 왔다.

아, 훅킹을 사용한다는 특성상 2000년대 중반엔 64비트 에디션이 따로 추가되기도 했다. 하지만 GUI 껍데기는 x86용 하나만 놔두고 64비트 프로그램에 대해서는 내부적으로 64비트 서버 프로그램을 실행해서 얘와 통신을 하는 식으로 프로그램을 개발하면 더 깔끔했을 텐데 하는 아쉬움이 남는다. 그러면 사용자는 겉보기로 한 프로그램에서 32비트와 64비트 구분 없이 창을 마음대로 들여다보고 훅킹질을 할 수 있을 테니 말이다.

실제로 <날개셋> 입력 패드도 그런 식으로 동작하며, 당장 Visual C++ IDE도 내부적으로 64비트 IPC 서버를 따로 운용하기 때문에 IDE 자체는 32비트이지만 64비트 프로그램도 아무 제약 없이 디버깅이 가능하다. 하지만 안 그래도 훅킹을 하느라 시스템 성능을 잡아먹는 프로그램인데.. 성능 문제 때문에 깔끔하게 64비트 에디션을 따로 빌드한 것일 수도 있으니 Spy++ 개발자의 취향은 존중해 주도록 하겠다.

Spy++는 워낙 역사가 긴 프로그램이기 때문에 초창기 버전은 창/프로세스들의 계층 구조를 전용 트리 컨트롤이 아니라 리스트박스를 정교하게 서브클래싱해서 표현했다. 쉽게 말해 과거 Windows 3.1의 파일 관리자가 디렉터리 계층 구조를 표현한 방식과 비슷하다. 사실은 리스트박스에서 owner draw + user data로 계층 구조를 표현하고 [+/-] 버튼을 눌렀을 때 하부 아이템을 표시하거나 숨기는 건 1990년대 초반에 프로그래밍 잡지에서 즐겨 다뤄진 Windows 프로그래밍 테크닉이기도 했다.

그러다가 VC++ 2005인가 2008 사이쯤에서 Spy++은 운영체제의 트리 컨트롤을 사용하는 걸로 리팩터링이 됐다. 사용자의 입장에서는 기능상의 변화가 없지만 내부적으로는 창을 운용하는 방식이 완전히 바뀐 것이기 때문에 이건 내부적으로 굉장히 큰 공사였으리라 여겨진다.

그런데 VC++ 2010과 함께 제공된 Spy++는 일부 단축키들이 동작하지 않는 버그가 있었다. 전부 먹통인 것도 아니고 창 찾기 Alt+F3, 목록 새로 고침 F5, 속성 표시 Alt+Enter 같은 게 동작하지 않아서 프로그램을 다루기가 불편했다. 이 버그는 잠깐 있었다가 다시 2012 이후에 제공되는 Spy++부터는 고쳐졌다.

Posted by 사무엘

1. 메트로 앱

Windows 10이 나온 지 1년이 좀 넘었고, 마소에서 그 1년간 시행하던 사상 초유의 OS 메이저 버전간의 무료 업그레이드 기간도 끝났다.
처음부터 Windows 7 이하의 구형 OS를 쓰고 있었고 컴의 사양도 빠듯하다면 모를까, 8.1을 쓰는 중에 10으로는 업그레이드를 마다할 이유가 확실히 전혀 없다고 여겨진다.

잘 알다시피 시작 메뉴와 메트로 앱이 쓸데없이 전체 화면을 점유하는 게 아니라 창 형태로 실행 가능해진 것은 아주 환영할 만한 변화이다. 왜 진작에 이렇게 안 만들었나 모르겠다.
결국 PC용 Windows의 입장에서는 재래식 데스크톱 UI뿐만 아니라 외형이 뭔가 flat하고 modern하고 stylish(?)하고, 모바일에 친화적이고 보안 제약이 강하게 걸린 UI 모드가 하나 더 생긴 셈이다. 마소에서는 그걸 최종적으로 Universal Windows app이라고 이름을 붙였으며 같은 기능을 하는 프로그램들을 이 형태로도 여럿 만들었다. 대표적인 게 Edge 브라우저이고.

하지만 개인적으로는 같은 기능을 하는 프로그램이 두 버전으로 중복 구현돼 있는 게 별로 마음에 안 든다. 특히 제어판도 기존 제어판에 덧붙여 '설정'이라는 메트로 앱과 이중 구도로 바뀌었다. 화면 해상도를 바꾸는 기능과 DPI를 바꾸는 기능만 해도 데스크톱 버전으로 갔다가 메트로 버전으로 갔다가 하면서 찾는 등 좀 혼란스러워진 느낌이다.

데스크톱 UI는 전통적으로 키보드가 주류이고 마우스가 옵션인 구도이다. 그리고 640*480 내지 800*600처럼 지금으로서는 상상도 할 수 없는 열악한 저해상도 디스플레이와 비트맵 글꼴 환경에서 시작해서 차근차근 발전해 왔다. 그렇기 때문에 글자 크기도 전통적으로 작은 편이다. 사실, 업무 환경에서는 한 화면에서 작은 글씨로 정보가 많이 표시되는 것도 중요하기도 하니까.

그러나 메트로 UI는 그런 레거시 배경이 없으며, 반대로 터치스크린을 염두에 두고 있기 때문에 각종 글자나 GUI 위젯이 큼직하다. 키보드를 배려한 지저분한 focus rectangle 점선이나 액셀러레이터 문자 밑줄이 없다. 사실 마소는 데스크톱 UI에서도 진작부터 저걸 시각적으로 지저분하다고 인지했다. 하지만 그걸 대놓고 없애 버릴 수는 없으니, 고육지책으로 마우스만 사용할 때는 저걸 기본적으로 표시하지 않으려고 세심한 신경을 썼다. WM_UPDATEUISTATE 같은 메시지가 추가된 건 무려 Windows 2000 시절부터이다.

과거에 닷넷이 C++보다 생산성이 더 뛰어나고 단순 바이너리 레벨에서의 API 통합 규격인 COM보다 규모가 더 큰 언어 통합 바이트코드 실행 환경을 추구했다면, 메트로는 PC와 모바일 기기간의 통합 UI를 추구했다고 볼 수 있다. 메트로와 닷넷은 큰 관련이 없으며 메트로 앱도 C++ 네이티브 코드 기반으로 얼마든지 만들 수 있다는 게 의외의 면모이다.

하지만 난 컴퓨터에서는 걍 데스크톱 앱만 있는 게 좋다. 모니터에 가로/세로 피벗 기능이 있는 건 봤어도 멀티터치 기능이 있는 건 난 지금까지 한 번도 못 봤다. 정작 멀티터치 API 자체는 Windows 7부터 도입됐는데도 말이다. 멀티터치는 문자 입력과도 밀접한 관계가 있는 인터페이스임에도 불구하고 날개셋 역시 그쪽 지원은 전무하다. 지원되는 기기를 지금까지 전혀 못 봤고, 고로 지원할 필요를 못 느껴서.
터치스크린은 호주머니에 넣고 들고 다니는 기기만으로 족하지, 커다란 모니터에다가 지저분한 지문 묻히고 싶지는 않더라.

2. 에디트 컨트롤

아 그나저나 굉장히 뜻밖인 점인데, Windows 10은 에디트 컨트롤이 내부적으로 대대적인 리모델링을 거쳤는지 메모장이 수~10수MB에 달하는 파일을 순식간에 읽고 편집할 수 있게 됐다. 아주 최근에야 알았다. 직전의 8.1만 해도 안 이랬는데.
Windows에서 에디트 컨트롤은 전통적으로 단일 버퍼 기반이기 때문에 아주 큰 파일을 읽은 뒤 맨 앞부분에서 글자를 삽입하거나 지우면 랙이 장난 아니게 발생했다. 평생 영원히 안 고쳐질 줄 알았는데.. 이건 뜻밖의 긍정적인 변화가 아닐 수 없다.

먼 옛날, Windows 9x에서 NT로 넘어가면서 일단 황당한 64KB 제약은 없어졌다. 하지만 2000/XP급에서도 16비트 기준에 맞춰졌던 비효율적인 내부 알고리즘은 여전했기 때문에 메모장이 편집할 수 있는 실질적인 파일 크기는 겨우 몇백KB 수준에 머물러 있었다. 그게 Windows 10에 와서야 완전히 개선돼서 한계가 없어졌다. 참 오래도 걸렸다.

3. 마우스 휠의 적용 대상

마우스 포인터의 움직임이나 버튼 누름 메시지는 너무 당연한 말이지만 포인터의 바로 아래에 깔려 있는 윈도우로 전달된다.
그러나 휠 굴림 메시지는 사정이 약간 다르다. 맥 OS는 여전히 바로 아래의 윈도우로 전달되는 반면, Windows는 전통적으로 키보드 포커스를 받고 있는 윈도우로 전달되곤 했다.

그랬는데.. Windows 10에서는 휠 메시지 전달을 어느 방식으로 할지를 지정할 수 있다. 내가 본 기억이 맞다면, 제어판의 마우스 카테고리엔 없고, '설정'이라는 메트로 앱으로 가야 한다.
콤보 박스에서 drop list는 열지 않고 키보드 포커스만 갖다 놓은 뒤 휠을 굴렸는데 콤보 박스의 selection이 바뀌지 않아서 마우스에 문제가 생겼나 의아해했는데 사실은 이렇게 동작이 바뀌었기 때문이었다.

둘을 절충해서 일단 마우스 포인터가 놓인 창부터 먼저 고려하되, 그 창에 스크롤 바 같은 게 없어서 휠에 반응할 여지가 없으면 그 다음 순위로 키보드 포커스가 있는 창을 스크롤 시키는 것도 괜찮지 않을까 싶다.

4. 두벌식/세벌식 전환

세벌식 자판 사용자에게는 참 난감한 일이지만, Windows라는 운영체제는 기본 한글 IME에서 두벌식/세벌식을 전환하는 절차가 버전업을 거칠수록 더욱 복잡해져 왔다.

• 98/2000/ME: 이때가 제일 나았음. 한영 상태 버튼을 우클릭했을 때 나오는 메뉴에서 글자판을 바로 고를 수 있었다.
• 95: 한영 상태 버튼 우클릭 메뉴에서 '환경설정' 대화상자를 꺼낼 수 있었고, 거기서 글자판을 고르면 됐다.
• Windows XP/Vista/7: 우클릭 메뉴에서 "텍스트 서비스 및 입력 언어" 대화상자를 꺼낸 뒤, 거기서 한 단계 거쳐야 MS 한글 IME의 환경설정 대화상자를 열 수 있다. 즉, 예전보다 한 단계 더 거쳐야 글자판을 바꿀 수 있다.
• Windows 8 ~ 10: IME 브랜드 아이콘을 클릭 후 맨 아래의 '설정'을 고른 뒤, '한국어'를 골라야 MS 한글 IME를 찾을 수 있고, 거기서 또 '옵션'을 클릭하면 환경설정 대화상자를 열 수 있다. 이제는 두 단계를 거쳐야 된다.

요약하자면 XP 시절에 TSF라는 체계가 추가되면서 글자판 전환 절차가 급 까다로워졌으며, 8~10에서는 더 번거로워졌다.
사실 이건 TSF 자체의 문제는 아니다. MS 한글 IME가 옛날과는 달리 자체적으로 글쇠배열을 간편하게 전환하는 버튼이나 메뉴를 제공하지 않는 바람에, 운영체제 제어판 애플릿을 일일이 꺼내야 하는 구조가 된 것이 근본 원인이다. 마소에서는 두벌식/세벌식 전환을 꼭 그렇게까지 기능을 노출해 줄 필요가 있을 정도로 자주 행해지는 동작은 아니라고 판단한 것이다..;;

어쨌든 이런 이유로 인해 Windows 10 시절에도 본인의 세벌식 파워업 프로그램에 대한 수요는 없어지지 않고 있다.
사용자 차원에서 글쇠배열 전환 절차는 복잡한 편이지만, 그래도 Windows Vista 이래로 마소에서는 내부적인 두세벌 정보 저장 방식은 쓸데없이 이랬다 저랬다 바꾸지 않고 있다. 그 덕분에 거의 10여 년간 세벌식 파워업 프로그램도 핵심적인 동작 알고리즘이 크게 바뀔 필요는 없었다.

5. 프로그램 외형

Windows 10은 데스크톱 앱의 창 껍데기가 알다시피 전반적으로 하얗게 밝은 회색 계열로 바뀌었다. 8 시절에는 non-client 영역의 두꺼운 테두리가 배경 그림의 분위기에 맞춰 형형색색으로 바뀌곤 했는데 그건 없어졌다.
Visual Studio와 Office도 최신 버전이 다 그런 색으로 바뀐 걸 보면 이게 2010년대 마소의 디자인 트렌드인 듯하다. 다만, 활성화된 창과 비활성화된 창이 껍데기나 제목 표시줄에 배경색의 차이가 서로 전혀 없고 글자색만 살짝 달라지는 건 좀 아쉬움으로 남는다. 상태를 분간하기 어려워서다.

어쩌면 저 디자인이 마소가 데스크톱 앱에다 선보이는 마지막 디자인인가 하는 생각도 든다.
1990년대부터 2000년대까지 마소는 운영체제와 VS, 오피스 공히, 메이저 버전이 바뀔 때마다 프로그램 비주얼과 아이콘을 왕창 뜯어고치는 게 유행이었다. 맥OS 진영에서는 상상도 못 할 일..;;

그런데 그 관행이 이제 약발이 다해 가나 보다.
VS 2013과 2015, 오피스 2013과 2015는 웬일로 비주얼이 큰 차이가 없고 프로그램들 아이콘도 바뀌지 않았다. 마소 제품들에서 전반적으로 발견되는 추세이다.
심지어 미플이라든가 IE는 잘 알다시피 개발을 중단하고 유사 기능의 메트로 앱으로 대체한다는 선언까지 된 상태이다. 진작에 개발이 중단되어 명맥만 유지되고 있는 Html Help를 보는 듯한 느낌이다.

그래도 또 2010년대 후반이나 2020년대로 가면 프로그램 외형이 또 어떻게 바뀔지 알 수 없는 노릇이다. 머리를 쥐어짜면서 미래를 개척한다는 것 참 힘든 일이다.

6. 도움말

Windows 10은 로컬 도움말이란 게 사실상 완전히 없어졌는가 보다.
메모장 같은 기본 제공 프로그램에서 F1을 누르면 HTML 도움말이 뜨지도 않고 자기네들이 또 따로 만든 도움말 창이 뜨지도 않고 그냥 Edge 브라우저로 웹사이트 기반 도움말만이 달랑 뜬다. 인터넷에 연결돼 있지 않으면 도움말을 열람할 수 없다. 도움말이 일체의 전용 프로그램이 없이 아예 이런 형태로 싹 바뀌어 버린 건 10이 처음인 듯하다.

덕분에 C:\Windows\Help 디렉터리를 보면 XP까지만 해도 예전엔 chm 파일들이 즐비했으며 웹페이지/플래시 기반의 신제품 데모 같은 볼거리도 있었다. 그러나 지금은 죄다 옛날 추억이 됐다.
PC 사용자들의 평균적인 컴퓨터 실력이 충분히 향상됐으니, 어차피 읽지도 않을 구질구질한 도움말들을 다 삭제한 건지는 모르겠다. 허나 Vista/7 때는 아예 '에니악'까지 소개하면서 컴맹을 대상으로 컴퓨터 기초를 일일이 소개하는 로컬 도움말이 있었는데 이건 너무 과격한 변화가 아닌가 싶다.

Posted by 사무엘

1. 테두리

GUI 프로그램에서 대화상자를 만들다 보면 단순히 글과 그림, 목록, 버튼 같은 것만 집어넣는 게 아니라 그 컨트롤들을 성격별로 분류하는 구획 경계선, 테두리 같은 걸 그어야 할 때가 있다.
그런 게 필요하면 static 컨트롤을 쓰면 된다. Visual C++의 리소스 에디터 상으로는 Static text와 Picture control이 서로 다른 항목으로 나뉘어 있지만, 둘 다 운영체제의 윈도우 클래스 이름은 동일하게 "Static"이다.

Picture 컨트롤을 삽입한 뒤 속성에서 Type을 Etched Vert으로 고르면 세로줄이 만들어지며, Etched Horz를 고르면 가로줄이 만들어진다. 그리고 Type을 Frame으로 지정하고 Color를 Etched로 지정하면 사각형 테두리를 만들 수 있다.
선을 단순히 단색으로 그리는 게 아니라 음각으로 파인 듯이 3D 입체 효과(?)가 나게 그리기 때문에 etched라는 단어가 자꾸 나온다.

그런데 Picture 컨트롤만 있는가 하면 그렇지는 않다. 우리가 잘 아는 Group box라는 컨트롤도 있어서 사각형 테두리를 친다는 점에서는 Picture하고 거의 같은 역할을 한다.
단, Group box는 테두리의 좌측 상단에 간단한 텍스트를 찍을 수 있다. 그래서 이 테두리 안에 속한 컨트롤들의 전체 제목이나 카테고리 이름을 넣을 수 있기 때문에 더 유용하다.

또한, 이런 이유로 인해 Group box는 테두리의 윗변은 무작정 맨 위쪽이 아니라, 그 텍스트의 중앙 라인에 맞춰서 그어진다. 아래 그림을 보면 이게 무슨 말인지를 알 수 있다. (크기가 서로 동일한 Group box와 Picture frame이 화면에 실제로 보이는 형태)

Group box는 말 그대로 한 그룹에 속하는 컨트롤들(특히 라디오/체크 박스)의 가로· 세로 경계선과 제목 텍스트까지 한큐에 표시해 주기 때문에 굉장히 유용하다. 그런데 프로그램들에 따라서는 static text 옆에다가 가로줄 하나만 추가해 넣어서 Group box의 간소화 버전인 일종의 Group line을 넣기도 한다. 이 역시 위의 그림에 형태가 묘사되어 있으며, 독자 여러분도 이런 GUI를 많이 보신 적이 있을 것이다.

본인은 새로운 대화상자를 디자인할 때 Group box를 쓸지 Group line을 쓸지를 종종 고민하곤 한다. 가끔은 line이 box보다 더 깔끔하게 느껴질 때도 있다. line은 추가적인 좌우 여백을 소모하지 않기 때문에 공간 활용면에서도 좋다.

하지만 line은 group과는 달리, 텍스트와 가로줄을 서로 폭을 정확하게 계산해서 그려 주는 컨트롤이 없기 때문에 만들기가 불편하다. static text 따로, 가로줄 따로 두 컨트롤을 일일이 만들어야 한다. 텍스트의 글꼴이나 내용이 바뀌면 가로줄의 위치와 길이도 프로그램이 수동으로 업데이트해야 하니 번거롭다.

개인적인 생각은 (1) 길쭉하게 만들어 놓은 static 컨트롤에다가 텍스트를 찍은 뒤 나머지 오른쪽 여백에다가는 글자 크기 기준으로 중앙에 etched 가로줄을 자동으로 그려 주는 옵션을 추가하거나, (2) 기존 group box 컨트롤에 사각형 테두리가 아니라 가로줄만 찍는 옵션이 좀 있어야 한다고 본다. group box를 크기를 줄인다고 해서 group line로 만들 수는 없기 때문이다.

하지만 어느 것도 갖춰져 있지 않기 때문에 심지어 마소에서 만드는 프로그램들도 대화상자를 Spy++로 들여다보면 Group line은 별 수 없이 텍스트+가로줄로 수동으로 구현돼 있다. 아쉬운 점이 아닐 수 없다.
그래서인지.. MS Office 제품 중에서 운영체제의 대화상자를 사용하지 않고 자체 GUI를 사용하는(너무 역사가 길어서) Word와 Excel은 서식 대화상자 같은 걸 보면 group line이 상대적으로 많이 쓰였고, PowerPoint, Access, Publisher처럼 상대적으로 늦게 개발된 프로그램들은 group box를 더 많이 볼 수 있다.

내 심증은.. Word와 Excel은 한 개체만으로 간단하게 제목과 가로줄까지 group line을 표시해 주는 GUI 컨트롤/위젯을 자체적으로 보유하고 있는 것으로 보인다. 그 증거로는 Excel과 PowerPoint의 '화면 확대 배율' 대화상자 스크린샷이다. PowerPoint는 진짜 운영체제의 static 컨트롤 가로줄이지만 Excel은 그게 아니기 때문에 가로줄의 색깔이 두 프로그램이 서로 다른 걸 알 수 있다.

같은 제품 안에도 프로그램끼리 이렇게 미묘하게 일관성이 없는 부분이 존재한다.
그 뿐만이 아니다. 고전 테마에서는 group box의 선 모양과 static 컨트롤의 etched 선이 저렇게 똑같지만, 다른 테마가 적용되고 나면 둘의 선 모양이 달라진다. XP 시절의 Luna 테마든, 그 뒤의 Aero든.. 마찬가지다. 어느 것이든 group box의 선이 통상적인 etched 선보다 더 연해진다.

더욱 놀라운 사실은 따로 있다. 사실 group box는 윈도우 클래스가 Static이 아니라 Button이다. 이 정도로 Static 컨트롤과는 애초부터 기술적인 연결 고리가 없었다.
check나 radio 버튼은 비록 push 버튼과는 성격이 다르지만 그래도 BN_CLICKED라는 이벤트를 날려 준다는 공통점이 있으니 같은 버튼이라는 게 이해가 된다만.. group box는 포커스도 안 받고 이벤트도 없고.. 버튼과는 하등 공통점을 찾을 수 없는 static 장식품에 불과한데 도대체 왜 얘까지 Static이 아닌 버튼 소속인 걸까?

(더구나 라디오 버튼의 소속을 분류하는 것도 그 컨트롤들이 자체적으로 갖고 있는 WS_GROUP 스타일로 하지, 딱히 group box가 기여하는 건 없다. group box 안 만들어도 "1~3 중 택일, 4~7 중 택일" 같은 라디오 버튼들의 선택 영역 구분은 얼마든지 할 수 있다.)

Windows에서는 같은 버튼이라는 클래스인데 스타일을 무엇을 주느냐에 따라서(BS_GROUPBOX) 외형과 동작이 완전히 다른 윈도우가 되는 것이다. 먼 옛날 1.0 시절에는 리소스가 하도 부족해서 기본 윈도우 클래스를 새로 등록하는 것조차도 부담스러워서 가능한 한 같은 클래스에다가 여러 기능을 구겨넣기라도 해야만 했는가 보다. 하지만 group box가 왜 버튼 출신이며 기존 etched 선과 괴리가 생겼는지는 여전히 내 머릿속에 이해되지 않는 의문으로 남아 있다.

2. 버튼

말이 나왔으니 다음으로 버튼 얘기를 더 계속해 보도록 하자.
아래 그림은 평범한 라디오/체크/푸시 버튼과 탭 컨트롤을 고전 테마 기준으로 집어넣어 표시한 모습이다.

그런데, 라디오와 체크 버튼은 Button 출신답게 자기 자신도 버튼처럼 표시되게 하는 옵션이 있다. 바로 BS_PUSHLIKE 스타일. (BS_PUSHBUTTON은 윈도우의 동작 자체를 푸시 버튼으로 결정하는 스타일이니 혼동하지 말 것.)

저렇게 하니 라디오/체크도 푸시 버튼과 외형이 거의 똑같아진다. 그래도 키보드 포커스를 받았을 때 라디오/체크 버튼은 푸시 버튼처럼 테두리가 굵어진다거나 하지는 않기 때문에 실제로 조작해 보면 푸시 버튼과는 뭔가 다른 게 느껴진다.
라디오와 체크 버튼은 자신이 클릭된 경우 자신이 눌러지고 선택된(체크된) 상태로 바뀌는 반면, 진짜 푸시 버튼은 선택된 상태 같은 건 존재하지 않는다. 눌러도 다시 도로 튀어 올라온다는 차이점이 있다.

한편, 위의 그림에서 나오듯, 사실은 탭 컨트롤도 경계선 없이 각각의 탭의 이름만을 버튼처럼 표시하는 옵션이 있다(TCS_BUTTONS).
탭 버튼은 라디오 버튼과 비슷하지만 키보드로 조작할 경우, 화살표 키만 누른다고 해서 선택이 바로 이동하지 않는다. Space를 눌러서 선택을 확인해 줘야만 바뀐다는 차이가 있다.

도대체 이런 기능이 왜 존재하나 싶겠지만, 이 물건은 우리에게 아주 친숙하다. 먼 옛날, Windows 95의 작업 표시줄이 바로 탭 컨트롤에다가 이 스타일을 써서 구현돼 있었다. 물론 지금이야 작업 표시줄은 독자적인 비주얼과 기능이 너무 많이 들어갔기 때문에 진작에 자체 구현으로 바뀌었다.

이로써, 푸시 버튼처럼 생긴 놈이 푸시 버튼 자체뿐만 아니라 최소한 세 종류가 더 있을 수 있다는 뜻인데..
얘들도 테마를 변경하면 사정이 좀 달라진다.
Button들은 테마가 적용되어 버튼이 알록달록하게 바뀌지만 탭 컨트롤의 버튼들은 변화가 없다. 작업 표시줄 말고는 딱히 쓸 일이 없어져서 그런 듯하다. 글쎄, MDI 에디터 같은 데서 문서 탭을 나타낼 때 쓸 수도 있지 않으려나 모르겠다만..

이로써 버튼이 전혀 아니지만 클래스가 Button인 놈(group box), 버튼처럼 생겼지만 버튼이 아닌 놈(탭 버튼)을 모두 살펴보았다.
Windows XP~7이라는 과도기를 거쳐 8~10까지 나온 마당에 이제 운영체제에서 고전 테마는 더욱 보기 어려워지고 마치 XP Luna만큼이나 역사 속으로 사라져 가고 있다.
하지만 지금 생각해 봐도 고전 테마는 단순하면서도 굉장히 철저한 원칙 하에 세심하게 디자인된 것 같다. 화면에 표시만 하는 놈은 회색, 사용자와 interation을 하는 부분은 흰색에다가 두꺼운 입체 테두리, 포커스를 받은 아이템은 점선, 실제로 선택된 아이템은 highlight 색 등등..

그렇게도 사용자 감성, 인터페이스를 중요시한다면서 애플 맥 진영은 옛날에 GUI가 어떠했나 모르겠다. 안 그래도 마소가 애플의 GUI를 베꼈다고 험담이 많이 나돌던데.
그렇게 고전 테마 때 일관되게 형성되었던 GUI 가이드라인이 오히려 테마가 적용되면서, 당장 겉으로 드러나는 비주얼은 더 화려해졌을지 모르나, 그런 질서가 좀 무너진 듯한 것도 보여서 아쉬움이 남는다. 아무래도 고전 테마를 처음 만들던 때와 지금, 개발자가 세대 교체가 돼서 그런 것일 수도 있고.
그나저나 group line은 세대를 초월하여 진짜로 운영체제 차원에서 기능이 좀 있었으면 좋겠다.;;

Posted by 사무엘

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 사무엘

이건 개인적으로 오래 전부터 알고 있었던 사소한 옛날 추억 아이템인데, 지금까지 한 번도 공개적으로 언급한 적이 없었던 관계로 털어놓고자 한다.

Windows에 메모장은 1.0 시절부터 있었던 터줏대감 기본 프로그램이다. 기본 윈도우 프레임 껍데기에다 운영체제의 내장 에디트 컨트롤 하나만 달랑 얹은 극도의 최소주의 형태이다. 세월이 흐르면서 워드패드와 그림판은 리본 UI가 탑재됐고 계산기도 아주 화려한 UI로 리모델링된 마당에, 메모장만은 외형이 거의 바뀐 게 없다.

Windows 프로그래밍 공부를 한 사람이라면 메모장 정도는 하루 정도만 투자하면 동일 프로그램을 직접 만들 수도 있을 것이다. 아니, 있는 그대로 복제품만 만드는 건 너무 시시하고, MDI 정도는 지원하게 확장해서 만들기도 한다. 지금도 있는가 모르겠는데 비주얼 C++의 MFC 예제에는 MultiPad라고 실제로 메모장의 MDI 버전도 소스 코드와 함께 제공된 바 있다.

그런데 Windows 95부터 ME까지 9x 계열의 메모장은 '도움말'이라는 메뉴 명칭의 뒷부분에 출처를 알 수 없는 공백이 하나 더 들어가 있었다. 아래 스크린샷을 참고할 것. 계산기의 '도움말'과는 달리, 메모장의 '도움말'은 파란색이 조금 더 긴 게 보일 것이다.

더욱 신기한 건, 98과 ME로 버전이 올라가도 상황이 바뀐 게 없었다는 점이다. 그것도 한글판과 영문판 공히.
메모장이 아무리 최소주의 기본 프로그램이었다고 해서 그 시절 동안 변화가 전혀 없었느냐 하면 그렇지는 않았다. 보다시피 아이콘 모양이 바뀌었으며 본문의 글꼴을 변경하는 기능이 98에서 추가되었다. 코드뿐만 아니라 리소스 쪽도 검수할 기회가 있었는데 저 문자열의 뒤의 공백은 여전히 제거되지 않은 채 남았다.

그 반면, Windows 2000의 메모장은 그렇지 않다.

ME는 2000보다 나중에 나왔음을 감안한다면, 같은 메모장도 NT 계열의 것과 9x 계열의 것은 코드와 리소스가 정말로 한데 공유된 구석이 없었다는 걸 알 수 있다. 같은 소스에서 조건부 컴파일을 한 것조차도 아닌 듯하다.

심지어는 도움말도 둘 다 완전히 다르게 따로 만들어졌다. Windows ME의 메모장 도움말은

이라고 사용자에게 당장 필요한 task 지향적인(use, using) 설명 위주인 반면.. Windows 2000의 메모장 도움말은

이라고 프로그램의 정체성에 대해서 더 사무적이고 격식을 차린 문체로 시작한다.

메모장은 아주 단순한 프로그램이지만 9x 계열의 것과 NT 계열의 것이 기능상의 차이도 꽤 크다. 후자는 (1) 유니코드를 지원하며 (2) 64KB 이상 크기의 파일도 열 수 있다. 다시 말해 전자는 "파일이 너무 큽니다. 워드패드에서 여시겠습니까?" 이런 로직이 존재하며, 지금으로서는 상상하기 어렵지만 UTF8 방식 텍스트를 읽고 쓰는 것조차도 지원하지 않았다.

물론 운영체제의 에디트 컨트롤이라는 건 리치 에디트와는 달리 아주 방대한 텍스트를 편집하는 데는 최적화되지 않았던지라 단일 버퍼 기반이라는 한계는 NT 계열도 그대로 갖고 있었다.

또한 NT 계열의 메모장은 BOM이 없는 유니코드 텍스트 파일에 대해서 IsTextUnicode라는 휴리스틱 API를 호출해서 텍스트 파일의 인코딩을 판단했었다. 그런데 그게 좀 버그가 있어서 정상적인 영어 단어로만 이뤄진 짤막한 파일을 UTF16 방식으로 저장된 중국어 한자로 오판하곤 했다. 0x41, 0x42.. 이런 묶음이 코드값상으로는 한중일 통합 한자 내지 확장 A이다 보니.. -_-;;
이 버그는 보안 쪽 문제는 아니지만 그래도 사람을 성가시게 하는 문제인 관계로, 2000이던가 XP 즈음에 패치가 나와서 고쳐졌다.

Windows 9x에는 IsTextUnicode라는 함수 자체가 존재하지 않으니 9x 계열의 메모장이야 저런 문제가 존재할 여지조차 전혀 없었다.
끝으로, 메모장은 아마 Windows XP에서 '상태 표시줄'을 표시하는 옵션이 추가된 게 현재까지 외형상의 마지막 변화 사항이지 싶다. '자동 줄바꿈'을 사용하지 않을 때에 한해서 줄/칸 위치를 표시하는 깨알같은 기능이 추가된 것이다.

이런 Windows와 메모장의 유구한 역사 속에서 도스용 Windows 3.x 내지 NT 3~4의 메모장에는 '불필요한 공백'이 존재했었나 모르겠다.

Posted by 사무엘

도스와 유닉스 명령창 공히 디렉터리를 이동할 때는 cd 내지 chdir이라는 명령을 사용한다. 단, 도스는 드라이브 이름을 A~Z 알파벳 한 글자로 표현한다는 게 마치 날개셋의 수식 변수만큼이나 특이하며, Windows는 이 관행을 그대로 물려받았다. 파일명에 대소문자를 구분해서 표현은 하지만 유닉스와는 달리 이를 서로 다른 것으로 취급하지는 않는다. 또한 디렉터리 구분자가 /가 아니라 \(역슬래시)라는 것도 유닉스 계열과 다르다.

그 뿐만이 아니다. 도스는 cd라고만 치면 현재 디렉터리를 표시만 해 주는 반면, 유닉스는 cd라고 치면 그냥 자신의 홈 디렉터리, Windows로 치면 "C:\Users\계정명" 정도로 이동해 버린다. 도스가 유닉스의 다른 개념들은 다 따 왔어도, 이건 다중 사용자라는 개념이 없던 물건이다 보니 홈 디렉터리 같은 건 도입하지 않기 때문이다. 유닉스에서 지금 디렉터리를 표시하는 명령은 잘 알다시피 pwd라고 따로 있다.

그렇게 도스와 유닉스 계열이 차이가 나는 와중에도 . 가 현재 디렉터리를 의미하고 ..는 부모 디렉터리를 의미한다는 건 둘이 동일하다. cd ..를 하면 부모 디렉터리로 갈 수 있다. 다만, 문법이 둘이 완전히 동일한 건 아닌지라.. 도스는 cd..라고 둘을 띄지 않아도 됐던 반면, 유닉스는 둘을 띄워야 한다는 깨알같은 차이점이 또 있다.

그런데 Windows 9x의 도스창에서는 숨겨진 기능이 더 있었다. cd 다음에 점을 세 개 이상 늘어놓음으로써 두 단계 이상의 조부모 디렉터리로 이동이 가능했다. cd...처럼. 그럼 저건 cd ..\.. 를 의미한다. 네 개 이상 숫자를 얼마든지 늘어놓아도 된다.
게다가 이건 파일 시스템 차원에서 공식적으로 인식하기라도 하는지, 굳이 cd에서만 쓸 수 있는 게 아니다. dir ... 이라고 하면 두 단계 상위 디렉터리를 조회할 수 있고, Windows의 파일 열기/저장 대화상자에서도 "..."이라고 치면 동일 기능이 동작했다.

Windows 9x는 C:\Windows 디렉터리를 가 보면 readme 등 몇몇 '읽어 보세요' 문서가 html이나 doc나 rtf가 아니라 txt 파일로 들어 있었는데, 그 중엔 tips.txt가 있다. 그 파일에 cd...에 관한 언급이 존재한다.

위는 영문판 Windows ME, 아래는 한글판 Windows 95의 tips.txt 내용 일부이다.

이 기능은 이전의 도스 시절엔 존재한 적이 없었으며 Windows 95에서 처음으로 추가되었다는 것이 명시되어 있다. 또한 95의 문서에서는 ....로 디렉터리를 세 단계 건너뛰는 예를 제시하는 반면, 후대 98/ME의 문서는 ...로 두 단계만 건너뛰는 예를 제시한다. C:\로 바뀌는 건 cd\와 동일하기 때문에 예제를 바꾼 게 아닌가 싶다.
참고로 Windows의 한글판은 98부터 '디렉토리'라는 표기가 '디렉터리'로 바뀌고, 문서들의 문체가 반말에서 존댓말로 바뀌었다.

놀라운 사실은, 이 기능은 오늘날의 Windows NT 계열에서는 지원되거나 존재한 적이 전혀 없었고 오로지 95, 98, ME만의 관행이었다는 점이다.

The old new thing 블로그의 설명에 따르면 cd ...는 노벨 네트웨어(Novell NetWare)라는 네트워크 솔루션에서 제공하는 명령 문법과의 호환성 때문에 편의 차원에서 도입된 기능이라고 한다. 그땐 노벨 사의 IPX/SPX 프로토콜 기반으로 네트워크 구성요소들도 있었으니 수긍이 간다.

그리고 9x와 달리 NT에서 ...를 지원하지 않은 이유는, 윈NT가 사용하는 NTFS 파일 시스템에서는 '.'나 '..'와는 달리 '...'는 그 자체가 올바른 파일이나 디렉터리 이름이 될 수 있기 때문이다. 그렇기 때문에 NT 계열에서는 이런 기능을 앞으로 지원할 의향은 더욱 없다고 봐야 할 것이다. 그냥 cd..\..를 해야지, 약칭인 cd...는 IPX 프로토콜이 존재하던 Windows 9x 시절의 추억으로 old timer들에게 남을 것으로 보인다.

9x 시절에는 dir con\con이던가, '실행' 대화상자에서 con\con 이런 걸 치면 운영체제를 뻗게 하고 도스창을 강제 종료시키는 게 가능했다. 이건 꽤 유명한 버그였으며 ME에서야 보정을 통해 패치가 됐다. cd ...는 그것만큼이나 9x 시절에 파일 시스템과 관련해 흥미로운 고유 아이템 추억거리인 것 같다.

여담으로, 명령 프롬프트에서 공백은 여러 명령 인자 토큰들을 구분하는 역할을 한다. 그렇기 때문에 거기서 공백이 들어간 파일을 표시하기 위해서는 파일명 전체를 ""로 싸야 하며, 각종 프로그래밍 언어에는 따옴표 문맥을 인식하면서 공백 기준으로 명령 인자들을 파싱· 토큰화하는 라이브러리도 존재한다. 그러나 이 cd 명령만은 예외로 공백이 들어간 디렉터리도 CD Program Files 라고만 쳐도 인식되게 되어 있다. cd /?를 해 보면 이 사실을 확인할 수 있음.

그리고 cd에는 드라이브까지 같이 변경하는 명령이 한동안 존재하지 않았다. 도스 커맨드 셸의 대체제이던 4DOS 내지 NDOS에서는 자체적인 명령 확장을 통해서 그런 기능을 제공하곤 했는데, 오늘날 Windows에서는 /D 라는 별도의 옵션을 줘야만 드라이브도 변경 가능하다. 아마 드라이브를 변경하지 않는 게 보장된다는 무슨 호환성 때문에 옵션 형태로 기능을 추가한 것 같다. 참고로 /D는 9x의 도스창에는 존재하지 않으며, Windows NT 계열의 명령 프롬프트에만 있다. ...를 지원하지 않는 대신 /D가 있는 셈이다.

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 사무엘