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

1. 그냥 기종에 상관없이 세벌식 자판만 평범하게 쓰고 싶으면

이미 설치되어 있는 MS IME만으로 충분하고 거기에 제가 개발한 '세벌식 파워업'을 덧붙이면 더욱 편리합니다.
오피스 2007이나 윈도우 비스타와 함께 설치되는 IME는 세벌식 최종 글쇠배열 오류도 고쳐져 있습니다.

2. 거기에 좀더 강화해서 모아치기도 쓰고 싶고 Shift+Space로도 한영 전환하고 싶고 동시치기, 영문 드보락, 세벌식 순아래, 안 마태 같은 마이너 글쇠배열이나 타자 기법을 써 보고 싶으면

새나루가 딱 좋습니다. <날개셋>보다 훨씬 덩치도 작고 UI도 간단해서 내게 필요한 기능만 바로 지정해서 쓰면 됩니다.
특히 새나루는 IME 차원보다 더 낮은 키보드 드라이버 후킹 차원에서 드보락 자판도 제공해서 한글과 같이 쓸 수 있습니다.

3. 하지만, 다음 조건에 하나라도 해당되면 <날개셋> 한글 입력기가 필요합니다.

- 2를 윈도우 9x 옛날 기종이나 아니면 아예 64비트 환경에서 쓰고 싶은 경우
- 옛한글을 쓰고 싶은 경우 (특히 세벌식으로.)
- 운영체제나 아래아한글의 각종 글쇠배열 드라이버를 불러와서 특수문자/외국어와 한글을 같이 입력하고 싶은 경우
- 한글 글쇠배열부터 시작해서 오토마타와 글자 결합 조건을 완전히 마음대로 고치고 싶은 경우
- 글자판 전환이나 한자 글쇠를 완전히 다른 걸로 지정하고 싶은 경우 (특히 윈도우 키 조합)
- 입력기 커널을 완전히 공유하는 유니코드 기반 자체한글 전용 에디터도 필요한 경우
- 한글 로마자 입력, 복벌식, 세벌식 이중모음 정석 강요 같은 여러 특화된 입력 환경을 쓰고 싶은 경우
- Bksp 다 지우고 앞 글자에 자동 달라붙기, 무한 낱자 수정, 특정 낱자 바로 변형 특수 키 같은, 세벌식에 특화된 전문적인 입력 기능을 쓰고 싶은 경우

전문적이고 기능 많으면서도 초심을 잃지 않고 쓰기 쉽고 친숙한 프로그램을 만들고 싶습니다.
모든 개발자, UI 디자이너들의 고민거리겠지요?

Posted by 사무엘

도로는 과속을 방지하고 운전자의 안전을 위해서 일부러 길을 어느 정도 꼬불꼬불하게 만들기도 해야 하지만,
철도는 지형적으로 가능하기만 하다면, 무조건 곧게만 만드는 게 최고입니다.

철도 차량은 고무 타이어로 다니는 도로 차량보다 동력비가 훨씬 적게 들고 수송력이 월등합니다. 하지만 가감속이 도로보다 매우 더디고, 등판능력이 부족하다는 단점도 있습니다.

철도는 궤도로만 차량이 다닌다는 특성상, 버스보다도 폭이 더 큰 차량이 도로보다 폭이 훨씬 좁은 선로 위를 다닐 수 있습니다. 즉, 토지 이용면에서 대단히 효율적입니다.

도로는 항공· 해운만치는 아니어도 기상 상황의 영향을 많이 받는 편이지만
철도는 사실상 전천후이며, 기상과 가장 무관하게 운행 가능한 교통수단입니다.
멀미 걱정할 필요 전혀 없고, 좌석 안전벨트가 필요없다는 점도 큰 매력.
질량 차이가 어마어마하기 때문에, 건널목에서 자동차 정도하고 부딪혀 가지고는 승객은 아무런 영향도 가지 않습니다.

철도는 조향(steering)이란 개념이 없기 때문에 한편으로는 단점이지만, 다른 한편으로는 운전을 매우 용이하게 해 주어, 도로를 능가하는 고속 주행이 가능합니다. 또한 선로를 따라 전기 동력원을 손쉽게 공급할 수 있다는 독자적인 장점이 철도의 매력을 매우 높입니다. 이 둘이 연합하여 등장한 개념이 바로 고속철도입니다.
지하철과 고속철도는 사실상 전기철도 기술의 개발 덕분에 가능했습니다. 전자: 지하에 매연 없이 고가감속 차량 구현 / 후자: 저렴한 동력원으로 손쉽게 고속 차량 구현

