« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 11 : Next »

이건 개인적으로 오래 전부터 알고 있었던 사소한 옛날 추억 아이템인데, 지금까지 한 번도 공개적으로 언급한 적이 없었던 관계로 털어놓고자 한다.

Windows에 메모장은 1.0 시절부터 있었던 터줏대감 기본 프로그램이다. 기본 윈도우 프레임 껍데기에다 운영체제의 내장 에디트 컨트롤 하나만 달랑 얹은 극도의 최소주의 형태이다. 세월이 흐르면서 워드패드와 그림판은 리본 UI가 탑재됐고 계산기도 아주 화려한 UI로 리모델링된 마당에, 메모장만은 외형이 거의 바뀐 게 없다.

Windows 프로그래밍 공부를 한 사람이라면 메모장 정도는 하루 정도만 투자하면 동일 프로그램을 직접 만들 수도 있을 것이다. 아니, 있는 그대로 복제품만 만드는 건 너무 시시하고, MDI 정도는 지원하게 확장해서 만들기도 한다. 지금도 있는가 모르겠는데 비주얼 C++의 MFC 예제에는 MultiPad라고 실제로 메모장의 MDI 버전도 소스 코드와 함께 제공된 바 있다.

그런데 Windows 95부터 ME까지 9x 계열의 메모장은 '도움말'이라는 메뉴 명칭의 뒷부분에 출처를 알 수 없는 공백이 하나 더 들어가 있었다. 아래 스크린샷을 참고할 것. 계산기의 '도움말'과는 달리, 메모장의 '도움말'은 파란색이 조금 더 긴 게 보일 것이다.

사용자 삽입 이미지

더욱 신기한 건, 98과 ME로 버전이 올라가도 상황이 바뀐 게 없었다는 점이다. 그것도 한글판과 영문판 공히.
메모장이 아무리 최소주의 기본 프로그램이었다고 해서 그 시절 동안 변화가 전혀 없었느냐 하면 그렇지는 않았다. 보다시피 아이콘 모양이 바뀌었으며 본문의 글꼴을 변경하는 기능이 98에서 추가되었다. 코드뿐만 아니라 리소스 쪽도 검수할 기회가 있었는데 저 문자열의 뒤의 공백은 여전히 제거되지 않은 채 남았다.

사용자 삽입 이미지사용자 삽입 이미지

그 반면, Windows 2000의 메모장은 그렇지 않다.

사용자 삽입 이미지

ME는 2000보다 나중에 나왔음을 감안한다면, 같은 메모장도 NT 계열의 것과 9x 계열의 것은 코드와 리소스가 정말로 한데 공유된 구석이 없었다는 걸 알 수 있다. 같은 소스에서 조건부 컴파일을 한 것조차도 아닌 듯하다.

심지어는 도움말도 둘 다 완전히 다르게 따로 만들어졌다. Windows ME의 메모장 도움말은

Using Notepad to edit text files
You can use Notepad to create or edit text files that do not require formatting and are smaller than 64K (kilobytes).


이라고 사용자에게 당장 필요한 task 지향적인(use, using) 설명 위주인 반면.. Windows 2000의 메모장 도움말은

Notepad overview
Notepad is a basic text editor that you can use to create simple documents.


이라고 프로그램의 정체성에 대해서 더 사무적이고 격식을 차린 문체로 시작한다.

메모장은 아주 단순한 프로그램이지만 9x 계열의 것과 NT 계열의 것이 기능상의 차이도 꽤 크다. 후자는 (1) 유니코드를 지원하며 (2) 64KB 이상 크기의 파일도 열 수 있다. 다시 말해 전자는 "파일이 너무 큽니다. 워드패드에서 여시겠습니까?" 이런 로직이 존재하며, 지금으로서는 상상하기 어렵지만 UTF8 방식 텍스트를 읽고 쓰는 것조차도 지원하지 않았다.

물론 운영체제의 에디트 컨트롤이라는 건 리치 에디트와는 달리 아주 방대한 텍스트를 편집하는 데는 최적화되지 않았던지라 단일 버퍼 기반이라는 한계는 NT 계열도 그대로 갖고 있었다.

또한 NT 계열의 메모장은 BOM이 없는 유니코드 텍스트 파일에 대해서 IsTextUnicode라는 휴리스틱 API를 호출해서 텍스트 파일의 인코딩을 판단했었다. 그런데 그게 좀 버그가 있어서 정상적인 영어 단어로만 이뤄진 짤막한 파일을 UTF16 방식으로 저장된 중국어 한자로 오판하곤 했다. 0x41, 0x42.. 이런 묶음이 코드값상으로는 한중일 통합 한자 내지 확장 A이다 보니.. -_-;;
이 버그는 보안 쪽 문제는 아니지만 그래도 사람을 성가시게 하는 문제인 관계로, 2000이던가 XP 즈음에 패치가 나와서 고쳐졌다.

Windows 9x에는 IsTextUnicode라는 함수 자체가 존재하지 않으니 9x 계열의 메모장이야 저런 문제가 존재할 여지조차 전혀 없었다.
끝으로, 메모장은 아마 Windows XP에서 '상태 표시줄'을 표시하는 옵션이 추가된 게 현재까지 외형상의 마지막 변화 사항이지 싶다. '자동 줄바꿈'을 사용하지 않을 때에 한해서 줄/칸 위치를 표시하는 깨알같은 기능이 추가된 것이다.

이런 Windows와 메모장의 유구한 역사 속에서 도스용 Windows 3.x 내지 NT 3~4의 메모장에는 '불필요한 공백'이 존재했었나 모르겠다.

Posted by 사무엘

2016/04/18 08:33 2016/04/18 08:33
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1216

도스와 유닉스 명령창 공히 디렉터리를 이동할 때는 cd 내지 chdir이라는 명령을 사용한다. 단, 도스는 드라이브 이름을 A~Z 알파벳 한 글자로 표현한다는 게 마치 날개셋의 수식 변수만큼이나 특이하며, Windows는 이 관행을 그대로 물려받았다. 파일명에 대소문자를 구분해서 표현은 하지만 유닉스와는 달리 이를 서로 다른 것으로 취급하지는 않는다. 또한 디렉터리 구분자가 /가 아니라 \(역슬래시)라는 것도 유닉스 계열과 다르다.

그 뿐만이 아니다. 도스는 cd라고만 치면 현재 디렉터리를 표시만 해 주는 반면, 유닉스는 cd라고 치면 그냥 자신의 홈 디렉터리, Windows로 치면 "C:\Users\계정명" 정도로 이동해 버린다. 도스가 유닉스의 다른 개념들은 다 따 왔어도, 이건 다중 사용자라는 개념이 없던 물건이다 보니 홈 디렉터리 같은 건 도입하지 않기 때문이다. 유닉스에서 지금 디렉터리를 표시하는 명령은 잘 알다시피 pwd라고 따로 있다.

그렇게 도스와 유닉스 계열이 차이가 나는 와중에도 . 가 현재 디렉터리를 의미하고 ..는 부모 디렉터리를 의미한다는 건 둘이 동일하다. cd ..를 하면 부모 디렉터리로 갈 수 있다. 다만, 문법이 둘이 완전히 동일한 건 아닌지라.. 도스는 cd..라고 둘을 띄지 않아도 됐던 반면, 유닉스는 둘을 띄워야 한다는 깨알같은 차이점이 또 있다.

그런데 Windows 9x의 도스창에서는 숨겨진 기능이 더 있었다. cd 다음에 점을 세 개 이상 늘어놓음으로써 두 단계 이상의 조부모 디렉터리로 이동이 가능했다. cd...처럼. 그럼 저건 cd ..\.. 를 의미한다. 네 개 이상 숫자를 얼마든지 늘어놓아도 된다.
게다가 이건 파일 시스템 차원에서 공식적으로 인식하기라도 하는지, 굳이 cd에서만 쓸 수 있는 게 아니다. dir ... 이라고 하면 두 단계 상위 디렉터리를 조회할 수 있고, Windows의 파일 열기/저장 대화상자에서도 "..."이라고 치면 동일 기능이 동작했다.

Windows 9x는 C:\Windows 디렉터리를 가 보면 readme 등 몇몇 '읽어 보세요' 문서가 html이나 doc나 rtf가 아니라 txt 파일로 들어 있었는데, 그 중엔 tips.txt가 있다. 그 파일에 cd...에 관한 언급이 존재한다.

MS-DOS COMMAND PROMPT
=====================

Directory Shortcuts
-------------------
Related directories have the following shortcuts:

. = current directory
.. = parent directory
... = parent directory once removed
.... = parent directory twice removed

For example, if you are in the C:\Windows\System\Viewers
directory, and you enter cd... at the command prompt, the
directory changes to C:\Windows.


위는 영문판 Windows ME, 아래는 한글판 Windows 95의 tips.txt 내용 일부이다.

* 디렉토리 단축키
다음과 같은 디렉토리 관련 단축키를 사용할 수 있다.
. = 현재 디렉토리
.. = 상위 디렉토리
... = 하나의 디렉토리가 삭제된 상위 디렉토리(Windows 95에 새로 추가)
.... = 두 개의 디렉토리가 삭제된 상위 디렉토리(Windows 95에 새로 추가)
예를 들어, C:\Windows\System\Viewers 디렉토리에서 명령 프롬프트에 cd....를
입력하면 디렉토리는 C:\로 바뀐다.


이 기능은 이전의 도스 시절엔 존재한 적이 없었으며 Windows 95에서 처음으로 추가되었다는 것이 명시되어 있다. 또한 95의 문서에서는 ....로 디렉터리를 세 단계 건너뛰는 예를 제시하는 반면, 후대 98/ME의 문서는 ...로 두 단계만 건너뛰는 예를 제시한다. C:\로 바뀌는 건 cd\와 동일하기 때문에 예제를 바꾼 게 아닌가 싶다.
참고로 Windows의 한글판은 98부터 '디렉토리'라는 표기가 '디렉터리'로 바뀌고, 문서들의 문체가 반말에서 존댓말로 바뀌었다.

놀라운 사실은, 이 기능은 오늘날의 Windows NT 계열에서는 지원되거나 존재한 적이 전혀 없었고 오로지 95, 98, ME만의 관행이었다는 점이다.

사용자 삽입 이미지

The old new thing 블로그의 설명에 따르면 cd ...는 노벨 네트웨어(Novell NetWare)라는 네트워크 솔루션에서 제공하는 명령 문법과의 호환성 때문에 편의 차원에서 도입된 기능이라고 한다. 그땐 노벨 사의 IPX/SPX 프로토콜 기반으로 네트워크 구성요소들도 있었으니 수긍이 간다.

그리고 9x와 달리 NT에서 ...를 지원하지 않은 이유는, 윈NT가 사용하는 NTFS 파일 시스템에서는 '.'나 '..'와는 달리 '...'는 그 자체가 올바른 파일이나 디렉터리 이름이 될 수 있기 때문이다. 그렇기 때문에 NT 계열에서는 이런 기능을 앞으로 지원할 의향은 더욱 없다고 봐야 할 것이다. 그냥 cd..\..를 해야지, 약칭인 cd...는 IPX 프로토콜이 존재하던 Windows 9x 시절의 추억으로 old timer들에게 남을 것으로 보인다.

9x 시절에는 dir con\con이던가, '실행' 대화상자에서 con\con 이런 걸 치면 운영체제를 뻗게 하고 도스창을 강제 종료시키는 게 가능했다. 이건 꽤 유명한 버그였으며 ME에서야 보정을 통해 패치가 됐다. cd ...는 그것만큼이나 9x 시절에 파일 시스템과 관련해 흥미로운 고유 아이템 추억거리인 것 같다.

