« Previous : 1 : ... 26 : 27 : 28 : 29 : 30 : 31 : Next »

본인은 컴퓨터 가상화 프로그램으로 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

황금도끼 도스용 버전을 처음 해 본 게 초등학교 고학년이던 92년이었습니다.
그 후 무려 17년이 지나서 몇 달 전에.. 마메를 돌려서 오락실 아케이드 버전을 처음으로 해 봤습니다. -_-;;

둘을 충분히 해 보고서 내린 결론은
도스용과 오락실용의 차이는 아래아한글과 MS 워드의 차이와 비슷하다는 것. =_=;;;;
모든 동작 방식이 손에 익어 있고 예측 가능한 아래아한글과는 달리, MS 워드류는 영 적응이 안 되는 야생마 같습니다.

도스용은 눈에 띌 정도로 스프라이트 수가 엄청 감소(strip down)해 있다는 것을 알 수 있었습니다. 메모리가 부족해서 그런 거겠죠. 그리고 원본에 존재하던 다중 스크롤도 삭제되었고, 움직이던 독수리 눈도 도스용에서는 응당 정지해 있습니다.

때리는 프레임이 남자와 여자는 2프레임, 그리고 가장 날렵한 캐릭터인 난쟁이 할아버지는 단 1프레임이죠. 뛰기 전에 잠깐 다리를 굽히는 동작도 오락실에는 있지만 PC에는 없습니다.

하지만 이 덕분에 PC판이 주인공의 조작 반응성이 더 날렵-_-해진 것은 있습니다. 오락실은 타이밍을 놓쳐서 적이 나의 때리기 공격을 피하고 반격을 하는 게 가능하지만 PC는 거의 그런 게 없지요. 물론 나뿐만 아니라 적도 더 날렵해졌지만.. -_-;; 때리면 거의 무조건 맞거나 아니면 아예 피하거나 이뿐입니다.

1단계에 나오는 꼬리로 공격하는 괴물은 PC판보다 다루기가 훨씬 더 어렵고 불을 쏘는 용도 발사 후의 cooldown이 굉장히 길어서 운용하기 어렵습니다. 그거 발사한 후 뒤의 적에게 반격을 당하기 쉽습니다.
PC판은 용에서 한번 떨어지고 나면 용은 거의 즉시 달아나 버리는 반면, 오락실판은 그래도 관용이 좀 있더군요.

몬스터의 AI도 원판이 훨씬 더 강력합니다. 작은 몬스터도 점프 공격을 하며, 해골은 훨씬 더 똑똑하고 무섭고 공격 데미지가 강합니다. PC판은 해골은 남자 몬스터와 체력도 일치하고, 점프 공격을 할 줄 아는 것 외에 딱히 차이가 없거든요. 사실, 몬스터별 체력이라든가 데미지 체계도 PC판은 딱 정해져 있는 반면 오락실판은 이미 수십 판을 해 봤는데도 파악이 잘 안 되겠더군요.

몬스터는 PC판처럼 무조건 주인공을 향해 접근만 하는 게 아니라 근처에 용이 있으면 용부터 탑니다. 그리고 PC판처럼 x축부터 일치시킨 후 y축으로 접근하는 게 아니라, y축부터 일치시킨 후 달리기 박치기 시도를 굉장히 잘 합니다. 이런 이유로 인해 용 같은 걸 뺏어 타기도 PC판보다 더 어렵습니다.

그리고 무엇보다도 오락실판이 PC판보다 어렵고 전략 전술을 근본적으로 다시 짜게 만드는 원인은.. 바로 근거리 공격 때문입니다.
PC판은 모든 몬스터들은 주인공이 너무 바싹 붙어 있으면 일단 뒤로 물러나서 일정 거리를 확보한 후 공격합니다. 게다가 다른 AI가 전반적으로 무척 멍청하기 때문에, PC판으로는 한 대도 안 맞고 엔딩 보는 것도 가능합니다.

하지만 오락실판은 그렇지 않으며 얄짤없이 근거리에 있는 주인공은 곧바로 공격합니다. 매우 위험합니다. 게다가 큰 몬스터인 대머리 아저씨나 칼 든 기사는 주인공을 내던지기까지 하며, 원거리에서도 공격 성향이 더욱 짙습니다. 용 없이 기사 두 명을 피해 없이 상대하는 건 거의 불가능에 가깝습니다. (제가 보기엔) 큰 몬스터를 향해 날라차기를 해도 실패하고 반격 당할 확률이 훨씬 더 높고요.

다만, 오락실판에만 존재하는 필살기가 있더군요(마법 쓰는 것 말고). 뛰면서 위로 점프한 후, 칼을 아래로 내리찍기. 이게 데미지가 굉장히 커서 작은 몬스터는 한 방에 바로 골로 보내더군요.
PC판의 몬스터라면 100% 저게 성공일 텐데, 오락실판 몬스터는 그걸 피할 줄 압니다. PC판은 몬스터가 y축으로 왔다갔다 하는 걸 거의 볼 일이 없는 반면 오락실판은 y축으로 이동하여 필살 공격을 회피할 줄 압니다. 그래서 제일 밑으로 내려가서 회피를 못 하게 하고 때리면 성공률이 꽤 높습니다.

오락실판은 날라차기를 하다가 목표물을 맞으면 목표물이 힘을 받아 튕겨나가고 나는 추진력이 탁 떨어지기 때문에 타격감과 탄성을 느끼죠. 하지만 PC판은 목표물을 맞든 안 맞든 언제나 정해진 공식만큼 앞으로 나아갑니다. 기계적입니다. 오락실판은 도둑을 때려서 나온 물약병도 통통 튀지만, PC판은 그렇지 않습니다.

이런 것 말고도, 오락실판은 PC판에서 게임의 쾌감을 떨어뜨리던 그런 요인들이 없습니다.
가령, 열심히 때리고 한 몬스터를 집어 던지는 모션을 취하느라 uncontrollable한 도중에는 다른 몬스터가 나를 공격하지 않습니다. 저 경우를 따로 배려를 했다는 걸 단번에 알 수 있었습니다. PC판은 나도 반격을 당해 튕겨 나가고 잡혀 있던 몬스터도 같이 튕겨 나가는 어색한 상황이 벌어지죠.

난쟁이 도둑을 때리면 PC판은 완전 랜덤한 다른 위치로 도망가 버려서 일일이 쫓아다니며 또 때려야 하지만 오락실판은 원래 있던 곳에서 그렇게 멀리 나가지 않으며, 또한 도둑을 때리기도 훨씬 더 쉽습니다. 어지간히 날라차기를 해도 맞고, 불을 쏘는 용으로도 굉장히 쉽게 맞힐 수 있습니다. 도둑이 약병을 다 내 준 뒤에도 이따금씩 가만히 죽어 버려서 게임 진행을 더 못 하고 끝내야 하는 버그도 오락실판에는 전혀 존재하지 않죠.

