(각 그림들은 마우스로 클릭해서 나타나는 별도의 창으로 감상할 것)

1.x는 옛한글도 지원 안 하고, 오토마타는 매우 허접한 숫자 시퀀스로 구현되었으며, 한 입력 설정 하에서 고정된 개수인 두 글자판을 공유하는 구조였다.
사용자 삽입 이미지

2.x는 최대 4개의 입력기가 서로 다른 자신만의 설정을 갖는 게 가능해졌으며, 플러그 인이 추가되고 옛한글 표현이 가능해졌다. 그리고 입력 옵션도 꽤 다양해졌다.
입력 설정 전체를 간편하게 저장하고 불러오거나, 저장하지 않고 이번 프로그램 실행 중에만 적용하는 기능이 추가된 것도 특징이다.
사용자 삽입 이미지
그에 반해 3.x의 제어판은 정말 괄목할 정도로 크게 변했다. 트리 구조로 원하는 입력 항목의 카테고리에 손쉽게 접근이 가능하며 오토마타는 수식으로 바뀌었다. 바로 이 형태가 지금까지 이어져 오고 있다.
사용자 삽입 이미지

Posted by 사무엘

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

레거시 코드

꽤 희귀한 기회 덕분에,
한때 시대를 풍미했던 상업용 소프트웨어의 소스를 구경하게 됐습니다.

윈도우 3.1에서 돌아가는 녀석이었거든요.
저야 도스박스에다 윈도우 3.1 + 비주얼 C++ 1.5도 갖추고 있어서 이걸로 돌려도 되지만
32비트로 포팅을 해 보고 싶어서 최신 개발툴로 프로젝트를 만들고 빌드를 해 봤습니다.
당연히 바로 빌드는 안 되고 수백여 군데에서 에러가 나는데...
16비트 윈도우 코드의 특징을 한눈에 알 수 있었습니다.

1. precompiled header가 없었는지 매 소스 파일마다 <windows.h> 인클루드.

2. 말로만 듣던 far, huge 포인터의 압박. 메모리 모델별로 malloc이라든가 포인터를 다루는 함수도 따로 존재. _fmalloc 같은.

3. POINT 구조체. 옛날엔 POINT 구조체의 x,y 멤버가 16비트 크기였기 때문에 32비트 long 하나로 POINT를 나타내는 게 관행이었으며, 심지어 lParam *을 POINT *로 바로 캐스트하는 MAKEPOINT 같은 매크로까지 존재했습니다. 하지만 지금은 좌표계가 32비트로 커지고 이것 때문에 MoveTo, SetWindowOrg, SetViewportExt 같은 함수들은 모두 Ex가 붙은 형태로 프로토타입이 바뀌게 됐죠.

4. 옛날에는 핸들(HANDLE, HINSTANCE, HGDIOBJ, HWND 등등)은 전부 void *의 typedef였고, 아무 형변환 없이 마음대로 섞어 썼습니다. 이 폐해를 막으려고 지금은 STRICT(엄격한 타입 구분)라는 개념이 추가됐지만 어마어마한 분량의 레거시 코드를 컴파일시키려면 그 옵션을 꺼야 하죠.

5. WM_CTLCOLOR 메시지. 옛날에는 이 메시지 하나만 왔지만 지금은 WM_CTLCOLORBTN, DLG, EDIT, LISTBOX 등으로 세분화됐습니다. 다만, 16비트 관행을 물려받은 MFC는 여전히 OnCtlColor 라는 한 함수로 이 메시지들을 모두 처리합니다.

6. 멀건 윈도우 3.1 대화상자에다가 은빛 3차원 효과를 입혀 주는 ctl3d.dll과 교신을 하는 흔적. 그러고 보니 그때는 이런 효과가 지금의 공용 컨트롤 6.0 매니페스트 같은 그런 매개체였던 것 같습니다. MFC에도 CWinApp 클래스에 Enable3dControls 같은 멤버 함수가 있을 정도였는데, 이제는 완전히 deprecated로 처리되죠.

7. DLL도 아니고 EXE에 웬 export 속성이 지정된 함수? 그것도 __declspec(dllexport) 같은 지금 통용되는 문법으로 작성된 것도 아닙니다.
16비트 윈도우 EXE는 헥사 에디터로 들여다보면, 윈도우/대화상자 프로시저처럼 운영체제로부터 호출을 받는 콜백 함수들의 이름을 따로 name table에다 등재를 해 놓는 경우가 많더군요. 꼭 그렇게 할 필요는 없는데 왜 그러는지 궁금.. 디버깅 정보와 관련이 있는지, 아니면 속도를 높이려고 그러는지 이유는 모르겠습니다.

8. C++ 문법이 바뀌어서 옛날에는 허용되었으나 지금은 허용되지 않는 몇몇 문법들

맥이나 리눅스 같은 다른 플랫폼들은 도스 같은 극악의 호환성 발목은 없었겠지만, 16비트를 겪은 시절조차 전혀 없었는지가 문득 궁금해지네요.

참고로 저는 C/C++은 32비트 도스 익스텐더 환경에서(왓콤, DJGPP) 처음 시작했고 16비트는 거의 접한 적이 없는 세대입니다. ^^

Posted by 사무엘

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

철도역 리모델링의 추억

저의 대학 시절 중반기에 KTX 개통과 주요 대형역들의 리모델링 공사가 행해졌습니다.
그리고 그와 거의 딱 일치하는 시기에 저는 철도 매니아가 됐습니다. 타이밍 한번 절묘하기 그지없습니다.

※ 서울

