※ 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 사무엘

2010/04/27 12:51 2010/04/27 12:51
,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/254

윈도우 운영체제가 인식하는 실행 파일 포맷인 PE(portable executable)의 헤더를 보면,
이 EXE/DLL이 실행되는 플랫폼(x86, x64, IA64 등등)이라든가, 이 실행 파일의 특성을 나타내는 플래그 등 여러 정보가 존재한다.
그런데 그 플래그 중에는 'Large address aware' 여부를 나타내는 플래그가 있다.
이건 무엇을 뜻하며, 왜 만들어진 것일까?

윈도우 NT는 도스의 잔재 없이 처음부터 순수 32비트로 개발된 운영체제이다.
32비트 공간에서는 최대 2^32 = 4GB 크기의 가상 메모리를 사용할 수 있는데, MS는 전통적으로 하위 2GB는 응용 프로그램이, 상위 2GB는 커널이 사용하는 구도로 운영체제를 설계했다.

그때는 램은커녕 하드디스크 용량도 4GB보다 훨씬 적던 시절. 그러니 그때 32비트는 가히 무한대에 가까운 공간이었으며, 메모리 분배를 어떻게 한다고 해도 이상할 게 없었다.
응용 프로그램은 언제나 하위 2GB만을 사용하다는 게 무슨 뜻일까?
포인터에서 32비트 크기가 다 쓰이는 게 아니라, 최상위 1비트는 절대로 1이 될 일이 없다는 말이다.

그래서 일부 잔머리 잘 굴리는 프로그래머들은 포인터에다가도 자신만의 1비트짜리 boolean 정보를 최상위 비트에다 얹고, 포인터를 쓸 일이 있으면 그 값을 잠시 제거한 후 사용했다고 한다. 흠좀무.

그런데 세상이 변해서 이제 램이 기가바이트급 스케일이 되었고, 32비트 공간만으로는 부족한 시대가 왔다. 본격적으로 64비트 시대가 도래하기 전부터 데이터베이스처럼 아주 memory-intensive한 프로그램을 돌리던 업계에서는, 유저와 커널을 2:2로 가르지 말고 3:1로 갈라서 응용 프로그램에다가 메모리를 좀더 많이 얹어 달라고 MS에다 끊임없이 요구했다. 그래서 MS는 '물리 주소 확장' 모드라는 걸 만들어 줬다.

사실, 커널도 메모리, 좀더 정확히 말하면 주소 공간이 의외로 많이 필요하다. 2:2도 오히려 부족한 감이 있다. 커널 코드를 얹고 각종 커널 오브젝트를 관리하는 메모리만 필요한 게 아니기 때문이다. 가상 메모리라는 시스템은 그 개념상 메모리를 관리하기 위한 메모리도 요구하는 법. 그와 관련되어 방대한 공간이 필요하며, 디바이스 드라이버를 얹고 돌리기 위한 메모리 등등도 따지면 결코 만만한 수준이 아니다.

3:1로 가르면 응용 프로그램이야 사용 가능한 메모리가 좀더 늘며, 종전에는 응용 프로그램이 한번에 약 1GB 남짓밖에 매핑을 못 하는 memory mapped file도 훨씬 더 큰 크기까지 확장할 수 있다. 하지만 만들 수 있는 프로세스/스레드 수가 감소하며 네트웍이라든가 운영체제의 전반적인 기능상의 한계가 매우 커지고, 운영체제가 이론적으로 관리 가능한 총 물리 메모리의 양도 줄어든다! 이 tradeoff를 반드시 잊지 말아야 한다.

그런데 문제는...
그렇게 3:1로 응용 프로그램의 메모리 주소를 확장하면...
드디어 최상위 비트가 1인 포인터 값이 응용 프로그램으로 오는 게 가능해진다는 것.
그렇다면, 예전에 놀고 있던 최상위 비트를 다른 용도로 활용하던 프로그램을 이런 확장 환경에서 돌리면.....;;; 더 이상의 자세한 설명은 생략한다.

