지속적인 리팩토링으로 이 지경까지 오지 않도록 하는 것이 최선이었겠지만 어쩌다보니 여기까지 왔네요. ㅎㅎ~ 확 뜯어 고친다는 건 양날의 검과 같은 작업이지요. 겁도 났지만 시작하길 잘했다는 생각이 듭니다. 일주일 넘게 작업한 것 같은데 오늘 드디어 5개 프로젝트 정도를 손봐서 하나의 모듈을 대략 끈냈습니다. 후훗. 홀가분하네용. 아직 남은 게 태산이지만 ㅋㅋㅋ~

택도아닌 스레드 스택에 말리는 바람에 시간이 엄청 걸렸네용.
애꿏은 윈도 소스만 연나 뒤적였네요. ㅎㅎ

“빌게이츠의 야망을 가진 남자들”. 책 제목만 보면 무슨 삼류 통속 소설 같은 삘이 확 느껴지는 책이죠. 원서 제목은 “Show-stopper!: Breakneck Race to Create Windows NT and the Next Generation at Microsoft”입니다. 정말 왜 저렇게 통속적으로 제목을 바꿨는지 도저히 이해할 수 없습니다. 엉뚱한 책 제목 베스트 10 정도에는 뽑힐 법한 번역서 제목이죠. 참고로 쇼스토퍼란 NT 개발팀이 NT를 중단시킬 만큼 치명적인 버그를 지칭하는 말입니다.

이 책은 Windows NT의 개발 스토리를 담고 있습니다. 커틀러 팀이 마이크로소프트에 합류하게 된 부분부터 Windows NT의 초기 버전 릴리즈 까지의 내용이죠. Windows NT는 1989년 부터 본격적으로 개발이 시작되어서 1993년에 첫 릴리즈가 배포됩니다.  근 5년간 개발된 것이죠. NT는 실로 방대한 프로젝트 였습니다. 첫 릴리즈 버전의 코드가 530만 라인이 넘었으며, 참여한 개발자만 거의 300명에 육박했습니다. 좀 놀라운 프로젝트죠.

이 책의 스토리 중심에 데이비드 커틀러가 있습니다. 데이비드 커틀러는 NT의 아버지로 불리는 사람으로 실제로 NT의 코어 아키텍처부터 운영 체제의 여러 부분을 설계, 코딩 했습니다. 커틀러는 마이크로소프트로 오기 전 디지털에서 VMS라는 운영체제를 성공적으로 개발했던 적이 있었죠. 사실 운영체제 개발 쪽에 있어서는 전설적인 인물입니다. 상용 운영체제를 세 번 넘게 성공적으로 개발한 사람은 전 세계를 통틀어서 딱 한 명 뿐인데,  그 사람이 바로 데이비드 커틀러죠.

NT 프로젝트 진행 과정을 보면서 가장 놀라운 점은 저렇게 거대 괴물 같은 아웃풋이 결국은 나왔다는 점 입니다. 정말 우여곡절도 많고 사람들이 좌절하는 시간도 많았습니다. 정치적인 이슈 사항도 많았죠. 하지만 결국 운영체제는 릴리즈가 됩니다. 소프트웨어 시간에서 5년이란 시간이 길지 않은 시간이고, 운영체제란 놈은 실로 괴물같은 놈임을 가만할때 커틀러 팀은 대단하다고 밖에 말할 수 없습니다. 그렇게 많은 장애물들이 있음에도 멋진 운영체제가 나올 수 있었던 건 커틀러 자신은 정확하게 무엇을 어떻게 만들어야 할지 알고 있었기 때문이 아닐까란 생각이 들었습니다.

두 번째로 놀라운 점은 커틀러는 소신을 굽히지 않는 엔지니어 였다는 점 입니다. 커틀러가 설계한 초창기 NT 커널은 마이크로 커널의 특징을 많이 가지고 있었습니다. 안정성이 높은 대신 느리고 컸죠. 게이츠는 이 설계 방식에 대해서 꾸준히 의문을 제기합니다. 하지만 커틀러는 안정성이 더 중요하다는 자신의 뜻을 굽히지 않습니다. 성능은 자신의 코딩 테크닉을 통해서 극복할 수 있다고 주장했죠. 그리고 결국 설계를 크게 변경하지 않는 선에서 운영체제 개발을 끝냈습니다. 지금의 NT 커널은 하이브리드 커널로 분류됩니다. 마이크로 커널과 모놀리틱 커널의 특징을 비슷하게 가지고 있기 때문이죠. 그게 커틀러가 말한 테크닉인지도 모르겠네요.

