제 1강 윈도우에서 프로그래밍을 위한 윈도우 이해하기

<A name="[문서의 처음]"></A> 윈도우 프로그래밍을 위한 윈도우 이해   지금으로부터 7~8년 전 쯤에는 윈도우 프로그래밍이란 잘 모르는 사람들에게는 ‘유치한 것’ 그리고 좀 아는 사람들에게 있어서는 ‘힘들고 지저분한 것’을 의미했습니다. 이는 이전부터 윈도우를 운영체제로 보지 않고 단순한 윈도우 매니저(Window manager)로 간주한 것에 기인한다고 보여집니다. 이로 인해 윈도우 프로그래밍은 거의 대부분 사용자인터페이스를 구현하는 것으로 인식됐습니다. 때문에 윈도우 프로그래밍을 처음 배울 때는 언제나 CreateWindow 함수로 하나의 윈도우 프로그래밍 하는 것에 대해 접했으며 하나의 윈도우를 띄우기 위해 수많은 윈도우 클래스 구조체의 맴버를 설정하고 이를 등록하는 일을 했습니다.   본 연재에서는 앞으로 윈도우를 철저하게 윈도우 매니저가 아닌 운영체제의 관점에서 바라보면서 Win32 환경에서 프로그래밍을 할 때 프로그래머로서 꼭 알아야 할 내용들에 대해 다루고자 합니다. 사실 Win32가 API(Application Programing Interface)로서 확립된 이후로 운영체제로서 윈도우의 기본은 쿠게 변한 것이 없습니다. 세상이 좋아져서 각종 RAD(Rapid Application Development)툴과 스크립트 언어가 세상을 지배하고 있는 상황에서 왜 Win32를 알아야 할까 생각할 지도 모르겠지만 성능을 중시하는 서버 프로그래밍이나 솔류션 개발에는 여전히 Win32를 이용한 시스템 프로그래밍이 절실히 필요합니다. 여전히 Win32를 이용한 시스템 프로그래밍이 절실히 필요합니다. 윈도우 프로그래머라면 알아야 할 그 기본을 지금부터 살펴보도록 하죠. 윈도우 NT 아키텍쳐 개요   운영체제의 일반적인 내용들에 대해 공부를 마쳤다면 자신이 프로그래밍을 하고자 하는 운영체제의 환경을 잘 이해해야 함은 당연한 이치일 것입니다. 따라서 지금부터는 윈도우가 어떻게 동작하고 알아보기로 합니다. 앞서 살펴봤듯 윈도우는 크게 윈도우 95계열과 NT계열로 구분할 수 있으며 두 운영체제의 구성과 동작 체계는 크게 다릅니다. 여기서는 윈도우NT를 기준으로 설명하겠습니다. 최근 윈도우는 사실상 NT계열이라 볼 수 있는 XP로 통합됐고 윈도우 NT4.0 이후 그 구성과 동작 체계에는 큰 변화가 없었기 때문입니다. 유저모드 VS 커널모드   윈도우NT에서는 프로세서가 실행되는 모드를 크게 유저모드(User Mode)와 커널 모드(Kernel Mode)로 구분합니다. 유저 모드는 NT가 제공하는 가장 낮은 수준의 권한을 가진 모드로 메모리나 하드웨어에 직접적인 접근이 불가능합니다. 워드나 엑셀 같은 일반적인 윈도우 애플리케이션들이 유저 모드에서 동작하는 대표적인 예입니다. 이와는 반대로 커널 모드는 모든 메모리와 하드웨어에 대해 직접적인 접근이 가능합니다. 가상 메모리 관리자나 디바이스 드라이버 등이 커널 모드에서 동작하는 예입니다. 수정 마이크로 커널   윈도우NT는 때때로 마이크로 커널 운영체제라 불립니다. 마소 Jr.를 꾸준히 읽은 독자라면 마이크로 커널이란 개념이 낯설지는 않을 것이지만 다시 한번 설명하자면 운영체제의 가장 핵심적인 부분만 커널에 구현한 것입니다. 마이크로 커널 운영체제는 높은 결함 허용성(Fault tolerance)과 설정이 용이한 장점이 있지만 가장 큰 문제는 성능이었습니다.   전형적인 마이크로 커널에서는 각 운영체제의 서브시스템은 별도의 프로세스로 동작하기 때문에 상호간의 통신이 프로세스 간 통신이 됩니다. 예를 들어 프로세스 관리자가 새 프로세스를 생성할 때 새로운 어드레스 맵을 생성해야 하는데 이 경우 가상 메모리 관리자에게 이를 프로세스 간 통신으로 메시지를 보내야 합니다. 또한 이 경우 프로세스 관리자에서 가상 메모리 관리자로, 다시 가상 메모리 관리자에서 프로세스 관리자로 두 번의 컨텍스트 스위치(context switch)가 일어나니 성능이 잘 나올 리가 없습니다.   이런 단점을 해결하고자 NT는 나름대로 독특한 구조를 선택했는데 이를 수정 마이크로 커널(Modified micro kernel)이라고 부릅니다. 사실 이 구조는 마이크로 커널과 모놀리틱 커널의 적절한 타협이라고 할 수 있습니다. 여타 운영체제 환경들, 예를 들어 DOS, Win16, Win32, OS/2, POSIX 등은 별도의 프로세스로 실행시키고 프로세스 관리자나 가상 메모리 관리자 등 기본적인 운영체제의 서브시스템은 커널 모드로서 동작하도록 하나의 이미지로 빌드한 것입니다. NT 실행부   NT운영체제는 유저 모드에서 실행되기 때문에 유저 모드에서 접근할 수 없는 작업을 수행하기 위해서는 커널 모드에서 동작하는 서비스들을 이용해야 합니다. 이 서비스들은 NT의 네이티브 API(native API)라고 합니다. 이 네이티브 API는 주로 시스템 서비스라 불리는 커널 모드에서 수행되는 함수들에 의해 호출됩니다. 시스템 서비스의 동작은 뒤에서 다시 다루겠지만 이 시스템 서비스들은 어떤 작업을 처리하기 위해 NT 실행부(Executive)의 함수들을 이용합니다. <표1> NT 실행부의 서브 시스템들 <A name=#61f28841></A> <TABLE style="BORDER-RIGHT: medium none; BORDER-TOP: medium none; BORDER-LEFT: medium none; BORDER-BOTTOM: medium none; BORDER-COLLAPSE: collapse" height=363 cellSpacing=0 cellPadding=0 width=608 border=1> <TBODY> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 실행 서브 시스템</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 기능</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 객체 관리자 (Object Manager)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 리소스를 관리하고 전역 네임 스페이스를 구현한다.</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 보안 참조 모니터 (Security Reference Monitor)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> NT의 보안 ID(SIDs) 보안 모델과 임의 접근 제어 리스트(Discretionary Access Control Lists(DACLs)를 구현</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 가상 메모리 관리자 (Virtual Memory Manager)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 프로세스 어드레스 영역을 정의(define)하고 물리적 메모리를 할당(assign)한다.</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> I/O 관리자 (I/O Manager)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 애플리케이션과 디바이스 드라이버간의 인터페이스를 제공한다.</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 캐시 관리자 (Cache Manager)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 파일 기반 전역 파일 캐시를 구현한다.</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 로컬 프로시서 콜 설비 (Local Procedure Call Facility)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 효율적인 프로세스 간 통신을 제공한다.</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 설정 관리자 (Configuration Manager)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 레지스트리를 관리한다.</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 프로세스 관리자 (Process Manager)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 프로세스와 쓰레드에 관련된 API들을 익스포트 한다.</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> Win32</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> Win32 메시징과 그랙픽 관련 함수들을 구현한다. (NT 4.0부터)</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 플러그 앤 플레이 관리자 (Plug-and-Play Manager)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 디바이스 드라이버들에게 어떤 디바이스의 온/오프를 알려준다.(NT 5.0부터)</TD></TR> <TR> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=246 height=4> 전력 관리자 (Power Manager)</TD> <TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER-BOTTOM: #000000 0.12mm solid" vAlign=center width=363 height=4> 기계의 전력 상태를 관리한다.(NT 5.0부터)</TD></TR></TBODY></TABLE> 실행부는 NT 운영체제의 가장 거대한 부분이라 할 수 있으며 I/O 관리자, 객체 관리자, 프로세스 관리자, 가상 메모리 관리자 등의 여러 컴포넌트로 구성되어 있고 각각의 컴포넌트 운영체제의 특정 역할을 책임지는 구조로 이루어져 있습니다. <표1>은 NT 실행부의 서브시스템과 각각의 기능을 정리한 것입니다. 커널과 그 밖의 부분들   NT 실행부의 컴포넌트의 마이크로 커널에 구현되어 있는 여러 기본적인 기능들을 이용해 구현됐습니다. 이 마이크로 커널을 NT에서는 일반적으로 커널이라 부릅니다. 커널은  스케쥴러를 포함하고 있으며 동기화 프리미티브(Synchronization primitive)들을 제공합니다.   디바이스 드라이버와 하드웨어 추상 계층 (HAL : Hard ware Abstration Layer)은 컴퓨터 하드웨어와 상호작용을 합니다. HAL은 자체적인 API를 제공하고 있으며 이 API들을 하드웨어에 특화된 기계어 코드로 변환시키는 역할을 합니다. NT에서는 이식성을 높이기 위해 하드웨어 특화적인 코드들은 커널과 HAL에만 존재시키고 나머지 코드들은 모두 C와 C++로 구현했습니다. 운영체제 환경   NT가 개발되던 당시에는 PC운영체제는 DOS가 장악하고 있었고 윈도우 3.1과 OS/2등이 인지도를 얻어가던 중이었으며 연구 영역이나 대규모 시스템의 운영체제는 유닉스가 절대적이었습니다. 따라서 NT는 이들 모두를 지원하고자 했으며 각각의 운영체제를 별도의 모듈로 구현했습니다. 이들을 일컬어 운영체제 한경(Operation System Environments)이라 칭합니다. 이것은 매우 이상적인 구조였지만 각각의 운영체제 환경들은 본래 운영체제와 비교하면 필연적으로 어느 정도의 제약이 있었기 때문에 결국 Win32만을 공식적인 운영체제 환경으로 간주하고 있습니다. 운영체제 환경의 실행과정   NT의 운영체제 환경은 클라이언트-서버 모델로 구현되어 있습니다. 예를 들어 어떤 애플리케이션을 빌드한다고 하죠. 이때 어플리케이션은 운영체제 환경이 익스포트는 운영체제 API를 이용했을 것이고 이 API를 통해 각 운영체제 환경의 클라이언트 측 DLL에 링크 됩니다. 만일 Win32 API를 써서 프로그램을 만들었으면 Win32 운영체제 환경의 클라이언트 측 DLL인 kernel32.dll, gdi32.dll, user32.dll에 애플리케이션이 링크 됩니다. 또 POSIX 애플리케이션을 빌드했다면 POSIX 운영체제 환경의 클라이언트 측 DLL인 posix.dll에 링크 됩니다.   운영체제 환경의 클라이언트 측 DLL은 각각 서버 측을 대신해 특정 작업을 수행하며 이 때 해당 애플리케이션의 클라이언트 프로세스로서 작업을 수행합니다.   클라이언트 측 DLL은 어떤 경우에는 전혀 서버측의 도움 없이 스스로 작업을 완료할 수 있으나 반드시 서버 측의 도움을 받아야 할 필요도 있습니다.   보통 서버 측의 도움이 필요한 때는 오직 운영체제 환경과 관련된 어떤 전역 정보가 변경돼야 할 경우가 대부분입니다. 만일 클라이언트 측 DLL이 서버 측의 도움이 필요하다면 클라이언트 측 DLL은 로컬 프로시저 콜(LPC : Local Procedure Call)이라 불리는 메시지를 서버 측에 던집니다. 서버 측이 작업을 마치면 다시 응답을 보내고 클라이언트 측 DLL도 작업을 마칩니다. 이 경우 클라이언트나 서버 측 모두 네이티브 API를 사용할 수 있으며 많은 운영체제 환경 API들은 이 네이티브 API를 이용해 구현되어 있습니다. 다시 말해 운영체제 환경 API들 자체는 유저 모드에서 실행되나 커널 모드의 작업이 필요할 경우 네이티브 API를 사용하는 것이죠. 운영체제 환경의 성능 문제   예를 들어 CreateProcess를 호출해 프로세스를 만드는 과정을 살펴보죠. CreateProcess는 새로운 프로세스를 만드는 Win32 API 중 하나입니다. 새로운 프로세스를 만들기 위해서는 운영체제 환경의 서버 측은 새 프로세스를 만들려고 하는 클라이언트 측의 프로세스와 새로 생성되는 프로세스의 관계를 설정해야 합니다. 이 때 서버 측은 네이티브 API의 NtCreateProcess 함수를 호출합니다.   이와는 반대로 ReadFile Win32 API를 이용해 파일에서 정보를 읽을 경우 ReadFile은 운영체제의 환경 전역 정보를 수정할 필요가 없기 때문에 모든 작업이 클라이언트 측 DLL에서 수행되도록 구현되어 있습니다. 이 때 클라이언트 측 DLL은 네이티브 API,의 NtReadFile 함수를 이용해 디스크 등의 하드웨어와 통신을 하겠지만 서버 측의 도움은 필요 없는 것입니다.   여기에서 언제나 민감한 독자라면 운영체제 환경은 작업은 클라이언트와 서버 통신이 필요하기 때문에 성능 저하가 발생할 수 있다고 생각할 수 있을 것입니다. MS의 주장으로는 NT의 LPC 자체는 최적화되어 있기 때문에 매우 휴율적이라고는 하나 그래도 성능은 떨어지게 마련입니다. 이런 문제를 의식해서인지 MS는 NT 4.0에서 LPC가 많이 쓰여서 성능이 떨어진다고 생각되던 그래픽 디바이스 인터페이스(GDI : Graphic Device Interface)와 사용자 인터페이스를 담당하는 유저 컴포넌트 Win32 운영체제 환경에서 분리해 아예 실행부의 서브 시스템으로 만들었습니다. 시스템 서비스   시스템 서비스는 커널 모드에서 동작하는 네이티브 API들을 유저 모드에서 사용할 수 있도록 제공해 주는 역할을 합니다. 원래 네이티브 API들은 운영체제 환경에서 사용하려고 만들어진 것이나 일반 애플리케이션에서 이를 사용하는 것을 막는 것은 아무것도 없습니다. 오직 하나, 부실한 도큐먼트를 제외하고 말입니다.  보통 네이티브 API들은 앞에 'Nt'가 붙습니다. 앞서 보았듯이 Win32 API인 CreateProcess가 호출하는 네이티브 API는 NtCreateProcess입니다. 두 함수는 인자도 서로 유사하지만 보통 운영체제 환경의 함수는 운영체제가 수행해야 할 더 많은 작업들을 수행하게 됩니다. CreateProcess의 예를 들면 운영체제 환경의 함수는 해당 프로세스의 환경변수도 설정해야 하고, 어드레스 맵도 채워야 하는 것입니다.   애플리케이션이나 운영체제 환경이 네이티브 API를 이용하려면 NTDLL.DLL이라는 DLL을 통해 호출하게 됩니다. 이 DLL은 운영체제가 운영되고 있는 NT 시스템의 모든 프로세스와 링크되어 있으며 모든 시스템 서비스들의 진입점(entry point)으로 구성되어 있습니다. 이 진입점은 필요한 변수들은 준비하고 시스템 서비스 소프트웨어 예외를 발생시키는 역할을 합니다. 예외가 발생하면 커널 보드에서 동작하는 시스템 서비스 예외 핸들러가 이에 반응해 시스템 서비스 테이블에서 해당 서비스를 구현한 함수를 찾아 실행시키게 됩니다. 첫 회를 마무리하며   지금까지 윈도우NT 아키텍처를 가볍게 살펴봤습니다. 다음 회 부터는 본격적으로 윈도우 프로그래밍, 정확히 말하면 Win32 프로그래밍에 대한 이야기가 진행될 것입니다. 사실 윈도우 프로그래밍을 위해 미리 다루고 싶은 내용은 이보다 훨씬 많지만 이것으로 마무리하고자 합니다. 평소 운영체제에 별 관심이 없던 사람이라면 도대체 이런 것들을 왜 알아야 하는가에 대해 생각할 수도 있었을 것이고, 관심이 많던 사람이라면 실제 윈도우 구성에 대해 조금이나마 이해의 폭을 넓힐 수 있었으리라 생각 됩니다.   필자는 현재 온라인 게임 서버를 개발하고 있는데 최근에 많이 느끼는 것은 점점 시스템의 하부, 그리고 기본을 충실히 공부하는 프로그래머가 줄어들고 있다는 것입니다. 사실 점점 하드웨어는 좋아지고 네트워크는 빨라지는 것이 현실입니다. 이전에는 프로그래머들 개인이 재산으로 생각했던 팁들이 압도적인 기술의 발전에 초라하게 느껴지는 시대이기도 합니다. 하지만 프로세서가 생기고 메모리가 붙어서 컴퓨터가 탄생한 이후로 프로그래머가 알아야 하는 기본은 크게 변하지 않았다고 생각합니다. 그 기본을 탄탄히 하는 것은 새로운 것을 더욱 빨리 받아들이고 더욱 혁신적인 기술을 창발해내는 첫 단계일 것입니다. 게다가 시스템에 대한 탐구와 집착은 프로그래머들의 본성이 아닐까 싶습니다. 이 글이 첫 단계에 조금이나마 독자들에게 도움이 되었기를 바랍니다.