일제 강점기 때 일본의 건축가가 서양 스타일로 지은 그 유명한 옛 역사는 역사적 가치가 워낙 높아서 사적 문화재로도 지정돼 있죠. 간이역이 아닌 대형역이 문화재로 지정받은 건 유일한 사례가 아닐까 합니다.
옛날 역사만 해도 공항 같다는 느낌이 들 정도로 게이트 수도 많고 덩치가 컸습니다. 요즘이야 선상역이 대세이지만, 옛날에는 어지간한 중대형 역도 1층이 매표소이고 승강장까지는 지하도를 통과하여 가는 경우가 많았는데요. 그래도 서울 역은 옛 건물도 나름 선상역인지라, 탈 때는 1층의 입구로 들어가서 대합실, 매표소가 있는 2층으로 올라가고 다시 승강장으로 계단을 이용하여 내려갔었습니다. (영화 라이터를 켜라 참고)

이미 KTX 개통 전 2003년 말부터 지하철 서울 역의 출구 개조 공사가 활발히 진행됐고 역의 기능은 옆에 새로 지어진 민자역사 유리궁전으로 완전히 넘어갔습니다. 그러고 보니 서울 청계 고가 철거 공사와 시기적으로 비슷했습니다. 신축 건물은 서울 역이라는 문구보다 콩코스(Concos)가 더 큼직하게 보이죠.

옛날 역사는 하차 승객은 역 입구로 나오는 게 아니라, 지하도를 통해 별도의 출구로 빠져나갔습니다.
지금도 대전 역은 지하도는 아니지만 하차 승객의 통로가 별도로 분리된 형태이고, 대전은 동부 고속버스 터미널도 마치 서울 강남 고속버스 터미널처럼 하차장이 따로 갖춰져 있는 게 인상적이랍니다.
참고로 옛날에는 청량리 역도 하차 승객 전용 지하도와 출구가 있었습니다. 지금은 또 새 역사 신축하느라 그것도 다 없어지고 형태가 바뀌었지만.

※ 대전

대전 하면 우동이 유명했지요.
옛날 역사는 2층도 없는(최소한 승객이 올라갈 일은 없는) 1층짜리 자그마한 건물이었고, 역사에서 승강장까지는 또 지하도로 이동하던 형태였습니다. 하지만 2004년부터 슬슬 리모델링 공사가 진행되어 지금은 선상역으로 변했습니다. 저는 대학 시절, 대전 역의 변화를 일일이 목격할 수 있었습니다.

옛날에는 역전 광장도 무지막지하게 넓었습니다만, 지금은 온통 택시 진입로와 지하철 출구 공사 때문에 공간이 거의 사라지고 없습니다. 대전은 건물 통로상으로 딱 연결은 안 돼 있지만 지하철 출구로 나오면 딱 철도역 입구이기 때문에 지하철과의 연계가 서울만큼이나 잘 돼 있습니다.
다만, 대전은 1호선 치고는 철도역에 해당하는 지하철 역이 이례적으로 굉장히 깊습니다. 서울, 대구, 부산은 안 그렇거든요.

※ 동대구

과거의 구질구질하던 동대구 역도 유리궁전으로 변신하고, 언덕 위의 본 입구뿐만 아니라 언덕 아래에서도 올라가는 출입구를 신설했습니다. 사실, 선상역으로 리모델링하면서 서울, 대전도 반대편 출입구가 신설되어 역의 접근성이 더 향상되기도 했답니다.

동대구 역은 언덕 위에 건설되어서 언덕 아래의 승강장으로 내려간다는 특성상, 입구에 들어가서 별도로 또 계단을 오르내리지 않습니다. 들어가면 곧바로 매표소와 대합실이 나오는 게 특이하죠. 나가면 광장은 거의 없고 고가 도로 상으로 차와 택시들만이 즐비합니다.

지하철 동대구 역하고는 서울· 대전에 비해서는 거리가 좀 먼 편입니다. 하지만 이 기회에 이 지역에 동대구 역, 지하철 역, 동대구 고속버스 터미널, 동부 시외버스 터미널이 통합한 종합 터미널이 생기면 얼마나 좋을까 싶기도 합니다. 전국에서 유례를 찾을 수 없는 대구 명물이 되겠죠. 대구는 철도역과 고속버스 터미널 모두 굉장히 특이한 형태라는 건 익히 잘 알려진 사실이니까요.

※ 부산

겉은 으리으리한 유리 궁전으로 탈바꿈하여 외형은 광주 역과 비슷해 보입니다. 하지만 내부는 60년대 말에 건설된 옛날 형태에서 크게 달라진 게 없습니다. 한 건물로 연결은 돼 있지만 서울 같은 완전한 선상역은 아니어서 대합실· 매표소 영역과 승강장 영역은 다소 거리가 있습니다.
바다와 가까운 역이다 보니 이 역의 승강장 주변엔 온통 컨테이너, 화물들을 심심찮게 볼 수 있습니다. 경부선상의 다른 역과는 다른 분위기이고 마치 또다른 항구 역인 인천 역을 떠올리게 합니다.

부산 역은 제가 알고 있는 경부선 역들 중 현재 광장이 가장 넓은 역이기도 합니다. KTX 개통을 앞두고 숱한 리모델링의 손길에도 불구하고 학교 운동장을 방불케 하는 넓은 광장이 아직 원형 그대로 남아 있습니다. 지하철 역과는 그렇게 완전 가깝지는 않아서 지하철 출입구는 학교로 치면 딱 교문까지만 닿지, 대전이나 서울처럼 학교 건물 코앞에 닿아 있지는 않습니다. 이런 점에서는 부전동 역(부전 역)도 마찬가지.
전에도 글로 썼지만 부산은 남쪽이 철도, 북쪽 노포동 쪽에 종합 버스 터미널 이렇게 교통이 양분되어 있습니다.

