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

Windows에서 메뉴, 리스트박스, 콤보박스처럼 세부 항목이 존재하는 고전적인 UI 컨트롤에는 기본 글꼴로 문자열을 찍는 기능뿐만 아니라 임의의 크기로 임의의 그림도 그리는 owner draw 기능이 있다. 한두 개 정도 특수하게 쓰이는 owner draw 기능이라면 해당 UI 컨트롤을 구동하는 대화상자 등 부모 윈도우에서 메시지를 받아서 처리한다.

그러나 매 아이템들마다 check box가 달린 리스트라든가, 트리 계층 구조를 owner draw 기능을 이용해서 얼추 구현한 리스트처럼.. 특정 owner draw 기능과 동작을 컴포넌트화해서 여러 곳에서 동시에 사용하고 싶다면 그 UI 컨트롤 자체가 개조 대상이 된다. 윈도우 프로시저를 서브클래싱한 후, owner draw 메시지를 부모 윈도우로부터 되받아서 자신이 직접 처리하면 된다. 이건 뭐 16비트 시절부터 존재해 온 아주 고전적인 Windows 프로그래밍 테크닉이다.

owner draw는 개념적으로 모든 아이템의 크기가 동일한 owner-draw fixed와, 각각의 아이템 크기가 모두 다를 수 있는 owner-draw variable이 존재하는데, 개인적으로 후자는 전혀 다뤄 본 적이 없다.

그리고 string 버퍼를 사용하는 owner-draw가 있고(LBS_HASSTRINGS 내지 CBS_HASSTRINGS 스타일), 그런 게 없는 owner-draw도 있다. 문자열의 옆에다가 아이콘 같은 걸 추가로 그리거나 문자열 자체를 좀 색다른 색깔과 폰트로 출력하기 위해서 owner-draw를 사용하는 것이라면 전자를 선택해야 할 것이고, 그게 아니라 완전히 생판 다른 그림만을 찍거나, 자체 버퍼에 있는 문자열을 직통으로 찍으려면 후자를 선택하면 된다.
문자열 없는 owner draw 리스트박스는 일일이 LB_ADDSTRING을 호출할 필요 없이 LB_SETCOUNT만으로 간단하게 아이템 수를 뻥튀기할 수도 있다.

owner draw 컨트롤이 동작을 시작하면 아이템을 손수 직접 그리라는 WM_DRAWITEM 메시지가 오기에 앞서, 그림을 그릴 영역을 정하기 위해 WM_MEASUREITEM 메시지가 부모 윈도우로 날아온다. 그런데 여기서 꽤 재미있는 동작 특성이 있다. WM_MEASUREITEM는 DRAWITEM과는 달리, 굉장히 일찍 날아온다. 대화상자의 경우, MEASUREITEM은 WM_INITDIALOG보다도 먼저 날아온다.

WM_INITDIALOG는 대화상자 내부의 모든 컨트롤들이 생성되었고 모든 준비가 완료되어서 대화상자가 화면에 표시되기 직전에 날아온다. 그러나 MEASUREITEM은 그렇게 내부 컨트롤이 생성될 때마다, WM_CREATE 타이밍에서 자신의 스타일에 owner draw 속성이 주어져 있으면 곧장 부모 윈도우로 전달된다고 생각하면 된다. 그러니 자기 주변의 다른 대화상자 컨트롤들이 다 생성되기도 전의 굉장히 이른 타이밍에 날아온다.

대화상자 윈도우(HWND)를 그에 상응하는 C++ 개체 같은 사용자 정의 오브젝트(LPARAM)와 연결하기 위해서는 CreateDialog나 DialogBox 같은 함수에다가 연결할 그 오브젝트 포인터를 넘겨주는 편이다. 그리고 HWND와 LPARAM이 실제로 만나는 타이밍이 WM_INITDIALOG이다. 즉, 이 메시지가 대화상자계에서 WM_CREATE나 마찬가지인 셈이다.

하지만 WM_MEASUREITEM은 이런 통상적인 초기화 메커니즘이 수행되기 전에 부모 윈도우로 호출된다. 그렇기 때문에 MFC 말고 자체적인 Windows API 프레임워크를 구현하고 있다면 이 메시지의 처리를 좀 특수하게 해 줄 필요가 있다.
리스트박스나 콤보박스가 좀 지연 초기화를 지원해서 대화상자의 초기화가 다 끝나고, 자기가 WM_PAINT를 받아서 화면에 그려지기 직전(WM_DRAWITEM)처럼 정말로 폭을 알아야 할 때에나 저런 메시지를 보냈으면 사용자가 UI 프로그래밍을 하기 약간 더 수월했을 텐데 싶은 아쉬운 생각이 좀 든다.

그리고 WM_MEASUREITEM의 도착 타이밍이 너무 일러서 부담된다면, 아이템의 폭을 꼭 이때 지정해 주지 않아도 된다. 뒤늦게라도 부모 윈도우에서 LB_SETITEMHEIGHT(리스트박스), CB_SETITEMHEIGHT(콤보박스) 메시지를 보내서 아이템 전체(ower-draw fixed), 또는 개별 아이템(owner-draw variable)의 폭을 지정해 줄 수 있다.
리스트박스의 경우 경험상 둘의 차이는 거의 없다. 콤보 박스는 WM_MEASUREITEM 메시지의 결과에 따라서 drop list 내부에서의 아이템 높이뿐만 아니라 한 줄짜리 자기 본체의 높이도 그에 맞춰 자동으로 조절되는 반면, CB_SETITEMHEIGHT 메시지는 그런 효과까지는 없다는 차이가 있다.

또한, 메뉴야 대화상자의 내부 컨트롤 같은 존재가 아니니 저런 대체제가 존재하지 않으며 owner-draw 메뉴 아이템의 폭을 지정하는 타이밍은 WM_MEASUREITEM밖에 선택의 여지가 없다. 딱히 MENUITEMINFO 같은 구조체에 자신의 높이를 지정하는 곳은 존재하지 않는다.

요즘 운영체제의 옵션에 따라서는 콤보 박스의 drop list가 튀어나올 때, 또는 메뉴가 출력될 때 바로 툭 튀어나오는 게 아니라 fade in으로 서서히 나타나거나 위-아래 내지 대각선 방향으로 슬라이딩 하듯이 튀어나오곤 한다. 이건 임의의 윈도우에 대해서 AnimateWindow라고 이런 애니메이션 효과를 구현해 주는 함수가 따로 있다.

그런데, 과거의 Windows 9x에서는 owner-draw 아이템이 들어있는 콤보박스나 메뉴에 대해서는 그런 애니메이션이 지원되지 않았다. 기본 스타일로 문자열을 출력하는 컨트롤만 애니메이션이 나오던 것이 2000/XP 같은 NT 계열에 와서야 owner-draw 방식의 컨트롤에 대해서도 동등하게 애니메이션이 지원되기 시작했다. 그림을 화면에다 바로 그리는 게 아니라 내부 버퍼 DC에다가 그려 놓고 그런 처리를 하게 된 듯하다.

참고로 AnimateWindow는 애니메이션 대상인 윈도우에다가 WM_PRINTCLIENT라고 좀 생소하게 생긴 메시지를 보낸다. 이것은 WM_PAINT와 비슷하게 창의 내용을 그리라는 메시지이지만, WM_PAINT 때와는 달리 BeginPaint나 EndPaint 호출이 필요하지 않다. invalid 영역이나 클리핑 처리 같은 개념도 없으며 주어진 DC에다가 언제나 윈도우 내용을 처음부터 끝까지 그려 주면 된다.

Posted by 사무엘

본인은 몇 년 전에 쓴 글을 통해 Windows API에서 비트맵을 출력할 때 사용하는 GDI API 몇 개를 브러시와 비트맵의 관계라는 관점에서 비교하고 살펴본 적이 있었다. 이번에는 픽셀 포맷과 DDB/DIB라는 관점에서 관련 API들과 이들의 특성을 살펴보도록 하겠다.

1.
먼저, 비트맵은 CPU의 관점에서 봤을 때 빅 엔디언 형태이다.
모노크롬 비트맵에서는 128, 64 같은 큰 비트 자리수가 왼쪽을 나타내고 작은 비트로 갈수록 오른쪽으로 간다.
색깔을 나타내는 RGB야 숫자의 대소 구분이 무의미하겠지만, 일단 RGB 매크로(메모리)에서의 색상 배열 순서와 RGBQUAD 구조체(파일 저장)에서의 색상 배열 순서는 서로 정반대이다. 전자는 R이 최하위 비트이지만 후자는 R이 최상위 비트이다. 그러니 여기서도 이념이 빅 엔디언임을 확인할 수 있다.

2.
일반적으로 비트맵 폰트 파일 내부의 비트맵들은 한 줄이 바이트 단위로 align이 돼 있다. 그러나 CreateBitmap 함수가 받아들이는 DDB(장치 종속 비트맵)는 역사적인 이유 때문인지, 한 줄이 2바이트, word 단위로 align돼 있어야 한다.
compatible bitmap이 아니라 CreateBitmap으로 직통으로 만들 수 있는 비트맵이 사실상 모노크롬밖에 없다는 점을 감안하면, 저기에 전달되는 가로 크기는 사실상 언제나 16의 배수 단위여야 한다.

한편, BMP 파일과 직통 대응하는 DIB(장치 독립 비트맵)는 이런 제약이 더 커져서 한 줄이 4바이트 단위로 align돼 있어야 하며, 얘는 또 상하가 뒤집혀 있기까지 하다. y축 양수가 위로 올라가는 좌표계를 염두에 뒀기 때문이다. DIB를 취급하는 함수들은 다 이런 형태의 비트맵을 입력으로 받는다.

3.
Create(Compatible)Bitmap 함수로 만들어진 비트맵은 성능이 가장 좋고 속도가 빠르지만, 한번 초기화한 뒤에 내부 비트맵 메모리에 직접 저수준 접근을 할 수 없다. GetDIBits 같은 함수로 내부 메모리 컨텐츠에 대한 복사본만을 얻을 수 있을 뿐이며, 이 내부 메모리는 철저하게 장치 종속적이다. 즉, portable하지 않다. 컨텐츠를 조작하는 건 BitBlt 같은 타GDI 함수를 써서 해야 한다.

비트맵을 출력하는 다른 함수로는 SetDIBitsToDevice가 있다. 얘는 받는 인자가 많고 사용이 좀 복잡하긴 하지만, BitBlt와는 정반대로 그냥 아무 메모리가 가리키는 임의의 BMP 헤더와 컨텐츠를 통째로 받아서 그 내용을 화면에다 찍어 준다. 원본 비트맵에 대해서 뭐 메모리 DC 만들고 비트맵 만들고 SelectObject 할 필요가 없으며, 메모리에 직통으로 접근해서 픽셀, 팔레트 테이블, 크기 따위의 수정도 얼마든지 가능해서 매우 좋다.

하지만 BMP 헤더를 매번 해석해서 DIB를 DDB로 변환해서 찍을 준비를 해야 하기 때문에 이 함수는 비트맵을 뿌리는 속도가 DDB 전용 함수만치 빠르지는 않다. 구형 운영체제의 16/256색 구닥다리 비디오 환경에서는 성능 열화의 폭이 더욱 크다.

그런데 알고 보니 저 둘의 중간 역할을 하는 함수도 있다.
CreateDIBSection은 내부적으로 반쯤 DIB로 취급되는 HBITMAP을 되돌린다. 이 비트맵을 사용하기 위해서는 BitBlt를 쓸 때처럼 원본 메모리 DC를 만들고 SelectObject를 해 줘야 한다. 하지만 픽셀을 직접 조작할 수 있는 메모리 포인터도 되돌리기 때문에 이를 응용 프로그램이 사용 가능하다.

이 메모리는 운영체제가 내부적으로 직접 할당해서 준 것이다. SetDIB*처럼 아무 메모리에 있는 비트맵을 찍을 수 있는 게 아니며, 그림의 크기나 색상 수 같은 헤더 정보는 한번 정해진 뒤에 변경 가능하지 않다. (그게 달라진다면 그냥 비트맵을 새로 만들어야..) 단지 픽셀 데이터에만 접근 가능하며, 색깔 변경은 SetDIBColorTable라는 별도의 함수로 해야 한다.

하지만 픽셀 데이터에 직접 접근과 조작이 가능한 것만 해도 어디냐. 기존 HBITMAP의 특성은 다 가지고 있기 때문에 BitBlt, DrawText, LineTo 같은 GDI 함수들을 고스란히 사용하면서 그림이 그려진 결과를 메모리 포인터 레벨에서 바로 확인 가능하니 실로 놀라운 일이 아닐 수 없다. 이런 DIB의 특성을 반쯤 가지면서 비트맵을 뿌리는 성능도 SetDIB*보다는 약간 더 좋다.

지금까지 얘기했던 이 세 가지 API를 표로 정리하면 다음과 같이 요약된다.

* 참고로, CreateDIBitmap은 DIB 함수들처럼 BMP 헤더를 인자로 받긴 하지만, HDC까지 인자로 받아서 DIB를 완전히 DDB 형태로 변환해 버린다. 이 함수를 통해 생성된 HBITMAP은 외부에서 내용 수정이 가능하지 않다.

* 그리고 HBITMAP의 내부 컨텐츠를 얻어 오는 함수로 GetDIBits 말고 GetBitmapBits도 있는데, 얘는 그냥 레거시 잔재이다. BITMAPINFO 헤더 정보를 받는 부분이 없기 때문에 그냥 모노크롬 비트맵 데이터를 얻을 때나 쓰는 간소화 버전이라고 생각하면 된다.

예전에 Windows 95부터 2000/ME까지는 시스템 종료 명령을 내리면 화면 전체에 50% 검은 음영 픽셀이 깔리면서 시스템 종료, 재시작 같은 세부 기능을 선택하는 대화상자가 떴다. 지금은 그런 효과는 관리자 권한을 요청하는 UAC 확인 대화상자가 뜰 때에나 그렇게 배경이 어두워질 텐데 그때는 시스템 종료 대화상자가 그 비주얼 이펙트 역할을 담당했다. (XP에서는 그 효과가 "흑백으로 서서히 fade out"이라는 더 화려한 형태로 바뀌었다가, 후대 버전부터는 이펙트가 사라졌다.)

그런데.. 그렇게 50% 검은 음영을 뿌리는 게 바로 래스터 오퍼레이션을 가미한 BitBlt 내지 PatBlt 실행으로 구현되었다. 최신(당대 기준) 그래픽 카드에서야 즉시 전체 화면에 음영 뿌려졌겠지만, 하드웨어 가속 없이 640*480 VGA 내지 그에 준하는 구린 그래픽 환경에서는 음영이 위에서 아래로 뿌려지는 게 눈으로 보일 정도로 속도가 느렸다. 그건 나름 수십만 개에 달하는 픽셀이 바뀌는 거니까..