또한 '해골 다구리'. 가끔 여러 해골들이 있는 상태에서 막다른 곳에 몰리면, 해골들이 나를 일어나서 반격할 틈도 안 주고 계속 점프 공격을 해서 결국 죽게 만드는 경우가 PC판에는 있습니다. 오락실판은 그런 식의 공격 패턴을 지니고 있지는 않거든요.
여러모로 PC판보다 더 신경을 쓰고, 쓸데없는 것 갖고 사용자를 짜증 나지 않게 설계가 돼 있다는 것을 알 수 있었습니다. 다만, 단거리 공격까지 틈을 조금도 안 주는 거는 너무 어렵습니다.

오락실용은 세 마리 정도는 죽고 엔딩을 봤습니다. 점수는 230점대, strength는 85점까지는 가 봤네요.

Posted by 사무엘

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

윈도우 비스타에서는 모르긴 몰라도 그래픽/사운드 기술과 관련된 계층이 굉장히 많이 바뀌었습니다.

※ 비디오 (그래픽)

예전에 글로 쓴 적이 있지만 제가 가장 먼저 인지한 큰 변화는, 이제 동영상 화면까지 Print Screen 키로 바로 캡처가 된다는 것. 그것도 Aero (desktop window manager)가 가동 중일 때뿐만 아니라 DWM이 돌아가지 않는 고전 모드일 때도 동일하게 잘 됩니다. 옛날에는 인터넷 같은 데서 웹브라우저 창을 옮기면 그 안에서 돌아가던 동영상은 위치가 이동하지 않거나 느릿느릿 굼뜨던 현상도 심심찮게 볼 수 있었는데 이 역시 비스타에서는 아련한 추억이 됐지요. 그래픽 카드와 운영체제의 발전에 힘입어, 드라이버 계층에서의 어떤 큰 변화가 생긴 게 틀림없습니다.

멀쩡하게 상위 계층의 윈도우 API만 썼다면 비스타라고 해도 안 돌아갈 이유가 없는데, VMware, 메이플, 비주얼 스튜디오 같은 프로그램들이 옛 버전이 비스타에서는 제대로 동작하지 않아 버전업을 해야만 하는 이유도 저런 ‘저수준에서의 미묘한 변화’ 때문이라고 풀이할 수 있겠습니다. XP와 비스타는 각종 하드웨어 드라이버들이 호환되지 않죠. 하지만 비스타와 7은 드라이버 차원의 호환이 유지될 것으로 알려져 있습니다.

윈도우 XP부터는 심지어 운영체제 설치 GUI나 안전 모드에서도 VGA 640*480 16컬러는 완전히 자취를 감추었고, 하이 컬러 이하로는 디스플레이 모드가 설정이 되지도 않습니다. 게임용 3D 그래픽 가속까지는 뒷받침을 원활히 못 하더라도, 최소한 1024*768 하이컬러 이상급의 그래픽 모드는 메인보드가 내장하는 VBE 규격만으로도 지원되게 컴퓨터 규격이 향상됐기 때문이지요. 물론 이것만으로는 비스타 체험 지수는 1밖에 나오지 못하며, 창을 끌어 보기만 해도 답답함이 느껴지기 때문에 비디오 카드 드라이버 업데이트는 필수입니다.

XP보다 전에 선보였던 윈도우 2000은 시대가 시대였으니만큼 여전히 16/256컬러의 잔재를 볼 수 있습니다. 하지만 설령 안전 모드의 16컬러 표준 VGA에서 실행될 때라 하더라도, 그래픽이 쉴 새 없이 변하고 있는 곳에 마우스 포인터를 가져갔을 때 포인터가 깜빡거리거나 사라지지 않습니다. 윈도우 9x 시절에는 상상도 할 수 없었는데! 이걸 보고도 저는 당시 2000은 보통 운영체제가 아니라는 생각을 했었습니다. 하드웨어 차원의 지원이 필요하거든요.

90년대 말, 윈도우 95급 컴퓨터 시절에만 해도(메인보드의 폼 팩터가 슬슬 AT에서 ATX로 넘어가던..), 운영체제의 표준 디폴트 포인터만 깜빡임 보호가 되었지 사용자 정의 포인터는 여전히 깜빡거렸습니다. 비디오 카드의 성능이 썩 좋지 못했다는 뜻이겠죠. 하지만 몇 년 사이에 이마저도 깜빡임이 완전히 사라졌습니다.

아, 그러고 보니 이것도 그래픽 체계의 변화와 관계가 있는지는 모르겠지만, 비스타는 알 수 없는 이유로 인해 콘솔을 전체 화면 모드에서 실행하는 기능이 사라졌고(무조건 창 모드만 가능), 콘솔에다가 파일이나 디렉터리 이름을 마우스로 드래그하여 떨어뜨리는 기능도 없어졌지요.

※ 오디오 (사운드)

지금까지 열거한 비디오 쪽뿐만 아니라 오디오 계층도 윈도우 비스타는 굉장히 많이 바뀌었습니다.
일단 윈도우 95부터 XP까지 큰 차이 없이 제공되던 볼륨 조절 유틸리티 sndvol32.exe가 없어지고 비슷한 기능을 sndvol.exe가 대신 담당하기 시작했는데, 인터페이스가 싹 달라졌죠.

옛날에는 컴퓨터 내부에 소리를 만들어내는 ‘장치’가 여럿 존재했고 윈도우 XP까지는 각 장치들을 멀티미디어 API를 써서 enumerate한 뒤, 장치별로 볼륨을 조절하는 구도였습니다. PC 스피커 따로, 애드립 소리를 내는 미디 따로, 오디오 CD 따로, 입력 단자 따로, 그리고 일반 wave 오디오 따로! (PC 스피커는 볼륨 조절이 되지 않는 게 보통이지만, 노트북 컴퓨터 중엔 그것도 조절되는 게 있었답니다.)

특히 CD롬 드라이브는 CPU와는 전혀 상관없이 자기가 직접 오디오 CD를 재생했습니다. 윈도우 95 시절의 CD 재생기는 그저 오디오 CD에다가 재생/정지/탐색 명령을 내리고, 드라이브로부터 트랙별 시간 정보를 가져와서 재생 지점을 업데이트해 주는 ‘시다바리’ 기능밖에 하지 않았었습니다. 당시 도스용 퀘이크 같은 게임은 오디오 CD 겸 CD롬 형태로 게임을 만들어서 게임 음악은 아예 오디오 트랙의 형태로 제공하기도 했지요.

그러나 지금은 시대가 바뀌었습니다. 사운드 카드는 이제 랜 카드와 더불어 메인보드의 일부로서 완전히 편입이 되어 버렸습니다. 그리고 소리를 내는 모든 장치는 가장 범용적인 매체인 wave 오디오로 통합이 되어 버렸습니다. 이는 전적으로 컴퓨터 성능이 좋아진 덕분입니다.

미디는 이제 어설픈 FM 사운드가 아니라, 소프트웨어적으로 노래방 수준 음향을 wave 오디오로 흉내 내어 주는 신시사이저가 재생합니다. 오디오 CD도 마찬가지. 컴퓨터가 디지털 음원을 일일이 추출, 파악해서 wave 오디오로 내보내는 건 요즘 필수입니다. 그래야 파형 visualization도 보여주고 mp3/wma 리핑 기능도 제공할 수 있을 테니까요.

