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

윈도우 운영체제가 NT 초창기 시절 이래로 지금까지 사용해 오고 있는 실행 파일 포맷은 잘 알다시피 portable executable 형식입니다. 헤더도 이니셜인 PE로 시작합니다. 물론 네이티브 EXE이기 때문에 코드 부분은 기계마다 다르겠지만, 헤더 구조체라든가 리소스 같은 공통된 부분은 최대한 일치시켜서 이식성을 고려해서 설계했다는 뜻이지요.

늘 인텔 CPU에서만 돌아가는 EXE만 보다가 MIPS 같은 RISC CPU에서 돌아가는 PE 실행 파일을 헥사 에디터로 들여다보니 진짜로 기계어 코드가 한눈에 보기에도 일정 바이트 간격으로 아주 균일하게 나열돼 있더군요. 그걸 보고 놀랐던 기억이 납니다.

64비트 PE도 일부 구조체만 64비트로 확장되었을 뿐 기본적인 골격은 초창기 32비트 PE와 같습니다. 더구나 윈도우 운영체제가 인식하는 리소스(스트링 테이블, 대화상자, 메뉴 등)의 포맷은 매우 다행스럽게도 32비트 PE와 완전히 일치합니다.

EXE와 DLL은 자신만의 프로세스 공간을 만들어서 단독 실행이 가능하냐의 차이가 존재하는데, 기술적으로는 헤더의 비트 몇 군데만 다르지 똑 같은 PE 바이너리입니다. 이런 바이너리를 ‘모듈’이라고 부릅니다.

c, cpp 같은 소스 코드를 컴파일하면 기계어 코드인 obj 파일이 생깁니다. 이런 obj 파일과 lib를 링크하면 그런 모듈 파일이 결과물로 생성됩니다. lib는 또다른 obj의 묶음일 뿐 obj와 완전히 다른 파일이 아닙니다. 또한 모듈 역시 그런 obj, lib에 들어있는 코드를 PE 규격에 맞게 재배치하고 묶은 파일일 뿐이지 원시 파일과 그렇게 큰 차이가 없습니다.

윈도우 운영체제에서 개발 환경을 만든 사람들의 생각은, 링커가 특별히 할 일이 없게 하는 것이었던 것 같습니다. 물론 요즘은 전역 최적화처럼 링크 타임에도 코드를 생성하는 기술도 도입되어 사정이 그렇게 간단하지만은 않게 됐지요.

PE는 text(실행되는 기계어 코드), rdata(스트링 리터럴처럼 읽기전용 상수나 초기화 값), rsrc(윈도우 리소스 데이터), DLL 심볼 import/export 테이블, reloc(재배치 정보) 등 여러 섹션으로 나뉩니다. 특히 재배치 정보는 Win32s 시절에는 exe에도 필요했지만 지금은 dll에만 넣어 주면 됩니다.

PE의 헤더에는 자신의 기본 어드레스, 자신이 돌아가는 데 필요한 최소한의 운영체제 버전 같은 여러 정보가 들어가고 심지어 자신을 빌드한 링커의 버전을 기입하는 공간도 있습니다. 가령 비주얼 C++로 빌드하면 6.0, 7.1 (닷넷 2003), 8.0 (2005) 같은 번호를 쉽게 식별할 수 있지요.

원래 MS 자체에서 만든 프로그램 바이너리들의 링커 버전은 비주얼 C++의 버전과 거의 일치하지 않았습니다.
가령 윈도우 95는 까마득한 2.5, 그리고 98/ME는 3.1, 윈도우 2000은 5.12, 오피스 XP는 6.2였습니다. 비주얼 C++과는 별도로 자신들만 쓰는 컴파일러/링커가 있었던 것 같습니다.

하지만 이것이 언제부턴가, 한 02~03년부터 버전이 일치하기 시작했습니다. MS에서도 내부적으로 비주얼 스튜디오를 쓰기라도 했는지?
윈도우 XP는 7.0으로 당대의 최신 비주얼 C++이던 닷넷 2002와 일치합니다.
그리고 XP sp2 (sp1은 모르겠음)와 오피스 2003은 비주얼 C++ 닷넷 2003의 버전과 같은 7.1입니다.

그 후 윈도우 비스타와 오피스 2007의 모든 바이너리들은 비주얼 C++ 2005의 버전인 8.0으로 물갈이되어 있습니다. 하지만 CRT 라이브러리는 살짝 다릅니다. 오피스는 msvcr80을 쓰지만 운영체제는 자신만의 msvcrt를 고수하고 있습니다. 하지만 이제는 msvcrt에도 비주얼 C++ 2005에서 새로 추가된 strcpy_s 같은 보안 강화 함수들이 추가되어 있습니다.

msvcrt는 이제 운영체제가 혼자 마음대로 바꿔 쓰는 CRT DLL로 격리시키고 응용 프로그램들은 이제 msvcr??을 알아서 배포해서 쓰든가, 싫으면 스테틱 링크하라는 구도가 된 셈입니다.

Posted by 사무엘

※ 1호선: 서울로 들어가는 경로 자체가 영등포 쪽으로 우회입니다. 물론 광역전철 말고 지하철 구간은 종로라는 큰 길을 따라 건설되어서 곧은 편이지만, 시청-종각만이 거의 90도로 꺾는 급커브입니다. 동아일보 사옥 아래를 피하느라 그렇게 됐다고 합니다.