그래서 호환성을 목숨처럼 1순위로 강조하는 MS는, 아무 프로그램이나 일방적으로 넓어진 포인터를 주는 게 아니라, 넓어진 포인터를 줘도 안전하다고 플래그가 따로 지정되어 있는 프로그램에 대해서만 제 기능을 다하도록 하는 정책을 선택했다. 그것이 바로 large address awareness이다. 이 플래그가 없이 빌드된 프로그램은 여전히 메모리를 2GB씩밖에 못 쓴다. 마치 윈도우 XP 이후에도, 별도의 매니페스트를 내장하고 있지 않은 옛날 프로그램들은 비주얼 스타일 테마가 적용되지 않는 것과 같은 맥락으로 말이다.

단, 이건 EXE에 한해서이다. DLL은 그런 선택의 권리가 없다. 확장 주소가 지원되는 EXE에 붙을 수도 있고 지원 안 되는 EXE에 붙을 수도 있으며, 어느 때건 동작을 잘 해야 한다. 따라서 DLL은 반드시 확장 주소를 지원하도록 작성되어야 한다.

본격적으로 64비트 환경이 되면서 확장 주소의 진정한 의미가 드러났다. 이제는 상위 1비트 정도가 아니라 아예 테라바이트급 메모리 주소에도 접근 가능해야 하며, 64비트 프로그램은 '확장 주소 지원' 플래그가 반드시 있어야 한다. 이 플래그가 없으면, 비록 x64 내지 IA64 아키텍처용으로 만들어진 64비트 프로그램이라 할지라도 포인터의 주소로는 여전히 무려 2GB 이내의 값만 들어온다. -_-
포인터 크기를 4바이트 int 크기로 하드코딩하고 제작된 무개념 프로그램을 최대한 쉽게 64비트로 포팅할 수 있게 배려한 것이다. 물론 이 역시 EXE에 한해서이지만 말이다.

large address aware 옵션은 비주얼 C++의 x86 플랫폼에서는 호환성 차원에서 디폴트로 꺼져 있다. 즉, 사용자가 별도로 옵션을 켜지 않으면, 2GB까지만 인식하는 프로그램을 만든다.
하지만 x64/IA64 플랫폼에서는 사용자가 별도로 이 옵션을 끄지 않으면 디폴트로 켜져 있으며, 코드가 2GB 정도가 아니라 4GB 이상의 공간도 안전하게 인식하는 것으로 간주한다. 둘이 묘한 차이가 있다는 것을 기억하자.

물론 굳이 램이 4GB가 아니더라도 64비트는 CPU가 한번에 정보를 처리하는 단위 자체가 더 크다는 점 하나만으로 32비트보다 대용량 데이터를 처리하는 성능이 더 뛰어나다. double 실수형을 하나 스택에 얹을 때만 해도 32비트에서는 CPU 명령을 최소 둘 이상 써야 하는데 64비트에서는 한 번만에 끝난다는 소리이지 않은가. 그렇기 때문에 램 용량이 32비트 크기를 초과하기 전부터도 64비트 프로세서가 개발되어 일부 제한된 영역에서 쓰이기도 했던 것이다.

잘 알다시피 64비트 윈도우는 과거 16-32비트가 그랬던 것처럼 그 정도로 지저분한 호환 계층은 제공하지 않으며, 한 프로세스 공간에 64-32비트 코드가 공존하는 것을 허용하지 않는다. 그래도 윈도우 핸들값은 여전히 32비트 범위 안에만 존재하며 32와 64비트가 값을 그대로 공유 가능하다는 게 신기하다. 하긴, 윈도우 9x에서는 윈도우 핸들값이 아예 16비트 범위에 있었지만 말이다. ^^ 썽킹이라는 말도 참 오랜만에 다시 듣는다.

Posted by 사무엘

2010/04/12 09:12 2010/04/12 09:12
, ,
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/242

컴퓨터 쪽 잡설

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 사무엘

2010/04/05 09:28 2010/04/05 09:28
, ,
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/234

엉터리 번역

윈도우 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 사무엘