사정이 이러하니 예전처럼 ‘장치’별 볼륨 조절은 완전히 무의미해졌습니다. 그건 한 프로그램이 어떤 장치를 꺼내서 소리를 출력하면 다른 프로그램은 그 장치를 이용할 수 없던, 쉽게 말해서 멀티웨이브조차 안 되던 윈도우 3.1~95 캐 암울하던 시절의 사고방식이죠. 그나마 wave 오디오의 멀티웨이브는 윈도우 98~2000급으로 넘어가면서 가능해졌지만, 여전히 애드립 미디 같은 다른 장치는 멀티웨이브가 되지 않았었습니다.

비스타부터는 운영체제가 모든 사운드를 wave 오디오 하나로 통제하고 믹싱까지 담당합니다. 그래서 비스타의 볼륨 조절 프로그램을 살펴보면 예전과 같은 개념의 장치 구분은 완전히 사라지고, 현재 실행 중인 응용 프로그램별로 상대적 볼륨을 조절하는 게이지가 나와 있습니다. 이거야말로 윈도우 XP 이하에서는 상상조차 할 수 없던 일이었지 않습니까?

※ 윈도우 각 버전별 비교

Aero Flip3D를 보면서 신기해하던 게 엊그제 같은데 비스타와 오피스 2007이 나온 지도 벌써 2년이 넘었습니다. 제가 XP를 주 작업용 OS로는 ‘빠이빠이’ 한 지도 반 년은 넘은 것 같습니다. 이제는 윈도우 7이 나온다고 해도 비스타하고 시간 간격은 윈도우 95와 98 사이의 간격과 별 차이가 안 날 정도로 시간이 흐른 셈이군요. 그렇게 긴 시간이 지난 것 같지는 않은데.

비스타는 XP 이후로 꽤 긴 시간만에 출시된 데다 상당히 무거운 편인 컴퓨터 요구 사양, 그리고 이질적으로 바뀐 보안 정책, 일부 옛날 프로그램과의 호환성 문제 같은 여러 잡음 때문에 비스타는 그 기술적인 우수성에 비해서는 그렇게까지 환영 받지는 못한 것 같습니다. 그래서 MS도 7에다가 더 전략 가중치를 더 부여하고 있는 듯하기도 하고요.

약 2001~2002년경에 2000/ME/XP 이던 구도가 앞으로는 조만간 XP/비스타/7이 되지 않을까 싶습니다. 비스타는 ME와는 급이 다른 운영체제임에도 불구하고! 차라리 7로 갈아타면 탔지, XP는 앞으로도 한동안은 없어지지 않을 최장수 운영체제로 기억에 남을 것 같습니다.

저의 주 개발 분야인 문자 입출력 쪽만 보더라도 비스타는 일단 TSF를 주된 입력 프로토콜로 완전히 굳혀서 운영체제의 기본 입력기로 지정도 가능하게 했고(XP는 여전히 IME 모듈만 가능함), 일부 TSF A급 확장 프로토콜도 도입했으며 전세계 모든 언어 입력기와 글꼴을 다 내장하고 있습니다. XP로 치자면 ‘동아시아 및 complex script 지원’ 옵션이 선택의 여지 없이 무조건 켜져 있는 것과 같다는 뜻입니다.

한자 글꼴도 단순히 ‘한중일 통합 한자’뿐만 아니라 확장 A, 그리고 심지어 surrogate 영역의 확장 B까지도 Simsun-extB 같은 외국의 확장 글꼴까지 자동으로 대체 동원해서 운영체제 차원에서 제대로 표시해 주는 걸 보고 정말 놀랐습니다. 비스타에서는 굳이 ‘한컴바탕확장’이 없어도 이런 한자들을 어디서나 볼 수 있습니다. <날개셋> 다음 버전에서는 글꼴을 본뜰 때 이런 점도 감안하도록 수정할 예정입니다.

윈도우 ME는 잘 알다시피 태생이 9x 계열이기 때문에 95 이래로 변함없던 유니코드 API 부재, 지저분한 16비트 도스의 잔재에다 불안정한 커널, 64K 리소스 제한 같은 단점은 고스란히 갖고 있습니다. 그래서 비슷한 시기에 나온 2000보다는 95/98과 더 동일시됩니다. 안정성은 떨어지는 주제에 덩치만 더 무거워지고, 겉보기로만 도스로 빠져나가는 옵션은 또 없애 놓으니, 도스와의 호환성 때문에 9x 계열 운영체제를 찾는 파워 유저로부터조차도 외면 받을 수밖에 없었습니다.

하지만 ME도 98 SE에 비해서 장점이 없는 것은 아니어서, 부팅 속도가 매우 빠르고 최신 하드웨어 인식은 역시 98보다 확실히 더 탁월하여 2000급에 필적합니다. VMware로 각 운영체제들의 가상 머신을 만들어 보면 2000/ME 이상은 사운드가 자동으로 잡히는 반면, 95/98은 그렇지 않습니다. 또한 2000/ME부터가 미디 신시사이저를 기본 내장하고 있고 멀티웨이브 기능도 더 원활하게 잘 감지됐습니다. 외장 하드와 USB 메모리를 별도의 드라이버 설치 없이 바로 인식하고, ‘하드웨어 안전하게 제거’ 기능을 갖추고 있는 것도 2000/ME부터입니다.

Posted by 사무엘

2010/01/11 09:47 2010/01/11 09:47
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/69

회사 동료가, 수백 개의 작은 그림 파일들을 엑셀을 써서 카탈로그처럼 일목요연한 표 모양으로 한데 정리해야 할 일이 있었습니다. 그 많은 그림들을 일일이 Alt+I, P, F로 삽입하는 건 사람이 할 짓이 못 되었기에 프로그래밍을 할 줄 아는 제가 좀 도와 줬습니다. 셀마다 각 파일들을 이미지로 담고 있는 HTML 표 코드를 생성하는 프로그램을 짠 후, 그 표를 엑셀에서 import하는 방법을 썼지요.

쉘 스크립트라든가 하다못해 엑셀의 매크로를 능숙하게 다루는 분이라면 더 쉬운 방법으로 이 문제를 해결했을지 모르나, 저는 그런 지식은 없었기 때문에 이런 일까지 비주얼 C++을 동원해서 해결했습니다.
그런데 문제는 다음부터였습니다. 이렇게 만든 엑셀 문서는 다른 컴퓨터에서는 그림이 보이지 않았습니다. 그림이 문서에 완전히 내장(embed; by value)되지 않고 링크만 저장되었던 것입니다(by reference).

저는 굉장히 당황하지 않을 수 없었습니다. 원래 MS 오피스의 제품에서 그림을 자체 기능으로 삽입하면, 그림은 기본적으로 문서에 완전히 내장됩니다. 링크라는 개념 자체가 사실상 없는 걸로 저는 알고 있었습니다.