여담으로, 명령 프롬프트에서 공백은 여러 명령 인자 토큰들을 구분하는 역할을 한다. 그렇기 때문에 거기서 공백이 들어간 파일을 표시하기 위해서는 파일명 전체를 ""로 싸야 하며, 각종 프로그래밍 언어에는 따옴표 문맥을 인식하면서 공백 기준으로 명령 인자들을 파싱· 토큰화하는 라이브러리도 존재한다. 그러나 이 cd 명령만은 예외로 공백이 들어간 디렉터리도 CD Program Files 라고만 쳐도 인식되게 되어 있다. cd /?를 해 보면 이 사실을 확인할 수 있음.

그리고 cd에는 드라이브까지 같이 변경하는 명령이 한동안 존재하지 않았다. 도스 커맨드 셸의 대체제이던 4DOS 내지 NDOS에서는 자체적인 명령 확장을 통해서 그런 기능을 제공하곤 했는데, 오늘날 Windows에서는 /D 라는 별도의 옵션을 줘야만 드라이브도 변경 가능하다. 아마 드라이브를 변경하지 않는 게 보장된다는 무슨 호환성 때문에 옵션 형태로 기능을 추가한 것 같다. 참고로 /D는 9x의 도스창에는 존재하지 않으며, Windows NT 계열의 명령 프롬프트에만 있다. ...를 지원하지 않는 대신 /D가 있는 셈이다.

Posted by 사무엘

2016/04/16 08:30 2016/04/16 08:30
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1215

* 꽤 오래 전인 블로그 개설 초창기에 썼던 글을 리메이크 한 것이다.

※ 1.0부터 9x/ME까지
가난하지만 파이가 가장 큰 16비트 도스 진영을 특별히 공략한 전용 제품이다. 그러니 x86 전용. 가난한 컴에서 리소스를 최대한 짜내야 했던 관계로 코드는 쑤제 어셈블리어가 가득했으며, 어차피 이식성도 없었다.

※ NT 3~4
9x 같은 현실 절충이 아니라, 이상과 이식성을 추구한 컨셉을 살려 x86뿐만 아니라 Alpha, MIPS를 지원했다. 특히 NT 4의 경우 PowerPC까지 지원하여 지원하는 아키텍처가 가장 많았다. 실행 파일 포맷의 이름을 괜히 Portable Executable이라고 지은 게 아니었다.
Alpha의 경우 64비트 아키텍처이긴 했지만, Windows 자체는 여전히 32비트로만 동작했다. 물론 그때는 메모리 용량상으로 64비트는 어차피 전혀 의미가 없었으며, 단지 같은 클럭으로 32비트보다 대용량 데이터를 더 빠르게 처리한다는 점에서만 의의를 둘 수 있었을 것이다.

참고로 OS/2는 Windows NT에 준하는 귀족 된장(?) OS임에도 불구하고 이식성이 없이 x86 전용이었다. 이식성 있는 코드 위주로 개발되지 않았기 때문이다.

※ 2000
NT 계열이지만, 이제 한물 가고 망했다고 간주되는 아키텍처들에 대한 지원을 대거 끊어서 사실상 x86 전용이 됐다. 인텔에서 발표 예정인 IA64 Itanium 아키텍처와 연계하여 최초의 레알 64비트 OS로 거듭나려 했지만 CPU의 출시가 늦어지는 바람에 제대로 성사되지 않았다.

※ XP
이제야 x86 (32비트)과 Itanium (64비트) 에디션이 동시에 발매되었다. 하지만 Itanium는 알고 보니 정말 대차게 망한 관계로, 얘를 정식으로 지원하는 Windows는 XP가 처음이자 마지막이 됐다. -_-;;
그 대신 x86과 잘 호환되는 x64 내지 x86-64라는 새로운 아키텍처가 64비트 PC의 대세가 되었다. PC도 이제 메모리가 슬슬 4GB 방벽에 걸릴 타이밍이 되기도 했고.

그래서 2005년, 이미 SP2까지 출시되고 나서야 Windows XP는 x64용 에디션이 나왔다. 허나 정말 존재감 없이 지나가 버렸으며, XP는 대외적으로 여전히 싱글 코어 + 32비트 OS의 상징이라는 이미지가 압도적으로 더 강하다.

※ Vista와 7
Itanium은 칼같이 짤렸고 그 대신 x86 (32비트)과 x64 (64비트) 패턴이 나란히 정착했다. 7부터는 서버 에디션은 이제 32비트가 없이 64비트 에디션만 나오고 있다.

※ 8과 그 이후
저기에다가 모바일용 CPU인 ARM 에디션이 새롭게 추가됐다만, 이 에디션은 키보드 달린 일반 컴퓨터에서 볼 일은 딱히 없을 것 같다. 이 구도가 당분간 계속 이어질 듯.

이렇듯, Windows는 운영체제의 버전이 바뀌면서 지원 플랫폼도 은근히 자주 바뀌어 왔다. 이 외에도 운영체제 별 문자 입력 시스템의 변천사라든가 다국어 글꼴 시스템의 변천사를 다뤄도 무척 재미있을 것 같다.

다국어 하니까 짚고 넘어갈 사항으로는..
Windows NT는 3.51부터 한글화되어 나왔다. 그러나 한글판이 나온 건 1996년, 이미 95도 나오고 NT 4.0이 나오기 몇 달 전이었던지라 3.51의 한글판은 별로 주목받지 못했다. 그러니 NT 3.51이 윈도 3.x의 셸 기반이었다고 해서 NT 3.51의 한글판이 한글 윈도 3.x의 투박한 비트맵 바탕체를 썼다거나 하지는 않았다.

Windows 자체가 한글판이 나온 건 무려 2.1때부터라고 한다. 하지만 1980년대 말에 우리나라 IT 인프라에서 뭘 그리 바랄 게 있겠는가..? 이 역시 3.0이 나오기 얼마 전일 정도로 시기가 매우 늦기도 해서 존재감은 거의 부각되지 않고 싹 묻혔다. 저 광고 말고는 스크린샷이고 기록이고 뭐고 아무것도 없다.

사용자 삽입 이미지

Posted by 사무엘

2016/03/23 08:24 2016/03/23 08:24
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1206

문자· 문서를 처리하는 기계의 역사를 살펴보면 기계식 타자기가 발명된 뒤 나중에는 전자식 타자기가 만들어지고, 그게 더 나중에는 컴퓨터가 달린 휴대용 워드 프로세서 기기 형태로 발전했다.

그 뒤 특정 장치에 구애받지 않고 범용 컴퓨터에서 동작하는 워드 프로세서 소프트웨어도 개발되긴 했지만 이 역시 특정 컴퓨터 내지 프린터 번들의 성격이 강했다. 아무래도 워드 문서의 최종 목적지는 인쇄였던지라 프린터의 입김에서 자유로울 수 없었으니 말이다. 게다가 윤곽선 글꼴이 없었으니 글꼴부터가 애초부터 프린터의 해상도에 따라 도트판/레이저판으로 나뉠 수밖에 없었다.

이런 척박한 여건에서 옛날 도스 시절에 '한글'을 처리할 수 있는 워드 프로세서가 몇몇 컴퓨터 선구자들에 의해 개발되었다. 그래픽 모드에서 실행되었던 도스용 한글 워드 프로세서로 제대로 살아남은 건 아래아한글밖에 없다.
관공서에서 많이 쓰였던 '하나' 내지, 삼보 컴퓨터 번들로 제공되었던 '보석글'(엄밀히 말하면 순수 국산 프로그램은 아님)은 그래픽 기반이 아니었기 때문에 편집 중에 각종 속성들은 태그 부호로 표시되었다는 한계가 존재한다..

0. 하나

사용자 삽입 이미지
1995년까지 금성이 아닌 LG 소프트웨어라는 브랜드로도 생각보다 오랫동안 개발됐다. 95년이면 아래아한글은 이미 Windows용까지 나왔을 정도였으니 시대에 너무 뒤쳐지긴 했다. 물론 금성/LG 소프트웨어에서도 그 시기에 다른 팀을 꾸려서 Windows용 '윈워드'라는 제품을 개발했으며 이걸 2.0까지도 만들긴 했지만... 더 오래는 못 갔다.

‘하나’도 아래아한글처럼 문서 확장자가 hwp였다. 하지만 둘은 동일한 포맷은 물론 아니었다. 아래아한글이 하나 문서를 읽거나 쓰는 건 ‘공용(공통) 파일’이라는 이름으로 최소한 아래아한글 2.5나 3.0 등 도스용 에디션의 막바지 시절에야 추가됐다. 자기 hwp와 구분을 위해 확장자는 일부러 kwp라고 했다.

하나와 아래아한글 모두 관공서에서 사랑받은 프로그램답지 않게 한때 보안이 좀 허술했다. 하나의 경우 암호를 걸어서 저장해도 암호가 문서 파일의 헤더에 평문으로 버젓이 저장되었는지 군대에서 이렇게 암호를 뚝딱 풀어서 중대의 영웅으로 추앙받았다는 분의 무용담이 전해진다.

한편, 1994년경엔 아래아한글 2.1 (2.1과 2.5 공용) 파일 포맷의 암호도 어느 서울대 출신의 천재 해커에 의해 뚫려서 화제가 됐는데..
이건 이적행위 증거를 찾으려고 지금의 국정원, 당시의 안기부에서 작정을 하고 해커를 고용해서 뚫은 것이었다고 한다. 개발사인 한컴이 이적행위를 했다는 건 물론 아니고, 사용자 중에 불온문서를 만든 사람이 있었다는 뜻.
단순한 오덕질이나 사적 이익 때문이 아니었다는 점이, 그리고 또한 단순히 한 특정 문서의 암호만 brute force 방식으로 대입해서 알아낸 게 아니라 전반적인 암호화 알고리즘 자체를 파악하고 예측하는 데 성공해 버렸다는 점이 무척 놀랍다.

그 당시 한컴은 2의 32승 운운하면서 “암호를 걸었던 사람이 암호를 잊어버리면 우리조차도 암호를 풀 수 없다. 암호를 뚫으려면 130년은 족히 걸릴 것”이라고 언론 보도까지 내면서 아주 자신만만한 모습이었다. 그런데 그것이 실제로 일어나자 망연자실할 수밖에 없었다. 다음 3.0 버전에서는 즉시 암호화 알고리즘을 변경해야 했다.

그럼 다음부터는 자체한글 '그래픽' 모드에서 실행된 프로그램 얘기를 하겠다.
본인은 오래 전에 윤곽선 글꼴로 한글을 찍는 기능이 어떤 형태로든 있었던 도스용 프로그램을 주목하여 몇 가지 예를 든 적이 있다.
아래아한글 2.x를 제외하면 그래픽 에디터 내지 배너 프로그램이 걸려들곤 했는데, 그것들 말고 아래아한글과 비슷한 급의 상업용 워드 프로세서로는 다음 두 프로그램이 있다. 단, 본인은 어렸을 때 이들 프로그램을 직접 써 보지는 못했다.

1. 사임당

난 10여 년 전에 우리나라에서 5만원권 지폐를 신권 형태로 첫 발행했을 때 이 프로그램이 떠올랐다. 지폐에 들어간 모델 때문이긴 하지만, 그래도 써 본 적도 없는 프로그램을 어떻게 그렇게 분명하게 기억하고 있었는지는 모르겠다.