※ 2호선: 순환선이기 때문에 생기는 커브를 제외하면 직선 구간은 그런대로 곧게 잘 만든 것 같습니다.

※ 3호선: 교대-고속터미널을 경유하느라 ㄷ자 모양의 괴이한 커브가 생겨 버렸죠. 일산선 구간도 삼송-원당 쪽을 경유하느라 오리지널 경의선에 비해 굴곡이 너무 심합니다.

※ 4호선: 과천선 구간의 경마공원-대공원 경유가 굴곡을 만들고 있고, 용산-서울역 1호선과의 중복 구간도 일종의 굴곡 우회 경로입니다. 남산 아래를 뚫고 도심으로 바로 직행하는 전철 노선이 아쉽습니다.

※ 5호선: 2호선과 겹치는 강북 도심 구간은 매우 심한 굴곡 커브가 이어집니다. 신금호까지 남쪽으로 내려갔다가 광화문까지 북쪽으로 올라가죠.
오로지 1호선과의 환승을 위해 건설된 신길 역도 긴 환승 통로에 상당한 굴곡이 진 곡선역이 됐습니다.
끝으로, 김포공항도 예외가 아니어서 인근역과 거의 예각을 이룰 정도로 큰 굴곡입니다.

※ 6호선: 마포구에서 지하철이 왼쪽으로 살짝 꺾게 만든 장본인은 상암동의 월드컵 경기장입니다. 6호선 건설 당시, 월드컵 경기장의 건설 예정지가 뒤늦게 그렇게 확정되자 황급히 노선을 바꾸느라 꽤 곤혹을 치렀다고 합니다. 그 대신 택지 개발 계획도 취소되고 월드컵 경기장 후보지에서도 탈락한 5호선 마곡 역은 미개통 노는 역이 되고 말았지요.

※ 7호선: 강남 구간에 고속터미널-상도가 국립묘지를 피해 가는 우회 구간입니다. 직선 구간은 9호선이 역할을 대신할 것으로 보입니다.

※ 8호선: 분당선과의 중복을 피하기 위해, 남쪽에 남한산성을 경유하는 괴상한 굴곡 노선이 형성되어 있습니다.

Posted by 사무엘

※ 육상 (도로)

문전 수송이 가능한 유일한 교통수단
차체의 크기가 가장 작음
휴게소라는 중간 시설이 있는 유일한 교통수단
조향이 가능한 2차원 교통수단
도로 정체의 영향을 받는 유일한 교통수단. 날씨 영향도 받긴 하나 항공, 해운만하지는 않음. 승차권에 평균 운행 시간은 나와도 도착 예정 시각은 찍혀 있지 않음

※ 육상 (철도)

한 치의 오차도 없이 정확하게 길이 있는 곳만 다닐 수 있고, 진로 분기도 외부에서 선로를 바꿔 줘야만 가능한 유일한 1차원 교통수단. 폐선되는 경우, 차량이 다니던 기반 시설까지 다 철거해야 하는 유일한 교통수단.
버스보다 객실 폭이 넓지만, 선로 폭은 도로보다 더 좁음 (공간 이용이 매우 효율적)
조향이라는 개념이 없기 때문에 속력은 비행기 다음으로 가장 빠르게 올릴 수 있음
좌석에 구명 장비(조끼, 안전벨트, 마스크 등)가 없는 유일한 교통수단. 멀미도 전혀 없다.
차량을 매우 길게 편성할 수 있어 대량 수송에 적합함
길에 대한 초기 투자비용이 가장 많이 들며, 꼼꼼한 유지 보수도 필요한 유일한 교통수단
전기 동력원을 쉽게 끌어다 쓸 수 있는 유일한 교통수단
기상 영향을 가장 덜 받는 전천후 교통수단
차체의 옆에서 탑승하며 출입문이 여러 군데에 있음

※ 항공

유일한 3차원 교통수단이며 디젤 엔진이 쓰이지 않는 유일한 교통수단
운항 중에는 중간 정지나 기체 비상 탈출이 절대 불가능한 유일한 교통수단으로, 운항 전 보안이 가장 크게 요구됨
속력이 가장 빠르고 가장 장거리를 운행할 수 있으며 운임도 가장 비쌈

※ 해운

탈 때, 동체가 땅에 닿아 있지 않은 유일한 교통수단
조향이 가능한 2차원 교통수단 (도로와 비슷)
크기를 가장 키울 수 있는 교통수단. 화물의 비중이 큼 (철도와 비슷)
바다의 특성상, 풍력으로도 그럭저럭 달릴 수 있는 유일한 교통수단
속력은 가장 느림
기상 영향을 크게 받음 (항공과 비슷)

서로 개성 넘치죠?

Posted by 사무엘

※ 메이저급

  경부(1): 서울-경주, 경주-대구, 경주-대전, 대전-서울 뭐 고속도로 하면 이 경로가 골수에 박혀 있죠. 하도 많이 이용해 봤으니까요. 저의 고속도로 이용 기억의 70% 이상 차지.