그리고 그게 바로.. 그 컴퓨터에서 BitBlt 함수로 화면을 가득 채우는 속도와 같다 생각하면 된다. 그때는 이 따위 느린 그래픽 함수로는 답이 없으니, Windows에서 게임을 돌리려면 발상의 전환을 달리한 DirectX 같은 API를 만들어야겠다는 생각을 응당 안 할 수 없었을 것이다. 하드웨어 계층 추상화+통합이 아니라, 하드웨어 직통 제어를 지원하게 말이다.

DirectX 쪽 그래픽 프로그래밍이 재래식 GDI 그래픽 프로그래밍과 다른 점은..

• 하드웨어의 발전에 따라 프로그래밍 방법론의 변화 기복이 매우 큼.
• 하려는 일(도형 그리기, 글자 찍기..)보다는 그래픽 하드웨어의 기능 위주로 API가 설계돼 있다. 사실, 이걸 수용하라고 애초부터 이념이 이런 식인 API를 따로 만든 거다.
• 이런 이유로 인해, GDI처럼 프린터, 플로터, 메타파일 같은 디바이스까지 다 통합하는 추상화 계층 건 전혀 안중에 없음. 오로지 화면 아니면 화면 출력용 메모리 버퍼 위주이다.
• BeginPaint/EndPaint로 대표되는 invalid 영역 그딴 개념이 없고, 그 대신 '서피스 소실'이라는 개념이 존재한다.
  

정도로 요약되겠다.
예전에는 GDI와는 완전히 다른 기술 계층을 거쳤기 때문에 화면 캡처도 특수한 프로그램을 써서 했을 정도이지만 이제는 그런 유별난 점이 점점 없어지고 통합돼 가고 있는 것도 인상적이다.

Posted by 사무엘

C/C++, 자바, 파이썬 등 프로그래밍 언어를 하나 배워서 초보 딱지를 뗄 정도가 되면, 프로그래밍을 할 줄 모르던 때보다 컴퓨터를 훨씬 더 유용하고 창의적으로 활용할 수 있게 된다. 초보 딱지를 뗐다는 건 한 변수로부터 복수 개 + 다중 계층 형태로 된 숫자나 문자열에 접근하는 '복합 자료형(composite type)'을 다룰 수 있고, 함수와 반복문과 재귀호출로 반복 절차를 구현할 수 있음을 의미한다. 거기에다 Windows API에 대한 약간의 지식이 필요하다.

뭐, C/C++보다 더 고수준 언어를 쓴다면 날포인터(raw pointer)를 써서 수동 메모리 관리까지 직접 다룰 일은 없겠지만, 거기는 거기 고유한 방식으로 리스트나 시퀀스처럼 복합 자료형을 제공하는 게 있을 것이다. 복합 자료형과 실행 시간 조건부 반복 및 분기가 튜링 완전한 계산 모델의 본질이며, 자연어로 치면 그냥 Hello world나 I am a boy를 넘어서 길고 복잡한 안은 문장과 이어진 문장을 자유자재로 구사하는 것과 같다.

모든 사람이 전산학과 코딩을 전공으로 삼아 생업 수준으로까지 할 필요는 전혀 없다. 굳이 번듯한 GUI 갖추고 제3자가 쓸 만한 번듯한 소프트웨어를 개발하는 경지에 이르지는 않아도 된다. 그냥 일상생활에서 내가 당면한 문제를 코딩으로 스스로 해결하는 '자가용' 프로그래밍 스킬만으로 충분하다. 원하는 웹사이트 내용을 크롤링 해서 텍스트를 추출하거나, 방대한 무슨 데이터 파일을 내 입맛에 맞게 변환· 가공하거나, 특정 시간대에나 주기적으로 컴퓨터로 하여금 특정 작업을 수행하게 하는 게 대표적인 예이다.

물론 프로그래밍을 공부하는 대신, 그런 일을 수행해 주는 유틸리티(특히 매크로 같은..)를 찾아서 사용법을 익히는 것도 방법이 될 수 있다. 그러나 본인의 경우는 간단한 건 그냥 직접 만들어 쓴다. 그게 더 빠르다.
옛날 직장에 다니던 시절엔 이튿날 아침 9시 3분 전에 회사 인트라넷에 접속해서 출근 도장을 자동으로 찍게 하는 프로그램을 짜 놓고 퇴근 후, 정작 나는 다음날 느긋하게 출근하기도 했었다. 이 정도 잔머리야 뭐 직업 프로그래머라면 완전 껌(piece of cake)일 것이고, 반대로 회사에서 작정하고 오토의 부정 사용을 단속하려 한다면 키보드 드라이버 차원의 보안 프로그램들로 직원들의 컴을 도배시켜 놓겠지만 말이다.

잡다한 서론이 좀 길어졌으니 본론으로 들어가도록 하겠다. 컴퓨터 프로그래밍에는 저렇게 고정된 입력에 대해서 언제나 고정된 답만 출력하는 작업 말고 의외로 재미있고 유용한 분야가 있는데, 바로 난수(random number) 생성을 이용한 시뮬레이션, 무작위 표본 추출 등이다.

이 글은 난수 생성 방법 자체에 대해 다루지는 않을 것이다. 그래도 말이 나왔으니 잠시 언급하자면, 난수란 그 정의상 등장 패턴을 예측할 수 없으면서(혹은, 몹시 어렵고) 각 숫자들의 등장 빈도에 치우침이 없어야 할 것이다. 파이나 자연상수 같은 유명한 무리수가 파면 팔수록 끝없이 생성하는 소수점들은 난수의 범주에 든다고 볼 수 있으려나 모르겠다.

품질 좋은 난수를 값싸고 빠르게 많이 생성하는 알고리즘에 대한 수요는 매우 많으며, 이건 정수와 관련된 응용 수학에서 매우 중요하게 다뤄지는 분야이다. 옛날에 CACM에서 Random numbers: good ones are hard to find라는 논문을 봤던 기억이 나는데... 거기는 그 정도 퀄리티의 논문이 그야말로 상상도 할 수 없을 정도로 옛날에(1988년!) 이미 게재되었다는 게 전율이 느껴진다.
시뮬레이션도 좋고 각종 게임도 좋지만 추첨 역시 단순 유흥이 아니라 그야말로 사람의 인생과 진로를 결정하는 매우 사무적이고 크리티컬한 분야에 쓰인다.

추첨의 가장 간단한 형태는 A명의 사람에게 B개의 물건을 무작위로 배분하거나(단, A>B) 그냥 B명을 무작위로 답정너 선발하는 것이다. 그리고 이를 일반화하면 단순히 "당첨 B개 vs 꽝 A-B개"라는 이분법적인 상태를 넘어서 3개 이상의 상태를 배분하는 것도 생각할 수 있다.
이런 추첨을 종이와 연필만으로 수행하는 대중적인 방법 중 하나는 사다리 게임이다. 이 정도 추첨이야 언제 어디서든 필요할 때 하라고 사다리를 무작위로 생성해 주는 스마트폰 앱도 진작에 나와 있다.

그러나 현실에서는 이보다 더 복잡한 조건을 주고 추첨을 해야 할 때도 있다. 조 추첨이 대표적인 예인데, 각 조별로 인원과 성별이 비록 조의 수로 나눠 떨어지지 않더라도 최대한 균일하게 유지돼야 하며, 그 밖에 구성원들별로 다른 내부 속성도 최대한 균일하게 유지돼야 한다.
본인은 고등학교 시절에 반 내지 학교 행사 때 테이블별 인원 추첨을 컴퓨터 프로그램을 짜서 실시한 적이 있다. 하긴, 반 편성 자체도 일단 컴퓨터가 뒤섞어 놓은 결과에다가 각 반 담임들이 보정을 해서 뽑는다고 들었다. 가령, 문제아들은 한 반에 몰리지 않고 최대한 서로 다른 반에 찢어지게 말이다.

그 뒤 본인은 최근에는 교회 청년부의 소그룹 기도 모임의 인원을 분기별로 새로 추첨해 주는 프로그램을 작성했다.
이 역시 기본적으로 조별 인원과 성별부터 균등하게 맞추지만, 거기에다가 모임에 활발히 참여하는 사람과 그렇지 않은 사람도 나눠서 특정 성향의 사람이 한 조에 너무 몰리지 않고 최대한 분산되게 하는 조건을 추가했다.
그리고 또 중요한 것으로, 동일 집안의 친형제· 친자매· 친남매는 같은 조에 결코 걸리지 않게 했다. 흥미롭지 않은가?

처음에 인원과 성별은 무조건 균등하게 나오게 틀을 먼저 짜서 했다. 그러나 나머지 필터링은 알고리즘으로 구현한 게 아니라 무식한 방법을 썼다. 추첨 결과가 조건을 전체 만족하는지 검사해서 안 그러면 그냥 빠꾸 시키고 될 때까지 추첨을 다시 한다. 그러니 이건 프로그램의 실행 종료와 성공 여부를 전적으로 난수 생성 알고리즘의 품질에다 맡기는 셈이다.

물론 이렇게만 해도 소규모 인원의 조편성 결과쯤이야 운이 나빠 봤자 몇십 번 정도 뺑뺑이 만에 답이 즉시 잘 튀어나온다. 허나, 진지한 프로그램이라면 추첨 결과에 anomaly가 존재하면 조의 인원을 무작위하게, 적절하게 교환하고 보정을 해서 그걸 해소해야 할 것이다. 난수 생성 결과와 무관하게 수행이 유한 시간 만에 끝난다는 게 보장되는 알고리즘으로 말이다.

더 나아가면 이렇게 추첨이라는 computation을 위한 범용적인 '로직 선언형 프로그래밍 언어'를 생각할 수 있을 것 같다. 어찌 보면 SQL처럼 select A from B where 같은 문법 구조를 가질 수도 있겠다. 10명의 인원에다 무엇을 배당하되 무엇과 무엇에는 무엇이 같아서는 안 되고..
마치 "A와 B의 사이에는 C가 있지 않다. C의 오른쪽에는 D가 있다." 이런 단서들 주고 나서 "A~D의 가능한 정렬 순서는 무엇인가?" 이런 문제를 풀듯이 추첨 조건을 쫙 명시할 수 있다.

모든 조건의 충족이 불가능하다면 무식하게 무한 루프에 빠지는 게 아니라 저 조건들만 분석해 보고는 일찌감치 "성립 불가능, 답 없음"이라고 에러가 깔끔하게 튀어나와야 한다.
조건들 중에는 일단 추첨 뒤에 사후 보정을 해야 하는 것도 있겠지만, 여러 가지 속성 변수들을 균등하게 분할하는 것은 변수의 개수만큼 n차원 공간을 만들어서 거기에다가 차곡차곡 무작위로 숫자들을 채워 넣는 선형대수학 같은 방법론을 동원해서 구현할 수도 있을 것 같다. 아무튼 추첨· 배분과 관련된 수학 패키지나 프로그래밍 언어 솔루션이 있는지 궁금하다.

그리고 다음으로.. 컴퓨터 추첨은 추첨 알고리즘에 인위적인 조작이 없다는 걸 어떻게 보장하느냐고 결과에 대한 불신이 있을 수 있다.
이걸 해소하기 위해서는 제3자 참관인을 두는 게 바람직할 듯하다. 그래서 1부터 N회 중 가추첨을 몇 번 할지를 결정하게 한 뒤, 그 횟수를 공언한다. 그리고 그 횟수만큼 그 사람이 실제로 추첨을 돌리고 N회째의 결과를 최종 결과물로 선택하는 것이 모두에게 공정할 것 같다.

프로그램을 개발하는 사람 입장에서는 몇 회째에 조작된 결과를 내놓아야 할지 알 수 없으며, 참관인은 자기가 원하는 추첨 결과가 나왔을 때가 아니라, 먼저 약속했던 횟수만큼만 가추첨을 돌리다가 최종 결과에는 승복해야 한다. 그리고 가추첨의 결과도 계속 공개되므로 각 가추첨의 결과가 충분히 무작위하지 않고 이상하다면 이의 제기가 가능하다.

빵 같은 걸 두 사람이 먹게 반으로 나눌 때, 한 사람은 칼로 빵을 나누고 다른 한 사람은 나눠진 결과물 중 원하는 것(= 더 큰 것)을 취사선택하게 한다면 그야말로 두 사람이 모두 만족하는 결과가 나올 수밖에 없을 것이다. 이와 비슷한 시스템을 구현하는 것으로 논란을 잠재우는 게 합리적이어 보인다.

Posted by 사무엘

1. 나랏말씀

이런 프로그램이 과거에 개발되어 나왔다는 것을 머리로는 알고 있었지만, 인터넷에 굴러다니는 걸 구해서 도스박스에서 개인적으로 직접 돌려 본 건 굉장히 최근의 일이었다.
얘는 개발 목표와 이념이 완전히 일치하는 건 아니지만, 어찌 보면 날개셋 편집기의 먼 조상뻘 되는 프로그램이라 해도 과언이 아니다.

그리고 얘는 시대를 굉장히 앞서 갔던 프로그램이다. 1993~94년 사이에 개발됐는데 무려 유니코드 1.1 방식 옛한글을 세벌식 글자판과 글꼴로 입· 출력하는 텍스트 에디터이기 때문이다. 비록 에디터로서의 기능은 매우 빈약하고(찾기 기능도 없다!) 글자 모양도 심히 열악하지만 그래도 모아쓰기 출력과 글자 단위 cursor 이동 같은 최소한의 처리는 옳게 지원된다.

예문으로 훈민정음 서문이 포함돼 있다. 방점도 자형 자체는 있지만 오늘날 OpenType 규격처럼 글자의 뒤에다가 쳐 넣으면 글자의 왼쪽에다 알아서 찍어 주지는 않는다.

그 옛날에 국내에서는 겨우 2바이트 조합형이니 완성형이니 하면서 논쟁이 진행 중이었을 뿐, 유니코드를 아는 사람은 일부 극소수 계층 말고는 없었다. 대다수 사람들에게 유니코드는 최소한 2.0이 제정되고 나서 Windows 98 이후의 시간대는 돼서야 갑자기 툭 튀어나온 물건이다.

하물며 지금 같은 인터넷도 없고 "유니코드가 뭐야? 먹는 거야? 주변에 지원하는 프로그램도 아무것도 없구만?" 이러던 초창기였으니.. 이 프로그램은 서식이나 레이아웃 기능이 없는 텍스트 에디터임에도 불구하고 저장한 파일을 읽을 수 있는 프로그램이 사실상 자기 자신밖에 없었다.

