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

개인적으로 1995-6년 사이는 PC 게임 환경의 역사상 굉장히 의미심장한 과도기였다고 생각한다.
플랫폼이 도스에서 윈도우로 넘어가고 있었고, 그래픽 역시 VGA 320*200 256색 모드를 탈피하여 2D 게임을 기점으로 고해상도화하기 시작했다. 사실, 그래픽 가속기라는 개념이 등장한 것도 이 무렵부터이고, 비록 아직 듣보잡 지위이긴 하나 DirectX란 것도 그때 개발되어 나왔다. 빌 게이츠는 윈도우 95를 게임용 엔터테이먼트 플랫폼으로 만들려고 안간힘을 다하는 중이었다.

패키지 게임의 경우, 저장 매체도 CD롬이 슬슬 플로피 디스크를 대체하기 시작했다. 하지만 그 당시 게임은 650MB 공간을 꽉 채울 정도로 대용량은 아니었다. 97~98년 사이에 출시된 스타크래프트도 음악과 동영상을 제외한 립버전이 200MB 안팎이었고, 윈도우 95 역시 실제 운영체제 파일 용량은 100MB도 채 하지 않던 시절이다.

이때 몇몇 게임은 CD롬을 아주 재미있게 활용했다. 디스크를 오디오 CD 겸 CD롬 겸용으로 만들어서 파일은 50-100MB 정도의 공간만 차지하고, 나머지 공간에다가는 게임 배경 음악을 집어넣은 것이다. 대표적인 예가 퀘이크 1이다. 옛날에 무슨 팝송 영어 교재 CD도 그렇게 겸용 형태였다. 공간 활용을 잘 한 경우라 하겠다.

게임 내부에서 사용하는 음악을 일반 CD 플레이어로 간단히 들을 수 있을 정도로 노출한 것이긴 하지만, 개인적으로 그건 굉장히 기발한 방법이라고 생각했다. 또한 그때는 그 CD를 정품 인증 수단으로 활용하기도 했다. 비록 가상 CD 기술 때문에 완전히 무력화됐지만 말이다.

그 당시에 오디오 CD는 CPU와는 완전히 별도로 동작했기 때문에 CPU에 부담을 전혀 주지 않았다. 요즘이야 MP3 틀어 놓고 온라인 게임도 마음대로 할 정도로 하드웨어 환경이 좋지만, 486이나 펜티엄급 컴퓨터만 해도 MP3 하나 트는 것만으로 CPU 사용률이 10~20% 정도 치솟던 시절이었다.

미디보다 음질 좋지, CD롬의 남는 용량을 활용하지, CPU 부담 안 주지, 40분 남짓한 정도의 시간이면 게임 사운드 트랙을 모두 담는 데 별 무리도 없지(게임 음악은 은근히 짧으며, 나머지는 전부 반복이다. ^^), 허접하게나마 정품 체크도 간단히 할 수 있지.. 일석이조가 아닐 수 없었다.
요즘은 온라인 게임 클라이언트가 최하 기가바이트급이다. 배경 음악은 미디도 아니고 그냥 내부적으로 mp3/wma/ogg 같은 걸 그대로 재상한다. 불과 15년 남짓 전인데 세상이 이렇게 달라졌다니 참 격세지감이다.

Posted by 사무엘

요 며칠, 압축 프로그램으로 7zip과 압축시대-_-를 써 보다가 다시 빵집으로 복귀했다.

빵집!
한창 알집이 불안정함, 버그, 황당한 독자 포맷 때문에 파워 유저들을 중심으로 까이고 있던 무렵에, 개인 명의로 순수 공개로 개발된 프로그램인지라 한동안 인기를 누렸다. 하지만 개발자의 개인 사정 때문에 너무 오랫동안 버전업이 못 되고 있어서 차츰 사용자가 다시 줄고 있다.

하긴, 빵집이 나오기 전에 알집이 국내 압축 유틸리티의 판도를 완전히 뒤집어엎긴 했다. 알집이 없었으면 본인도 WinZIP이나 WinRAR 같은 것이나 어렵게 크랙판 구해서 썼을테니 말이다.
컴퓨터를 잘 모르는 초보자의 관점에서는 압축 포맷 나부랭이를 떠나서 아무 포맷이나 원큐에 압축을 풀고 할 수도 있는 프로그램을 원했을 것이고 알집은 수요 분석 하나는 잘 했다. (그보다 더 옛날엔, 아예 A, E, X 같은 옵션을 익혀서 온갖 어려운 명령행 유틸리티로 압축을 했으니 더욱 암울했다)

