김 용묵의 절대공간 - 블로그

그림을 보면 알겠지만 동일한 실험을
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 사무엘

멀티태스킹 운영체제에는 한 주소 공간에 여러 프로그램들이 동시에 실행될 수 있다. 그렇기 때문에 그런 환경에서 동작하는 프로그램이라면 자기가 메모리의 어느 위치에 적재되는지를 신경써야 하며, 임의의 위치에 올라가더라도 잘 실행될 준비가 되어 있어야 한다.

과거 도스 시절에는 EXE말고 COM이라는 실행 파일이 있었는데, 이것은 최소한의 헤더 같은 것도 없고 코드와 데이터가 다 16비트 공간 안에 막혀 있으며(과거 메모리 모델로 치면 제일 작은 tiny와 동일), 메모리 주소도 고정 붙박이식이어서 오늘날의 컴퓨터 환경과는 도저히 어울릴 수 없는 과거 유물이 되어 있다.

윈도우 운영체제의 실행 파일이 사용하는 PE 포맷은 position dependent code 방식이다. 즉, preferred base라는 개념이 존재하여 자기는 32비트 주소 공간에서 어디에 적재되는 게 이상적인 경우라고 이미 가정하고 만들어져 있다는 뜻이다. 어떤 EXE나 DLL이 거기에 바로 적재가 가능하다면 가장 빠르고 좋지만, 만약 이 선호하는 주소에다 적재가 못 된다면 별도의 재배치 작업이 필요하다. 즉, 마치 퀵 정렬처럼 잘 될 때와 못 될 때의 성능 편차가 크며 일종의 모험이 동반된다는 뜻이다.

이는 유닉스의 shared library와는 다른 디자인이다. 그쪽은 이렇다할 preferred base 주소가 없으며, 코드 자체가 어느 메모리 주소에 적재되든 동일한 성능으로.. 하지만 딱히 최적의 성능을 발휘하지는 않는 구도로 동작한다. 일종의 힙 정렬이나 병합 정렬처럼 동작한다는 뜻.

윈도우 PE 포맷에는 실제로 실행되는 기계어 코드인 code 섹션도 있고 data라든가 리소스(rsrc)와 더불어 재배치 정보를 나타내는 섹션(reloc)도 있다. preferred base에서 동작하지 못할 때, 코드의 어느 부분을 쫙 수정해 주면 preferred base가 아닌 다른 지점을 기준으로 이 프로그램이 잘 돌아갈 수 있는지를 따로 기록해 놓은 것이다. 사실 이런 개념의 재배치 정보는 도스 EXE나 16비트 윈도우 EXE에도 있긴 했다.

그런데 32비트 윈도우 EXE만은(물론 64비트도 포함) 원칙상 이런 재배치 정보가 필요하지 않게 됐다. 32비트 환경부터는 모든 EXE들이 나만의 독립된 주소 공간을 가지기 때문에, preferred base가 무엇이든지에 무관하게 EXE는 무조건 내가 원하는 위치에 가장 먼저 적재되는 게 보장되기 때문이다.
그래서 통상 EXE들은 재배치 정보를 넣지 않는다. 필요가 없기 때문에, 넣지 않는 게 파일 크기를 줄이는 데도 도움이 되기 때문이다.

그럼에도 불구하고 재배치 정보가 필요한 경우는 다음과 같다.

1. EXE가 아닌 DLL은 반드시 필요하다. DLL은 다른 EXE의 밑에 붙어서 동작한다는 특성상 자신만의 주소 공간을 갖고 있지 않다. 나의 preferred base에 EXE라든가 다른 DLL이 이미 선점되어 있다면 응당 재배치가 필요하다. DLL은 그런 상황을 언제든지 대비해야 한다.

2. Win32s에서 돌아가는 32비트 프로그램이라면 EXE라도 재배치 정보가 반드시 있어야 한다. Win32s는 과거 윈도우 3.1에서 일부 32비트 프로그램을 구동하기 위해 제공되었던 일종의 운영체제 익스텐더로, 32비트 프로그램을 실행만 해 줄 뿐, 16비트 윈도우 3.1이 지니고 있던 시스템적인 한계는 그대로 답습하고 있다.
멀티스레딩을 지원하지 않으며 32비트까지 포함해 모든 EXE가 독립이 아니라 단일 주소 공간을 공유한다!
프로그램을 실행할 때마다 EXE의 핸들이 제각각인 값이 들어오며, 로딩도 preferred base에 정확하게 절대로 되지 않는다. 여기에 대해서는 추후 실험해 볼 예정.
실제로 테스트를 해 보면 핸들이 0x1xxx 이렇게 아주 작은 값으로 들어온다는 게 매우 흥미롭다. 윈도우 NT에서는 그렇게 낮은 주소는 아예 무조건 에러로 간주하는 반면, Win32s에는 그게 여전히 쓰인다는 소리이다. 포인터가 아니라 진짜로 다른 번호에 가깝다.