이건 평범하게 터보 C 공부한 어느 똑똑한 대학생이 뚝딱 만들어서 PC 통신에다 올릴 만한 물건은 아니고, 사실은 부산 대학교 김 경석 교수 연구실에서 개발해서 배포한 프로그램이다. 지도교수는 그 당시 유니코드 위원회의 우리나라 대표였고, 동료 학자들과 함께(아마 국어학자들과도..) 문헌을 뒤져서 옛한글 자모들을 선별했으며 <컴퓨터 속의 한글 이야기>라는 책을 쓰기도 했다. 이 프로그램은 그 책의 부록 디스켓에 포함돼 있다.

물론, 프로그램의 실제 개발은 제자인 대학원생이 했다. 프로그램 개발자들은 다들 부족한 시간과 여건 속에서 코딩을 하는 편인데, 이 프로그램은 의외로 화면 비주얼은 신경을 썼는지 VGA 기본 팔레트가 아니라 연보라색 계열의 자체 색상을 쓰고 있다.

완성된 글자들의 모양은 볼품없지만, 이미 찍힌 낱자의 모양이 입력 도중에 다른 성분의 낱자에 의해 바뀌지 않기 때문에 뭔가 타자기를 쓰는 것 같다. 세벌식 글자판에다 세벌식 글꼴의 묘미를 제대로 경험할 수 있다. 더구나 이 프로그램에서 최초로 채택한 '세벌식 옛한글' 글쇠배열은 오늘날까지 아래아한글이나 날개셋이 그대로 계승하고 있기도 하다.

유니코드 1.1 옛한글 자모 집합은 그 전 1992년에 발표된 아래아한글 2.0이 사용하는 한컴 2바이트 코드에도 반영된 바 있다. 하지만 아래아한글은 아직 2바이트 완조형에 묶여 있었기 때문에 옛한글의 표현 능력이 온전하지 못했다.

굉장히 의외의 사실인데, 이 프로그램은 텍스트를 빅 엔디언 방식으로 저장한다. 다시 말해 UTF-16BE라는 것이다. LE가 아니라. (물론 저 당시에는 UTF라는 계층은 존재하지 않았기 때문에 UCS2만 있음)
저기서 입력하고 저장한 텍스트는 MS Word처럼 UTF-16BE를 지원하는 소수의 프로그램에서 인코딩을 수동으로 지정해 줘서 연 뒤, 날개셋 편집기에서 한글 형태 정규화를 해 줘야 오늘날 통용 가능한 텍스트 형태로 바뀐다. 저 프로그램이 개발되던 시절에는 지금 같은 U+AC00으로 시작하는 현대 한글 글자마디 11172자가 아직 없었다. byte order mark 같은 것도 없었다.

한편, 나랏말씀은 옛날에 만들어진 프로그램이지만 문서 저장 확인 질문의 Yes/No가 "예/아니오"가 아니라 "예/아니요"인 게 인상적이었다. 그 시절에 본인은 '아니요'를 그 어떤 프로그램의 UI에서도 보지 못했다. 표준어가 나중에 개정되기라고 했나 싶었는데, 그건 아니고 '아니오'가 오랫동안 컴퓨터 프로그램들 사이에서 잘못 내려온 관행이라고 한다.
아래아한글은 2002부터, Windows은 Vista부터 '아니요'로 바뀌었다. 단, 요즘 프로그램들은 대답 자체에 '저장함/저장 안 함'처럼 동작을 일일이 집어넣는 게 대세가 되어 가다 보니 간단한 "예/아니요"를 볼 일이 예전보다 드물어져 있다.

나랏말씀 같은 프로그램이 있다는 걸 내가 더 일찍 알았으면 날개셋 한글 입력기도 한컴 2바이트 코드 같은 걸 거칠 필요 없이, 3.x보다 더 이른 1이나 2.x 버전부터 유니코드 옛한글 기반으로 개발됐을지 모르겠다.
내 프로그램이 1990년대 초· 중반에 개발돼 나왔으면 도스를 겨냥해서 자체한글 텍스트 에디터(편집기) 내지 도스용 한글 바이오스(외부 모듈), 혹은 간단한 램 상주 키보드 훅킹 유틸(입력 패드) 형태로 나왔지 싶다. 흥미로운 상상이 아닐 수 없다. 아예 한글 Windows용 3rd-party IME나 영문 Windows를 통째로 한글화하는 시스템은 만들기 너무 어려웠을 것 같고.

비록 내 프로그램은 기본적인 한글 입출력 인프라는 운영체제 차원에서 다 갖춰지고 보장된 뒤에야 개발되어 나왔지만, 그래도 기성 IME들이 지원하지 않는 기능들이 매우 많으며 구현체 차원에서도 Windows IME의 온갖 지저분한 꼼수 동작들을 이 정도로 보정하는 3rd-party IME라는 존재 역할을 수행하고 있다.

2. 신의손

본인은 한글 IME/텍스트 에디터뿐만 아니라 고유한 타자연습 프로그램도 개발하고 지금까지 유지보수 중이다.
타자연습을 처음 개발하던 시절에는 당연히 그 당시 국내에 이미 나와 있던 다른 타자연습 프로그램들을 먼저 쭉 살펴보면서 벤치마킹을 했다.

그런데 그 중 압도적으로 높은 완성도로 제일 잘 만들어진 프로그램을 꼽자면.. 단연 '신의손'이었다. 지금까지도 이 생각은 변함없다.
20년 전 하이텔 게임 제작 동호회 공모전에서 '삭제되었수다'가 혼자 튀면서 압도적인 1등을 했듯이, 타자연습 프로그램 중에서는 신의손이 지존이었다고 개인적으로 생각한다.
상업용 내지 셰어웨어로 만들어도 됐을 퀄리티였다.

디자이너가 따로 없이 1인 개발자의 해골만으로 VGA 16색에서 어지간한 게임에 준하는 저 정도의 미려한 그래픽과 UI를 만든 거라면 정말 보통 실력이 아니다.
게임도 스토리나 설정 같은 게 센스가 철철 넘지고.. (신 중의 신 고무신 ㄲㄲㄲ)
내 경험상 16컬러에서 팔레트를 자체적으로 조작해서 자기만의 독자적인 색깔톤을 만들 정도의 프로그램이라면 비주얼에 신경을 꽤 쓴 프로그램이다. 예전의 도스용 Packard Bell desktop 셸처럼 말이다.

(보통은 저런 파란 톤이지만 최고 어려운 마지막 난이도에서는 화면이 전반적으로 시뻘건 톤으로 바뀐다. 우와~!)
도스용이지만 그래도 나온 때가 1995년이다 보니, 보다시피 Windows에서 그 퍼런 키보드 배경 그림(95에서만 존재하던!)과 각종 아이콘과 굴림체 글자를 따서 도스용 프로그램에다 접목한 것도 꽤 독특한 분위기를 만들어 냈다.
식상한 윗줄 따라 치기 말고 좌우/상하 대조 같은 연습 방식을 도입한 것도 얘가 원조였지 싶다.

손가락 모양의 포인터로 각종 버튼과 UI 요소들을 선택하는 GUI 비주얼을 자랑하면서 정작 마우스를 지원하지 않은 건 조금 의외였다. 허나, 키보드 뚜드리는 연습만 하라고 만들어진 프로그램이 굳이 마우스까지 지원할 필요는 없긴 하지..

신의손의 개발자는 백 승찬 씨로 알려져 있다. ('신자'이신 분은 옹기장이 백 승남 씨와 혼동하지 말 것.)
이분은 정말 진지하게 게임 개발자로 가도 되지 않을까 생각했는데..
근황을 검색해 보니.. 아아~ P2P 유틸인 프루나도 만들었으며 2010년대부터는 이미 모바일로 전향하여 어썸노트라는 앱을 개발해서 여전히 1인 기업 하고 계신다.

신의손은 그냥 대학교 재학 시절에 만든 것인데, 그 프로그램을 상업용으로 판매하려고 유통처를 알아보고 고생도 했다고 한다. (그러나 현실적인 한계에 부딪혀서 실제로 하지는 못했음)
내가 겨우 날개셋 2.x 갖고 깨작거리던 나이 때 벌써 저런 프로그램을 만들 정도였으니 지금은 뭘 못하겠냐..;;
나는 17년 전이나 지금이나 최소한 플랫폼과 외형은 진~짜 바뀐 거 없는 투박하고 공대감성 충만한 프로그램만 죽어라고 파고 있는걸. ㄲㄲㄲㄲㄲ

세상 참 많이도 바뀌었다. 창의적인 일을 하는 모든 분들에게서 경외감을 느끼는 하루이다.

그러고 보니 옛날 프로그램들 중에는 메뉴를 열어 놓은 상태에서도 단축키가 곧장 동작하는 것들이 있었다. 당장 떠오르는 예는 도스용 아래아한글, PowerBasic IDE처럼.
Windows의 기본 UI는 구조적으로 이게 전혀 지원되지 않고 그 대신 메뉴 자체의 액셀러레이터만이 동작하게 돼 있다.
어디서든이 단축키가 동작하는 게 편하긴 한데 그래도 지금은 바뀐 프로그램에 사용자가 적응해야 할 때이긴 하다.

Posted by 사무엘

1. 트리플

• 저그 해처리 레어 하이브 : 학사 석사 박사
• 워드 엑셀 파워포인트 : 서울 지하철 1호선 2호선 3호선 (힌트: 색깔의 유사성)
• 크레용-크레파스-파스텔 : 짜장면-짜파게티-스파게티
• 레코드 SP EP LP : 그래픽 카드 CGA EGA VGA =_=;;

세상에는 3개로 이뤄진 진영이 속성이 서로 다 동일하거나 제각기 다 다른 경우가 있다.
스타크래프트의 플토, 테란, 저그가 좋은 예이다. 미네랄과 가스, 서플라이를 사용하며 기본적인 공방 업그레이드가 3단계씩 있는 건 공통이지만, 건물을 짓는 방식이나 각종 스킬 같은 건 전부 제각기 다르다. 두 종족은 완전 공통인데 한 종족만 다른 경우는... 일단 없다.

요런 체계를 모델링한 세트(Set)라는 아주 재미있는 머리 싸움 보드 게임도 있다. 4가지 속성(색깔, 도형 개수, 채움 패턴, 도형 모양)이 전부 같거나 전부 다른 카드 트리플을 빨리 찾는 게 목적이다. n개의 카드가 있을 때 세트가 하나라도 존재할 확률 내지 전혀 존재하지 않을 확률도 구할 수 있을 텐데 내 수학 지식으로는 모르겠다.

필기 내지 그리기 도구로서 색연필-크레용-크레파스-파스텔-콩테로 갈수록 특성이 어떻게 달라지나 모르겠다. 파스텔은 그냥 딱딱한 분필 같고, 크레파스는 왁스가 들어가서 그런지 좀 끈적거렸던 것 같다.
콩테나 목탄 같은 건 본 적 없다. 목탄화는 <플란다스의 개>의 주인공이 화가 지망생이라 쓰던 물건이라는 것 정도만 알고 있다.

2. 트윈

• 지하철역 중에서 종로3가와 종로5가는 영락없이 삼겹살과 오겹살을 떠올리게 한다. -_-
• 농사에 비닐하우스가 있다면, 야구에는 돔구장이 있는 듯..
• 서울 강북에 청와대 뒷산인 북악산이 있다면 강남에는 국정원 뒷산인 대모산이 있다. 그리고 강북에 거대한 군사 시설인 용산 미군 기지가 있다면, 강남에는 국군정보사가 있어서 서초대로에 길이 끊겨 있고 gap이 존재한다. 서로 비슷한 심상이 느껴지는데, 얘들은 가까운 미래에 서울 밖으로 이전할 계획이 잡혀 있다.
• 스타크래프트에나 있어야 할 옵티컬 플레어의 실사판: 공중으로 쏘는 레이저 포인터(특히 녹색), 육지 자동차에는 HID 불법 개조.
  

크리스천들이 하나님에 대해서는 그분이 우리가 원하는 것을 주시는 게 아니라 우리에게 "필요한" 것, 우리에게 유익한 것을 주신다고 믿는다.
허나, 사람에 대해서는 능력껏 벌어서 "필요한" 만큼 가져가는 세상은 필연적으로 다같이 망하고 거지 되는 세상을 부른다.
이것이 신과 인간에 대해서 '필요'라는 개념이 작용하는 방식의 차이점이다. 이건 성악설이 성립하는 한 반박 불가능할 것이다.

그리고 한편, 컴퓨터와 관련해서는..

• 옛날에 컴퓨터를 다루던 사람들은 디스크의 배드 섹터를 걱정했지만 요즘 사람들은 모니터의 불량 화소를 신경 쓰는 듯하다.
• 옛날 사람들은 컴퓨터를 오래 쓰면 Windows 3.x 내지 9x의 리소스 퍼센티지가 줄어드는 걸 보고 바싹 긴장했지만, 요즘 사람들은 스마트폰의 배터리 퍼센티지가 줄어드는 걸 보고 바싹 긴장한다.

3. 부정적인 예

• C++ 템플릿의 문제(소스 코드가 노출된 채 모든 번역 단위에 매번 인클루드 돼야 함)를 해결하려고 고민했는데 기껏 나온 게 export
• 남북이 통일하랬더니 기껏 나온 게 고려연방제 (1국가 2체제.. 그냥 전쟁만 없는 반쯤 적화통일)
• ActiveX를 없애라고 하자 나온 게 EXE 프로그램

이들이 무슨 공통점이 있는지는 설명이 필요하지 않을 것이다. 본질적인 문제는 전혀 해결하지 않은 채 그냥 눈 가리고 아웅일 뿐이다.

4. 긍정적인 예

• 건축업계· 학계에서는 '철근 + 콘크리트'가 신이 건축· 재료공학계에 내린 천혜의 재료 궁합이라고 그런다. 열팽창 계수가 거의 같아서 혼합 가능하면서도 서로 장점을 부각시키고 단점은 보완하면서 최고의 건축 자재 역할을 하기 때문이다.
• 항공업계에서는 하필 여객기의 최적 순항 고도에 제트 기류라는 게 존재하는 게 기적적인 행운이라고 한다.
• 1970년대에 인류가 우주 개발을 하고 있을 때 마침 태양계 행성들이 가까이 일렬로 배열돼 있어서 보이저 2호는 단독으로 천왕성과 해왕성을 동시에 탐사하는 대박을 경험할 수 있었다. 이것도 못해도 백수십 년 만에 한 번 찾아오는 기회였다고 그런다.

이런 예가 더 있을지 궁금하다. 혹시 반도체를 만드는 데에도 무슨 천혜의 자연 광물 특성이 활용되는 게 있지 않을까?

5. 예상치 못한 대박

예전에 교통수단 관련 글을 쓰면서 한 번씩 언급한 적이 있는 내용이긴 하지만 복습 차원에서..