단, 경주 이남은 정말 묘하게 간 적도 없고 기억도 없다시피하군요. 경부는 전국에서 가장 넓은 고속도로로, 이제 아직까지 4차선으로 남아 있는 곳은 영천 이남 정도밖에 없습니다.

  중부(35): 경부 다음으로 제 기억 속에 남은 고속도로입니다. 대전에서 청주나 서울 갈 때 웬 처음 듣는 IC 이름들이 보이길래 경부가 아니구나 직감했습니다. 무려 통영까지 뚫렸지만 대전 이남 구간은 못 타 봤습니다. 개인적으로 이 도로가 경부 다음으로 무척 애착이 갑니다.
요즘은 또 유성-서울 시외버스가 이 도로를 애용합니다. 중부는 경부보다 동쪽에 있기 때문에 동서울 터미널과 잘 연결되기 때문입니다. 경부보다 훨씬 험한 지형을 고가와 달리고 하남, 이천, 광주 같은 수도권 동남부를 경유합니다. 산으로 가로막힌 오나전 철도 사각지대이기도 하죠.
덕분에 수도권 구간의 도로 확장도 경부 확장하듯이 못 하고, 옆에 아예 도로를 하나 더 짓는 방법으로 해야만 했습니다. 이름하여 제2 중부 고속도로이죠.

  중부내륙(45): 중부보다 더 오른쪽이고 영동 고속도로의 여주 분기점에서 만납니다. (여주 분기점 이북으로 양평까지도 확장 예정이라 함) 그리고 김천에서 경부와 만나는 걸로 끝나던 노선도 더 확장되어 마산까지 내려가죠. 김천 이남은 즐.
서울에서 출발하여 구미, 대구, 경주로 가는 고속버스들이 이 도로 덕분에 대전으로 우회하지 않고 더 곧은 길로 갈 수 있게 됐습니다. KTX 뺨칠 정도로 길이 곧고, 고가 터널이 일품입니다. 서울-경주 오갈 때 가끔 구경함.

※ 마이너급

  영동(50): 수도권 남부의 대표적인 가로축 고속도로로, 주말, 평일에 극심한 혼잡을 자랑합니다. 서쪽으로는 인천, 안산까지도 가죠. 하지만 저는 동쪽으로 여주 정도까지만 이용해 봐고 그보다 더 동쪽으로는 못 가 봤습니다.

  호남 고속도로 지선: 대전에서 학교 다닐 때, 유성 고속/시외버스 터미널에서 버스 타고 서울 갈 때, 유성 내지 북대전 IC에서 회덕 JC까지 아주 짤막한 구간만 이용해 봤습니다. 그 이남은 가 본 적 없습니다.

  서울외곽순환(100): 중부에서 동서울 IC -> 서울 시내 진입할 때에나 잠깐. 다른 구간은 경험무.

  서해안(15), 평택제천(40): 사실 서울은 서쪽은 철도, 동쪽은 도로 거의 이런 구도로 장거리 교통이 형성돼 있습니다. 그래서 서서울 IC, 서해안 고속도로는 더욱 경험이 드뭅니다. 고속버스로 이 도로를 가 본 적은 없고, 자가용은 더더욱 전무하고, 정말 특별한 계기로 딱 두 번 서해안 -> 평택제천 -> 경부 이런 식으로 길을 가 본 적은 있습니다. 그 유명한 서해대교까지는 못 가 봤고요.

  당진상주(30): 작년 가을에 개통한 오나전 따끈따끈 새 도로. 개통한 줄도 모르고 지냈는데, 작년 겨울에 경주 집에 갈 때 처음 보고 깜짝 놀랐습니다. 제한 속도가 110도 아닌 120km/h이고 '회인'이라는 웬 처음 듣는 IC가 등장하길래 새로 생긴 도로임을 직감했지만 어디를 경유하는지는 몰랐습니다. 나중에 지도를 찾아 보고서야 알았죠.

※ 한 번도 못 가 봤고, 달려 보고 싶은 곳

  익산-포항(포항-대구)
  부산-대구 민자 고속도로
  중앙 고속도로
  88 올림픽 고속도로
  논산-천안 민자 고속도로 (훈련소 있으면서 논산 쪽 톨게이트를 봤음)
  서해안, 영동 고속도로의 나머지 구간들

Posted by 사무엘

※ 성수-신설동 지선

성수: 대합실(매표소, 개집표기가 있는 층)까지도 계단으로 오르고, 거기서 또 계단으로 승강장에 올라가서 타는 고가역입니다.

용답: 대합실은 지상이고, 계단으로 승강장까지 한 층만 올라가서 탑니다. 높이가 낮아졌죠.

신답: 대합실과 승강장이 모두 같은 층 지상입니다. 신설동 방면은 계단 이용할 필요도 없이 승강장에 바로 갈 수 있습니다. 성수 방면 승강장만 육교로 건너갑니다.

용두: 드디어 지하이지만, 대합실과 승강장이 같은 지하 1층에 있고 얕습니다. 반대편 승강장으로 가는 통로는 지하도로 있습니다.

신설동: 대합실 지하 1층, 1호선 승강장 및 환승 통로가 지하 2층이고 2호선은 지하 3층에 있어서 더욱 깊어졌습니다. 더 깊은 곳에 유령 승강장도 있죠?