3. 비주얼 C++ 2008에서 추가된 '시작 주소 랜덤화' 기능을 사용하려면 재배치 정보가 필요하다.
보안을 위해 성능을 희생하듯, 윈도우 비스타부터는 PE 실행 파일도 일종의 position independent (과거의 dependent가 아닌) code처럼 써먹으려는 것 같다.
이 방식으로 빌드된 EXE는 운영체제가 일부러 EXE의 preferred base와는 다른 임의의 위치에다가 로딩을 해 준다. 즉, 이 EXE의 특정 지점의 코드나 데이터를 딱 맞춰 수정하는 프로그램이 제대로 동작하지 않게 위해서이다. (스타크로 치면 맵핵 같은 프로그램)

Posted by 사무엘

※ 2000

일반 사용자를 대상으로 NT 커널과 9x 계열의 통합을 야심차게 기획했던 운영체제이다.
하지만 윈도우 디렉터리의 이름은 여전히 Windows가 아닌 WinNT였고, 특이하게도 마우스 포인터의 이동 자취(trail)를 남기는 기능이 없었다. 9x 계열은 말할 것도 없고 구닥다리 윈도우 3.1조차 갖추고 있는 기능인데 NT에서만 원래 없었던가? 물론 XP부터는 이 기능이 있다.
탐색기에서 wav/mp3을 클릭 후 바로 재생이 가능하던 유일한 운영체제이다.

그리고 2000부터 GUI의 표준 색상이 약간 바뀌었다. 그저 RGB(192,192,192)이던 회색은 살짝 더 누르스름하게 바뀌고, 파랑은 좀더 어둡고 군청색에 가깝게 바뀌었다.
그런데 유독 윈도우 2000만.. 스타크래프트 같은 256색 전체 화면에 들어갔다가 나오면 그 파란색이 예전의 덜 어두운 색으로 돌아가는 신경 쓰이는 버그가 있었다. 이 역시 ME라든가 XP 이후부터는 전혀 발생하지 않으며 윈도우 2000만의 문제. 후대의 추가 최신 업데이트까지 다 받으면 어찌 될지 모르지만, 아무튼 SP4까지 가도록 이 문제는 고쳐지지 않았다. 2000만의 고질병으로 기록될 듯.

(이해를 돕기 위해 스크린샷을 첨부하자면, '위'가 '아래'로 바뀐다는 뜻이다. RGB(10,36,106)이 RGB(0,0,128)로 변경. 본인에게는 정말 바로 티가 나고 아주 거슬리는 버그였던 반면, 저 버그에 대해서 공감하는 사람은 주변에서 지금까지 전혀 보지 못했다. 윈도우 2000 쓰면서 스타도 띄워 본 적 없나??)

※ XP

1. 유저 인터페이스가 파격적으로 많이 바뀌었다 보니 초창기 SP0은 별 특이한 버그가 많았다.
스트링을 내장하고 있지 않은 리스트박스나 콤보박스는 LB_ADDSTRING 내지 CB_ADDSTRING 메시지로 아이템을 추가할 때 당연히 string을 NULL로 지정해도 괜찮은데, 새로운 비주얼 스타일(테마)이 적용된 컨트롤은 저렇게 하면 프로그램이 죽는 어이없는 버그가 있었다. -_-;; (비주얼 스타일 없는 옛날 컨트롤은 문제 없음)

95부터 2000/ME까지 아무 탈 없던 코드가 유독 XP에서만 문제를 일으킨 것. 과거 <날개셋> 한글 입력기 2~3.x 시절에 윈도우 XP (sp0)에서 일부 제어판 UI가 뻗던 문제는 이 문제 때문이었다. 매우 황당한 버그이기 때문에 이 문제는 SP1에서 곧바로 고쳐졌다.

2. XP부터는 응답이 없이 죽은 윈도우는 대책 없이 배째라 있는 게 아니라, 최소한 창의 이동과 강제 닫기는 가능한 일명 고스트 윈도우를 그 프로그램의 원래 윈도우를 대체하여 잠시 보여주는 기능이 추가됐다. 그래, 만든 취지는 좋다.

그런데.. 최대화되어 있던 프로그램 창이 한동안 응답이 없어서 고스트 윈도우가 됐다가... 다시 돌아와서 깨어나면,
그 창의 최대화 이전의 위치와 크기가 사라지고 창의 최대화를 해제해도 창 크기 자체가 최대화나 마찬가지인 상태로 남는 버그가 있었다. -_-
이 문제 역시 SP1을 전후한 시기에 고쳐졌다.

3. SP0은 무선 인터넷을 좀 하다 보면 lsass던가 뭐가 이상한 시스템 프로그램이 문제를 일으켜서 1분간 초 단위로 카운트다운을 한 후 운영체제가 재부팅되는 현상도 있었다. -_-;;
갑자기 그런 게 떠서 놀랐고, SP1만 설치해도 그 문제가 없어지는 것을 보고는 더 놀랐다. 도대체 SP0에서는 무슨 문제가 있었기에?

