예전에도 글로 쓴 적이 있지만, 16비트 윈도우 바이너리(exe/dll), 소위 NE 파일의 형태는 보면 볼수록 참 이상야릇하다고 느껴져서 흥미가 갑니다.

MZ로 시작하는 도스 EXE는 구조가 사실 매우 간단합니다. 맨 처음 32바이트 남짓한 구조체에다 몇몇 오프셋, 사이즈, 레지스터 초기값 따위를 넣고 재배치 정보(optional)만 넣어 주고 나면 그 뒤부터는 공통분모라는 게 없이 전적으로 프로그래머/컴파일러 재량입니다. COM은 아예 헤더란 것이 없고 곧장 코드+데이터가 등장하는 형태이니 초간단 패치 내지 램 상주 유틸리티, 혹은 심지어 바이러스를 만들 때 이보다 더 좋은 수단이 없었습니다.

하지만 좀더 복잡한 운영체제는 바이너리 파일에도 더 정교한 체계대로 구간별 역할을 딱딱 나누고 있습니다.
가령, EXE 뒤에다가 별도의 내장 데이터를 덧붙이는 것은 도스 시절에는 전적으로 컴파일러/링커 내지 해당 기능을 수동으로 제공하는 라이브러리의 재량이었습니다. 가령 볼랜드 컴파일러로 *.bgi 드라이버나 글꼴을 *.obj로 바꿔서 embed시키는 것은 운영체제보다 훨씬 더 상위 계층에서 행해지는 일이었죠.
하지만 윈도우에서는 운영체제 차원에서 바이너리 파일 안에 리소스라는 데이터 영역을 별도로 구분하여 관리해 주며, 이를 불러오는 API도 운영체제 차원에서 제공됩니다.

16비트 중에서도 윈도우 1.x(무려 1985년에 나온 바로 그것!), 2.x, 3.x의 포맷이 모두 서로 살짝 다르다고 하는데, 2.x 이상 바이너리는 오늘날 윈도우 운영체제의 NTVDM 하에서도 바로 실행 가능하다고 들었습니다. (9x 계열에서는 말할 나위도 없음.) 하지만 1.x도 리소스 데이터를 좀 변환하고 버전 플래그 같은 몇몇 값만 수정하면 곧장 실행할 수 있다고 하더군요. 윈도우가 하위 호환성을 상당히 잘 지키면서 버전업되어 왔다는 얘기가 되겠습니다.

0x3C 오프셋에 도스 바이너리가 아닌 실제 바이너리가 시작되는 위치가 기록되어 있다는 것은 NE(16비트 윈도우 바이너리), PE(오늘날의 32/64비트 바이너리) 모두 공통입니다. NE에도 PE와 마찬가지로 최소 운영체제 버전과 자신을 빌드한 링커의 버전이 헤더에 명시되어 있습니다.

윈도우 3.x 바이너리들은 대개 링커 버전이 5~6 정도로 잡혀 있던데 이건 비주얼 C++ 버전이 아니라 그 전신인 MS C 버전 기준이라고 보는 게 타당하겠습니다. 비주얼 C++ 1.5x는 MSC_VER의 값이 600밖에 안 되거든요. 그 반면 요즘 비주얼 C++ 200x는 이미 무려 1300~1500대까지 올라갔죠.

최소 운영체제 버전은 물론 3.10으로 잡으면 윈도우 3.1에서 실행 가능합니다. 하지만 이 수치를 더 높게 4.0으로 잡으면 “윈도우 3.1에서 실행되지 않는 16비트 윈도우 바이너리”를 만들 수 있습니다.

그런 예가 무엇이 있냐 하면 바로 윈도우 9x 이후에 제공되는 SysEdit.exe입니다. 이 프로그램은 16비트 EXE이지만 정작 윈도우 3.1에서는 실행이 안 됩니다. 하지만 윈도우 9x에서 실행하면 비록 16비트 EXE이지만 대화상자의 배경을 다른 32비트 프로그램들처럼 회색 입체 효과로 입혀 주며 16비트 프로그램과 호환되지 않는 일부 신규 메시지/API를 32비트 프로그램과 같은 스타일로 날려 줍니다. Win32s도 아니고 참 난감한 케이스이죠? 윈도우 9x가 나오던 당시, MS에서 내부적으로 기존 16비트 프로그램들의 외형 껍데기의 이질감을 줄이려고 넣은 꽁수에 가깝다고 보면 되겠습니다.

요즘은 파일 포맷을 설계할 때 최대한 확장성을 고려하여 chunk 테이블부터 넣는 게 일반적입니다. MIDI(음악), TTF(글꼴), PNG(그래픽)들이 다 그렇죠. PE도 마찬가지여서 text, data, reloc, rsrc 같은 청크 식별자가 존재합니다. 하지만 NE는 나중에 등장한 PE와는 달리 그런 구분은 존재하지 않으며 헤더, 세그먼트 테이블, 리소스 테이블, 이름 테이블 등 미리 정해진 정보가 순차적으로 쭉~ 등장하는 형태입니다.

kernel, user, gdi처럼 내가 참조하여 import하는 다른 모듈의 API에 대한 정보는 있지만 PE처럼 함수명이 그대로 기록되어 있지는 않고 그냥 서열 번호만 들어가는 것 같습니다. 또한 윈도우 1.x가 맨 처음에 파스칼로 개발되어서 그 영향을 받아서인지, export하는 심볼 이름들은 다 대문자로만 적혀 있고 대소문자 구분은 딱히 안 하는 걸로 보입니다. 물론 윈도우 내부 API가 SDK 형태로 최초로 정식 공개된 3.0 시절에는 이미 다 C언어 기반으로 바뀌었지만.

끝으로, NE에는 PE에 전혀 없는 개념인 name table이라는 게 있습니다. 프로젝트 빌드할 때 *.DEF 파일로부터 링커가 생성해 주는 테이블일 겁니다.
그것도 resident name, non-resident name이라 하여 언제나 메모리에 상주하는 것, 아니면 언제나 상주시키지 않기는 때문에(메모리 아끼기 위해) 불러오는 데 시간이 좀 걸릴 수도 있는 것으로 종류도 나뉘어 있습니다. 둘 다 자신이 export하는 함수들의 명칭 같은데 정확한 용도가 무엇인지, 그리고 또 왜 이런 식으로 분류를 했는지는 알 길이 없습니다. 인터넷으로도 이런 게 있다는 식으로 기계적으로 설명해 놓은 자료만 있지, NE 포맷을 왜 이런 식으로 만들 수밖에 없었는지 같은 친절한 설명은 정말 찾을 수 없더군요.