※ 신도림-까치산 지선은 어떤지 잘 모르겠네요.
신도림은 지하 2층으로 일단 얕습니다.

중간에 양천구청처럼 자연 채광역도 있지만, 한 가지 확실한 건
5호선과 같은 층인 까치산 역이 무지막지 깊다는 거겠죠?
물론 그건 다른 이유는 없고 주변이 언덕 때문에 높아서 깊어진 거라고 합니다.
5호선 서쪽은 원래 환승역도 없고 얕은 편이거든요?

※ 지하철을 건설할 때, 건물 아래나 강 아래를 지나는 것도 문제이지만 단순 도로가 아닌 고가 차도의 아래를 지날 때도 무척 난감해집니다.
제일 돈 적게 드는 개착식 공법(간단하게 위에서부터 땅을 파헤치는)을 쓸 수가 없죠.

2호선 아현 역이 그런 경우라고 하더군요. 중앙을 파헤치지 못하고 양 옆으로 공사를 하느라 터널도 단선 쌍굴이 되고, 무엇보다도 8호선 산성 역처럼 상· 하행 승강장이 단선으로 완전히 분리되게 됐습니다.

Posted by 사무엘

철도에서 단선과 복선은 선로 용량 면에서 서로 적수가 되지 못합니다.
단선은 잘 알다시피 마주 오는 열차의 정면충돌을 방지하기 위해서 반드시 일부역에서 교행을 해야 합니다. (기다렸다가 맞은편 열차를 먼저 보내고 진행)
그렇기 때문에 열차가 근본적으로 빠르게 통과할 수 없으며 선로 용량에 매우 큰 제한이 걸립니다.
옛날에 신호 설비마저 열악했을 때는 사고를 방지하기 위해서 지금보다 훨씬 더 비효율적인 열차 운행 시각표를 쓸 수밖에 없었기 때문에 열차 속도는 더욱 느렸고 배차간격은 더욱 길어야만 했습니다.

정확한 선로 용량은 대피선이 얼마나 자주 있냐에 따라 달라지지만, 아무리 고가감속 차량에 최첨단 신호 설비를 갖추더라도 단선에서 편도 기준 30분 이하의 배차간격은 도저히 무리입니다. 그 이하는 어차피 복선화하는 거나 다름없습니다.
서울 지하철 2호선에서 그 짧고 열차 운행도 뜸한 편인 지선 구간도 괜히 복선으로 건설된 게 아닙니다.

현재 한국 철도에서 단선 구간인 경춘선, 장항선의 평균 편도 배차간격이 4, 50분대인데, 이게 단선으로서는 거의 한계에 달하는 선로용량으로 운행하는 것입니다. 그래서 지연도 밥 먹듯이 하고 있으며, 현재 복선 전철화 공사가 한창인 것입니다.
요즘 건설되는 철도는 도로와 경쟁하려면 쫙 펼쳐진 직선 고가 터널에 장대레일, 복선 전철은 필수입니다.

그 반면 복선에서는 30분이 아니라 3분 간격으로 열차를 통과시킬 수도 있습니다. 출퇴근 시간의 지하철이 좋은 예이죠. 물론 그 정도라면 복선으로도 감당 못 할 선로 용량이긴 하지만 이론적으로 그만치도 가능하다는 얘기입니다.
아주 일반적으로는 복선의 선로 용량은 단선의 5~7배에 달한다고 여겨지고 있습니다.

복선 철도는 간단하게 한 선로가 한 방향으로만 운행 가능하게 신호를 정하는 게 매우 직관적이고 용이한지라, 전통적으로 좌측통행 또는 우측통행 이런 한 방법만으로 선로를 이용해 왔습니다.
하지만 요즘은 필요에 따라 건넘선을 따라 선로를 바꿔 가며 어느 방향으로도 열차가 운행 가능하게 좀더 융통성 있는 신호 체계도 도입되고 있습니다. 한 쌍의 선로가 아니라, 단선 병렬이라는 개념으로 바뀌는 것이죠.

우리나라에서 가장 먼저 복선화한 철도는 물론 경부선입니다. 일제 강점기엔 경부선이 경의선과 직결하여 중국까지도 갔기 때문에 경의선도 복선화해 있었지만, 이내 국토가 분단되면서 경의선은 단선으로 줄었다가 (전쟁물자 -_-) 지금 다시 복선 전철화 공사 중입니다. 경부선은 이미 80년대에 수도권 전철 구간이 2복선으로 확장되기도 했습니다.
한편 경인선은 60년대에 복선화해서 전동차 운행이 시작됐다가 21세기에 들어서야 전구간 2복선으로 확장됐습니다.

충북선은 여객이 아닌 화물 수송 때문에 일찌감치 복선 전철화했습니다.
호남선은 KTX 개통에 발맞춰 복선 전철화했습니다.

Posted by 사무엘

C 런타임 라이브러리에는(이하 CRT) 단순히 내가 호출하는 printf, strcpy, malloc 같은 함수에 대한 코드만 있는 게 아니다.
사용자가 작성한 C/C++ 프로그램보다 아래 계층에서 먼저 실행되면서
사용자가 짠 main 함수를 호출해 주고, 표준 C 스펙에 정의돼 있는 각종 전역변수의 값을 설정해 주고
전역변수 C++ 오브젝트들을 미리 초기화해 주는 것도 CRT의 몫이다.