그림을 주로 링크로 취급하던 대표적인 프로그램이 과거 아래아한글이었지요. 그래도 얘는 링크가 깨지면 그림이 있는 경로를 다시 묻기라도 했으며, 3.0부터는 그림을 문서 안에다 내장하는 기능도 추가되었습니다. 그림을 링크만 할지 문서에 내장시킬지를 얼마든지 쉽게 지정할 수 있으며, 한번 그렇게 한 후에도 한 상태로 된 그림을 다른 상태로 전환 역시 얼마든지 할 수 있습니다. 그렇기 때문에 전혀 어려울 게 없었습니다.

xlsx의 내부 구조를 들여다보고는 저는 기겁을 하고 말았습니다. 압축 파일 내부의 media 디렉터리에 아무 파일도 없는 걸로 보아 내장이 안 된 건 확실했는데, 이놈의 링크는 또 C:\로 시작하는 완전 절대 경로로 저장되더군요! 이런 이유로 인해, 상대방 컴퓨터에다가 그냥 그림 파일만 던져 준다고 해서 그림을 볼 수 있는 것도 아니며, 디렉터리 구조까지 완전히 일치해야 했습니다.

진짜로 문서 내부에 내장된 그림과, 이렇게 링크만 달랑 걸린 그림이 제각기 어떤 방식으로 저장되는지는 파악할 수 있었습니다만, 엑셀 프로그램 내부에서는, 아래아한글처럼 어떤 그림이 링크인지 내장인지 알려주거나 그 속성을 바꾸는 기능은 아무리 눈을 씻고 찾아 봐도 없었습니다! 이거 뭐 나더러 어쩌라고?

한국어 검색 엔진으로는 이런 문제에 대한 해결책도 거의 찾을 수 없어서 구글에게 영어 검색어로 의뢰를 해 봤지요. 통상 구글링을 해 보면 여러 해외 IT 분야 '지식인' 내지 포럼 사이트들이 검색되는 게 있습니다. 그런데 네이버 지식인 류와는 또 다른 게, 질문만 쏙 보여주고서 답변을 보려면 결제 내지 최소한 회원 가입은 해야 하는 형태인 게 많습니다. 딱 본인처럼, 그림이 들어간 HTM 표를 엑셀로 가져왔다가 나중에 낭패 본 케이스가 하나 있긴 했는데 답변을 보지는 못했습니다. 썅~

그래서 다음으로 생각해 본 방법은, xlsx의 내부 xml 코드를 고쳐서 문서 내부의 '링크 그림'을 '완전 삽입 그림'으로 인위적으로 수정하고 media 폴더에다 강제로 그림 파일도 추가한 후, 이를 다시 zip으로 압축하는 것이었습니다. 오랜만에 OpenXML 덕을 좀 보는가 싶었는데...

문제는 이 방법마저도 통하지 않았습니다. 압축을 푼 내부 구성 파일을 수정 없이 그대로 빵집 같은 유틸로 재압축만 했는데도, 엑셀은 오류가 있다면서 그 압축(=xlsx) 파일을 읽어들이길 거부한 것입니다. xlsx뿐만 아니라, 오피스 2007 SP2에서 추가된 OpenDocument (역시 xml+zip 기반) 방식 역시 마찬가지. 얘네들은 zip 압축이긴 하지만, 일반 압축 유틸리티가 생성하지 않는 메타 정보도 같이 집어넣는 것 같습니다. 이쯤 되니까 진짜 꽤 열받기 시작했죠. MS 제품이 이 정도로 개념 없는 줄은 몰랐는데.

또 한 30분을 삽질하다가 꽤 허무하게 문제를 해결은 했습니다.
htm 문서를 파일-열기로 열면 그림이 링크로 삽입되는 반면, 웹브라우저에서 이 htm을 연 것을 Ctrl+C로 복사하여 엑셀에다 붙여넣으면, 그 그림들은 완전히 내장으로 삽입된다는 것을 알게 되었기 때문입니다. 아놔~ ㅁㄴㅇㄹ

MS 제품과 아래아한글 사이의 넘사벽 이질감을 또 확인하는 계기였습니다. 이놈의 MS 제품들은 내가 문서라든가 프로그램의 내부를 확실하게 제어(under my control)한다는 느낌을 주질 않고 제멋대로 붕 뜬 상태로 알아서 하다가, 그걸 응용/변형해야 할 상황이 생길 때 사람 완전 낭패 보게 만듭니다. 좋게 말하면 당장 사용하고 결과물 만들기엔 편한 것이고, 나쁘게 말하면 사용자를 바보 만들고 일정 실력 이상은 오르는 게 거의 불가능하게 돼 있는, 좀 사악한(?) 기능 디자인이 아닐까 싶습니다.

MS 워드도 97 시절부터 10년을 넘게 써 왔지만 개요/스타일이라든가 특히 개체를 배치하는 방식에 대해, 저는 독학만으로는 절대 완전히 적응 못 하겠다는 결론을 내리고 포기했습니다. 그 반면 아래아한글은 97은 물론이고 워디안/2002 급 이후 버전도 손에 착 잘 맞는 편입니다. MS 워드에만 있던 고급 기능을 아래아한글 특유의 세밀한 스타일로 잘 배치했다는 점은 인정합니다. 지금도 아래아한글이 기술적으로 워드에게 뒤지는 면모는 있으나, 아래아한글에도 MS 워드가 절대로 흉내낼 수 없는 디자인 상의 안정성과 편안함이 있습니다. (민족주의에 호소하는 한글 표현 같은 것 말고요. 한글 표현마저도 엄밀히 말하면 오히려 MS 워드가 좀더 앞서 있습니다.)

사실 이런 비슷한 느낌은 프로그래밍 언어를 쓰면서도 받습니다. C/C++ 이외의 언어, 특히 type이 굉장히 느슨한 언어로 코딩하다 보면 이 개체가 과연 value로 전달되는지, reference로 전달되는지, new만 있고 delete가 없는 언어들은 도대체 언제 이 개체가 garbage collect되어 소멸되는지?
내가 짜는 건 한 줄이지만 이게 내부적으로 어떤 알고리즘으로 구현되며 데이터가 100개가 아니라 10만 개가 넘어가면 성능이 어떻게 될지?
이런 게 신경쓰여서 불안해서 코딩이 잘 되지 않는 경우가 있습니다. 나와 언어가 일심동체가 못 되고 붕 떠 있는 느낌.

그런 상위 계층 언어들이 how보다 what을 중시하게 하고, 익숙해질 경우 생산성은 더 뛰어난 것은 사실이나 저는 C/C++스러운 저수준 면모가 더 마음에 들고 편안하더군요.

Posted by 사무엘

2010/01/11 09:46 2010/01/11 09:46
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/68

아래아한글 2007은 2006년 한글날에 출시되었던 초창기 RTM 판을 어둠의 경로로나 잠깐 구해 쓰다가 다시 2005로 돌아와 버렸고, 저는 그 존재감을 1년이 넘게 잊고 지내 왔습니다.