도로는 차들이 진행할 수 있는 방향을 나타내는 비교적 단순한 신호 시스템이 존재합니다. 하지만 철도에는 방향은 별 의미가 없고 대신 속도를 제어하는, 비교적 복잡한 다단계 신호/열차 통제 시스템이 존재하며 이에 대해서는 기관사의 고도의 학습이 필요할 정도입니다. 마치 컴퓨터에서 둘 이상의 스레드가 동시에 접근할 수 없는 코드나 리소스를 관리하기 위한 스레드 동기화 오브젝트가 있는 것처럼, 철도에는 폐색 구간이라는 개념이 있어서 이 구간에는 둘 이상의 열차가 진입하지 못하도록 하는 장치가 있습니다.

도로는 어느 한 곳이 사고나 천재지변 때문에 불통되면 다른 곳으로(고속도로 -> 일반국도 등) 우회가 대부분 가능하지만, 철도는 그렇지 못합니다.

아마도 철도의 가장 큰 단점은 유지 보수 비용이 아닐까 합니다.
도로는 한 번 길 닦고 난 뒤부터는, 과적 차량에 의한 표면 파손이나 큰 사고나 천재지변 따위가 없는 한, 거의 반영구적으로 24시간 운영할 수 있는 반면...
철도는 남자가 매일 면도를 하고, 고기 구워 먹으면서 주기적으로 불판 가는 것만큼이나 빈번하게, 차량뿐만이 아니라 레일 자체에 대한 유지보수와 정비가 필요합니다. 깔끔한 레일이 그냥 유지되는 게 아니거든요.
그래서 지하철도 복선 선로만으로는 원천적으로 24시간 운행이 불가능한 교통수단입니다. 뉴욕 지하철은 예비 선로를 번갈아가면서 쓰면서 24시간 운행을 하는 것입니다.

Posted by 사무엘

2006. 5. 8. 어린이날과 휴일을 맞이해 집에 방문했다가, 서울로 돌아갈 때 지름길 대신 경전선과 전라선을 경유하여 이동했습니다. 경전선 최초 시승.

2006. 6. 24-25. 정선 아우라지 역까지 들렀다가 강릉에 갔다왔습니다. 숙박은 찜질방 이용. 스위치백 구간을 최초로 시승했습니다. 천혜의 경치를 카메라에 담아 온 귀한 시간이었습니다. 돌아오는 길은 제 인생에서 처음이자 마지막으로 전기기관차가 끄는 새마을호를 탑승했지요.

2006. 8. 5-6. 장항선 전구간 시승. 지금 사용하고 있는 새 디카가 첫 투입된 여행이었습니다. 장항선에 대체 투입된 구특전 새마을호를 시승함과 동시에, 새마을호 Dreamers, Looking for you 뮤직비디오 동영상을 촬영하여 소중한 역사 기록이 되었습니다. 노선보다도 열차가 더 중요했던 여행 같습니다. 숙박은 장항 역 근처의 여관에서 했습니다.

2006. 8. 14. CDC로 경의선 당일치기 시승. 파주까지 갔다가 되돌아왔습니다. 경의선 구간은 여전히 허허벌판이 많고 역도 시내버스 정류장 같은 허접이 많다는 걸 느꼈습니다.

2006. 9. 23. 경춘선 당일치기 시승. 강촌 역까지 갔다왔습니다. 무척 날씨가 좋아서 역사 내부도 살펴보고 주변 사진도 많이 찍었습니다. 이 역시 경춘선 복선전철로 인해 선로가 이설되고 나면 역사 기록이 되겠죠.

2006. 11. 18-19. 근성인 님과 함께 전주 방문. 난생 처음으로 새마을호 특실 이용. 내 인생 마지막으로 새마을호 Looking for you를 현장에서 들은 순간이었다. (물론 디카로 녹화함) 참으로 의미심장하지 않을 수 없다. 잠은 전주 소망 침례교회 예배당에서 잤습니다.

2007. 4. 1. 훈련소 입소하기 직전. 근성인 님과 함께 공항철도 짤막 시승. 코레일 관할의 광역전철도 아니고 일반열차도 아닌 므흣한 사철 구간이라 할 수 있는데, 무척 훈훈했습니다.

2007. 7. 14-17. 대박 대박!! 내일로 티켓을 이용하여 중앙선 완행열차로 중앙선과 동해남부선 시승. 난생 처음으로 경부선 대구-부산 구간과, 경북선, 충북선 전구간 이용. 난생 처음으로 영동선 영주-통리 구간 이용. 강릉까지는 안 가고 통리까지만 갔습니다.
사진 무진장 찍었습니다. 잠은 부산에서는 찜질방, 제천에서는 여관에서 자고 대전 카이스트에도 들렀습니다.