이 오버헤드가 작지는 않다.
그렇기 때문에 hello, world! 한 줄만 찍는 프로그램을 C 언어로 짜 봐도 어지간해서는 크기가 최소한 1만 바이트는 넘어서며, 특히 윈도우 프로그램의 경우 내가 전혀 호출하지 않은 GetStartupInfo, GetVersion 같은 커널 쪽 Win32 API를 호출해 있는 걸 볼 수 있다. (CRT를 스테틱 링크한 경우)

그런 함수는 당연히 CRT가 호출한 것이다.
가령 main 함수에 인자로 전달되는 명령줄 인자는 CRT가 준비해서 넘겨 준 것인데,
CRT 역시 명령줄 인자는 더 아래 계층의 GetCommandLine 같은 API 함수를 통해 얻어 온 후, 파싱해야 하기 때문이다.

이 CRT 초기화 코드를 무시하고 진짜 순수하게 내가 짠 코드만 집어넣게 하는 링크 옵션이 컴파일러에 따라서 물론 존재한다.
이렇게 하면 어셈블리 프로그래밍 하듯이 아주 작은 EXE를 만들 수 있다.
하지만 이 경우, 정상적인 C언어 사용은 포기해야 한다.

CRT 초기화 코드가 실행되지 않으면 printf, malloc 등 I/O라든가 뭔가 초기화 context가 필요한 함수들도 죄다 사용할 수 없게 되기 때문이다.
윈도우 환경의 경우 그런 것들도 Win32 API만으로 내가 직접 다시 짜야 할 것이다.
fopen은 CreateFile로,
malloc/free는 HeapCreate 등으로 힙 관리 직접 다 하고,
sprintf는 wsprintf 등으로. (그나마 윈도우는 운영체제 차원에서 % 문자를 C랑 똑같이 해석해 주는 함수가 있어서 다행이다. 운영체제 자체가 C언어로 개발됐다는 증거가 아닐까 한다)

과거 16비트 도스용 컴파일러 시절에는 이 CRT 라이브러리가
메모리 모델별로 따로 존재해야만 했다. tiny, small, medium, compact, large, huge 기억하시는가? 아주 골치아팠다.

그러다가 32비트 윈도우 환경에 와서는 메모리 모델 구분은 없어지고 CRT에 새로운 속성이 존재하게 됐다.

- 멀티스레드: 옛날에 컨텍스트를 저장하는 데 배째라 전역변수 썼던 것들을 이제 스레드 TLS로 옮겨야 한다. 대표적인 예가 strtok. 이제 비주얼 C++ 2008부터는 싱글스레드 라이브러리는 없어지고 무조건 멀티스레드만 지원한다.
- 디버그: 도스용 컴파일러 중에 디버그 용 CRT가 따로 있었던 건 별로 본 기억이 없다.
- DLL이냐 스테틱이냐: CRT를 DLL로 따로 떼어낼 수도 있게 됐다. 한 프로그램이 같은 CRT를 사용하는 수많은 DLL들을 로딩하는 경우, 그 DLL 모듈들도 CRT DLL 하나만 로딩하도록 개발하면 메모리를 많이 절약할 수 있다.

Posted by 사무엘

텝스는 토익과 비슷하게 990점대가 만점이지만, 토익보다 어렵습니다. 토익 점수가 7~900점대라면, 텝스 점수는 토익보다 약 100점 정도 낮게 나옵니다.

텝스는 듣기와 독해 모두, 졸라 긴 한 지문을 가지고 여러 문제를 푸는 게 없습니다. 문제마다 서로 완전히 다른 지문이 주어집니다.
또한 토익의 생활/비즈니스 영어와 토플의 학술 영어가 골고루 조화를 이루고 있다는 점도 인상적입니다.

※ 듣기

텝스의 듣기는 모든 문제와 보기까지 전부 음성으로만 들려 주기 때문에, 문제지엔 파트 별 지시사항밖에 인쇄돼 있지 않습니다.

듣기 60문제를 다 푸는 데 55분 가까이 걸립니다. 앞부분에 짤막한 대화로 빨랑빨랑 진행되는 파트는 전체 문제의 절반인 30문제를 15분이 채 지나기 전에 다 진행해 버리는 반면, 나머지 문제는 매 대화마다 긴 대화나 담화를 들려 주고, 모든 문제의 보기도 일일이 다 들려 주고, 더구나 반복도 있기 때문에 소요시간이 깁니다. 무척 인상 깊게 느낀 부분입니다.

뒤쪽 파트는 지문과 질문을 다시 한 번 들려 주는 게 있다는 것도 특이합니다. 텝스는 문제지에 메모가 허용되기 때문에 이것도 수험자에겐 유리하게 적용합니다. 토플 듣기는 메모가 허용되지 않기 때문에 자비심 없습니다.