Posted by 사무엘

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

※ 1기: 1.x 커널

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

※ 2기: 2.0 커널

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

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

※ 3기: 21세기 커널

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

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

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

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

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

비주얼 C++의 역사

그동안 비주얼 C++에 대한 글을 적지 않게 썼었는데 이렇게 전버전의 특징과 역사를 정리해 본 적은 없는 것 같다.
역시 2003과 2005에 대한 설명이 가장 길다.

※ 1.0

MS C 7.0의 차기 버전으로서, 비주얼 베이직처럼 비주얼이라는 브랜드를 걸고 첫 제품이 출시되었다. 비주얼 C++의 역사는 초기에 Application framework라 불리던 MFC 라이브러리와도 역사를 함께 한다.

※ 1.52

윈도우 3.1 타겟을 지원하는 마지막 버전인지라 굉장히 중요한 위치를 차지하고 있다. AppStudio라는 통합 환경이 있기는 하나 도움말 열람, 리소스 편집 등은 여전히 다른 프로그램에서 따로 해야 했다.
프론트 엔드 GUI는 모두 16비트 프로그램인 반면, 커맨드 라인에서 동작하는 컴파일러, 링커 같은 주요 툴들은 도스 익스텐더 stub을 내장하고 있는 32비트 PE 포맷인 점이 무척 인상적이다.

이 시절에 컴파일러는 도스/윈도우 모두 그것도 메모리 모델별로 다 지원해야 했기 때문에 타겟 지정하는 옵션이 무척 까다로웠던 것 같다. 그리고 kernel32, gdi32, user32처럼 API가 분야별로 나뉘어 있는 게 아니라 윈도우 API import 라이브러리가 한 파일에 다 들어있었다.

군대 갔다 온 분, 특히 육군 쪽으로 갔다 온 분은 ‘상호 존중과 배려’라는 표어에 매우 익숙할 것이다. 실제로 이걸로 검색해 보면 군대 관련 사이트, 블로그 포스트들이 제일 먼저 많이 뜬다. -_-;;
그런데 윈도우 3.1만큼 이 문구가 잘 들어맞는 환경도 별로 없을 것 같다. 프로세스들이 혼자 시스템 자원 CPU 시간을 절대 독점하지 말고 다른 프로세스에 대한 자발적인 ‘상호 존중과 배려’로 멀티태스킹을 서로 만들어 가야 하기 때문이다. ^^;;

※ 2.0

32비트 타겟으로 나온 첫 버전으로 알려져 있으나, 그 시기가 윈도우 95가 나오기도 전이고 NT는 점유율이 미미하던 때였다. 시대를 너무 앞서 가는 바람에 주목을 별로 못 받은 전설 같은 존재이다.
(그나저나 그렇다면 94년 이전에 윈도우 NT 3.1의 각종 바이너리들은 무엇으로 빌드했는지 궁금하다. MS 자체적으로만 쓰는 내부 컴파일러? ㄱ-)

32비트 환경에서는 메모리 모델 구분이 없는 대신, CRT에 링크 방식(static/DLL)과 멀티스레드 지원 여부라는 개념이 새롭게 생겼다.

※ 4.0

DirectX에 4라는 버전이 없는가 하면 비주얼 C++에는 3.x대 버전이 없다. 내부적으로 꾸준히 버전업이 돼 온 MFC의 버전 번호에 맞춰 곧바로 4.0으로 건너뛰게 된다. 참고로 윈도우 95의 워드패드가 웬 듣보잡 MFC 3.0 기반인 점이 흥미롭다. 98 이후부터는 전부 MFC42 기반으로 바뀌었음.

4.0에 와서야 비로소 오늘날의 비주얼 C++과 상당한 골격이 갖춰졌다. 즉 코딩, 리소스 편집, 클래스 마법사, 도움말 열람을 한 프로그램에서 할 수 있는 진정한 통합 환경 Developer Studio가 이 버전부터 생겼다. msdev.exe라는 프로그램 이름은 훗날 6.0까지 이어졌다.
이때는 아직 16비트에서 32비트로 한창 넘어가는 과도기였기 때문에 Win32s 타겟이 지원되기도 했다.

참고로 MS에서 개발한 프로그램 중에서 MFC를 쓴 놈은 고작 워드패드, 그림판, 그리고 비주얼 C++ 6 이하 버전의 IDE와 관련 몇몇 유틸리티(Spy++, Dependency Walker) 정도? -_-;;

※ 4.2

4.1을 거쳐 4.0이 마이너 업그레이드된 버전으로, 제법 인지도를 얻었다. ActiveX 컨트롤, STL 같은 기능이 추가되고 MFC DLL의 이름도 이때부터 MFC42로 이름이 바뀌어 큰 뼈대의 변경 없이 훗날의 6.0까지 이어졌다. MFC42는 윈도우 98 이래로 운영체제가 이제 known DLL로 인정하는 마지막 버전 숫자이기도 하니 더욱 의미가 있다.

4.2에서부터 Win32s의 지원이 중단되었다. 오죽했으면 설치할 때 “이 버전부터 Win32s를 더 지원하지 않으니, 그 환경 개발하고 싶으면 이거 설치하지 말고 옛날 버전 쓰셈!”이란 경고문까지 나온다.

※ 5.0