2007. 7. 18. 내일로 티켓 유효기간이 남아있었기 때문에 퇴근 후 바로 서울 역 가서 수원까지만 새마을호 타고 내려갔다가, 상행 새마을호 타고 되돌아왔습니다. 그냥 오로지 열차 타는 게 목적이었습니다. ㄳ 회사가 서울 역에서 지하철 겨우 두 정거장 거리밖에 안 됐으니 가능한 일.

2007. 7. 19. 이번엔 퇴근 후 아예 광주 갔다가, 새벽 상행 열차 타고 서울로 돌아온 뒤, 바로 출근했습니다. 열차 안에서 외박한 셈. (평일 아침 상행열차.. 승객 정말 많았습니다.)

2007. 7. 20. 퇴근 후 오랜만에 또 경춘선 타고 마석 역까지 갔다가 되돌아왔습니다. 이렇게 해서 대망의 내일로 티켓 여행 끗.

2007. 12. 30-1. 일요일 밤차 타고서, 지난번 내일로 티켓 여행 때처럼 부전 역까지 간 뒤, 경전선을 오랜만에 재답사했습니다. 순천이 아닌 송정리 역까지 간 뒤, 광주 시내 구경 좀 하다가 익산의 모 찜질방에서 숙박. 그 후 익일 아침엔 장항선 경유 열차를 타고 서울로 되돌아왔죠.
지난 여름의 내일로 티켓으로 가 보지 못한 노선만 골라서 아주 뜻깊은 여행이었습니다. 시기적으로도 타이밍 아주 좋았구요.

Posted by 사무엘

한강: 사람이 만든 시설은 아니지만, 폭이 800미터가 넘는 큰 강..! 세계 대도시 중에서는 서울이 유일하죠. 정말 복받은 겁니다.

문제는 강뿐만 아니라 뭐든지 큰 걸 좋아한다는 것.

  도로: 서울 강남이나 도심에 있는 육중한 8차선, 10차선 간선도로는 세계 다른 대도시에서 유례를 찾기 힘들 정도로 우악스러운 대로입니다. (자동차 전용 고속도로가 아니라 시가지에 있는 도로)
차선 수만 많다고 해서 그에 비례해서 교통 소통량이 늘어나는 것도 아니고, 지나치게 넓은 도로는 지역을 양분시키고 보행자 횡단을 힘들게 만들기 때문에 도시/교통공학상으로 좋지 않습니다. 차라리 차선 수는 적어도 지금처럼 너무 대기시간이 긴 4현시 교차로 신호 대신, 비보호 좌회전, 로터리 등으로 교차로 신호 체계를 개선하는 게 더 효율적입니다.

  시험지: 기본이 B4이고 수능 시험지 같은 건 아예 신문지 수준의 A3 용지여서 책상에 다 펼치기도 못하죠. 미국 SAT나 토익, 토플 시험지하고는 차원이 다릅니다.

  지폐: 신권은 그나마 좀 개선이 됐지만, 옛날에 쓰던 지폐는 더 말이 필요없었지요. 지갑 수입업자들이 사이즈 제일 큰 것만 골라서 수입해야 했습니다.

  전동차: 지금까지 우리나라 대중교통에는 경전철이란 개념이 없었습니다. 전철 하면 언제나 표준궤에, 육중한 대형 전동차를 10량씩이나(서울 1~4호선) 끌고 다니는 중전철만 생각했습니다. 그러니 지방 광역시 지하철만 타도 전동차가 비정상적으로 너무 작고 불편하다고 여기죠. 반대로 서울 지하철이 엄청 크다고는 거의 생각 안 합니다. ^^;;
그 반면, 일본만 해도 신칸센 같은 장거리 고속 노선을 제외하면 아예 협궤도 만만찮게 볼 수 있습니다. 물론 여기에는 한국에 철도가 처음 부설되던 당시의 일제 군부의 무서운 선견지명도 작용했습니다. 당장 건설비 좀 더 들더라도, 한반도에다가는 중국, 러시아 대륙 침략을 위한 철도 직결운행을 염두에 두고 애초부터 표준궤를 썼던 것입니다. 예상은 적중.

  자동차: 우리나라처럼 땅 좁고 기름 한 방울 안 나는 나라에서 철도가 이토록 홀대받고, 자동차 중에서도 경차가 이토록 홀대받는 경우도 없을 겁니다. 그나마 요즘은 기름값이 워낙 너무 비싸져서 다시 경차 찾는 분위기가 살고 있는 거 같습니다.

  책: 전세계적으로 같은 책이 출판, 번역되어도 한글판이 종이 크기가 제일 크고, 재질도 고급이고 값도 제일 비쌉니다. 언제부턴가 우리나라 서점에서는 주머니에 넣고 다닐 만한 책이 거의 전멸했습니다.

Posted by 사무엘

1. (지정석 체계가 아닌 버스나 열차 안에서) "여기 자리 있습니까?"