• 서울 지하철 9호선은 잠재적 수요를 인정받은 덕분에 서울 3기 지하철 중 거의 유일하게 얘 혼자만 노선 계획이 온전히 살아남아서 건설되고 개통되었다. 그런데 한편으로는 국가에서는 이거 만들어 봤자 지상의 올림픽대로를 달리는 자동차들의 적수가 못 될 것이고 공기수송 적자이면 어쩌나 지금의 입장에서는 참 쓸데없는 걱정을 했다. 그래서 전동차도 달랑 4량으로 편성하고, 최대한 메리트를 끌어올리려고 급행도 만들었다. 그랬는데, 실제로 뚜껑을 열어 보니 9호선은 초대박을 쳐서 최악의 가축수송 혼잡도를 보이는 노선이 됐다.
• 지난 1960년대 말, 보잉 사에서는 유럽에서 초음속 여객기 콩코드가 개발되는 걸 예의주시하면서 "이거 초음속 여객기가 대박을 치면 어쩌나" 생각을 했다. 그래서 자기들도 초음속기인 보잉 2707을 개발 준비만 하면서 간을 보는 한편으로, 이미 개발 중이던 보잉 747 아음속 여객기는 주류에서 밀려날 경우 화물기로 언제든지 개조 가능하게 만반의 대비를 해 놓았다. 그러나 뚜껑을 열어 보니 초음속기는 가성비가 심각하게 부족했고 오일 쇼크와도 맞물려 영 재미를 못 봤다. 그 대신 747은 대형 여객기로 수십 년간 엄청난 성공을 거뒀다.

6. 2단계 계층

컴퓨터 프로그램 내지 알고리즘을 보면 작업을 수행하는 양상이 명백하게 독립된 두 phase로 나뉘는 것이 있다.

• 힙 정렬: 정렬 알고리즘 중에는 얘가 꽤 독특하다. 배열을 기반으로 heap을 생성하는 단계와, 그 heap으로부터 최종적으로 정렬된 리스트를 하나씩 뽑아내는 단계로 나뉜다.
• 컴파일러: 소스 코드를 구문 분석을 해서 내부 representation으로 변환하는 프런트 엔드, 그리고 이를 토대로 최적화와 기계어 코드 생성을 하는 백 엔드로 단계가 분명하게 나뉜다.
• 일본어 IME: 일본 문자 자체를 입력하는 방식과, 그 일본어 문자열을 NLP 관점에서 분석해서 어절을 나누고 한자 변환 후보를 제시하는 것은 서로 완전히 별개의 단계이다. 그러니 전자와 후자를 분리해서 일부 파트만 서로 다른 알고리즘 내지 DB 제품으로 교체해서 사용할 수 있지 않나 싶다.

그리고 데이터 압축이 있다. 흔히 간과하기 쉬운데, 압축이라는 절차도 두 단계로 나뉜다. 먼저, 원소나열법을 간단한 조건제시법으로 바꿀 만한 규칙성, 반복 패턴을 찾아서 더 간결한 방식으로 표현 방식을 바꾸는 것이 전자이다. 전자를 수행하는 방법은 그야말로 무궁무진하며, 손실 압축과 비손실 압축도 이걸 수행하는 방식의 차이에 지나지 않는다. 압축된 데이터는 데이터 + 탈출문자 + 약어에 대한 번문 명령(expansion instruction) + 사전 참조 오프셋 같은 게 뒤죽박죽 섞여 있다.

그 다음으로, 이런 인코딩 결과를 정보 이론 관점에서 빈틈 없는 아주 compact한 형태로 물리적인 표현 방식을 바꿔서 최종 출력하는 것이 후자이다. 후자는 이론적인 압축률의 한계도 다 증명돼 있고 전자에 비해 더 발전할 게 별로 없는 상태이다.
압축 알고리즘이라 하면 이 둘을 싸잡아서 한데 일컫는 경향이 있으나, 이 두 단계는 엄연히 용도와 성격이 다르다. 가령, jpg 이미지 포맷의 경우 이산 코싸인 변환은 전자요, 결과를 허프만 코딩으로 출력하는 것은 후자에 대응한다.

요즘은 보기 힘든데 1990년대에 Windows Installer가 아직 없던 시절에는 마소에서는 확장자가 cab이던가? 독자적인 압축 파일 포맷을 써서 프로그램을 배포했다. 더 옛날에는 원본 디스크를 보면 설치되는 파일들이 확장자만 다 _xe, _ll 혹은 ex_, dl_ 이런 식으로 바뀌고 안에 내용은 어설프게 압축되어 있곤 했다. Lempel-Ziv 같은 알고리즘으로 압축되긴 했는데, 코딩 방식을 조밀화하는 '후처리'는 하지 않아서 가끔씩 원본 파일에 들어있는 문자열이 드문드문 보이곤 했다.

파일을 압축하면 기본적으로 전자 과정을 거쳐서 크기가 줄어드는데, 후처리까지 거치면서 크기가 좀 더 감소할 뿐만 아니라 이때 진짜 난수표 같은 뒤죽박죽 비트 나열로 바뀐다. 둘은 마치 사이다에서 (1) 단 맛을 내는 향신료와 (2) 탄산, 에어컨에서 (1) 온도를 낮추는 압축기와 (2) 송풍기하고 얼추 비슷한 관계가 아닌가 싶다.

7. 혈액형과 상속 개념

코딩 하니까 드는 생각인데..
중등학교 때 혈액형과 수혈 가능성에 대해 배울 때 우리는 객체지향 프로그래밍에서 말하는 상속이라는 개념을 어렴풋이 접했다고 볼 수 있을 듯하다. 수혈 가능성은 형변환 가능성이고.

O형이 베이스 클래스이고 A, B형은 O형으로부터 상속이며 AB는 A와 B 다중 상속이다.
A형과 B형이 O형을 가상 상속을 한 건지는 잘 모르겠다.
하지만 현실은 그렇게 매끄럽지가 않기 때문에 어지간해서는 반드시 같은 유형끼리만 수혈을 하지, A/B계열형에다가 O형 피를 수혈하고 AB형에다가 A나 B형 피를 수혈한다거나 하지는 않는다고 한다. 이런 얘기는 어렸을 때 과학 책이나 교과서에서 접하지 못했다.

아무쪼록 다중 상속은 포인터의 형변환이 이뤄질 때 오프셋 보정이 필요하게 하며, pointer-to-member도 포인터 하나 형태로 간단하게 구현할 수 없게 만드는 주범이다.
다중상속 받은 한 클래스의 포인터를 다른 상속 파생 클래스의 포인터로 바꾸는 건 굉장히 조심해서 해야 한다. 이럴 때 C-style cast는 reinterpret_cast와 개념적으로 다를 바 없어지기 때문에 반드시 static_cast를 써야 실수를 예방할 수 있다.
그러니 혈액형간 typecast도 가능한 한 안 하는 게 좋아 보인다. 아무래도 위험해 보인다.

Posted by 사무엘

* 3년 전에 썼던 글을 내용을 보충하여 리메이크 한 것이다.

Windows 운영체제에서 생성하는 윈도우들은 그 본질이 크게 overlapped, popup, 그리고 child 이렇게 셋으로 나뉜다. 이해를 돕기 위해 아래의 Windows 1.0 사진을 한번 살펴보도록 하자. 그때는 이 세 종류의 구분이 지금보다 훨씬 더 명확했기 때문이다.

1. overlapped

1985년에 발표된 Windows 1.0 첫 버전은 기술적인 한계 때문..은 아니고, 애플 사와의 이상한 특허 분쟁에 얽히는 바람에 응용 프로그램 창들이 서로 겹치지를 못하고 타일 형태의 배치만 가능한 정말 괴상한 형태로 개발되었던 걸로 유명하다.
그러다 Windows 2.0에서는 타일 제약 봉인이 풀렸기 때문에 이 윈도우들은 겹쳐지는 게 가능해졌으며 Z-order라는 개념도 생겼다. 그게 워낙 뜻깊은 일이었던지라 명칭에까지 OVERLAPPED가 붙은 것이다.

그리고 저렇게, 타일 형태의 배치가 가능한 응용 프로그램의 최상단 껍데기 윈도우가 바로 오늘날의 개념으로 치면 overlapped 윈도우이다. 캡션이라고 불리는 제목 표시줄이 달려 있고 크기가 언제든지 유동적으로 바뀔 수 있으며, CreateWindow(Ex) 함수에다 위치와 크기를 지정할 때 CW_USEDEFAULT(대충 적당히 알아서)를 줄 수 있는 유일한 타입의 윈도우이다.

사실, WS_OVERLAPPED의 값은 그냥 0이다. popup이나 child 같은 속성이 따로 지정되지 않은 윈도우는 기본적으로 overlapped 속성이 지정된다. 여기에다가 최소화/최대화(WS_M??MIZEBOX)/닫기(시스템 메뉴 WS_SYSMENU) 버튼, 크기 조절 가능한 굵은 껍데기(WS_THICKBORDER) 비트들이 합쳐진 것이 바로 WS_OVERLAPPEDWINDOW 스타일이다.

2. popup

그럼 popup은 무엇이냐 하면 저 위의 About 대화상자처럼, overlapped window의 위에 겹쳐져서 배치될 수 있는 윈도우이다.
그런데 당장 Windows 2.0부터 오버랩은 말 그대로 overlapped window에서도 다 가능해졌으니, 둘의 실질적인 차이가 없어졌다고 볼 수도 있다. 하지만 둘은 여전히 완전히 동일하지는 않다.

popup 윈도우는 기본적으로 캡션이 없는 형태이며, WS_CAPTION 같은 별도의 옵션을 줘야만 캡션이 달린다. 그러나 overlapped 윈도우는 옵션을 주지 않아도 캡션이 무조건 달려 나온다. Windows 2~3 시절까지만 해도 응용 프로그램에서 캡션이 없고 제목이 없는 대화상자는 지금보다 훨씬 더 흔하게 볼 수 있었다.

지금은 대화상자들도 다 캡션이 달려 있으며 일반적인 응용 프로그램처럼 아이콘에다 최소· 최대화 버튼과 두꺼운 프레임까지 별도로 스타일로 주고 나면.. popup 형태의 대화상자 프로그램과, overlapped 형태의 일반 프로그램 창과 외형상의 구분은 사실상 다 사라지는 건 사실이다.

그럼에도 불구하고 popup과 overlapped의 구분이 원래 저런 데서 시작되었다는 것을 알면 되겠다. 다른 창의 내부에 종속되지 않고 독자적으로 화면에 떠 있으면서 캡션 같은 외형이 없거나 취사선택 가능한 모든 custom 윈도우라면, 묻지도 따지지도 말고 그냥 WS_POPUP을 주면 된다.

대화상자 리소스 편집기에서도 이 대화상자의 초기 스타일을 지정해 줄 수 있다. 프로퍼티 페이지처럼 다른 대화상자의 내부에 들어가는 대화상자이면 WS_CHILD를 주면 되고, 나머지 경우에는 WS_OVERLAPPED는 신경 쓸 필요 없고 그냥 WS_POPUP을 지정하면 된다.
여담이지만, 인터넷을 하면서 수시로 튀어나오는 웹브라우저 팝업창은 명칭과는 달리 사실은 overlapped 윈도우라고 생각하면 된다. 팝업창에도 웹브라우저 창 고유의 캡션과 프레임은 그대로 남아 있기 때문에 overlapped 윈도우의 정의에 훨씬 더 부합하는 걸 알 수 있다.

3. child

끝으로, WS_CHILD는 동작 방식이 위의 둘과는 굉장히 다르니 이해하기 쉽다.
자기의 위상이 독자적이지 않고 외형상 부모 윈도우의 내부에 종속된 모든 윈도우들은 child 윈도우이다. 대화상자의 내부 컨트롤들이 대표적인 예임.

얘는 컨트롤 ID라는 정보도 갖는다. HWND는 운영체제가 창들을 식별하기 위해 부여하는 가변적인 번호인 반면, ID는 창을 생성하는(= 운영체제에다 생성을 요청하는) 주체 측에서 고정붙박이로 부여하는 번호라는 차이가 있다. GetDlgItem은 이름처럼 굳이 대화상자의 자식 컨트롤뿐만 아니라 부모-자식 관계를 갖는 아무 윈도우에서나 ID값으로부터 자식 창을 얻을 때 사용 가능하다.

popup이나 overlapped 윈도우에는 저런 ID라는 개념이 존재하지 않으며, 그 대신 메뉴를 표시하는 기능이 있다.
뭐, child 윈도우도 비록 메뉴는 태생적으로 없을지언정 마치 overlapped 윈도우처럼 캡션과 프레임, 그리고 시스템 메뉴를 갖는 건 불가능하지 않다. 그 대표적인 예는 MDI 프레임 윈도우이긴 한데.. 그래도 그걸 빼면 캡션과 프레임을 갖춘 child 윈도우는 매우 드물다. 캡션과 프레임 자체가 최상위 윈도우의 상징과도 같으니 말이다.

이렇게 보면 overlapped와 popup이 한 묶음이고, 성격이 다른 child가 혼자 좀 따로 노는 것처럼 보인다. 하지만 동일한 클래스의 윈도우가 상황에 따라서 popup과 child 속성을 취사선택해서 동작하는 경우도 의외로 있다. 콤보 박스에서 내부적으로 쓰이는 ComboLBox라는 리스트 박스가 대표적인 예이다.

콤보 박스의 타입이 Simple이어서(대표적인 예는 글꼴 선택 대화상자) 리스트가 언제나 표시되어 보일 때는 얘는 콤보 박스에 딸려 있는 child 윈도우이다.
그러나 콤보 박스를 클릭하거나 F4를 눌렀을 때만 리스트가 표시되는 drop list 상태일 때는 그 리스트는 대화상자의 위에 별도로 표시되는 popup 윈도우 형태로 생성된다. 이해가 되시겠는가?

차일드 윈도우의 표시 위치는 자기 부모 윈도우의 클라이언트 위치를 기준으로 상대적으로 산정된다. 그런데 자기가 현재 부모 윈도우의 클라이언트 위치 기준으로 어디에 있는지를 한 번에 얻는 게 은근히 힘들다. 대화상자 크기에 따라 차일드 컨트롤들을 적절하게 재배치하는 코드를 작성해 보았다면 이 말이 무슨 뜻인지 잘 알 것이다.