2010/03/22 08:26 2010/03/22 08:26
, ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/218

굴림, 궁서의 한자 글립

거의 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 사무엘

2010/02/19 08:47 2010/02/19 08:47
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/190

정신을 차리고 주위를 둘러보니..
회사 사람들은 다 XP 아니면 7을 쓴다.

비스타를 쓰는 사람은 사무실 전체에서 현재 본인밖에 없다...... ㅎㄷㄷㄷㄷ
라고 말하려고 하는데, 다른 부서에 딱 한 분이 더 있어서 총 둘이다. -_-

그래도 개발팀 중에는 나밖에 없고, 게다가 Aero조차 없는 홈 베이직 에디션은 내가 회사 전체에서 유일한 걸로 추정된다. -_-

디자인이나 영업처럼 컴 환경이 그렇게 크리티컬하지 않은 부서들은 다 약속이나 한 듯 그냥 XP에 눌러앉아 있다.
그 반면, 개발이나 기획 쪽은 일찌감치 7로 갈아탔다. 회사에 나보다 늦게 입사한 관계로 컴을 비교적 최근에 지급 받은 사람들은 당연히 윈도우 7을 쓴다.

그렇게 XP와 7이 양분된 구도이고 비스타 구경하기가 의외로 힘들어져 있는 것이다.
그 반면, 본인은 개인용 컴퓨터도 노트북과 데스크톱 모두 비스타 홈 프리미엄으로 2년 넘게 쓰는 중.

내가 전에도 이런 요지의 글을 썼는지 모르겠는데,
비스타는 실패작이 아니다. 그 정도만 해도 충분히 안정적이고 상당히 훌륭한 OS이다.
XP 이후에 너무 긴 시간만에 나오고, breaking change가 너무 많고 너무 무거워져서 욕 얻어먹은 건 사실이지만 그건 시대 정황상 어쩔 수 없는 것들이 대부분이다. XP 다음에 바로 7급의 OS가 나왔어도 갑작스러운 변화 때문에 비판 많이 쏟아졌을 게 대부분이다.

비스타에서 사람 짜증나게 만들던 강화 보안 정책인 UAC는 7에도 당연히 있다.
7이 아무리 비스타보다 산뜻하고 가벼워졌다고 해도 XP나 돌릴 수 있는 컴에서 7을 돌릴 수 있는 건 응당 아니다.
얼리 어답터들의 심정을 이해 못 하는 건 아니지만, 그렇게까지 당장 비스타를 버리고 당장 7로 탈출, 갈아타야 하나 하는 회의감이 든다.

아 그래도..
새로 깔기가 귀찮다는 소리이지, 나더러 '비스타 깔린 컴 쓸래, 7 깔린 컴 쓸래'라고 누가 물으면 동일한 조건에서야 본인도 당연히 후자 고른다. ^^;;; 배경 그림들 예쁜 게 참 많아서 말이다. ㅋㅋㅋㅋ
비스타는 검정+청록색 배색이 테마였다면, 7은 다시 XP처럼 새파란 하늘색을 추구하는 듯하다.

비스타를 대신하여 최고 인기를 고가하고 있는 7이지만, 한글 IME 개발자인 본인의 관점에서는 속을 좀 많이 썩인 OS이기도 하다. 왜 또 쓸데없이 뭘 건드려 놔서 패치를 해야 하게 만들고, 더구나 콘솔에서 세벌식 자판으로 한글을 입력하면 '다다.' 처럼 한글이 덧나는 어이없는 버그도 있다.

알록달록 파랗던 XP의 luna 테마도 이제 아련한 역사 속으로 사라져 가는구나. 이제 XP는 일부 저성능 보급형 넷북에서나 볼 수 있는 듯하다.

Posted by 사무엘

2010/02/11 16:57 2010/02/11 16:57
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/180

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

실행 직후에 자신만 식별할 수 있는 이름으로 커널 오브젝트를 만들어서, 이놈의 생성 여부로 판단하는 게 제일 무난하고 안전하다. 커널 오브젝트라 함은 메모리 맵드 파일, 뮤텍스, 이벤트 등 이름의 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 사무엘