GUI 껍데기는 거의 다 6.0처럼 바뀐 반면, 내부 구조와 기능은 여전히 4.2와 비슷하다고 보면 되겠다. 도구모음줄과 메뉴가 MS 오피스 97 스타일로 바뀌고(하지만 내부 코드 베이스는 서로 완전히 다름) 대화상자도 리모델링되었으나, 도움말은 여전히 RTF 기반이고 인텔리센스도 아직 없었다. 이듬해에 나온 6.0에 밀려 완전히 존재감을 상실했다. 프로젝트 파일 포맷이 이때 처음으로 DSP, DSW로 바뀌었는데, 이 포맷은 결국 5와 6 두 버전에서만 쓰이고 이후 버전에서는 또 바뀌게 되었다.

이때부터 bool이 built-in type으로 지원되기 시작했다. 그리고 이때부터 빌드하는 EXE 파일에 PE 재배치 정보가 기본적으로 생략되게 되었다.

※ 6.0

나온 지 10년이 지난 지금도 어렵지 않게 찾을 수 있고, 윈도우 XP만큼이나 최장수 개발툴로 이용되고 있는 결정판이다. 이 버전 이후로 거의 4년 가까이 버전업이 없었고 다음 버전인 닷넷이 변화폭이 너무 크기도 했기 때문이다.

6에서는 인텔리센스, edit and continue, delay-loaded DLL 같은 획기적인 기능이 처음으로 추가되고 도움말이 별도의 MSDN 라이브러리로 독립함과 동시에 HTML 기반으로 모두 바뀌었다.
이 버전은 윈도우 9x에서 설치 가능한 마지막 버전임과 동시에 MSVCRT, MFC42 같은 known DLL만 사용하는 바이너리를 생성할 수 있는 마지막 버전이기도 하다. 주요 라이브러리를 DLL 링크하고도 DLL 배포 걱정을 할 필요가 전혀 없다는 장점이 있다.

4.2 때는 ClassView에 있는 각종 클래스, 변수 정보가 소스 파일을 매번 저장할 때에만 업데이트됐다. 이것이 내용이 바뀔 때마다 실시간으로 바뀌기 시작한 것도 5.0은 아니고 6.0부터인 걸로 기억한다.

※ 7.1 (2003)

비주얼 C++의 다음 버전은 처음엔, 버전 번호나 연도가 아닌 닷넷이라는 브랜드로 출시되었다. MFC를 써서 개발된 VC 특유의 전통적인 msdev.exe는 퇴출되고 devenv라는 MS 오피스 내지 비주얼 베이직 스타일의 IDE가 등장했는데, 이는 완전히 새로운 것이라기보다는 예전에 비주얼 스튜디오에 있던 Visual InterDev와 비슷한 형태였다. 단지 거기에다 외형만 MS 오피스 XP 스타일 UI를 그대로 물려받았다.

덕분에 비주얼 C++과는 영 인연이 없고 비주얼 베이직만의 전유물인 것 같던 Property grid가 도입되어 비주얼 C++ 특유의 등록정보 대화상자를 대체했다. 클래스 마법사도 이 형태로 대체됐다. 도움말은 5.0 시절처럼 IDE 내부에 띄울 수도 있고 6.0처럼 외부에 띄울 수도 있는 융통성 있는 형태로 바뀌었다.

이제 주류로 내세운 게 C#, 공용 언어 런타임 같은 닷넷 환경이긴 했지만 네이티브 C/C++ 쪽도 크게 향상되었다. 6이 표준대로 제대로 지원하지 않던 문법 내지 컴파일러의 버그 많이 수정되기도 하고 네이티브 wchar_t 형식이 지원되기 시작했으며, 6에서 첫 도입됐던 인텔리센스도 굉장히 강력해져 특히 #define 심볼에 대해서도 동작하기 시작했다. 링크 시점에서 코드를 생성하는 전역 최적화라든가 crash mini-dump 생성 기능도 이때 첫 도입된 기능이다. 닷넷 정도만 써 보면 이제 6.0은 충분히 열악함을 느끼기에 충분할 것이다.

공용 라이브러리는 이제 MSVCR71, MFC71로 바뀌었는데, 이 DLL은 최신 운영체제라고 해서 더는 기본 내장을 해 주지 않기 때문에 응용 프로그램이 알아서 자기 디렉터리나 윈도우 시스템 디렉터리에다 구비해야 한다. 이 점에 관한 한 6.0이라든가 side-by-side assembly를 사용하는 8.0 이후만도 더 못하고 무책임한 면이 없지는 않다. 또한 64비트 개발은 불가능하지는 않으나 불편하고 디버깅도 되지 않고 IDE 차원의 적극적인 보조는 못 받는 어정쩡한 위상을 차지하고 있다. 이 불완전한 면모들은 후속 버전인 8에서 보완되었다.

사실 7.1은 최초로 나왔던 ‘닷넷’(7.0)의 버그 수정판이다. 엄청난 기능이 도입되었던 만큼 첫 버전은 불안정하고 버그도 많았기 때문이다. 7.1 버전은 아래아한글, VMware, 스타크래프트 같은 다수의 상용 프로그램의 최신 버전 개발에 아직까지 쓰이고 있다.

※ 8.0 (2005)

이 버전부터 닷넷이라는 이름을 떼고 출시는 되었으나 8은 7.1하고 아무 단절도 없이 닷넷과 네이티브를 모두 지원하는 동일한 개발 도구의 연장선이다. 이 버전은 닷넷 초창기 버전인 7의 과도기적 불완전하고 2% 부족하던 면모를 속 시원히 보완한 게 무척 많았다. 요즘 어도비 사에서 나오는 프로그램들이 이 버전으로 개발되고 있다.