이외에 다른 사람들은 XP에서 시스템 차원에서 첫 도입된 TSF와 관련된 문제(ctfmon) 등 여러 버그를 찾아낸 듯하던데(해결책이라고 내놓은 게 '고급 텍스트 서비스 사용 안 함' ^^), 본인은 그런 건 모르겠고 저 세 가지 버그가 지금까지 기억에 남는다.
SP2는 저런 사소한 버그 해결 수준이 아니라 보안 관련 기능 추가가 즐비해서 단순 서비스 팩 같지가 않고,
SP3은 제대로 쓸 일도 없이 그 즈음에 비스타로 갈아타게 돼서 잘 모르겠다. SP2 정도만 해도 사실 상당히 안정화가 돼 있으니까.

※ 비스타

굉장히 오랜만에 출시된 만큼 엄청나게 높아진 사양, 그리고 디폴트로 적용돼 있는 UAC (사용자 계정 컨트롤) 때문에 뭇매도 많이 맞았다. 하지만 비스타는 객관적으로 상당히 잘 만든 OS이며, 7에 비해서 그 정도로 평가절하될 품질은 결코 아니다. 윈도우 98이 단순히 95+IE4가 결코 아닌 것과 같은 이치이다.

본인은 language bar (TSF 도구모음줄, 입력 상태 표시줄)를 task bar(작업 표시줄) 내부에 포함(embed, minimize)시키는 게 아니라 바탕화면에 동동 띄워 놓고 지낸다.
그런데 유일하게 비스타에서만 구경한 버그로는.. 응용 프로그램을 좀 사용하다 보면 이 language bar가 사라져 버리고 아마 내 기억이 맞다면 한글 입력도 안 되는 것.
내 컴만 그런가.. 왜 그런지 좀 성가시고 불편했다. 윈도우 시스템 디렉터리로 가서 ctfmon.exe를 재실행하면 사라졌던 language bar가 살아났다.

이것도 요즘은 구경을 안 하는 걸 보니, 다행히 서비스 팩을 설치하는 과정에서 고쳐진 것 같다.
엑셀 2007에서 유명하던 65535 곱셈 버그가 생각난다.
예전에 MS의 정책은 SP n은 SP n-1을 다 포함하는 형태였던지라, 최신 서비스 팩 하나만 갖고 있으면 됐다. 비주얼 C++ 6이라든가 윈도우 NT는 패키지 프로그램을 설치 후 최신 SP인 SP6만 깔면 끝이었던 것.

그런데 윈도우 비스타부터는 SP2를 깔려면 먼저 SP1부터 깔아야 한다. 매번 꽤 오래 시스템 파일 고치고 재부팅하고.. 불편하더라.
그래도.. 본인은 보안 업데이트는 귀찮아하는 편이지만, 서비스 팩은 그때 그때 깔 필요가 있다는 걸 체험 중. 왜냐하면 내가 현실적으로 직접 겪는 버그가 서비스 팩을 통해 곧장 해결된 경우를 꽤 자주 겪었기 때문이다.
듣기로는 비주얼 스튜디오 2010을 설치하려면 비스타조차도 SP1 이상이 필요하다.

아 그리고.. 윈도우 비스타 SP0은 인증 기간이 끝나면 대놓고 작동이 완전히 맘춰 버리는 유일한 운영체제이기도 했다. 기능 제한 모드가 되어, 인증을 받게 인터넷 접속이 가능한 웹브라우저 하나만 달랑 뜨고 다른 모든 기능을 사용할 수 없었다. 이 때문에 항의가 빗발쳤는지 SP1부터는 바로 사라지고 이는 후속작인 윈도우 7도 마찬가지. 화면이 주기적으로 까맣게 변하고 '이 제품은 정품이 아닙니다' 자막만 뜰 뿐, 동작 자체는 한다.

※ 7

콘솔에서, 한글을 조합 중이다가 비조합 문자를 “IME 차원에서” 삽입하면 조합 중이던 문자가 덧나는 버그가 있다. 이건 <날개셋> 문제가 아니라 MS IME에서도 나타나는 운영체제의 버그이다.
가령, "다"를 조합 중에 마침표를 누르면 "다."가 아니라 "다다."가 되는 것.

MS IME의 경우 두벌식일 때는 발생하지 않는다. 두벌식은 A~Z 사이에 배당된 한글 글쇠만 IME 차원에서 삽입하고 여타 숫자나 기호는 영문 자판과 동일한 방식으로 별다른 터치 없이 응용 프로그램으로 보내기 때문이다.
과거에 포트리스 space 버그를 비롯해서 MS IME가 유독 세벌식 자판에서만 발생하는 버그가 심심찮게 발견됐던 이유는 이런 동작 방식의 차이 때문이다. 세벌식은 아는 사람도 쓰는 사람도 거의 없다 보니 버그 발견이나 수정도 금방 금방 되지 않을 것이고.. -_-

이제 문자 입력 쪽 기능은 비스타 이후로 좀 안정화가 돼 있길 바랐건만, 또 뭘 건드려서 저런 버그가 생겼는지 모르겠다. SP1에서라도 당장 고쳐져 있길 기대한다.

Posted by 사무엘

Posted by 사무엘

1.
요즘 스마트폰 프로그램 개발 플랫폼:
- 안드로이드: 자바
- 아이폰: 오브젝티브 C
- 윈도우 모바일: C/C++
아주 언어까지 가지각색 제각각이네. =_=;;;
생각해 보면 각각 데스크톱 PC에서 리눅스, 맥OS, 윈도우 진영이 그대로 형태만 바뀐 게 아닌가 싶다.