또한 이 테이블에는 꼭 export symbol만 들어가는 게 아니라, non-resident name의 1순위로는 이 프로그램의 full name도 같이 들어갑니다. 즉, 버전 리소스를 굳이 안 뒤져도 여기를 찾아봐도 “Microsoft Visual C++”, “FontMania” 같은 정보를 얻을 수 있다는 것이죠. 오늘날 쓰이는 PE에는 이런 정보가 없습니다.

윈도우 3.1의 기본 프로그램인 문서 작성기, 페인트 등의 EXE를 들여다보면 마치 DLL처럼 프로그램의 내부 함수로 추정되는 명칭(특히 윈도우/대화상자 프로시저)을 상당수 non-resident name table에다가 export해 놓은 것을 알 수 있습니다. PageInfoWndProc, DialogGoto, BroadcastChildEnum 등. 왜 이렇게 해 놓은지는 저는 16비트 윈도우 개발 경험이 없으니 알 길이 없습니다. 메모리가 캐 부족하던 시절에 아마 한 번 만들어 놓은 코드는 EXE, DLL을 불문하고 최대한 많이 재사용하려고 이렇게 한 게 아닌가 싶습니다.

그나마 resident name table은 거의 쓰지도 않는 거 같던데 왜 만들었는지도 모르겠고.. 수수께끼이군요. 참고로 32비트 시대로 와서는 리소스 같은 건 free 한다는 개념 자체가 없어졌습니다. 당연히 resident, non-resident 같은 구분도 전혀 필요 없죠.

대략 이렇게 NE 포맷에 대해서 살펴봤는데, PE까지 그대로 이어지고 있는 개념도 있는 반면 어떤 것은 완전히 다른 것도 존재한다는 걸 알 수 있었습니다. 역시 16비트와 32비트 사이에는 넘사벽 같은 gap이 있는 듯이 보입니다.

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/48

Leave a comment

몇 가지 지론

오랜만에 플게에 이런 이슈가 나와서 우리말 쪽으로도 글을 써 본다.

1. 서로, 스스로를 부사가 아닌 명사로 쓰는 것은 잘못됐다.
OK. 공감함.
  서로가 서로를 배려해야 한다. (X)
  각자(우리)가 상대를 배려해야 한다. (O)

  네 스스로에게 문제가 있다. (X)
  너 자신에게 문제가 있다. (O)
O 같은 어휘를 생각해 내기가 귀찮아서 X로 단순화하고 있는 것 같다.

하지만 '모두'까지 부사로만 써야 하고 명사형이 잘못됐다는 것은 현실성이 없다.
모두를 안 쓰면 전부, 전체 같은 한자어가 대신 들어갈 수밖에 없음.

2. 그녀라는 말을 쓰지 말아야 한다.
응, 충분히 취지를 이해하며 가능한 한 다른 걸로 표현을 바꿔 쓰고 싶은데 전혀 안 쓸 수가 있나?
특히 성경 번역 같은 거 할 때.. 한국어에 she 같은 개념 자체가 없었고 이제는 필요해졌는데 어떡하라고?

3. '-에 있어서'란 말을 쓰지 말아야 한다.
OK. 정말 장황한 군더더기이고 '더 이상'만큼이나 안 쓰고 지냄.

4. 역할, 입장, 불구하고(despite, in spite of) 같은 말도 쓰지 말아야 한다.
글쎄. 한동안 구실, 관점, though 같은 다른 표현도 써 봤지만 전자는 후자하고 의미가 다른 면모가 있다.
완전히 안 쓸 수는 없을 것 같으며, 특히 이런 문제와 관련하여 본인의 고민은 도대체 일본과 한국이 공용하는 한자어들 중 어떤 건 괜찮고 어떤 건 써서는 안 되는지 판단하는 그 잣대가 불분명하다는 것이다. 이건 판단 보류.

5. 애매하다와 모호하다를 구분해야 한다.
OK. 좋은 지적.
  공연히 애매한 사람을 들볶다..
  의미가 너무 모호(한자어)하고 막연하다.

6. '의'자 붙이는 거 자제해야 한다.
가능한 한 지키려고 노력하지만, 싸그리 몰아낼 수는 없다.
'의'자 안 붙이고 링컨 대통령의 "국민의, 국민에 의한, 국민을 위한 정치"를 번역할 수는 없는 노릇이 아닌가.
한국어는 이런 점에서 표현력이 무척 떨어지는 면모가 있다.
'A의 평면 B로의 정사영'... 영락없는 영어/일본어 번역투인 것은 알지만 도대체 이보다 더 간편하게 어떻게 번역할 수 있겠는가?

7. '보다'를 주의해서 써야 한다.
  보다 나은 미래 (X)
  네가 나보다 낫다 (O)
OK. X는 영 어색하고 기초적인 우리말 문법 관념도 없이 생겨난 표현임을 인정한다. '(좀)더'만 써도 충분하죠.

8. 했었다 같은 이중 과거
순화 운동가들이 보면 펄쩍 뛰고 노발대발할 말투인데..
원래 한국어에는 없던 시제 표현을 확장해서 받아들인 거라고 볼 수 있지 않을까? "간 적이 있다"를 줄여서 "갔었다"라고.. 굳이 배척할 필요는 없다고 느낀다.

9. '가지다' 남발
OK. 한국어의 정서와 명백하게 이질적인 own, have 직역투는 자제염..;;
쓰기 전에 한번 생각을 해 보고 쓰자.
임신하면 아이를 배는 거지 아이를 갖는 게 아니다.
행사를 가지는 건 너무 심했잖아!

이것 말고 또 무슨 예가 있을까?
본인은 고등학교 시절에 이 오덕 선생, 대학교 시절에 이 수열 선생님의 우리말 순화 책을 섭렵한 경험이 있다.
100% 공감하지는 못하는 사항도 있지만 어쨌든 우리말의 실태에 대해 많은 생각을 일깨워 준 좋은 내용이었다.

스스로 판단하기에 OK라고 결론을 내린 사항들은 나름대로 이 홈페이지 열 무렵부터 그대로 지켜 왔다.
지금은 한말글 정신이 투철하던 2001~02 시절에 비해서는 많이 타-_-락해서 본인 쓰는 글에 한자어, 영단어도 예전보다 많이 들어간 편이지만, 그래도 감각 자체를 잃어버린 건 아니다.

나의 원칙은 간단하며 실용성을 지향한다.

- 한국어가 의미가 잘 구분되고 문법에 원칙이 있는 언어가 되는 방향으로: 다르다/틀리다는 반드시 구분해서 써야 한다. '더 이상' 같은 말을 쓰지 말아야 한다.
- 청각적으로 구분이 잘 되는 방향으로: 그래서 한글 전용 지지이다.
- 그리고 가능하면 짧고 간결하게
- 그리고 가능하면 토박이말에 우선순위: 어설픈 외래어 순화보다, 이미 있던 순우리말부터 먼저 퍼뜨리고 써야 한다.

