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

이 글에서는 1994년에 발매되었던 국산 패키지 게임을 하나 소개하고자 한다. '리크니스'라고 그림체나 게임 진행 방식이 슈퍼마리오와 비슷한 형태인 아케이드 게임이다.
본인은 그 시절에 얘 실물을 해 보거나 구경한 적이 없다. 단지 초딩 말년이던 시절, PC월드 한국어판 1994년 8월호 기사를 통해 소개된 것을 읽은 기억만이 남아 있다. 그리고 그 기억이 최근에 오랜만에 되살아나서 다시 회고를 하게 된 것이다.

1990년대 중반에는 그 날이 오면, 못말리는 탈옥범, 낚시광 같은 여러 국산 게임들이 있었다.
이 시절에 게임은 하드웨어 제어가 용이한 도스용으로 개발되었다. DirectX나 3D 셰이더 언어, 언리얼/유니티 엔진 같은 건 존재하지 않았다. 그 대신 어셈블리를 이용한 교묘한 하드웨어 테크닉이 고급 기술로 취급되었다. 그래픽 모드를 바꾸고, 비디오 메모리를 직접 조작해서 화면이 Doom처럼 쫙 흐르듯이 갈라지고, 사각형이 아닌 형형색색 모양의 2D 스프라이트로 애니메이션을 구현하고..

IBM PC는 게임 전용 하드웨어가 아니다 보니 3차원 그래픽은 고사하고 부드러운 2차원 화면 스크롤을 구현하는 것조차도 보통일이 아니었던 것 같다. Windows API로 치면 ScrollDC 내지 ScrollWindowEx를 구현하는 거 말이다.
스크롤 기술이 더 발전하면 '다중 스크롤'이 된다. 먼 배경은 천천히 스크롤하고, 가까운 기물은 많이 스크롤해서 반쯤 원근감과 입체감을 내는 것 말이다.

저 리크니스도 그렇고, 더 옛날에 id에서 Doom 이전에 개발했던 커맨더 킨을 보면 자기들의 독자 노하우를 동원해서 게임기를 방불케 하는 빠르고 부드러운 스크롤을 구현했다고 자랑을 했다. 스크롤을 못 하면 페르시아의 왕자 같은 페이지 단위 스크롤밖에 구현할 수 없을 것이고 그건 단조롭다. Titus에서 만들었던 고인돌(Prehistorik) 1편과 2편의 스크롤의 차이도 생각해 보시라.

게임용 그래픽 아티스트들도 포토샵이나 MAX, Maya가 아니라 딜럭스 페인트가 생계 도구였다. 트루컬러 같은 건 없고, 256색에서 팔레트 배분을 잘하고 도트 노가다를 열나게 하는 게 일이었다.
320*200이 지금으로서는 상상하기 힘든 워낙 저해상도이니, 막 크고 화질 높은 그림을 그릴 필요가 없는 건 다행이었다. 그러나 스프라이트 말고 고정된 그림은 가장자리 안티앨리어싱을 잘해서 저해상도에서도 최대한 부드럽게 보이게 해야 했다.

1990년대에 그런 불모지 영역을 개척했던 1세대 게임 개발자들이 김 동건· 이 은석(85되었수다/삭제되었수다), 정 재성(그 날이 오면) 같은 분들이다. 그리고 같은 연배의 개발자로 김 학규라는 분이 있으며, 이분이 옛날에 소프트맥스의 아트크래프트 스튜디오에 소속되어서 만들었던 게임이 리크니스이다.

(이 게임을 심층 분석한 블로그 링크)

리크니스는 만화풍 + 파스텔톤의 그래픽을 추구했는데 개인적으로 색감이 참 예쁘고 마음에 든다.
저런 게임 스토리 연출과 각종 그래픽들을 그 시절에 어떻게 다 생각해 내고 만들었는지 경이로울 따름이다. 하드웨어 장비도 열악하고 지금 같은 인터넷도 없던 시절에!

스토리 화면에서 리크니스(남캐)와 아이리스(여캐)가 눈을 마주친 뒤, 새들이 푸드득 날아가면서 시작 메뉴 화면이 뜬다.
링크하는 블로그 글에서도 지적하지만, 주인공을 선택했을 때의 반응이 참 익살스럽다.
블루스 형제(Titus 작)와는 달리, 이 게임에서는 선택받은 주인공이 기뻐하는 게 아니라 "뭐? 또 나야?" 같은 뻘쭘하고 당황한 표정을 짓는다. 특히 아이리스 아가씨는 마시던 물을 뿜기까지 한다.

(전체 플레이 동영상)

플레이 장면을 보니 진짜 슈퍼마리오 스타일 같다.
여러 블로그들의 평을 보면.. 리크니스는 왕창 어렵다는 게 중론이다. 특히 카지노 슬롯 같은 걸 돌려서 공격하는 최종 보스전은 메모리를 강제 조작해서 보스의 HP를 너프시킨 뒤에야 겨우 깼다는 얘기까지 있다.
그럼 나 같은 사람한텐 더욱 어렵겠다. <그 날이 오면>도 그렇고 게임들이 전반적으로 어려웠다. ^^

끝판을 깬 뒤 엔딩은 생각보다 허무하고 별로 볼 게 없었다. 개발팀의 사진 같은 게 나오는 것도 아니고.

본인이 리크니스를 재주목하게 된 이유는 개인적인 경험과 관련하여 또 있다.
먼 옛날에 하이텔 게임 제작 동호회에서 딱 두 번인가 게임 공모전을 한 적이 있었다. 이 얘기 자체는 <삭제되었수다>를 소개하면서 예전에 한 적이 있다. 그때 저 게임이 1등을 했기 때문에.

그런데, 그 당시에 본인이 개인적으로 알고 지내던 프로그래밍 동호회 친구도 거기에 게임을 출품했으며, 공개된 그 게임을 나도 해 봤다.
그 게임에 쓰였던 BGM들 중 일부가 바로 리크니스 게임의 BGM을 빌린 것이었다는 걸 알게 된 게 그로부터 거의 20년 뒤의 일이니 감회가 새로울 수밖에... 일부 스테이지의 음악이 귀에 아주 익숙했다.

1990년대에 20대 초반의 나이로 이미 저렇게 날고 기었던 김 학규 씨는 그 뒤로 대학까지 중퇴하고서 게임 개발 학원 강사로 뛰기도 했고, 수제자들과 함께 그라비티를 설립해서 걸출한 온라인 게임을 계속해서 개발했다. 1990년대 이후에는 플랫폼도 Windows로 넘어가고 3D 기술 + 네트워크 기술까지 게임 개발 방법론이 그냥 싹 갈아엎어진 거나 마찬가지 아니던가? 그걸 일일이 다 공부하면서 어떻게 따라갔는지가 그저 대단할 따름이다. 하지만 개발 능력 대비 경영 수완이 부족해서 자기가 세웠던 회사에서 물러나기도 하고 인생에 우여곡절이 많았던 모양이다.

나도 학창 시절에는 프로그래밍에 빠져서 제도권 교육에서는 완전히 이탈해 버렸지만.. 그렇다고 실력이야 쨉도 안 되고 저렇게 현업에서 당장 돈 되는 물건을 만들 능력도 없다 보니 학교를 때려칠 배짱은 없었다. 저런 사람들의 꿈과 열정이야 참 대단하긴 한데 요즘 우리나라는 게임 업계가 사정이 너무 안 좋긴 하다. 정부로부터의 온갖 규제, 사용자의 불법복제, 끊임없이 치고 들어오는 외산 게임들.. 업계에서는 또 공밀레에 야근 야근..;;

그런데 이렇게 열악함에도 불구하고 코딩으로 먹고 살자니 그나마 SI 품팔이 같은 진짜 지옥 말고 스스로 수익을 내고 할 만한 데가 미우나 고우나 게임밖에 없다. 국내의 걸출한 소프트웨어 개발자 프로그래머들을 제일 많이 볼 수 있는 데가 모르긴 몰라도 넥슨, NC 같은 게임 개발사들이다. 에구, 이건 나의 적성· 전공과도 관계가 있는 문제인데 이 바닥이 앞으로 어떻게 변화할지 찬찬히 살펴봐야 할 것 같다.

Posted by 사무엘

1. 블레이크 스톤 (Blake Stone)

먼 옛날 기억을 되살려 보니, 본인은 1990년대 중반에 울펜슈타인이나 둠 같은 id 사의 게임 말고 다른 계열의 3D FPS 게임을 친구 집 컴퓨터에서 본 적이 있었다. Doom처럼 좀 SF스러운 분위기이지만 Doom은 아니고 그것보다는 기술 수준이 뒤떨어졌다. 열쇠가 없는 상태로 잠긴 문을 열려고 하면 깜찍한 소리로 문이 열리지 않는다는 피드백이 왔다. (울프와 둠에는 청각 피드백이 없음)