2010/02/08 22:38 2010/02/08 22:38
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/176

윈도우 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 사무엘

2010/01/31 10:01 2010/01/31 10:01
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/163

본인은 컴퓨터 가상화 프로그램으로 VMware와 도스박스(DOSBox)를 애용하고 있다. 순수 도스와 윈도우 3.x까지를 돌리는 데는 도스박스가 독보적인 솔루션인 반면, 윈도우 9x부터 시작해 여타 NT급 운영체제, 리눅스 등을 구동할 때는 VMware를 사용한다.

둘은 구동하는 방식이 근본적으로 다른데 이 차이를 세세히 논하기 위해서는 나도 잘 모르는 CPU 계층에서의 난해한 개념 설명이 필요하다. 하지만 다 모르더라도 이 사실 하나만 기억하면 된다. VMware(와 기타 동급의 가상화 프로그램)는 CPU가 하드웨어 차원에서 자체 제공하는 가상화 기능을 적극 활용하여 동작하며 이는 32비트 윈도우 NT급 운영체제가 아주 허접하게 호환성 에뮬레이션 계층으로 제공하는 NTVDM도 마찬가지이다. 하지만 도스박스는 CPU 동작 자체를 포함해 모든 하드웨어 동작을 소프트웨어적으로 흉내 낸다.

그 결과 둘은 제각기 일장일단을 갖게 된다. D는 동작 방식의 특성상, 태생적으로 성능은 V보다 꽤 뒤쳐진다. 오늘날의 1~2GHz급 초고성능 컴퓨터에서 겨우 90년대 중반, 윈도우 95 출현 직전의 486~펜티엄급 PC의 성능을 낸다. 사실, 도스의 수명은 거기가 끝이었으므로 그 정도만 동작해도 D는 제 할 일 충분히 해 낸 셈이다. 32비트 보호 모드도 지원하여 둠 정도까지는 도스용을 잘 실행해 내지만, 퀘이크까지 되면 차라리 윈도우용으로 포팅된 퀘이크를 돌리는 게 낫다는 뜻.

하지만 D는 소프트웨어 계층이 담당하는 일이 많은 덕분에, V의 방식으로는 상상도 할 수 없는 다양한 옛날 하드웨어를, 호스트 컴퓨터의 성능만 좋다면 얼마든지 재현해 낼 수 있으며 컴퓨터 구동 속도도 세밀하게 제어할 수 있다.

V의 경우 PC 스피커 소리가 제대로 나지 않으며, 위험한 데이브는 너무 빠르게 돌아가고 금도끼(도스용)는 너무 느릿느릿 실행된다. 이것은 V의 방식으로는 소프트웨어적인 방법으로 제어를 할 수 없다. 윈도우 3.x를 설치는 할 수 있으나 guest extension(VMware tools)을 제공하지 않으며 겨우 16컬러 VGA에서밖에 사용할 수 없다. 사실 V는 근본적으로 16비트 구닥다리 플랫폼 에뮬이 주된 목적인 제품이 아니다.

그 반면 D는 어떤가? 아예 PC 스피커 소리와 옛날 애드립 소리를 사운드카드로 흉내 내어 준다. 그냥 비프음뿐만 아니라, 하드웨어를 교묘하게 제어하여 PC 스피커로 얼추 사운드카드 소리를 내던 기법까지 완벽하게 재현된다! 화면/동영상/음성 캡처야 요즘 가상화 프로그램들이 거의 필수로 갖추고 있는 기능이지만, 아예 프로그램이 내리는 미디 명령을 캡처하여 게임 음악의 미디 악보를 저장하는 기능은 하드웨어를 소프트웨어적으로 흉내 내지 않고서는 구현할 수 없는 기능인 것이다.