이 경우 GetWindowRect를 한 후에 부모 윈도우를 기준으로 ScreenToClient를 하여 화면 좌표를 한번 거쳐야 하거나, 아니면 번거로운 구조체 초기화를 해야 하는 GetWindowPlacement 함수를 호출해야 한다. 후자 함수의 경우, 최대화된 윈도우라도 원래 있던 위치와 크기까지.. 그 윈도우의 위치와 관련된 모든 정보를 되돌려 주기 때문에 유용하다. 응용 프로그램이 종료 후 나중에 재실행될 때 원래 위치를 100% 그대로 실행되기를 원할 때 이 구조체 값을 백업해 두면 된다.

4. 윈도우 간의 부모/자식 관계

child 윈도우야 그 정의상 태생적으로 부모 자식 관계가 명백하게 존재할 수밖에 없다. 하지만 popup 윈도우도 비록 child처럼 표시되는 위치와 영역이 부모 윈도우 내부로 한정되는 급까지는 아니더라도, 부모 자식 관계 비스무리한 개념이 물론 존재한다.

popup 윈도우는 Z-order상으로 자기 부모 윈도우를 가리고 언제나 더 앞에 출력되며, 부모 윈도우가 소멸될 때 자기도 같이 없어진다. 요렇게 child가 아닌 popup 윈도우의 부모 역할을 하는 윈도우를 개념상으로 owner 윈도우라고 따로 부르기도 한다.

그럼 popup 말고 overlapped 윈도우는? 지금까지 살펴보았듯이 쟤는 애초에 주 용도가 응용 프로그램의 최상단 프레임 껍데기이다. 그러니 태생적으로 부모 윈도우 같은 걸 지정하지 않고 생성되며 부모 자식 관계를 따지는 건 딱히 의미가 없다고 봐야 할 것이다.

그런데, 여기서 유의해야 할 점이 있다. EnumChildWindow나 GetWindow(GW_CHILD) 함수에서 찾아 주는 건 순수하게 child 윈도우들뿐이다. Spy++를 실행하면 계층 구조로 표시된 윈도우 트리를 볼 수 있는데, 이것도 child 윈도우들의 관계만 볼 수 있다.
쉽게 말해 어떤 대화상자 내부의 대화상자(프로퍼티 페이지)라든가 각종 컨트롤들은 계층 구조로 표시되지만, 대화상자에서 얘를 owner로 삼아서 또 다른 modal 대화상자를 꺼내 놓은것을 계층 구조로 보여주지는 않는다는 뜻이다.

자신을 부모(정확히는 owner)로 갖는 서열상 하위의 popup 윈도우들을 한번에 찾아 주는 API는 의외로 존재하지 않는다. 난 이게 당연히 있을 줄 알았는데 없는 걸 발견하고는 개인적으로 굉장히 놀랐다.
일단 top-level 윈도우들을 다 enumerate 한 뒤, 얘들의 owner가 일치하는 놈을 일일이 뒤져 봐야 한다. 그래서 Spy++가 표시해 준 윈도우 리스트가 생각보다 직관적이지 않고 top-level 윈도우가 많은 것이었구나.

이상이다. Windows 프로그래밍을 15년 가까이나 판 본인도 몇 년 전까지만 해도 child는 그렇다 치더라도 popup과 overlapped는 도대체 왜 존재하는 구분인지를 잘 몰랐다. 그리고 parent 윈도우와 owner 윈도우의 관계도 정확하게 모르고 있었고 owned 윈도우는 child 윈도우 조회하듯이 곧장 조회가 가능하지 않다는 것도 미처 생각을 못 하고 있었다. 그러다가 요 근래에야 어렴풋이 이해하게 된 것들을 이렇게 정리해 보았다.

Posted by 사무엘

C 언어는 가히 프로그래밍 언어계의 라틴어라 해도 과언이 아닌 대중적인 언어가 돼 있다. 얘는 알골(Algol), 그 다음으로 B라는 언어의 뒤를 이어 단순하게 C라고 명명되었으며 1972년에 만들어졌다. 이걸 보면 컴퓨터계에서 3.0 버전이 흥행 대박 친다는 법칙은 언어 분야에서도 유효한 것 같다.

C 언어의 고안자는 '데니스 리치'이다. 이 사람은 지난 2011년 가을에 마침 스티브 잡스와 거의 1주일 간격으로 나란히 작고했다(잡스가 먼저). 그래서 컴퓨터쟁이들 사이에서는 둘 중 덜 유명한 사람이 사실은 컴퓨터계에 훨씬 더 큰 공헌을 했다는 요지의 글을 올리곤 했다.

C는 기본적으로 컴파일 형태로 빌드되는 언어이며, 1990년대를 전후해서 16비트 도스 시절엔 볼랜드라는 회사에서 개발한 터보 C 컴파일러가 아주 대중적으로 쓰였다.
그러나 터보 C보다 이전에 IBM PC용으로 최초로 등장한 C 컴파일러는 Lattice C라고 다른 회사 제품이었다. 1982년인가 그렇다. 이게 그 먼 옛날에 타 플랫폼용으로 개발된 프로그램들을 도스용으로 포팅하는 데 중요한 선구자적 역할을 했다. 얘가 당대의 다른 후속 경쟁사 컴파일러들에 비해 코드 생성 성능도 좋았다고 한다.

사실은 Microsoft C도 Lattice C를 기반으로 개발되었다. 그러다가 1985년에 개발된 MS C 3.0부터 마소가 완전히 독자적인 컴파일러 개발 라인을 구축했다고 영문 위키백과를 보면 나온다. 브라우저에다 비유하자면 IE의 소스에서 모자이크의 소스를 완전히 떼어낸 것과 비슷한 격이겠다.

Windows의 경우 1.0은 처음에 파스칼로 개발되었으며, 이거 영향으로 실행 바이너리들을 들여다보면 export 심벌들의 명칭은 대소문자 구분이 없고 문자열도 앞에 길이가 기록된 형태로 저장되었다고 한다. 대소문자 구분이 없는 건 확실하게 본 기억이 있는 반면, 후자는 잘 모르겠다.

물론 초창기에도 파스칼이 아닌 C언어 기반의 Windows SDK가 있긴 했다. Windows 1.0 SDK의 경우 바로 저 초창기의 MS C 3.0까지는 아니고 4.0과 연계해서 동작했던 걸로 기억한다. 운영체제(?)의 개발과 컴파일러의 개발이 나름 병행되었던 셈이다. 그래도 뭐, 파스칼의 흔적이 어떤 형태로든 과거에 존재했기 때문에 PASCAL이라는 calling convention 명칭도 오늘날까지 legacy로 버젓이 전해지는 아닌가 싶다.

그러다 Lattice C는 1980년대 후반에 개발사가 타사에 인수되었으며 물건 역시 MS, Borland 같은 후발주자 대기업(?) 제품에 밀려서 역사 속으로 사라졌다. C를 제외하면 볼랜드는 파스칼을 민 반면, 마소는 빌 게이츠의 입김과 추억이 담긴 Basic을 밀었다. 베이직이 Quick-을 거쳤다가 나중에 폼 디자인 기능이 탑재된 Visual Basic이 되었다면, C 계열은 Quick-을 거쳤다가 C++ 언어에 MFC까지 탑재하여 Visual C++이라는 공룡으로 거듭났다. 물론, 그래도 VC에 지금과 같은 IDE의 프로토타입이라도 갖춰진 물건은 또 한참 뒤인 4.0 (1995)부터이다.

도스 시절에는 Turbo/Borland라는 브랜드로 볼랜드 컴파일러가 심지어 마소의 컴파일러조차도 따돌리며 리즈 시절을 구가했다. 1990년대 중반이 되면서 32비트 도스라는 틈새시장을 겨냥해서 Watcom, DJGPP 같은 제품이 꼽사리로 꼈을 뿐이며, 정작 마소와 볼랜드는 32비트 도스 플랫폼 지원은 상대적으로 미흡했다.

허나, Windows 95/NT가 널리 퍼지면서 주력 C/C++ 컴파일러는 Visual C++로 판도가 급격히 기울었다. Lotus 1-2-3이 하루아침에 급격히 밀리고 Excel이 천하를 평정했으며, 넷스케이프가 90년대 말에 정말 급격히 몰락한 뒤 IE 세상이 된 것처럼 말이다. 컴파일러는 브라우저처럼 무슨 끼워팔기 독점 같은 게 있지도 않았는데 어쩌다 상황이 바뀌었는지 모르겠다. (옛날엔 플랫폼 SDK와 함께 제공되던 공짜 컴파일러는 상용 Visual C++와 동급의 고성능 컴파일러가 아니었음)

자, 그럼 다음으로 C에 이어 C++도 언어와 컴파일러 역사를 회고해 보겠다. C++은 1970년대 말에 C with Classes라는 가칭으로 개발되었다가 1983년에 지금의 이름으로 첫 발표되었다. C++의 고안자는 덴마크 사람이다. 그리고 초기의 몇 년 동안(1980년대 중반) C++은 인지도가 안습했던 관계로 독자적인 컴파일러가 존재하지 않았다.

오늘날 C++의 위상과 지위를 생각하면 저런 시절이 존재했다는 게 믿어지지 않는다만, 그때는 C++ 코드를 C 코드로 변환해 주는 Cfront라는 전처리기 형태로 C++의 구현체가 명맥을 이었다. 말은 전처리기라고 했지만 소스 코드를 완전히 분석하고 변환하는 것이기 때문에 기술 수준은 엄연히 전처리기를 넘어 컴파일러의 front end급은 된다.

그러다가 C++ 직통 컴파일러가 등장한 것은 1980년대 말~1990년대 초이다. 메이저한 개발사인 볼랜드와 마소에서 C++ 컴파일러를 내놓은 것은 역시나 빨라도 1990년과 그 이후부터이지만, 1980년대 말에.. 그래픽 카드로 치면 VGA의 등장과 비슷한 시기에 C++ 직통 컴파일러를 내놓은 제조사도 있었다.
IBM PC/도스용으로는 Zortech C++가 그런 선구자 축에 든다. 딱 우리나라가 올림픽 하던 시절과 얼추 비슷하게 첫 작품이 나왔다.

Zortech C++은 훗날 1993년경에 Symantec C++ 이라고 브랜드 이름이 바뀌어서 6~7.x 버전까지 개발되었다. 도스와 OS/2, Windows (16/32비트)를 모두 지원하는데 역시나 볼랜드, 마소, 왓컴 같은 다른 브랜드에 밀려서 인지도는 그리 높지 못했던 듯하다.
본인은 먼 옛날에 어둠의 경로를 통해서 이 컴파일러 자체는 접한 적이 있다. Hello, world!만 출력하는 프로그램을 빌드해 봤는데 exe의 크기가 꽤 작게 나왔던 걸로 기억한다.

그리고 Zortech / Symantec C++ 컴파일러의 개발자는 Walter Bright이라고.. 프로그래밍 언어 연구와 컴파일러 개발에만 뼈를 묻은 유명한 아저씨이다. 원래 전공은 전산· 컴공도 아닌 기계공학인데 프로그래머로 전업 후, 컴공에서 최고로 어려운 분야 축에 드는 컴파일러를 곧장 파기 시작했다는 게 대단하다.
이 사람이 D 언어의 고안자이기도 하다는 걸 본인은 최근에 알게 됐다. D에 대해서는 개발자 개인이 아니라 Digital Mars라는 개발사의 이름만 알고 있었기 때문이다.

C++ 컴파일러를 개발하는 현업에 수십 년 종사했으니 그는 C++의 언어 구조와 빌드 과정에 존재하는 구조적인 비효율과 단점에 대해서 누구보다도 잘 알고 있을 것이다. 그러니 자신의 경험과 노하우를 집약해서 네이티브 코드 컴파일 언어이면서 C/C++의 단점을 보완한 새로운 언어를 직접 만드는 지경에 이르렀다. 하지만 D의 지지자· 사용자들이 어떻게든 똘똘 뭉쳐서 언어의 인지도를 끌어올리는 데 목숨을 걸어도 시원찮을 판에, 런타임 라이브러리가 Phobos와 Tango로 분열되고 커뮤니티가 폭파되는 큰 악재를 겪기도 한 모양이다.

거기에다 C++ 자체도 2010년대부터는 부스터를 단 듯이 언어와 라이브러리가 모두 하루가 다르게 미친 듯이 발전하는 중이다. 이게 과연 내가 알던 그 C++가 맞나 싶은 생각이 들 지경이며, 오죽했으면 같은 C++로도 이런 새로운 패러다임을 잔뜩 도입해서 코딩을 하는 걸 Modern C++이라는 비공식 명칭으로 따로 일컬을 정도이다. 이대로 가면 인클루드의 단점을 개선하는 import/패키지 기능까지 가까운 미래에 C++에 도입될 추세다. 그러니 "호환용 레거시가 너무 지저분하다"처럼 태생적으로 어쩔 수 없는 것 빼고는 단점들이 의외로 많이 해소되었다.

그걸로도 모자라서 다른 대기업이나 오픈소스 진영에서도 Rust처럼 네이티브 기반이면서 독특한 패러다임을 담고 있는 언어를 내놓고 있으니 D 역시 자신만의 메리트와 경쟁력을 확보하기 위해서는 갈 길이 아직 먼 것 같다.
C에서 파생형 언어 명칭을 만든 게 C++, C#뿐만 아니라 D라니 참 재미있다. C++뿐만 아니라 C#도 고안자가 덴마크 사람이라니 저 나라도 의외로 전산 강국인 듯하다.

(여담이지만 Walter Bright 아저씨는 컴파일러 개발자 겸 PL 연구자로 이름을 날리기 전인 1970년대부터 이미 Empire이라는 턴 기반 전략 시뮬 게임을 만들기도 했다. 워낙 너무 옛날이니 오늘날과 같은 컴퓨터에서 컬러 그래픽이 나오는 형태의 게임은 아니었겠지만, 아주 어린 시절부터 정말 비범한 분이었다는 건 확실해 보인다. 게다가 저 작품은 전략 시뮬 장르에서 맵의 전체 시야를 노출해 주지 않는 fog of war라는 개념을 첫 도입한 선구자이기도 하다고 한다.)

Walter Bright 말고, 또 볼랜드나 마소 계열도 아니면서 C++ 골수 덕후인 컴파일러 제조사가 하나 더 있다. 바로 Comeau. C++98이던가 03 시절에 그 악명 높은 템플릿 export 키워드를 유일하게 손수 다 구현한 이력도 있는 대단한 용자이다. 얘들 역시 1989년 초에 곧장 C++ 컴파일러를 내놓았으며, 그때부터 도스와 OS/2 등 다양한 플랫폼을 지원했는데, 거기 내부엔 또 어떤 출신과 배경을 가진 컴파일러/PL 괴수가 기업을 이끌고 있나 궁금해진다.