그렇긴 해도 문제는 점진적으로 굉장히 어려워집니다. 처음에는 대화 내용을 다 들을 필요도 없이 “이 대화의 요지는? 이 대화가 이루어질 만한 장소는?” 이렇게 시작하다가 나중에는 “이 대화로부터 유추할 수 있는 것은? 이 대화 내용과 일치하는 진술은?”처럼 매 문장을 일일이 파헤쳐 봐야 풀 수 있는 문제로 발전합니다. 어휘도 어지간한 대학 강의 수준으로 상당히 어려워져서 메모가 아무 의미 없는 지경이 되기도 하더군요.

8년 전이나 지금이나 듣기는 여전히 시린 이처럼 아픈 분야였습니다. ㄲㄲㄲ

※ 문법과 어휘

이런 분야에서는 생각을 해서는 안됩니다. 골치아프고 뭐가 틀렸는지 모르겠고, 시간이 부족한 거 자체가 아직 영어 감각이 부족하다는 뜻입니다.
턱없이 짧은 시간 동안 굉장히 많은 문제를 풀어야 하는데, 이상적인 경우라면 그냥 외우고 있는 표현으로 그대로 동물적인 감각으로 답을 가려낼 수 있어야 합니다.

문법의 마지막 파트인 ‘넷 중에서 문법이 틀린 문장 고르기’가 그래도 이 바닥에서는 상당히 어렵습니다. 시제, 복수, 관사 등이 머릿속에 어지럽게 맴돕니다. 제대로 풀긴 풀었는지. ㅠㅠ
어휘 같은 경우는 모르면 아예 풀지를 못하죠. 시간 낭비할 겨를이 없습니다. 미련 없이 다음 문제로 가야 합니다.

문법과 어휘는 배점이 굉장히 낮은 게 인상적이었습니다. (그나마 족집게 달달 외우기로 땜빵이 되는 녀석이어서 그런지?) 듣기나 독해의 1/4~1/3 수준밖에 안 되는 것 같았습니다.

※ 독해

정확한 영문법 지식이 필요한 것도 아니고 듣기 스킬이 필요한 것도 아니고, 결국 지문만 뚫어지게 들여다보면 답을 찾을 수 있는 분야이긴 하지만 역시 어휘와 시간에서 걸립니다.

처음엔 수능 외국어 영역 수준의 쉬운 ‘빈 칸 채워넣기’로 시작하고 질문 자체도 글을 다 읽을 필요도 없이 ‘중심 생각은?’, ‘이 글의 제목으로 적당한 것은?’ 같은 포괄적인 걸로 나오다가 나중에 지문도 무지막지 어려워지고 ‘이 글의 내용과 일치하는 진술은?’처럼 글을 꼼꼼히 읽어야 풀 수 있는 질문으로 바뀝니다.

마지막 세 문제는 “다음 네 문장 중 글의 전체 흐름과 관련이 없는 하나는?”인데, 모의고사 풀어 볼 때는 무척 어렵게 느껴졌지만 이번에 친 시험은 그다지 어렵게 느껴지지 않았습니다.

이상..
끙!
소위 입학, 취업에 필요하다는 영어 시험 부류에 응시하기는 8년만에 처음이어서 심하게 떨렸습니다. (8년 전엔 대학 학부 입학할 때 기관 토플) 영어 쓸 일이 없으니, 2001년 이후로 그런 공부하고는 완전 손을 놓고 살았죠.

이번에 그래도 시간 분배는 작정을 하고 후회 없이, 효율적으로 만족스럽게 했습니다. 별다른 미련이나 패닉 상태 없이 각 파트별로 딱 1분만 남기고 모든 문제를 차분하게 다 풀었습니다. 뭐 맞게 풀었냐는 완전 별개의 문제지만, 그나마 있는 실력의 발휘는 충분히 한 것 같습니다. ㄱ-

워낙 허겁지겁 시험 치고 오느라 머릿속이 멍합니다.
제게 영어는 언제까지나 native로 구사하는 언어가 아니요 thunking, emulation을 거치는 힘겨운 인스트럭션인지라,
많이는 안 바라고 한 750~800대만 나와도 아주 행복할 것 같습니다. ㄱㅅ;;;

Posted by 사무엘

1. 프로젝트의 링커 옵션 수정

"링커-입력" 카테고리의 "추가 종속성"에다가 같이 링크할 라이브러리 이름을 입력하는 것으로, 가장 일반적인 방법이다. 이 설정은 해당 프로젝트에 대해 전역적으로 적용된다. (당연히)

라이브러리 파일을 찾는 디렉토리 순서는 "링커-일반" 카테고리의 "추가 라이브러리 디렉토리"에다가 설정해도 되고, 아예 "도구-옵션" 명령의 "프로젝트 및 솔루션-VC++ 디렉토리" 카테고리에다가 완전 전역적으로 설정해도 된다.

하지만 내가 관리하는 프로젝트를 어느 컴퓨터의 비주얼 스튜디오에서나 바로 빌드하고 싶다면(외장 하드 같은 데에 담아다가), 디렉토리 순서는 후자의 애플리케이션 단위가 아닌 전자의 프로젝트 단위로 지정해 두는 게 좋을 것이다.
사실, "도구-옵션" 명령의 디렉토리 설정에다가는 C/C++ 기본 라이브러리나 윈도우 플랫폼 SDK 같은 완전 기본적인 디렉토리만 설정해 두고, 내 프로젝트에 특화된 디렉토리는 지정하지 않는 걸 추천한다.