없는 하드웨어를 소프트웨어로 다 만들어 준다. 일일이 autoexec나 config.sys 튜닝을 하지 않아도 EMS, XMS 같은 메모리 세팅도 다 자동으로 해 주고, 과거의 베사 SVGA 비디오나 미디 카드, 마우스, 심지어 모뎀 따위도 프로그램이 필요로 하면 다 잡아 주니 V와는 비교가 안 되는 그야말로 도스 천국이 아닐 수 없다. 옛날 잡동사니 드라이버 파일을 뒤지면 윈도우 3.x도 그래픽/사운드 잡아서 쓸 수 있다. 더구나 D는 무려 윈도우 9x에서도 돌아간다!

아무튼 D는 참 대단한 프로그램임이 틀림없다.
그러고 보니 굳이 NT 계열로 운영체제가 완전히 넘어가기 전부터도 윈도우 9x 시대가 되면서 디렉터리의 파일들을 정렬-_-해 주는 유틸리티, 그리고 파일 첫 글자를 입력하여 지운 파일을 살리는 undelete 유틸리티는 아련한 추억 저편으로 사라진 것 같다. FAT32를 도입한 윈도우 95 OSR2가 이를 더욱 가속화한 게 아닌가 싶다. 요즘 NT 계열에서 쓰이는 NTFS는 아예 구조적으로 파일이 자동으로 정렬이 유지되는 파일 시스템이다.

그 전의 FAT16은 하드디스크 크기를 겨우 2GB까지밖에 인식 못 했었다. 요즘은 하드가 아니라 램 크기가 수 GB인데! ㅎㄷㄷㄷ FAT16이 MS 도스 4.0에서 처음 도입되어서 그때는 그걸 갖고 “하드디스크 용량 제한이 ‘없어졌다’”라고 말을 붙이곤 했다. (과거의 FAT12는 한술 더 떠서 하드디스크를 32MB까지밖에 인식 못 했음)
하지만 윈도우 9x는 FAT32로도 100수십 GB 이상의 하드는 제대로 인식 못 하니 어차피 요즘 컴퓨터에서는 쓰지도 못한다.

참고로, VMware에다 과거 윈도우 운영체제를 설치해 보면, 2000/ME부터는 사운드를 자동으로 인식하고 멀티웨이브까지 되는 반면 95/98은 그렇지 못하다. USB 메모리를 안전하게 제거하는 트레이 메뉴가 추가된 것도, 그리고 미디에 소프트웨어 신시사이저가 기본 내장된 것도 2000/ME부터이다.

이런 맥락에서 보면 윈도우 ME는 같은 9x 계열 중에서 그저 나쁘기만 한 게 아니라 최신 하드웨어의 지원 면에서는 98 SE보다 나아진 점도 분명 있다. 하지만 괜히 도스로 부팅하는 기능만 쏙 빼서, 도스 지원 때문에 윈도우 9x 계열을 일부러 선호하는 사용자들로부터도 외면 받았고, 1년 남짓 XP가 출시되는 바람에 아주 짧은 시간만에 묻혀 버린 비운의 마지막 9x 계열 운영체제로 역사에 기록된 셈이다.

98도 마찬가지. 처음 나왔을 때는 윈도우 95+IE4 통합일 뿐이라고 비아냥거림이 많았지만, 95는 마우스 휠, USB, 멀티 모니터라는 개념 자체가 없었던 캐 구닥다리였다. 그런 것들이 도입되고 IME의 문자 입력 프로토콜이 유니코드로 확장된 것만으로도 98은 정말 숨통을 튼 것이었다. 98 SE는 윈도우 9x 계열 중에서는 정말 최장수 안정판이었음도 주지의 사실이다.

Posted by 사무엘

2010/01/19 21:10 2010/01/19 21:10
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/150

메모장의 변천사

윈도우즈에서 메모장은 그야말로 운영체제의 역사와 함께 해 온 기본 프로그램이다.
1.0때부터 있어 왔고, 윈도우 7에서도 도구상자 하나, 리본 하나 장착되는 법이 없이 그 베이직한 형태를 유지하고 있다.

사실, 맥에서는 TextEdit, 우분투 리눅스에서는 gedit라고 하여 워드패드와 메모장의 구분이 딱히 없이 서식/비서식 텍스트를 모두 다룰 수 있고 텍스트의 경우 문법 강조까지 지원되는 우수한 에디터가 있는 반면 윈도우즈는 그렇지 못하다.