그런데 얼마 전 한 지인께서 보내 주신 아래아한글 2007은 정말 사뭇 달라진 모습이었습니다.
사실 아래아한글이 그 때 이후로 3년에 가까운 시간 동안 아직까지 메이저 버전업이 없는 상태이긴 하지만 그래도 제품 개선은 정말 꾸준히 돼 오고 있었습니다. MS 식으로 표현하자면, 단순한 버그/보안 업데이트 수준을 넘어 서비스 팩 정도는 된다는 거지요.

각종 패치와 업데이트를 다 받고 나니 버전은 7.5.8.527이 되었습니다. 아래아한글도 날개셋과 마찬가지로 비주얼 C++ 2003 (7.1)로 개발되고 있는 건 여전하고요.
윈도우 비스타에서 “시스템 스타일” 테마를 쓰면드디어 Aero 반투명 프레임이 적용된 대화상자가 나오더군요. (2005는 그렇지 않았음.) 윈도우 XP 시절엔 MS 오피스 2003 테마가 그럭저럭 볼만 했으나 비스타에서는 아주 밍밍하고 보기 안 좋은 모양이 돼 버리기 때문에 차라리 아래아한글 2007 특유의 기본 블루 메탈 테마나 시스템 스타일 테마가 낫습니다.

지금까지 아래아한글은 대화상자에서 숫자만 입력 받는 에디트 컨트롤의 동작이 정말 기괴했습니다. 글씨 크기나 여백량 등. 세벌식 자판을 쓰고 있으면, 2004 이하에서는 Shift+알파벳의 고유 숫자도 동작을 안 하고, 0~9의 쿼티 숫자 배열도 동작을 안 해서 꼼짝없이 글자판을 바꾸거나 numlock 키패드만 써야 했습니다. 그러던 것이 2005에서는 Shift+알파벳 숫자는 인식되도록 개선됐고, 2007에서는 숫자 입력란에서는 아예 한글 글자판이 동작 안 하고 무조건 0~9 숫자만 인식하게 바뀌었던데 저는 차라리 이런 결정을 환영합니다. 정말 속 답답하던 동작 방식이었는데 무척 잘 했습니다.

글꼴을 고르는 콤보 박스가 화살표 키 선택만 가능한 게 아니라 이름을 입력도 해서 빠르게 찾을 수 있게 된 것은 매우 환영할 만한 기능. 비주얼 C++ IDE는 2003에서 2005 이후로 넘어가면서 이런 점에선 오히려 퇴보했죠. (물론 글꼴이 주류인 프로그램은 아니지만.)

그리고 운영체제 한글 IME로 비완성형 문자가 ?로 바뀌고 제대로 입력되지 않던 버그.. 드디어 고쳐진 것을 확인했습니다. 이제 아래아한글로도 <날개셋> 한글 입력기를 띄워서 각종 확장 한자나 옛한글까지 그대로 입력할 수 있습니다.

어떤 프로그램이 유니코드를 얼마나 잘 대비해서 만들어졌는지 측정하는 좋은 척도 중 하나는 파일 이름 인식인데요.
제가 보기엔 아래아한글은 아직도 윈도우 9x를 지원하느라, 혹은 TCHAR 같은 범용 자료형으로 Unicode-prepared된 코드를 작성해 놓지를 못해서... 하이튼 이 둘 중 한 이유로 인해 과감하게 스위치를 유니코드로 바꿔서 빌드 못 하고,
당장 유니코드 문자 지원이 절대적으로 필요한 부분에다가만 유니코드 함수를 임시방편으로 끼워넣은 거라는 인상을 받습니다. 윈도우 XP sp2 이상만 지원하는 MS 오피스 2007과는 달리, 한컴 제품은 똑같은 2007이 무려 윈도우 98 이상을 지원한다고 명시하고 있지요.. 물론 날개셋은 윈도우 95/NT4까지 다 지원.. 그러고도 유니코드도 100% 지원하죠.

임시방편이라고 생각하는 근거를 말씀드리자면..
영문 윈도우에서 HWP 파일은 한글이 섞인 파일도 잘 불러옵니다. 한글이 섞인 디렉터리 이동도 되고 파일 열기도 대화상자와 drag/drop 방식 모두 잘 되더군요. 이것만 해도 크게 개선된 것입니다. 하지만 HWP가 아닌 TXT 파일은 열리지 않았습니다. 더구나 “다른 프로세스가 파일을 사용 중이어서 열 수 없습니다”라고 에러 메시지도 ‘잘못’ 나오고요.따로 처리할 이유가 전혀 없는데도 파일 타입에 따라 유니코드 API 사용 여부를 따로 처리하고 있으니, 일관성 있는 처리가 아니라 HWP에다가만 임시방편 처리를 추가한 거라는 결론을 잠정적으로 내린 것이죠. 또한 ‘열기’ 대화상자라든가 타이틀에 뜨는 문서 파일 이름이 여전히 ???? 로 바뀌어 나온다는 것도 개선돼야 할 것입니다. 진짜로 여기서는 Ansi, 저기서는 유니코드 API를 섞어 쓴 것입니다.

한편, 아래아한글도 드디어 2007 나중판에서는 문서를 PDF로 저장? 인쇄? 하는 기능이 자체 포함되었습니다. 예전에 별개의 제품으로 팔던 PDF converter 엔진이 그대로 포함되어, 자체 글꼴인 HFT까지도 깔끔한 PDF로 바꿔 줍니다! 2.5 확장팩 시절의 추억의 신명 시스템 글꼴과 3.0/96 때의 #로 시작하는 수많은 글꼴들을 이제 깔끔한 PDF로 만날 수 있어 무한 감개무량하며 앞으로 아래아한글 쓸 일이 더욱 늘 것 같습니다.

단, 하나 옥의 티를 찾았는데요.
HFT 영문 이탤릭 글꼴이 PDF로 제대로 인쇄되지 않고 그냥 normal 글꼴을 기울인 형태로 바뀌어 버리더군요.
아래아한글이 내장하고 있는 신명조와 윈도우 운영체제가 내장하고 있는 바탕은 둘 다 ‘한양 시스템’에서 제작했으며 원도가 거의 일치합니다. 물론 후자가 영문의 폭이 좀더 크긴 하지만 비슷하죠.

하지만 둘의 큰 차이를 하나 꼽자면 전자는 영문에 이탤릭 전용 글꼴이 있다는 것입니다.
더구나 아래아한글 2.5 정도에서 추가된 걸로 기억하는 수식 전용 글꼴은 당시 교과서와 문제집 같은 출판물에서나 볼 수 있던 그 자형을 재현한 것이어서 더욱 의미가 컸습니다. 이것도 이탤릭체가 없으면 거의 무용지물이죠. 이것이 PDF로 만들면 여전히 되살아나지 않으니 개선이 필요하다고 봅니다.

끝으로 이건 극소수 매니아 계층 이외에게는 거의 의미가 없을 내용이지만 제품의 완성도 차원에서 하나 언급하겠습니다. 아래아한글의 한자 코드 체계와 관련이 있는 내용입니다.
아래아한글 2.0 이후에서부터 추가된 약 11000여 자의 제 2 수준 한자는 유니코드 BMP 영역에 대부분 이미 존재하지만(A급), 어떤 건 BMP에 없고 무려 surrogate 영역(B급)까지 가야 하는 것도 있으며 어떤 건 아예 유니코드 자체에 아직 정식 등재되지 않은 것(C급)도 있습니다. 물론 유니코드 버전이 계속 올라가면서 C급 한자라는 집합은 완전히 사라질 수도 있지요. 지금도 C급 한자는 거의 10여 자 남짓밖에 안 됩니다.