그래서 이런 기기 프로그램 개발하는 회사들.. 특히 문자 입력 솔루션을 개발하는 회사들이 고역이라고 한다. 서로 극단적으로 다른 분야인지라, 동일한 제품을 만들어도 플랫폼별로 프로그래머를 따로 고용해야 하기 때문에.

2.
64비트 윈도우에는 32비트 모듈과 64비트 모듈이 서로 철저하게 분리되어 있으며 시스템 디렉터리가 둘 존재한다.
그런데, SysWOW64는 32비트 dll이 들어있는 곳이고, system32가 64비트 dll이 들어있는 곳이다. 헷갈리지 말자.
이름에 들어있는 숫자하고 실제 숫자가 서로 일치하지 않는다는 게 아이러니이다. ^^;;;

3.
윈도우 7은 비스타와 비슷한 기술 계층 위에서 UI가 굉장히 세련되게 많이 바뀌어서 호평 받고 있다. 그 중엔 창을 화면 한구석으로 끌면 자동으로 창을 최대화하거나 좌우 반쪽을 꽉 채우게 바꾸는 기능이 있다. 대부분의 상황에서 그건 편리한 기능이긴 한데, 그래도 정말로 창을 그렇게 구석으로 살짝 치우기만 하고 싶고 최대화를 시키고 싶지는 않을 때는 어떡하는지가 좀 의아하다.
툴바를 도킹할 때처럼 ctrl 키를 누르고 있으면 채우지 않게 한다거나 하는 기능이 필요하지 않을까?

4.
윈도우 7 얼터밋 같은 상위 에디션에는 윈도우 XP 가상 머신이 추가되어 있다. 이것은 단순히 VMware 같은 가상 머신 유틸이 추가된 게 아니라 아예 윈도우 XP 모드로 웹브라우저를 다른 7 응용 프로그램들과 동일한 위상으로 돌려 주는 기능도 제공한다. 이걸 보고 적지 않게 놀랐다. XP 가상화 모드로 실행된 IE는 Aero 적용도 받지 않고, XP 스킨을 그대로 유지하고 있다. 하지만 다른 프로그램과 동일하게 다루는 게 가능하다.
그런데 그렇게 XP 가상화 모드로 실행된 프로그램의 윈도우의 클래스 이름이 RAIL_WINDOW이다. rail이 난간, 울타리라는 뜻이 있으니 그런 이름이 붙은 것 같다.

전에도 글로 썼듯이, 본인은 집이나 회사에서나 온통 비스타밖에 안 쓴다.
하지만 바깥에서는 차라리 XP를 쓰면 썼지 비스타 구경하기는 굉장히 힘들어져 있다. 온통 7 쓰니까. ^^;;

5.
본인은 초딩· 중딩이던 시절엔 제발 더 좋은 컴퓨터 좀 장만해 달라고 부모님을 진짜, 엄청 속 썩였는데
이제는 정반대로 지나칠 정도로 이쪽으로는 무덤덤해져 버렸다.
그때야 XT, AT, 386, 486.. 컴의 성능이 한 단계 한 단계 올라갈수록 당장 돌릴 수 있는 프로그램의 스케일이 극단적으로 달라지고 그야말로 천지개벽의 변화가 있었던 반면,

이제는 어지간한 넷북 수준의 컴퓨터에서도 비주얼 스튜디오 깔아서 프로그램 개발하는 덴 별 지장이 없으니, 업그레이드의 필요성을 별로 안 느끼게 된 것이다.
그래서일까? 명색이 IT 업계 종사자 소프트웨어 개발자라면서 본인은 우리 회사에서 최고령 휴대전화를 쓰고 있다. ^^;; 자동차로 치면 아직까지 포니, 스텔라, 엑셀 같은 차를 몰고 있는 것이다.

튼튼하고 배터리 오래 가고 통화· 문자만 되면 된다. 잃어버리거나 고장나지 않는 이상 도무지 전화기를 바꿀 필요를 느끼지 않는다. 본인에게는 인터넷이 되는 작은 전화기보다, 인터넷 안 되더라도 정상적인 타이핑이 가능한 휴대용 컴퓨터가 훨씬 더 필요하다.
오히려 부모님이 나보고 폰 좀 바꾸라고 성화일 정도이니 세상이 과연 극과 극으로 바뀌었다. ^^;;

그나저나 20~30년 전에 비해 다른 모든 분야의 물가는 2배~3배 가까이 뛴 반면(버스비, 라면· 우유값, 자장면 값 따위를 생각해 보라), 컴퓨터는 성능이 그야말로 넘사벽 충공깽 급으로 향상됐음에도 불구하고 가격은 예나 지금이나 여전히 수십만~100수십만 원..;; 보편적인 물가를 역행해도 한참 역행하고 있다. 정말 신기한 노릇이다!!

Posted by 사무엘

윈도우 2000부터는 스크롤바에도 우클릭 메뉴가 생겼다. 마우스가 가리키는 특정 지점이라든가 맨 위/아래 지점으로 바로 스크롤이 가능해서 매우 편리하다.
그런데 문제는 병맛 같은 우리말 번역.