첫째, 별도의 플랫폼 SDK를 설치할 필요 없이 IDE 차원에서 64비트 빌드와 디버깅이 정식 지원된다.
둘째, 공용 DLL인 MSVCR80, MFC80의 배포 방식이 side-by-side assembly 방식으로 완전히 바뀌었다. 일각에서의 불만을 감수하고라도 이건 꽤 강한 정책이었다. 이와 덩달아, 리소스 편집기로 수동으로 해야 하던 메니페스트 생성/편집 기능도 상당 부분 자동화됐다.

셋째, for 문의 변수 scope처럼 그동안 표준을 어기고 있던 문법을 교정하고, CRT의 보안을 크게 강화했다. strcpy_s와 gets_s(대상 버퍼 크기), qsort_s(콜백 함수에 데이터 전달 가능), strtok_s(토큰 중복 호출 가능) 같은 함수가 새롭게 등장하고 strchr 같은 경우, C++에서는 const 포인터를 되돌리는 버전과 비const 포인터를 되돌리는 함수가 오버로딩으로 분리해 나갔다. 무척 신선한 변화라 느껴진다. STL 디버깅도 훨씬 더 편해졌다.
넷째, UI 상으로도 이제 MS 오피스 스타일에서 독립한 새로운 외형 비주얼을 갖기 시작했으며, 도구모음줄 아이콘도 256색으로 더 화려해졌다. 전통적으로 ClassView에 클래스와 멤버들이 한 트리에 쫙 나열되던 것이 멤버는 별도의 리스트에 뜨도록 바뀌기도 했다.
이 버전부터는 생성하는 프로젝트의 디폴트 기반 인코딩이 드디어 유니코드로 바뀌었다.

※ 9.0 (2008)

8이 질적으로 많이 바뀌었다면 9는 윈도우 비스타의 등장처럼 8 출시 이후에 생긴 변화를 IDE나 MFC 라이브러리 같은 데에 적극 반영하여 양적인 향상을 꾀했다. 또한 MS 오피스 스타일의 GUI를 손쉽게 만들 수 있는 feature pack을 드디어 도입하기도 했다.

이렇게 시대의 조류 때문에 생긴 변화를 제외하면 9는 네이티브 C/C++의 관점에서 봤을 때, 7에서 8로 넘어갈 때 같던 큰 변화는 느껴지지 않으며 따라서 8은 조만간 별다른 존재감 없이 9로 흡수될 걸로 예상된다. 완전히 새로운 기능으로는 보안 강화를 위해 링커에 추가된 시작 주소 랜덤화 기능 정도? 이 옵션은 MS 오피스 2007과 윈도우 비스타의 모든 바이너리에 기본 적용돼 있으며, 과거 Win32s의 잔재로나 기억되던 EXE 파일의 재배치 정보를 다시 끌어들인 장본인이기도 하다.

9는 8과는 달리 윈도우 2000도 설치되지 않으며, 윈도우 9x 계열은 아예 타겟 플랫폼에서도 완전히 제외되었다. 링커 옵션에서 바이너리의 최소 요구 운영체제 버전이 4에서 5로 껑충 뛰었고, 이보다 낮은 값은 지정 자체가 안 된다.
또한 single threaded CRT 라이브러리 옵션도 없어졌다. 이것만 빼면 그다지 아쉬울 것 없다.

Posted by 사무엘

2010/01/10 23:50 2010/01/10 23:50
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/41

※ QuickBasic

아래의 PB와 더불어 제 인생에서 거의 최초로 접한 “EXE 생성기”가 아니었나 싶습니다. 중학교 시절 저의 주된 장난감이었습니다. 특히 가장 대중적인 베이직 컴파일러였던지라 한글 입출력/그래픽/사운드/마우스/메모리 등 갖가지 분야의 공개/상용 라이브러리로 기능을 확장해서 프로그램을 만들던 기억이 납니다.

MS는 오로지 고객 편의 위주로 기존 관행을 확 깨는 새로운 제품 만드는 데는 정말 비상한 재주가 있다는 걸 인정해야겠습니다. 그래서 윈도우 9x 같은 타협안으로 소비자 시장을 우려먹기도 했고, 베이직 개발 환경만 해도 저런 대화형 구조에다가 라이브러리까지 특수한 EXE로 링크해서 ‘퀵라이브러리’(QLB)라는 개념을 발명하여, IDE에서 빌드도 없이 바로 프로그램을 실행시킨 것도 정말 대단하다고밖에 말할 수 없군요.

QB는 최종 버전이 4.5였고 그로부터 몇 년 뒤에 소위 MS Basic이라 불린 Basic PDS (전문 개발 시스템)가 7.0/7.1 (VS .NET 같군)라는 QB 후속 버전이 나오긴 했습니다. 하지만 차이를 전혀 모르겠어요. 오히려 기능 확장의 생명인 라이브러리가 호환이 안 되고 불편해서 널리 사용되지는 않았습니다. PDS 이후 MS는 비주얼 베이직으로 넘어갑니다. 마치 MS C 7 이후로 비주얼 C++이 나온 것처럼.

※ PowerBasic

볼랜드에서 Turbo Basic을 잠시 만들던 전 직원이 볼랜드를 나와서 따로 창조한 브랜드이죠. 베이직만으로 QB보다 월등히 빠르고 거의 C/C++ 수준의 효율적인 네이티브 코드를 만들어 준 덕분에 QB와는 별개 영역에서 사용자를 구축하고 있습니다. 저는 3.1을 써 봤습니다.