89년도 NT가 개발되기 시작한 시점부터 최근 윈도우 7이 나오기 까지 근 20년 가까운 세월이 흘렀습니다. 재미있는 사실은 그 때 커틀러가 작성한 코드가 여전히 윈도우 7에 포함되어 있다는 사실입니다. 책의 주요 인물들이 작성한 코드들이 아직도 운영체제 속에 살아있는 것이죠. 이 책을 보고 그 코드들을 다시 들여다보니 그 때 그 사람들의 땀방울이 느껴지는 듯 하는군요. 엔지니어로써 이보다 더 뿌듯한 일이 있을까요? ㅎ~ 20년이란 세월을 버티는 코드를 만든다는 일… 흠~

이러한 것 중에 하나가 유니코드 함수에 대한 지원이다. 윈도우에 포함된 거의 대부분의 함수는 유니코드 버전은 끝에 W가 붙어있고, 안시 버전은 A가 붙어있다. 글자가 붙어 있지 않은 기본 함수는 프로젝트 셋팅에 따라서 달라진다. 즉, 아래와 같이 기본적으로 API를 설계한다는 이야기다.

void SomeGoodFunctionA(LPCSTR parameter);
void SomeGoodFunctionW(LPCWSTR parameter);

#ifdef _UNICODE
#define SomeGoodFunction SomeGoodFunctionW
#else
#define SomeGoodFunction SomeGoodFunctionA
#endif

그런데 그 많은 함수들 – API는 정말 많다 — 중에 저런 원칙을 어긴게 하나도 없을 순 없다. 그 중 대표적인 놈 하나가 툴헬프 라이브러리다. 전통적으로 NT 시스템은 psapi를 사용하고, 9x 시스템은 툴헬프를 사용한다. 이 녀석들의 역할은 프로세스 열거, 모듈 열거 따위를 하는 일이다. 여튼 툴헬프 라이브러리는 조금 엉뚱한 방식으로 포팅이 되거나 진화가 되었다.

9x 시스템의 툴헬프에는 Module32FirstW 함수가 없다. 좋다. 여기까진 그럴수도 있다. NT에는 Module32FirstW 함수가 있다. 그렇다면 NT에는 Module32FirstA 함수가 있을까? 없다. 9x에도 없다. Module32First란 이름의 함수는 안시를 입력받도록 설계되어 있고, Module32FirstW만 추가된 형태로 NT에 있는 것이다. 즉 다음과 같이 되었다는 이야기다.

BOOL WINAPI Module32First(HANDLE, MODULEENTRY32);
BOOL WINAPI Module32FirstW(HANDLE, MODULEENTRY32W);

이해할 수 있는 부분이다. 원래 A함수가 없었고, W 함수만 NT에 추가되었다고 생각할 수 있다. 그런데 문제는 이것을 포함하고 있는 tlhelp32.h다. 이 파일은 Module32First 함수가 일반적인 함수와같이 설계가 되었다고 생각한다. tlhelp32.h에서 가장 문제가 있는 줄은 다름아닌 다음과 같은 라인이다.

#ifdef UNICODE
#define Module32First Module32FirstW
#define Module32Next Module32NextW
#define MODULEENTRY32 MODULEENTRY32W
#define PMODULEENTRY32 PMODULEENTRY32W
#define LPMODULEENTRY32 LPMODULEENTRY32W
#endif  // !UNICODE

즉, 유니코드 환경에서는 Module32First를 Module32FirstW에다 맵핑을 시켜 버리는 것이다. 그렇다면 위 헤더를 추가하는 순간부터 우리는 영영 유니코드 환경에서는 Module32FirstA에 해당하는 Module32First 함수를 호출할 수 없게 된다. 즉, 툴헬프 함수는 환경에 따라서 한 가지 버전밖에 호출을 못하는 것이다. 일반적인 상황에서는 문제가 없지만 한 컴파일 단위에서 A/W 함수를 모두 호출해야 하는 상황에서는 쪼다가 된다. 그런 상황이라면 아래와 같이 tlhelp32.h를 포함한 다음 정의를 전부 해제해 주면 된다.