위쪽 / 아래쪽 이 무엇인지 짐작하시겠는가?
이게 영어는 Top / Bottom이다. 즉, 스크롤되는 대상의 맨 꼭대기/맨 밑바닥 위치를 가리킨다.
본인은 한국어를 봐서는 도저히 그 의미를 알 수 없었다.

페이지 위로 / 페이지 아래로는 Page up / Page down의 직역이다.
차라리 위쪽 / 아래쪽은 Page up / Page down의 번역으로 더 적절하지 않은가? 아니면 차라리 '한 화면 위/아래' 말이다.
Top / Bottom의 의미를 우리말로 번역하려면 최소한 '가장'이나 '맨', '최' 같은 최상급 부사가 동원되어야 할 것이다.

이것보다 더욱 병맛 같은 번역, 사람 진짜 낚은 번역은 따로 있다.

윈도우 XP와 비스타는 새로운 스타일의 시작 메뉴가 도입되어서 자주 실행하는 프로그램이 자동으로 메인에 뜬다. 그리고 사용 빈도와 관계없이 언제나 나타나 있길 원하는 프로그램은 거기에 '고정'(pin)이 가능하다.

고정을 할 때는 프로그램 아이콘을 우클릭한 후, '시작 메뉴에 고정'을 누르면 된다.
그런데 이미 고정된 프로그램을 우클릭하면 '시작 메뉴에서 제거'와 '이 목록에서 제거'가 뜬다.
둘 중 하나는 단순히 '고정 상태 해제'이고, 다른 하나는 말 그대로 시작 메뉴에서 완전히 없애버리는 것이다. 독자 여러분은 한국어만 봐서 뭐가 뭔지 파악하겠는가? (7은 아예 작업 표시줄에 고정이 되므로 해당 사항 없음)

정답을 말하자면 '시작 메뉴에서 제거'가 고정 해제이고, '이 목록에서 제거'가 완전히 제거이다!
도대체 시작 메뉴하고 이 목록의 개념상 차이가 무엇인지 아시는 분? -_-;;
영어 원문은 엄연히 전자는 Unpin, 후자는 Remove이다. '고정 해제'라고 하면 아무 혼동 없이 알아들을 텐데 왜 번역을 이 따위로 했는지? 2002년에 윈도우 XP를 써 온 이래로 아직까지도 본인은 직접 아이콘을 실수로 없애 버리지 않고서는 분간을 못 한다. MS 제품에 들어있는 제일 엉터리 번역이라고 생각한다.

하긴, 윈도우 XP sp2가 나오기 전, IE 6의 About 화면을 보면 '승인'이라는 버튼이 있었다. 이게 뭘까요?
영어 원문은 Acknowledgments이다. 이걸 클릭하면 IE 6의 개발자 명단이 애니메이션으로 쭈르륵 나온다. 그렇다. 이건 논문이나 저서(특히 외국물)에서도 볼 수 있듯, '감사의 글' / '만든 사람들' 뻘 되는 의미로 번역해야 맞다.

이때 Acknowledgment를 승인이라고 너무나 사전적인 의미로 번역하는 것은, '만든 사람들' 리스트가 나오는 Credits를 달랑 신용이라고 번역하는 것이나 다름없다. ^^;; 번역가가 이 단어가 쓰이는 문맥과 상황을 알지 못하고, 그냥 수많은 영어 문장/단어 리스트를 보면서 기계적으로 번역해서 그런 것 같다.

저런 오역은 그냥 사람을 낚는 정도이지만, 오역이 사람을 잡을 수도 있다. 오늘날처럼 영어로 무수한 정보와 지식이 쏟아지는 시대엔 영한 사전을 만드는 사람이나 번역가의 역할이 매우 중요하다.

Posted by 사무엘

거의 20년 전의 윈도우 3.0 이래로 한글판 운영체제가 내장해 온 한글 글꼴은 바탕, 돋움, 굴림, 궁서의 4종류였다. 그리고 한자 글꼴은 바탕, 돋움에만 존재하여 2종류였다. 지극히 교과서적인 기본 글꼴에만 한자 글립이 있었다는 뜻.
그때는 fallback 글꼴이라는 개념조차 없었기 때문에 궁서나 굴림 같은 글꼴을 쓰면 한자가 아예 나타나지도 않았었다.

그러던 것이 윈도우 95에서부터는 상황이 크게 개선되어 궁서의 한자는 바탕으로, 굴림의 한자는 돋움으로 좀더 유사한 글꼴의 한자 글립을 공유하게 되었다. 이것은 별도의 fallback 글꼴을 지정한 게 아니라, 아예 한 글꼴 파일이 collection으로 바탕과 궁서를 나타내고 있고 한자 글립을 내부적으로 바탕의 것으로 공유하기 때문에 가능해진 것이다.

윈도우 비스타에서 새롭게 추가된 글꼴인 ‘맑은 고딕’도 한자 글립을 갖고 있지 않다. 한자를 찍으려고 하면 돋움체의 글립이 자동으로 쓰이는데 이것은 fallback 글꼴이 쓰인 게 맞다.