단점으로는 QB에 비해 역시 라이브러리 캐부족, 일부 QB와 호환되지 않는 문법, QB보다는 다루기 불편한 IDE. 그리고 PB도 아예 Win32 콘솔 프로그램은 만들어도 32비트 도스 익스텐터와의 연계는 없었던 걸로 압니다.
또한 QBasic도 지원하는 스크린 mode 13H (VGA 320x200 256색) 모드를 지원 안 하는 것도 너무너무 아쉬운 점.

세상에 베이직처럼 Dialect가 많은 언어도 별로 없는 것 같습니다. 요즘 베이직은 그냥 스크립트 언어처럼 쓰거나 아니면 .NET 구도에 맞춰서 문법 다 뜯어고쳐서 쓰는데, PB는 베이직으로 하드코어 네이티브 코드를 지향했다고 볼 수 있습니다. 참고로 베이직을 거의 어셈블리 수준으로 짬뽕시킨 언어 내지 툴로 ASIC이라는 녀석도 있었습니다.

※ Visual Basic

GUI 바로 만들고 거기에다 코드를 즉시 갖다붙이는 형태가 무척 재미있어서 잠시 갖고 놀아 봤습니다. 하지만 런타임 DLL이 필요한 EXE밖에 못 만든다는 걸 알고서 이내 좌절함. 그나마 5.0 이전 버전은 EXE 자체도 자바 내지 닷넷 같은 슈도코드 기반이지 네이티브 코드는 지원도 안 하고 있었고요.

아울러, 닷넷부터는 IDE가 언어 불문하고 한데 통합되었기 때문에 VB 특유의 그 개성 넘치는 IDE를 볼 수 없게 된 것이 좀 아쉽습니다.

※ Borland Pascal

언어 특성상 C/C++과는 비교가 안 될 정도로 빌드 속도가 월등히 빠르고 라이브러리 오버헤드도 훨씬 작아서(Hello, world! 프로그램의 exe 크기) 굉장히 좋은 인상을 받았습니다. 16비트 도스용 네이티브 컴파일러로는 그야말로 최고봉이 아닌가 싶습니다. 파스칼 언어도 제가 베이직에서 C/C++로 전환할 때의 과도기 컨셉 역할을 잘 해 주었습니다. 이걸로 뭔가 걸출한 프로젝트를 진행해 봤으면 하는 아쉬움도 있습니다.

파스칼은 교육용으로 무척 훌륭한 언어이고 간단한 문법 덕분에 빌드하기는 간편하나, C/C++보다 함축성이 굉장히 떨어져서 코딩하기는 번거롭습니다. 가령 정수 나누기 정수도 결과가 무조건 실수가 되고 일일이 형변환을 해야 하는 건 기계 입장에서는 직관적이지 못하죠. 또한 단축연산이란 것도 없고.

※ Turbo C/C++

고등학교 때 정보 올림피아드 준비하던 시절에 잠시 다뤘을 뿐, 제품 자체의 왕년의 영향력에 비해서 얘를 써 본 경험은 거의 없습니다. 본격적인 응용 프로그램 개발을 위해 필요한 프로젝트 세팅, 메모리 모델 설정 같은 것도 전혀 해 본 적 없습니다. 저는 16비트 C/C++과는 도스/윈도우 공히 인연이 없는 셈입니다.

※ Delphi

놀랍게도 제가 얘를 다뤄 본 건 95년에 나온 초창기, 그것도 16비트 버전인 1.0뿐입니다. 오브젝트 파스칼 언어로 비주얼 베이직 같은 프로그래밍을 할 수 있구나 하는 인상만 받고 더 진척된 건 없습니다.

델파이는 런타임 DLL이 필요한 EXE를 만드는 옵션 자체가 없고 기본적으로 EXE 크기가 2~300KB대 이상은 먹고 들어가는 걸로 알고 있습니다.

※ C++ Bulder

비베, 델파이 수준의 RAD 환경을 C++로도 만들어 버렸으니 대단하다는 인상을 받았음. 물론 다른 건 다 델파이를 따라해도 빌드 속도를 따라할 수는 없지요.
버전 3을 써 봤습니다. 골치아프게 Win32 GDI API 쓸 필요 없이 캔바스 객체에 접근하여 프로퍼티를 바꾸는 것만으로 선과 면 색을 바꾸는 것도 흥미로웠습니다.

하지만 RAD 용도로는 어차피 델파이가 한 역할 담당하고 있었고, C++ 빌더는 상대적으로 존재감이 덜했던 것 같습니다.
MFC도 지원은 하지만, 빌드 속도 내지 빌드된 코드의 성능이 MFC의 본고장인 VC로 빌드한 것보다 무척 뒤쳐졌던 걸로 기억합니다. 빌드 속도는 흠, pre-compiled header 설정을 안 해서 그런 걸까?

델파이와는 달리 C++ 빌더의 EXE는 기본적으로 VCL.DLL이던가 컴포넌트 DLL이 필요한 형태입니다. 스테틱 링크가 가능한지는 기억이 안 납니다.

※ Watcom C/C++

MS와 볼랜드 컴파일러의 공통점은 32비트 도스 익스텐더 기반 코드 생성을 지원하지 않았다는 것입니다. 자기네 컴파일러들이나 겨우 몇 MB 정도 추가 메모리 확보를 위해, 286용 16비트 도스 익스텐더 정도를 사용한 게 고작입니다.