#include <tlhelp32.h>

#undef Module32First
#undef Module32Next
#undef MODULEENTRY32
#undef PMODULEENTRY32
#undef LPMODULEENTRY32

A/W에 대한 약간의 편집증이 있는 개발자라면 아래와 같은 방법을 추가할 수도 있다.

#define Module32FirstA Module32First
#define Module32NextA Module32Next
#define MODULEENTRY32A MODULEENTRY32
#define PMODULEENTRY32A PMODULEENTRY32
#define LPMODULEENTRY32A LPMODULEENTRY32

많은 C 개발자들은 이렇게 생각합니다. “흠, 파이썬으로 할 수 있는걸 난 C로도 다 할 수 있는 걸. 그것도 충분히 빠르게.” 하지만 그 사람은 아직 모르고 있는 거죠. 얼마나 더 빨리 만들 수 있는지를 말입니다. 경험해 보기 전에는 더 빠른 세상이 있는지를 모르는 것과 같겠죠.

파이썬 공부하지 마세요… ㅎㅎ~

P.S) TAOCP를 질렀습니다. 예전에 영문판보고 좌절했던 기억이 있는데 겁없이 또 한글판 질렀습니다. 같이 공부하실 분 안계신가요? 저 책은 정말 혼자서는… 좌절이더군요. Windows Internals와 더불어 베개로 전락하는 삼대 명서 중 하나인 것 같습니다. 카누쓰 교수님의 정기를 좀 받을 수 있을런지… ㅋㅋ~

지난 달에는 부산에 치과 치료를 받으로 휴가를 얻어 가던 기간이 마침 원고 마감일이랑 겹쳐서 노트북을 들고 갔었다. 그런데 회사에서 작업하던 다 써둔 원고 초안을 서울에 두고 가는 바람에 상당 부분을 집에서 새로 써야 했다. 혹자는 자기가 썼던걸 다시 쓰는게 뭐가 그리 어렵냐고 반문하지만 썼던 걸 다시 쓰는 것 만큼 짜증나는 일도 없다. 어쨌든 결국 원고는 마감 날짜에 다 못썼고, 서울에 와서야 완성을 하게 되었다. 기자님께 죄송하다는 말과 함께 메일을 보냈다. 내가 보내는 원고 메일엔 항상 죄송이라는 단어가 포함된다. 마감을 제대로 지켜서 내본게 언젠지 참… ㅎㅎㅎ~

지난 달에 난 미리 원고를 써 두리라 다짐했다. 하지만 방학 숙제 마냥 그게 잘 지켜질리는 만무하다. 계획성 없는 나는 어렸을 때에도 항상 방학 숙제를 하나도 하지 않아서 마지막 주말에 엄마한테 오지게 혼나곤 했다. 하지만 오지게 혼나고 나면 늘 마법같은 방학 숙제는 등교날 나의 손에 쥐어져 있었다. 누나들이 겪었을 고통이란 ㅎㅎ~ 어쨌든 하야토에게 주어진 마지막 코너처럼, 나에겐 늘 마지막 주말이 주어진다. 이번 주말이 그런 주말이다.

당연히 이 글의 존재가 의미하듯 이번 주말도 그냥 넘어가는 법은 없다. 고등학교 친구 녀석이 집엘 놀러온 것이다. 생전 서울이라곤 안오던 놈인데, 몇 일 전 아는 사람을 만난다고 약속이 있다고 해서 온다고 전화가 왔다. 친한 녀석이라 거절하기도 뭣해서 그러라고 했다. 사실 약속 당일날 올라오기가 뭣해서 전날 우리집에서 하루 정도 숙식하는 거라 생각했다. 안본지 오래지 않았지만 어쨌든 한달만에 보는 친구 얼굴은 반가웠다. 거기까진 좋았다. 그런데 문제는 그 다음이다. 그 녀석의 약속 이야기를 곰곰 듣다보니 이건 뭐 정해진 것도 아니고, 만날 수도 있고 안만날 수도 있는 아주 애매모호한 형태의 약속인 것이었다. 사실 내가 봤을때는 저런 걸로 서울까지 왜 왔지, 라는 생각이 드는 정도였다. 어쨌든 난 졸지에 그 놈의 주말을 책임져야 하는 입장이 되었다.