4번을 제외하고 위의 세 가지 대원칙에 역행하지 않는다면 외래어나 번역투도 다른 우리말 순화 운동가들에 "비해서는" 그렇게 배척하지 않는다.
우리말이 영어처럼 수동태가 발달해 있지 않고 자주 쓰이지 않는 것은 사실이나 우리말에 수동태에 해당하는 표현이 없어서 좋을 것도 없는 건 사실이지 않은가.

물론, 번역투 때문에 말이 장황하고 거추장스러워지는 것은 분명히 경계한다. 또한 외래어나 외래 문체가 전혀 필요하지 않고 이미 멀쩡히 잘 쓰이던 우리말 표현까지 왜곡되고 파괴되는 것 역시 막아야 할 것이다.

우리말과 글 쪽의 홍보/계몽은 이렇듯 분명한 원칙과 체계를 갖추고 추진해야 쓸데없는 논쟁과 반감에 휩싸이지 않는다.

그리고 "비판을 하려면 수긍할만 한 대안을 제시하라." 주의이다.
그런 거 없이 무조건 뭐 일본식 한자어니까, 번역투란 이유만으로 쓰지 말자는 주장은 그냥 가능한 한 기피하는 고려 수준은 될 수 있어도, 적극적으로 안 쓰지는 않는다.

내가 또 하나 주장을 하는 걸로 글을 맺겠다. 나름대로 이 바닥에 짬밥도 있기 때문에 응용하는 것이다.

※ '기존'은 '예전'이 아니다. 제발 똑바로 쓰자.

- 현존, 실존 이런 단어하고 똑같은 용법으로 써야 하는 말이다.
- "기존에 있던 것들은 다 지워라" 이런 말... 정말 한숨만 나온다. "기존하는 것들은" 아니면 "예전의 것들은"이라고 쓰는 게 낫다.

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/47

Leave a comment

요세미티 국립 공원과, 샌프란시스코 일대의 관광 사진부터 먼저..

사용자 삽입 이미지

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

(1)

모레 아침이면 벌써 귀국이다. ㅠㅠ (여기는 지금 금요일 저녁)
내일은 멀리는 안 나가고 쉬면서 선물 쇼핑 위주로 시간을 보내게 될 것 같다.
한국은 또 환율이 워낙 올라서, 이거 귀국 후에 남은 달러를 되팔아도 차익 챙길 수 있을 정도가 돼 있구나. -_-;;

민박을 한 집안이 다 크리스천 가정이었다.
LA에서 만난 분들은 아예 매주 우리 서울 교회 목사님하고 잘 알고, 설교를 정기 구독하는 KJV 신자들이니 노선이 완전 일치한다. 그러니 그 교회 다니는 청년이 미국 방문한 거니까, 이거 뭐 일면식인 사람들하고도 어지간한 친척 이상으로 친밀하게 지낼 수 있었다.

샌 프란시스코에서 만난 가정도 KJV까지 일치는 아니지만 꽤 열심히 믿는 장로교 집안이었다. 이것만으로도 마음이 굉장히 편했다.

금문교를 비롯해 볼 거 다 봤다.
말로만 듣던 실리콘 밸리와, 스탠포드, UC 버클리 대학도 다 눈도장 찍고 사진 찍었다. 둘은 서로 사립, 공립이라는 차이도 있거니와 캠퍼스 분위기가 서로 굉장히 다른 것 같았다.

프리웨이 저 너머로 보이는 저 건물이 말로만 듣던 휴렛 패커드, 야후의 본사라니 감개무량했다.

(2)

무지로 인해 한 가지 실망한 것.
샌 프란시스코에 UC 버클리 대학이 있고,
매사추세츠 주에 버클리 음악 대학은 따로 있다.
한글로는 구분되지 않으나 영어 스펠링이 서로 다르다. Berkeley vs Berklee.. -_-;;
내가 가 본 곳은 당연히 전자..

사용자 삽입 이미지
(스탠포드 대학과 라이벌 관계이다. 참고로 스탠포드 대학은 아래..)

사용자 삽입 이미지

버클리라고 해서 Looking for you의 작곡자 MALTA님이 거쳐 간 학교를 이 기회에 성지 순례로 방문하는가 싶었지만 그건 아니었다. T_T
후자뿐만 아니라 전자도 재즈 쪽이 강하다고 하더라만..
아마 송 영주 씨가 거쳤다는 버클리 대학도 전자가 아니고 후자이지 싶다. 한글로만 적으면 구분 못 한다. 전자를 "UC 버클리"로, 후자를 "버클리 음악 대학"으로 구분해 줘야 한다.

(3)

혼자 이렇게 훌쩍 외국으로 떠나는 것도 그렇게 어려운 일이 아니란 걸 알게 됐다.

미국 가기 전까지는 이민에 대해서 부정적인 얘기를 주로 많이 들어 왔다.
의료 제도가 완전 개떡이다,
유색 인종에 대한 정서적 차별이 여전하고 치안도 형편없다, 미국도 이제 예전의 미국이 아니다,
그저 교육비, 기름값 비싸다는 이유 정도만으로 한국 떠나고 싶다는 식의 소리는 꿈에도 하지 마라.

처럼.

하지만 여기서는 약간 다른 의견도 들었다.
여기에 잘 정착해 계신 분들은 하나같이 한국보다 여기가 살기 좋다고 말한다.
(한국과는 달리) 법과 원칙이 통한다,
연줄이 아니라 실력만 있으면 인정 받을 수 있다,
국민성이 훨씬 더 선진적이다,
굳이 대도시에 안 매달려도 푸근하게 잘 살 수 있다 등.

그리고 만난 분들로부터도,
너처럼 영어 걱정 없고 미국 음식 거부감 없고
더구나 컴퓨터 쪽 하는 사람은, 여기 와서 공부 계속하다 영주권 받고 걍 정착하라는 제안도 적지 않게 받았다. ㄱ-

단순히 개인의 영달 차원이 아니라
유능한 사람들이 이민 듬뿍 가 줘서 전세계에 코리아 타운 건설하고 한국인들이 정착해서 살 수 있는 터전을 마련하는 게 애국 행위라는 얘기까지 나오더라.
실제로 재미 교포들이 국내 수출 자동차나 전자 기기도 듬뿍 사 주고, 외환 위기 때 달러도 굉장히 많이 보태 줬다고 한다.
스타로 치면 끝없는 멀티 확장 뻘 되겠다.