Comeau 컴파일러는 오늘날은 프런트 엔드로는 Edison Design Group의 제품을 사용하여 동작한다. 그럼 저 업체와는 어떤 관계인지 궁금하다. 그리고 프런트가 그런 관계이면 쟤들은 최적화와 타겟 코드 생성 같은 백 엔드 쪽에 차별화 요소가 있어야 할 텐데.. 백 엔드로는 아예 CPU 제조사라는 결정적인 텃새가 있는 인텔 컴파일러도 강세 아니던가? 그런 제품과 경쟁이 되려나 모르겠다.

이상. 이 글은 볼랜드나 마소 같은 유명 대기업 계열이 아니고 그렇다고 gcc 같은 오픈소스 진영도 아니면서 C/C++ 컴파일러를 상업용으로 제일 먼저 PC에다 구현했던 선구자들이 누군지를 문득 생각하면서 끄적여 보았다.

Posted by 사무엘

1.
근래에는 회사 업무 때문에 드디어 맥OS에다가 xcode까지 좀 건드릴 일이 있었다. 작년에 애플에서는 자기네 PC용 운영체제의 공식 명칭을 macOS라고 붙이면서 mac이라는 단어를 다시 복귀시켰던데, 이건 잘한 조치라고 생각된다. mac을 빼고 OS X라고 하는 건 영 아니었다. 무슨 OS/2도 아니고. 물론 걔네들 입장에서는 iOS 같은 타 기기용 운영체제와 명칭 표기를 통일하느라 mac을 소문자 형태로 살린 것이었다.