--> 이 자리에 임자가 있습니까?
--> 내가 앉을 수 있는 빈 자리가 있습니까?

2. 너 보는 날도 얼마 안 남았다

--> 지금은 볼 수 없지만 얼마 후엔 너를 볼 수 있게 된다.
--> 지금은 너를 볼 수 있지만 얼마 후엔 볼 수 없게 된다.

2와 비슷한 예로, 누굴 오랜만에 만났을 때

--> 너 본지 꽤 오래 됐다
--> 너 안 본지 꽤 오래 됐다 (????)

일단 언어란 게 그 문자나 소리 자체보다도 분위기, 눈치, 문맥이 먼저 차지해서 의미 판단의 편견으로 작용하는 게 엄청 많습니다. '가가 가가가?'처럼.
말은 그런 게 있는데 글은 그런 게 없기 때문에 맞춤법이 필요하고 말소리보다 표기가 훨씬 더 엄밀해야 사람이 수월하게 알아들을 수 있습니다.

어쨌거나 저 표현.. 둘 다 맞을 수는 없거든요.
용법을 통일해야 할 것입니다.
우리 말글을 갈고 닦고 논리성을 높인다다는 게 이런 작은 것에서부터 시작해야 하지 않겠습니까.

Posted by 사무엘

서울에서 약 1시간 50분 동안 열차로 갈 수 있는 거리는?

경부선 KTX로는 무려 대구까지 갈 수 있습니다. (293.1km)
호남선 KTX로는 딱 익산까지 갈 수 있습니다. (244.5km)
새마을호로는 (서)대전까지 갈 수 있습니다. (약 165km)

그 반면,
중앙선 열차로는 원주까지만 갈 수 있습니다. (108.2km)
아니면 춘천까지가 딱 그 정도 시간이 걸립니다. (92.8km)

중앙선은 경부선에 비하면 완전 시간이 정지해 버린 노선이란 게 틀린 말이 아니죠.
경부선으로는 급행도 아니고 모든 전철역에 정차하는 1호선 완행 전동차를 타도 그 시간 동안 얼추 천안까지는 갈 수 있습니다. (약 94km)

Posted by 사무엘

※ once -- 컴파일러의 동작 방식을 바꿈

비주얼 C++ 거의 6.0 시절부터 지원되었던 것 같습니다.
헤더 파일의 첫 줄에다 삽입하여 이 헤더가 중복 인클루드되지 않도록 합니다.

헤더 파일 전체를 #ifdef, #endif로 싸는 것보다 간편해서 좋습니다.
물론, 이걸 쓰면 특정 헤더 파일이 인클루드됐는지의 "여부"는 알 수 없지만, 그런 거 상관없이 중복 인클루드만을 방지하려는 용도로 아주 적합하지요.

※ comment -- 오브젝트 파일에 뭔가 정보를 기록함

- lib: 프로젝트 전체의 링커 옵션을 일일이 바꾸지 않고도 이 오브젝트 파일을 링크할 때는 이 라이브러리를 추가로 찾아 보도록 지정합니다. 매우 유용합니다.
- linker: 이 소스 코드에만 적용할 링커 옵션을 아예 소스 코드에다 바로 써 넣을 수 있습니다.
비주얼 C++ 2005는 예전까지 번거롭게 리소스로 처리하던 side-by-side 메니페스트 작성을, 링커 옵션으로 지정하여 전용 도구로 손쉽게 할 수 있게 되었습니다. 내 exe가 윈도우 XP 비주얼 스타일을 지원하고 싶으면 그냥 /manifestdependency를 지정하는 링커 옵션 pragma를 한 줄 써 주면 끝이라는 것입니다.

※ pack -- 컴파일러의 코드 생성 방식을 바꿈

위의 pragma 지시들이 그냥 다른 기능이나 옵션 설정만으로도 실현할 수 있는 기능에 대한 '편의'만을 제공하는 거라면, 이건 뭔가 고유한 의미를 갖는 기능입니다. 대체할 수 있는 다른 기능이 없습니다. 바로 구조체 패킹 관련 설정을 제어하는 것이기 때문입니다.

이건 근래에는 32비트 코드를 64비트 코드로 포팅할 때 특히 신경써야 합니다. 평소에는 기계가 처리하기 적당하게 32비트 내지 64비트 크기로 패킹을 하지만, 파일을 한 구조체로 바로 읽어들이거나 네트워크 패킷처럼 크기에 아주 민감하게 구조체를 짜려면 반드시 8 또는 16비트 크기의 정밀한 패킹이 필요합니다.

구조체 패킹 크기 옵션은 컴파일러가 스택 구조로 처리하기 때문에, 나의 새로운 설정을 집어넣었다가(push) 다시 예전 설정으로 돌아가는(pop) 식의 세팅이 가능합니다.

