사용자 삽입 이미지
위의 그림은 동일한 32비트 윈도우용 프로그램을 세 개 연달아 실행하여
1. 자신의 인스턴스 핸들
2. 어떤 지역 변수의 주소
3. 어떤 전역 변수의 주소
4. 그리고 동일한 공유 메모리(memory-mapped file)를 가리키는 주소
를 차례로 찍은 것이다.

그림을 보면 알겠지만 동일한 실험을
a. 윈도우 3.1+Win32s
b. 윈도우 9x
c. NT급 윈도우

에서 모두 해 봤다. (요즘 버전의 비주얼 C++로 그 구닥다리 Win32s에서도 동작하는 프로그램을 만들려면, 컴파일/링크 옵션을 상당히 특이하게 바꿔야 한다. ㄲㄲ)

Win32s의 한계를 절실히 느낄 수 있을 것이다.
CPU의 가상 메모리 기능을 적극 활용하여 각 프로세스마다 자신만의 주소 공간이 절대 보장되는 윈도우 NT에서는,
같은 프로그램은 아무리 동시에 여럿 실행하더라도 자기 주소가 0x400000으로 고정 불변임을 알 수 있다. 심지어 윈도우 9x조차도 그건 보장된다.

그러나 Win32s는 프로그램을 실행할 때마다 프로그램의 인스턴스 핸들이 제각각이며, 지역 변수와 전역 변수의 주소조차도 완전히 달라진다. 시스템의 모든 프로그램들이 단일 주소 공간을 공유한다는 게 바로 저런 의미인 것이다.

Win32s는 모든 메모리 주소가 0x80000000 위의 상위로 잡혀 있는 것도 매우 신기하다.
9x나 NT급 윈도우에서는 그런 주소는 사실상 커널에서나 볼 수 있기 때문이다.
16비트 운영체제에다 아주 특수한 임시방편으로 32비트를 구현한 Win32s의 동작 방식을 짐작케 한다.

또 하나 재미있는 차이를 발견할 수 있는 것은 인스턴스 핸들과 포인터와의 관계이다.
9x/NT에서는 인스턴스 내지 모듈 핸들이 곧 포인터이기 때문에, 0x400000 같은 값에 해당하는 메모리 주소를 들여다보면 EXE 파일이 통째로 로드된 흔적을 고스란히 찾을 수 있다. 즉 MZ 같은 EXE 헤더가 바로 나타난다는 뜻이다. 그리고 전역 변수의 주소는 역시 근처의 0x40????대로 잡힌 것을 볼 수 있다.

그러나 Win32s의 인스턴스 핸들은 포인터와 아무 관계가 없는 임의의 16비트 정수일 뿐이다. 이는 원래부터 포인터가 서로 아무 관계가 없던 16비트 윈도우의 인스턴스 핸들과 개념을 일치시키기 위한 조치로 보인다. 제아무리 32비트 프로그램이라 하더라도 16비트 운영체제 내부에서는 16비트 규모로 식별이 가능해야 하기 때문이다.

끝으로, 공유 메모리의 주소도 흥미로운 결과가 나와 있다. 오로지 윈도우 9x만이 세 프로그램이 가리키는 주소가 모두 일치해 있다.
이는 윈도우 9x만의 메모리 사용 방식 때문이다. 0x80000000~0xC0...에 해당하는 영역에다 모든 프로그램들이 공유하는 운영체제 시스템 DLL과 공유 메모리를 올려 놓는다. 즉, 이 영역은 윈도우 9x에서는 아무 프로그램이나 바로 접근할 수 있는 단일 주소 공간이나 마찬가지이기 때문에 어느 프로그램에서나 의미가 동일한 셈이다.

NT는 그렇지 않다. 비록 실질적으로 가리키는 물리 메모리는 동일한 위치인지 모르나 이를 가리키는 응용 프로그램의 주소는 완전히 제각각이다. 이렇게 하는 게 훨씬 더 안전하고 보안 관점에서도 유리하기 때문이다.

Win32s는 공유건 응용 프로그램의 코드건 데이터건 가리지 않고 무조건 0x80... 상위 메모리 주소가 뒤죽박죽으로 쓰이는데, 공유 메모리마저 9x와는 달리 제각각인 주소가 배당되는 건 좀 의외이다. 9x는 공유 메모리만 상위 메모리 주소가 쓰였고 NT는 보다시피 상위 메모리 주소가 전혀 등장하지 않는다. 사용자 계층과 커널 계층이 엄격하게 잘 분리되어 있음을 뜻한다.

※ 덧붙이는 말

1. 유니코드

일단 Win32s와 9x는 운영체제의 내부적으로는 유니코드 기반이 전혀 아니다. 그래도 9x는 GDI 계층 차원에서 유니코드 문자를 폰트로부터 인식하고 찍는 건 지원하며 98부터는 유니코드 IME 프로토콜까지도 지원한다. 그 반면 Win32s는 운영체제의 한계 때문에 그런 게 전혀 없다. 운영체제 차원에서 임의의 유니코드 문자를 출력할 방법이 없다는 뜻이다.
오늘날까지 살아남은 NT는 무려 1993년에 나온 3.1 버전부터 애초에 100% 유니코드 지원을 염두에 두고 16비트 wide string을 기본으로 설계했으니 과연 대인배. 물론 이렇게 하려면 메모리가 더 많이 필요하다.

9x는 TextOutW, ExtTextOutW, GetTextExtentPoint32W 같은 GDI 함수는 NT와 기능이 동일하다(비록 surrogate는 지원 안 하지만). 그리고 MessageBoxW도 지원한다. 에러 메시지 뱉고 죽는 최소한의 동작만은 유니코드 함수로도 가능하게 배려했다는 뜻이다.
이외에 리소스를 찾는 FindResourceExW, 명령 인자 옵션을 얻어오는 GetCommandLineW 같은 함수가 유니코드 버전도 간단히 구현돼 있다. 비록 문자열을 ansi 문자열로 변환해서 A 함수를 그냥 호출해 주는 수준이지만.

