2009. 5. 22. 03:08
프로그래밍/Windows API
프로그램을 짜려면 메모리가 참 중요한데... 차근 차근 책을 보며 다시 한번 정리해 보았다.
Win32 는 32비트로 메모리 주소공간을 표현한다는 의미로 Windows 95 부터 사용된 것으로 알고 있다. Win16은 Windows 95가 나오기 전에 사용된 것으로 주소공간을 표현하는 비트의 수가 최대 16 비트로 최대 표현 가능한 주소공간이 2의 16승 밖에 되지 않는다. 2의 16승은 64K 군.
고로 상위 컴퓨터들이 등장하면서 확장된 메모리 공간 표현을 위해서는 Offset을 추가하는등 복잡한 계산법이 필요했단다... 그러다 보니 자연스레 Win32로의 확장이 이루어 진것인데, 엄밀히 말해서 Win16의 문제점은 두가지였다.
1. 증가하는 메모리 용량을 16비트의 레지스터 공간으로는 쉽게 표현이 불가능했다.
2. 모든 프로그램이 같은 주소 공간에 존재하였으므로 포인터만 가지고 있으면 수퍼맨 처럼 어디든 액세스 가능.
바로 2번은 심각한 안정성 문제를 초래한다. Win16은 주소 공간과 실제 물리적 메모리가 서로 1대 1 대응 관계를 가지고 있었다. 즉, A라는 응용 프로그램의 포인터 값은 실제 물리적 메모리의 주소이며 이는 B라는 응용 프로그램에서도 마찬가지로 접근 가능한 고유한 값이었다.
하지만 이 개념이 Win32에 들어오면서 확 바뀌는데... 어떻게 바뀌냐면...
1. 가상 메모리의 등장. 가상 메모리 = 물리적 RAM + 페이징 파일
2. 독립적인 4G 바이트의 가상 주소 공간이 각 응용 프로그램에 할당.
3. 각각의 4G 바이트 공간은 페이지 테이블을 통해 가상 메모리에 연결.
일단 가상 메모리가 등장하는데 이놈은 실제 컴퓨터가 가지고 있는 RAM 공간 + 페이징 파일이다. 페이징 파일은 물리적인 하드 디스크 공간을 메모리로 사용하는 것을 말하는데 일반적인 RAM보다 속도가 떨어질다는 것 외에는 RAM과 같은 놈이다.
그리고 각 응용 프로그램 당 4G 바이트라는 어마어마한 가상 주소 공간이 할당 되는데 이 가상 주소 공간은 실제로 할당된 메모리가 아니라 최대 저만큼 쓸수 있다는 말이다. 응용 프로그램이 실제로 무엇을 할당하거나 운영 체제의 모듈을 불러들일 경우 중간자 역활을 하는 페이지 테이블을 통해서 가상 메모리에 메모리 공간을 실제적으로 할당한다.
고로 각 응용 프로그램은 각자가 독립적인 4G 바이트의 주소 공간을 가지므로 서로가 서로에게 간섭을 할수가 없다. 즉, 안정성이 확보된것이다.
응용 프로그램은 운영 체제가 메모리를 관리 (페이지 테이블에 의한) 하여 줌으로써 그 댓가로 안정성을 획득한 셈이다. 이런 구조의 한가지 단점이라면 프로세스간에 (응용 프로그램 간에) 데이터 교환이 용이 하지 않다는 점이다.
왜냐면 서로가 가지고 있는 주소 공간의 독립적이므로 A라는 응용 프로그램이 가지고 있는 주소 값은 B에서는 엉뚱한 값을 가지고 있을 수 있기 때문이다. 이것을 해결하기 위해 IPC 혹은 메모리 맵 파일을 사용해야 한다.
'프로그래밍 > Windows API' 카테고리의 다른 글
| 윈도우 - 차일드, 팝업 (0) | 2009.11.17 |
|---|---|
| 윈도우 - SetClassLongPtr(), SetWindowLongPtr() (0) | 2009.11.17 |
| 윈도우 - WNDCLASS 구조체 (0) | 2009.11.17 |
| 윈도우 - CreateWindow() (0) | 2009.11.17 |
| Device Context의 개념 + GetDC / ReleaseDC (0) | 2009.03.11 |