에휴, 하지만 본인은 유학 가기엔 학부 성적도 상당히 안 좋고,
무엇보다도 한글 입력기, 한국 철도 등..
내 전문 특기 분야 자체가 그다지 미국에서 인정 받을 만한 분야가 아니니, 말씀은 고맙지만 현실성은 별로 높지 못하다. -_-;;

(4)

- 도로에 가끔씩 XING 이렇게 적혀 있는 게 도대체 뭐지? 한어병음 표기 같아서 중국식 지명이나 도로명인 줄 알았는데 LA뿐만 아니라 샌 프란시스코에서도 보인다.
나중에 알고 보니 CROSSING (횡단)을 줄여 쓴 것이었다. ㅜㅜ
미국 도로 표지판에도 그런 거 굉장히 많다. BLVD, RD, INTL
X는 Z소리도 되고, 음절 말미에서 ks 소리도 되고, 저런 의미도 갖고 있다. ㅜㅜ #이 sharp도 되고 number도 되는 것처럼.

- 흰 달걀을 미국 가서야 거의 10년만에 처음 본 거 같다. 우리나라는 묘하게 흰 달걀이 완전 자취를 감추고 말았다. 살색 달걀하고 맛, 영양이 아무 차이가 없는데 소비자 취향이 한데 우루루 쏠려 버렸기 때문이다.

- 미국에서 어디 돌아다니느라 차 안에서 보낸 시간이 정말 어마어마했다. 만약 다음에 또 미국 갈 일이 있을 때는 차에서 들을 수 있는 오디오 내지 MP3 씨디 하나 좀 구워 가야겠다. 오랫동안 Looking for you 못 들으니 금단 증세 때문에 좀 괴로웠다. ㅜㅜ
10년 안으로, 이번 여권과 비자 유효 기간이 끝나기 전엔 또 갈 기회가 있으려나? 더구나 미국 비자는 면제 직전에 꽤 번거롭게 받은 건데, 한 번 방문만으로 끝내 버리면 아까우니까. -_-


Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/46

Comments List

  1. 특백 2011/10/11 07:30 # M/D Reply Permalink

    정확하게 딱딱 떨어지지 않고 언문일치가 완전히 파괴된 영어 스크립트 같은 것의 장점이 여기 있군요.

    Berkeley 對 Berklee

    1. 사무엘 2011/10/11 23:34 # M/D Permalink

      뭐, 한자를 옹호하는 대표적인 논리도 동음이의어 식별이니 말 다 했죠.

      다만, 학문 용어는 아예 말을 다른 걸로 바꿀 게 아니라면, 엄밀하고 정확하게 익혀야 합니다. 쓸 때 한자를 남발하지는 않더라도 최소한 어원이 무엇인지 정도는 알아야 합니다.

Leave a comment

대형 산불 (2008/11/16)

여기 낮엔 완전 더워서 초여름 같습니다.
여름 같은 날씨에 겨울 같은 낮 길이는 태국에서도 경험한 적 있지만 참 적응 안 되네요.

그런데.. 뉴스 보셨나 모르겠는데 LA 일대에 대형 산불이 났습니다.

오전에는 해수욕장 구경 갔다가
오후에는 불 구경 하게 됐습니다.

지인 집 인근 야산까지 불길이 치솟더군요.
평소에 안 불던 바람도 어찌나 거세게 불던지.

소방수들도 불 끌 엄두를 못 내고 그저 민가로 불길이 번지는 것만 방어하는 수준.
그래도 이미 집도 최소 수십 채가 불탔다고 합니다.
뒷산의 불은 껐지만 옆에 여전히 불길이 잡히지 않아서 결국은 경찰에게서 대피 명령이 떨어졌습니다.

설마 지인 집까지 불이 옮겨붙을 것 같지는 않지만 하필 제가 온 날 LA 안에서 제가 머문 지점에서 참 별난 일을 겪게 됐습니다.

오늘 낮에 LA에 비행기로 도착한 사람이라면 시꺼먼 구름이 상공을 뒤덮은 광경을 목격했을 것입니다.

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

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/45

Leave a comment
관광 하나 갔다오고 나니까 벌써 이번 주도 끝이 슬슬 보이는군요. 먼저 그랜드 캐년.
사용자 삽입 이미지
라스베이거스의 멋진 일출 장면!
사용자 삽입 이미지

다음은 캘리코의 폐은광촌. 고전 게임 <금광을 찾아서>의 한 장면이 생각나기도 합니다.
BannerMania라는 옛날 도스용 프로그램을 보시면 Frontier(개척자)라는 폰트가 있는데, 그 폰트에 왜 저런 이름이 붙었는지를 이런 곳에 가 보시면 금방 알 수 있습니다.
사용자 삽입 이미지
사용자 삽입 이미지
하늘 하나는 정말 맑고 푸르고 좋습니다. 우리나라 가을 하늘 뺨칩니다.

다음 주 월요일엔 다른 곳으로 이런 스케일의 관광을 하나 더 갑니다.
동부도 가 볼까 하는 욕심이 슬그머니 들기도 하고요;; (너무 늦었지만)

여기 물가는,
식당에서 파는 소주 한 병이 10달러가 넘음.
머리 깎는 데 20~30달러
어느 프리웨이 편의점에서 파는 신라면 하나가 봉지, 컵 공히 3달러. (한국에서 그 가격이면 5개들이 박스를 산다-_-)
쵸코우유 하나가 2달러. -_-

또한 사람의 서비스를 받는 거의 모든 일에는 팁도 준비를 해야 하기 때문에
미국 가서 돈 쓰다 보면 1$ 지폐가 굉장히 많이, 빨리 없어집니다.
환전할 때, 지폐 수를 최소화하는 방법으로 돈을 받지 말고, 소액 지폐를 많이 만들어 두면 편합니다.

뭐 그건 그렇고,
오늘은 막간을 이용해서 LA 지하철을 잠시 시승했습니다. Metro라고 부르는데요,
코리아타운 구간에서는 Red/Purple 두 라인이 윌셔 가를 지납니다.