그러던 차에, 상용 게임들 덕분에 유명하던 DOS4GW 기반 코드 생성을 지원하던 왓콤 컴파일러는 정말 신선한 충격이었습니다. sizeof(int)도 말로만 듣던 4바이트로 나왔죠.
최적화 성능도 매우 뛰어났던 걸로 기억합니다. 익스텐더는 다르지만 도스용 아래아한글 386 에디션도 왓콤 기반이었던 것으로 유명합니다.

하지만 라이브러리가 부족하고 IDE도 없는 이 컴파일러로 본인이 당장 할 수 있는 일이 별로 없었던 게 아쉽습니다.

※ DJGPP

자유 소프트웨어 진영의 위력을 보여준 불세출의 32비트 도스 컴파일러입니다. 소스까지 공짜, DOS4GW보다 stub 크기가 훨씬 작고 더구나 DPMI가 기제공되는 환경에서는(윈도우 도스박스 같은) 필요하지도 않은 CWSDPMI.
거기에다 rhide 같은 IDE와 알레그로 같은 무지막지한 게임 라이브러리.

빌드 속도가 좀 느리고 exe 크기가 살짝 좀 큰 게 압박인데, 그 정도는 좀 대형 프로그램 작성하다 보면 아무것도 아닙니다. 도스가 살아 있다면 계속해서 쓰고 싶습니다. 물론 윈도우용 GCC도 있다고는 들었지만.

※ Visual C++

여러 개발툴들을 거쳐 이제 최종적으로 정착한 도구는, 그 이름도 유명한 비주얼 C++입니다. 더 설명이 필요없으리라 믿습니다. 닷넷이고 뭐고 많이 나와도 역시 한글 IME를 직접 개발하다 보니 제게는 네이티브 말고 다른 계층은 필요하지가 않네요.

Posted by 사무엘

2010/01/10 23:26 2010/01/10 23:26
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/36

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

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

새마을호의 역사

<사진으로 보는 한국 철도 역사>
이런 책이라도 있으면 당장 사겠다.
풍부한 역사 검증에, 사진에, 주제별 색인까지!

어쩌다 비슷한 주제의 책을 검색해 보면 전부 철도청 시절의 정부 간행물이고, 지금은 다 절판되고 없다. ㄱ- 어쩜 이 분야로 자료가 왜 이리 열악한지 모르겠다.

앞의 글은 지하철 글이고 이번에는 어제 철도 연표를 뒤져 본 기억으로 새마을호의 역사만을 종합해 보고자 한다. 새마을호 애호가라면 이 날짜들을 꼭 기억하라.

1974년 8월 15일, 서울 지하철 1호선이 개통함과 동시에 관광호가 새마을호로 명칭 변경하여 운행 시작.
새마을호가 무궁화호, 통일호 같은 명칭보다 먼저 생겼다는 뜻이다. (밑줄 그으시길. ㄱ-) 나머지 명칭은 거의 10년 뒤인 84년 1월 1일부터 시행되기 시작했다. 시민들을 대상으로 명칭 공모를 83년 7월 4일에 했다.

1979년 1월 12일. 서울-경주 새마을호 운행 시작. 포항, 울산으로는 아직 안 갔다. 이때 새마을호는 지금 새마을호의 좌석이나 외형이 아니었다.

1983년 7월 1일. 열차 시각표를 전면 개정하여 운행 시간 단축. 다른 문헌을 종합하면, 이때 서울-부산 새마을호의 운행 시간이 4시간 40분이 되었다. 성능 좋은 특대형 기관차의 도입과 경부선 선형 개량 덕분에, 한창 열차 속도가 빨라지던 시절이었다.

1984년 8월 31일. 경부선 서정리-천안 구간에서 새마을호 150km/h로 시운전 성공. 역사적인 기록이다. 이곳은 지금까지도 KTX를 제외하고 전국에서 선형이 가장 좋으며 열차가 가장 빠르게 전속력으로 달리는 구간이다. 철도 기술 연구소 연구진의 노력의 결실이었다.
그런데 저런 말만 불쑥 있지, 이때 뭘 구체적으로 개선해서 속도를 끌어올렸는지 내용이 없던 게 아쉽다.

1985년 11월 16일. 83년에 이어 또다시 열차 시각표가 전면 개정된다. 지난해의 시운전 결과를 적용하여 열차 운행 시각은 더욱 단축되었으며 KTX 개통 직전까지 가장 빠른 시간인 서울-부산 새마을호 4시간 10분이 이때 달성되었다.

1987년 7월 6일. 오늘날 새마을호의 프로토타입인 전후동력형(PP) 디젤 동차가 운행되기 시작함. 대우 중공업에서 생산한 6량짜리 동차가 그 시초이다. 그 후 불과 사흘 뒤인 8월 9일부터는 주말에 중련편성 운행도 시작했다.

흔히 혼동하기 쉬운데, 새마을호의 과거의 트레이드마크이던 시속 150km 주행 및 서울-부산 4시간 10분 달성은 PP의 운행보다 먼저 별개로 일어난 사건이다. PP가 이를 최초로 달성한 것이 아님을 기억하기 바란다. 마치 공 병우 박사가 한글 타자기 자체를 최초로 발명한 분이 아닌 것과도 같은 이치이다.

1988년 언젠가부터, 새마을호 기내지인 레일로드가 비치되기 시작함.
1989년 10월 22일. 서울-울산 간 새마을호 운행 시작

1991년 11월 25일, 수도권 전철의 확장 공사로 떠들썩하던 바로 그 때 장항선에도 새마을호가 운행되기 시작

1992년 6월 30일, 새마을호의 차기 구도로서 고속철 기공식이 거행됨. (참고로 알아 두셈)
1992년 10월 1일. 서울-마산 간 새마을호 운행 시작

