1. conime가 conhost로
윈도우 NT 계열 운영체제에는 전통적으로 시스템 디렉터리에 conime.exe라는 자그마한 프로세스가 있었다.
이 프로그램의 타이틀은 Console IME로, 말 그대로 명령 프롬프트(콘솔이라고 불리는)라는 특수한 환경에서 한글이나 일본어의 입력을 지원하기 위해 운영체제와 명령 프롬프트 사이의 통신을 담당하는 듯하다.
conime는 명령 프롬프트를 여러 개 연다고 여러 인스턴스가 중복 실행되지는 않는다. 하지만 한번 실행되고 나면 나중에 명령 프롬프트를 모두 닫아도 종료되지 않고 남아 있는다. 그래서 명령 프롬프트에서 <날개셋> 한글 입력기를 사용하다가 나중에 <날개셋>을 버전업/제거한다거나 하면 conime 프로세스를 강제 종료시켜야 한다고 설치 프로그램이 징징대는 걸 볼 수 있다.
뭐, 작업 관리자로 이 프로세스를 강제 종료시키더라도 운영체제에 악영향은 (전혀) 없다. 나중에 명령 프롬프트를 열면 운영체제가 그걸 알아서 또 실행해 준다.
그런데 윈도우 7에서는 시스템 프로세스 중에 conime.exe가 사라졌다는 걸 본인은 아주 뒤늦게 확인했다. 명령 프롬프트에다 IME 기반 문자 입력을 제공하는 계층이 다른 걸로 바뀌었다는 뜻인데, 어쩌면 이런 변화 때문에 콘솔에서 조합 중인 한글이 덧나는 버그('다다.' 같은)도 덩달아 들어간 게 아닌가 하는 추측도 할 수 있을 것 같다.
관찰해 보니, 윈도우 7에서 콘솔과 관련하여 대신 등장한 프로세스는 conhost.exe이다. 콘솔에서 <날개셋> 한글 입력기를 사용하고 있는 채로 해당 프로그램을 제거하거나 변경하려고 시도하면 conhost 때문에 안 된다는 경고가 뜬다.
그럼 conhost는 cmd.exe 자체와 일대일 대응하는 자매 프로세스냐 하면 꼭 그렇지는 않다.
명령 프롬프트에서 또 cmd라고 치면 그 동일한 창 안에서 명령 프롬프트가 또 구동되는데(exit를 치면 종료 가능한), 이때는 conhost가 또 생기지는 않는다. start cmd라고 쳐서 독립된 콘솔 창이 생성되어야 conhost도 중첩 생성된다. 관계가 이해되시겠는가?
conime와는 달리, 이놈은 명령 프롬프트 창의 인스턴스와 일대일 대응하고, 창이 닫히면 이 프로세스도 종료되어서 IME 프로그램 파일에 걸렸던 lock이 풀린다. 예전에는 콘솔 디버깅 후에는 conime를 강제로 죽여 줘야 했는데 윈7에서는 그럴 필요가 없어진 건 편해진 점이다.
2. 윈도우 7의 kernel32.dll 리모델링
이뿐만이 아니라, 윈도우 운영체제의 시스템 프로그래밍 내지 파일 해킹에 관심이 많은 분이라면 윈도우 7의 under the hood에서 일어난 흥미로운 변화를 하나 알고 있을 것이다.
운영체제의 근간을 이루는 시스템 DLL 중 하나인 kernel32.dll이 내부적으로 여러 분야로 리모델링을 거치기 시작했다는 점이다.
시스템 디렉터리에 가 보면 api-ms-win-core-*.dll이라는 수십여 개의 DLL들이 보일 것이다.
이것들은 kernel32.dll이 제공하는 1000개가 넘는 윈도우 API를 스레드, 힙 메모리, 동기화 오브젝트, 파이프 등으로 세부 분류한 껍데기들이다.
전통적으로 kernel32.dll은 윈도우 9x 계열의 것은 100% 순수 자체 코드로만 이뤄져서 그런지 외부 DLL에 의존하는 게 아무것도 없었다.
NT 계열의 것은 운영체제 커널보다 먼저 로딩되는 ntdll.dll에만 의존도가 있었다. 그리고 그 ntdll이 외부 DLL에 전혀 의존하지 않는 원초 프로그램이었다.
영원무궁토록 변하지 않을 것 같은 kernel32.dll의 내부 구조가 윈도우 7에서 이렇게 바뀐 걸 처음 봤을 땐 무척 흥미로움을 느꼈다.
지금은 그냥 뭔가 더 큰 변화를 위한 준비 수준일 뿐인 것 같은데, 윈도우 8에서는 변화가 얼마나 더 진행될지가 궁금하다.
3. 콘솔의 시각 테마 적용
윈도우 7로 넘어가면서 콘솔에 미묘하게 생긴 재미있는 변화가 또 있다.
전통적으로 명령 프롬프트 창은 윈도우 XP에서부터 도입된 '시각 스타일', 혹은 시각 테마가 적용되지 않는 딱딱한 창으로 처리되었다.
물론, 공용 컨트롤 6.0 매니페스트가 명시되어 있지 않은 구형 프로그램은 각종 컨트롤이나 child window의 테두리가 구닥다리 고전 테마로 나오긴 했지만, 그래도 프로그램의 제목 표시줄 같은 non-client 영역은 모서리가 둥글게 다듬어지기도 하고 최소한의 시각 테마가 자동으로 적용되었다.
그런데 명령 프롬프트는 그런 게 전혀 없이 완전 사각형 모양에 제목도 여전히 윈도우 98/2000식의 그러데이션이고 100% 고전 테마 스타일로 나왔다.
이렇게 100% 구닥다리로 뜨는 프로그램은 (1) 명령 프롬프트, (2) ntvdm 밑에서 돌아가는 16비트 윈도우 프로그램, 그리고 (3) 사용자가 호환성 옵션에서 '시각 테마 사용 안 함' 옵션을 명시한 프로그램 이렇게 세 종류로 한정되곤 했다.
윈도우 비스타/7의 Aero를 사용하면 100% 구닥다리 프로그램도 제목 표시줄이나 창 프레임 자체는 다른 창과 똑같은 형태로 나오기 때문에 이를 구분하기가 쉽지 않다. 고전 테마 말고 Basic 테마를 고르면 한눈에 구분이 가능해진다. 이게 과거의 윈도우 XP Luna와 기술 수준이 동일한 테마이기 때문이다.
그랬는데 윈도우 7부터는 (1) 명령 프롬프트 창도 시각 테마가 적용되는 창으로 바뀌었다. (2)에 해당하는 16비트 윈도우 프로그램은 64비트 운영체제에서는 아예 존재하지도 않으니, 남은 건 이제 (3)뿐이다.
윈도우 비스타/7이 제공하는 한국어/일본어 입력기는 그렇게 시각 테마 열외 프로그램 밑에서 동작하면 가/A, 漢 같은 아이콘이 흰색이 아닌 검은색으로 표시된다. 고전 테마가 아니라 Basic이나 Aero 같은 일반 테마에서 동작할 때 말이다.
본인은 한글 IME의 개발자로서 그 차이를 눈여겨보고 있었고, 그냥 얘네들이 명령 프롬프트에서 동작할 때만 아이콘 글자색을 검게 처리하는가 보다 하고 넘어갔었다.
그랬는데 윈도우 7에서는 명령 프롬프트에서도 글자색이 변하지 않았고, 이에 의문을 느껴 좀 더 관찰을 해 보니 차이를 만드는 요인은 '시각 테마'의 적용 여부라는 사실을 발견하게 되었다.
왜 일부러 그런 차이를 만들었는지는 나로서는 알 길이 없다. 문자 입력기가 응용 프로그램의 시각 테마 적용 여부에 따라 달리 동작해야 할 요인이 있을 리도 없을 텐데 말이다.
자, 다음 그림은 Basic 테마일 때 윈도우 비스타의 명령 프롬프트 화면과 7의 명령 프롬프트 화면이다. 창 프레임의 모양과 입력기 도구모음줄 아이콘의 색깔에 차이를 주목하시길. 내가 지금까지 설명한 것들이 이해가 될 것이다.
 |  |