Posted by 사무엘

평일 N/H 기준 배차간격.

A급 약 4분: 서울 지하철 1호선
B급 약 5~6분: 대부분의 서울 지하철 시내 간선 구간 (2~5, 7호선)
C급 약 6~8분: 서울 지하철 6· 8호선, 경인선-의정부 완행
D급 약 8~10분: 분당선, 일산선 대화 행

이제 여기부터는 슬슬 시각표를 확인하고 타야 정신건강에 좋겠죠.

E급 약 10~12분: 경부선 병점 완행, 5호선 상일동· 마천 지선, 과천· 안산선 안산 행, 7호선 장암 행, 2호선 성수· 신정 지선, 경인선 급행
F급 약 15분: 분당선 보정 행, 용산-덕소선
G급 약 20분: 경부선 천안 완행, 오이도 행
H급 약 30~40분: 소요산 행, KTX광명 셔틀
I급 약 1시간: 천안 급행

개인적으로 역마다 이런 정보가 표시되어 있는 노선도를 제각기 만들고 싶습니다.

- 깊이: 5호선이라면 마포, 영등포시장 같은 역은 색깔이 무지 진하고, 발산 같은 역은 옅음
- 승강장 구조: 섬식, 상대식, 2폼 3선식 등
- 구간별 평균 배차간격: 위의 두 요소가 그래프 상에서 vertex에 대한 속성이라면, 이건 edge에 대한 속성이겠죠. A, B급 구간은 아주 진하고 I로 갈수록 옅어집니다.

Posted by 사무엘

<날개셋> 타자연습에 게임이란 게 생긴 건 무려 01년 가을에 나온 1.0부터입니다. 베네치아 류의 전형적인 ‘혼자하기’ 게임입니다. 열두 단계 레벨, 각 레벨별 배경 디자인, 그리고 세벌식 지옥 훈련 같은 컨셉은 이 첫 버전부터 존재해 왔습니다. 세벌식 4단 자리와 윗글쇠 받침을 집중적으로 공략하는 9~11탄은 매우 어렵습니다.

각 레벨별로 떨어지는 글자의 수, 속도와 간격 등은 나름대로 식을 세워서 계산까지 하면서 정했습니다. 엔딩까지 쉬지 않고 게임을 진행하면 소요 시간은 약 20분 가량 됩니다. 1탄을 깬 직후에는 200점 남짓밖에 되지 않지만, 끝탄까지 다 깨고 나면 16000점이 넘어갑니다.

게임을 처음 만들었을 때의 레벨은 지금보다 더 어려웠습니다. 개발자인 제가 10탄 정도까지밖에 못 가게 설정되어 있었습니다. 그러다가 지금의 난이도는 03년 무렵에 완전히 정착되었고, 저는 끝탄을 깹니다. 레벨뿐만 아니라 무중력, 숨바꼭질 바이러스 같은 것도 한메 타자 교사의 베네치아 게임에서 아이디어를 따 와서 그때 이미 정착되었습니다.

처음엔 단일 주인공이었다가 02년 초에 나온 1.2에서 한별, 아름, 미르라는 세 주인공과 각각의 컨셉이 추가되었습니다. 특히 방어력이 약한 대신, 좀 오타가 있어도 단어를 맞힌 것으로 인식해 주는 미르가 무척 특이한 캐릭터였지요. 한별은 그와는 정반대로 단어를 틀리게 치면 벌칙으로 잠시 키 입력이 안 되게 됩니다.

주인공 별 밸런스도 초창기에는 자주 바뀌었지만 이 역시 레벨 난이도 정착과 비슷한 시기에 정착되어 그 이후로 바뀌지 않고 있습니다. 정석적이고 맷집이 가장 좋지만 오타에 매우 약한 한별, 체력 회복 능력이 뛰어나서 초보자에게 좋은 아름, 날타에 최강이지만 방어력이 매우 약한 미르 이런 구도이고요.

그 후 02년 초에 나온 1.25에서 게임이 DirectX 기반의 640x480 전체 화면으로 바뀌고 프레임 수가 늘어 화면이 부드러워졌습니다. DirectX라고 해 봐야 3D도 없고, 완전 DirectDraw 초창기 시절 API로 원초적인 2D 서피스 블릿밖에 쓰지 않습니다. 그리고 화면을 그리는 대부분의 과정은 지금까지도 여전히 윈도우 DC를 통해서 이뤄지고 있습니다.