- 번호나 이름 없이 색깔만으로 노선을 단순하게 구분함. Red/Purple/Gold line
- 출구 번호도 없다. 그냥 출구별로 Exit to street, exit to ... 이런 안내 표지판만 있다.
- 차내 안내 방송은 영어와 스페인어로 나온다.
- 승강장 전광판은 올컬러로 다음 열차의 도착 시각이 찍혀 있고 무척 잘 돼 있다. 최근에 시설 개편을 한 거 같다.
- 거의 모든 구간을 단선 쌍굴로 파고 터널식으로 짓기라도 했는지 터널이 둥그렇고 섬식 승강장이 대부분이다. 하지만 실제로 지하철은 그다지 깊지도 않으며 현지인의 말에 따르면 건설 당시에 여전히 개착식으로 땅도 파헤쳤다고 한다. 그런데 지하철이 생긴 모습은 영 그런 형태가 아니어서 의아스러움.
- 승강장에 스크린 도어는 없다.
- 1회용 편도 승차권은 1.25$이며 마그네틱 카드 형태이다. 유효 시간은 2시간이다.
- 현금 일색인 우리나라와는 달리 지하철 승차권도 신용 카드 결제가 가능하다.
- 내가 이용한 역만 그런지는 모르겠으나, 특별히 개 집표 게이트가 없었다. 그냥 승무원이 불시 검문만으로 승차권 검사를 하는 듯하다.

- 전동차는 구동음을 들어 보건대 VVVF 차량과 쵸퍼 차량이 둘 다 운영 중인 것 같다.
- 도로와 마찬가지로 전구간 우측 통행이고 전차선은 선로 아래에 있다.
- 4량 1편성이지만 승강장의 길이는 그보다 더 긴 5~6량 1편성 기준이다.
- 롱시트가 아니고 우리나라의 CDC 통근열차 같은 정방향 좌석도 있다. 그리고 객차 사이에 이동이 되지 않는다.
- 선로는 장대 레일이 아니며 승차감이 그렇게 좋은 편은 아니다.

LA 시에서 지하철 때문에 생기는 적자는 정말 무지막지한 수준이라고 합니다. 순전히 못 사는 사람들 복지를 위해서 울며 겨자 먹기로 억지로 어쩔 수 없이 운영하는 거라 하더군요.
열차 UI가 무척 단조롭고, 서울이나 도쿄처럼 전철 동호인이 생길 만한 매력은 없다는 결론을 내렸습니다.

3년 전에 시승했던 방콕 지하철과 비교하면,
- 단선 쌍굴 섬식 승강장가 주된 구조인 것은 일치하나, 방콕 지하철은 LA와 달리 전구간 스크린도어가 있습니다.
- 방콕 지하철 역시 4량이고 전차선이 아래에 있는 것은 같습니다. 그러나 방콕은 우리나라 지방 지하철과 마찬가지로 객실 간 이동이 용이하고 차량이 거의 연결된 거나 마찬가지이지만 LA는 그렇지 않습니다.
- 방콕은 영국과 일본처럼 철도까지 완전 좌측 통행이지만 LA는 그렇지 않습니다.

아 그나저나.
미국은 도로 안내 표지판에 단일 언어밖에 안 나오는 데다 알파벳 자체가 모아쓰지 않고 풀어쓰는 문자이다 보니
표지판 하나는 정말 글자가 큼직하고 시원스럽고 읽을 맛이 나더군요.

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/44

Leave a comment
미국 가서 최초로 인터넷 접속..

예정 시각보다 50분 가까이 일찍 현지에 잘 도착했습니다.
11월 초에 서머 타임이 풀리기 때문에 그거 때문에 시각에 착오라도 생긴 게 아닌가 생각했을 정도입니다.
제트 기류가 시속 거의 300km를 넘는 속도로 불어 준 덕분인지, 순항 중일 때는 비행기가 시속 1200km를 넘는 속도로 날기도 했으니 이 정도면 음속 돌파 수준 아닌가요? =_=

이코노미 석으로 다리, 허리, 엉덩이가 본인이 경험상 견딜 수 있는 시간의 한계는 4시간 정도. -_-
하반신에 피가 잘 안 통하니 굉장히 힘들었습니다.
KTX 터널 안에서는 좀체 겪을 수 없던 이명 현상.. 비행기가 착륙할 때는 고막에 진짜 고통이 느껴졌습니다.
입을 벌리고 있으면 괜찮아진다고 하더군요. 저는 그건 몰라서 그저 귀 틀어막는 수밖에 없었음.

뉴욕 정도까지 가면 완전 북극 쪽으로 그린란드 내지 알래스카까지 빙 걸쳐서 가는데(그게 구면상에서의 최단 거리임.) LA이니 그냥 태평양만 쭉 경유하여 목적지에 도착했습니다.

지인 좀 만난 후 지금은 2박 3일 그랜드 캐년 여행사 관광을 가 있습니다.
라스 베가스의 모 호텔에서, 남 놋붉 빌려서 잠시 글 쓰는 중.

미국은,
1. 끝없이 펼쳐진 허허벌판 위로 뻗은 도로
2. 3층 이상 건물을 도무지 찾을 수 없는 시가지 내지 주거 구역
3. 서울 같은 고층 빌딩이 즐비한 도시
사용자 삽입 이미지

대략 이런 양상 같습니다. 뉴욕 내지 라스 베가스는 3정도 되겠지만
LA는 더구나 지진 위험 지대이기도 해서 대부분이 1, 2 타입입니다.
(내진 설계 하면 건축비 무지 비싸진다 함)

여기도 철도가 없지 않습니다. 고속도로 타다 보면 비록 원시적인 단선 비전철이긴 하나, 철길을 어렵지 않게 볼 수 있고
사용자 삽입 이미지

LA도 나름 지하철이 지나기도 하는 곳입니다. 지도로 위치는 못 봤지만 고속도로 중앙으로 지상 전철이 지나는 것도 봤고요.
사용자 삽입 이미지

내일은 드디어 그랜드 캐년으로 고고씽입니다.

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/43

Comments List

  1. 소범준 2012/01/06 20:56 # M/D Reply Permalink

    우리나라에선 지하철 지상 역들 중에 일반 도로 중간(그것도 교량 사이)에 위치한 경우만 있는데, 미국은 저렇게 고속도로 중간에도 오는 경우가 있네요. ㅎㅎ 역시 미국은 상상 이상으로 각양각색이군요.

    LA도 학창시절 과학 시간에 그 유명한 '지진대'에 있다는 것을 배웠습니다만, 요샌 그런 개념도 무덤덤 하더군요.
    하나님의 말씀의 위력 때문인지 싶기도 합니다만.

    1. 사무엘 2012/01/09 09:18 # M/D Permalink

      일반 도로 중간에 있는 대표적인 역은 2호선 강변 역이죠. 독특한 구조입니다. 그쪽 일대의 만성적인 교통 혼잡을 감안하면, 지하철역에서 동서울 터미널 사이도 지하로 연결이 돼야 한다는 생각이 듭니다. (테크노마트 방면뿐만 아니라)

      그리고 말씀하신 것처럼 LA는 지진 안전 지대가 아닙니다.
      그래서 고층 건물을 건물을 지을 때 내진 설계가 의무화돼 있습니다.
      하지만 그럴려면 돈이 많이 들고... 안 그래도 미국은 땅이 무진장 넓고
      그러니 좁은 도심을 제외하면 건물들이 다 2~3층을 안 넘고 넓게 퍼져 있습니다.

      거기는 어차피 대전-서울뻘 거리도 우리나라로 치면 그냥 분당-서울 정도의 통근권에 드는 곳이니까요. 그것도 전철도 아니고 다 자가용으로..! -_-