4. 도스에서 명령 프롬프트로의 변화
윈도우 9x 계열이야 전용 명령 프롬프트 터미널이라는 게 없이 도스창이 명령 프롬프트의 역할도 겸해 왔다. 그리고 거기서는 아예 도스용 한글 바이오스 프로그램이 따로 쓰이니 conime 같은 컴포넌트는 필요하지 않다.
사실, 16비트 윈도우 시절에 운영체제가 쓰던 전용 실행 파일 포맷(New Executable)은 GUI 환경 전용이었지, 콘솔용은 있지도 않았다. 어차피 똑같은 16비트 기반이고 윈도우 운영체제 자체가 파일 접근 같은 요청은 여전히 도스에다 요청을 해서 처리를 하고 있었으니, 콘솔용 실행 파일을 따로 만드는 건 아무 의미가 없고 필요하지도 않았다.
사실, 매킨토시와는 달리 윈도우 계열 OS에만 존재하는 독특한 ANSI/OEM 인코딩, 코드 페이지 같은 개념은 그 기원을 도스의 명령 프롬프트에서 찾을 수 있을 것이다. 걔네들은 원래 철저하게 1바이트 기반 인코딩을 썼었기 때문이다. 그에 반해 매킨토시는 시작부터가 명령 프롬프트가 전혀 없는 GUI였으니 그런 잔재가 없는 셈일 테고.
5. 윈도우 운영체제의 문자 입력 관련 보조 프로세스
처음에 얘기가 나왔던 conime.exe처럼, Windows에서 문자 입력 프로그램과 관계가 있는 시스템 프로세스를 더 나열하자면...
과거에 윈도우 95~2000/ME까지는 internat.exe라는 프로그램이 있었다. 시스템 트레이에다 현재 선택되어 있는 입력기의 언어와 종류를 띄워 주는 역할을 했다.
그러다가 2001년에 윈도우 XP와 함께 COM 인터페이스 기반의 고급 텍스트 서비스(TSF)가 도입되면서 그 역할은 ctfmon.exe가 대체하게 되었고 그게 오늘날의 비스타/7까지 변함없이 내려오는 중이다. internat이나 ctfmon은 언제나 상주해 있으며, 운영체제를 업데이트하지 않는 한 사용자가 강제 종료할 일도 없는 프로그램이다.
하지만 TSF의 도입 초기이던 오피스/윈도우 XP 시절에는 그게 운영체제의 안정성을 떨어뜨리기도 했기 때문에, 딱히 고급 문자 입력 기능에 관심이 없던 사용자 사이에는 운영체제의 버그를 고친답시고 TSF 기능을 완전히 끄고, 심지어 ctfmon 프로그램을 죽여서 문제를 해결하는 방법이 운영체제 팁으로 공유될 정도였다.
6. MS IME가 등록해 놓는 정체 불명의 유틸리티
MS가 제공하는 한중일 IME는 시작 프로그램에다가 정체를 알 수 없는 이상한 migration 유틸리티 같은 걸 등록하여, 운영체제가 시작될 때 매번 그게 실행되게 해 놓곤 했다. HKLM\Software\Microsoft\Windows\CurrentVersion\Run 아래에 말이다.
일본어나 중국어도 아니고 한국어 IME는 무슨 사용자 데이터를 관리하는 것도 아닌데 도대체 이게 하는 일이 무엇이며 왜 이런 과정이 필요한지는 본인으로서는 알 길이 없다. 그냥 일본어 IME 따라 관례적으로 이런 것도 따라 한 것이기라도 할까?
Posted by 사무엘