난 그냥 조용이 앉아서 음악이나 들으며 원고 쓰고 싶을 뿐이고, 친구 온다는 거 안말렸을 뿐이고, 친구 약속 없어졌을 뿐이고, 엄마 보고 싶고, …

나의 어정쩡한 우유부단함에 키스를…
이 느낌은 머지? ㅎㅎ~

10일이 생일이었습니다. 9일날 저녁에 케잌에 불을 밝히면서 다음 날 블로그에 올려야지 하는 생각으로 사진을 한 컷 찍었습니다. 그런데 다음 날도, 그 다음 날도, 그 다음 다음 날도 못 올리고, 이제서야 올리네요. 요즘 참 여유가 없는 것 같습니다. 출근하면 할 일이 왤케 많은지. 메신저, 메일에 치여서 정리를 좀 했다 싶으면 하루가 다 가 버리네요. 그래도 재미는 있습니다. 만들고 있는 제품이 조금은 괜찮아진다는 느낌이 들기 때문이겠죠. ㅋ~

누구 이야기처럼 블로그가 너무 업데이트가 되지 않았네요. 회사 업무외에도 신경 쓸 일들이 많아서 사실 블로깅을 많이 하지 못했습니다. 많진 않지만 RSS 구독 하시는 분들께 정말 죄송스럽군요. ㅎㅎ~  앞으로는 좀 더 자주 업데이트 하도록 하겠습니다.

어제 집에 컴퓨터를 Internet Explorer 8로 업그레이드를 하고 글을 쓰려는데 태터 툴즈 동작이 이상하더군요. 이제는 더는 아니다, 라는 생각으로 미련없이 새로운 툴로 갈아 탔습니다. 기존 자료 링크를 위해서 블로그를 폐쇄 하지는 않았습니다. 기존 블로그 자료를 보고 싶으신 분들은 http://www.jiniya.net/tt로 접속하시면 됩니다. 워드프레스를 처음 설치해 봤는데 적응하는데 힘드네요. 아직도 어떤 기능이 어디에 숨어 있는지 모르겠습니다. 차츰 나아지겠죠. ㅎㅎ~

얼마 전에 회사 자리를 새롭게 옮겼습니다. 비오는 날 집도 대 청소를 했었습니다. 블로그도 새롭게 정리 했으니 이젠 열심히 달리는 일만 남았네요. 새로운 출발을 한다는 것. 출발선에 서 있다는 건 항상 설레는 일인 것 같습니다. 뭔가 가능성이 있는 것 같으니깐요. 기분 탓이겠죠. ㅋㅋ~

최근에 드라이버 프로그램 하나를 릴리즈할 일이 있었다. 계획에도 없던 것이라 성급한 일정, 준비되지 않은 계획, 거침없는 코딩, 끝없는 밤샘 작업을 통해서 결국 드라이버는 릴리즈 되었다. 결과는? 당연히 엄청난 양의 BSOD와 문제점들로 나타났다. 이러한 디버깅 경험이 늘어나면서 몇 가지 사소한 생각들이 디버깅 시간을 지나치게 지연시킨다는 사실을 발견했다. 물론 좋은 책들에서 이미 모두 다 언급해버린 것들이지만 아직도 그 부분을 미처 읽지 못했던 분들을 위해서 반성문 같은 글을 적어보려 한다.

#0: 코드에 대한 지나친 신뢰는 금물이다.
우리를 방해하는 가장 큰 산은 지나친 신뢰다. 특히나 코드에 대한 지나친 신뢰는 버그 소탕과는 영영 멀어지게 하는 지름길이다. 개발자들이 흔히 하는 말이 있다. 원래 잘 동작하는 코든데요. 하지만 원래라는 말은 따져 본들 의미도 없을뿐더러 그 말이 사실이라면 그 코드는 지금부터 제대로 동작하지 않는 코드라고 생각하는 것이 정신 건강에 좋다. 