Leave a comment

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/42

Comments List

  1. 밝은터 2010/07/10 13:08 # M/D Reply Permalink

    안녕하세요. 좋은 글 감사합니다. 한글 2002에 히브리어로 쓴 글이 있는데 이를 MS 워드로 옮기려니 깨져 나오네요. 혹시 방법을 아시는지요...한컴측에서는 솔루션이 없는 듯합니다. 알려주시면 대단히 감사하겠습니다.

    1. 사무엘 2010/07/10 06:10 # M/D Permalink

      반갑습니다. (아주 알찬 블로그를 운영하시는 분이네요. ^^)
      2002라면 아직 아래아한글이 아랍이나 히브리어 같은 complex script를 제대로 지원도 안 하던 시절입니다. 그렇기 때문에 그 시절에 맞춰 편법으로 만들어진 히브리어 텍스트는 MS 워드 같은 곳에서는 분명 제대로 표시되지 않을 것이고 이렇다할 해결책이 있을 것 같지는 않습니다.
      2002를 안 쓴 지 오래 되어 잘은 모르지만, 텍스트 배열 순서 같은 걸 수작업으로 바꿔 줘야 될 겁니다.

  2. 밝은터 2010/07/10 13:05 # M/D Reply Permalink

    친절한 답변에 감사합니다.
    "텍스트 배열 순서 같은 걸 수작업으로 바꿔 줘야"라는 말씀의 의미가 어떤 것인지요. 변환은 불가능하다는 말씀이시겠죠? MS 워드가 아닌 다른 파일로도 전환이 불가능한 것 같더군요. 감사합니다!!!

    1. 사무엘 2010/07/11 06:33 # M/D Permalink

      요즘 아래아한글(2005부터)이나 MS 워드는 왼쪽에서 오른쪽으로 순서대로 쳐도 자동으로 히브리어가 오른쪽에서 왼쪽 방향으로 출력됩니다. 그러나 과거 아래아한글은 그렇지 않았어요. 그런 동작 방식의 차이가 깨지는 원인이 아닐까 생각하며, 그 옛날 방식대로 잘 보이게 입력된 히브리어를 나중 방식대로 다시 변환하는 유틸리티 같은 건 제가 아는 바가 없다는 뜻입니다.

  3. 밝은터 2010/07/11 08:17 # M/D Reply Permalink

    아..그렇군요. 많은 걸 배웠습니다. 감사합니다!

Leave a comment

비주얼 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

Trackback URL : http://moogi.new21.org/tc/trackback/41

Comments List

  1. 김 기윤 2011/01/06 15:34 # M/D Reply Permalink

    저는 6.0->2008->2010->2005 라는 꽤 괴이쩍은(..)순서로 접했습니다.

    요즈음은 컴퓨터가 받쳐주고, Visual Studio 2010이 가장 편하기 때문에, 새로 시작하는 프로젝트라면 별 고민 없이 2010 으로 하는 중입니다.

    1. 사무엘 2011/01/06 18:41 # M/D Permalink

      저는 4.2부터 2008까지, 5.0과 7.0만 skip하고 비교적 점진적으로 썼습니다.
      2010로는 과연 언제쯤 업글하려나.

Leave a comment
설치 프로그램 같은 부류를 작성하다 보면, 지금은 다른 프로세스에 의해 사용 중이기 때문에 건드릴 수 없는 파일을 다음 재부팅 때 교체(업그레이드 설치) 또는 삭제(제거)되도록 설정해야 할 필요가 있다.
(사용 중이어서 잠긴 파일도 놀랍게도 rename과 같은 드라이브 안의 이동은 가능하다. 단지 드라이브 바깥으로의 이동이나 삭제, 교체, 덮어쓰기가 안 될 뿐이다.)

이 분야에 관한 한 윈도우 API는 무척 자비심이 없었다. 윈도우 NT 계열과 9x 계열이 설정하는 방법이 서로 완전히 달랐기 때문이다.
전자의 경우 MoveFileEx라는 걸출한 API가 있어서 MOVEFILE_DELAY_UNTIL_REBOOT 플래그만 지정해 주면 됐다. 다음 재부팅 때 교체/삭제될 예정인 파일 목록은 레지스트리에 별도로 관리되는데, 이 위치 역시 MSDN에 문서화돼 있다.

이게 제일 깔끔한 방법인 반면 윈도우 9x에서는 이 방법을 쓸 수 없다.
윈도우 9x는 부팅 직전에 업데이트 또는 삭제해야 하는 파일의 리스트를 윈도우 디렉토리에 있는 wininit.ini 파일로부터 읽는다. 거기에 뭔가 의미 있는 값이 있다면, 바로 그 때 “Windows가 일부 구성요소를 업데이트하고 있습니다. 몇 분 정도 시간이 소요될 수 있습니다”란 친근한 메시지를 부팅 중에 텍스트 모드에서 영어로 잠시 보여준다. 아마 9x 유저들은 이 메시지를 기억할 것이다.

이 처리를 다 마치고 나면 wininit.ini 파일은 wininit.bak로 개명된다.
이 일을 하는 프로그램은 wininit.exe라는 프로그램이다. 그런데 얘는 본격적인 32비트 운영체제가 로딩되기 전에 잠깐 실행되는 완벽한 16비트 도스용 프로그램일 뿐이다. 그래서 wininit.ini 리스트에는 긴 파일 이름(LFN)을 쓸 수 없다는 무지하게 불편한 제약이 걸린다. 파일 이름이야 그렇다 치지만 폴더 이름까지 공백 하나 표현 못하니 얼마나 불편하리요.

지울 때야 LONGFI~1.TXT 이렇게 지정하면 되겠지만 옛 파일을 LFN 방식의 새 파일로 깔끔하게 교체하는 건 불가능하다는 뜻이기도 하다. 정 하고 싶으면 rename을 부팅 때 강제로 해 주는 다른 프로그램을 RunOnce 이런 레지스트리에 넣기라도 해야 한다.

또 하나 고려할 만한 점으로..
인스톨러가 프로그램을 설치/제거하다가 일부 파일을 건드리지 못했다면 “다음 프로그램이 이 파일을 사용 중입니다” 이러면서 파일을 사용 중인 프로그램 나열까지 띄워 주면 무척 좋을 것이다. (MSI는 실제로 그렇게 해 주고 있다.)

