누군가 저에게 직업 개발자로써 가장 피곤한 일이 무어냐고 물어본다면 전 딱 두 가지를 말할 겁니다. 하나는 제가 만들기 싫은 것도 만들어야 한다는 것이고, 나머지 하나는 경계선을 제가 정할 수 없다는 것 입니다. 그 중에서도 제일 피곤한게 이 경계선입니다. 가장 악몽같은 경계가 운영체제죠. 그 경계에서도 끝판 대장은 바로 Windows 9x입니다.
회사에서 만드는 프로그램은 지금 이 시점에서도(옛날 시점입니다) Windows 98을 여전히 지원해야 합니다. 심한 경우에는 Windows 95 OSR2까지 지원하기를 요청받는 경우도 있습니다. Windows 95 OSR2에 얼마나 많은 API가 없는지 알게된다면 분명 피토하고 쓰러질 겁니다. ㅎㅎ 각설하고 오늘 알게된 Windows 98의 놀라운 현상에 대해서 알려드리겠습니다. 아래 스크린 샷을 한 번 살펴보도록 합시다.
이상한 걸 발견하셨나요? 그렇습니다. MSGSRV32.EXE란 프로세스의 모듈 목록에 MSGSRV32.EXE가 없습니다. 이 무슨 얼토당토 않는 상황일까요? 그런데 이런 프로세스가 한 두개도 아니고 부지기수로 발견됩니다. 희한한 일이 아닐 수 없습니다. 해당 프로세스의 모듈 목록에 그 프로세스가 없다니요? 물론 다 없으면 98의 프로세스 관리는 그렇게 되는거구나라고 이해하고 넘어갈텐데 그렇지도 않습니다. 있는 것이 좀 더 많고, 없는 것이 나머지 입니다. 당황스럽습니다. 그 위에 부모 프로세스가 KERNEL32.DLL인 것도 조금 당황스럽긴 하네요. ㅎㅎ
비밀을 파헤치기 위해서는 Toolhelp32 라이브러리를 살펴보는 것이 도움이 됩니다. Toolhelp32로 프로세스와 모듈을 열거하면 나오는 구조체는 다음과 같은 모양을 하고 있습니다. 비밀은 구조체 속에 있는 th32ModuleID에 있습니다. 지금은 사용되지 않는 이 필드를 통해서 9x는 모듈 관리를 하고 있답니다. 물론 그 체계도 우리가 상상하는 그것과는 완전히 다르답니다. 보다 더 자세한 내용이 궁금하신 분들은 도서관에 가셔서 매트 피에트릭을 영접하시기 바랍니다. 어쨌든 9x에서는 프로세스 빠진 모듈 목록이 이상한 현상은 아니랍니다.
typedef struct tagPROCESSENTRY32 {
DWORD dwSize;
DWORD cntUsage;
DWORD th32ProcessID;
ULONG_PTR th32DefaultHeapID;
DWORD th32ModuleID;
DWORD cntThreads;
DWORD th32ParentProcessID;
LONG pcPriClassBase;
DWORD dwFlags;
TCHAR szExeFile[MAX_PATH];
} PROCESSENTRY32, *PPROCESSENTRY32;
typedef struct tagMODULEENTRY32 {
DWORD dwSize;
DWORD th32ModuleID;
DWORD th32ProcessID;
DWORD GlblcntUsage;
DWORD ProccntUsage;
BYTE *modBaseAddr;
DWORD modBaseSize;
HMODULE hModule;
TCHAR szModule[MAX_PATH];
TCHAR szExePath[MAX_PATH];
DWORD dwFlags;
} MODULEENTRY32, *PMODULEENTRY32, *LPMODULEENTRY32;
덧1) 네. 여기 저기서 웅성 거리는 소리가 들립니다. NT에도 그런 일들은 많다구요. 루트킷에 그런 것들이 많다구요. 맞습니다. NT에서도 모듈 엔트리를 끊으면 9x 캡처 화면에 나온 것처럼 프로세스에 로드된 모듈 목록에 실행 파일이 존재하지 않도록 만들 수 있습니다. 하지만 그건 어디까지나 트릭을 썼을 때 이야기입니다. 노멀한 일은 아니죠.
덧2) 흠, 한 십만년만에 9x 이야기를 하니 제가 왠지 올드한 프로그래머라는 느낌이 드는군요. 예전 선배님들이 8비트를 추억하는 느낌이랄까요 ㅋㅋ~ 저 시절에는 저것 또한 대단한 일이었지만, 아쉽게도 지금 생각해보면 9x는 사실 운영체제가 아니었습니다. 응용 프로그램으로 분류를 하고 싶은 마음이 굴뚝같네요. 9x를 고민하지 않아도 되는 여러분은 정말 행복한 개발자입니다. 정말로요. ㅋ~
0 0