사용자 삽입 이미지

사임당은 윤곽선 글꼴, 위지윅, 컬러 지원, 그래픽 처리 등의 기술적인 면에서는 아래아한글 2.x 초반대 버전보다 더 뛰어나면 뛰어나지 절대로 못하지는 않았던 매우 우수한 프로그램이었다. 그런 기능들은 따지고 보면 오히려 아래아한글이 도입 타이밍이 더 늦거나 전문용에만 오랫동안 봉인돼 있었다. GUI만 봐도 뭔가 비범한 구석이 느껴지지 않는지?

사용자 삽입 이미지

저기 '무른연모'라는 글자를 보아하니 휴먼샘체/팸체(안상수체는 아님) 같은 한글 가변폭 글꼴도 잘 지원하고 있었다.
사임당은 분명 시대를 앞서갔던 프로그램이었지만, 위키백과의 설명에 따르면 비싼 가격과 강경한 복제 방지 정책 때문에 그리 많이 보급은 못 됐으며 아래아한글을 실질적으로 위협하지 못하고 사라졌다고 한다.

사임당의 개발사인 한컴퓨터 연구소/주식회사도 오늘날의 한글과컴퓨터 못지않은 워드 프로세서 개발 전문 기업이었다. 예전부터 사임당의 전신인 '한글 2000'이라는 프로그램을 만들었고, 사임당 말고도 저가 보급형 프로그램인 '쪽박사, 글박사' 같은 프로그램을 따로 개발했다. 글박사의 경우 본인도 초딩 시절에 컴퓨터 잡지에 소개된 걸 본 기억이 있다. 무려 1992년에! 하지만 이 역시 실물을 직접 써 보지는 못했다.

사임당, 글박사 등의 스크린샷을 보면 저기서 만든 워드 프로세서들은 전통적으로 세로획도 1픽셀인 고딕 계열 글꼴을 UI 표시용 한글 글꼴로 써 왔다. 세로획이 2픽셀인 명조 계열 글꼴을 사용한 아래아한글과는 대조적이다.

2. 21세기 워드

아래아한글과 사임당으로도 모자라서 도스에서 한글 윤곽선 글꼴을 지원했던 그래픽 워드 프로세서가 더 있었다. 그것은 바로.. 지금은 알집과 카발(온라인 게임)로 유명한 그 회사가 먼 옛날 초창기에 만들었던 제품이다.

사용자 삽입 이미지

본인은 실물을 써 보지는 못했지만 컴퓨터 잡지에서 광고를 한 건 봤다. 글꼴을 가지고 대놓고 아래아한글을 디스하고 있었다.
모 제품은 가격이 8만 8천원이나 하는데도 글꼴이 꼴랑 다 깨지는 비트맵 명조로밖에 안 나오는 반면,
우리 21세기 워드는 그거 거의 반값으로도 아주 미려한 윤곽선 글꼴 신명조가 나온다고...;;

디스 당한 모 제품은 뭔지 직접적으로 언급은 안 돼 있지만, 누가 봐도 아래아한글 2.0이던가 2.1의 일반용인 건 뻔한 노릇이었다.
이를 의식해서인지 아래아한글도 2.5 버전에 와서야 일반용/전문용 구분을 없애고 16비트 컴퓨터에서도 컬러와 윤곽선 글꼴을 실현시켰지만.. 때가 좀 늦은 조치였다.

21세기 워드는 글자 크기 조절과 윤곽선 글꼴을 빼면 나머지 워드로서의 기능은 아래아한글 1.5x와 크게 차이가 나지 않았다고 한다. 화면을 딱 봐도 색상이나 글꼴은 아래아한글 1.5x를 대놓고 오마주한 것 같지 않은가? ㅎㅎ
단, 한글의 비트맵 글꼴 명조체는 아래아한글 1.5x가 사용하던 그 명조와는 다르다. 아래아한글은 custom 3차원 조합 테이블을 사용한 약간 더 정교한 글꼴인 반면, 21세기는 그냥 그 당시에 널리 통용되던 초중종 8*4*4벌 도깨비 조합 규칙으로 구현된 명조이다.

어떻게 아냐고? 다 방법이 있다.
도깨비 조합형은 세로줄형 모음에서 받침 ㄴ일 때와 이외의 다른 모음일 때의 구분이 없다. 그래서 '편'(집)일 때와 (입)'력'일 때 ㅕ가 길이가 똑같아서 받침 ㄴ일 때 아래 공간이 약간 허해 보인다.
그 반면, 지금 <날개셋> 편집기의 '바탕'으로 채용돼 있는 아래아한글의 명조는 받침 ㄴ일 때 세로 모음들이 딱 1픽셀 더 길어서 아주 조금 더 균형이 잡혀 보인다. 이런 작은 차이가 존재한다.

사소한 글꼴 디테일 얘기는 그렇고.
그 당시 이스트소프트는 파릇파릇한 공대생 몇 명이 갓 창업한 벤처/스타트업 수준에 불과했기 때문에 기술과 영업 역량에 한계가 있었다. 물론 그 여건에서 천재 프로그래머 몇 명이 이 정도를 뚝딱 만든 건 정말 대단한 일인 건 맞지만, 그런 몇 가지 차별화 요소만 갖고 아래아한글이라는 기득권 아성을 무너뜨릴 수는 없는 노릇이었다.

21세기 워드는 사임당 정도의 엘리트주의로 간 것 같지는 않지만, 어쨌든 그렇게 망하고 역사 속으로 사라졌다. 이걸 계기로 이스트의 창립자분은 뭔가 깨달은 게 있었는지, "그냥 기술적으로 뛰어나기만 한 제품"이 아니라 "사용자에게 잘 어필되고 실질적으로 팔리는 제품"을 만들어야겠다는 실용주의 노선으로 생각을 급선회하게 됐다고 한다. 하긴, 에디슨도 처음엔 자기 오덕질대로만 외곬스러운 발명을 하다가 나중에야 그렇게 깨닫는 계기가 있었다고 들었다.

21세기 워드를 만들었던 회사는 그로부터 6, 7년쯤 뒤 21세기가 실제로 임박하자, 이번엔 '새 폴더'를 비롯해 아주 익살스러운 외형의 압축 프로그램을 무료로 뿌리면서 컴백했다. 본인은 2000년 말, 알집을 4.8대 버전 때 처음으로 접했다. 그런 식으로 잘나갈 수도 있었고 "개인에게만 무료, 기업은 유료" 정책도 나쁘지 않은 것 같았는데.. 프로그램이 압축 본연의 기능이 탄탄하지 않다는 나쁜 소문이 2000년대 초중반에 워낙 퍼지면서 안 쓰게 됐고.. 지금은 빵집을 거쳐서 반디집이 국민 압축 프로그램 타이틀을 물려받았다. 빵집은 퀄리티가 나쁘지는 않았으나 보다시피 개발이 중단됐으니 말이다.

워드 얘기를 하다가 갑자기 딴 얘기가 길어졌네.
아무튼, 저 두 프로그램들은 아래아한글에 밀려 역사 속으로 사라졌다. 그로부터 20여 년 뒤, 도스가 아닌 Windows 얘기이긴 하지만 지난 2014년 가을엔 삼성조차 1992년 이래로 개발돼 왔던 훈민정음을 완전히 포기하고 MS 워드로 복귀를 선언했다. 훈민정음은 처음부터 Windows용으로 개발됐고, 버전 4.5 시절엔 마치 Visual Basic 4처럼 16비트용과 32비트용이 동시에 따로 출시된 탄탄한 제품이기도 했는데 말이다.

훈민정음이 GG를 쳤는데 그럼 아래아한글은? 지금까지 쌓인 인프라가 워낙 많고, 또 아래아한글과 워드는 내부 구조가 서로 너무 다르다 보니 사용자가 하루아침에 전멸하고 쫄딱 망할 것 같지는 않다. 그러나 '갈라파고스화' 알박기 덕분에 겨우 연명하고 있는 비중도 크며, 학교· 군대· 관공서가 아닌 사기업에서 HWP의 입지는 이미 눈에 띄게 줄어들었다는 것을 감안해야 할 것이다. 그리고 결정적으로, 이젠 워드, 엑셀 같은 너무 흔한 필수 프로그램은 그냥 다 공짜로 뿌리는 거나 다름없는 세상이 되기도 했고.
그러니 이스트도 결국은 돈 되는 건 게임이라고 생각하고 진작부터 과감하게 카발을 개발한 것 같다. 이 컴퓨터 소프트웨어 업계가 앞으로 어찌 되려나 참 눈 돌아가겠다.

Windows의 개발 역사에 대해서는 현직 마소 고참 개발자인 레이먼드 챈 아저씨가 The Old New Thing이라는 개인 블로그에서 10년이 넘게 오늘날까지도 구수한 입담으로 그때 그 시절 이야기를 하고 있다. 그것처럼 개인적으로는 아래아한글 1.0부터 현재까지의 역사를 몽땅 꿰뚫고 있는 어떤 개발자가 아래아한글 내지 그 시절 경쟁 워드 프로세서들의 역사를 구구절절 회상하는 코너가 좀 있으면 좋겠다. 필기체가 개발된 사연, 1.2 버전에서 테트리스 게임이 개발된 사연, 한컴 2바이트 코드의 제정 경위, 옛날 공 병우 박사와의 인연 등등 얘기가 엄청 많을 것 같은데..!

Posted by 사무엘

2015/10/30 08:34 2015/10/30 08:34
, , , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1154

고전 소프트웨어의 추억을 발굴하는 작업은 변함없이 계속된다.
몇 달 전엔 비트맵 그래픽 에디터 얘기를 했다. 구글링으로도 좀체 정보를 발견할 수 없던 Splash와 Image72를 찾아 냈다. 이어서 오늘은 도스용 셸 유틸리티 얘기를 해 보겠다. 출처를 도저히 알 수 없었던 한 외국산 프로그램의 정체를 또 파악하는 데 성공했기 때문이다.
그것은 이름하여 Packard Bell이다.

사용자 삽입 이미지

옛날 도스 시절엔 부팅이 끝나면 화면에 뜨는 건 시꺼먼 화면에 C:\ 프롬프트가 전부였다. 이런 인터페이스로는 초보자건 전문가건 컴퓨터를 제대로 활용하기가 몹시 불편했기 때문에, 컴퓨터에 존재하는 다른 프로그램들을 빠르고 편하게 실행시켜 주는 '셸'에 해당하는 프로그램이 별도로 여럿 만들어지곤 했다.

전문가를 위해서는 MDIR이나 노턴 커맨더처럼 파일 관리 유틸리티를 겸하는 셸이 쓰였다. 이런 프로그램들은 파일 정보만 표시하면 되니 보통 텍스트 모드에서 실행되었다.
그러나 초보자를 위해, 당시의 Windows 3.0에 준하는 GUI를 표방하면서 알록달록한 아이콘이 나오는 그래픽 셸도 있었다. 골치 아픈 단축키를 외울 필요 없이 마우스 클릭만 하면 원하는 프로그램을 실행할 수 있었다.

MS-DOS 버전 4인가 5부터 제공되었던 '도스셸'은 그래픽 모드에서 실행되는 것도 가능했지만 그래도 전자와 후자 중에서는 전자의 성격에 더 가까운 물건이었다. 그래도 GUI의 불모지인 도스에서 나름 마우스 드래그 드롭을 구현했고, 프로그램의 색상과 화면 모드를 다양하게 바꿀 수 있는 게 인상적이었다.