그리고 제일 결정적인 단서로는.. 체력이 막대기나 숫자나 주인공의 얼굴 상태로 표시되는 게 아니라 검은 배경에 초록색 파형인 심전도 그래프로 나타났다. 완전히 죽어 버리면 물론 심장 박동이 없어진다.
이 모든 조건을 만족하는 게임을 검색해 보니.. Blake Stone이다.

기술적으로는 얘는 울펜슈타인 3D 엔진을 기반으로 개발되었다. 그렇기 때문에 높이를 표현할 수 없으며 레벨 배경은 여전히 건물 안으로 제한된다. 그러나 얘는 울프와는 달리 (1) 바닥과 천장에도 텍스처를 얹어서 그래픽을 고급화했으며, (2) 시점에서 먼 곳은 살짝 더 어둡게 표시되는 걸 구현했다. 게다가 얘도 미래가 배경이기 때문에 높이가 없다는 것만 빼면 전반적으로 둠과 분위기가 비슷해 보인다.

얘는 분명 나쁘지는 않은 게임이었으나, 스케일과 기술 수준 등에서 둠의 적수가 될 수는 없었다. 게다가 너무 늦게 나왔다. 출시일이 1993년 12월. 얘가 발매되고 나서 겨우 1주일 뒤에 Doom이 출시되는 바람에 블레이크 스톤은 존재감이 싹 묻혀 버렸다.

2. 퀘이크 1의 베타 3

본인은 중학교 말년에 어느 이웃집 형이 가져온 불법복제 백업CD를 통해서 퀘이크라고 둠의 다음 세대 게임을 처음으로 접했다. 그때는 지금 같은 고속 인터넷망이 없었으니 어둠의 경로에서 소프트웨어 불법복제를 책임지던 매체는 CD였다.
요즘은 아무 컴퓨터에나 당연하게 달려 있는 CD 쓰기/굽기 기능도 그때는 고가의 기계를 따로 돌려야 할 수 있는 첨단 기능이었다. 어디 그 뿐이랴? 요즘은 인터넷, USB 메모리, 외장 하드의 발달로 인해 광학 드라이브의 필요 자체가 극도로 줄어들어 있으니 격세지감이 아닐 수 없다.

그렇게 본인은 오랫동안 도스용 퀘이크 1을 즐겼다. 486 66MHz짜리 컴퓨터로는 퀘이크는 기본 최저 해상도인 320*200/240대에서나 제대로 프레임이 나왔지 640*480으로는 도저히 제대로 할 수 없었다. 그러고 보니 동일한 영어 이니셜을 갖고 "그 FPS(1인칭 슈팅) 게임은 이런 사양의 컴터에서 FPS(초당 프레임 수)가 얼마나 나오냐?" 이런 드립을 치는 게 가능하구나.;;

세월이 흘러 2000년대 중반이 되었고, 본인의 컴퓨터는 퀘이크를 처음 접하던 시절보다 당연히 성능이 월등히 더 향상된 걸로 바뀌었다. 본인은 옛날 생각에 Windows용으로 포팅된 퀘이크를 고전 게임 사이트에서 구해서 돌려 봤다.
그런데 이 퀘이크는 내가 옛날에 하던 퀘이크와는 미묘하게 다른 게 많았다. 정자체에 가깝던 화면 글꼴은 bloody한 분위기를 내려는 듯 좀 흘리고 날린 형태로 바뀌었다. 메뉴를 꺼내면 뒤의 게임 배경이 단순히 팔레트만 바뀌는 게 아니라 시꺼먼 하프톤 점이 쫙 깔렸다.

각 에피소드별로 모아야 하는 아이템의 이름을 본인은 10여 년 가까이 sigil이라고 알고 있었는데 이 게임은 rune이라고 표현했다.
그 이름도 유명한 무기 파워업 아이템은 quake power이라고 알고 있었는데 그게 이 퀘이크에서는 quad damage였다.
새로 구한 퀘이크는 에피소드 2의 마지막 레벨은(비밀 레벨 말고) 물웅덩이를 중심으로 사방으로 이동해서 다리를 내는 형태였는데 내가 기억하는 맵이 아니었다. 또한 에피소드 3의 마지막 레벨의 끝부분에서 Vore 두 놈은 높은 곳에서 튀어나왔으나, 이 게임은 다리 아래 용암 바닥에서 튀어나왔다.

차이점은 이 뿐만이 아니다. 에피소드 1의 보스인 Chthon의 생김새도 내가 기억하던 모양이 아니었다. 내가 하던 퀘이크는 얼굴도 몸통과 비슷한 색깔이고 눈이 있었던 반면, 이 퀘이크는 딱히 눈 같은 게 없고 얼굴 전체가 세로로 난 입의 이빨 같은 것으로 둘러져 있었다.

결정적으로 게임 전체의 최종 보스인 Shub-Niggurath와 싸우는 마지막 레벨은 완전히 다른 맵으로 바뀌어 있었다.
내가 기억하는 마지막 맵은 요렇게 뭔가 에피소드 4의 비밀 레벨과 비슷한 분위기였다. 나중에는 천장이 청록색인 거대한 필드에 도달하고, Shub-Niggurath가 있는 곳까지도 갈 수는 있지만 여기서 더 보스를 죽이거나 게임을 진행해서 엔딩을 볼 수는 없었다. 적을 다 죽인 뒤에 어떻게 해야 할지를 몰랐다.
(그나저나 퀘이크는 다 뭘 참고해서 몬스터들의 이름을 지었는지, 스펠링이 다 읽기 힘든 형태이다.)

이렇게 내가 경험했던 퀘이크에 차이가 존재했던 이유는 이미 제목에 쓰여 있다. 내가 중딩 시절 옛날에 했던 퀘이크는.. 바로 퀘이크 정식 버전이 발매되기 불과 2주 남짓 전에 유출된 '0.8 베타 3 버전'이었기 때문이다. 그게 어째 어떤 복돌이가 만든 백업 CD에 포함되었던 것이다. 난 10년이 넘게 베타 버전 퀘이크가 정식 퀘이크인 줄로 알고 있었다.
그래도 이런 것도 이제 검색해 보면 구체적인 출시 내역을 다~ 알 수 있고.. 옛날 기억도 어지간한 건 다 복원 가능한 세상이 됐으니 참 대단하다.

beta 3 구버전의 구동 및 플레이 동영상을 짤막하게나마 유튜브로 다시 보니 감회가 새롭다. 구버전은 마지막 레벨을 클리어 하는 엔딩이 원래 존재하지 않았던 게 맞았다. 미완성이었다.
그에 반해 정식 버전은 적절한 타이밍에 순간이동 장치로 들어가서 Shub-Niggurath의 몸 속으로 '텔레프래깅'을 하는 방식으로 적을 죽여서 엔딩을 볼 수 있다.

더 생각나는 걸 열거하자면, 몬스터 Ogre가 톱질 하는 소리가 구버전 것은 정식 버전의 것보다 피치가 좀 더 낮았다. Vore가 쏘는 탄환이 구버전은 그냥 용암 fireball과 동일했지만 정식 버전은 보라색 공으로 바뀌었다.

또한, 주인공이 뭔가에 깔려 죽었을 때 구버전은 be crushed라는 말을 썼지만 정식 버전은 be squished라고 말을 바꿨더라. 본인은 crush라는 단어를 둠과 퀘이크를 통해서 알게 됐다. Doom 2에서도 레벨 6이 The crusher이기도 하고 말이다. 끝으로, 구버전에서는 Ogre 이상 몬스터들은 로켓 같은 무기로 오버킬을 당해도 결코 육편 피떡으로(gibbed) 변하지는 않았던 걸로 기억한다.

id에서 1990년대 중반에 개발했던 Doom과 Quake들은 묘사가 잔혹할 뿐만 아니라 오각형, 염소 뿔 등 의도적으로 오컬트나 사탄 숭배교를 표방하는 듯한 비주얼이 많이 들어가 있었다.
그래서 자국 내에서도 이런 비판을 많이 받았는가 보다. 파일로 제공되는 도움말 문서를 보면, FAQ 중 하나로 "Are you guys Satan-worshipers?"가 있고, 이에 대한 답변은 No 한 마디로 간단히 일축해 놓았다.

그런데, 이것도 구버전의 도움말 문서는 간단히 No만 있는 게 아니라.. "아니요, 우리는 그냥 오각형과 666을 좋아할 뿐입니다."라는 부연 설명도 들어있었다. 중고딩 시절에 분명히 읽었던 기억이 있다.
id는 전통적으로 종료 확인 메시지도 그렇고 말을 전반적으로 익살스러운 농담조로 하는 걸 좋아하긴 한데, 이 질문에다가도 답변을 그런 식으로 하면 기독교 단체 같은 데에다가 더 큰 논란과 어그로를 일으킬 것 같으니 저 말을 삭제한 듯하다.

3. 기타

10대 중반의 나이로 접했던 FPS들은 나의 가치관 형성에 많은 영향을 줬다.