한자 자체도 윈도우 95 시절까지는 고작 KS 완성형 코드에 있는 상용 한자 4888자밖에 없었다. 그러던 것이 98부터는 확장 한자 2856자가 추가되었고, XP 무렵에는 유니코드의 ‘한중일 통합 한자’ 영역의 한자가 모두 기본 제공되기 시작했다. 그리고 비스타부터는 ‘한중일 통합 한자 확장 A’까지 굴림/돋움 같은 글꼴에서 기본 제공되기 시작했고, 심지어 surrogate 영역에 존재하는 확장 B도 외국에서 제작된 별도의 글꼴을 자동으로 fallback 하여 표현할 수도 있게 되었다.

이렇게 PC 환경이 좋아지면서 컴퓨터에서 문자를 표현하는 능력이 비약적으로 향상돼 왔는데 본인이 늘 아쉽게 생각하는 게 있다. 기본 제공되는 한자 서체 자체는 20년 전이나 지금이나 바탕과 돋움 두 종류뿐이라는 점이다. 이제는 굴림과 궁서도 고유한 한자 글립을 제공할 때도 되지 않았나 싶다.

21세기가 된 지 무려 10년 가까이 지나고 온갖 기발하고 현란한 한글/영문 글꼴이 넘쳐나는 지금도, 한국에서 소위 명조와 고딕 계열 이외의 한자 글꼴을 찾기란 의외로 매우 어렵다! 사실은 신명조와 중고딕 말고 견명조, 견고딕조차도 드문 실정이다.
어지간한 운영체제나 워드 프로세서가 번들로 제공하는 글꼴에서는 거의 찾을 수 없고 최소한 별도의 글꼴 확장팩에서나 제공된다. 이런 의미에서 과거 아래아한글 2.5 확장팩은 정말 신선한 충격이었다. ‘신명 궁서’는 아래아한글이 최초로 제공한 궁서 계열 한자 글꼴이었다.

그나마 견명조, 견고딕, 궁서는 좀 사정이 나아졌다. 아래아한글이 번들로 제공하는 HY견명조, HY견고딕에도 한자 글립이 같이 들어있다. 하지만 굴림 계열의 한자 글꼴은 정말 없다. 무려 아래아한글 3.0대 내지 96의 확장팩부터 제공된 한글맵시 글꼴에서 그런 한자 글꼴을 본 기억이 나고 HFT가 아닌 범용적인 TTF 방식은 아직까지 구경조차 못 해 봤다.

둥근고딕, 세나루, 디나루 등의 명칭으로 불리는 이 굴림 계열 글꼴은 원래는 그래픽이나 헤드라인처럼 일반 PC에서 보기가 쉽지 않은 글꼴이었으며, 아래아한글도 2.5 확장팩에서부터나 제공하기 시작했다. 그런데 윈도우 95가 이 글꼴을 확 퍼뜨려 준 덕분에 굴림은 그때부터 그야말로 길바닥에 차이는 돌멩이마냥 오늘날 우리나라에서 웹과 인쇄물 등에서 제일 흔하게 쓰이는 글꼴이 되었다. ^^

워낙 흔하다 보니 굴림 말고 별도의 굴림 계열 글꼴은 거의 나오거나 쓰이지 않았다. 그런데 그 흔한 기본 글꼴에 한자 글립이 없었고, 따라서 한자 글립이 추가된 다른 둥근고딕 글꼴도 거의 볼 수 없게 된 게 아닌가 한다.

사실 굴림체 계열의 한자 글꼴이 가장 널리 쓰이고 있는 곳은 일본이다. 둥근고딕 한자로 쓰인 문장만 봐도 일본이 바로 떠오를 정도이다. 한국에서 이런 글꼴을 볼 일이 없기 때문이다.
그리고 뭔가 소프트웨어를 동아시아 환경에 맞게 localize할 때 기준으로 삼는 언어 역시 단연 일본어이다. 국력도 국력이거니와, 워낙 일본의 문자 체계와 문자 입력법이 복잡하기 때문에 일단 일본을 기준으로만 프로그램을 고쳐 놓으면 한국이나 중국어 버전은 약간만 추가 조치를 취하면 되기 때문이다.

굴림체를 비판하는 사람들은 굴림체가 한글답지 못하고 일본 한자 서체의 스타일을 그대로 베꼈다고 주장한다. 사실, 한글 윈도우 95가 돋움이 아닌 굴림을 기본 글꼴로 내세우고 나온 것도, 굴림 계열 글꼴을 즐겨 쓰는 일본 쪽 문화를 참고했던 게 아닐까 하는 생각이 들기도 한다. 실제로 각종 컴퓨터 용어를 제정하거나 심지어 한글 코드과 글꼴 같은 걸 정할 때도 우리나라 엔지니어들은 일본은 localize를 어떻게 했는지를 엄청 많이 참고해 온 것도 어쩔 수 없는 현실이다.