이 기능을 직접 구현하려면 현재 로딩되어 있는 모듈(EXE/DLL)의 리스트를 얻어 오는 API를 써야 하는데 이 역시 윈도우 9x와 NT가 사용하는 API 계보가 완전히 달랐다. 전자는 ToolHelp라고 불렸고 후자는 Process Status API였는데 다행히 윈도우 2000에는 9x의 ToolHelp API도 추가되어서 API가 일종의 통합을 이뤘다.

한편, 저런 이유 때문에 일부 파일을 결국 교체나 삭제를 못 한 경우 인스톨러는 “작업을 완료하려면 재부팅이 필요합니다. 지금 하시겠습니까?”라고 묻는 게 일반적이다. 하지만 대다수의 사용자는 귀차니즘에 입각하여 ‘아니요’를 고르고 만다.

그런데, 그렇게 재부팅을 미루고 언인스톨러를 종료했는데 그 상태에서 사용자가 그 프로그램을 다시 설치한 경우 꽤 문제가 된다. (변덕 한번 심하기도 하다. -_-)
잘 만들어진 인스톨러라면, 이 경우 교체하거나 삭제하기로 요청해 놓은 파일의 예약을 도로 취소해야 한다. 안 그러면 그렇게 재설치 한 후 다음에 운영체제를 재시작하는 순간 재앙이 벌어질 수도 있다.

따라서 원칙대로라면 건드리지 못한 파일이 없더라도 인스톨러는 wininit.ini 같은 목록을 뒤져 봐야 한다. 그것도 운영체제 계열 별로 완전히 다른 접근 방식으로 말이다. 요즘이야 9x 계열은 사실상 신경 쓸 필요도 없어지긴 했지만. 참고로 MSI가 저것까지 똑똑하게 알아서 처리해 주는지는 테스트 안 해 봤다.

결론은, 인스톨러는 완성도 높게 잘 만들려면 현 프로그램의 설치/제거 상태부터 시작해서, 저런 지저분한 API 차이까지 감안해 가며 귀찮게 따져야 하는 게 무지하게 많다는 것. IME 하나 만들려면 지저분한 잡일이 너무 많으니 MS에서 TSF를 개발한 것처럼, 저런 작업을 표준화하고 자동화하기 위해서 MSI라는 것을 안 만들 수가 없었을 것이다.

MSI는 파일을 복사하고 쓰는 제 본연의 기능 면에서 완성도는 무척 높은 것을 인정하지만, 같은 MS에서 개발한 AppLocale 같은 프로그램하고도 UI가 충돌을 일으킨다는 점은 심히 유감이다. -_-

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/40

Comments List

  1. 란마 2010/11/16 11:25 # M/D Reply Permalink

    자동업데이트 구현하고 있습니다.
    말씀하신대로 변덕이 심한 유저를 고려하자니 머리가 복잡해지는데요..
    현재 변경할 수 없는 파일들 때문에 재부팅 후 업데이트가 완료되는 것을
    구현하려고 합니다.
    MoveFileEx를 이용하는 방법과..
    자체적으로 작은 실행 프로그램을 만들어서 레지스트리의 RunOnce에 등록해 두고 윈도우 시작 시에 실행하면서 직접 파일을 엎어치는 방법이 떠오르는데요, 용묵님은 어떤 방식이 괜찮다고 보시나요?

    첫번째 방법은 단지 파일복사만 되는거라, 레지스트리 등록/해제같은 부가적인 일을 할 수 없는거 같습니다(혹시 방법이 있나요?)

    두번째 방법은 '업데이트 대상이 되는 프로그램'이 '작은 실행 프로그램'보다 먼저 실행될 가능성이 존재하는거 같네요..
    실제로 저같은 경우도 윈도우 시작되고 마우스 컨트롤 되자마자 바로 원하는 프로그램을 더블클릭하는 급한 성격이라..ㅡ.,ㅡ;
    -> 지금 테스트해보니 RunOnce에 등록되어 실행된 프로그램이 종료되기 전까지 바탕화면에 아이콘 안뜨고 대기하고 있네요. 두번째 방법으로 하는게 좋겠네요..
    그런데 RunOnce에 등록된 프로그램이 어떤 이유로 종료되지 않는다면... 흠.. 안전모드가 있군요 ㅎ

    1. 사무엘 2010/11/17 01:06 # M/D Permalink

      윈도우 프로그래머이시군요. 반갑습니다. ^^
      아무래도 파일을 지우거나 위치 이동, 대체만 하는 건 MoveFileEx가 간편합니다. 그러나 좀더 복잡한 작업이 필요하다면 작은 별도의 프로그램 실행+RunOnce가 필요할 것 같습니다. 단, 후자의 방법을 사용하는 경우, 작은 프로그램 자신을 제거하는 테크닉 같은 것도 필요해지니 경우의 수는 더 늘어나겠죠.

      설치/제거라든가 자동 업데이트 기능을 손으로 직접 짜려면 요즘은 또 UAC나 권한 같은 쪽도 알아야 되고.. 너무 복잡해요. 권한이 없으면 Program files 디렉터리의 파일을 건드리질 못하게 되니까..;;

Leave a comment

날개셋 모듈 설명

※ ngs3.dll (since 1.0, 2000)

<날개셋> 한글 입력기 커널이다. 문자열 처리, 옛한글 코드 변환, 한글 입력 오토마타 같은 본연의 임무부터 시작해서 자체 한글 비트맵 폰트 출력, 에디트 컨트롤, 심지어 제어판 UI도 들어있고 3.0부터 추가된 수식 해석과 XML 해석까지 다 담당하고 있다. <날개셋> 전체 소스 코드의 절반이 약간 넘는 분량을 이 모듈이 차지한다. 이제 UI 엔진까지 얹으면 커널의 덩치는 더욱 커질 것으로 보인다.

※ ngsedit.exe (편집기. since 1.0, 2000)

<날개셋> 한글 입력기는 처음엔 이런 자체 한글 MDI 에디터로 출발했다. <날개셋>이라는 커널의 기능을 가장 이상적으로 활용할 수 있는 전용 환경이자 가장 기초적인 프런트 엔드가 이 프로그램인 셈이다.

※ ngsx.nip (기본 플러그 인. since 2.x, 2002)

플러그 인이라는 개념은 본인이 거의 2.0을 개발하던 시절부터 생각하고 있었다. ngs3이라는 호스트가 기능을 확장할 수 있는 여러 프로토타입을 제시하면 플러그 인은 그 프로토타입대로 다양한 기능을 구현하여 호스트가 이를 끌어다 쓰는 것이다. 처음엔 텍스트 필터 정도만 액세서리 정도로 플러그 인이 담당하다가 이제는 빠른설정 도우미, 동시입력 스키마 등 다양한 분야에서 이 기본 플러그 인이 기능을 제공하고 있다.