1993년 5월 1일. 포항까지 가는 새마을호 운행 시작. 아마 이것이 발전하여 이내 울산-포항 중련편성 새마을호가 되지 않았나 싶다.

1995~97년 사이에 새마을호의 도색이 노랑-초록으로 바뀌었다. 철도청 연표에 왜 이런 기록이 없는지 궁금하다.

1998년 8월 1일. 새마을호 안내방송에 일본어가 추가되었다.

1999년 12월 1일. 전국 철도역사에서 대합실, 승강장이란 말이 사라지고 맞이방, 타는곳 등으로 바뀌었다. 이때 용어 개편을 단행했는데, 이걸 잘 했다고 철도청은 한동안 이 오덕 선생님 같은 우리말 운동 진영에서 꽤 칭찬 받았다. 새마을호와는 관계가 없지만 중요하기 때문에 그냥 다시 소개함.

2000년 2월 10일, 철도청에서 6 sigma 경영방침을 선포함

2000년 6월 1일. 그렇다. 새마을호 객실 내부에 세계 최초로 영상정보 서비스가 개시되었다. 그 전에는 객실에 그냥 자막이 흘러나오는 전광판만 있었는데 모니터로 다 대체된 셈이다.
영상 서비스는 그 후로 약 7년 동안 지속되었으며, 아마 Looking for you도 2002년부터 06년까지 4년 남짓한 시간 동안 새마을호에서 들을 수 있지 않았나 추정된다. 이런 UI 쪽으로는 공식 문헌이 전무하며, 경험담으로 추측할 뿐이다.

Posted by 사무엘

2010/01/10 23:19 2010/01/10 23:19
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/32

※ 1.x 시절

윤곽선 폰트라는 개념이 없던 시절엔 도트용과 레이저용이라는 기묘한 구분이 있었습니다.
레이저용이라고 해 봤자 겨우 300dpi짜리 프린터였는데, 그때는 그 고해상도 비트맵 글꼴만 해도 제작 비용이라든가 컴퓨터 상의 처리 부담이 만만찮았습니다.
레이저 프린터용 자형의 존재 여부가 한 프로그램의 에디션을 구분하고 복사 방지장치 장착 여부를 결정한 것이나 다름없습니다.

※ 2.0, 2.1

일반용과 전문용으로 구분했습니다. 가격 차이는 거의 2.5배 정도.
글씨를 자유롭게 확대할 수 있게 되었기 때문에, 일단 레이저 프린터용 비트맵 자형도 일반용에 기본 내장은 되는 '거저 먹는' 양상이 되었습니다.
아래아한글 2.0은 우리나라 소프트웨어 역사에 그야말로 획기적인 한 획을 그었습니다.
하지만 컬러 인쇄와 윤곽선 글꼴, 맞춤법 검사기 같은 기능은 전문용에만 있었지요. 윤곽선 글꼴이 없었으니 일반용은 글씨 크기 조절이 사실 별 의미가 없었습니다.
전문용은 락이 걸렸습니다. 그리고 2.1 전문용은 386 전용 코드로 개발되었습니다.

※ 2.5

드디어 2.5에서 일반용과 전문용이란 구분도 없어지고, 대신 86, 386 코드 에디션 구분이 생겼습니다. 86 에디션은 제 기억으로 덧실행, 맞춤법 같은 기능이 없는 거 빼고 문서를 만드는 기능상으로는 거의 차이가 없습니다. 286 AT 기종에서도 드디어 컬러 인쇄와 윤곽선 글꼴을 구현해 냈습니다. 눈물나게 감동스럽습니다.
다만, 2.5부터는 영한사전, 추가 확장 글꼴 같은 '확장팩'이란 개념이 생겼고, 확장팩에만 락이 걸렸습니다. 락이 없으면 영한사전 메뉴는 비활성화됐고, 신명시스템 글꼴은 아무 말 없이 그냥 동작하지 않고 명조로 대체되어 나왔죠. "한글과컴퓨터 2"라는 폰트 드라이버 자체가 락이 걸렸던 것 같습니다.

※ 몇 가지 중요한 사실

- 아마 2350자에 없는 비완성형 한글에 대해 최초로 동작한 윤곽선 글꼴은 2.1에서 추가된 휴먼 안상수체 계열의 조합형 글꼴입니다.
- 신명조가 비완성형 한글과 옛한글까지 윤곽선화한 건 2.5나 3.0때부터입니다. 제 2수준 한자가 윤곽선화한 것과 시기가 비슷합니다.
- 1.X 시절부터 있던 샘물과 필기체는 정확하게 2.5에서 윤곽선화했습니다.

- 윈도우용 아래아한글 3.x에서부터 2.5 확장팩 글꼴이 락이 풀린 형태로 제공되기 시작했습니다. 윈도우용 버전은 기존 도스용 2.5의 락이 걸린 확장팩 글꼴도 바로 읽어들였을 뿐만 아니라, 3.0용 확장팩 자체도 락이 풀려서 도스용 2.5에다가 복사하면 바로 읽을 수 있는 형태로 글꼴이 들어있었다는 뜻입니다. 사용하는 폰트 드라이버가 "한글과컴퓨터 2" 대신 일반 "한글과컴퓨터"로 바뀌었습니다.

Posted by 사무엘

2010/01/10 22:43 2010/01/10 22:43
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/18

« Previous : 1 : ... 14 : 15 : 16 : 17 : 18 : 19 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/10   »
    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:
1267004
Today:
137
Yesterday:
552