TextEdit은 수십 MB의 텍스트 파일을 열어서 수십 MB에 달하는 구간을 블록으로 잡아서 지워도 성능 하락이 그렇게 크게 느껴지지 않을 정도로 에디팅이 굉장히 탄탄하게 잘 만들어져 있다는 생각이 들었다.
(참고로 <날개셋> 편집기는 그렇지 못하다. 특히 TSF를 A급으로 지원해 주는 데 드는 오버헤드가 굉장히 큰 편이기 때문에, 10MB급 이상 되는 파일을 편집할 때는 “TSF 지원” 옵션을 끄고 프로그램을 다시 실행하는 게 좋다.)

어쨌든..
메모장은 운영체제가 제공하는 기본 에디트 컨트롤을 사용한다. 보통 텍스트 에디터는 매 줄별로 linked list를 사용하는 반면, 에디트 컨트롤은 텍스트 전체가 한 배열이다! 텍스트 맨 앞에다 문자를 삽입하는 경우 그 뒤 문자열은 일일이 한 자씩 뒤로 밀려나며, 메모리 공간이 부족한 경우 전체 메모리가 재할당된다. ㅎㄷㄷㄷ

이런 이유로 인해 메모장은 비록 가볍다고 해서 덩치 큰 파일을 편집하는 데 좋은 환경이 되지는 못한다. 윈도우 9x 때까지는 16비트의 잔재로 인해, 아예 64KB가 넘는 파일은 읽지도 못하던 암울한 시대가 존재했었다. NT급으로 와서는 그런 물리적인 크기 한계는 비록 해결되었지만, 에디팅 엔진은 여전히 64KB짜리 작은 파일에나 적합하게 설계되어 있다는 사실은 변함없음을 기억할 필요가 있다.

거의 변화가 없는 것 같은 메모장이지만 운영체제 버전이 올라가면서 개선된 것도 은근히 많았다.
Fixedsys 고정이던 글꼴을 바꿀 수 있게 된 것이 윈도우 98부터이고, XP부터는 자동 줄바꿈 옵션을 끈 경우 줄/칸 위치를 보여주는 옵션도 추가되었다.

같은 메모장이라 해도 윈도우 9x 계열과 NT 계열은 저렇게 읽을 수 있는 파일 크기만 차이가 나는 게 아니라 편집 기능에도 차이가 존재한다. 전자는 찾기 기능만 제공되는 반면 후자는 바꾸기도 지원하며 한번에 전체 바꾸기(replace all) 기능도 제공된다.

그런데 전체 바꾸기 기능을 구현한 방식이 무척 재미있다.
윈도우 2000/XP는 말 그대로 매번 메시지를 보내서 순차적으로 찾기/바꾸기를 수행한다. 그래서 화면이 쭉 스크롤되어 내려가는 모습이 보이며, 바꾸기 작업을 수행한 후에 Ctrl+Z를 누르면 바로 직전에 바꾼 문자열 하나만 취소가 된다.

그 반면 비스타는 문자열 전체를 선택하여(select all) 얻어 온 후, 내부적으로 문자열을 기계적으로 빠르게 치환한다. 그러고 나서 문서를 그 텍스트로 일괄 교체한다. 덕분에 Ctrl+Z를 누르면 바꾸기 작업이 전부 취소된다.

근본적으로 에디트 컨트롤에는 일괄 바꾸기 기능을 수행하는 기능이 없기 때문에 응용 프로그램이 그런 것을 직접 구현할 필요가 있다. 하지만 비스타의 메모장은, 메모리를 좀 희생하는 대신 더 빠르고 일괄 취소가 가능한 방법을 선택한 것이다.

Posted by 사무엘

2010/01/11 10:32 2010/01/11 10:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/98

« Previous : 1 : ... 15 : 16 : 17 : 18 : 19 : 20 : 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:
2635585
Today:
2383
Yesterday:
1754