요렇게 거의 270도 턴을 해서 미로처럼 꼬불꼬불 들어가게 돼 있는 건물 화장실을 이용한 적이 있었다.
벽면 텍스처도 규칙적인 형태인 게 무슨 둠 맵 같다. 문은 좌우로 열리는 게 아니라 셔터처럼 위로 열릴 것 같다.
이런 모양의 맵을 설계하면 bsp 파일이 어떤 형태로 만들어질까 이런 게 머리에 어른거린다. -_-;;

정확하게 1인칭 시점인 건 아니지만 툼 레이더도 있다.
선유도 공원을 가 보면 거긴 잡초가 낀 야외 콘크리트 구조물이 영락없이 툼 레이더 1 맵 같다.
손에 쌍권총 쥐고 옆으로 점프라도 하고 싶은데.. 그랬다가는 다치겠지.

말이 나왔으니 말인데, 내 생각에 적당히 스토리만 잘 짜 놓으면 우리나라 DMZ를 배경으로 툼 레이더 커스텀 레벨 얼마든지 만들 수 있다고 본다. GP에 들어가서 아이템 먹고 북한군을 때려잡는 식으로 진행될 것이다.
Demilitarized Zone 이름도 얼마나 근사하냐? ㅋㅋ

Posted by 사무엘

본인은 태생적으로 신체 활동을 싫어했다. 운동 경기는 스스로 하지도 않고, 남이 하는 걸 즐겨 보지도 않았다. PC 게임으로도 액션· 아케이드에 밀려서 거의 안 했다.
야구의 경우, 아직까지도 정확한 룰과 득점 조건도 모를 정도이다. 투수가 던진 공을 쳐내고 나서 각 선수들이 무엇을 목표로 어디로 그렇게 열나게 뛰어가는지 로직을 모른다. 배구· 농구· 축구만치 룰이 직관적이지 않아서 말이다. 당연히 유명 구단이나 선수 같은 것도 전혀 아오안이다.

야구는 옛날에 '하드볼'이라는 PC용 고전 게임이 있었고, 축구는 더 나중에 'FIFA 연도' 이런 게임이 있었던 것 같다. 요즘도 계속 나오는지는 모르겠다.
그런데 스포츠라는 장르에 속하는 고전 게임 중에는 그렇게 한 종목에 특화된 놈이 있는가 하면, 간단한 종목들을 여럿 옴니버스 식으로 제공하는 게임도 있었다. 오늘은 그런 게임들을 먼저 좀 늘어놓아 보겠다.

먼저, 캘리포니아 게임즈이다. 학교 친구와 함께 디스켓으로 실행하며 즐겼던 추억이 있다.

Epyx라고 옛날에 스포츠 게임 시리즈를 전문적으로 개발해 온 회사에서 1987년에 발표한 게임이다. Epic Games와는 다른 회사임.
IBM PC뿐만 아니라 다양한 플랫폼으로 만들어졌다. PC용의 경우 VGA 카드가 개발되기도 전이었으니 최고 그래픽은 응당 EGA 16컬러였다.
게임 로고가 뜬 뒤엔 위의 사진과 같이 검은 배경에 흰 글씨로 게임 방식을 선택하는 메뉴가 뜬다. 선택막대가 Doom은 두개골이라면 얘는 야자수인 게 인상적이다.

이 게임은 여러 간단한 퍼즐형 스포츠의 컬렉션이다. 요즘 같으면 플래시나 모바일용으로 만들면 딱일 듯한 스케일이다.
보드 타기, 파도 타기, 제기 차기, 롤러 스케이트처럼.. 무슨 올림픽 종목까지는 아니지만 미국 서부의 길거리 스포츠라고 해야 하나.. 그런 것들이 제공되었다.

각 경기별로 주인공은 남자도 있고 여자도 있다. 특히 부메랑처럼 생긴 디스크 날리기(flying disc)도 있는데... 뭔가 좀 미국스러운 게임 같다. 사람이 날리고 개가 받아서 가져오는 게 아니라, 남자가 날리고 여자가 받는다. 실사로 치면 이런 식으로.

먼저 남자가 각도와 힘을 설정해서 디스크를 날리는데, 이 자체는 뭐 투사체를 던지는 기능이 있는 게임들과(QBasic 고릴라, Scorched Earth 등) 크게 다를 바 없는 UI이다.
디스크를 날린 뒤부터 게임 컨트롤은 파트너인 여자에게로 넘어간다. 디스크가 떨어질 걸로 예상되는 위치에다 파트너를 잘 조종해야 디스크를 붙잡을 수 있다. 디스크와 여자 파트너의 위치는 화면 위의 미니맵에 표시되어 있다.

그런데 재미있는 건... 남자가 디스크를 오랫동안 안 날리고 가만히 있으면.. 하늘에서 무슨 UFO 같은 게 내려와서 여자를 납치해 가 버린다..;;; 그 장면을 우리가 직접 볼 수는 없고 미니맵 상으로만 표시된다. 그리고는 게임오버. 디스크가 외형상 비행접시와 비슷하니 이런 깜짝쇼를 넣은 건지는 모르겠다.

그리고 또 캘리포니아 게임즈에서 즐겨 하던 게임은 사이클이었다. 장애물을 요리조리 잘 피해야 넘어지지 않고 제한 시간 안에 목적지에 도달할 수 있으며, 그 와중에 회전이나 바퀴 들기 같은 위험한 묘기도 종종 해서 성공해야 점수를 딸 수 있다. 생각보다 어려웠던 걸로 기억한다.
1990년에는 VGA를 지원하고 1보다 그래픽이 크게 강화된 캘리포니아 게임즈 2가 나오기도 했다. 하지만 본인은 2는 접해 보지 못했다.

Epyx에서는 역시 비슷한 시기인 1988년경엔 우리나라에서 개최된 서울 올림픽을 게임화한 The Games: Summer Edition을 내놓았다. 전편인 Summer Games도 있고 자매품인 The Games: Winter Edition까지 있으니 저 회사는 진짜 스포츠 게임 전문이었나 보다.

그런데 여느 작품과는 달리, 이 The Games: Summer Edition은 올림픽 개최국인 한국을 지도까지 곁들여서 굉장히 자세히 소개했다. 위의 애니메이션을 보시라. 한복에다 서울 남산 타워도 나온다. 이 정도면 저 제작사가 그냥 스스로 저렇게 만들지는 않았고 우리나라 정부로부터 협찬· 후원도 받았지 않았나 생각된다. 쟤들은 캘리포니아 하계 스포츠를 소개하는 게임을 만들면서도 1984년 LA 올림픽을 대놓고 홍보하는 게임을 만든 적은 내가 알기로 없다.

플레이 동영상에 나와 있듯이, 얘는 올림픽 스포츠 게임답게 평행봉, 다이빙, 기계 체조, 양궁, 장애물 넘기, 육상, 사이클까지 간단하지만 다양한 종목의 경기를 제공했다. 게다가 제한적이나마 1인칭 시점 3차원 애니메이션까지 제공하며 그래픽의 퀄리티가 높다. (지금으로부터 30여년 전의 게임이다!)

운동 선수가 하는 동작의 무엇을 컨트롤해서 무엇으로 승부를 가르고 재미를 만들지를 설계하는 건 쉬운 일이 아니었을 텐데 그 당시 이 게임을 만든 개발자들은 굉장히 똑똑한 사람들이었음이 틀림없다. 허나, 정작 본인은 우리나라를 소개하는 이 게임은 어렸을 때 접해 보지 못했다.

그 다음, 마지막으로 소개하고자 하는 종합 스포츠 게임은.. 위의 것들과는 달리 '동계' 스포츠 담당이다. 바로 Ski or Die. 제목이 참 아찔하다.

본인은 Ski or Die와 캘리포니아 게임즈가 성격이 비슷하다고 생각해 왔다. 하지만 Ski or Die는 Epyx 사의 작품이 아니다. 그 이름도 유명한 Electronic Arts에서 개발했다고 나온다. 다만, 신기술의 도입이 늦었는지 1990년작임에도 불구하고 VGA를 지원하지 않고 여전히 16컬러인 것은 좀 아쉬운 점이다.

얘는 메뉴를 고르는 게 아니라 주인공의 스키를 조종해서 원하는 경기를 선택하는 형태로 진행된다. 스키, 보드 또는 튜브를 타고 슬로프를 내려가는 건 기본이며, 스키 점프 묘기에다 심지어 눈싸움도 있다. 눈싸움은.. 뭐랄까 SEGA 시노비에서 한 레벨을 깬 뒤에 등장하는 보너스 게임과 비슷한 스타일 같다. (돌아다니는 자객들을 전부 표창 던져서 맞히는 거)

캘리포니아 게임즈에서 자전거나 스케이트를 타고 이동하는 게임은 다 횡(가로) 스크롤이지만, Ski or Die에서 스키를 타고 이동하는 게임은 다 종(세로) 스크롤이라는 차이가 있다.

Posted by 사무엘