1.5에서는 지금과 같은 여섯 곡의 배경 음악이 추가되었습니다. 각 레벨의 특성에 맞게 몇 주간에 걸쳐 고민하면서 선곡했습니다. 1~3단계의 <마법의 성>에서 시작해서 맨 끝 레벨의 <이젠 안녕>으로 끝납니다. 게임을 쉬지 않고 정상적인 속도로 진행하면, 얼추 음악이 한 번 완전히 끝나고 다시 반복될 무렵에 레벨이 바뀌고 다음 음악이 나오게 됩니다. 이것도 절묘한 일치입니다.

03년 5월에 나온 1.72에서는 음악에 이어 다양한 게임들에서 따 온 효과음이 추가되었습니다. 이것 역시 제가 매우 심사숙고하면서 선택한 것입니다. 단어를 맞혔을 때 나오는 효과음이 세 주인공마다 다르지요.
이때 도움말에 허접한 ‘게임 줄거리’가 추가되고 전체 화면뿐만 아니라 ‘창 모드’ 실행도 가능해졌습니다.

그 후 한동안 게임 쪽은 변화가 없다가 올해 초에 나온 2.4에서는 시스템적으로 존재하던 여러 버그들을 잡았으며, 특히 게임 중에도 음악/효과음을 켜거나 끌 수 있고, 창/전체 모드를 바꿀 수 있게 했습니다.

저는 게임 개발에 그렇게 머리가 잘 돌아가는 타입이 아니지만 <날개셋> 타자 게임만은 긴 시간 동안 나름대로 상당히 창의적으로 기획과 개발을 동시에 해서 최소한의 노력으로 게임성도 갖추고 무엇보다도 세벌식 자판 연습에 특화된 의미 있는 컨텐츠를 잘 창조했다고 생각합니다.

글쇠 연습이나 문장 연습 같은 UI는 그 흔한 비트맵 텍스쳐 하나 없이 일반 대화상자 그대로이지만 게임만은 현란하지는 못해도 일단 부드럽고 형형색색이죠. ㅎ <날개셋> 타자연습의 가장 큰 매력이 아닐까 합니다. 토박이말 사전 어휘를 대폭 끌어다 쓴 것도 독창적인 면모입니다.

현재 바라는 건...
떨어지는 글자의 뒤로 어두운 그림자가 같이 깔리고, 숨바꼭질 바이러스는 스타의 클록킹 유닛처럼 그 글자 모양대로 공간 왜곡 효과나 좀 냈으면 좋겠습니다. 그리고 세 주인공별로 맞힌 글자가 터지는 시각 효과도 다르게 했으면 좋겠는데 그걸 기술적으로 구현 못 해서 아쉬울 뿐입니다.
3D화, 네트워크 연동 등, 응용할 수 있는 다른 분야도 많죠.

Posted by 사무엘

side by side assembly는 윈도우 운영체제의 구조적인 문제 중 하나였던 DLL hell 문제를 해결하기 위해 윈도우 XP에서부터 처음으로 도입한 기술입니다. (그 후 2003, 비스타 등등..)

전통적으로 Win32 EXE가 symbol import table을 통해 읽어들이도록 지정되어 로드 타임 때(런타임이 아닌) 실제로 읽어들이는 외부 dll은
해당 EXE/모듈이 있는 디렉토리, 커런트 디렉토리, 윈도우 및 윈도우 시스템 디렉토리, path 환경변수가 걸린 디렉토리 등등의 순서대로 탐색합니다. 물론 kernel32, gdi32, user32 같은 시스템 dll도 다 여기에 속하고요.

런타임이 아니라 로드(load) 타임이기 때문에
이런 dll 파일이 존재하지 않거나 한 심볼이라도 읽어들이지 못했다면
그 프로그램은 그냥 속수무책으로 전혀 실행되지 못합니다.
그런 상황에서의 처리를 프로그래머가 능동적으로 전혀 할 수 없다는 게 큰 약점입니다.

* * * * * * *

자, 이런 전통적인 로딩 방식은 잠재적인 문제를 품고 있습니다.
먼저, 한 회사에서 만들어서 여러 디렉토리에 상주하는 다수의 프로그램들이 자기네끼리 한데 공유하는 dll의 경로를 지정할 수가 없습니다. 기껏 잘 해 봐야 path 환경변수 지정이 고작인데, 이는 정량적인 방법은 아닙니다. 그 경로 지정 자체가 이미 '런타임'에만 가능한데, dll 로딩 경로는 '로드 타임'에 결정되어야만 하기 때문입니다.

이런 딜레마로 인해 조금이라도 한데 공유하는 dll은 반드시 탐색한다는 게 보장되는 윈도우 시스템 디렉토리에다 집어넣는 게 무조건 장땡이었고, 이 때문에 거기는 운영체제가 기본 제공하는 dll과, 응용 프로그램들이 집어넣은 dll로 인해 몇천 개의 수백 MB에 달하는 dll들로 난장판이 되어 버렸습니다.