과거 WinZIP이 압축하기/풀기 마법사에다가 완벽한 쉘 통합(탐색기 우클릭)까지 환상적인 인터페이스 껍데기를 선보였다면, 알집은 ‘새 폴더’라는 개념을 처음으로 도입했고 빵집은 ‘알아서 풀기’, 복사해서 붙여넣기 등을 추가하여 더욱 편리한 기능을 제공했다. 요즘은 압축 프로그램이 액세서리로 심지어 CD 이미지 파일까지 열 수 있다. 압축 파일은 아니지만, 파일 시스템 정보를 포함한 아카이브 파일이라고 볼 수 있기 때문이다.

그런데 요즘 압축 프로그램에게 또 필요한 덕목이 생겼으니, 바로 64비트+유니코드 지원이다. 그야말로 필수가 됐다. 64비트 OS에서는 우클릭 메뉴가 안 나온다거나, 요즘 세상이 어느 세상인데 일본어로 된 영화 자막 파일의 압축을 못 푼다거나 해서는 곤란하다.

하지만 빵집은 안타깝게도 저게 되지 않는다. 시스템 코드 페이지가 한글로 되어 있지 않으면 프로그램 UI가 죄다 깨진다. 또한, 정확한 재연 조건을 잘 몰라서 빵집 잘못이라고 100% 단정은 못 내리지만, 빵 폴더 같은 쉘 통합 기능을 사용하다 보면 아주 가끔 explorer가 죽는 현상을 경험한다.
왜 빵집을 ‘의심’하는가 하면, 첫째, exception 상황을 알리는 에러 메시지 박스가 델파이로 개발된 프로그램이 죽었을 때 뜨는 스타일이기 때문이다. 둘째, 빵집이 설치되지 않은 컴에서는 그런 현상을 지금까지 전혀 겪은 적이 없기 때문이다.

어쨌든 이런저런 이유로 인해 본인도 빵집에서 다른 프로그램으로 갈아타려고 대안을 찾아봤는데..
회사에서만은 도로 빵집으로 돌아오고 말았다.

이유는 단 하나.
다른 모든 압축 프로그램들은 tar.gz 파일을 열면 내부의 tar 파일 하나만 달랑 보여주는 반면,
빵집은 사용자에게서 확인 질문을 받은 후 친절하게도 tar 내부까지 자동으로 보여주기 때문이다. 이거 정말, 너무 편하다.

리눅스 환경에서 그냥 tar로 압축하여 백업한 파일을 다루는 경우가 많은데 그걸 윈도우 환경에서 손쉽게 관리하기 위해서는 다른 기능보다도 저게 무엇보다도 마음에 들고 꼭 필요한 기능인 것이다.

흠, 이런 건 혼자만 알고 있지 말고 개발자에게 건의를 해 봐야겠다. 본인은 특정 분야의 공개 소프트웨어 개발자이다 보니 다른 사람들로부터 버그 신고와 건의를 많이 듣는 편이지만, 본인도 역시 아주 가끔은 다른 소프트웨어에 대한 버그 신고와 건의도 직접 한다.

※ 덧.

윈도우 비스타나 7에서 Aero를 사용하고 있을 때 창을 최소화하면, 대부분의 표준 윈도우들은 작업 표시줄 쪽으로 멋있게 사그라든다.
하지만 경험상 델파이로 개발한 프로그램들은 아래로 멋있게 사그라들지 않고, 그냥 창을 닫을 때와 동일하게 그냥 fade-out으로 사라진다. AcroEdit라든가 WinM, 빵집 모두 마찬가지임. 뭔가 특별한 방식으로 윈도우를 다루는 것 같다.

그 반면 완전 자체 스킨을 사용하는 아래아한글이나 알집-_- 같은 프로그램은 그런 효과가 전혀 적용되지 않고 그냥 없어진다.
또한 비스타 이상에서 정상적인 실행이 보장되지 않는 비주얼 C++ 2003 같은 프로그램은, 최소화될 때 빈 창틀만 사그라들면서 다른 어느 프로그램과도 다른 이상한 애니메이션을 보인다.

Posted by 사무엘

Posted by 사무엘

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

윈도우즈에서 메모장은 그야말로 운영체제의 역사와 함께 해 온 기본 프로그램이다.
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 사무엘

황금도끼 도스용 버전을 처음 해 본 게 초등학교 고학년이던 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 사무엘

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

※ 비디오 (그래픽)

예전에 글로 쓴 적이 있지만 제가 가장 먼저 인지한 큰 변화는, 이제 동영상 화면까지 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 사무엘

아래아한글 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 사무엘

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

한메 타자 교사(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 사무엘