자, 그 와중에 저 '패커드 벨'이라는 프로그램은 우리 집 컴퓨터에 처음부터 있었던 프로그램은 아니고, 친구 집 컴퓨터에서 접했다. 그런데 GUI가 굉장히 고퀄이고 화면이 예뻤다. 16색 VGA에서 실행되는데 투박한 표준 팔레트를 쓴 게 아니라 보다시피 자체적으로 팔레트 색상을 재정의했으니 더욱 이색적인 느낌이 났다. 색상도 그렇고 글꼴도 그렇고, 알록달록한 아이콘까지, 뭔가 프로그래머가 대충 발로 그린 게 아니라 그래픽 전문가의 손길이 닿은 티가 났다. 어린 시절에 본인은 저렇게 "나만의 세계가 느껴지는 비주얼"을 보면 아주 사족을 못 썼다.

저 스크린샷에서는 안 보이지만, 원래는 마우스 드라이버가 있건 없건 마우스 포인터도 나타난다. 그런데 포인터도 운영체제가 그냥 기본으로 주는 작고 투박한 화살표가 아니라, 무려 살색의 사람 손가락 모양이다. 요즘으로 치면 웹 브라우저에서 링크를 가리킬 때 나타나는 그 마우스 포인터와 비슷하다.
화살표 키를 누르면 지금의 마우스 포인터 위치에서 그 화살표 방향으로 가장 가까이 있는 버튼으로 포인터가 이동하는데, 이것도 즉시 되는 게 아니라 부드럽게 궤적을 그리면서 이동한다. 이런 것까지 세심하게 신경을 썼다.

워드 프로세서나 그래픽 에디터가 아니고, 그렇다고 게임도 아니고.. 자체 한글 같은 것도 필요하지 않는 외국산 도스용 유틸리티가 그래픽 모드에서 가변폭 영문 글꼴 출력까지 구현한 것은 그 당시로서는 몹시 드문 일이었다.
도대체 이 프로그램은 누가 언제 어디서 만들었는지 알고 싶어서 뒤늦게 인터넷을 수소문했지만, 정보를 도저히 얻을 수 없었다.

본인은 이 프로그램의 이름이 Pen Bel(l) Desktop인 것으로 기억하고 있었다. 왕년에 베이직 프로그래머였으니 PB라고 하면 파워베이직의 이니셜이 가장 먼저 떠오르지만, 저 추억의 프로그램의 실행 파일에도 PB라는 문자가 포함되어 있긴 했다. 하지만 저 이름으로는 아무것도 검색이 되지 않았다.

이 프로그램에 대한 결정적인 단서를 얻은 곳은 IE is evil!로 유명한 이 사람의 GUI 갤러리 웹사이트였다.
도스는 말할 것도 없고 Windows 3.1 시절까지만 해도 기존의 허접 구닥다리 '프로그램 관리자'를 대체하는 싸제 셸 유틸이 수요가 있었다. 노턴 데스크톱, 그리고 MS의 흑역사 Bob 같은 프로그램들이 있는데.. 어? Packard Bell 내비게이터라는 프로그램이 있었다.

3.5 버전은 완전히 Bob처럼 그래픽 기반으로 바뀌었지만, 1.1은 보아하니 도스용과 완전히 같지는 않아도 색상과 외형이 웬지 도스용 프로그램과 관계가 있는 것 같다는 생각이 들었다.

사용자 삽입 이미지

튜토리얼, Support, your software처럼 큰 메뉴 구성이 꽤 비슷해 보이는 데다 자음 이니셜이 일치하기도 하니 동일 회사의 프로그램일 거라는 감이 강하게 들었다. 그래서 이 키워드로 구글링을 계속했다.. 그러나 일단 '패커드 벨'은 컴퓨터 제조 회사인지라 걸려 나오는 것은 온통 컴퓨터 사진밖에 없었다.

그랬는데 어느 국내 블로그에서 드디어 월척을 낚는 데 성공했다. 내가 찾던 바로 그 프로그램의 스크린샷이 나온 것이다. 프로그램과 개발사 이름이 동일하게 '패커드 벨'인 듯하다.
이 회사는 소프트웨어가 아닌 하드웨어가 주력 상품이고, 프로그램은 자기 컴퓨터에 번들로 설치되는 것 위주로만 개발한 듯하다. 소프트웨어만 전문으로 만든 게 아닌데도 1991년경에 도스와 Windows용 셸을 모두 그것도 상당히 뛰어난 퀄리티로 만든 것이 무척 대단하게 느껴진다.

사용자 삽입 이미지

그래서 이 도스용 '패커드 벨' 셸은 메뉴 구조가 좀 특이했다. ESC를 누르면 도스셸이나 '로터스 웍스' 같은 붙박이 고정 프로그램이 있고, 'Your software'을 골라야만 아까와 같은 프로그램 아이콘 리스트가 나타났다. 패커드 벨 컴퓨터에는 원래 '로터스 웍스'도 번들로 제공되었던 듯하다.

사용자 삽입 이미지사용자 삽입 이미지

새로운 프로그램을 등록하는 화면이다. 아이템에 사용할 '아이콘', 밑에 표시할 텍스트, 그리고 실제로 실행할 프로그램 이렇게 세 가지 정보를 서로 다른 화면에서 지정해 줄 수 있다. 아이콘은 저 35종류의 기성 그림 중 하나만 선택할 수 있고 다른 외부 그림 파일을 사용할 수는 없다는 게 특이하고 한편으로는 아쉬운 점이다. 기성 그림들은 각각 어떤 컨셉으로 만든 건지는 잘 모르겠다.

그리고 저 스크린샷에서는 제대로 나타나지 않았지만, 원래 이 프로그램은 하드디스크에 존재하는 모든 실행 파일들을 아래의 리스트에다가 표시해 준다. 그래서 사용자는 일반적인 파일 열기 대화상자를 다룰 때처럼 매번 디렉터리를 오갈 필요 없이 한 목록에서 실행 파일을 곧장 선택할 수 있었다. 이건 사실 MS 도스 셸에도 있던 기능이다. 2~30여 년 전, 한 하드디스크가 크기가 수십~100수십 MB밖에 하지 않던 시절에나 가능했던 일이다.

지금 다시 저 프로그램을 접할 수 있다면 무척 감회가 새롭고 흥미진진할 것 같다.

도스 셸 하니까 생각나는데, 옛날에 MS-DOS 4.0은 우리가 아는 그 4.0만 있는 게 아니라 '멀티태스킹 에디션'이라고 유럽 쪽에서 주로 쓰인 다른 브랜치가 있었다고 한다. 16비트 Windows가 사용하던 New Executable 포맷도 사실은 이때 처음으로 제정되었다고 하고.

또한, 국내에서 개발된 그래픽 위주 도스 셸로는 먼 옛날(1993년쯤) 이 종하 씨가 개발한 '능금'이라는 프로그램도 있었다. 옛날에는 '파란연필'이라는 텍스트 에디터도 개발했던 분인데 본인은 요것들은 옛날 컴퓨터에서 다 직접 써 봤다.
'능금'은 셰어웨어였으며, 비등록 공개판은 등록할 수 있는 그룹과 프로그램 개수에 제한이 걸려 있었다.

사용자 삽입 이미지

그래픽 셸로서 '능금'이 지닌 가장 독특한 점은.. 한 아이템에 대한 아이콘을 최대 5개까지 연달아 지정해서 초보적인 수준의 '움짤'을 만들 수가 있다는 점이었다. 물론 외부 파일 사용 가능함. 저 스크린샷을 보면 '그래픽'의 경우 물결이 출렁거렸고, '게임'은 테트리스 블록이 내려가는 모습이 반복되곤 했다.
그래도 '능금'의 기본 팔레트 화면과 저 아이콘들은 '패커드 벨'에 비하면 좀 아마추어 같은 느낌이 들긴 한다. ^^

Posted by 사무엘

2015/07/07 08:34 2015/07/07 08:34
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1113

컴퓨터로 뭔가 input을 받아들여서 output을 내는 나만의 프로그램을 개발한다면, 그 결과물이 단순히 화면으로만 잠깐 나타났다가 사라지는 걸 원하지는 않을 것이다. 꼭 프린터로 출력까지는 아니더라도 파일로 저장하여 사용자의 컴퓨터에 (반)영구적으로 남는 정도는 가능해야 할 것이다.

일반적인 텍스트/그림 파일뿐만이 아니라 내 프로그램만이 인식할 수 있는 고유한 파일 포맷을 제정하고, 그 포맷이 널리 쓰이게 되는 것은 분명 해당 파일 포맷을 만든 사람에게는 기분 좋은 일일 것이다. 새로운 이미지 파일 포맷이라든가 압축 파일 포맷처럼 말이다. 본인의 경우는 <날개셋> 한글 입력기의 글쇠배열/입력 설정 파일이 이런 창조물의 범주에 속하게 됐다.

파일 포맷이라는 건 지금 당장 공간 낭비 없이 읽고 쓰기 빠르게 만드는 효율도 중요하지만, 범용성과 확장성도 대단히 중요하다. 지금 만들고 있는 프로그램이 구조와 기능이 앞으로 어떻게 바뀔지 알 수 없기 때문이다. 마치 프로그래밍 언어가 하드웨어 친화와 사용자 친화라는 양 이념 사이의 tradeoff로 떨어지듯, 파일 포맷도 위의 두 이념 사이의 tradeoff를 고려하여 제정된다.

또한 파일 포맷은 거의 필수적으로 앞부분에 헤더가 들어간다. 이 파일이 요런 파일 포맷으로 된 파일이라는 것을 나타내며, 헤더가 일치하지 않으면 파일을 더 읽지 말고 에러를 출력하라는 일종의 배려이다. 헤더의 앞에는 식별자가 있는데, 요것이 또 파일 포맷마다 아주 개성이 넘쳤다. 도스 실행 파일(EXE)은 MZ, ZIP 압축 파일은 PK 등.

도스에서 파일의 내용을 보여주는 type 명령은 end-of-file을 나타내는 아스키 문자인 0x1A를 만나면 뒷부분에 텍스트가 더 있어도 표시를 멈췄기 때문에, 파일 시그니처의 끝에다가도 저 문자를 넣어 주는 게 일종의 센스쟁이 관행이었다. 딱 HWP Document File v3.0 요까지만 출력하고 멈추게 할 수 있으니까 말이다. 0x1A는 10진수로 26인데, 이것이 바로 지금도 copy con 다음에 종결을 위해 입력하는 Ctrl+Z와 대응한다. Z는 알파벳 26째 마지막 문자이니까 말이다.

PNG 그래픽 파일은 이 시그니처를 상당히 머리를 써서 만든 것으로 잘 알려져 있다. 마냥 텍스트 파일로 오인하지 않게 의도적으로 맨 앞은 0x89라고 128보다 큰 문자를 집어넣고, 그 다음 PNG를 찍고 줄 바꿈 문자를 찍은 뒤 0x1A로 종결시킨다.

옛날에 아래아한글이 도스용으로 1~2.x 버전이던 시절엔 이런 미래 확장 가능성을 꼼꼼히 설계를 안 했는지 파일 포맷이 수시로 바뀌어서 하위 호환성이 깨지곤 했다. 뭐, 2.1 때는 최초로 압축 저장 기능이 생겼고 도중에 암호 체계가 뚫리는 해프닝이 있어서 불가피하게 포맷이 바뀌어야 하기도 했지만 말이다.
그나마 3.0 포맷이 도스와 Windows 공용으로 무려 97 버전까지 변경 없이 잘 쓰이다가 그래도 지금은 무려 워디안 이래로 포맷이 바뀌지 않고 꿋꿋이 잘 나가고 있다. 안정화가 됐다.