1.
예전에도 한번 이런 비유를 꺼낸 적이 있었는데.. 라면을 소프트웨어 플랫폼에다 비유하자면 봉지 라면은 PC, 사발면은 태블릿, 컵라면은 스마트폰 정도에 대응하는 것 같다. 그래서 한 플랫폼에서 잘나가던 라면이 다른 플랫폼으로 종종 포팅되곤 한다(카카오톡 PC 버전, 오피스 안드로이드 버전처럼). 비록 둘이 맛이 완전히 동일하지는 않지만 말이다.

식당에서 주문해서 먹는 라면은 집 밖의 거대한 다른 가게에 들어가서(서버 접속) 먹는 것이니 서버 사이드 웹 애플리케이션일 것이며..
분식점 같은 식당 납품을 목적으로 라면 제조사가 면이나 스프만을 대량으로 따로 파는 건 '엔진' 같은 미들웨어 컴포넌트 내지 라이브러리에 대응한다고 볼 수 있겠다.

2.
스마트폰은 컴퓨터와 달리.. (1) 특별한 일이 없는 한 24시간 켜져 있고, (2) 열받고 뜨거워질지언정 그래도 팬 돌아가는 소리가 안 나고, (3) 보조 기억장치가 있지만 하드디스크 돌아가는 것 같은 소리는 전혀 없다.
그래서 (2)와 (3)을 종합하면 스마트폰은 아주 조용하다. 게다가 얇기까지 하다.
어찌 보면 세상에 어떻게 이런 컴퓨터가 존재 가능해졌는지 신기한 노릇이 아닐 수 없다. 그것도 화면은 옛날 구닥다리 액정 같은 단색이 아니라, 고해상도 천연색 그래픽을 찍어 낸다. CPU뿐만 아니라 디스플레이나 메모리까지 총체적으로 왕창 발전했기 때문에 스마트폰이 만들어질 수 있었다.

옛날에는 뭔가 영상이 표시되는 기계 자체가 굉장히 미래 하이테크의 상징이었다. 집 현관을 표시해 주는 인터폰이나 자동차 내비 같은 거 말이다.
텔레비전이나 컴퓨터 모니터는 아날로그 신호에 둥그런 브라운관 형태로나마 진작부터 천연색을 표현할 수 있었다. 하지만 들고 다닐 수 있는 소형 텔레비전이나 인터폰, CCTV 같은 건 원가 때문인지 무엇 때문인지, 의외로 흑백 버전이 2000년대까지 쓰였다. 본인은 몇 차례 이사를 다니며 집을 옮긴 적이 있지만, 컬러 화면이 나오는 인터폰 실물을 태어나서 지금까지 한 번도 구경을 못 해 봤다.

그런데 어느 샌가 갑자기 CCTV의 화질이 급격히 향상되고 차량들이 개나 소나 내비에 블랙박스까지 달고 다니면서 블랙박스에 찍힌 사고 영상만 모아서 보여 주는 TV 프로가 큰 인기를 모을 정도가 됐다. 사진과 동영상을 즉각 생성해서 남들 보는 사이버 공간에 용량과 트래픽 걱정 없이 올리는 게 너무 금방, 쉽게 가능해졌다. 이건 1980년대의 SF물들이 제대로 상상하지 못한 너무 엄청난 변화임이 틀림없다.

그리고 컴퓨터 자체도.. 이젠 스마트폰 내부에서 가상 머신을 돌려서 도스는 말할 것도 없고 과거의 Windows 9x를 구동할 수도 있게 됐다. 머리만 비교하면 스마트폰의 CPU가 일반 데스크톱 PC의 CPU와도 성능이 호각이 됐으며, 단지 PC에 비해 부족한 건 입력 장치와 하드디스크 정도밖에 없다고 한다. 발열이나 전원의 한계는 차치하고라도 말이다.

모바일 플랫폼이 등장하면서 PC에서 x86 계열 CPU + Windows 계열 운영체제를 총칭하는 '윈텔' 독점 구도도 상당 부분 흔들리게 됐다. 완전히 새로운 형태의 시장 수요를 창출해 냈으니까. x86은 30년을 넘게 거슬러 올라가는 유구한 하위 호환성을 자랑하지만, 그 때문에 저전력 모바일에서 빠릿빠릿 움직이는 용도로는 상당히 부적합한 CPU가 돼 버려서 말이다. Windows도 마찬가지다.

다만, 단순히 이미 만들어진 정보들을 받아 보기만 하는 인터넷 단말기 이상으로, 뭔가 글쓰기나 코딩 같은 생산적인 활동을 하기에는 스마트폰은 문자 입력이 너무 불편한 게 흠이다. 구닥다리 타자기의 인터페이스를 답습하고 있지만 그래도 문자 입력 분야에서 키보드만 한 가성비를 제공하는 물건은 아직까지 없다.

예전에 그나마 전화기 버튼이라도 있던 시절에는 3*4 배열이라는 틀은 고정돼 있었는데..
요즘 스마트폰은 화면의 절대적인 크기나 종횡비까지 전부 그냥 흰 도화지 수준인 거 같다. 인간에게 가장 적합한 글쇠 scheme은 어떤 형태일까? 블루 오션이다 보니 먼저 연구해서 표준 틀을 정착시키는 사람이 그냥 장땡이 돼서 혼자 다 해먹을 수 있을 것 같은 생각이 드는데.. 난 잘 모르겠다. 난 한글 입력 쪽은 글쇠배열이 아니라 일단은 근본 메커니즘 연구가 주 관심 분야인지라..

글쇠 수가 너무 많으면 안 그래도 작은 화면에 너무 작은 글쇠 버튼을 잘못 찍어서 오타를 내기 쉽고, 반대로 글쇠 수가 너무 적으면 타수가 늘어나고 이것저것 모드를 바꾸는 빈도가 잦아져서 그것대로 또 입력이 불편해진다.
구글 단모음을 한동안 써 보다가 불편해서 다시 나랏글로 돌아왔다. ㅎ, ㅔ 같은 자모를 한 번에 바로 입력할 수 있어서 편한 것보다, 오타가 나서 불편한 게 더 크게 느껴졌다. 개인적으로는 나랏글을 거의 2004년부터 10년 넘게 쓰기도 했고 말이다.

3.
스마트폰이 폭발적인 인기를 끌면서 오늘날과 같은 사진· 동영상 업로드 문화를 만들어 낸 건 두 말할 나위 없이 '디지털 카메라' 기능까지 전화기 안에 쏙 들어간 덕분에 가능했다.
오늘날 폰의 카메라가 단순 화소수와 색감만 따지자면 어지간한 보급형 디카의 성능을 다 따라잡고도 남는다. 하지만 폰 카메라가 전용 디지털 카메라를 결코 따라잡지 못하는 게 크게 둘 있는데, (1) 줌과 (2) 부팅 속도이다.

근본적으로 카메라의 형태로 적합하게 설계되지 않은 그 얇은 몸체에다 두꺼운 다기능 렌즈까지 우겨넣는 건 아무래도 무리다. 그렇기 때문에 폰 카메라는 줌 기능이 전문적인 카메라의 적수가 될 수 없다. 시야각도 한계를 받기 때문에 이걸 극복하려면 별도의 파노라마 합성 앱 같은 것의 도움을 받아야 한다.

또한 디지털 카메라는 사진을 찍을 때에만 잠시 켰다가 끄는 걸 스마트폰보다 훨씬 더 간편하게 할 수 있기 때문에 밖에서 사진을 몇백 장씩 산발적으로 찍을 일이 있을 때 전력 소모 부담이 훨씬 덜하다. 부팅도 아예 범용 컴퓨터인 스마트폰보다야 비교할 수 없이 더 빨리 되며, 전원을 켜자마자 거의 곧장 촬영 ready 상태가 된다. 그 반면 스마트폰은 이런 특성을 전혀 갖고 있지 못하다.

하긴, 피처폰이 스마트폰으로 바뀌고 스마트폰에 온갖 복잡 다양한 기능들이 추가될수록 사용자가 알게 모르게 치르는 대가로는 배터리 시간이라든가 폰의 물리적 내구성 같은 게 있다. 이와 비슷한 맥락에서 스마트폰도 켠 직후에 수 초 이내로 바로 쓸 수 있는 게 아니라, PC에 준하는 급의 부팅이 필요하고 엄청난 양의 초기화와 캐싱, pre-fetching을 해 줘야 쓸 수 있는 물건이 되고 있다. 예전에 PDA나 공학용 계산기가 그렇게 부팅 시간이 긴 물건은 아니었으니 말이다. 부팅이 존재하고 악성 코드 걱정을 해야 하는 기기는 다른 전자 기기와는 성격이 근본적으로 다르며 훨씬 더 능동적인 물건이다.

한때는 이런 작은 화면에 찍히는 글자는 초간단 비트맵 글꼴 기반인 게 당연시되었는데 그게 힌팅까지 적용된 미려한 윤곽선 글꼴로 바뀌었다는 것 하나만으로도 소프트웨어적으로는 예전에 비해 그야말로 엄청난 부담이 추가된 거나 다름없다. 윤곽선 글꼴은 캐싱 없이는 도저히 쓸 물건이 못 되며, 캐싱이라는 건 굉장한 양의 메모리를 요구하기 때문이다.