아래아한글은 이미 제 2수준 한자와 유니코드 사이의 변환 테이블도 다 갖추고 있고 이를 문자표에다 제공하고 있습니다. 하지만 정작 한컴 2바이트 코드로 저장된 파일을 가져와 보면 아래아한글이 지금처럼 유니코드 surrogate를 정식 지원하기 전에 워디안/2002 시절에 임시로 사용하던 변환 테이블을 여전히 수정하지 않은 것 같습니다.
가령 B급 한자에 속하는 0x531C는 한중일 통합 한자 확장 B인 U+20850 (surrogate 영역)이지만 이 글자를 한컴 2바이트 코드로 저장하여 불러와 보면, 옛날의 임시 주소인 U+A700이라는 엉뚱한 문자가 되지요.

아래아한글은 97에서 워디안으로 넘어갈 때 정말 큰 진통을 겪긴 했지만 그래도 그때 고비를 잘 넘긴 것 같습니다. 그때 HWP 파일 포맷이 딱 바뀐 이후, 지금은 아랍 어, 세로쓰기, 문서 워터마크 등 문서의 뼈대 구조를 결정하는 굵직한 기능이 엄청 많이 추가되었음에도 불구하고 워디안부터 2007까지 파일 포맷이 근본적으로 바뀌는 일 없이 하위/상위 호환성이 잘 유지되고 있으니까요.

다음 버전(아마 2010)은 지금 MS 오피스 다음 버전이 추구하고 있는 것과 마찬가지로 ODF 스펙 구현이 몰두 중이라고 합니다. 개인적인 생각은 아래아한글도 어서 워드처럼 개체가 사각형이 아닌 모양으로 본문을 감싸는 기능이 지원돼야 한다고 생각합니다. 앞서 지적했지만 유니코드 지원도 강화돼야 할 것이고, 좀더 욕심을 부리면 워드처럼 TSF A급 프로그램으로 발전하고 한양 PUA가 아닌 유니코드 낱자 결합 방식으로 옛한글을 지원해야 할 텐데, 참 가야 할 길이 멀군요!

Posted by 사무엘

2010/01/11 09:43 2010/01/11 09:43
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/65

※ 1기: 1.x 커널

아래아한글 1.x 시절의 에디팅 엔진입니다. 잘 알다시피 단순한 plain text에다가 약간의 서식만 붙은 것 같은 초보적인 형태였죠.
글씨의 크기 조절은 가로 확대/세로 확대만 되고 가변폭 글꼴은 사실상 지원되지 않았으며, 문단 여백도 그냥 칸 수로 지정하던 시절이었습니다. 표는 선그리기 기능으로 그려야 했습니다.
문서의 파일 포맷은 최소한 1.0, 1.1, 1.2 이렇게 세 방식 이상이 존재했던 것 같습니다. 아래아한글 1.5x는 1.2 방식과 문서 파일 포맷이 동일하며, Alt+V (새 이름으로 저장)를 누르면 과거 1.1 방식으로 저장도 할 수 있습니다.

※ 2기: 2.0 커널

1992년에 출시된 2.0부터 97까지 굉장히 장수하여 안정화한 한컴 2바이트 코드 기반의 에디팅 엔진입니다. 글씨 크기를 포인트로, 여백은 mm 같은 단위로 지정할 수 있게 되고 색깔도 8종류 중 하나로 지정할 수 있게 됐습니다. 가변폭 글꼴의 표현이 가능해지고 그림, 표 같은 각종 개체를 넣을 수 있게 됐습니다. 개요, 스타일 같은 개념도 생겼죠.

문서 파일 포맷은 2.0, 2.1, 3.0으로 나뉩니다. 사실 아래아한글 2.1은 기능면에서는 2.0과 그렇게 큰 차이가 없으나, 글꼴 쪽으로 굉장히 많은 변화가 생겼고 또 2.1에서 문서 압축 저장이 추가됐기 때문에 포맷이 바뀐 것으로 기억합니다. 아래아한글 2.5는 파일 포맷의 변동이 없었기 때문에 2.1과 포맷이 동일합니다.
3.0은 하이퍼텍스트라든가 자체 벡터 드로잉 기능, 그리고 윈도우 OLE 데이터 같은 것을 저장해야 하는 데다, 때마침 2.1 방식 문서 파일의 암호가 크랙되어서 큰 논란을 겪기도 했기 때문에 바뀌었지 싶습니다.

※ 3기: 21세기 커널

정말 많은 우여곡절을 겪은 워디안 때부터 지금까지 큰 변화 없이 이어지고 있는 에디팅 엔진 겸 파일 포맷입니다. 아마 아래아한글은 앞으로 이 방식에서 더 바뀔 일이 없을 것 같습니다.
문자 인코딩이 시대의 조류를 따라 드디어 유니코드로 바뀌고 글씨라든가 용지의 크기 제한이 완전히 사라졌습니다. 색깔도 RGB 어느 색으로나 줄 수 있게 되었으며, 여러 쪽에 걸치는 표처럼 MS 워드의 앞선 기능을 대폭 수용하여 2.0 시절 커널과는 비교가 되지 않는 많은 기능들이 추가됐습니다.

더구나 워디안 이후로 아래아한글은 과거에 없던 여러 기능이 추가되고 있음에도 불구하고 예전과는 달리 파일 포맷의 하위 호환성은 비교적 잘 유지되고 있는 것 역시, 처음에 파일 포맷 설계를 확장성 있게 잘 한 덕택이라고 볼 수 있습니다.
아래아한글도 이제 open xml 기반 문서 파일 포맷도 적극 도입해야 하지 않나 싶습니다만 과연 실현될지?

- MS 워드의 경우 97~2003 커널이 가장 보편적으로 널리 쓰이다가 2007에 와서는 에디팅 엔진과 파일 포맷이 또 크게 바뀌었지요. 95 그 이전 기수는 잘 모르겠네요.
개인적으로 워드보다도 엑셀에서, 편집 가능한 셀 수가 크게 증가하고 색깔 제한이 없어진 것을 매우 환영합니다.

Posted by 사무엘

2010/01/11 00:37 2010/01/11 00:37
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/56

한메 타자 교사(HTT).
정말 전설적인 타자 연습 프로그램이며, 이후에 등장한 동일 분야 프로그램들의 근간을 제공했습니다.

아래아한글 1.x와 비슷한 연배의 프로그램이죠. 90년대 초반에 개발된 도스용 응용 프로그램들이 90% 이상 볼랜드 터보 C 2.0 기반이었고 그래픽 모드 동작을 위해 BGI 라이브러리를 사용한 것과는 대조적으로 HTT는 MS C 6.0 기반입니다. (비주얼 C++ 6.0이 아님!)

  당시에 통용되던 프로그램들을 좀더 살펴보면,