둘째, dll을 식별하는 수단이 이름이 유일한지라, 이름이 같지만 다른 위치에 있거나 버전이 다른 엉뚱한 dll이 로딩되었을 때 대처할 방법이 전혀 없습니다. 이는 보안상으로도 매우 위험합니다. 이게 바로 말 그대로 DLL hell의 근본 원인입니다.

msvcrt.dll, mfc42.dll, comctl32.dll 이런 것들은 윈도우 98 이래로 이름은 같지만 그동안 버전별로 프로토콜, 인터페이스가 내부적으로 상당히 바뀐 게 많습니다. 내부적으로 문서화되지 않은 동작 방식이야 두말할 것도 없겠죠. 그런데 본이 아니게 그런 문서화되지 않은 동작 방식에 의존하던 프로그램이 다른 버전의 dll을 읽어들이면 그때부터 프로그램의 안정성은 뻑이 나기 시작한다는 것입니다.

* * * * * * *

side by side assembly 기술은 위의 두 문제를 모두 원천적으로 해결하는 과정에서 나온 해결책입니다.

첫째, 이제 MS에서는 지금까지 내놓았던 시스템 dll 이후로 제 3자 응용 프로그램의 고유 dll이 윈도우 시스템 디렉토리에다 들어가는 것을 비추(discourage) 행위로 규정했습니다.
호환성 때문에 저걸 완전 금지할 수는 없구요. <날개셋>의 경우 윈도우 IME가 반드시 시스템 디렉토리에만 있어야 하기 때문에 시스템 디렉토리를 건드립니다.

그런 특수한 경우가 아니면, 응용 프로그램이 사용하는 모든 dll은 가능하면 응용 프로그램 디렉토리에다가만 두어라! 시스템 디렉토리는 이제 운영체제만 자체적으로 쓰겠다. 이곳의 포화는 이제 그만!
메모리가 부족한 상황에서 자원을 하나라도 더 공유하려고 시스템 디렉토리를 두었지만 이제 그런 정책까지 과감히 포기한 것입니다.

이게 파격이 큰 이유는, 심지어 준시스템 dll이나 다름없는 개발툴의 런타임 dll들까지 이제 시스템 디렉토리에다 넣지 않기로 했기 때문입니다. 비주얼 C++ 기준으로 6.0이 끝입니다. 6.0으로 만든 EXE만이 mfc42.dll이나 msvcrt.dll 정도는 윈도우 98 이래로 어디에나 편재해(ubiquotous) 있다고 간주할 수 있습니다. 즉 'known dll'인 것입니다.

그 이후로, 닷넷으로 만든 EXE는 자신이 사용하는 msvcr71, msvcr80, mfc71 등등을 배포 패키지에다 자체 내장해야 합니다. 윈도우 XP, 비스타의 시스템 디렉토리에 기본으로 들어있지 않습니다. 응용 프로그램이 자기가 쓰는 런타임 dll은 무조건 복사본을 자기 디렉토리에다 심어야 합니다.

둘째. 첫째가 상당히 자비심 없는 정책이 되었는데 그럼 대책이 뭐냐 하면,
내가 정확하게 읽어들이고자 하는 DLL의 고유 식별자, CPU 아키텍쳐, 언어, 정확한 버전 번호를 exe 내부에다 리소스의 형태로 xml 문서로 명시해 놓는 것입니다. 한 컴퓨터의 디렉토리 구조와는 완전히 무관하게 말입니다. 메니페스트 xml이라고들 하죠.

그 메니페스트용으로 등록된 핵심 dll들은 윈도우 시스템 디렉토리에 있는 게 아니라 WinSxS 밑에 각 버전과 아키텍쳐별로 별개의 디렉토리에 저장됩니다.
윈도우 XP라면 gdiplus, comctl32 이런 dll이 존재할 텐데요. 이름이 같은데 윈도우 XP 원본이 갖고 있던 comctl32, SP2가 갖고 있던 comctl32 이런 버전별 '스냅샷'들이 전부 따로 저장되어 있는 걸 알 수 있습니다. 비스타에는 이보다 훨씬 더 많이 있습니다. 내가 만들어서 공유하기를 원하는 핵심 dll도 이런 식으로 등록, 배포할 수 있습니다.

* * * * * * *

윈도우 XP에서 이런 새로운 방식으로 곧바로 사용되기 시작한 대표적인 운영체제 컴포넌트가 바로 comctl32.dll 입니다. advapi, shell32 같은 거 말고 comctl32만 이런 형태가 됐습니다.
얘는 윈도우 9x 시절부터도 인터넷 익스플로러와 함께 곧잘 업데이트되었던 파일이고 특히 윈도우 9x의 안정성을 떨어뜨리는 주범이기도 했습니다.