CPU 점유율과 관련된 이슈 사항이 보고 되었다. 일부 PC에서 CPU 점유율이 과도하게 높다는 것이었다. 일부 PC를 가질 수 없는 우리 입장에서는 당연히 왜 그런 일들이 발생했는지를 생각하고, 코드를 검토해보는 일이 최선이다. 이 과정에서 나는 이전 드라이버에서부터 잘 사용해왔던 IRQL Hack 관련 코드는 검토 대상에서 제외했다. 물론 의도적으로 제외한 것은 아니었지만 이건 아니겠지 하는 심정으로 코드를 검토한 것이었다. 지난 드라이버에서도 잘 사용했던 코드였고, 그 드라이버를 통해서는 그런 보고를 받은 적이 한 번도 없었기 때문이었다. 하지만 결과적으로 버그의 원인은 IRQL Hack 코드에 있었다. 지난 번 드라이버와의 차이점은 그 코드를 호출하는 시점에 있었다. 

#1: 성급한 단정은 절대 피하자.
단정은 금물이다. 생각은 물과 같아서 한번 길을 터주면 그 곳으로만 흐르려는 습성이 있다. 따라서 절대로 마음속으로라도 단정은 하지 않는 것이 좋다. 항상 모든 가능성을 열어두라는 의미다. 

특정 PC에서 특정 보안 제품을 설치하자 드라이버가 로딩이 되지 않는 문제가 발생했다. 정상적인 두뇌를 가진 인간이라면 디버깅 버전의 드라이버를 넣어보거나 해서 무엇이 문제인지를 찾는 작업에서 시작을 할 것이다. 하지만 이전에 해당 보안 제품을 테스트 하던 과정 중에 특정 바이너리 시그니처만 포함시키면 드라이버 로딩을 펜딩 시키는 현상을 경험했던 나는 해당 보안 제품이 우리 쪽 드라이버 로딩을 차단했다고 생각을 해버렸다. 이렇게 단정이 지어지고 나니 계속 그 보안 제품에 대한 코드만 검토하게 되었다. 해당 보안제품의 훅 코드에서부터 드라이버 코드까지 말이다.

몇 시간을 뒤졌지만 이상한 점을 찾지 못했다. 당연했다. 문제는 우리 쪽 코드에 있었기 때문이다. 원인은 커널에서 사용하는 시스템 콜백 루틴에 있었다. 그 루틴은 보통 8개까지 등록을 할 수 있도록 제한되어 있다. 문제가 발생한 PC에는 과도하게 많은 보안 제품이 설치되어 있어서 그 특정 보안 제품이 설치되면서 8개를 모두 사용했던 것이다. 그것을 지우면 7개가 되면서 우리가 등록할 수 있는 상황이었던 것이었다. 정상적인 디버깅 루트를 따랐더라면 30초면 해결할 수 있는 문제를 성급한 단정으로 인해서 5시간이 넘도록 고생했던 것이다. 물론 그 디버깅 시간이 죄다 의미 없지는 않았지만 말이다.

#2: 경계를 넘는 순간 믿을 수 있는 정보는 하나도 없다.
윈도우 개발자라면 누구나 MSDN은 틀리지 않았다는 사실을 믿고 싶어한다. 하지만 그 방대한 MSDN도 틀린 곳이 없을 수는 없으며, MSDN의 예제 코드 중에도 문제를 일으킬만한 소지를 담고 있는 것도 있다. 특히나 이런 것들은 알려지지 않은 테크닉을 사용한 코드와 결부될 때 더 두드러지게 나타난다.

특정 상황에서 KeSetEvent의 호출로 BSOD가 발생하는 현상이 나타났다. DDK 문서에 따르면 KeSetEvent는 IRQL에 상관없이 사용할 수 있다고 언급되어 있다. 또한 그렇게 사용하기 위한 모든 조건을 해당 코드는 충족 시키고 있었다. 하지만 특정 부분에서 호출하는 KeSetEvent는 100% BSOD를 발생시켰다. 결국 원인은 해당 함수의 호출 지점에 있었다. KeSetEvent를 호출하면 내부적으로 커널 디스패처 락이라는 것을 획득하려는 시도를 한다. 그런데 우리가 호출한 KiSwapProcess라는 후킹 함수에서는 이 락이 이미 획득된 상태였던 것이다. 이 상태에서 KeSetEvent를 호출하면 그 락을 다시 획득하려는 시도를 하게 된다. 그러면서 시스템은 안드로메다로 가버린 것이다. 커널 디스패처 락은 외부로 노출된 객체가 아니기 때문에 일반적인 상황에서는 해당 락을 획득한 상태에서 작업할 일이 없다. 하지만 시스템 내부 함수를 후킹하면서 그런 가정이 깨져버린 것이다.