그런 최소한의 융통성을 갖춘 파일 포맷을 만들려면, 결국 어떤 용도의 포맷을 만들든지간에 버전 정보를 남기고 섹션, 구획(혹은 chunk)을 설정하는 정도의 추상화는 공통으로 필요하다. 내가 아는 chunk의 정보만 읽어들이고 모르는 건 무시할 수 있게, 하위 호환이 되게 말이다. PE라고 불리는 Windows용 실행 파일에서도 이런 구획이 있고(text, rdata, data, rsrc 등), TTF 폰트 파일에도 내부에 구획이 있다(cmap, glyf, head 등). 미디(mid) 음악 파일도 온갖 구획들이 합쳐진 컨테이너 포맷이다.

그렇게 외부에서 구획을 표현하는 방식은 파일 알멩이 포맷 이전에 껍데기 '컨테이너' 포맷이라는 공통 규격으로 바뀌는 게 요즘 추세이다. 매 프로그램마다 GUI 프로그래밍을 제각각 할 필요가 없듯, 껍데기를 일일이 새로 만들 필요는 없으니 말이다. 무손실 압축 파일 포맷도 컨테이너와 압축 알고리즘을 분리해서 생각하는 건 상식 중의 상식이고, 손실 압축 알고리즘의 각축장인 동영상/소리 파일 포맷도 컨테이너와 내부 컨텐츠 포맷은 계층이 분리돼 있다.

컨테이너는 아예 human-readable한 텍스트 방식과, 그것보다는 성능을 더 중요시한 바이너리 방식 둘로 나뉜다.
텍스트는 xml이 대세를 평정하는가 싶었는데 요즘은 json도 급부상하고 있다. json은 프로그래밍 언어에서 배열이나 튜플 같은 복합 자료형을 표기하는 방식을 그대로 가져왔다는 점이 무척 참신하다. 배열스러운 나열과 key-value 형태의 데이터를 모두 표기할 수 있으며, 그 덕분에 바이너리 덤프 같은 것도 xml보다는 덜 부담스럽게 집어넣을 수 있고 공간 효율도 더 좋다.

바이너리 차원에서의 컨테이너 포맷으로 요즘 굉장히 많이 쓰이는 건 zip 압축 포맷이다. 수많은 압축 알고리즘들이 존재하지만 역시 오픈소스 앞에서는 답이 없다. zip이 세상을 평정했다. 가장 친숙하게는 MS Office 2007 이후의 문서 파일 포맷, 그리고 오픈오피스 문서 파일 포맷이 내부적으로는 zip 압축 파일이다. Java의 jar 라이브러리, 그리고 안드로이드 adb 패키지도 zip이다.

다만, 저런 프로그램들은 zip 안에다가 자기 방식으로 고유한 메타데이터도 집어넣곤 한다. 그렇기 때문에 이들 파일의 압축을 풀었다가 다시 압축을 했다고 해서 그것들이 해당 오피스 문서나 패키지로 인식되지는 않는 경우가 많다.

멀티미디어 파일 포맷 중에는 avi/wav가 동일하게 RIFF(리소스 교환 파일 포맷)라는 컨테이너 기반이다.
한편 Windows 세계에서는 의외로 많이 쓰이는 공용 바이너리 컨테이너 포맷이 있는데.. 그것은 바로 OLE Compound Binary이다. 이름에서 알 수 있듯이 바이너리 규격에서 여러 프로그래밍 규격들의 통일을 시도했던 OLE/COM 기술과 역사를 같이하는 포맷인 것 같다. 난 잘 모르겠지만 아마 이 파일을 읽고 쓰는 I*** 하는 인터페이스 API도 있으리라 여겨진다.

이 방식의 파일은 D0 CF 11 E0 A1 B1 1A E1이라는 8바이트짜리 시그니처로 시작한다. 의도적으로 128 이하의 텍스트나 제어 문자는 제외한 듯하다. 그리고 앞부분엔 0xFF 문자가 수십~수백 개 나온다.
MS Office가 2007 버전이 등장하기 전에 재래식 doc/xls/ppt가 이 컨테이너 하에서 자기 데이터를 저장하곤 했다. 그리고 지금도 일반적으로는 xml+zip 기반의 docx/xlsx/pptx이지만 암호를 걸어서 저장하면 여전히 예전처럼 이 compound binary를 사용한다. 이건 그리 널리 알려져 있지 않을 것이다.

엑셀의 경우 대용량의 데이터를 빠르게 저장하기 위해 예외적으로 xml 대신 바이너리 포맷을 쓰는 xlsb도 지원하긴 하는데, 이때에도 컨테이너는 여전히 zip이다.
하지만 암호를 걸면 xls든 xlsb든 동일하게 컨테이너가 저 OLECB 방식으로 회귀한다.

OLECB는 Office 문서에서만 쓰이는 게 아닌 범용적인 컨테이너 포맷이기 때문에 Windows의 내부에서는 thumbs.db에서도 쓰이고 심지어 msi 패키지도 이 방식으로 만들어져 있다.
국내에서는 아래아한글이 워디안 이후 새로운 hwp 포맷이 이 컨테이너를 사용하는 중이다. 몇 년 전에 hwp 파일의 포맷이 부분적으로나마 공개되면서 요 방식도 같이 주목받은 편이었다. 워디안의 개발 당시에 OLECB를 사용하기로 한 것은 21세기에 아래아한글의 향후 행로를 결정한 매우 중대한 결정이었을 것이다.

파일 포맷이란 건 한번 정해지고 그게 대중화돼 버린 뒤에는 마치 전기 전압이나 교통수단의 통행 방향처럼 다른 방식으로 덥석 고치기가 거의 불가능하다. 프로그램의 구조가 아주 간단하고 기능 구현만 빨랑 해야 할 때는 숫자/문자열 몇 개를 덥석 텍스트 형태로 덤프하거나, 구조체가 차지하는 메모리 형태를 파일로 통째로 써 버렸을지 모른다. 하지만 그 파일을 남과 주고받게 되고 프로그램을 지속적으로 발전시켜야 한다면 본격적으로 파일 포맷을 고민해야 하는 날이 온다.

이걸 처음에 신중하게 생각을 안 하면 파일 포맷은 legacy들이 가득한 누더기가 돼 가고, 참다못해 파일 포맷을 다 갈아엎게 되고 그러면서 사용자들로부터 욕도 먹을 것이다. 컴터쟁이 프로그래머로서 파일 포맷은 참 재미있는 주제인 것 같다. 그 어떤 파일 포맷이라도 결국은 튜링 기계가 인식할 수 있는 형식 언어와 문법에 속하는 방식으로 귀착된다는 점 역시 생각할 점이고 말이다.

Posted by 사무엘

2015/06/26 08:35 2015/06/26 08:35
, ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1109

오늘은 1980년대 후반~1990년대 초반에 개발되었던 비트맵 그래픽 에디터인 Image72와 Splash!를 소개하겠다.
이들은 닥터할로(원래 이름은 드로잉 할로라고 하는..) 나 딜럭스 페인트 같은 프로그램에 비해 인지도가 이상할 정도로 듣보잡인 것 같다.
진작부터 추억을 회상하는 글을 올리고 싶었으나, 정보가 넘쳐나는 구글과 잡학 지식의 보고인 위키백과를 검색해 봐도 나오는 정보가 너무 없었다.

이름뿐만이 아니라 제작사까지 같이 넣어 줘야 그나마 외국 사이트 위주로 몇 개가 뜨는데, 그래도 자료가 드물다.
국내에서는 운영자가 뭘 하는 어떤 분인지는 모르겠지만 dreamphp라는 사이트에서 그야말로 엄청난 양의 국내외 고전 소프트웨어 소개와 스크린샷 리스트가 있고 거기에 Image72와 Splash!도 나란히 소개돼 있다. 가히 고전 소프웨어 박물관이라고 해도 될 듯. (단, 소개와 스크린샷만 있지 프로그램의 다운로드는 제공 안 함)

본인은 초· 중딩 시절엔 컴퓨터가 256컬러를 표현하는 것만으로도 희열을 느끼곤 했다.
게다가 그래픽 에디터는 여타 분야의 프로그램과는 뭔가 다른 독특한 UI와 포스가 존재해 왔으니 말이다.
그런 프로그램들을 어른이 된 뒤 다시 접하니 마치 이산가족을 상봉한 듯한 느낌이다.

1. Image72

사용자 삽입 이미지

20여 년 전, 본인이 집에서 486 컴퓨터를 처음으로 접했을 때 그때 컴에 기본으로 깔려 있던 프로그램 중 하나였다.
나중에 알고 보니 얘는 메뉴가 없이 그저 검정 배경에 단순한 UI를 제공한다는 점에서는 닥터할로를 닮았다. 그리기 기능은 Windows의 그림판 같은 그저 그런 수준.

표준(?) 버전은 640*480 16색 VGA에서 실행되었다. 단색 버전과 심지어 Image256이라는 256색 SVGA 버전도 있다고는 하지만 그건 난 실물을 못 봤다.
또한, A4tech라는 제작사에 대해서도 현재는 알려진 게 없다. 다른 제품을 더 만든 게 있는지, 혹시 이 프로그램은 DOS 말고 다른 플랫폼 포팅도 됐는지 같은 것들. 단, 검색을 해 보니 미국이 아닌 타이완 국적의 기업이며 저 링크된 회사와 정체성이 동일한 회사가 맞는 것으로 보인다.

인터넷에서 존재감이 완전히 묻혀져 가는 Image72에 대해서 더 많은 정보를 알고 계신 분의 제보를 기다린다.

2. Splash!

사용자 삽입 이미지

얘는 320*200 저해상도에서 256색을 지원한 프로그램이다. 게임 말고 이런 그래픽 모드를 사용하는 프로그램은 드물었다.
개발사는 Spinnaker software. 지금도 있는 회사이긴 하나, 그때로부터 워낙 긴 시간이 흘렀다 보니 Splash!의 개발사와 동일한 곳인지 정확히는 모르겠다. (맞는 것 같긴 하다만)

우리가 놀랄 만한 점은, 이 프로그램은 1988년 12월에 출시되었다는 점이다.
VGA 그래픽 카드가 출시된 게 1987년이다. 그 정도로 까마득한 옛날에 VGA의 256색을 모두 활용하는 거의 초창기 프로그램이었기 때문에 Splash!는 출시 당시엔 굉장한 화제를 모았다. 당대의 컴퓨터 잡지들도 앞다퉈 소개할 정도였다고 한다. 마치 19세기나 20세기 초반에 만들어진 소수의 컬러 사진을 보는 듯한 느낌이다.

다만, 화면 해상도는 그렇다 쳐도 편집할 수 있는 그림의 크기도 화면의 크기를 넘어갈 수 없었던 걸로 기억한다. 그건 좀 아쉬운 점이다.

Splash!를 보니 다음으로, 팔레트 관련 추억을 좀 늘어놓고 글을 맺도록 하겠다.
컴퓨터의 그래픽 모드에서 256색은 2색/16색 같은 저색상도 아니고 하이/트루 같은 고색상도 아닌 딱 중간을 차지하는 독특한 모드이다. 1픽셀의 정보량이 딱 1바이트여서 프로그래밍이 쉬운 한편으로, 팔레트의 중요성이 가장 커진다. 어떤 색들을 선별해서 256개에다가 배당하느냐에 따라 해당 그래픽의 분위기가 싹 달라지곤 했다. 특히 게임들 말이다.