이 파일이 특히 윈도우 XP에서는 비주얼 스타일 테마의 등장으로 인해 구조가 완전히 뒤바뀌었는데, 정작 새로운 파일은 WinSxS에 있고, system 디렉토리에 있는 파일은 버전이 여전히 5.82이고 옛날 IE 5.x 시절과 별 차이 없습니다. 한 마디로, system 디렉토리에 있는 파일은 옛날 프로그램과의 호환성을 위해 시간이 그 상태 그대로 정지해 버린 것입니다.

그 반면, 메니페스트에다가 새로운 comctl32를 사용하도록 지정을 해 놓은 exe만이 대화상자에서 윈도우 XP 이후의 비주얼 스타일 적용을 받을 수 있는 구조가 됐습니다. comctl32를 이 방법을 통해 최신 버전으로 지정하지 않으면, 옛날 프로그램에서는 알록달록한 테마만 나오지 않는 게 아니라 하이퍼링크 컨트롤 같은 XP에서 새로 추가된 컨트롤을 쓸 수도 없고, 비스타에서 그 유명한 TaskDialog 함수조차도 쓸 수 없습니다.

* * * * * * *

유행 따라서 윈도우 XP 비주얼 스타일을 쓰려고 으레 '리소스' 형태로 따로 작성해 온 메니페스트가 비주얼 스튜디오 2005에서는 개발툴 차원에서 통합적으로 지원되는 요소가 되었습니다. 2005는 이제 배포 대상 플랫폼으로서 윈도우 9x의 지원을 완전히 제껴 버리고 CRT와 MFC DLL 역시 side by side assembly 형식으로"만" 로딩하게끔 정책이 바뀌었습니다.

이게 언뜻 보기에 골때리는 이유가 뭐냐 하면, 이제 2005로 만든 exe는 msvcr80.dll이 시스템 디렉토리나 심지어 그 exe 디렉토리에 같이 있다고 하더라도 winsxs 설정이 안 되어 있으면, '응용 프로그램 구성이 잘못됐다'며 실행 안 되기 때문입니다. (msvcr80이 자체적으로 퇴짜를 때리는 듯.)
그냥 msvcr80, mfc80 같이 슬쩍 복사해 놓는 방식으로는 실행 못합니다. 이들을 winsxs 정식 등록을 해 주든가, 아니면 앗싸리 MS에서 배포하는 VS 2005 redistributable 프로그램을 같이 배포해야 합니다.

그런데 도대체가 VS 2005 redist.도 따로 있고, VS 2005 sp1 resit.도 따로 있습니다.
윈도우 비스타에 기본 내장되어 있는 msvcr80의 버전이 다르고, 오피스 2007이 사용하는 msvcr80의 버전이 다릅니다. 세부 버전 숫자가 하나라도 다르면 로딩 안 되는 게 일단 보안과 안정성 면에서는 나아진 점입니다만, 도대체 같은 기능을 하는 CRT DLL을 왜 자꾸 이렇게 바꿔 대는지, 도대체 앞으로는 또 어느 장단에 맞춰 춤을 추라는 소리인지 헷갈립니다.

MFC도 아니고 CRT가 뭐가 그렇게 자주 바뀌어야 하는지.. 그냥 아무 걱정 없이 윈도우 시스템 디렉토리의 msvcrt만 쓰던 시절이 살짝 그립기도 합니다. strcpy, malloc 이런 고전적인 함수가 도대체 뭐 변할 일이 있나요? (물론 보안 쪽으로 계속 더욱 강력해져 오긴 했죠. strtok_s, strcpy_s 이런 것도 마음에 듦.)

비주얼 스튜디오 2005로 처음으로 만들어 본 <날개셋> 4.8 64비트 바이너리들은 이런 잡음을 원천 봉쇄하기 위해, 메모리 낭비를 감수하고 일단 모든 바이너리에 CRT 라이브러리를 static 링크를 해 버렸습니다. 64비트 에디션을 앞으로 계속 이렇게 만들지는 미지수입니다.

다만, 이도 저도 못한 신세가 되어 버린 게 비주얼 스튜디오 2002/2003의 CRT DLL인 msvcr71입니다. side by side assembly 형식으로 완전히 넘어간 것도 아니면서, 운영체제의 기본 지원도 못 받아서 이 파일의 배포와 로딩은 재래식으로 응응 프로그램이 그냥 알아서 해야 합니다. 이제 VS 2005 쓰라고 64비트 지원도 중단됐고 그냥 과도기 DLL로 역사 속으로 사라지게 되었습니다.
VS 2003도 서비스 팩 1이 나온지라 버전이 살짝 다른 msvcr71.dll 두 버전이 존재하게 되었지만 겉보기 상으로 차이는 없는 듯합니다.

Posted by 사무엘