페르시아의 왕자도 1, 2 모두 MS C로 개발되었고 볼랜드 계열 빌드가 아닙니다.
아래아한글은 16비트 바이너리들은 전통적으로 볼랜드 컴파일러를 써 왔지만, BGI 라이브러리 기반은 물론 아니지요.

HTT는 제가 두벌식을 쓰던 시절과 맥을 함께 했습니다. 세벌식 연습은 도스용 한컴 타자 연습으로 주로 했고 HTT를 쓰지 않았거든요. 390에서 최종으로 갈아타던 시절에는 박 정만 님이 개발한 <광타>의 도움을 받기도 했습니다. 그때가 얼마나 불모지였냐 하면 390 말고 최종 연습을 정식으로 지원하는 프로그램이 “없었습니다.” 윈도우 운영체제는 말할 것도 없고 아래아한글 97이 제공하던 최종 자판에도 오류가 있었습니다. 지금이야 워디안 때부터 최종 자판이 제대로 지원되기 시작했고, 윈도우용 한컴 타자 연습에도 최종 배열이 추가되긴 했지만, <날개셋> 타자연습이 첫 등장하던 시절엔 정말 제 프로그램의 지위가 더욱 독보적이었었습니다.

한메 타자는 일부러 이렇게 만들기라도 했는지 문장 연습하는 감이 묘하게 좀 좋지 않았습니다. 키를 계속 누르고 있으면 글자가 생기는 느낌이 더디고 좀 latency가 느껴집니다. 아마 이것 때문에 그 당시 세벌식 연습을 한메 대신 한컴으로 사용하지 않았던가 생각됩니다.

두벌식으로는 단문도 700 이상은 정말 무리였지만 지금 세벌식으로 연습해 보니 800 넘는 것도 가뿐하군요. “드는 정은 몰라도 나는 정은 안다.”라는 문장은 완전 세벌식 최적화 문장이어서 1000을 넘기기도 했습니다.

그리고 베네치아 게임을 오랜만에 해 보니,
<날개셋> 타자 게임의 혹독하기 그지없는-_- 지옥 훈련에 단련돼 있는 저한테는 정말 애들 장난도 아니었습니다. 떨어지는 속도도 느리고 단어도 훨씬 더 짧고 쉬운 것들이고..!
1단계부터 시작해 보니 2만점대의 점수로 끝탄을 깼습니다. 껑충 바이러스가 두 번이나 걸렸습니다.

8단계부터 시작하니 클리어 시 보너스가 더욱 붙어 47000점대의 점수를 획득했습니다. 물론 단 한 번도 HP를 소모한 적이 없었으므로 재건 바이러스는 아무 의미가 없었죠.

<날개셋> 타자연습의 게임은 베네치아를 전혀 어려움 없이 가뿐하게 엔딩 보는 개발자 본인도 만신창이로 간신히 다 클리어할 정도로 월등히 더 어렵게 짜여 있습니다. 옛날 버전은 지금보다도 더 어려웠어요. -_-;; 난이도와 각종 주인공 밸런스들은 거의 05~06년 이후로는 더 수정 없이 완전히 정착한 듯합니다. 지금 이 상태가 딱 적당하며, 더 어렵게도, 더 쉽게도 만들 필요 없을 것 같습니다. 지금은 타자를 치는 인구가 훨씬 더 늘었으니 국민 평균 실력도 영어 실력만큼이나 더욱 상향 평준화해 있을 거라는 점, 모아치기 같은 세벌식 고급 입력 기능을 십분 활용할 수 있다는 점을 감안하면 말이죠.

옛날에 두벌식 쓰던 시절엔 베네치아도 6~8단계 정도만 되면 글자 떨어지는 게 무서워서 차마 못 할 정도였는데 정말 격세지감입니다. 그나저나 “에이즈 바이러스 퇴치!”와 “지뢰 바이러스”는 도대체 뭘 하는 놈이고 왜 넣었는지 모르겠습니다. 전자는 아무 효과 없는 꽝인 것 같고, 후자는 글자들이 지뢰에 부딪히면 점수가 깎이는 것 정도밖에 모르겠네요.

<날개셋> 타자연습 1.x를 개발하던 초창기 시절엔 한메, 한컴, 광타는 물론이고 신의 손, 번개손, 천타를 꿈꾸며 같은 당대의 경쟁(?) 프로그램들을 많이 참고했습니다. 개인적으로는 도스용 <신의 손>이 정말 완성도가 높다고 인정하며, 그 열악한 640*480 16컬러에서 어지간한 게임을 방불케 하는 비주얼 디자인을 연출해 낸 것에 최고의 점수를 주고 싶습니다. 게임도 나름 테마를 갖춰서 무척 잘 만들었죠.

아무튼, 한메 타자 연습을 보니 이런 저런 여러 생각이 들었답니다. 그리고 세벌식 만세입니다. =_=;;;

Posted by 사무엘

2010/01/11 00:35 2010/01/11 00:35
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/55

아무리 MS 워드가 다른 기술이 월등하고 훨씬 더 프로페셔널하고 무엇보다도 파일 포맷이 국제적으로 널리 통용되고 다 좋다고 하나, 아래아한글의 비장의 무기들.

글자 모양/문단 모양을 구분할 수 있는 속성 복사 Alt+C

그리고 Alt+B 키매크로. MS 제품에도 심지어 비주얼 스튜디오에는 키매크로가 있습니다. Visual Basic 기반의 더 복잡하고 전문적인 매크로 이전에 이런 게 없나 궁금합니다. 키매크로는 차라리 과거의 도스용 아래아한글만한 시절이 없었죠.
사실 매크로, 핫키 정도는 과거 윈도우 3.1의 “레코더”처럼 운영체제 차원에서 유틸이 하나쯤 있어야 합니다. 너무 초보자 위주의 마우스 GUI에만 치중하다 보니 GUI 운영체제들은 컴퓨터를 정말로 효율적으로 활용하게 해 주는 자동화, 프로그래밍, 일괄 처리 기능이 너무 미약하죠.

하나 더, 특정 스타일을 바로 지정하는 Ctrl+숫자 단축키. 이거 정말 워드에는 없나 궁금합니다.
사실 이따금씩은 도스 시절의 잔재인 “글꼴 단축키”가 아쉽기도 합니다. 블록 잡고 Alt+L, K, T, C, D 끗. (한글 폰트를 ‘견명조’로 바꾸기 ^^)

단축키가 더욱 빛을 발하는 또다른 분야는 표입니다. 저는 비슷한 난이도의 표 문서를 아래아한글과 워드로 모두 작성해 봤습니다. 셀 블록 잡기, 병합, 분할, 서식 지정 등등.
지켜보는 사람도 말하더군요. “님은 아래아한글 쓸 때는 대부분 양손이 키보드에 가 있고 단축키로 하는데, 워드는 꼭 스타 하는 것처럼 마우스 움직임이 복잡하고 많네. ㄳ”