VGA 그래픽 카드가 모드 13h에서 기본 제공하는 256색 팔레트는 다음과 같았다. 기존 16색 이후로는 흑백 32단계와 고채도 원색 그러데이션이 잠시 나온 뒤, 형광/파스텔톤의 색이 3단계 명암으로 나열된다. 저 색깔띠 자체는 예쁘지만, 배색이 게임 같은 그래픽을 표시하는 데는 그리 적절하지 않은 것 같다.

사용자 삽입 이미지

유명한 VGA 팔레트로는 1990년대를 풍미한 명작 그래픽 편집기인 딜럭스 페인트가 제공한 팔레트가 있다. 나름 미술 전문가가 설계했다고 전해지는데 이 정도는 돼야 좀 알록달록 다채로운 색상을 쓸 수 있는 것 같다. 이 팔레트는 그대로 각종 게임들에서 많이 쓰였다.

사용자 삽입 이미지

요즘이야 웹 표준이라고 하면 HTML5를 떠올리지만, 지금으로부터 20년 전쯤만 해도 웹 그래픽에도 256색 디스플레이를 배려하여 web-safe한 표준 색상 규정이 있었다는 걸 기억하시는가?
RGB 각 축당 6단계 명암을 줘서 총 6^3 = 216개 색상이 나오니 그걸 순서대로 배당하고, 나머지 40개 색깔은 호환용이나 흑백 등 다른 용도로 비워 두는 것이다. 공교롭게도 51*n(n은 0이상 5이하, 이상 6단계)을 해 주면 n이 최대값 5일 때 성분값이 딱 255 최대값이 된다.

색깔을 그런 식으로 배당하는 게, 마치 유니코드에서 나눗셈/나머지 연산만으로 한글 자모 정보를 추출하듯이 원하는 RGB대역의 색깔 인덱스를 계산만으로 얻는 데 유리할 것이다.
차라리 VGA의 기본 256색 팔레트도 그렇게 원시적인 방식으로 색을 배당할 법도 한데 나름 파스텔톤 색깔띠를 만든 게 누구 머리에서 나온 발상인지는 잘 모르겠다.
아무튼, 오늘날 그래픽과 디스플레이 기술이 불과 20여 년 전에 비해 얼마나 까마득하게 발전했는지를 실감한다.

Posted by 사무엘

2015/03/24 19:39 2015/03/24 19:39
, , , ,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1076

이번에 소개하는 세 개의 고전 게임들은 다음과 같은 공통점이 있다.
  • 지금으로부터 무려 30년도 더 전에 만들어진 엄청난 옛날 물건이다. 나이가 본인과 맞먹는다~!
  • 게임기(오락기 포함)이 아닌 PC용이다. 그래서 비주얼이 겨우 4색 CGA로 맞춰져 있는지라 당대의 게임기용 게임들보다는 그래픽이 다소 초라해 보인다.
  • 본인은 옛날에 컴퓨터 학원에서 구경했던 적이 있다. 그런 인연이 있기 때문에 이렇게 내 블로그에다 소개도 하는 것이다.
  • 개인 작품이다.
  • 프로그램은 롬/카트리지 이미지 따위가 아니라 COM 파일 하나로 존재한다. 그래서 도스박스 정도의 에뮬레이터에서 간단히 실행 가능하다.
  • 딱히 이렇다 할 엔딩이 없다. 단지 인간이 도저히 감당할 수 없을 정도로 게임 진행이 점점 더 빨라지고 어려워질 뿐이다.
  • PC용이지만 그래도 여전히 게임기용 게임을 표방하는지, 실행을 종료하는 명령도 없다.
  • 오늘날은 다들 '리메이크' 작품이 나와 있다. 특히 모바일용으로. 게임 목표와 방식은 동일하지만 그래픽과 사운드를 월등히 더 고퀄로 끌어올려서 말이다.

"아~ 이거! 그때 그랬지" 하면서 공감하는 old-timer들이 많이 계시기를 기대하며 글을 시작하겠다.

1. Paratroopers (1982)

우리는 화면 하단 중앙의 포탑의 각도를 좌우 화살표로 조종할 수 있다. 하늘 위로는 헬리콥터들이 수시로 드나드는데 총알을 맞혀서 떨어뜨려야 한다. 총알을 한 발 쏠 때마다 점수를 1 잃지만 목표물을 맞히면 그보다 더 많은 수의 점수를 얻는다. 단, 0점이라도 총알 보급 자체는 무한임.

사용자 삽입 이미지

가끔은 헬리콥터에서 낙하산을 탄 군인이 떨어지는데 얘는 반드시 쏴 죽여야 한다. 좌나 우 한 방향에 군인이 4명이 생기면 이 군인은 포탑 위로 기어 올라와서 포탑을 부수며 이로써 게임이 끝난다.
또한 주기적으로 헬리콥터 대신 제트기가 날아오면서 폭탄을 일직선으로 투하하는데, 이 폭탄도 요격해야 한다. 안 그러면 포탑은 폭탄에 맞아 박살 난다. 폭탄을 요격했을 때의 점수가 가장 높다.

재미있는 것은 사람의 경우 사람 자체가 아니라 낙하산만 맞히는 게 가능하다는 점이다. 그러면 그 사람은 땅바닥으로 운지-_-하는데, 아래에 다른 사람이 있다면 그 사람도 같이 죽는다. 이것이 포탑 아래에 이미 내려간 군인을 제거하는 유일한 방법이다.

나름 아기자기한 요소가 여기저기 담겼고 상당히 재미있는 시간 죽이기용 게임이다.
다만 실제로 게임을 해 보면 조작이 굉장히 불편하다는 게 아쉬운 점이다. 폭탄 요격도 생각보다 잘 안 돼서 첫 제트기 씬 때 죽어 버리는 경우가 허다하다.
포탑이 돌아가는 속도, 총알이 날아가는 속도도 그리 빠른 편이 아니어서 군인들이 좌우로 사정없이 떨어질 때 신속하게 대응하기 어렵다.

이 게임의 개발자는 폴란드계 미국인인 Greg Kuperberg인데.. 이 사람은 1967년생이다. 즉, 저 게임을 중3~고1쯤 되는 나이일 때 어셈블리어를 혼자 뚝딱거리며 만들었다는 뜻이다. 그리고 이 글에서는 소개하지 않지만, 저 사람은 비슷한 시기에 이것과 비슷한 타입의 다른 게임도 여럿 개발한 경력이 있다.

10대 중반의 나이에 엄청난 프로그램을 개발한 괴수야 이 세상에 한둘만 있는 건 아니니, 이것만으로는 그렇게까지 대단한 이야기가 아닐 수 있다. 하지만 저 사람은 좀 더 무서운 가정사와 내력이 있는데, 바로 부모가 모두 영문 위키백과에 등재되어 있을 정도로 저명한 수학자이다. (대학교 수학과 교수) 그리고 저 사람 자신도 나중에 미국의 유수의 명문대에서 박사 학위를 받은 뒤 나중에 수학과 교수가 되었고, 수학은 아니지만 물리학과 교수인 여자와 결혼했다.

이 정도면 우리나라의 홍 성대 씨에 맞먹는 수학 명문 가문이 아닐 수 없다.
수학 덕후가 만든 덕분에 헬리콥터나 대포가 박살날 때 날아가는 파티클들의 모양과 움직임이 상당히 고퀄이었던 건지도 모르겠다. 다시 말하지만 저건 중삐리~고삐리 급 애가 만든 게임이다.

2. Bouncing Babies (1984)

화면의 왼쪽엔 5층짜리 건물이 온통 불길에 휩싸여 있으며, 미처 지상으로 대피를 못 한 어린 아기들이 수시로 창문에서 떨어진다. 그리고 당신은 안전 낙하용 매트를 든 2인조 구급대원이다. 아기는 한번 매트에 떨어지면 오른쪽으로 세 번 통통 튀는데, 이때도 아기를 매트로 받아서 구급차가 있는 데까지 안전하게 보내야 한다. 게임 진행이 하도 엽기적이어서 머리에서 잊혀지지가 않는다. (걍 구급차를 좀 더 건물에 가까이 주차시켜 놓지 그래..?? 같은 건 묻지 말자..ㅋ)

사용자 삽입 이미지

게임의 기술 수준은 그렇게 높지 않다. 건물의 불은 불꽃 애니메이션이 있는 것도 아니고 그냥 무작위로 불 스프라이트를 xor 연산한 것이 나타났다가 사라지기를 주기적으로 반복하는데, 그래도 기술적인 단순함에 비해 불 같은 느낌이 살짝은 난다. 색깔을 나타내는 숫자의 한 비트만을 xor시킨 것으로 보인다.

또한 구급대는 일체의 스프라이트가 존재하지 않으며, 좌우 화살표를 누를 때마다 좌중우 세 위치 중 하나로 곧바로 워프할 뿐이다. 이 정도 게임은 걍 GWBASIC으로도 만들 수 있지 않을까 싶을 정도.

그리고 그런 의심이 더욱 강하게 드는 이유가 뭐냐 하면.. 이 프로그램은 실행 직후에 불, 아기, 구급대 같은 그래픽만 화면에 잠깐 나타났다가 사라지기 때문이다.
도스 시절의 BASIC 프로그래머라면 이건 화면에 그려진 그래픽 내용을 버퍼에다 저장하는 GET 명령을 호출하는 준비 과정과 유사함을 눈치 챌 수 있을 것이다.

난이도가 올라가서, 한 아기가 완전히 구급차로 가기 전에 또 5층에서 아기가 떨어지기 시작하면 구급대는 그야말로 좌우로 축지법을 써야 하게 된다. 옛날 도스용 라이온 킹 게임의 스테이지 중간 보너스 게임으로 있던 Bug Toss와 비슷한 방식이다.

게임 화면에서 고개를 좀 갸웃거리게 하는 것은.. 잔기를 표시한 방식이다.
저 게임에서 미스는 두 말할 나위 없이, 떨어지는 아기를 하나라도 놓쳐서 땅에 떨어뜨리는 것이다. 그런 사고를 낼 때마다 잔기가 하나씩 줄어들며, 모든 잔기가 떨어지면 게임 오버가 된다.

그런데 게임에서는 그 잔기를 아기 모양으로 표시해 놓았다. 아기 모양은 차라리 한 스테이지당 구해야 하는 아기의 수를 나타내고, 스테이지가 진행될수록 그 남은 수가 줄어들게 하는 게 자연스럽지 않을까? 아기 모양으로 "허용되는 미스의 수"를 표기한 건 좀 직관적이지 못해 보인다.

물론 나도 말은 그렇게 했지만 근본적으로 아기를 떨어뜨린다고 해서 저 구급대원이 당장 다치거나 죽는 건 아니기 때문에, 이런 게임 체계에서는 뭔가 다른 대안을 떠올리기도 쉽지 않아 보인다.

뭐, 이런 게임도 있다 싶어서 소개해 보았다.
개발자는 Dave Baskin이라고 알려져 있으나, 동명이인이 많을 뿐만 아니라 직접적으로 이 게임과 프로필이 연결되어 있는 사람을 찾지 못해서 개발자가 지금은 뭘 하고 있는지 알기가 어렵다.

3. Alley Cat (1983)

그리고 그 이름도 유명한 Alley Cat. 얘는 게임 자체와 개발자 모두에 대해서 본인이 이미 심층분석을 한 적이 있기 때문에 이 글에서 또 상세히 다루지는 않겠다.