그런데 그렇게 굴림체를 도입해 놓고도 정작 둥근고딕 스타일의 한자 글립은 아직까지도 없다는 게 아쉽다. 예전이야 메모리 용량이 아깝고 하드디스크 용량이 아까워서 뺐다 치지만 지금은 전혀 그런 걱정이 없고 평생 쓸 일 없을 것 같은 유니코드 상의 온갖 외국어 문자도 다 글꼴이 내장되어 있다. 현실적으로 한글과 로마자 다음으로 가장 많이 쓰이는 문자인 한자를, 많이도 필요 없고 상용 한자 4888자만이라도 바탕과 돋움이라는 단조로움을 벗어나게끔 운영체제가 배려를 해 주면 어떨까 하는 생각이 든다.

Posted by 사무엘

Posted by 사무엘

내 프로그램의 중복 실행 여부를 판단하려면? (물론 윈도우 프로그래밍 기준)

실행 직후에 자신만 식별할 수 있는 이름으로 커널 오브젝트를 만들어서, 이놈의 생성 여부로 판단하는 게 제일 무난하고 안전하다. 커널 오브젝트라 함은 메모리 맵드 파일, 뮤텍스, 이벤트 등 이름의 scope가 전역적인 어느 것이라도 될 수 있겠다.

다른 방법으로 중복 실행을 판단하는 방법은 크게 윈도우 아니면 파일로 식별하는 것으로 나뉘는데, 커널 오브젝트만치 완전하지는 못하다. 그 이유를 지금부터 설명하겠다.

※ 응용 프로그램이 생성한 윈도우로 판단하는 법

FindWindow 함수로 나만이 지정하는 윈도우 클래스 이름이나 윈도우 캡션 이름을 검색하여 그게 존재하면 그 윈도우로 포커스를 옮겨 버리고 나는 실행을 종료한다. 대개, 이미 존재하는 인스턴스로 포커스를 옮겨 주는 작업이 필요할 것이므로 윈도우로 검색하는 방법은 어지간해서는 상당히 간편하고 직관적이고 좋은 방법이긴 하다. 다만,

만약 MFC 같은 프레임워크로 프로그램을 개발하고 있었다면, 메인 윈도우의 클래스 이름을 나만의 명칭으로 변경하기 위해 PreCreateWindow 같은 함수를 번거롭게 오버라이드해야 한다.

또한 클래스 이름이 아니라 캡션 이름으로 검색하는 것은 어지간해서는 피해야 한다. 캡션 이름 검색은 모든 top-level 윈도우들에 WM_GETTEXT 메시지를 보내는 방법으로 행해지기 때문에 오버헤드가 클 뿐만 아니라, 이미 실행된 내 프로그램 윈도우가 작업 중이어서 응답을 안 하고 있다면 프로그램 실행이 의도대로 되지 않을 우려가 크다.

윈도우로 검색하는 방법은 근본적으로 큰 약점이 있다. 일반적으로 프로그램이 실행된 직후 로딩, 각종 초기화를 끝내어 메인 윈도우를 생성하기까지는 적지 않은 시간이 소요된다는 것이다. 커널 오브젝트를 생성하는 것처럼 즉시 생성되는 게 아니다. 그렇기 때문에 첫 인스턴스가 아직 메인 윈도우를 만들기 전에 사용자가 실수나 고의로 또 엔터를 눌러서 둘째 인스턴스까지 실행한 경우 여전히 프로그램이 두 개가 실행되어 버릴 수가 있다. 프로그램이 어떤 경우에도 절대로 두 인스턴스 이상이 실행돼서는 안 되는 중요한 프로그램인 경우 윈도우 검색의 결과에만 의존해서는 안 된다.

※ 파일 차원에서 판단하는 법

윈도우 3.1 시절에는 WinMain 함수의 둘째 인자인 hPrevInstance를 살펴보는 것만으로도 내 프로그램의 중복 인스턴스를 판단할 수 있었다.
32비트 이후의 운영체제에서는 인스턴스 핸들의 의미가 한 주소공간 안의 포인터로 완전히 바뀌어 버렸기 때문에, 주소공간 자체가 독립적인 프로세스를 식별할 수는 없게 되었다. 오로지 그 주소공간 안에 로드되어 있는 여러 DLL 같은 모듈들만 식별할 수 있다.

그 반면, 지금도 EXE 내지 DLL 내부에 공유 가능한 섹션을 따로 생성하여 여기에 중복 인스턴스와 관련된 정보를 간단하게 집어넣을 수도 있다. 즉,
#pragma data_seg()
#pragma comment(linker, "/Section:SHARED,RWS")
이런 지시문 안에다가 전역변수를 선언하면 그 변수는 운영체제의 가상 메모리 상으로 나의 모든 인스턴스들이 공유하게 된다는 뜻이다. 자세한 것은 MSDN 참고. 번거롭게 메모리 맵드 파일 API를 호출할 필요 없이 간단한 데이터 공유에는 이 방법이 굉장히 편리하다.

이렇게 파일 차원에서 식별하는 방법은 윈도우 차원에서 식별하는 방법이 잠재적으로 갖고 있는 부작용들이 전혀 없어서 좋으나, 말 그대로 파일에 전적으로 종속적이라는 큰 한계가 있다.
같은 EXE를 이름만 바꿔 복사해서 실행한 것은 중복 인스턴스로 전혀 판단하지 못한다는 것이다. 이 점이 매우 중요하며, 이는 대부분의 경우 원치 않는 결과일 것이다. 결국 실행 파일 그 자체가 아니라 그 실행 파일이 만들어 놓은 결과를 추적해서 중복 실행을 판단하는 접근 방식이 필요하게 된다.