오늘날 컴퓨터 프로그램들이 같은 일을 해도 예전보다 메모리와 CPU를 훨씬 더 많이 요구하는 이유는 유지 관리 차원에서의 범용성과 추상성을 높인 대신에 오버헤드가 더 커지고 성능 희생을 감수한 게 매우 크게 작용한다(가상 머신, 가상 함수, 등등등등). 스마트폰의 전력 소비나 부팅 속도도 그런 맥락에서 살펴볼 수 있을 듯하다.

Posted by 사무엘

1. 들어가는 말

오늘날의 거대하고 복잡한 운영체제와는 달리, 도스는 이니셜 D-_-가 암시하듯이 달랑 플로피디스크 한 장만으로 부팅이 가능할 정도로 참을 수 없이 작고 가벼웠다. 정말 필수불가결인 파일은 부팅에 쓰이는 io.sys, 그 뒤 셸 역할을 하는 텍스트 명령 해석기인 command.com이 전부다.
msdos.sys라는 파일도 있는데 얘는 정확하게 무슨 존재인지 모르겠다.

그리고 사실은 config.sys의 DEVICE 명령을 통해 실행되는 sys 파일과, com 실행 파일이 서로 무슨 차이가 있는지도 모르겠다. 마우스, 그래픽 카드 에뮬(simcga, msherc ^^), 사운드(sound, unsound) 같은 여러 램 상주 드라이버들은 com이었지만, 씨디롬 드라이브는 sys였으며 그것도 주 메모리를 꽤 많이 차지하는 드라이버였다. 단, 부팅 후에 sys 파일을 별도로 실행해 주는 유틸리티가 있기도 했다.

디스크로부터 파일을 읽으려면 파일 시스템이 정립돼 있어야 하며, 이건 운영체제가 하는 일 중 하나이다. 그런데 그 운영체제를 로딩하는 프로그램도 파일 형태로 저장돼 있다. 이런 '닭이 먼저냐 계란이 먼저냐' 딜레마를 해소하기 위해서는, 부팅에 쓰이는 운영체제 프로그램은 디스크에 단순히 파일 형태로만 존재하는 게 아니라, 컴퓨터 바이오스가 물리적이고 원초적으로 인식 가능한 첫 지점에 저장돼 있어야 한다. 이건 굳이 도스뿐만 아니라 어느 운영체제라도 마찬가지이다.

도스는 단일 사용자 단일 프로그램 구동 체계이다 보니, 한 프로그램이 그야말로 컴퓨터 하드웨어를 전부 있는 그대로 조종 가능하게 허용하는 백지수표, 열린 허허벌판 같은 환경이었다. 프로그램의 인터페이스도 명령 기반, TUI, GUI 등 제각각이었고 정말 창의적이었다. 요즘 프로그램들만치 UI가 획일화됐다는 느낌이 없이 형형색색 컬러풀했다.

물론 그건 거시적인 관점에서는 그리 효율적이지 못하다. 이런 빵빵한 컴퓨터 자원에서 여러 프로그램을 동시에 실행하고 작업 전환을 할 수 없다면 그것도 컴퓨터에 대한 예의-_-가 아니다.
그러니 운영체제가 더 강력하게 모든 걸 통제하는 지금 같은 환경으로 궁극적으로는 바뀌는 게 맞긴 하지만.. 인제 와서 도스가 다시 새삼스럽게 그리워질 때도 있다.

2. 역사

본인이 경험한 MS-DOS의 가장 옛날 버전은 학교 내지 컴퓨터 학원에서 봤던 3.2/3.3이다. 2.x 이하나 4는 실물로 구경을 못 해 봤다. 다만, 5.0과 6.2는 집 컴퓨터에 내장돼 있던 물건이다 보니 개인적으로 친숙하다.

1981년에 첫 출시되었다고 전해지는 MS-DOS 1.0은 그야말로 정말 골동품 폐물이었다고 한다. 그리고 Windows 1.0이 프로그램 창을 겹치게 배열하는 걸 지원하지 않았다면, DOS 1.0은 디스크에 서브디렉터리를 만드는 걸 지원하지 않았다..;;
그나마 도스가 최소한의 도스다운 틀을 갖춘 건 2를 거쳐서 3.x대에 와서부터이다. 특히 5.25내지 3.5인치 고밀도(1.2, 1.44MB) 플로피디스크를 지원하기 시작한 첫 버전이 이 버전이기 때문이다. 3.x에 와서야 좀 물건다운 물건이 나왔다는 점에서는 도스와 Windows가 역사가 서로 비슷한 것 같다.

그 다음 4.0의 아주 기념비적인 업적은 파일 시스템이 FAT12에서 FAT16으로 확장되어, 이론적으로 지원 가능한 디스크 볼륨의 용량이 2GB로 커진 것이다.
그 시절에 기가바이트는 가히 꿈의 규모였기 때문에 홍보 자료에서는 그냥 '제한이 없어졌다'라는 표현이 관용적으로 쓰였다. 참고로, FAT12 시절의 하드디스크의 용량 한계는.. 고작 32MB였다. =_=;;

또한 MS-DOS shell이라고 나름 드래그 드롭도 지원하고 Windows GUI를 어설프게 베낀 듯한 파일 관리자 셸이 추가된 것도 4부터이다. 하지만 MS-DOS 4는 구체적인 내역은 모르겠지만 불안정하고 버그가 많아서 좀 문제작으로 남았다고 한다.

도스 5.0에서 기념비적인 업적은 그 이름도 유명한 HIMEM.SYS와 DOS=HIGH일 것이다. EMM386은 4.0 때 SYS 버전이 있었지만 5.0부터는 EXE로 형태가 바뀌었다고 한다.
또한 이 버전에서는 과거의 불편하던 EDLIN을 대체하는 QBASIC 기반의 텍스트 에디터가 추가되었으며, 명령 프롬프트에서 cursor 이동을 자유롭게 할 수 있게 하고 히스토리 기능도 넣어 주는 DOSKEY 유틸도 이때 추가됐다.

지워진 파일을 첫 글자 이름을 집어넣어서 복구하는 undelete 역시 아마 6이 아닌 5에서 첫 추가됐지 싶다. 이건 PC-tools나 노턴 유틸리티가 먼저 제공하던 꼼수 기능이었는데 동일 기능을 도스에서 직접 수용한 것이다.

그 뒤 6.0은.. 변한 게 많았다.
가장 유명한 건 하드 디스크를 압축해 주는 '더블 스페이스'라는 유틸리티의 도입이다.
이건 무슨 요술을 부리거나 하드 디스크를 물리적으로 어떻게 하는 게 아니라, 그냥 파일 시스템 차원에서 데이터를 zip 같은 소프트웨어 압축을 적용하는 것일 뿐이다. 당장 용량 확보에는 도움이 되지만 디스크의 액세스 속도가 좀 느려지고 에러에 취약해지며, 하드웨어를 좀 험하게 다루는 일부 프로그램과는 트러블의 여지가 생긴다.

참고로 1993~1994년이면 Windows 3.1이 보급되고 어지간한 PC의 하드디스크는 몇백 MB 정도이던 시절이다.
더블 스페이스는 그렇잖아도 꽤 중요하고 민감한 간판 기능인데, 버그를 많이 잡고 안정화를 더 시켜서 6.2가 나왔다.
그런데 이게 '스태커'라는 타사의 제품을 무단 도용한 것으로 판결이 나서 '더블 스페이스'를 뺀 6.21이 나왔고, 저작권 문제를 해결하여 '드라이브 스페이스'를 대신 도입한 6.22로 6.x대가 마무리 되었다. 지금이야 마소에 대해서 IE 브라우저의 독점 소송이 유명하지만, 1990년대 중반엔 저거 저작권 침해 소송이 IT 업계에서 굉장한 화두였다.

압축 유틸리티 말고도 6.x대엔 멀티 부팅이라는 매우 유용한 기능이 추가됐다. 즉, C/C++의 조건부 컴파일처럼 사용자가 선택한 옵션 방식대로 디바이스 드라이버를 로딩하여 부팅할 수 있게 됐다는 것이다.
그리고 디스크 점검 scandisk, 조각 모음 defrag, 시스템 점검 msd, 주 메모리 확보 유틸리티 memmaker 등이 추가되고 PC-Tools로부터 라이선스 받은 안티바이러스 msav 같은 유틸도 도입됐다. 덕분에 노턴 유틸리티가 예전보다는 좀 덜 필요해졌다.

모든 내부/외부 명령에 /? 옵션을 줬을 때 도움말이 나오는 것도 처음부터 존재한 게 아니었다. 6이거나 아니면 5부터인데 그건 정확하게 기억이 안 난다. 옛날에는 도움말 텍스트를 일일이 내장시켜 줄 정도로 컴퓨터의 메모리나 디스크 용량이 충분하지 못했기 때문이다.