Win32s는 그런 거 없다. MessageBoxW도 지원하지 않으며, 오로지 WideCharToMultiByte(와 그 역함수) 처럼 문자열 변환 함수만 지원되고 나머지 W 함수는 전혀 지원되지 않는다.

2. GDI/User 계층의 32비트

NT는 순수한 32비트 운영체제인 반면 9x 계열은 아직 상당수의 코드가 16비트로 존재했다. 이런 이유로 인해 9x는 대표적으로 GDI의 좌표계가 16비트 크기로 제한되어 있었으며, NT는 GDI 함수의 실행이 실패했을 때 GetLastError() 에러값이 온 반면, 9x 계열은 그렇지 않은 경우가 많았다. 그 에러값은 32비트 코드 계층에서 설정되는 값이기 때문이다.

과거 16비트 윈도우(Win32s도 당연히 포함)에서는 어떤 GDI 오브젝트 자체와 그 오브젝트가 따로 동적으로 할당하는 메모리의 양이 모두 GDI 힙 64KB 내부에 매여 있었다면,
9x는 일단 할당 가능한 오브젝트의 개수는 64KB의 제약을 받으나 각 오브젝트가 추가로 할당하는 메모리는 ‘별도의 제약이 없는 32비트 범위’인 식으로 제한 조건이 완화된 경우가 많았다. 가령, 복잡한 path나 region 같은 경우 추가 메모리 사용량이 만만찮으리라 예상 가능하다.

제약이 완화되기는 했으나 그래도 9x는 공포의 ‘리소스 제한’이 여전했던 것이다. 리소스 퍼센티지를 아직 기억하시는 분 계시려나?
NT는 역시 애초부터 그런 개념이 없었다. 모든 게 자유로운 32비트 공간이고 지금은 64비트로 자연스럽게 확장되어 있기까지 하다. ^^;;

Posted by 사무엘

2010/05/07 07:45 2010/05/07 07:45
,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/261

Trackback URL : http://moogi.new21.org/tc/trackback/261

Comments List

  1. 김 기윤 2010/05/07 21:30 # M/D Reply Permalink

    메모리 주소... 라 해도 그다지 깊게 생각한 적이 없었으니 처음 보는 내용이 좀 많군요 (^^;;)

    그냥 포인터 변수에 저장되는 것이 메모리의 주소이다.. 정도..

    1. 사무엘 2010/05/07 22:29 # M/D Permalink

      시스템 쪽도 파면 팔수록 재미있습니다.
      문제는.. 리눅스나 맥 같은 OS도 내가 윈도우를 아는 것처럼 알려면 얼마나 삽질을 더 해야 할지.. =_=;;;

  2. 정 용태 2010/05/07 21:36 # M/D Reply Permalink

    끔찍한 리소스 제한...;; 글자크기가 커져버리고 파란 화면을 뿜어내죠 ^^;; 그래서 항상 윈도우98의 리소스 모니터를 틀어놓고 작업했었습니다.. win32s를 사용했던 한글3.0b와 한글96은 어떤의미로든 참 대단했던것 같습니다 ^^

    1. 사무엘 2010/05/07 22:33 # M/D Permalink

      정말 악명높은 흑역사입니다.
      유니코드 지원 안 하는 건 그렇다 쳐도 리소스는.. 램이 아무리 많아도 해결이 안 되는 문제이다 보니 너무 치명적인 제한이었죠.

      Win32s는 지금 생각하면 정말 장난감 정도밖에 안 되는 열악한 환경인데, 옛날엔 그 불안정한 환경에서 무려 상업용 소프트웨어를 개발해 냈다는 게 신기할 따름입니다.
      아래아한글 3.0b와 96은 윈3.1+Win32s에서는 실행되기 전에 자체 메모리 서버도 올려야 했답니다. (95에서 돌릴 때는 필요하지 않음) 그리고 3.0b 말고 최초 3.0은 윈도우 3.1+Win32s에서는 돌아가는데 정작 윈도우 95/NT에서는 실행되지 않은 병크까지...;;;
      아래아한글도 큰 breaking change를 겪은 그때와 워디안 시절 때는 가루가 되도록 까인 적이 있었습니다. ^^;;

  3. 김기윤 2011/01/18 13:30 # M/D Reply Permalink

    문득 생각났는데, 이전에 VS6.0 에서 유니코드를 사용해서 빌드를 하려 했는데 API였는지, MFC였는지, 그쪽에서 뭔가 꼬여-_-서 에러났던 기억이 납니다. 2008로 컨버팅하니까 문제없이 잘 되고..

    1. 사무엘 2011/01/18 21:14 # M/D Permalink

      닷넷 이전(특히 6.0)에는 MFC 프로젝트를 유니코드 기반으로 빌드하려면 링크 옵션에서 entry 함수를 wMainCRTSetup로 반드시 지정해 줘야 했습니다. 안 그러면 링크 에러. 초보자가 저지르기 쉬운 실수입니다. 유니코드를 지원하긴 했지만 무척 불친절했지요. 아마 꼬였다는 게 저걸 말하는 걸겁니다.
      물론 닷넷에서는 유니코드 지정 옵션이 별도로 추가되었고 저런 수고를 할 필요가 없습니다.

Leave a comment
« Previous : 1 : ... 1915 : 1916 : 1917 : 1918 : 1919 : 1920 : 1921 : 1922 : 1923 : ... 2131 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/03   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Site Stats

Total hits:
2635480
Today:
2278
Yesterday:
1754