2. 프로젝트의 구성원으로 라이브러리 파일 자체를 추가

한 프로젝트를 이루고 있는 여러 소스 파일들 중, 컴파일러 같은 특정 빌드 도구를 거치지 않은 파일은 자동으로 링커에게 그대로 전달되게 된다.
그렇기 때문에 굳이 링커 옵션을 지정하지 않더라도 프로젝트에 포함되어 있는 lib 파일은 링크 과정에서 자동으로 인식되고 사용된다.

지정하려는 라이브러리가 다른 SDK가 아니라 역시 내가 만들고 수정하고 관리하는 것인 경우에는, 이렇게 해 두는 것도 괜찮다. 특히 링커 옵션이나 "도구-옵션" 설정에 지정되어 있지 않은 임의의 디렉토리에 있는 아무 라이브러리나 자유롭게 참고할 수 있다는 장점이 있다.
단, 이 방법은 debug/release 같은 configuration별로 한 라이브러리의 여러 변종 파일을 지정하기가 좀 까다롭겠다.

옛날에, 거의 비주얼 C++ 6 시절엔, DLL을 만들 때 쓰이는 모듈 정의 파일(def)도 그냥 소스 파일로 프로젝트에다 집어넣어 놓으면 링크할 때 알아서 인식이 됐던 것 같은데 닷넷 이상부터는 안 그런 것 같다. 반드시 "링커-입력" 카테고리의 "모듈 정의 파일"에다 이름을 넣어 줘야 하는 듯.

3. #pragma 지시문

전체 프로젝트 파일 중에서 극소수의 소스 코드만이 특정 희소 API를 사용하기 때문에 그 놈에 대해서만 추가 라이브러리 링크 지정이 필요한 경우엔, 그 소스 파일에다가만
#pragma comment( lib, "rare_lib.lib" )

이렇게 지정해 주면 아주 간단하고 편리하다. 프로젝트 파일 차원에서의 수정이 없으며 한 소스 파일을 여러 프로젝트에서 공유할 때 관리가 용이해진다. 물론 표준이 아니라 MS 컴파일러 확장이긴 하지만.
이 소스를 컴파일하여 생긴 obj 파일의 내부에는, "나중에 나를 읽어들이는 링커님은 내가 가진 심볼들을 링크할 때 요 lib 파일도 추가로 좀 참고해 주셈"이라는 힌트 정보가 포함되게 된다.

이 방법은 static library를 만들 때 유용하다.
A라는 클래스 라이브러리를 빌드하는데, 얘는 B라는 다른 라이브러리의 함수를 참고하는 C라는 메소드를 멤버로 가지고 있다고 치자.
그리고 나는 D라는 애플리케이션을 A 라이브러리를 기반으로 개발하고 있다고 치자.

이 경우, D는 C라는 메소드를 호출하지 않더라도 링크할 때 A뿐만 아니라, 사용하지도 않는 B 라이브러리를 역시 지정을 해 줘야 한다. 그렇지 않으면 링크 에러가 난다.

하지만 라이브러리의 소스 코드 자체에 내가 의존하는 다른 라이브러리에 대한 정보가 이미 포함되어 있으면, 사용자는 그 내부 의존성에 대해서 알 필요가 없어지는 것이다. C 메소드를 사용하든 안 하든 D 프로젝트는 B 라이브러리의 링크 지정을 안 해도 되게 된다.

Posted by 사무엘

MDIR은 도스 시절에, 특히 컴퓨터 깨나 하는 사람들의 거의 필수품인 쉘 겸 통합 유틸리티 프로그램이었습니다.

작고 가벼운 크기에 굉장히 편리한 인터페이스. 단축키에 중독되고 나면 이거 없이는 불편해서 못 살았죠. 기본적으로 텍스트 영문 모드였지만 한글 바이오스도 인식하고 나중 버전은 윈도우 95 아래에서 긴 파일 이름도 그럭저럭 잘 인식했습니다.

도스 시절엔 더 말할 필요도 없었고
한 확장자를 상대로 단일 연결 프로그램밖에 바로 실행 못 하는 윈도우 쉘과는 달리,
압축 파일 내용 바로 보는 기능, 드라이브를 바로 바꾸는 단축키(Shift+C, D), 특정 프로그램을 바로 실행하는 펑션 키 연결, 노턴 유틸리티 NCD를 필요 없게 만든 F10 MCD, 그리고 특정 단축키로 바로 디렉토리를 바꾸는 QCD, 그리고 두 창 열어서 보는 기능.

간단합니다.
원하는 디렉토리로 빨리 가고,
선택된 파일에 대해서 다양한 조작을 하는 다양한 프로그램을 키 조작만으로 바로 실행하는 것.

저도 처음부터 M 사용자는 아니었는데 94~95년경에 M 거의 광신자인 한 친구의 영향을 받아 쓰게 됐습니다. 아주 편리하더군요.
등록판으로 바꿔 주는 크랙도 한동안 쓰고 지냈지만, 98년에 그렇잖아도 도스용으로는 마지막 버전이 된 3.10이 나왔을 때 나름대로 돈 주고 정품을 구입했습니다.