단독 제품으로서 MS-DOS의 역사는 1994년에 출시된 6.22가 끝이었다. 도스는 Windows 95/98/ME와 함께 7.0. 7.1. 8.0 버전으로 명맥을 유지하다가 2000년에 드디어 20여 년의 긴 수명을 마치고 역사 속으로 사라졌다.
도스 외부 명령어 중에서 몇몇 필요한 건 Windows 9x 계열에서는 Windows\command로 갔고, NT 계열은 그냥 system32 디렉터리에 있다. 그리고 NT 계열은 format이나 diskcopy 같은 유틸리티도 콘솔에서 실행될지언정 도스가 아니라 Windows용 프로그램이라는 차이가 있다.

3. 그 당시의 유사품/경쟁자

한편, 도스의 바리에이션으로는..
PC-DOS는 그냥 MS-DOS가 IBM 브랜드만 달고 나온 동일 제품이었다고 한다. 한동안 그러다가 6.x대부터는 서로 다른 길을 가기 시작했는데 이미 그때는 PC 환경이 Windows로 충분히 넘어가기 시작했으니 별 의미는 없다. 따지고 보면 IBM은 OS/2가 망한 데다, 도스 분야도 뒷북으로 끝나고 별 재미를 못 본 셈이다. "IBM 호환 PC"라는 걸출한 대인배 이름만 남긴 채 PC 시장에서는 철수했다.

DR-DOS는 MS-DOS의 전신인 CP/M을 직접 만든 게리 킬달이라는 엔지니어가 '디지털 리서치'라는 회사를 세워서 따로 만든 MS-DOS의 대항마이다. '디알'이지 '닥터 도스'는 아님.. 뭔가 기능이 MS-DOS보다 뛰어났다고 얘기는 들었는데 구체적인 내역은 잊어버려서 기억이 안 난다.
DR-DOS를 '노벨' 사가 인수하여 새로 내놓은 것이 '노벨 도스'이며, 이건 1990년대 초중반까지 나왔다.

한편, 4DOS는 커널을 처음부터 새로 만드는 건 아니고 명령 인터프리터인 COMMAND.COM만 대체하는 기능 확장판으로 컴덕들에게 많이 알려져 있었다. 이걸 시먼텍(Symantec) 사에서 인수하여 자신들이 인수한 다른 유명 솔루션인 '노턴 유틸리티'에다가 집어넣은 것이 NDOS이다. 각종 도스 명령들에서 2% 부족하던 것을 보완하는 편의 기능이 굉장히 많았던 걸로 기억한다. (가령, 중간에 파일이 사라져도 괜찮은 batch-to-memory 배치 파일)

그리고 8.3 짧은 파일 이름의 한계를 보완하기 위해, 내부적으로 descript.ion이라는 숨김 파일을 만들어서 파일명에 대한 '주석'을 표시하는 것도 4DOS의 작품이었다. 옛날에 MDIR도 이걸 지원했다. 파일이 복사· 이동· 개명· 삭제됐을 때 주석도 같이 관리하는 게 좀 번거로운 일이 됐으니까.. NTFS처럼 운영체제의 파일 시스템 차원에서 메타데이터를 관리하는 기능이 없으면 어쩔 수 없이 셸 유틸리티가 뒷감당을 해야 한다.

4. MS-DOS의 한글화

MS-DOS가 최초로 한글판이 나온 것도 2나 3 버전부터이지 싶다. 정말 먼 옛날에는 마소가 잠깐 동안 조합형 코드 기반으로 도스를 한글화화기도 했다는데 지금으로서는 거의 Windows 2.1의 한글판 같은 도시전설이 돼 간다.
허나, 1987년에 지금의 KS X 1001, 그 당시의 KS C 5601 완성형이 제정되자마자 표준을 잘 지키는 마소는 완성형으로 광속으로 갈아탔다. 그게 이미 도스 3 시절의 일이다. 마소는 그냥 표준을 따른 것일 뿐이지만, 결과적으로 조합형 코드를 죽이고 한글을 파괴한 원흉(?)으로 일부 진영으로부터 좀 지탄받곤 했다.

그런데 한글 MS-DOS가 텍스트 모드에서 한글 입출력을 구동해 주는 바이오스 유틸리티를 처음부터 내장하고 있지는 않았던 것 같다. 쉽게 말해 hbios와 그 특유의 바탕체 글꼴을 구경한 건 최소한 도스 5나 6부터이다. 3이나 4 시절에나 그런 게 없었으며, 한글 바이오스는 다른 프로그램으로 구동했었다. 이건 내 기억이 잘못됐을 수도 있음.

hbios는 Windows 95로 가면서 mshbios로 이름이 바뀌었으며, 그 당시의 고유 글꼴은 <날개셋> 편집기에 '마소바탕'이라는 글꼴을 통해 구경할 수 있다. 도깨비나 태백한글 같은 싸제 한글 바이오스들은 조합형/완성형, 두벌식/세벌식, 명조/고딕 등 글꼴과 글자판과 코드를 다 선택 가능했지만, 마소의 보급 바이오스는 당연히 완성형, 두벌식, 명조로 다른 선택의 여지가 없었다.

전에도 한번 얘기한 적이 있었지만, 마소에서 한글화한 프로그램들은 2바이트 문자에 대한 처리가 굉장히 잘 돼 있었다. 2바이트를 구성하는 앞뒤 문자 중 하나가 가려지거나 지워지면 다른쪽 문자도 반드시 같이 사라졌기 때문에 텍스트 모드에서 메뉴나 대화상자가 표시될 때도 문자가 깨지는 걸 보이는 법이 없었다. 이에 대한 처리가 세심하게 돼 있었다.

5. 도스 시절의 멀티태스킹

비록 그래픽은 아니고 텍스트 기반이긴 하지만, Windows 3.x 비스무리한 도스 기반 멀티태스킹 운영환경(운영체제는 아니고..)으로 DESQView 같은 프로그램이 있었다. 난 이름만 들어 보고 실제로 구경은 못 했다. 외국에서는 그럭저럭 쓰는 사람이 있었던 듯하지만 Windows의 등장 이후에는 조용히 역사 속으로 사라졌다.

그리고 사실은 더 발전된 멀티태스킹 운영체제를 마소에서 직접, 그것도 Windows나 OS/2와는 별개로 만들려는 시도를 한 적이 있었다. 무려 1986년, Windows조차 이제 막 개 허접한 1.0이 나왔던 시절에 MS-DOS 3을 기반으로 일명 '멀티태스킹 MS-DOS 4.0'이 계획되었던 것이다. 이것은 앞서 언급한 그 도스 4.0과는 무관한 새로운 개발 브랜치였다.

멀티태스킹 MS-DOS 4는 제품이 나오기는 했고 의도도 나쁘지 않았지만, 1980년대 중반에 시대를 너무 앞서간 문제작이었다. 그 옛날에 그 열악한 하드웨어 환경에서 도대체 뭘 더 바라겠는가? 컨셉에 비해 상품성이 떨어졌다.
게다가 그 당시 마소는 지금처럼 독자적인 불특정 다수용 유명 소프트웨어를 독점 판매하는 공룡 기업이 아니었으며, 여전히 하드웨어 제조사에다 소프트웨어를 납품하면서 먹고 사는 기업이었다. 즉, 지금으로서는 상상이 잘 안 되지만, 업계에서의 위상이 '갑'이 아니라 '을'이었다.
프로젝트를 발주했던 IBM이 이 물건을 더 구입해서 사용하지 않겠다고 선언하자 프로젝트는 흑역사가 되었고, 이 멀티태스킹 MS-DOS 4는 오히려 유럽의 일부 컴퓨터에 OEM 형태로 공급되는 걸로 개발 계보가 끝났다.

멀티태스킹 MS-DOS 4는 비록 GUI 환경은 아니지만 Windows의 전유물로만 알려졌던 NE (new executable) 실행 파일도 지원하고 지금으로서는 무척 신기한 면모가 많았다고 한다. 정작 NE를 사용하던 Windows는 NT가 등장하기 전에는 콘솔 모드라는 게 없었는데, GUI 기반이 아니던 멀티태스킹 도스가 NE를 어떤 형태로 사용했는지 궁금하다.

6. 맺는 말

도스 시절에 메모리 관리를 하는 건 요즘으로 치면 연봉별로 돈 관리하는 요령과 비슷했다. 램이 1MB 이하일 때, 2MB일 때, 4MB일 때, 8MB 이상일 때... HIMEM.SYS와 EMM386을 세팅하는 법, 기본 메모리를 최대한 확보하는 법, 메모리가 왕창 많이 있다면 램 드라이브와 디스크 캐시를 운용하는 요령 등.. 그런 게 1990년대 컴퓨터 잡지들이 고급 정보랍시고 많이 다룬 정보였다.
지금으로서는 그저 격세지감이 느껴질 뿐이다. 그 당시에 기본 메모리라는 개념은 돈에다 비유하자면 당장 손에 있는 현금이고, 나머지 확장 메모리는 통장 잔고나 신용카드 같다는 생각도 든다. =_=;;