워드 2007에서 표 작업 정도 하려면 ‘아래에다 셀 삽입, 셀 제거’ 같은 자주 쓰는 기능을 간추려서 Quick Access Toolbar에다가 옮겨놓기부터 먼저 해야 합니다. Home, Table 이런 리본들 왔다갔다하다 보면 정신 없습니다.

물론 워드가 훨씬 더 합리적으로 기능 잘 제공하는 것도 많습니다. 가령, 여러 아이템을 클립보드에다 복사해서 골라가며 붙이는 게 실무에서 이렇게 유용한 줄은 몰랐습니다. 오피스 2000부터 추가된 기능이죠.

아래아한글은 기본적으로 2.0 시절부터 표를 그림이나 문자 같은 동일한 개체라는 개념으로 봐 왔습니다. 그래서 여러 페이지에 걸치는 표는 2002에서 에디팅 엔진을 새로 디자인할 때에야 드디어 가능해졌습니다. 하지만 워드는 애초부터 표는 레이아웃의 일종으로 구현되었으며, 아래아한글처럼 표 전체를 한 글자처럼 취급하는 기능이 없습니다. 이건 HTML의 구조와도 비슷하죠.

아래아한글이 2.0 이래로 별다른 변화 없이 제공해 온 개체 배치 방식은 저는 완전히 이해하여 프로그램과 제가 일심동체가 되어 있는 반면, MS 워드가 개체를 배치하는 방식은 저는 나름 97 이래로 워드를 쓰고도 아직도 알쏭달쏭입니다. 내가 이렇게 바꾸면 프로그램이 이렇게 딱 동작할 거라는 확신이 없습니다. ㅜㅜ

서식 지정하는 방식, 특히 불릿/개요 같은 문단 속성도 마찬가지. 아래아한글은 딱 프로그래머스럽게 동작하는 반면 워드는 정말 제멋대로.. 그 미묘한 감각 차이는 아래아한글처럼 독학 자습만으로는 도저히 습득을 못 하겠습니다.

워드와 아래아한글은 서로 정말 극과 극에 가까운 다른 철학으로 디자인된 프로그램이라는 건 두 프로그램을 모두 중급 이상 활용하는 분이라면 누구나 공감할 것입니다. 저는 이미 초등학교 고학년 때 그림, 표, 메일 머지, 목차, 각주, 스타일, 개요 등등 아래아한글 2.X 전기능을 마스터한 반면 워드는 성인이 된 지금도 아직까지 그 동작 알고리즘이 뿌옇게 흐리게만 보입니다. 한 프로그램의 철학에 익숙한 사람이 다른 프로그램에도 능숙해지기는 어려운 장벽이 있습니다. 그래서 두 프로그램 중 하나가 쉽게 없어지지는 않을 것입니다.

워드에는 아래아한글처럼 매 언어별로 글꼴의 상대 크기와 장평, 자간을 세밀하게 맞추는 기능이 아쉽고, 아래아한글에는 워드처럼 사각형이 아닌 개체의 실제 모양대로 글자가 흐르는 어려운 기능, 아주 정교한 서식들(덧말, 첫 글자 자동 키우기 등, 아래아한글에도 없지는 않으나 글자 배치가 워드에 비해 완성도가 떨어짐) 같은 게 아쉽습니다.

아래아한글이 2004에서야 surrogate를 지원하기 시작하고 2005부터 아랍/히브리 문자를 제대로 지원하기 시작한 건 굉장히 늦은 감이 있지만 바람직한 향상이라 생각됩니다. 그나저나 2005는 2007에서 잘 쓰던 과거 신명 시스템 글꼴들을 왜 인식을 못 하나 모르겠습니다. 태 시스템 것만 인식되네요. (태 가는 헤드라인) ㅜㅜ

Posted by 사무엘

2010/01/10 23:52 2010/01/10 23:52
,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/42

지금은 오나전 아련한 추억이 됐죠. ㄱ-

1. 포트 충돌이 일어나면 모뎀과 마우스를 동시에 못 쓰던 것. ㄲㄲㄲㄲㄲㄲㄲㄲ
(시스템 종료 후 컴이 자동으로 꺼지기 시작,
마우스 휠과 USB 포트, 키보드와 마우스 단자가 PS 포트로 변경...
한 97~99년을 전후해서 다 그렇게 바뀐 것 같더군요.)

2. 도스를 완전히 못 벗어난 윈도우 9x 특유의 블루 데드 스크린과
64KB 리소스 제약..
이건 지구상의 어떤 운영체제에도 없던 이상한 제약이 아니었나 싶습니다.
16비트에서는 도스, 아니면 풀 32비트에서 유닉스, OS/2급의 빵빵한 운영체제 이런 구도였지, 둘을 저렇게 짬뽕한 OS는 윈도우 9x 부류가 유일했으니까요. MS가 고객 수요에 맞춰 장사를 정말 잘 한 것입니다.

3. 물론 이건 운영체제라기보단 드라이버 탓이 더 크겠지만
윈도우 98 시절까지만 해도 멀티웨이브 안 되던 컴도 많았어요. -_-;;
사운드 카드가 동시에 한 프로그램밖에 쓸 수 없는 자원이었던 캐암울한 시절도 있었습니다. ㄱ-

윈도우 2000/ME로 넘어오면서부터

- 소프트웨어 시뮬만으로 미디 신시사이저 지원
- 멀티웨이브 본격 지원
- 메모리 스틱, 외장하드 등 어지간한 USB 기억장치를 자동 인식. "이 장치를 안전하게 제거" 메뉴 자체가 생김 (98 SE는 아직 그런 거 없음.)

꽤 많은 변화가 생겼던 것 같습니다. 과거의 제약이 차츰 사라졌죠.
윈도우 ME는 비록 악명은 높지만 최신 하드웨어 인식 잘 하는 건 98보다 뛰어나다는 걸 확실히 인정함.

그리고 마우스 포인터.
제 기억이 맞다면, 아마 윈도우 2000은 VGA 640*480 16 컬러에서 돌아갈 때도 마우스 포인터가 그래픽이 바뀌는 곳에서 깜빡거리지 않을 거에요. 그거 보고 무척 놀랐던 기억이 납니다.
XP부터는 이제 안전 모드에서도 VGA 16컬러는 볼 일이 없어졌고... ㄱ-

하드웨어 지원을 받아서 마우스 포인터가 깜빡거리는 게 없어진 것이 한 90년대 중반부터인데, 이때도 지원이 완전하지는 못해서 흑백 monochrome 기본 커서가 아닌 커스텀 포인터는 여전히 깜빡거리기도 했었습니다.

CD롬 부팅 후 곧바로 운영체제 설치가 가능해진 것도 2000부터이죠?
NT에 그런 기능 있었을 리는 없고,
9x 계열에도 그런 거 없습니다. 그래서 vmware에서 세팅할 때도 먼저 도스 + fdisk 파티션부터 만들어야 합니다.

Posted by 사무엘

2010/01/10 23:21 2010/01/10 23:21
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/34

« Previous : 1 : ... 26 : 27 : 28 : 29 : 30 : 31 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/08   »
            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:
1420306
Today:
97
Yesterday:
546