비슷한 시기에 나온 위의 두 게임과 비교해 보니 Alley Cat이 당시로서는 창의적인 명작 대작이었는지가 실감이 가지 않는가? (비록 Alley Cat은 전적으로 1인 기획은 아니었고, 다른 사람이 만들던 것을 Bill Williams가 물려받은 형태이지만)
다른 게임에 비해 얘는 일단 길거리, 집안, 최종 보스 퀘스트 등 현실 세계과 초현실 세계를 드나들면서 장면 내지 컨텐츠 자체가 엄청 많이 존재한다.

예전 글에도 적혀 있듯, 이 게임의 개발자는 훗날 게임 업계를 은퇴한 뒤 신학을 시작했다. 그러나 유전병을 갖고 있던 게 도져서 30대 후반의 나이로 세상을 떠났다. 생년과 몰년이 pkzip의 개발자인 필립 카츠와 비슷해서 비교된다는 점까지 언급한 바 있다.

* 그나저나 옛날에는 마우스가 없어도 조이스틱은 있었는지.. 그 시절엔 조이스틱을 어느 포트에다 연결해서 어떻게 썼는지 참 궁금해진다.
도스용 고전 게임들 중에서도 조이스틱을 지원 안 하는 물건은 거의 없다시피했기 때문이다.

Posted by 사무엘

2015/03/05 08:31 2015/03/05 08:31
, , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1069

1.
먼 옛날, 윈도 98을 쓰다가 2000으로 갈아탔을 때, 난생 처음으로 Windows NT 계열을 구경하고서 굉장히 놀랐던 기억이 지금도 선하다.

NT 계열은 일단 마의 리소스 퍼센티지 제약이 없었으며, 말로만 듣던 2바이트 문자열 기반의 유니코드 API가 잘 지원되었다. 이 둘은 매우 크게 다가온 아이템이다.
작업 관리자가 9x 계열에 비해서는 넘사벽급으로 잘 만들어져 있었고, 도스창이 아닌 정식 명령 프롬프트가 제공되었다. 이 외에도 EXE/DLL 내부의 리소스를 수정하는 API가 사용 가능한 것도 좋았다. (9x 계열은 16비트 바이너리의 리소스만 고칠 수 있었음)

윈도 95/98에서는 못 보던 파일은 ntoskrnl.exe, csrss.exe, lsass.exe, ntdll.dll, hal.dll, ntvdm.exe, svchost.exe 등이다.
그 반면, 윈도 9x의 잔재이던 파일은 msgsvr32.exe, win386.swp, system.dat, user.dat, winoa386.mod, *.vxd, win.com 같은 것이다.

윈도우 2000/XP부터는 NT 커널 덕분에 주기적으로 재부팅을 할 필요가 없어졌다.
하지만, 주기적으로 재설치도 거의 할 필요가 없어진 건 Vista 이상인 듯하다. XP는 이 범주에까지 넣기에는 좀 2% 부족한 구석이 있었다.

2.
과거에 Windows 9x 시리즈와 Windows NT는 구조적으로 여러 차이가 있었지만, 프로그래머의 관점에서 중요한 특징 중 하나는 '이식성'이었다.
NT는 하드웨어에 종속적인 계층이 철저히 분리되어 설계되었으며 커널이 대부분 어셈블리가 아니라 C/C++이라는 '고급 언어'로 작성되었다. 마치 유닉스처럼. 덕분에 인텔 x86뿐만 아니라 90년대 당시로서는 MIPS, Alpha 등 다양한 아키텍처용 윈도 NT가 나오기도 했다.

NT는 설계 차원에서 특정 하드웨어의 특성에 맞는 '타협'을 별로 안 하고 추상화 계층이 많이 존재하다 보니 깔끔함, 안정성, 범용성 등 많은 장점을 얻을 수 있었다. 게다가 그 시절에 벌써 유니코드를 염두에 두고 wide string을 기본적으로 사용하기 시작한 건 상당한 선견지명이다. 물론 그 대신 시스템 요구 사항이 당연히 1990년대의 가정용 PC가 도저히 범접할 수 없을 정도로 높았다. 메모리와 속도 모두.

이런 NT와는 달리, Windows 95는 이상이 아닌 현실을 추구하였다. 도스와 윈도 3.1을 돌릴 수 있는 정도의 램 한 자릿수 MB대 똥컴을 타겟으로 하여 Win32 API를 최대한 많이 구겨 넣었다. 이 과정에서 지금은 당연시되고 있는 유니코드 API조차도 메모리를 필요 이상으로 많이 잡아먹는 다고 판단되어 과감히 짤려 나갔다.

9x 커널의 소스에는 도스 레거시를 비롯해 오로지 x86 CPU에만 최적화된 쑤제 어셈블리 코드가 난무하였다. 그렇게까지 극도로 최적화를 하고 성능을 짜내야만 메모리 사용량을 1K라도 줄일 수 있을 테니 말이다. 9x는 NT보다 배고픈 운영체제인 것이다. 그럼에도 불구하고 OS/2를 PC 환경에서 완전히 몰아내고 Windows 천하통일을 이루는 데 기여한 일등공신은 NT가 아니라 95였음이 부인할 수 없는 사실이다.

OS/2를 개발하던 마소의 엔지니어들이 떨어져 나가서 따로 만든 게 NT라고는 하지만, OS/2 자체는 NT 같은 이식성 있는 형태라기보다는 9x에 더 가까운 어셈블리 최적화 컨셉이었다고 한다. OS/2는 NT 뺨치는 수준의 앞서 나간 최첨단 운영체제이긴 했지만, 내부 구조가 이식성보다는 역시나 x86에 너무 종속적이었다는 뜻. 그래서 다른 아키텍처로 이식은커녕, 같은 x86 컴에서 가상화 소프트웨어로도 돌리기가 곤란할 정도라고 한다.
(그래도 지금은 x86에서 맥 OS X 해킨토시까지 돌리는 세상이 됐는데 설마 OS/2를 못 돌리나 싶다.)

3.
더 옛날, 도스 시절에는 뭔가 새로운 하드웨어를 사용하려면 램 상주 프로그램을 덕지덕지 실행해 놔야 해서 몹시 불편했다. CD롬조차도!

  • 사운드: sound / unsound (굉장한 옛날 유물. 왠지 '불건전하다!'가 생각 나는 건 기분 탓. ㅋㅋㅋ)
  • 그래픽: simcga, msherc (이것도 옛날 유물. msherc의 경우, QuickBasic에도 포함돼 있었다.)
  • 마우스: mouse (단, 윈도 3.x는 별도의 램상주 드라이버 없이도 마우스를 스스로 인식하여 실행되었음!)
  • CD롬: mscdex (기본 메모리를 상당히 많이 차지했음)

아마 USB 포트가 도스 시절에 도입됐다면, 이걸 인식시켜 주는 램 상주 프로그램도 당연히 필요했을 것이다.
아, 텍스트 모드에서 한글을 구동해 주는 프로그램도 빼먹을 수 없다. hbios / mshbios(윈도 95) 같은 것.
그 외에 화면 캡처나 게임 위저드 같은 램 상주 유틸리티는 하드웨어 인식보다는 편의 기능 분야에 속한다.

요즘은 환경변수 같은 건 PATH에서나 제일 많이 쓰이고, C/C++ 프로그래머에게는 컴파일러의 동작에 필요한 include 및 라이브러리 디렉터리를 지정할 때나 쓰이는 게 고작이다.
하지만 옛날에 사운드 블래스터라는 사운드 카드가 있던 시절에는 기본 IRQ 번호던가 뭔가도 환경변수에다 지정해 놓곤 했으며, 각종 게임의 환경설정 프로그램에는 사운드 종류와 그런 세부 정보도 입력을 받곤 했다.

이것도 정말 까마득한 옛날 얘기가 됐다.
도스용 프로그램들에는 파일 메뉴에 '도스 나들이(DOS Shell)' 기능이 있던 시절이니까 말이다.
운영체제가 이렇게 방대하고 권한이 커지면서 상당수의 유틸리티들은 의미를 퇴색했으며, 전문화된 고급 셸 아니면(토탈 커맨더 같은) 더 전문적인 유지보수 유틸리티(노턴 고스트?) 내지 안티바이러스/보안 쪽으로 업종을 세분화· 전환하는 게 불가피해졌다.

4.
태초에 도스는 검은 화면에 흰 프롬프트밖에 없었을 뿐만 아니라 명령어를 입력하는 환경도 굉장히 자비심이 없었다.
삽입/삭제 모드 같은 개념이 없을 뿐만 아니라, 애초에 이미 입력된 글자를 지우지 않고서는 앞 글자로 cursor를 옮기는 것 자체가 불가능했다. 즉, 왼쪽 화살표만 눌러도 마치 bksp를 누른 것처럼 앞글자가 지워지면서 cursor가 앞으로 이동했다.

명령 히스토리는 직전의 딱 한 단계만 지원했다. F1~F3을 눌러서 직전 명령을 한 글자씩 복구하거나 첫 n 글자 또는 전체를 한꺼번에 불러오곤 했다. 그 시절을 혹시 기억하는 분이 계시는지?

그나마 doskey.com이라고 아마 도스 3~4쯤에서 추가된 걸로 추정되는 외부 명령 램 상주 유틸리티를 실행하면 위/아래 화살표로 히스토리가 가능하고 좌우 cursor 이동이 자유롭게 가능해졌다. 지금은 너무 당연하게 여겨지는 기능이 옛날에는 별도의 프로그램을 통해서만 접근 가능한 액세서리 기능이었던 것이다.

윈도 NT의 명령 프롬프트는 기본적으로 이 모드인 듯한데, 그런데 tab을 눌러서 파일/디렉터리 이름을 자동 완성하는 기능은 윈도 XP에서 처음으로 추가되었다. 세상에, NT4와 2000 시절까지만 해도 이런 기능이 없었으며, tab을 누르면 그냥 문자적인 탭이 그대로 삽입되곤 했다.

단, 기능 추가만 있는 건 아니다. 윈도 XP까지는 탐색기에서 파일이나 디렉터리를 명령 프롬프트에다 drag & drop을 하면 그 이름을 자동으로 삽입해 주는 기능이 있었는데 아마 윈도 Vista부터는 그 기능이 의도적으로 삭제되었다. 보안 때문에 취해진 조치라고 하는데 이런 편리한 기능에 도대체 무슨 보안 문제가 있는지는 나로서는 알 길이 없다.

명령 프롬프트를 전체 화면으로 실행하는 기능 역시 Vista에서부터 삭제되었다. 딱히 별 의미가 없어지기도 했으니.
어디 이 뿐이랴. 2000까지만 해도, 콘솔창 내용을 마우스로 긁는 '빠른 편집' 모드는 곧장 사용 가능했던 반면 XP부터는 먼저 속성 창을 거쳐서 강제로 켜야만 사용 가능하게 바뀌었다. 이건 보안 이유 때문은 아니고, 마우스를 지원하는 도스용 프로그램과의 호환 때문에 취해진 조치라고 한다.

제아무리 도스 기반이 아닌 NT 계열의 명령 프롬프트라 해도, 문자 인코딩부터가 2바이트 ANSI 코드 페이지와 여전히 얽혀 있고 도스의 흔적을 완전히 걷어내지는 못한 듯하다. 그래도 64비트부터는 16비트 코드 자체가 이제 지원되지 않는데 더 좀 걷어내도 되지 않나 싶다.
기존 명령 프롬프트보다 더 강력한 대체제라고 일컬어지는 PowerShell이라는 물건이 있긴 하나, 본인은 그런 게 있다는 것만 알고 이게 특별히 장점이 무엇인지는 알지 못한다.