MS-DOS의 역사를 살펴보면 많은 걸 느낀다. 금수저 출신의 독종에 천재에 똘끼와 운, 엔지니어 기질과 사업가 기질을 모두 갖고 있는 사람이라면 무슨 여건에다 던져 놔도 결국은 성공했겠다 싶다. 공부만 계속했어도 교수나 변호사가 됐을 사람이 결국은 소프트웨어의 황제로 등극해서 교수· 변호사보다 더한 억만장자가 됐으니까.

물론 빌 역시 그 과정에서 언제나 실력만으로 정정당당하게 승부하지는 않았으며, 경쟁자 치사하게 죽이기 같은 짓을 전혀 안 했다는 건 아니다. MS의 모든 기술과 제품이 100% 빌의 머리에서 비롯된 원천기술인 건 아니며, 그가 미래에 대해 예측한 것이 전부 적중한 것도 아니었다. 그래도 그는 자기보다 더 똑똑한 엔지니어들을 한데 통솔하고 이끌어서 시너지 효과를 잘 낼 줄을 알았다. 그리고 실수를 하고 병크를 저지르더라도, 회사를 완전히 말아먹을 정도로 치명적으로 하지는 않았으며 곧 수습했다.

한편, 게리 킬달은 뭔가 스티브 워즈니악 같은 포스가 느껴지는 공돌이로 보이는데, 실력에 "비해" 빛을 못 보고 좀 어이없게 훅 가 버린 게 안타깝게 느껴지기도 한다.
기술만 있고 너무 고지식하기만 하면 저렇게 되기 쉬운데, 나부터가 딱 그런 스타일이라는 게 문제임.. -_-;;

Posted by 사무엘

오늘날이야 우리들의 눈을 현혹하는 온갖 사진과 짤방, 동영상들이 인터넷을 통해 컴퓨터로 현기증 날 정도로 범람하고 터져 나가는 시대이다.
하지만 불과 2~30년 전만 해도 PC는 글이 아닌 그림을 처리하기에는 용량과 성능이 꽤 버거운 물건이었다. 컴퓨터로 뭔가 실사 사진 자체를 구해다 보기가 쉽지 않았다. PC 통신으로 인기 연예인 사진을 단 한 장 다운로드 해서 보는 것조차도 단단히 작정하고 기다릴 준비를 하고서 해야 했다. 그리고 그것도 출처는 종이 화보나 필름 사진 스캔, 또는 아날로그 TV 화면 캡처였다..

21세기에 태어난 애들이 이런 얘기를 듣는 건.. 우리 세대가 부모님에게서 1950, 60년대에 나라가 얼마나 폐허였고 못살았는지를 듣는 것과 비슷한 느낌일 것이다. 아아~ 나도 이런 식으로 올드 타이머 꼰대의 대열에 합류하는구나..;;
그래도 난 옛날 컴퓨터 환경 회상이 좋다. 그러니 얘기를 계속하겠다.

그 시절엔 bmp, pcx를 넘어 gif 정도만 돼도 디코딩이 만만한 작업이 아니었다. 아래아한글 도스용에서 그림을 삽입해 보면 gif는 유독 렌더링이 더뎠다. 그런데 하물며 jpg는... 전용 뷰어가 필요하고 386에 램 얼마 이상, 부동소수점 코프로세서는 필수 이런 걸 요구하는 엄청난 포맷이었다. png 역시 그 당시로서는 신생인 만만찮게 무거운 포맷이었고.

이런 이유로 인해 도스에서 그래픽 뷰어는 나름 단순 텍스트/헥스 뷰어 이상의 유니크함과 전문성(?)을 지녔고 또 그래픽 에디터와는 별개의 입지를 가진 프로그램이었다. GUI 운영체제의 셸이 제공하는 기본 중의 기본, 필수 중의 필수 기능이 그때는 그렇게나 특별한 기능이었다. 도스까지 갈 것도 없이 무려 Windows 95 시절, 웹 브라우저 같은 게 없던 때엔 운영체제 차원에서 jpg 파일을 바로 볼 수 있지 않았다. 그림판은 bmp/pcx 전용이었으니까.;;

그래픽 뷰어는 완전 상업용 제품이라기보다는 셰어웨어로 만들기에 좋은 소재였다. 디렉터리 이동 + 파일 리스트 선택 기능을 구현한 뒤, 사용자가 엔터를 누르면 그 그림을 표시해 주는 게 기본 형태이다.
그런데 그것만으로는 좀 단조로우니 그래픽 뷰어에는 여러 장의 그림을 슬라이드 쇼처럼 보여주는 기능이 응당 추가됐다. 현란한 화면 전환 효과는 덤이고. 요즘 같으면 화면 보호기와 역할이 비슷해졌다.

비주얼 쪽 말고 다른 방면으로는.. 파일 관리 기능이 있다는 점에 착안하여 단순히 뷰어 이상으로 많은 그림 파일들을 일괄적으로 포맷을 변환하고 크기를 보정하고 효과를 주는 기능이 들어갔다. 이건 전문적인 그래픽 에디터와도 기능이 겹치는 구석이 있지만, 이쪽은 드로잉 기능이 없으며 한 파일이 아니라 여러 파일들에 대한 일괄 편집에 더 최적화되었다.
이런 분야에 속하는 프로그램으로 본인은 현재까지 다음과 같은 제품들을 기억하고 있다.

1. Graphic Workshop

모 컴퓨터 잡지/서적을 통해 알게 됐다. 1990년대 초인 꽤 옛날부터 개발되어 온 프로그램이며, 내 기억이 맞다면 GIF를 굉장히 일찍부터 지원해 온 걸로 유명했다.
스크린샷을 보면 알 수 있듯, 전반적으로 셸은 파란 배경의 단순한 텍스트 모드에서 동작했고 단순 표시뿐만 아니라 포맷 변환, 크기 조절 같은 그림 파일 관리 기능도 갖추고 있었다.

1989년에 처음 개발됐는데 91년에 벌써 버전이 6을 넘어간 건 도대체 개발과 버전업이 어떻게 돼 왔다는 뜻인지 모르겠다. MS Word는 다른 제품과 번호를 맞추기 위해서 2에서 바로 6으로 넘어가긴 했다만..;;
개발사인 Alchemy Mindworks라는 회사는 지금도 살아 있으며, 이 프로그램은 Windows용으로 계속 개발 중이다.

2. SEA

그래픽 뷰어 중에서는 느낌이 굉장히 인상적이었다. 일단, 왓콤 C/C++ 32비트 에디션으로 만들어진 덕분에, 게임도 아닌 것이 첫 실행 때 DOS/4GW(도스 익스텐더) 로고가 떴다.
성능면에서는 jpg 파일의 디코딩이 경쟁 프로그램들 중 가장 빠르다고 자처했다. 그림뿐만 아니라 소리 파일 재생이 됐으며, 동영상도 AVI 중에 1990년대 중반 런렝쓰 정도의 간단한 방식으로 압축 된 건 바로 재생 가능했다.

스크린샷을 보면 알 수 있듯 일괄 변환과 슬라이드 쇼 기능 정도는 물론 갖추고 있었으며,
이 모든 것에 더해서 전반적인 GUI 껍데기도 NextStep 운영체제를 흉내 낸 듯한(바탕에 검정 제목 표시줄) 상당한 고퀄이었다.
여러 모로 인상이 좋고 장인 정신이 느껴지는 잘 만든 프로그램이었다. 비등록 셰어웨어 버전도 첫 실행 때 '등록 해 주세요. press any key'가 뜨는 것 말고는 별다른 제약이 없어서 상당한 대인배이기까지 했다.

3. ACDSee

운영체제에 gif/jpg/png급 그림 파일을 보는 기능이 자체적으로 없던 Windows 95~98/2000 시절에는 개인적으로 이 프로그램을 유용하게 썼다. 이름이 똑같이 '씨'인데 앞의 도스용 프로그램은 sea이고 요 프로그램은 see이다.
얘도 한때는 내가 운영체제를 새로 설치한 뒤에 MDIR만큼이나 곧장 설치하는 필수 프로그램 중 하나였다. 굉장히 유용하게 썼다. SEA의 Windows 버전이나 마찬가지였는데, 해당 기능을 운영체제가 흡수한 뒤에는 정말 자연스럽게 존재감이 싹 없어져 버렸다.

그 첫 신호탄은 Windows에 IE 웹브라우저가 포함돼 들어가면서 기본적인 그래픽 뷰어 문제는 사실상 제공되기 시작한 사건이다. 월드 와이드 웹이라는 게 글과 그림으로 이뤄져 있으며 웹브라우저는 그 자체가 훌륭한 단백질 공급원은 아니고 훌륭한 그래픽 뷰어였기 때문이다. 단, IE는 옆 파일을 바로 열람하는 기능조차 없고 진짜 보는 것 하나만 가능하기 때문에 전문 뷰어/슬라이드 쇼 프로그램이 여전히 존재 의미가 있었다.