Posted by 사무엘

윈도우 3.x 시절에 MS에 한글 글꼴을 공급한 업체는 왕년의 유명한 국내 벤처 기업이던 큐닉스 컴퓨터였습니다. 한때 프린터까지 만들던 곳인데, 지금은 망하고 글꼴 개발 부분만 모리스 디자인으로 상호를 바꿔 명맥을 유지 중인 걸로 알고 있습니다. 개성체를 비롯해 동글동글한 이솝체를 만든 곳이죠.

이 글꼴들은 같은 명조, 고딕, 궁서라 할지라도 당시 아래아한글 2.x 전문용이 번들로 제공하던 한양 글꼴 equivalent에 비해 미려함이 덜하고 단조로워 보였습니다. 하지만 외국산의 품질 좋은 래스터라이저와 힌팅 정보에 힘입어, 작은 크기에서의 품질 하나는 아래아한글이 적수가 될 수 없을 만큼 정말 좋았지요.
그때는 유니코드라는 개념 자체가 없었고 한글 글꼴은 2350자를 일일이 다 그려 넣는 것밖에 선택의 여지가 없었습니다.

그러던 것이 윈도우 95에 와서는 한글 글꼴 체계가 크게 향상됩니다. 그리고 이때 첫 라이선스 한 한양 글꼴은 그 최신 기술이 모두 반영된 작품이었습니다. 어떤 게 있는지 예를 들면 이렇습니다.

첫째, TTC. 굴림과 돋움, 바탕과 궁서가 한 글꼴 컬렉션으로 병합됨으로써 둘이서 한 한자 글립을 공유할 수 있게 되었으며, 나머지는 다 같은데 영문만 불변폭 글꼴인 ‘-체’ 글꼴 변종도 기억 장소의 낭비 없이 손쉽게 구현할 수 있게 됐습니다. 이런 기술은 작은 고유 문자와 한자를 공용하는 일본에서도 더욱 필요했을 것입니다.
(하지만 이제 굴림과 궁서도 별도의 한자 글립이 있으면 더 좋을 것 같네요. 한국에서는 지금도 명조 고딕 외의 한자 글꼴은 가정용 PC에서 좀체 보기 힘듭니다.)

둘째, 비트맵 자형 내장. 알파벳 글꼴이야 아예 비트맵밖에 없는 FON 파일만 쓰든가, 아니면 트루타입은 정교한 수제 힌팅만으로 작은 크기에서도 아주 보기 좋은 자형을 만들어 냈지만 한글/한자 같은 문자는 아예 비트맵을 만들어 넣어 주는 게 당장 더 유리합니다. 윈도우 3.1 시절엔 이런 개념이 없었던 것 같습니다. 그 바탕체 12포인트는 BT16.TBM이라고 TTF와는 완전히 별개의 파일에 글립이 저장되어 있으며 운영체제가 임의로 불러들이고 출력해 주더군요. 12포인트 말고도 15포인트용 BT20.TBM 파일도 있습니다.
TTF가 자체적으로 다양한 크기의 비트맵을 내장하게 된 것이 윈도우 95부터입니다. 덕분에 굴림, 바탕, 돋움이 모두 자체적으로 비트맵을 갖게 되고 결과적으로 윈도우 3.1보다 글꼴의 품질은 크게 향상되었죠.

끝으로 유니코드 지원입니다. 확장완성형 때문에 큰 물의를 빚긴 했으나 어쨌든 모로 가도 서울만 가면 된다고, 윈도우에서 운영체제 차원에서 11172자 한글 표현이 가능해지고 한글을 조합 글립으로 표현할 수도 있게 된 것이 95에 와서부터입니다.

윈도우 9x를 직접 설치해 본 분들은 아시겠지만 얘네 계열들은 설치 GUI가 정확하게 윈도우 3.1 커널 기반입니다. 16비트 코드와 32비트 코드가 짬뽕이어서 그런지 한글 글꼴도 두 체계가 완전히 짬뽕인 것을 볼 수 있죠. 첨부하는 그림을 보시면 설치 마법사 대화상자 안의 모든 글꼴들은 9x에서 볼 수 있는 ‘한양 시스템’ 굴림이지만, 그 바깥에 있는 약간 조악한 느낌이 드는 글씨들은 전부 윈도우 3.1 ‘큐닉스 굴림’ 10포인트입니다. 둘의 품질의 차이가 한눈에 보이시죠?

컴퓨터의 성능이 향상되고 운영체제가 발달하면서 문자 입출력 기술도 알게 모르게 더욱 정교해지고 범용성이 향상되고 있습니다. 언뜻 보기에 똑같은 기능을 하면서 덩치만 아무 이유 없이 커지는 건 아니거든요.
예전에는 동아시아 버전 아랍권 버전 이렇게 따로 적용되던 기술이 이제는 전세계 어느 기계 내지 소프트웨어에나 동일하게 들어가고 있다는 뜻입니다.

Posted by 사무엘