※ ngsime.ime (외부 모듈. since 3.0x, 2004)

그저 편집기에만 머물러 있던 <날개셋> 한글 입력기는 3.0 버전대에서 외부 모듈이 개발되면서부터 진짜 활로를 텄다고 해도 과언이 아니다. 완전 생소한 분야이다 보니 초창기에는 온갖 불안정 문제, 버그에 시달렸으나 경험과 노하우가 쌓이면서 그런 문제들은 차츰 해결돼 갔다. 이 모듈은 단일 바이너리로 윈도우 95의 IME부터 비스타의 TSF 프로토콜까지 가장 세밀하고 탄탄하게 잘 지원하고 있다.

※ uniapi9x.dll (since 3.41, 2005)

윈도우 9x에서 윈도우 유니코드 API 호출을 받아 주는 자그마한 호환성 레이어로, 21세기 초에 MS에서 개발한 unicows (MSLU) 라이브러리와 동일한 역할을 하는 모듈이다. <날개셋> 3.0 개발 당시에 그 MS 솔루션의 사용을 검토했다가 뭔가 문제에 부딪쳐 도입을 포기하고, 대신 잠시 NT 계열 에디션과 9x 계열 에디션을 따로 배포했던 적이 있다. (배포 패키지 만들기가 무지하게 번거롭고 불편했음.-_-)

그러다가 3.41에서는 해당 기능을 자체 구현에 성공함으로써 <날개셋> 한글 입력기, 특히 외부 모듈은 플랫폼 계열을 완전 정복한 무지막지한 프로그램으로 거듭날 수 있었다. 이 모듈은 32비트 PE 포맷에 특화된 루틴이 들어있으며(x86 어셈블리까지는 아니지만-_-), 64비트 에디션에는 당연히 들어가지 않는다.

※ ngsconv.exe (since 5.0, 2008)

뭔가 변환과 관련된 모든 뒷바라지를 담당할 유틸리티로서, 5.0에서 첫 도입되었다. <날개셋> 3, 4 방식으로 저장된 입력 설정(유형, 글쇠배열 등 포함)을 새로운 5.0 방식으로 변환하는 것이 가장 기본적인 용도이며, 이 외에도 <날개셋> 3, 4 방식으로 저장된 변종 옛한글, 한양 PUA, 유니코드 1.x 방식 옛한글과 5.2 방식 옛한글 사이의 변환도 파일과 클립보드 모두 지원한다. 유니코드 상에서 현존하는 모든 옛한글 표현 방식을 중재하는 역할을 한다는 뜻이다.
시간이 흐르고 앞으로 한글 코드, <날개셋> 프로그램 체계가 또 바뀐다면 이 변환 유틸리티의 역할도 더욱 커질 것이다.

※ ngspad.exe / padspyxx.dll (since 5.3, 2009)

실행은 편집기 실행하듯이 EXE로 하지만, 기능은 외부 모듈처럼 여타 환경에서의 한글 입력 역할을 하는 제 3의 중간 계층에 속하는 프런트 엔드이다. 이 역시 거의 3, 4.x 버전 시절부터 상상을 하고 있었으나 여건이 안 되어 추진하지 못했다가 5.0에서 드디어 한글 코드 체계까지 정립에 성공한 뒤 추진하기 시작했다. 문자 입력 솔루션으로서 <날개셋> 한글 입력기의 위상을 완전히 새롭게 자리매김할 아이템으로 기대 중이다.

훅킹 기반으로 IME/TSF 동작 방식을 흉내내어 응용 프로그램에다 한글 조합을 전달하거나 키 입력을 속인다. 가령, 단축키까지 드보락 같은 다른 영문 글자판으로 완전히 바꾸는 것 역시 이 새로운 프로그램으로 가능한 것 중 일부가 될 것이다. 또한 <날개셋> 한글 입력기의 UI 엔진으로 구현한 각종 포인팅 장비 입력이나 화상 키보드, 문자표 등을 일반 프로그램에서 꺼내서 사용할 수도 있게 된다.

윈도우 95 이래 모든 운영체제에서 실행 가능한 다른 모듈과는 달리, 이 새로운 모듈은 동작 방식의 특성상 윈도우 2000 이상 전용으로 설계될 예정이다. 물론 이것도 사실상 아무 제약도 아니다.

※ padui.nip (since 5.3, 2009)

ngsX에 이어 드디어 두 번째로 개발되는 플러그 인이다.
현재 ngsime.ime의 내부에 들어있는 “후보 선택 UI”와 “화상 키보드” UI가 여기로 옮겨져서 외부 모듈과 ngsPad(가칭)가 공유하게 될 것이다. 그리고 한자 부수 입력, 문자표 같은 다른 액세서리가 추후 개발된다면 이 역시 이 모듈에 들어가서 편집기, 외부 모듈, ngsPad가 모두 공유하게 될 것이다.

※ NgsType.exe (타자연습 프로그램. since 2001)

<날개셋> 한글 입력기 1.x 버전대부터 개발되어 온 이 프로그램은 세벌식 자판의 보급과 저변 확대에 지금까지 큰 기여를 했다. 특히 90년대 말~00년대 초에 개발되었다가 지금 더 버전업이 되지 않고 있는 많은 타자연습 프로그램과는 달리 <날개셋>은 기능상 큰 변화는 없을지언정 꾸준히 버그 수정과 유지 보수가 돼 왔다. (비록 개발 우선 순위는 입력기 개발보다 언제나 뒷전이지만)

이 프로그램은 <날개셋> 한글 입력기에 포함되어 있는 애플릿이 아니라 입력기를 사용하여 따로 개발된 정식 애플리케이션(응용 프로그램)이다. 입력기와는 달리 MFC를 사용해서 개발되었고 재컴파일 가능한 소스가 공개되어 있다.

여타 프로그램에 비해 특히 주목할 만한 점은 정확도가 융통성 있게 계산된다는 것, 자체적인 문단 정렬 기능 덕분에 다양한 형태로 연습글을 배치할 수 있다는 것, 세벌식에 특화되어 제작된 게임 정도가 되겠다. 개인적으로 게임 그래픽 개선과 네트워크 연동이라는 두 숙제가 남았다고 본다.
세벌식 외에 다른 글자판의 ‘익힘’ 기능을 추가할 계획은 없다.

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/39

Leave a comment
« Previous : 1 : ... 143 : 144 : 145 : 146 : 147 : 148 : 149 : 150 : 151 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/05   »
      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:
1184509
Today:
297
Yesterday:
641