한 디렉터리 안에 있는 그림 파일들을 IE 창에서 쭈욱 열람하기 위해서 그 디렉터리를 기준으로 <img src="...."/> 태그를 쭈욱 나열하는 html 파일을 '생성하는 프로그램'을 짜서 개인적으로 활용했던 기억이 있다. 물론 이건 썸네일만 읽어들이는 게 아니라 파일들을 몽땅 한 페이지에다 읽어들이는 것이니 성능면에서는 좀 안습한 짓이긴 하다.

그리고 둘째 확인사살은 Windows XP이다. 얘부터는 탐색기 내부의 파일 리스트에서 그림 썸네일을 보는 편의 기능이 크게 강화되었으며, 그럭저럭 가볍고 괜찮은  그래픽 뷰어까지 내장됐기 때문이다. 그러니 별도의 싸제 그래픽 뷰어 프로그램에 대한 필요는 거의 사라졌다. 이런 이유로 인해 기존의 그래픽 뷰어들은 생존을 위해서 포토샵 같은 이미지 보정 기능을 더 강화한다거나 디지털 카메라 사진 관리 같은 더 차별화되고 전문적인 영역으로 넘어갔으며, 내 기억 속에는 현업에서 다들 물러나고 추억의 영역만 남게 되었다.

한때는 Paint Shop Pro에 내장돼 있는 Browse 기능도 유용하게 썼던 것 같은데 지금은 그냥 MS Office에서도 2003부터 Picture Manager라는 유틸리티가 생겨 있다. 예전에는 희귀했던 기능들이 지금은 다 기본으로 내장되고 대중화가 된 것이다.
단, Windows XP의 기본 그래픽 뷰어는 애니메이션 GIF를 재생하는 것까지도 지원했는데 Vista 이후부터는 그 기능은 없어졌다. 왜 빠졌는지는 알 길이 없다.

여기까지가 그래픽 뷰어 프로그램에 대해 본인이 갖고 있는 추억이다.
하긴, 음악을 듣는 것도 한때 꽤 먼 옛날엔 거원 제트오디오, WinAmp 같은 프로그램을 따로 썼다. 그러다 언제부턴가 그냥 WMP만 쓰지 다른 건 안 쓰게 됐다.
그래도 동영상은 WMP가 코덱과 자막 등 부족한 구석이 많이 있어서 팟/곰 같은 제3자 프로그램이 여전히 살아 있다. 내가 알기로 마소에서 WMP도 거의 IE11만큼이나 이제 더 만들 게 없는지 별로 육성은 안 하는 것 같다.

Posted by 사무엘

텍스트를 입력· 편집하는 기능을 제공하는 에디터나 개발툴, 워드 프로세서에는 응당 텍스트를 검색하는 기능이 있다.
찾기 명령은 아무래도 바꾸기 명령과도 같이 쓰이는 경우가 많으니 이건 편집 기능의 일종으로 간주되며, 보통은 '편집' 메뉴의 하위 항목으로 들어가는 편이다.
그러나 편집 메뉴가 이미 다른 기능들로 너무 비대한 상태이거나, cursor를 원하는 조건대로 이동시키는 찾기/탐색 기능이 별도로 굉장히 전문적으로 발달해 있는 경우, '검색(Search)'이라는 메뉴가 따로 존재하기도 한다.

이 메뉴 구성은 프로그램들마다 제각각이다.
과거에 아래아한글은 1.x대까지 '찾기' 메뉴가 별도로 있다가 2.1부터 '편집'으로 들어갔다. 전반적으로 기능들이 메뉴에 많이 추가되면서 두 메뉴의 인수 합병에 정당성이 생긴 것이다.
Windows의 메모장은 9x 계열의 것은 '찾기' 메뉴가 존재하는 반면, 2000/XP의 것은 그렇지 않고 '편집' 메뉴에 있다.

<날개셋> 편집기는 1~2.x대까지는 찾기 기능이 '편집' 메뉴에 있었지만, 3.0부터는 별도의 '검색' 메뉴로 분리되어 지금에 이르고 있다. 검색과 관련된 기능들을 전부 편집에다가 몰아 넣으면 보기, 삽입, 도구 같은 다른 메뉴들에 비해 '편집'만 항목 수가 너무 많고 비대해지기 때문이다.
그렇다고 <날개셋> 편집기가 무슨 메모장만치 그렇게 기능이 적은 초소형 프로그램도 아니니.. 양 극단 사이에서의 고민 끝에 지금과 같은 메뉴 배치를 선택했다.

한편, 내 편집기에는 없지만 좀 기능깨나 있다 싶은 텍스트 에디터들은 Find in files 기능이 필수이다. 그런데 알고 보면 얘의 정체성도 약간 오락가락 하는 편이다.
아래아한글은 2.0에서 이 기능이 최초로 추가된 이래로 요게 '파일' 메뉴에 쭉 있어 왔으며, Visual C++ IDE도 옛날 버전에는 한동안 파일 메뉴에 있었다. 아무래도 한 문서를 편집한다기보다는 inter-file스러운 기능이라고 생각하고 그렇게 '파일'에다 분류했던 듯하다.

하지만 Visual C++의 경우 6인가 닷넷 이후부터 이 기능은 '편집' 메뉴로 이동했으며, IDE의 버전이 올라갈수록 요건 기존 '찾기' 기능의 자연스러운 연장선 형태로 인터페이스가 바뀌어 왔다는 게 주목할 점이다.
물론 '검색' 메뉴가 별도로 있는 에디터라면 Find in files는 응당 파일도 편집도 아닌 그 메뉴에 자리잡고 있다.

프로그램의 전반적인 옵션을 지정하는 명령이 요즘은 도구 메뉴의 맨 마지막에 있는 게 대세이지만, 한때는 preference라는 이름으로 파일 메뉴에 있기도 하고 Adobe Reader처럼 아예 편집 메뉴의 있기도 한 것과 비슷한 모습을 보는 것 같다. 옛날에는 역시 '옵션'이라는 메뉴가 별도로 있기도 했지만 프로퍼티 시트의 등장으로 인해 한 대화상자에서 엄청 많은 옵션들을 죄다 몰아서 지정하는 게 트렌드가 되면서 옵션만을 위한 메뉴는 요즘 UI 트렌드에서는 사라지는 추세이다.

끝으로, 이 검색 메뉴가 존재한다면 그 위치가 어디쯤인지를 살펴보고자 한다. 파일이야 맨 먼저 등장하는 것이 불문율이지만, '보기', '삽입(입력)' 같은 다른 메뉴와 비교했을 때 상대적인 순서가 어떻게 될까?
앞서 말했듯이 찾기 기능은 편집과 밀접한 관계가 있기 때문에 아무래도 편집 메뉴의 바로 다음에 오는 것이 가장 자연스러워 보인다.

그래서 실제로 검색 메뉴가 따로 존재하는 많은 프로그램들은 "파일-편집-검색-(보기)"의 순으로 메뉴가 구성되어 있다. NotePad++, Source Insight, 그리고 도스와 Windows용을 막론하고 볼랜드 IDE (Borland C++, C++Builder, 델파이), AcroEdit 등.

그런데 <날개셋> 편집기는 "파일-편집-보기-검색"으로, View 메뉴가 더 앞에 있다. 검색 메뉴가 처음으로 추가되었던 3.0 초창기 시절에는 "검색-보기"이었는데 나중에 모종의 이유로 인해 "보기-검색"으로 바뀌었다.
"검색-보기"가 적힌 과거의 흔적은 까마득히 먼 옛 버전을 기준으로 만들어진 프로그램 스크린샷 움짤들을 보면 확인할 수 있다.

"보기-검색"으로 순서를 바꾼 이유는 아마 본인이 옛날에 개발 과정에서 참고했던 EditPlus가 "보기-검색" 순이어서 그랬던 것 같다.
그리고 또 흥미로운 것은, 마소에서 만든 도스용 QBasic과 QuickBasic, 그리고 후대 버전인 QBX (MS Basic PDS 7), 도스용 비주얼 베이직 그쪽 라인은 역시 "보기-검색"이다.

그 반면, Windows 95와 그 이후에 새로 등장한 MS-DOS 에디터는 "검색-보기"로 돌아갔다. 대화상자에 선문자가 없는 그 프로그램 말이다.

원론적으로 따졌을 때 "검색-보기"가 더 자연스러우며 그 역순은 EditPlus와 QBasic 계열 같은 예외적인 프로그램에서밖에 존재하지 않는다는 점을 근거로, <날개셋> 편집기도 이번 8.4부터는 다시 "보기-검색"이 아니라 "검색-보기"로 복귀했다.
이 조치를 내리기 위해 저런 리서치와 고민이 있었음을 이 자리에서 밝힌다. ^^

Posted by 사무엘

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

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의 메모장 도움말은

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

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

메모장은 아주 단순한 프로그램이지만 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 사무엘

도스와 유닉스 명령창 공히 디렉터리를 이동할 때는 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...에 관한 언급이 존재한다.

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

이 기능은 이전의 도스 시절엔 존재한 적이 없었으며 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 사무엘

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

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