아 그리고. 지긋지긋한 Terminal 내지 굴림체 말고 Consolas 내지 Courier, Lucida Console 같은 글꼴을 좀 쓰고 싶은데 Wndows는 공식적으로는 명령 프롬프트의 글꼴을 자유자재로 바꾸는 방법을 제공하지 않는다. 마치 uxtheme을 해금/탈옥시키듯이 레지스트리를 조작해서 글꼴을 바꾸는 방법이 인터넷에 있긴 한가 본데 본인은 성공하지 못했다.

Posted by 사무엘

2015/03/02 19:28 2015/03/02 19:28
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1068

본인이 지금까지 게임 포함 고전 소프트웨어에 대해 글을 잔뜩 올린 것은 그래도 플랫폼은 PC 한정인 편이었다. 운영체제는 응당 16비트 도스/윈도이다.
하지만 그보다 더 옛날 8비트.. 아무래도 롬 베이직을 빼면 롬 카트리지를 꽂아서 게임밖에 할 게 없었던 더 옛날 컴퓨터에 대한 추억도 없는 건 아니다.

본인은 난생 처음 접한 개인용 컴퓨터가 286 AT인 관계로, 저 컴퓨터는 친구 집에서 어깨 너머로 구경만 했지 개인적으로 소장한 경험은 없었다.
그런 플랫폼용으로 프로그램 개발은 어떻게 했을까? 16비트도 모자라서 8비트이면 int도 char과 크기가 같을까? 몇만 바이트밖에 안 되는 허접한 메모리로 어떻게 저런 게임을 만들 수 있었을까? 1980년대 초니까 C 컴파일러조차도 없이 그냥 기계어/어셈블리 직통 코딩을 했을까?

그런 컴퓨터와 아예 8비트 아케이드 게임기와의 관계는 어떠했을까? 그리고 MSX인지 뭔지는 무슨 규격이지? 난 그런 건 전혀 모른다.
그러고 보니 일본이 유난히도 이런 플랫폼용 게임을 많이 만들었던 것 같다. 이 글에서 소개하는 5개의 게임도 다 일제이다.
하지만 본인은 정작 일본에서 동전 품절 현상을 일으킬 정도로 대성공을 거뒀다는 슈퍼마리오는 전혀 접한 적이 없었다. 그리고 황금도끼나 보글보글도 PC 도스용을 접했지 오락실용은 접한 적이 없다. 오락실용이 더 완성도가 높고 재미있는데도 말이다.

1. 남극 탐험

사용자 삽입 이미지

영어 원제는 Antarctic Adventure로, 1984년에 일본 코나미에서 MSX용으로 개발했다.
구멍과 바다표범을 요리조리 피하면서 펭귄을 잘 달리게 하는 게 목표이다. 구멍에 빠지거나 바다표범에 부딪히면.. 주인공인 펭귄이 죽거나 다치지는 않지만.. '지연'이 발생해서 제한 시간 안에 도착을 못 하고 미스가 난다.

BGM은 잘 알다시피 다른 음악이 아니라 스케이터 왈츠라는 고전 음악이다.
그리고 레벨을 클리어하면 가상 세계가 아니라 현실에서 남극 기지를 보유하고 있는 국가들의 국기가 뜨는데, 이는 이 게임이 완전한 허구의 게임성보다는 일종의 교육용으로 개발되었기 때문이다.
늘 드는 생각이지만, 주행 거리 단위는 km를 m로 거의 1/1000에 가깝게 너프시켜도 모자랄 판에 뻥튀기가 너무 심하다.

2. 캐슬 엑설런트

사용자 삽입 이미지

1985년에 일본 아스키 사에 MSX 및 여타 플랫폼용으로 개발한.. 일단은 아케이드 게임이지만 슈파플렉스처럼 퍼즐 요소가 굉장히 강하다. "도미솔미 파레솔~~ 도미솔미 파레도" 요런 BGM이 유명하다. 참고로 아스키는 MSX 규격을 제정하는 데 동참했던 그 회사이다.

얘가 게임 메카닉면에서 여타 게임들과 다른 점은.. 점프가 단순히 일시적인 추진력으로 공중에 떴다가 즉시 떨어지는 게 아니라... 일종의 제트팩을 몇 초간 동작시키는 것과 같다는 점이다. 그리고 다른 방으로 들어가면 각종 기물이나 적들의 위치가 원상복귀되어 버린다는 것도 비현실적이다. 단, 없애 버린 기물이나 적이 다시 생기지는 않는다.

이 게임은 레벨이라는 개념이 없으며, '캐슬'을 구성하는 가로 10*세로 10 총 100개의 방 전체가 거대한 단일 레벨이다. 그리고 지형과 기물, 각종 열쇠 조합을 이용한 굉장히 까다로운 퍼즐을 풀어야 공주가 있는 방까지 갈 수 있다. 주인공은 각종 움직이는 트랩이나 적에게 걸리면 HP 없이 바로 죽는다. 그리고 무기가 없어서 적은 움직이는 기물이나 트랩을 이용해서만 죽일 수 있다.
난 당연히 엔딩은 못 보고 포기했지만, 그래도 뭔가 중세풍의 성 안에서 각종 보석을 먹는 게 잠시나마 재미있긴 했다.

3. 덱스더(Thexder)

사용자 삽입 이미지
우리말로 표기와 영어 스펠링이 굉장히 헷갈려서 그 동안 검색을 하고 싶어도 못 하곤 했다. 원제품의 로고타입을 보면 T가 영락없이 C처럼 적혀 있기도 해서 더욱 혼란스러웠다. 게다가 Dexter라는 이름도 있다.
그런데 PC용에는 포팅을 한 기업인 '1987 시에라 온라인'이라는 문구가 뜬다는 걸 기억을 되살려서 역추적 후 검색에 성공했다.

친구 집에서 패미컴용을, 그리고 나중에 초딩 시절에 개인적으로 PC DOS용도 해 봤다. PC용은 극악의 종횡비를 자랑하는 CGA 640*200 16색 그래픽 모드에서 실행되었다. 물론 원작은 1985인가 86년에 Game Arts라는 일본 기업에서 개발되었으며, 그 당시 수십~수백만 카피가 팔렸을 정도로 굉장히 히트 치고 성공한 작품이라고 한다.

게임 주인공은 이족보행과 비행 기능을 모두 갖춘 로봇이다. 아케이드 게임으로서는 아주 드물게 각도를 목표물을 자동 조준하여 총을 쏘는 기능이 있다. (이것 말고 자동 조준을 하는 게임으로는 난 툼 레이더밖에 못 봤다~!)
비행 모드에서는 덩치가 좀 더 작아지고 낙하· 추락을 안 하게 되지만 자동 조준을 못 하며 중간에 정지를 할 수 없다는 제약이 생긴다.

이런 상태에서 던전 안의 수많은 장애물· 몬스터들을 죽이거나 피하면서 던전을 빠져나가는 게 게임의 목표다. 게임을 잘 못하면 적들이 너무 많이 나와서 걔네들에게 다구리 당하다가 게임오버 된다.
SF스러운 느낌이 나면서 한편으로는 단조 특유의 구슬픈 느낌이 나는 BGM도 인상적이다.

4. 마피 (Mappy)

사용자 삽입 이미지

1983년에 일본 남코에서 개발한 아케이드 게임으로, 동작 플랫폼이 위의 둘과는 좀 다르다. 위키백과에서도 MSX가 아니라 '아케이드'라고만 소개하고 있는데, 그래서 그런지 본인 역시 이건 동전을 넣어서 사용하는 동네 문방구의 오락기로만 구경해 봤다.
주인공은 쥐이고 적들은 고양이인데, 고양이를 피하면서 아이템들을 모두 모아야 한다.

고양이를 직접 공격해서 죽일 수는 없으며, 문을 적절한 타이밍에 열어서 기절시킬 수만 있다. 그리고 굉장히 특이한 규칙이 있는데, 봉봉 패드를 타고 점프 내지 낙하 중일 때, 다시 말해 발이 땅에 닿지 않은 상태일 때는 고양이와 닿아도 죽지 않는다. 요 타이밍을 잘 이용해야 한다.
그런데 안전하다고 해서 봉봉 패드만 계속 연달아 타고 있으면 안 된다. 그러면 패드가 나중에 끊어져서 화면 아래로 떨어지기 때문이다.

E단조의 BGM 멜로디도 20년 가까이 기억 속에 봉인되어 있었는데 본인은 아직까지 정확하게 기억하고 있다. 신기하다.
그리고 정식 오락실도 아니고 마치 뽑기 기계처럼 비치된 '동네 문방구의 오락기'라고 하니까 또 추억이 돋는다. 요즘은 그런 용도의 게임은 스마트폰 게임이 다 대체해 버렸으며, 3, 40대 아저씨들이나 옛날 추억을 살리려고 에뮬레이터와 롬 파일을 구해서 PC에서 게임을 즐기는 지경이 됐다.

일본에서는 패미컴(family), 퍼스컴(personal) 등.. 한국 같았으면 그냥 알파벳 이니셜을 그대로 썼을 텐데 영어 단어를 제멋대로 뚝뚝 잘라 내서 말은 참 잘 만든다는 생각이 들었다.

5. 요술나무 (Magical Tree)

남극탐험과 마찬가지로 코나미에서 1984년에 MSX용으로 개발한 작품이다. 제목을 까맣게 잊어버린 상태였는데 구글에서 MSX tree climbing game이라고만 쳤더니.. 이거 뭐 내가 원하는 답이 즉시 튀어나와서 기억을 복원할 수 있었다. 역시 무서운 구글.

사용자 삽입 이미지

이건 깃털 달린 모자를 쓴 귀여운 인디언 소년이 주인공으로 나오고, 나무를 수직으로 끝도 없이 타고 오르는 게 목표인 게임이다. 9개의 스테이지를 거치면서 설정상 총 2004m를 올라가야 한다. 한라산보다 약간 더 높구나.
게임 BGM을 말하자면, 평소에는 F장조 파~도 파~도 파라솔파도... 요렇게 시작하는 명랑한 멜로디 6마디가 무한 반복된다. 아, 한 스테이지에는 화면의 중앙에 나무 기둥이 있는 보통 모드가 있고, 중앙 대신 좌우 양 끝에 나무 기둥이 있는 특별 모드가 있다. 특별 모드에서는 반음 간격의 뚜두뚜두...만 반복되면서 뭔가 위기 상황인 듯한 분위기가 난다.

주인공을 방해하는 건 무슨 게처럼 수평 비행을 하는 부엉이, 번개를 떨어뜨리는 먹구름, 그리고 시도 때도 없이 튀어나오는 애벌레 등이다. 아이템으로 칼과 활이 있는데 이건 점수만을 줄 뿐 무기가 아니다. 이 게임엔 주인공에게 무기를 사용한 공격은 없으며 단지 사과를 떨어뜨리고 굴려서 적을 없애는 시스템만이 존재한다.

끝도 없이 높이 솟은 나무 위에 성이 있는 게 '재크와 콩나무' 동화 같은 느낌이 든다.

Posted by 사무엘

2015/01/27 08:26 2015/01/27 08:26
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1055

« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 11 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/07   »
      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:
1410540
Today:
71
Yesterday:
512