맥OS에서 메뉴를 꺼내는 단축키는 웬 뜬금없는 Ctrl+F2이구나(Win은 F10 또는 Alt). 그리고 한 프로그램 안에서 문서 창을 전환하는 단축키는 Cmd+` 이다(Win은 Ctrl+Tab 또는 Ctrl+F6). 이런 왕초보 기초부터 다시 시작했다.

Visual Studio와 C++과는 너무 다른 프로그래밍 방법론이 여전히 적응이 안 됐지만.. 나름 맥OS에 대한 이해가 예전보다는 더 깊어질 수 있었다. NextStep에서 딴 NS... 이런 명칭은 게임브리오 소스에 있는 NI... (넷이멀전) 접두사와 비슷한 느낌이 들었다. N으로 시작하고, 지금은 대외적으로 쓰이지 않는 이름. 마치 MFC의 Afx처럼 말이다.

한번은 각종 설정들을 이것저것 건드린 뒤부터 멀쩡한 프로젝트에서 정체를 알 수 없는 링크 에러가 나서 한참 고생한 적이 있었다.
링크 에러라면 당연히 extern "C"처럼 함수 호출 규약이나 심벌 decoration 방식의 충돌이 1순위로 의심되겠지만, 알고 보니 프로젝트 파일 리스트와는 별개로 관리되는 빌드 대상 목록에서 몇몇 소스 파일이 실수로 누락되어 벌어진 일이었다. 둘이 동일한 개념이 아니었 것이다.

하긴 Visual Studio도 각각의 파일들에 대해서 속성을 줘서 exclude from build를 지정하는 게 있긴 했다. 그걸 몰라서 딴 데서 한참을 헤맸다.
IDE에서 각종 경고를 출력하는 인텔리센스와 문맥 감지 색깔 처리가 정상적으로 되고 있어서 이 파일이 애초에 컴파일이 되지 않고 있다는 건 상상을 못 했었다.

2.
맥OS는 자기네 그래픽 비주얼은 그렇게도 뛰어나면서 정작 그래픽 툴을 제공하는 건 왜 그리 인색한지 모르겠다. 맥OS에는 Windows의 '그림판'에 해당하는 기본 프로그램이 내가 알기로 여전히 없다.
개발툴 중에서도 Visual Studio는 간단한 아이콘이나 비트맵 정도 편집할 수 있는 그래픽 에디터를 내장하고 있는 반면, xcode는 그런 거 없고 viewer만 있다. 비트맵 그래픽 편집을 어떻게 해야 할지 모르겠다.

그리고 또 인상적인 점으로는 맥 진영은 Windows에서는 거의 듣보잡이나 마찬가지이던 tif/tiff를 좋아하는 듯하다. 화면 캡처 기본 앱이 그림 파일을 tif로 저장할 때부터 뭔가 심상찮았는데.. 타 xcode 프로젝트들을 보니까 비트맵/아이콘에 역시 tif가 들어가 있구나.

그런데 tif도 다 같은 tif가 아닌지, Windows에서 돌아가는 타 그래픽 에디터에서 저장한 tif는 맥에서 못 읽는 것 같다.

3.
명령 프롬프트로 가 보면, 공백이 포함돼 있는 파일명을 명령 프롬프트에서 표현할 때 Windows는 파일명을 따옴표로 싸서 공백을 표현하는 반면, 맥은 그렇지 않은 듯하다. 역슬래시+공백이라는 탈출문자 기법을 사용한다. 그러니 "a b"냐 a\ b냐의 차이가 발생한다. 디렉터리 구분자부터가 슬래시이니 역슬래시를 저렇게 C스럽게 탈출문자 용도로 활용한다는 게 아주 흥미롭다.

명령 프롬프트가 현재 가 있는 디렉터리(폴더)를 기준으로 탐색기 또는 그에 준하는 파일 관리 셸을 여는 것도 자주 행해지는 작업이다. 숨김 속성 때문에 셸을 통해 접근할 수 없거나 접근 방법이 까다로운 폴더를 다루고 싶을 때 말이다. Windows에서는 start .이던데 맥은 open .이다. 리눅스는 어찌 되려나 궁금하다.

4.
그리고... 결정적으로 맥용 IME 예제도 다뤄 봤다. 골치 아픈 DLL이 아니라 쿨하게 EXE 형태이고, regsvr32 따위 할 필요 없이 그냥 프로그램을 특정 디렉터리에다 얹어 놓기만 하면 바로 IME가 동작하는 게 참 깔끔해 보였다. 여기에다가 날개셋 엔진만 얹으면 내 프로그램이 맥용으로 나오는 것도 불가능하지는 않겠다는 생각이 들었다. 물론 글자만 달랑 찍히는 수준을 넘어서 완성도 있는 제품을 만드는 건 지금 시간과 내 실력만으로는 아직 어림도 없는 요원한 일이다.

오래 전부터 인지했던 것이긴 하지만, Windows와 맥은 문자 입력 시스템을 설계한 형태가 서로 크게 다르다.
Windows는 IME가 또 내부적으로 한영 상태를 갖고 있고 자기 상태를 아이콘을 통해 출력하는 형태이다. 즉, Windows 8식 용어로 표현하자면 brand icon과 state icon이 따로 있다.
그러나 맥은 그렇지 않고 한글 입력 상태가 영문 상태만큼이나.. Windows식으로 표현하자면 별도의 input locale이다. 일단 한글 IME 상태에서 한영 키로 한영 전환을 하는 게 아니라, 입력 로케일 전환인 Ctrl+Shift가 한영 전환인 셈이다. state icon이 없고 brand 자체가 state 역할을 한다.

그러나 <날개셋> 한글 입력기는 자기 brand 하에서 2개 이상 열몇 개까지 입력 항목을 추가할 수 있는 형태이다. 이것부터 맥OS에서는 어떻게 표현을 해야 할지 모르겠다. 맥에서 <날개셋> 한글 입력기는 편집기 계층은 제대로 구현하지 못하고 그냥 입력기 계층 하나 수준에 머물러야 할 수도 있다.

맥에서는 IME가 독립된 프로그램이고 시스템 전체에서 동일한 한영 상태가 유지된다는 것도 매우 흥미로운 점이다. Windows도 IME가 애초에 이런 형태였으면 지금처럼 32비트와 64비트가 공존까지 하는 시대에 IME를 개발하기가 훨씬 더 깔끔해지지 않았을까 싶은 생각이 든다.
언제든지 자기 자신을 죽이고 재시작만 하면 업데이트도 아주 간편하게 할 수 있다. Windows는 DLL에다 memory-mapped file크리까지 겹쳐서 프로그램 강제 종료나 재시작 같은 지저분한 짓 없이는 IME의 업데이트라든가 전체 상태 동기화가 몹시 어렵다.

다만, 그 구조의 특성상 IME를 디버깅 하는 도중에 잠시 딴 프로그램에서 타 IME를 구동해서 문자를 입력하기가 좀 난감한 점은 있다. IME는 그 특성상 타 입력기로 대체만 될 뿐 '스스로 종료'라는 개념이 없는 프로그램인데, Windows에서는 자기 DLL을 사용하는 프로그램이 하나만 존재하면 그것만 끝내면 디버깅도 원활하게 종료되는 반면, 맥에서는 그런 것도 없어서 그냥 IME 프로그램을 강제 종료해야 한다.

그리고 IME 프로그램은 내 자신이 실행하는 게 아니라 운영체제가 on-demand로 구동해 주는 형태이다. 그러니 개발툴이 처음부터 IME를 디버깅 할 수 있는 게 아니라 이미 구동돼 있는 IME 프로세스에다 디버거가 붙는(attach) 식으로 디버깅을 해야 한다.
이렇게 붙으면 NSLog를 찍는 게 xcode의 output 창에 나타나질 않는 문제가 있더라. 그 이유는 모르겠다. 운영체제의 문자 입력 프로그램이라는 건 어떤 형태로 만들더라도 디버깅이 어려운 구석이 있는 듯하다. 동력분산식과 동력집중식만큼이나 서로 일장일단이 있는 셈이다.

5.
코딩을 하면 할수록 Objective C의 고유 문법과 일명 NSFramework 라이브러리는 독립된 언어라기보다는..
Windows로 치면 COM처럼, 그냥 API/라이브러리의 컴포넌트화, 그리고 운영체제-내 프로그램 간의 통신을 위한 바이너리 수준의 프로토콜에 가까운 물건이라는 생각이 든다.

쉽게 말해 NSObject는 IUnknown에, YES/NO는 S_OK, S_FALSE에, @문자열은 BSTR, SysAlloc/FreeString 등에, xib/nib는 리소스 겸 type library에 대응하는 식이다. 뭐 가상 머신이 따로 돌아가는 급은 아니지만 그래도 가벼운 garbage collector도 있다.

물론 기능 호출 방식은 서로 큰 차이가 있다. COM은 함수 포인터 기반인 C++과 더 비슷하지만 옵씨는 진짜 SendMessage 같은 방식이다.
그러니, NSObject에 뭐가 이렇게 오버라이드 가능한 메소드들이 많이 정의돼 있는지, 리스트를 보고 깜짝 놀라곤 했다. v-table 기반의 가상함수라면 상상도 못 할 일이다. MFC도 v-table 크기 부담 없이 운영체제 메시지 처리를 C++로 하기 위해 message map이라는 별도의 메커니즘을 도입한 것이다.

옵씨라고 해서 말 그대로 C만 쓸 수 있는 건 아니며 C++ 코드도 작성 가능하다. 그러니 [ ] 어쩌구로 시작하는 그쪽 ‘오브젝트’와 해당 문법은 운영체제로부터 호출을 받는 것에 대처할 일이 있을 때만 사용하게 되더라.
아무튼 지구를 떠나서 달이나 화성에서 사는 건 어렵고, Windows 홈그라운드를 떠나 타 OS에서 사는 건 여전히 몹시 어렵다!

Posted by 사무엘

1. 색소폰 연주

아시다시피 본인은 Looking for you를 3천 번 들었다.
성경의 사무엘이 '사무엘아' 음성을 두 번 듣고 나서 세 번째 들은 뒤엔 출처를 공부한 뒤 들을 준비를 하고 잠자리에 누웠다. 네 번째 '사무엘아' 음성을 들은 뒤에야 하나님의 음성에 제대로 응답하게 됐다.

그것처럼 나도 새마을호에서 Looking for you를 두 번 듣고 나서 세 번째 들은 뒤엔 출처를 인터넷으로 검색했고, 다음엔 들을 준비를 하고 새마을호를 탔다. 네 번째 Looking for you가 흘러나왔을 때 나는 철도 안에서 거듭났고 철도를 내 개인의 교통수단으로 영접하는 놀라운 일이 벌어졌다.

그 뒤로 나는 Looking for you를 주선율, 주요 화음, 대략의 비트까지 다 청음 채보했다.
콩나물 대가리를 한땀 한땀 입력해 넣고 원곡과 대조하면서, 어느 기보가 원음에 더 근접한 정확한 기보인지를 고민하면서..
Looking for you 작곡자의 마음과 심정을 이해하는 자가훈련을 했다.

이 음악의 어느 부분이 나를 감화시켜서 나를 철덕으로 만들었는지, 왜 이런 결과가 야기될 수밖에 없는지를 연구했다.
그리고.. Looking for you의 주선율을 만든 악기 공부를 (잠깐 동안이지만) 시작했다.

작년 성탄절, 우리 교회 복음 전도 집회에서.
아, 교회에서 Looking for you 연주했다는 얘기는 아님. 오해 마시길..

2. 나의 등산 노트

조건부 서식이 있으니 올랐던 산들의 높이를 일목요연하게 파악할 수 있어서 매우 좋다.
이것도 중복 정보 없이 정규화가 잘된 구조로 구축하려면 산에 대한 테이블과 등산 세션과 관련된 테이블을 분리하긴 해야 하는데, 엑셀로 그것까지 하기에는 많이 귀찮지.

입산 지점에 최종적으로 어떤 교통수단을 이용해서 가서 어디로 하산했는지,
산 속에서 주로 본 게 무엇인지, 바깥 경치로 주로 무엇을 봤는지,
정상에는 무엇이 있었고 어떤 형태였는지, 산이 행정적으로 어떤 관리를 받고 있는지 같은 것을 일목요연하게 조회 가능하게 했다.

3. 코딩

그럼 이제 일상생활 얘기로 넘어가겠다.

(밝은 화면을 비추느라 명암차 때문에 주변이 어두워진 거지, 촬영 당시에 책상 주변은 실제로는 저 사진만치 어둡지 않았음)
화면이 미치도록 광활한 데스크톱 컴과,
눕든지 앉든지 편한 자세로 침대, 책상, 자동차 등 아무 데서나 사용 가능한 놋붉 컴 중
뭘로 코딩을 할지가 매우 고민된다. 일종의 행복한 고민.

참고로 노트북의 화면 전체와, 데스크톱 모니터의 오른쪽에 떠 있는 작은 프로그램 창하고 화면 크기(화소 수)가 동일하다. ㄲㄲㄲㄲㄲㄲㄲㄲ 미래의 리드미 문서를 작성하고 있는 날개셋 편집기의 화면임.
내가 지금까지 갖고 있던 그림과 동영상들이 화질이 얼마나 구린지를 까발리고 정죄하는 마법의 모니터다.

역시 프로그래머에게 화면이 큰 건 컴퓨터에게 램이 많은 것과 같다~! 정말 다다익선이다.
그도 그럴 것이 자꾸 창 전환이나 스크롤 하는 게(개발툴, 웹브라우저, 에디터, msdn 등등) 컴터로 치면 메모리 부족해서 하드디스크 스와핑 하는 것과 개념적으로 완전히 동일하기 때문이다.

무식하게 혼자 3~5K급으로 해상도가 너무 높은 모니터 하나냐, 혹은 걍 2K 해상도급 모니터 듀얼/트리플 중 어느 게 더 좋을지는 잘 모르겠다. 제각기 장단점이 있어 보인다.
참고로 배(선박)와 DLL(Windows 파일..;; )은 작은 놈 여럿보다는 큰 놈 하나가 성능면에서 더 효율적이다.

일체형 PC는 간지나고 공간 덜 차지하고 지저분한 선 없이 콘센트 하나만 꽂으면 모니터 본체 스피커가 전부 OK이니 정말 좋긴 하다.
다만, 이렇게 한번 세팅된 이후로 부품 업그레이드가 어려울 것이고 발열 제어도 곤란하니 엔드급 게임은 무리일 것이다.

구조적으로 볼 때 철도 차량의 동력분산 / 동력집중의 차이와 비슷해 보인다. 일체형 PC가 동력집중이 아니라 분산식에 대응한다. 그리고 트렁크· 캐빈· 엔진룸 따위의 구분이 없는 원박스 형태의 자동차도 일체형 PC와 비슷한 컨셉이라 볼 수 있겠다. (공간 활용 최대, 그러나 정비가 어렵다는 점에서 비슷)

4. 시간 부족과 일정 압박

CPU 클럭 속도 향상의 병목은 발열이고, 자동차 속도 향상의 병목은 공기 저항이다. 스마트폰 성능 향상의 병목은 배터리 용량이다.
그리고 날개셋 한글 입력기 개발에서 최악의 병목은 잠으로 인한 시간 부족 되시겠다.
난 오랜 경험상 매일 6시간이 정말 마지노선이고 그 이하로는 도저히 못 줄이겠다. 결국은 낮에 졸음과 집중력 저하로 인해 밤에 안 잔 것 이상의 대가를 치르게 되더라. -_-;;

어지간한 고시 준비생만치 시간을 분초 단위로 쪼개며 살아도 시원찮을 판에 이래 가지고 날개셋 9.0은 언제 완성할 것이며 박사 졸업은 도대체 언제 하나..;;
늦게 자고 늦게 일어나는 것보다는 일찍 자고 일찍 일어나는 것 선호함. 눈 감았다 뜨면 그냥 6시간이 싹 워프되고 개운 가뿐하게 일어나긴 한다. 천성적으로 남 눈치 안 보고 앞날 걱정을 미리 안 하는 체질이어서 그런지 스트레스는 적게 받는 편. 불면증 같은 게 어떻게 존재하는지 이해를 못 한다.

단지 잠을 더 줄일 수가 없을 뿐임.
이것도 기초체력 문제인가..? 잠 적으신 분이 굉장히 부럽다.

5. 덕질

논문 쓸 '꺼리, 아이템'들을 만들어내는 활동은 재미있지만 (코딩, 시스템 구현, 실험 등등)
그걸로 온갖 형식 갖춰서 실제로 논문을 쓰는 건 꽤 성가시고 번거롭다. =_=;;
그래도.. 잔인한 주인이 무자비하게 내린 온갖 복잡한 재귀호출 뺑뺑이와 자질구레한 메모리 할당· 해제 요청들을 컴퓨터는 진짜 순식간에 전광석화처럼 해낸다.

소프트웨어의 추상화 계층이 올라가면 코드를 유지보수하고 확장하기는 편해지지만 컴퓨터의 입장에서는 뭘 하나 하려 해도 포인터가 가리키는 대로 메모리를 여러 단계 요리조리 따라가야 하고, 캐시 미스가 나면 더 느린 메모리에 갔다가 와야 된다.

사용자가 '확인'을 누르거나 키보드를 하나 눌러서 화면에 글자 한 자가 찍힐 때까지 컴퓨터가 전자적으로 처리하는 일의 양이 도대체 얼마나 될까.
하물며 실존하지 않는 종이, 실존하지 않는 음악과 영상이 존재하는 것 같은 경험을 사람에게 제공하기 위해서 컴퓨터는 얼마나 많은 계산을 순식간에 해치우고 있을까?
프로그래머로서 이런 컴퓨터가 고맙고 대단하게 느껴질 때가 있다.

글자를 온통 배배 틀고 배경과 뒤섞어 놓은 일명 '캡챠'는 사람은 곧바로 알아보지만 컴퓨터가 알아보지 못하는 (걸 지향하는) 그림이다.
그러나 사람이 도무지 판독할 수 없는 랜덤 노이즈로 보이는 QR 코드 같은 건 컴퓨터가 곧바로 판독해 낸다.
예전에도 말했듯이 주석과 들여쓰기가 잘 된 코드와, IOCCC용 난독화 코드는 컴퓨터가 해석하는 데 아무런 차이가 없다.
이런 걸 생각해 봐도 사람과 기계는 근본적으로 특성이 달라도 이렇게 다르다는 걸 느낄 수 있다.

6. 컴퓨터 세팅

개인용 컴퓨터를 새로 지르거나 회사 같은 데서 내 업무용 컴터를 받았을 때 내가 기종을 불문하고 제일 먼저 하는 일은

• 키보드 속도를 최고속으로 맞춘다. 보통 디폴트 값은 반복 속도가 늘 최고속에서 한 단계 낮은 걸로 돼 있는데.. 난 이게 최고속으로 돼 있지 않으면 답답하고 불편해서 못 쓴다. 키를 이 정도 시간 동안 눌렀으면 cursor나 선택 막대가 어느 정도로 이동해 있을 거라는 예상치와 기대치가 있기 때문이다. 지금 같은 '재입력/반복 키보드 속도 조절 체계'는 IBM PC AT 시절 이래로 변함없이 이어져 온 유구한 전통이다.
• <날개셋> 한글 입력기를 설치한다. 내 홈페이지에 대외적으로 공개돼 있는 최신 버전이 아니라, 나 혼자만 갖고 있는 "개발 중"인 진짜 최신 버전이다. 한글을 내가 원하는 형태로 입력 가능하고 그 구닥다리 16*16 비트맵 폰트를 화면으로 좀 봐야 내가 심리적으로 안정된다.
• Looking for you.mp3 복사해 넣는다. 음악 파일 중에서 묻지도 따지지도 않고 내가 무조건 제일 먼저 집어넣는 파일, 특히 사운드 테스트용으로 쓰는 파일은 답정너 looking for you이다. 이게 흘러나와야 내 개인용 컴퓨터라는 생각이 든다.

그나저나 노트북 내지 미니키보드들의 왼쪽 아래를 보면 Ctrl의 오른쪽에 Alt가 있는 것은 보장되지만 이것 말고 Fn, Win, 한자 키 같은 것은 생각보다 배치가 제멋대로이고 파편화가 심하다. 규격이 통일돼 있지 않다. 이것 때문에 한 키보드에 적응되고 나면 다른 키보드에서 modifier 키를 잘못 누르기 쉬워서 몹시 불편하다.

말이 나왔으니 하나 더.. 요즘 Windows 10은 사용자에게 선택의 여지를 안 주고 시도 때도 없이 강제 업데이트를 해서 꺼져야 할 때 바로 안 꺼지고, 켜져야 할 때 바로 안 켜지는 게 굉장히 싫다. 대규모 업데이트가 너무 잦고, 심지어 업데이트 후에 컴퓨터가 맛이 가는 것도 몇 번 겪어서 하기가 더욱 싫어진다. 그리고 컴퓨터를 오래 쓰고 나면 언제부턴가 시작 메뉴에서 앱들 검색이 제대로 동작하지 않기 시작한다. 나만 이러는 거 아니지?

그래서 인터넷을 뒤져서 이더넷 유선 랜도 데이터 요금이 부과되는 네트워크라고 속이는 레지스트리 패치를 적용시켰다. 그래야 운영체제가 제멋대로 깽판을 안 부린다. 제아무리 보안 업데이트도 인터넷 패킷 종량제 앞에서는 깨갱 할 수밖에 없으니까.

7. 삼각형의 오심을 그리는 프로그램

작년이니 엄청 옛날에 이미 작업된 사항이긴 한데, 막 중요한 건 아니어서 이제야 여기서 공지를 하게 됐다. 홈페이지의 '옛날 자료실'에 올라와 있는 '삼각형 오심을 그리는 프로그램'이 거의 10여 년 만에 기능이 크게 추가되고 보강됐다. 수학 강사인 교회 지인의 제안으로 행해진 작업이다.

삼각형의 오심이야 간단한 기하 알고리즘으로 (1) 두 직선의 교점과 (2) 두 변이 이루는 각을 이등분하는 변만 구할 줄 알면 컴퓨터로 아주 쉽게 구할 수 있다. 삼각형은 2차원 평면도형 중 가장 간단한 물건인데 얘의 모양에다 중심이라는 의미를 부여하는 방법도 이렇게 다양하다는 걸 알게 된다.

구체적인 개선 사항은 해당 웹페이지에도 나와 있지만, '구점원'이라는 걸 그리는 걸 추가했다. 삼각형 세 변들에 대해 변의 중점으로만 이뤄진 작은 삼각형의 외심원을 구한 것인데, 이게 또 방점과 접하고 수심을 지나기도 하는 등 기하학적인 의미가 장난이 아니다. 이걸 제6심이라고도 볼 수 있을지는 모르겠다.

그리고 내심을 제외한 수심, 구점원 중심, 무게중심, 외심 이렇게 네 점은 언제나 한 직선상에 있다는 게 보장된다..;; 이 오일러 직선을 그리는 기능도 추가했다.
또한 삼각형의 꼭지점만 마우스로 끌어서 이동시키는 게 아니라 삼각형 내부를 끌면 삼각형이 통째로 움직이게 했다. 한 점이 삼각형의 내부에 있는지 판별하는 건 세 점의 방향성 판별 공식을 이용해서 구현 가능하다.

웹브라우저에서 윤곽선 폰트 에디터까지 구동하는 세상인데 이런 간단한 그림을 그리는 프로그램쯤은 이제 플래시조차 필요 없고 HTML+(JS)로 다 만들 수 있을 것이다. 엔드 유저의 관점에서는 EXE 형태의 프로그램이 점점 필요 없어지고 있긴 한데, 일단 내가 아는 skill은 C++과 Windows API이니 저렇게 간다. GDI 말고 다른 API를 동원해서 선들을 안티앨리어싱도 좀 시킬 걸 하는 아쉬움도 남는다. 완벽하게 만들려고 욕심 부리면 뭐 한도 끝도 없다.

Posted by 사무엘

1. WNDCLASS와 HCURSOR

GUI 환경에서 키보드로 글자 입력을 받기 위해 캐럿(caret, 혹은 cursor)이라는 깜빡이는 세로줄이 나타난다면, 마우스의 입력을 받기 위해서는 마우스 포인터라는 게 떠 있다. 키보드 문자 입력과 마우스는 상호 배타적인 관계이다 보니, 문자 입력이 시작되면 마우스 포인터는 화면을 가리지 말라고 쏙 사라지곤 한다. 그 반면, 키보드 단축키와 마우스는 전혀 배타적이지 않고 상호 보완적이므로 이 경우는 마우스 포인터가 사라질 필요가 없다. 간단히 말해 스타를 하는 경우를 생각하면 된다.

Windows 운영체제 내부에서 생성되는 모든 창(window)들은 마우스 포인터가 자기 영역을 지날 때 어떤 모양의 포인터를 표시할지를 자유롭게 지정할 수 있다. 가장 static하고 간단한 방법으로는 윈도우 클래스를 등록할 때 WNDCLASS의 hCursor 멤버에다가 지정해 주면 된다.

HCURSOR라는 타입은 마우스 포인터의 모양을 나타내는 자료구조의 포인터이다. 마우스 포인터는 아이콘(HICON)과 거의 동급으로 취급되며, 아이콘에다가 중심 위치(hot spot) 정보만이 추가되었을 뿐이다. 화살표 그림의 경우 화살표가 가리키는 뾰족한 지점이 바로 hot spot의 위치가 되는 것이다.

그리고 그 아이콘이라는 것은 개념적으로 AND 연산용 비트맵(마스크)과 XOR 연산용 비트맵(그리기)이 추가된 정사각형 비트맵(HBITMAP) 쌍이다.
마우스 포인터 자체를 프로그램 코드를 통해 동적으로 생성하고자 한다면 이런 관계에 대해서도 이해할 필요가 있다. 이런 구조 덕분에 배경색을 반전시키는 마우스 포인터도 만들 수 있다. 또한, Windows에서 아이콘과 마우스 포인터가 매우 유사하게 취급된다는 것은 GetIconInfo 함수나 ICONINFO 구조체의 스펙을 보면 금방 수긍할 수 있다.

색깔 중에 system color가 있고 DC 오브젝트들(브러시· 펜 따위) 중에도 stock object가 있으며, 클립보드 포맷 중에 표준 포맷(CF_TEXT ...)이 있는 것처럼.. 마우스 포인터 중에도 용도가 고정되었고 운영체제 차원에서 모양을 공통으로 관리하는 것이 몇 종류 있다. 이런 공용 포인터의 예로는 일반 화살표, 모래시계, 입력란용 I-beam 등 우리에게 친숙한 것이 있으며, 이들은 제어판을 통해 그 모양을 바꿀 수 있다. 응용 프로그램에서는 LoadCursor(NULL, IDC_*)를 호출해서 이들의 HCURSOR 값을 얻을 수 있으며 이를 응당 클래스 등록 시에 사용하면 된다.

그래픽 에디터라든가 게임 급으로 정말 아주 튀는 GUI를 제공하는 프로그램을 만드는 게 아니라면, 공용 포인터 말고 다른 독자적인 포인터를 쓸 일은 잘 없을 것이다. 하지만 튀지 않는 일반 업무용 프로그램에서도 custom 포인터가 필요한 경우가 가끔은 있다.

• 워드 프로세서의 경우, IDC_IBEAM의 변형이 필요할 때가 있다. 이탤릭체 글자에서는 포인터의 모양도 살짝 기울어지며, 세로쓰기 모드에서는 포인터의 모양 역시 90도 돌아간다.
• drag & drop 상태를 표시하기 위해, 화살표 밑에 사각형 테두리와 [+] 마크가 붙은 포인터가 필요할 때가 있다. 이것도 의외로 공용 포인터에는 존재하지 않으며, ole32.dll 내부에 있는 비공식 리소스를 몰래 뽑아 와서 쓰는 경우가 많다.
• 먼 옛날, IDC_HAND가 존재하지 않던 Windows 95/NT4에서는 winhlp32.exe의 내부에 있는 손가락 링크 모양 비공식 리소스를 몰래 뽑아 와서 하이퍼링크를 구현할 때 쓰기도 했다.

LoadCursor는 원래 모듈(EXE/DLL)의 리소스로부터 마우스 포인터 그림을 추출하는 함수이다.
CreateCursor 함수는 HBITMAP을 받는 게 아니라 쌩짜 AND/XOR 비트맵 배열만을 입력받아서 포인터를 생성해 주는데, 그 말인즉슨 얘는 애초에 모노크롬 포인터밖에 못 만든다는 뜻이다. 컬러를 지원하지 않는다.

그러고 보니 마우스 포인터는 마치 GIF처럼 애니메이션 가능한 버전도 생겨서 단순 아이콘과 차별화가 이뤄지긴 했다. ico 파일에는 크기와 화질이 다른 여러 아이콘들이 있을 수 있다면, ani에는 동일 아이콘의 여러 프레임이 들어갈 수 있게 된 것이다. 교집합인 정보가 있지만 서로 완전히 호환되지는 않는 미묘한 관계가 됐다.

2. WM_SETCURSOR와 SetCursor 함수

윈도우 클래스를 등록할 때 hCursor 멤버에다가 NULL을 지정하면 그 윈도우는 마우스 포인터가 기본적인 화살표로 지정된다거나, 아니면 말 그대로 아무것도 없는 올투명 이미지가 지정되어서 포인터가 사라진다거나 하지 않는다.
어찌 되는가 하면, 이 윈도우 영역으로 들어오기 직전에 유지되었던 마우스 포인터가 변경 없이 그대로 유지된다..! 마치 C언어에서 초기화되지 않은 변수처럼 undefined 상태가 되는 것이다.

이런 동작을 원하는 프로그래머나 기대하는 사용자는 전무할 것이다. 그러므로 클래스 차원에서 지정된 기본 포인터가 없는 윈도우는 자신의 윈도우 프로시저 내부에서 매번 실시간으로 마우스 포인터를 지정해 줘야 한다. 어떻게? WM_SETCURSOR라는 메시지가 왔을 때 SetCursor라는 함수를 호출해서 하면 된다.
아니 사실은 클래스 포인터가 이미 지정돼 있는 창이라도 필요하다면 이렇게 마우스 포인터를 실행 중에 얼마든지 변경할 수 있다. 동일한 웹브라우저 창이라도 포인터가 링크 위를 가리키고 있을 때는 조건부로 손가락 모양으로 바뀌어야 할 테니까 말이다.

윈도우 안에서 마우스 포인터가 움직이면 WM_MOUSEMOVE만 오는 게 아니라 그 전에 WM_SETCURSOR부터 날아온다. 그에 반해 SetCursor는 굳이 WM_SETCURSOR 메시지 타이밍이 아니어도 아무 때나 언제든지 호출 가능하다. 이 함수 자체는 지금 포인터가 나 자신이(스레드 단위) 생성한 윈도우에만 있으면 위치 불문하고 포인터 모양을 즉시 바꿔 준다. WM_PAINT 타이밍 때에만 사용 가능한 BeginPaint/EndPaint처럼 특정 메시지에 매여 있는 게 아니라는 뜻이다.

그럼 왜 굳이 WM_SETCURSOR라는 메시지가 따로 있는 것일까? 그 이유는 저렇게 일상적으로 마우스 포인터가 움직였을 때 빼고는 얘는 WM_MOUSEMOVE와는 설계 철학과 생성 조건이 매우 다르기 때문이다.

• 윈도우가 disable됐을 때는 그 윈도우로 마우스가 움직이더라도 통상적인 WM_MOUSEMOVE가 오지 않는다. 그러나 이때에도 WM_SETCURSOR는 전달하는 상황 정보(hit-test code)만 달라진 채 언제나 온다.
• hit-test code가 같이 온다는 점에서 유추할 수 있듯, WM_SETCURSOR는 클라이언트와 논클라이언트를 가리지 않고 온다. 그에 반해 WM_MOUSEMOVE는 클라이언트 영역 전용이고 WM_NCMOUSEMOVE가 따로 있다.
• 마우스가 capture된 뒤부터는 마우스가 움직이면 반대로 WM_MOUSEMOVE만 오지 WM_SETCURSOR는 오지 않는다. 마우스의 포커스가 포인터 위치와 무관하게 이 윈도우에 집중되었기 때문에 포인터의 모양도 잠시 고정된다.
• 그리고 결정적으로.. WM_MOUSEMOVE는 지금 화면을 대면하고 있는 최하위 child 윈도우에 직통으로 전달되는 반면, WM_SETCURSOR는 최상위 parent 윈도우에 먼저 전달되어서 얘들이 처리를 포기/거부했을 때에만 child로 내려간다.

마지막 항목이 중요하다. 이런 메커니즘의 차이로 인해 두 메시지는 서로 호환성이 전혀 없으며 별도의 메시지로 분리되어야만 한다. 이 메시지가 그냥 이 시점에서 표시할 HCURSOR 값만 곱게 얻는 게 목적이라면 WM_SETCURSOR 메시지는 SET이 아니라 GET이라는 동사가 붙어서 WM_GETCURSOR, WM_QUERYCURSOR처럼 명명됐을 수도 있다. 대화상자의 WM_GETDLGCODE 메시지처럼 그냥 return (LRESULT)LoadCursor(...)의 형태.
그런데 그게 아니기 때문에 자기가 직접 마우스 포인터를 재지정할 의향이 있다면 WM_SETCURSOR가 올 때마다 SetCursor를 수동으로 매번 호출도 해야 하고, 그러면서 리턴값도 0이 아닌 값으로 되돌려야 한다. 특히 DefWindowProc를 호출해서는 안 된다.

DefWindowProc가 WM_SETCURSOR 때 하는 일 중에는 논클라이언트 영역에서 포인터를 화살표 내지 창의 크기 조절 손잡이 모양으로 바꾸는 것이 포함돼 있다.
하지만 클라이언트 영역에서 DefWindowProc은 "난 마우스 포인터 모양을 자체적으로 처리할 의향이 없으니, (1) 내 부모 윈도우에서 이의 없으면 (2) 최종 처리를 내 자식 윈도우에 맡기겠소"라는 의미가 된다. Def..없이 return 0은 (2)만을 담당한다.

참고로, SetCursor(NULL)을 하면 클래스 WNDCLASS::hCursor = NULL과는 달리 비로소 마우스 포인터가 화면에서 사라진다. 이것은 HideCursor / ShowCursor 함수와 비슷한 효과를 낸다. 이들 함수는 포인터의 레퍼런스 카운터를 1 증가나 감소시켜서 카운터가 양수이면 포인터를 계속 표시시키고, 그렇지 않으면 계속 감추고 있는다. 캐럿을 표시하거나 감추는 ShowCaret / HideCaret과 비슷한 원리로 동작한다.
그에 반해 SetCursor(NULL)은 효과가 일시적이므로 해당 윈도우가 WM_SETCURSOR에서 계속해서 SetCursor(NULL)을 해 줘야만 포인터가 없는 상태가 유지된다.

사소한 사항이다만, WM_MOUSEMOVE는 메시지 큐에 post 형태로 전해지는 반면, WM_SETCURSOR는 리턴값을 꼼꼼히 확인해야 하기 때문에 언제나 sent된다는 차이도 있다. 마우스 메시지 훅킹 같은 걸 한다면 요런 차이가 민감하게 와 닿을 것이다.

3. 대기 상태 표현하기

프로그램이 파일을 읽고 쓰고 복잡한 계산을 시작해서 대략 0.n초 정도 짤막하게 사용자의 응답(더 정확히는 운영체제 메시지)에 반응을 하지 않게 됐다면, 이에 대해 가장 간단하게 피드백을 주는 방법은 SetCursor(LoadCursor(NULL, IDC_WAIT))를 해서 마우스 포인터를 그 악명 높은 모래시계 모양으로 바꾸는 것이다.

물론 처리가 끝났다면 포인터 모양을 원상복구 해야 한다. 이것은 SetCursor의 리턴값을 보관하고 있다가 도로 전달하는 것으로 쉽게 구현 가능하며, 이렇게 시작과 끝을 생성자와 소멸자에다 넣어서 간단한 C++ 클래스를 구현할 수도 있다. MFC에 있는 CWaitCursor가 그 예이다.
모래시계로 변해 있던 동안 마우스 포인터가 조금이라도 다른 곳으로 이동했거나, 위치가 안 바뀌었더라도 그 사이에 포인터 아래의 윈도우가 바뀌었다면.. 프로그램이 의식을 회복(?)했을 때 WM_MOUSEMOVE와 그에 상응하는 WM_SETCURSOR도 오기 때문에 포인터 모양이 자동으로 갱신되긴 한다. 그러나 그런 외부적인 변화가 전혀 없었더라도 포인터 모양이 원상복귀 되어야 하니까 말이다.

마우스 포인터의 움직임은 일종의 하드웨어 인터럽트 형태로 발생하며, 응용 프로그램이 WM_SETCURSOR 메시지에 응답하지 않고 있더라도 포인터가 움직인 것에 대한 반응은 해야 한다. 그렇기 때문에 프로그램이 처리를 열심히 하고 있는 동안에는 좀 전에 지정된 모래시계 모양이 유지된다. 물론, 포인터가 정상적으로 응답 중인 다른 프로그램 창 위에 놓여 있으면 거기 모양으로 바뀌며, 한 프로그램이 수 초 이상 너무 오랫동안 응답을 안 하고 있으면 그건 그것대로 문제가 된다. 내 프로그램 창이 고스트 윈도우로 바뀌는 일은 없어야 한다.

시간이 굉장히 오래 걸리는 작업을 한다면 프로그램의 디자인 형태가 바뀐다. 작업은 백그라운드 스레드에다 담당시키고 프로그램은 현재 진행 상황을 출력하면서 UI 메시지 반응도 평소처럼 한다. progress 컨트롤이 장착된 대화상자가 이 역할을 하며, 사실 Windows Vista부터는 task dialog로 이걸 간단하게 띄울 수도 있게 됐다.
동영상 인코더처럼 input 데이터를 직접 생성하고 작성하는 기능은 없고, 이미 있는 데이터를 변환하는 일이 전부인 프로그램이라면 별도의 대화상자 없이 자기 main frame window 자체가 통째로 진행 상황을 표시하는 용도로 쓰이기도 한다. <날개셋> 변환기도 이런 형태의 프로그램이다.

이를 좀 더 일반화해서 생각하면 이렇다. 어떤 윈도우가 하는 역할이 자신과 별개이고 독립적인 타 작업의 진행 상황을 관찰하면서 표시하는 게 전부라면, 보통은 그 윈도우 내부의 마우스 포인터를 굳이 별도로 모래시계 모양으로 바꾸지 않는다. 설치 프로그램들이 그 예이다. 다만, Windows Installer 엔진의 경우 본격적으로 설치/제거를 수행하는 마법사가 뜨기 전에 준비 작업을 하느라 자그마한 대화상자가 떴을 때는 마우스 포인터를 거기로 가져가면 모래시계로 바뀐다.

요런 게 대화상자 윈도우에서 WM_SETCURSOR를 처리함으로써 구현 가능하다. 이 메시지는 부모-자식 top-to-bottom 형태로 내려가기 때문에, 부모에서 메시지를 가로채 버리면 자식 윈도우의 의도와 상관없이 마우스 포인터를 모래시계 모양으로 바꿀 수 있다. 밑에 지금 무슨 윈도우가 있는지 핸들도 wParam으로 친절하게 전달된다. 여기서 SetCursor 호출만 하고 리턴값으로 nonzero를 지정하지 않으면, 대화상자 배경들만 포인터가 바뀌고 버튼 같은 각종 컨트롤들은 바뀌지 않게 된다. (위의 스크린샷처럼)

이와 대조적으로, 키보드 메시지는 포커스를 잡고 있는 최하위 윈도우에 직통으로 전달되니(bottm-to-top), 그 위에서 공통 단축키 같은 걸 처리하려면 message loop 차원에서의 pre-processing이 필요한 것이다.

<날개셋> 변환기의 경우 변환하는 파일이 적으면 스레드 없이 그냥 비응답 상태로 빠진 채로 변환을 수행한다. 그러나 수십 개, 수MB 이상 분량 파일을 요청하면 대화상자의 모든 컨트롤들을 disable시키고 progress 컨트롤을 출력하고, 대화상자 내부의 마우스 포인터를 모래시계로 바꾼 뒤 변환을 수행한다. 이때는 어차피 대화상자의 다른 기능들을 전혀 사용할 수 없고 ESC나 [X]를 눌러 중간 취소만 가능하기 때문이다.

그리고 하나 더 생각할 만한 상황은.. 딴 작업이 아니라 대화상자 자기 내부에다 출력할 데이터들을 준비하고 초기화하는 작업이 시간이 좀 오래 걸릴 때이다. <날개셋> 한글 입력기 제어판의 대화상자에도 그런 경우가 몇 가지 있다.
이때는 문제의 콤보나 리스트박스가 빈 채로 먼저 대화상자를 출력한 뒤, 스레드를 만들고 마우스 포인터를 IDC_WAIT가 아니라 IDC_APPSTARTING 모양으로 바꿨다. 대화상자가 출력은 됐지만 아직 초기화가 덜 돼서 백그라운드에서 작업 중임을 이렇게 나타낸다.

요렇게 백그라운드의 스레드 작업이 끝난 뒤에는 마우스 포인터를 어떻게 원상복구 할지가 문제가 된다.
아까처럼 스레드 없던 시절에는 작업하던 사이에 포인터 위치가 바뀌었으면 WM_SETCURSOR와 WM_MOUSEMOVE가 자동으로 생겼다. 그러나 지금은 그렇지 않다. 작업이 수행되던 중에 포인터 이동에 대한 처리는 이미 다 이뤄졌기 때문이다.

마우스 포인터의 이동 없이 아래의 창에다가 WM_SETCURSOR를 인위적으로 생성해서 포인터 모양을 원래 것으로 갱신할 수 있어야 하는데.. 이것만 어떻게 하는지 잘 모르겠다.
일단 본인이 사용하는 방법은 GetCursorPos로 현재 포인터 위치를 얻은 뒤, 그거 그대로 SetCursorPos를 하는 것이다. 위치가 바뀐 게 없음에도 불구하고 이렇게 하면 WM_SETCURSOR와 WM_MOUSEMOVE가 생성되기는 하는 것 같더라.
이 정도면 Windows 프로그래밍에서 마우스 포인터 제어와 관련해서 어지간한 문제는 다 다룬 것 같다.

Posted by 사무엘