등록판은 About 화면의 강제 딜레이가 없으며 서로 다른 드라이브로 디렉토리 통째 복사가 가능하고, 보라/mcopy 같은 보조 유틸들을 제대로 사용할 수 있었습니다.

알 만한 사람은 다 알지만 MDIR은 컴을 잘 못 다루는 개발자의 여자친구를 위해 개발되었던 걸로 유명합니다. 실제로 그 두 사람은 결혼했다고 전해집니다.

하지만 MDIR은 여자친구의 전유물로 그치지 않고 꾸준히 개발된 끝에, 01년 말에는 드디어 윈도우용도 나왔고, 개인 명의가 아닌 회사 제품으로 개발되기 시작했습니다.
솔직히 MDIR 정도면 EditPlus처럼 세계적으로 셰어웨어로 내놓고 팔아먹어도 손색이 없다고 느껴집니다. 미국 같은 데서는 솔직히 제가 지금까지 개발한 프로그램보다도(날개셋, WordTech 등) 규모가 작은 프로그램도 당당히 개인 개발자로서 이름 걸고 홈페이지 운영하면서 셰어웨어로 팔아먹는 경우가 많습니다.

이 정도 프로그램을 만들려면 운영체제 쉘 구조부터 시작해서 상당 수준의 하드웨어 지식, 인내심과 노가다 코딩까지 통달해야 했을텐데 놀랍기 그지없었죠.

하지만 2003년경, MDIR이 소속되어 있던 회사는 경영수지 악화로 인해 없어졌고, 개발자 역시 그 회사를 나와서 이제는 완전히 "은퇴"하고 말았습니다. MDIR의 소스는 갖고 있으되 공개할 의향은 없고, 그렇다고 해서 얘를 유지보수할 여건은 안 되고.. 한 마디로 그렇게 개발이 중단되고 묻혀 버린 것입니다.
개발자는 MDIR 개발만 중단한 게 아니라 IT계에서 완전히 은퇴했고, 이제 완전히 다른 사업을 하면서 산다고 합니다. (안습)

MDIR은 상당히 이색적으로 C/C++이 아닌 파스칼(볼랜드)로 개발된 것으로 잘 알려져 있습니다. 윈도우용은 자연히 델파이로 개발됐죠. 도스용은 EXE 파일이 아주 빡세게 암호화-압축돼 있기 때문에 일반적인 분석 방법으로는 빌드 개발툴을 알 수 없는데, 저는 처음에 이 정보를 어디서 얻었는지 모르겠습니다.

16비트 EXE이기 때문에 메모리 제약이 좀 있었고, 특히 MCD에서 1000개가 넘는 디렉토리를 표시할 수 없고, 한 디렉토리에서 2000개가 넘는 파일을 표시할 수 없는 게 아쉬운 점이었습니다. 후자는 단순히 파일이 다 안 보이는 걸로 끝이지만 전자는 디렉토리 스캔하다가 프로그램이 뻑났거든요. 도스용도 32비트 컴파일러로 재개발됐으면 참 좋았을텐데, 쉘 유틸리티의 특성상 하드웨어에 종속적인 명령이 많아서 개발툴을 바꾸기가 쉽지 않았을 것 같습니다.

윈도우용은 32비트이다 보니 메모리 제한은 없지만, 이제 유니코드를 지원하지 않는다는 아쉬움이 남습니다. 5.0에서 추가될 기능 중 하나이기도 했는데, 5.0은 끝내 나오지 않은 채 MDIR의 개발은 중단됐습니다.
이 때문에 MDIR 정식 등록자들이 무척 좌절하고 허탈해했습니다. 하지만 반대로 생각해 보면 MDIR의 개발자도 극심한 불법복제의 피해자이기도 했습니다.

등록판을 불법복제 하려면 최소한의 부끄러운 줄은 알고 혼자 조용히나 쓸 것이지 대놓고 개발자한테 시리얼 번호 알려 달라고 메일 보내는 골빈녀석도 부지기수였다고 하더군요.

MDIR 역시 뭐 복사방지 락이라도 달고 나온 건 아니고, 전적으로 소프트웨어적인 방법만으로 등록판 판별을 해야 했기 때문에, 등록판 판별 방식을 여러 번 변경하고, EXE의 리버스 엔지니어링을 막기 위해 복잡한 방법으로 실행 파일 암호화/압축을 거쳤던 것입니다.
  (개인적으로 도스용 게임 Titus Fox이 컴퓨터별로 레벨 코드 생성을 어떤 원리로 하는지가 무척 궁금하기도 합니다.)

윈도우 비스타에서도 WinM이 돌아가긴 합니다. 하지만 32비트 어플의 특성상, 64비트 윈도우 시스템 디렉토리 같은 곳엔 접근이 되지 않습니다. 32비트 윈도우 시스템 디렉토리로 그냥 리다이렉션 돼 버리죠. (속임수)

어쨌거나 컴퓨터 세계는 이제 진짜로 기술이나 아이디어만으로는 자본력을 도저히 못 당해 내게 흘러가는 것 같습니다. 그리고 이 컴퓨터의 힘을 입어 컴퓨터뿐만 아니라 다른 업종도 다 저렇게 바뀌고 있습니다.

Posted by 사무엘