« Previous : 1 : ... 72 : 73 : 74 : 75 : 76 : 77 : 78 : 79 : 80 : ... 221 : Next »

우리나라에는 자동차 기반의 장거리 대중 교통수단으로 고속버스와 시외버스라는 이원화된 시스템이 존재한다.
사실, 법적으로는 이들은 일반형 시외버스, 직행형 시외버스, 고속형 시외버스라는 세 부류로 나뉘는데, 고속형 시외버스가 고속버스라고 여러 모로 특별 취급을 받는 구도이다. 그리고 나머지 시외버스들도 시대의 흐름에 따라 갈수록 직행화하고 고속버스와 형태가 비슷해지고 있다.

본인은 옛날 대학 시절에 경주에서 울진으로 가는 시외버스를 이용한 적이 있었다. 고속도로가 없이 국도만 타느라 울진까지 가는 데 4시간이 넘게 걸렸던 걸로 본인은 기억한다. 더구나 이런 지방 왕래 수요가 많을 리가 없으니, 버스도 무슨 완행 열차가 정차하듯이 온갖 시골 정류장들을 들쑤시고 다녔다. 그래야 수지가 맞을 것이다.

지방에서 시외버스는 원래 이런 식으로 운행되고 있다. 울진 같은 경북의 오지뿐만 아니라 당장 강원도의 전방에서 차가 없는 사람들의 이동을 책임지는 것도 시외버스가 유일하다. 화천· 양구 같은 곳에 철도가 있나, 공항이 있나? 동서울 터미널에 괜히 군인들이 우글거리는 게 아니다.

다만, 요즘은 집집마다 승용차를 굴리는 세상이며, 중소 규모 이상의 도시에는 철도 같은 대체제도 있다. 전국에 고속도로도 워낙 촘촘하게 많이 건설되고 있지 않은가?
그러니 버스도 경쟁력을 갖추기 위해서는 촘촘한 단거리 이동보다는 장거리를 어설픈 중간 경유 없이 승용차보다 더 빠르고 편하게 가는 것에 집중하게 되었다. 일반형 완행 시외버스는 저런 시골 지방 말고는 없어지는 추세이다. 철도로 치면 간이역들이 갈수록 없어지는 것과 비슷한 이치이다.

고속버스는 시외버스의 고급 특화 케이스이기 때문에 시외버스보다 노선이 훨씬 적다. 그 덕분인지 승차권 발매· 예매를 위한 단일 통합 전산망도 2000년대 초부터 시외버스보다 훨씬 더 잘 갖춰져 있었다. 과거 1980년대에 철도 승차권 전산 발매도 새마을호에 제일 먼저 적용되었던 것처럼 말이다.

현행법에 따르면 길이가 100km 이상이고, 전체 구간의 60% 이상을 고속도로로 달리는 노선에만 고속버스가 투입될 수 있다. 고속도로는 그 정의상 최대 속도가 100km/h 이상으로 정해진 곳이니 고속버스의 정의에는 속도와 거리에 모두 100이라는 숫자가 존재하는 셈이다.

경주-대구 사이에는 고속버스와 시외버스 노선이 모두 존재해서 서로 경쟁 중이다. 저기는 80km가 안 되는 짧은 거리이지만, 100km 이상 규정이 생기기 전부터 있었기 때문에 고속버스 노선이 여전히 존재하는 중이다. 마치 이화여대 초등교육과가 전국에서 유일하게 초등학교 교사를 양성하는 사립 기관이듯이 말이다. (국립 교육대들보다 먼저 존재했음)
뭐, 신경주 역에서 KTX를 타면 동대구 역까지 20분이 채 걸리지 않지만.. 운임과 역 접근성 때문에 버스도 여전히 경쟁력이 있다. (역이 시내에서 너무 멀므로..)

그리고 고속버스는 태생적으로 중간 정차가 거의 허용되지 않는다. 시점과 종점만 있는 시외버스라는 게 원래는 고속버스의 전유물이었다. 고속버스는 고속도로 휴게소에 두세 시간 간격으로 정차하고, 아니면 시점 또는 종점과 동일한 지역에 소재한 정류장에 딱 한 번만 추가 정차할 수 있다.

대표적인 예는 대구-서울 고속버스이다. 상행은 동대구 역 근처에 있는 터미널을 출발한 뒤에 서대구 정류장을 들렀다가 서울로 가며, 하행은 반대로 서대구 정류장을 들렀다가 터미널로 간다. 대구 시내 안에서 터미널과 정류장 사이만 왕복하는 용도로는 고속버스를 이용할 수 없다.

즉, 쟤들은 터미널을 출발하자마자 곧장 고속도로로 진입하지 않는다. 굳이 대구 시내를 횡단해서 서대구 정류장을 경유하느라 고속버스의 표정속도가 하락하는 건 개인적으로 아쉽게 느끼는 점이다.
이 정도만이 고속버스에게 허용된다. 이런 고속버스와는 달리, 동서울을 출발한 직행 시외버스는 경주에서 승객을 하차시킨 뒤 포항까지도 간다.

다음으로 운임의 측면에서 살펴보면, 고속버스는 시외버스보다 고급스럽고 사치스러운(?) 교통수단으로 간주되어 운임에다 부가가치세가 붙는다. 즉, 원가 대비 차삯이 더 비싸다. 하지만 겨우 고속버스가 사치품인 것은 무슨 1970년대에 경부 고속도로라는 게 처음 생겼고 버스 안에 안내양까지 탑승하던 시절의 사고방식에 지나지 않는다. 법리적으로 볼 때 부가세를 폐지하는 것이 옳다는 지적이 있어 왔다.

고속버스에는 1991년인가 92년부터 우등이라는 등급이 생겨서 좌석 수가 더 적고 넓고 큼직한 대신, 더 비싼 버스가 등장했다. 열차는 상위 등급이 정차역 수가 적고 더 빨리 가는 반면, 고속버스는 처음부터 중간 무정차를 표방했기 때문에 우등이라고 해서 더 빠른 건 아니다. 그 대신 버스는 그 구조상 한 차량 안에서 특실/일등석(!) 같은 구분은 없다.

새마을호에 종아리 받침대가 달린 한국 철도 역사상 최고급 좌석이 등장한 것도 비슷하게 1990년대 초인 것으로 본인은 기억하는데.. 우등 고속을 의식한 것인지, 아니면 반대로 우등 고속이 더 나중인지는 정확한 시기와 역학관계를 잘 모르겠다. 승차감과 좌석 앞뒤 간격은 철도인 새마을호가 더 낫고(특히 특실은!), 좌석과 팔걸이의 폭은 아예 2-1 배열인 우등 고속이 더 컸던 것으로 본인은 기억한다.

직행형 시외버스에도 우등형 좌석 차량이 있다. 단, 얘들은 앞뒤 간격이 우등 고속보다 약간 더 좁아서 28인승이 아닌 33인승이다.

고속버스 업계에서는 우등 고속이 생긴 지 25년 가까이 지난 2017년부터 우등보다도 더 고급스러운 21인승 프리미엄 우등이라는 것도 등장했다. 하지만 이건 서울-부산 같은 소수 장거리 노선 말고는 막 보급되기 어려울 듯하다. 우리나라가 무슨 1000km짜리 노선이 있는 것도 아닌데.. 속도의 향상 없이 내장재만 잔뜩 고급화해서 비싼 운임을 받는 건 타 교통수단 대비 경쟁력을 확보하기 곤란하다. 다만, 좌석에 콘센트나 폰 충전 단자가 있는 버스라면 개인적으로 귀가 약간 솔깃해지긴 한다!

지금이야 시대가 어느 시대인데 시외버스도 고속버스 못지않은 승차권 전산 발매 인프라를 갖췄고, 심지어 시내/광역버스처럼 교통카드 결제가 가능해지기도 했다. 줄 서서 창구에서 표 사는 번거로움을 덜기 위해 맨 처음에는 무인 예매 발권기라는 게 생겼고 2000년대 초반에는 홈티켓이 유행했는데, 이제는 그냥 모바일 승차권을 써도 된다.
그리고 고속버스도 무조건 한 차량으로 시점-종점만 고집하는 게 아니라, 휴게소 환승이라는 것도 이미 10여 년 전에 생겼다.

그 전에 옛날에는 고속버스의 승차권 전산 발매 시스템이 통합돼 있지 않아서 일부 지역은 kobus, 일부 지역은 이지티켓(easyticket)으로 별도의 사이트를 이용해야 했다. 그 시절에 동영상 코덱들이 난립하고 휴대전화 충전 단자들이 통일돼 있지 않았던 것처럼 말이다.

또한 대구는 대도시에 걸맞지 않게 고속버스 터미널이 회사별로 찢어져 있던 것으로 악명 높았다. 동부/서부 이렇게 정말 지리적으로 서로 멀리 떨어진 게 아니라, 똑같이 동대구이고 그냥 한 블록 간격인데 회사가 관할하는 행선지별로 터미널이 찢어진 것이다. 더구나 이게 전산 시스템에도 반영돼서 '대구 한진', '대구 동양' 같은 식으로 찢어졌으니 병크가 따로 없었다.

그러다가 대구에 드디어 동대구 역과 연계되고 기존 동부 시외버스 정류장과 백화점까지 통합한 동대구 통합 고속버스 터미널이 완공됐으니.. 참 오래 살고 볼 일이다. 진작에 그렇게 됐어야 했다.
이 추세라면 시외버스와 고속버스라는 두 체계는 궁극적으로 하나로 통합해도 되지 않나 싶다. 육군이 서부와 동부 전선 야전군(제1, 제3)을 통합해서 그냥 전방 담당 사령부를 만든 것처럼 말이다.

이제는 고속도로를 달리는 게 별다른 특권이 아니며 직행 시외버스와 고속형 시외버스의 경계가 굉장히 모호해졌기 때문이다. 고속버스만 타 시외버스와 다르게 취급할 이유가 별로 없다. 단일 시외버스 체계에서 시골 지방을 위한 완행 아니면 직행 구분만 하면 될 것 같다. 차량과 전산망 말고 터미널 건물은 요즘 모든 지역들이 고속과 시외 구분 없이 통합해서 만드는 게 대세가 된 지 오래다.

한반도에 철도와 시내버스까지는 일제 시대에도 있었던 교통수단이다. 그러나 고속철은 말할 것도 없고 그 전에 고속도로와 고속버스라는 것은 그 시절을 넘어 할배 슬하의 1공화국 시절에도 없었다. 1970년대 박통 때에 와서야 등장했다.
사실, 일제 시대 경성 시내 사진을 봐도 길거리에 자동차와 노면전차까지는 다니지만, 길에 차선이 그어지고 신호등이 설치된 걸 본 적은 없을 것이다. 미국 LA는 1940년대 모습이 이미 우리나라의 1970년대 이상 같고 자동차의 모양만이 옛날 디자인 같은데.. 참 대조적이다.

그렇게 길거리에 교통 시설이 아무것도 없다시피했기 때문에 미군정은 1946년에 자기 재량으로 한반도에서 자동차의 통행 방향을 좌측에서 우측으로 곧장 변경할 수 있었다. 자동차가 극히 드물던 시절, 고속버스를 타는 것만으로도 지금으로 치면 비행기를 타는 것 같은 희소한 경험이던 시절에 사람들의 삶이 어떠했을지가 궁금하다.

또한 저것보다는 비교적 가까운 과거에 운전석 옆에 안내양이 앉는 작은 의자가 있던 시절, 그리고 우등 고속의 오른쪽 맨 앞자리(3번)에 냉장고와 이동식 공중전화가 비치되어 있던 시절, 현대도 대우도 아닌 아시아 자동차 버스가 있던 시절도 개인적으로 문득 그리워진다.

Posted by 사무엘

2019/03/28 19:33 2019/03/28 19:33
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1602

스텐실 폰트

* 굉장히 오랜만에 폰트 분야에 글을 하나 추가하게 됐다.

지금은 실생활에서 좀 보기가 힘들다만.. 30대 이상의 나이가 좀 있으신 분들 중에는 요런 투박한 모양의 글자 내지 숫자를 각종 표지판이나 벽면, 차량의 외부에서 본 적이 있을 것이다. 양각· 음각 형태로 새겨지거나 오려 붙여진 게 아니라, 물감· 페인트로 칠해진 형태로 말이다.

사용자 삽입 이미지

이 글꼴의 컨셉은 글자가 가독성을 해치지 않는 한도 내에서 획의 일부가 규칙적으로 끊어지고 단절돼 있다는 것이다. 특히 O 대신 ()이고, ㅁ 대신 [] 모양이다.

미술· 디자인 쪽으로 조예가 있는 분이라면 이미 다 눈치 채고 아시겠지만, 이건 '스텐실'이라고 불리는 인쇄 내지 칠하기 기법에 맞춰진 글꼴이다.
투명한 필름지 같은 것에다가 도안을 그려서 선이나 면을 잘라내고, 그걸 종이 위에다 올린다. 그 뒤 필름에다가 칠을 하면 필름이 없어서 종이가 노출된 영역에만 색이 칠해진다. 이 필름지를 이용하면 동일한 그림도 여러 번 쉽게 찍어낼 수 있다.

판화와는 접근 방식이 다르다. 판화는 개념적으로 도장과 비슷하며, 찍는 과정에서 좌우가 바뀐다. 하지만 스텐실은 칠하는 방식이 다르니 그런 mirroring이 발생하지 않는다. 판화와 달리 칠을 더 다채롭고 다이나믹하게 할 수 있다.
그러나 스텐실은 판화에는 해당사항이 없는 한계도 존재하는데, 내부의 구멍을 구조적으로 표현할 수 없다. 그렇기 때문에 내부의 구멍이 존재하는 글자는 부득이하게 획의 일부를 끊어서 구멍 내부도 외부와 연결되게 해야 한다.

기왕 획의 일부를 끊었으니 이걸 일관된 개성과 컨셉으로 삼아서 스텐실용 글꼴을 만들어 보자는 발상은 서체 디자이너들이 누구나 할 수 있었던 생각이다.
저 영문 Stencil 글꼴에서 보듯, 획 굵기의 기복이 있는 세리프 계열 글꼴이 단절감이 덜하고 좀 더 어울린다. 어차피 획이 최대한 가늘어지는 곳에다가 단절을 시키면 되기 때문이다.

하지만 산세리프 계열에도 스텐실 글꼴이 얼마든지 존재한다.

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

디지털 글꼴이 없던 옛날에 이런 글자들은 스텐실 기법으로 만들어지고 복제된 도안들이라고 생각하면 된다.

사용자 삽입 이미지

버스의 경우, 동일한 노선을 달리는 버스가 수십 대 이상 있었을 테니 이렇게 행선지를 인쇄하는 게 합리적이었을 것이다.

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

옛날에 군부대 근처에 있던 "접근금지", "위험" 표지판도 다 이런 식이었던 것 같다.
지금이야 옛날 같은 투박함과 엉성함은 사라지고 스텐실 컨셉을 일부러 흉내 낸 깔끔한 글꼴을 골라 쓰는 시대가 됐지만 말이다.

일반적인 책과 문서에서는 Times 같은 평범한 본문용 서체를 쓰는 반면,

  • 타자기나 코딩용으로는 딱딱한 불변폭 서체를 쓰고,
  • 기계가 인식하기 편하라고 타자기와 비슷하면서 획을 간소화시킨 그 특유의 OCR용 서체도 만들고,
  • 멋을 내기 위해서는 기울이고 날리고 최대한 한붓그리기를 추구한 필기용 서체를 쓰고,
  • 열악한 디지털 기계에서는 8픽셀도 채 안 되는 높이 내지 7-segment 같은 극도로 단순한 형태로 문자 외형을 간소화도 하고,
  • 스텐실용으로는 이렇게 구멍이 없는 서체를 쓰는 등..
문자를 용도에 따라 다채롭게 활용 가능하게 하는 것이 타이포그래피의 묘미임이 틀림없다.

그나저나 오늘날 같은 디지털 인쇄와 복사 기술이 발달하기 전에 등사처럼 아날로그 판화· 인쇄술이 어떠했는지에 대한 의문과 관심이 문득 생긴다.

Posted by 사무엘

2019/03/26 08:36 2019/03/26 08:36
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1601

1. 32비트 컴파일러: 16비트 메모리 접근의 한계를 극복하기

예전에도 언급한 적이 있지만.. 1993년 말에 발매되었던 Doom 게임은 그야말로 충격적인 3차원 그래픽 덕분에 게임 업계에 큰 충격을 선사했다. 업계 종사자들은 기술 수준 자체뿐만 아니라 "얘는 어셈블리어를 거의 사용하지 않고 순수 C만으로 개발되었습니다"라는 존 카맥의 말에 더 큰 충격을 받게 됐다.

훗날(1997년) Doom의 소스 코드가 공개되면서 이 말은 사실임이 밝혀졌다.
Doom은 무슨 16비트 Windows 같은 쑤제 어셈블리어 튜닝 위주로 개발된 게 아니라, Windows NT처럼 굉장히 이식성 있게 개발되었다. 그러니 Doom 엔진 기반의 수많은 게임과 mod들이 온갖 플랫폼으로 이식되어 만들어질 수 있었다.

단지, 오리지널 도스용의 경우, 컴파일러를 그 당시에 흔하던 볼랜드나 MS 같은 16비트용을 쓴 게 아니라 Watcom이라는 다소 생소한 32비트 고성능 제품을 썼을 뿐이다.
그리고 어셈블리어를 안 쓰더라도 고정소수점이라든가, IEEE754의 특성을 이용해서 3차원 그래픽용 실수 연산(삼각함수, 제곱근, 벡터 정규화...)을 왕창 빠르게 수행하는 각종 tweak들은 응당 최대한 구사해서 성능을 끌어올렸다.

그러니 Doom은 아직 상대적으로 생소하던 32비트 컴파일러라든가 DOS/4G 도스 익스텐더 같은 물건의 인지도를 끌어올려 줬다. 이렇게 Doom을 통해 Watcom 컴파일러까지 알렸던 id 소프트웨어에서는 훗날 퀘이크를 만들어서 이번에는 오픈소스 진영의 걸출한 도스용 32비트 컴파일러이던 djgpp를 알리게 되었다.

운영체제 자체를 OS/2나 Windows NT처럼 통째로 32비트로 쓰기에는 아직 기계값이 너무 비싸고 특히 메모리가 부족했다. 그러니 도스에서 돌아가는 일부 대형/고사양 프로그램이 자체적으로 도스의 한계를 극복하고 보호 모드로 진입하는 솔루션을 내장했던 것이다.

생각해 보니 국내에서도 아래아한글 2.1이 전문용은 Watcom C/C++을 이용한 32비트 전용으로 만들어졌다. 얘는 발매 시기가 심지어 Doom보다도 3개월 남짓 더 앞섰다(1993년 9월 vs 12월). 그러니, 터보 C, 볼랜드 C++ 하던 그 시절에도 32비트 컴파일러에 대해서 알 사람은 이미 다 알기는 했던 모양이다.

다만, 아직도 286 똥컴이 많이 굴러다니고 서민용 운영체제들은 아직도 16비트 도스와 Windows가 주류인데, 내 프로그램을 386 전용으로 개발하는 것에 대한 득과 실을 신중하게 따져야 했다. 오죽했으면 아래아한글도 후속 버전인 2.5와 3.0에서는 일반용/전문용 구분이 없어지고 그냥 hwp86.exe와 hwp386.exe 두 에디션을 모두 내장하는 것으로 형태가 바뀌었다. 추가 글꼴과 사전 컨텐츠는 '확장팩'으로 분리되고 말이다.

아래아한글은 Phar Lap 도스 익스텐더를 사용했다. 아래아한글이 그 시절의 도스용 게임처럼 DOS/4G(W) 로고를 띄우면서 실행되었다면 무척 볼 만했을 것이다.
86과 386 에디션은 성능 말고는 덧실행 프로그램이 지원되는지의 여부가 가장 큰 차이점이었다. 덧실행은 16/32비트용이 따로 나오지 않고 32비트 전용이었기 때문이다.

화면 보호기들, 그리고 확장팩에서 제공되었던 프라임 영한사전도 다 덧실행 프로그램이었다.
먼 옛날 1.2 시절에는 별도의 액세서리로 테트리스 게임이 있었는데 나중에 그게 덧실행으로 컴백한 걸 보니 개인적으로 감회가 새로웠었다.

이렇게 1990년 중반에 도스용 프로그램들의 32비트화 추세와 달리, 마소는 진작부터 PC에서 도스를 Windows로 대체하려는 큰 그림을 갖고 있어서 그런지.. 도스용으로 32비트 컴파일러를 결코 내놓지 않았다. 정작 자기들은 그 기술을 내부적으로 보유하고 사용했으면서 말이다.
Visual C++ 1.5x는 16비트 도스/Windows 바이너리들을 빌드할 수 있었는데, 명령 프롬프트에서 돌아가는 컴파일러와 링커 같은 툴들은 그냥 32비트 프로그램이 아니라 32비트 PE 기반의 콘솔 프로그램이었다.

Windows NT 같은 데서는 직통으로 실행 가능하고, 도스에서 실행되면 stub으로 embed된 도스 익스텐더가 컴을 보호 모드로 진입시키고 CreateFile/GlobalAlloc 같은 Win32 API를 제공해서 프로그램을 실행했다.
스레드를 만들지는 못했겠지만 컴파일러· 링커가 사용하는 Win32 API야 뭐 파일이나 메모리 I/O 정도밖에 없었을 것이고, 이건 도스 익스텐더가 감당 가능했다. 결국 한 바이너리만으로 도스와 Windows에서 모두 사용 가능.

이건 뭐 콘솔 프로그램계의 Win32s나 마찬가지인 엄청난 기술인데.. 마소의 Visual C++에서 이런 이중 바이너리를 만드는 걸 end-user에게 지원한 적은 내가 알기로 없다.
마치 C# 네이티브 코드 컴파일러만큼이나 대외적으로 공개되지 않고 마소 내부에 봉인된 기술인 것 같다.

2. 슈퍼 VGA 라이브러리: 표준 VGA의 한계를 극복하기

IBM 호환 PC라고 불리는 물건에서 IBM이 주도하는 PC의 단일/표준 규격이라는 건 286 AT 이후로 없어졌다. 그러니 286 이후로 최초의 386 PC는 IBM이 아닌 컴팩에서 출시되기까지 했다.
그리고 그래픽 카드도 절대불변 단일 표준은 1987년의 구닥다리 VGA가 마지막이다. 표준 VGA는 800*600 해상도조차 지원하지 않았으며, 그나마 색깔이 아쉬운 대로 다양해진 256색은 겨우 320*200에서밖에 지원되지 않아서 업무라기보다는 그냥 게임 전용 모드로만 쓰였다.

그 뒤로 VGA보다 더 높은 해상도와 더 많은 색상을 지원하는 규격은 그야말로 온갖 싸제 SVGA 제조사들이 난립하면서 파편화 천국이 됐다. VESA 같은 규격이 괜히 필요해진 게 아니다.

이게 불과 1990년대 초반의 일이니, 앞에서 언급한 보호 모드가 어떻고 DPMI가 제정되던 때와 시기적으로 비슷하다. 하긴, 1990년에 나온 그 옛날 프로그램인 Deluxe Paint조차도 처음 실행될 때 맨 아래에 1024*768 256색 SVGA 모드가 있긴 했다. 물론 당대에 그걸 선뜻 고를 수 있을 정도의 금수저 컴퓨터를 소유한 사용자는 매우 소수였을 것이다.

마소의 베이직 컴파일러야 SCREEN 명령으로 SVGA 지원은 전무했다. API 구조가 완전히 다른 3rd-party 라이브러리를 구해서 써야 했다.
볼랜드의 경우는 상황이 약간 낫다. 비록 자체적으로는 VGA까지밖에 지원하지 않았지만, 일종의 그래픽 드라이버인 bgi 파일이 내부 스펙이 공개돼 있고 확장 가능했기 때문에 이걸 기반으로 SVGA 라이브러리를 만든 곳이 있긴 했다.

검색을 해 보니 Jordan Hargraphix 소프트웨어가 이 업계의 독자적인 큰손이었던 모양이다. 이미 1991년 무렵부터 유명했다.
바이오스를 거치지 않고 일명 VGA mode X라고 불리는 320*240, 400*300 같은 변형 모드까지 다 지원했다.
그때는 소프트웨어가 잘못된 명령을 내려서 컴퓨터만 뻗게 하는 게 아니라 모니터를 손상시키는 것도 가능했던 시절이다. (주사율 변조..) 옛날에 CGA도 160*100 같은 tweak mode가 있었다고 하는데 그것만큼이나 신기한 일이 아닐 수 없다.

다만, BGI라는 그래픽 API는 무려 1980년대 후반에 개발된 것이며, 아무리 bgi 드라이버를 새 하드웨어에 맞게 확장한다 해도 256색 이상의 색을 지원하는 것은 구조적으로 불가능했다고 한다. 트루컬러 SVGA를 지원하려면 완전히 새로운 독자 라이브러리를 써야 했다.
BGI는 색상을 관리하는 게 RGB값 기반이 아니라 팔레트 인덱스 기반으로 고정돼 있었던 모양인데, 16비트 시절에 이는 충분히 수긍이 간다. 쟤가 무슨 Windows GDI 급으로 하드웨어 통합과 추상화를 표방한 물건은 아니었으니 말이다.

도스용 아래아한글은 16비트 바이너리의 경우 Turbo/Borland 컴파일러로 개발되었다. 하지만 아주 초창기인 1.x 시절부터 그래픽 라이브러리를 독자 구현했는지, 볼랜드의 보급 BGI 라이브러리를 사용한 흔적이 전혀 없는 것이 매우 흥미롭다.
이건 비슷한 시기에 도스용 한메 타자 교사도 마찬가지다. 얘도 MS C로 개발되었지, 의외로 볼랜드 출신이 아니다.

Posted by 사무엘

2019/03/23 08:31 2019/03/23 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1600

제2중부 고속도로(37)는 중부 고속도로(35)의 서울-수도권 구간을 확장하는 과정에서 추가로 건설된 고속도로이다.
도로를 확장해야겠는데 기존 도로는 다들 평지가 아닌 고가 교량 형태여서 그걸 건드릴 수는 없다. 그래서 옆에 도로를 더 만들게 됐다.

그럼 보통은 기존 도로는 전부 하행, 새 도로는 전부 상행.. 이런 식으로 개편하는 게 자연스러울 것이나, 중앙분리대를 제거하고 각종 도로 표지판들을 변경하고 진출입로를 이설하는 작업마저도 여의찮았는지 결국 기존 도로는 하나도 안 건드리고 그대로 놔 두게 됐다. "새 도로 추가.. 그 대신 새 도로는 중간에 진출입로가 없는 직행" 컨셉으로 제2중부 고속도로가 만들어졌다. 그리고 이 결과는 운전자들에게 "중부냐, 제2중부냐" 하는 눈치 게임으로 전가됐다.

중부와 제2중부가 병행하는 구간, 그리고 그 이북으로는 휴게소가 다음과 같이 3개가 존재한다.

(1) 마장 프리미엄 휴게소

중부와 제2중부 고속도로 사이의 섬이라는 꽤 적절한 위치에 굉장히 거대한 규모로.. 거의 복합 쇼핑센터 컨셉으로 비교적 최근에 만들어졌다(2013). 도로들보다 나중에 생겼다는 점으로 인해 진출입로에 입체 교차로 같은 건 없다. 그래서 중부에서는 상행만(하남 방면), 제2중부에서는 하행(청주 방면)만 이 휴게소에 접근 가능하다.

즉, 두 고속도로에서 한 휴게소를 공유하지만 방향은 제각기 반쪽짜리이다. 그리고 방향별로 주차장이 서로 분리돼 있기 때문에 들어왔던 차량이 방향을 바꿔서 나갈 수는 없다.

(2) 이천 휴게소

상행과 하행 휴게소가 제각기 3km 가까이 떨어져 있다. 상행은 두 고속도로가 공유하며, 나갈 때 중부와 제2중부 정도야 도로를 바꿔치기 할 수도 있다.
하행은 마장 프리미엄 휴게소와 아주 가까이 있는데, 얘는 오로지 중부 고속도로의 하행만 접근 가능하고 제2중부는 해당사항 없다. 그쪽은 어차피 마장 휴게소로 가면 되기 때문이다.

정리하자면, 이 구간에서 중부+상행이라면 마장과 이천 휴게소를 모두 이용할 수 있다. 그러나 제2중부+상행과 중부+하행은 이천 휴게소만 이용 가능하며, 제2중부+하행은 마장 휴게소만 이용 가능하다.

(3) 하남드림(구 만남의 광장) 휴게소

경부 고속도로에 있는 '만남의 광장 휴게소'의 중부 고속도로 버전이다. 과거에는 실제로 이름도 동일하게 '만남의 광장'이었다고 한다.
다만, 얘가 경부 고속도로 만남의 광장과 다른 점은 다음과 같다.

  • 경부 만남의 광장은 그래도 과거에 톨게이트가 있었고 현재도 시내 도로와 고속도로의 경계인 지점에 있는 반면, 하남드림은 앞뒤로 여전히 차들이 쌩쌩 달리는 고속도로 상에 있다.
  • 경부 만남의 광장은 상행 방면에서는 진입할 수 없는 반면, 하남드림은 상행 방면에서도 지하도를 거쳐서 진입 가능하다.

그렇기 때문에 경부의 상행에서는 죽전 휴게소가 마지막 휴게소이지만 중부의 상행은 하남드림이 마지막 휴게소이다.
그리고 이 두 만남의 광장은 모두 서울/동서울 톨게이트를 지나고 요금제가 개방식으로 바뀐 구간에 존재한다. 그렇기 때문에 차들을 진행 방향별로 분리하지 않으며, 나갈 때는 상행이나 하행 아무데나 자유롭게 나가면 된다. 단지, 경부 만남의 광장은 들어오는 게 하행에서만 가능하다는 차이가 있을 뿐이다.

Posted by 사무엘

2019/03/21 08:31 2019/03/21 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1599

영화들 중에는 주인공이 극단적인 사고 또는 범죄를 당해서 특이한 위험한 장소에 갇히고 거기서만 이야기가 진행되는 형태인 것이 몇 가지 있다.
이런 장르는 촬영 영역이 아주 좁고 등장 인물도 적은 특성상, 대작을 만들기는 어렵다. 하지만 굉장한 저예산으로도 작품을 너끈히 만들 수 있으며, 잘 만들면 스케일 대비 소재와 설정이 참신하다고, 작품성이 훌륭하다는 칭찬도 들을 수 있다.

가장 먼저 떠오르는 예는 (1) <베리드(Buried)>(2010)이다. 주인공은 생매장-_-을 당해서 지하의 관짝 안에 있으며, 영화는 온종일 이 좁은 관 안에서만 진행되니 촬영 하나는 기가 막히게 단순하고 쉬웠을 것 같다. 관을 구성하는 직육면체 옆면 네 개 중에서 하나는 촬영을 위해서 뜯어냈을 것이고..

주인공은 유일한 희망인 휴대전화로 전화 통화를 하면서 외부 사람에게 자기 위치를 알려주고 구조 받으려 애쓰지만.. 거기 지역이 지역인지라 일이 영 쉽지 않다. 영화 자체는 공식적으로 열린 결말로 끝나지만, 주인공은 사실상 죽는 것이나 마찬가지이다.

주인공은 명을 단축하는 그 어떤 치명상도 입은 게 없다. 하지만 저렇게 좁은 관 안에서 누운 채 꼼짝달싹 못 하는 채로 목마르고 굶주리며 아주 서서히 죽는 건 단칼에 푹찍악 해서 죽는 것 만만찮은 비참한 죽음인 게 틀림없다. 당장 화장실도 못 가고 변을 그 자리에서 배출해야 한다는 걸 생각해 보자..;;

사람은 가만히만 있어도 언젠가는 죽는다. 허나, 아무리 사람이 물리적으로 연약하다 해도 그 명줄이란 게 호락호락 쉽게 금방 끊어지지는 않는다. 좀 민망한 얘기이다만, 자살하려는 사람들이 더 빨리 죽으려고 굳이 목을 매달거나 옥상에서 뛰어내리거나 번개탄을 피우는 등의 수고를 괜히 하는 게 아니다.

그러고 보니 옛날에 조선에서는 사도세자가 관은 아니고 뒤주에 갇혀서 저렇게 죽었다.
<킬 빌 2>(2004)에서는 잘 알다시피 버드가 주인공 키도를 제일 천천히 고통스럽게 죽여 주겠다면서 생매장을 해 버리는데, 이건 나름 머리를 쓴 조치였다. 물론 이 영화에서는 생매장 씬이 10여 개에 달하는 전체 스토리 중 극히 일부 에피소드만을 구성할 뿐이며, 결정적으로 주인공이 비현실적인 인간 흉기인 관계로... 정권으로 관을 때려부수고 무덤을 탈출한다는 차이가 있다.

<베리드> 얘기가 좀 길어졌는데, 이것 말고 (2) <화씨 247도>(2011)는 주인공 남녀 일행이 뜨거운 사우나 안에 갇혀 버리는 내용이다. 문의 자그마한 유리창을 주먹으로 쳐서 깬 덕분에 최소한의 환기와 냉각은 가능해졌지만, 사우나는 어차피 온도에 따라 화력이 자동으로 조절되고 있으며 세 명이나 되는 사람이 얼굴을 거기로 들이민 채로 잠을 잔다거나 할 수는 없다. 나름 실화를 바탕으로 만들어졌다는데, 결말에서는 남자 주인공이 결국 죽는다..;;

(3) <12피트>(2017)는 자매지간인 아가씨 두 명이 커다란 수영장 내부에 갇히는 내용이다. 수영장의 수면 위로 덮개가 쳐지는 바람에 물 밖으로 머리를 내밀고 있기가 극도로 어려워졌다. 이 상태로 수영장 관리자는 퇴근을 해 버리고, 그대로 불금 주말이 시작된다..;; 주인공들은 점점 지쳐 가고 체온이 떨어지는데..
다행히 수영장에 다른 사람이 들어오긴 하지만, 관객들 열불나게 하는 짓을 벌이면서 주인공들을 호락호락 구해 주지 않는다.

<화씨 247>은 짐작하다시피 사우나의 내부 온도를 나타내며(섭씨 거의 120도), <12피트>는 수영장의 깊이를 나타낸다(3.7미터). 둘 다 주인공들이 처한 극한 상황의 특성을 제목으로 뽑았다는 점이 흥미롭다.

이런 장르의 영화 소재를 앞으로 뭘 더 떠올릴 수 있을지 궁금해진다.
가령, 엘리베이터 안에 갇히는 건... 설마 했는데 (4) <데블>(2010)이라는 작품이 있다. 5명이 타고 있던 고층 건물 엘리베이터가 갑자기 고장 나는데, 무척 인위적이고 비현실적인 설정이긴 하다만 불이 잠시 나갈 때마다 엘리베이터 안에서 누군가 한 명씩 다치거나 죽는다.;;

밀실에서 범인이야 뻔한 노릇인데, 저 탑승자를 뒷조사 해 보니 저마다 사기꾼, 폭력 전과 등등 경력이 화려하다.
현실에서는 엘리베이터가 충분히, 너무 안전하게 만들어져 나오기 때문에 고증을 많이 무시하지 않고서는 저런 식의 영화화가 곤란할 듯하다.

끝으로, 좀 옛날 영화인 (5) <폰 부스>(2002)는 사건 전개 장소가 시내 한복판이니, 사우나나 수영장 같은 통상적인 감금의 범주에 들지는 않는다. 하지만 빌딩숲 어딘가에 숨어 있는 저격수를 설정해서 "그 전화를 끊는 순간 네놈 목숨도 끊어질 줄 알아라"로 주인공의 발을 꼼짝달싹 못 하게 묶어 놓는 게 흥미로운 설정이다.

Posted by 사무엘

2019/03/19 08:34 2019/03/19 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1598

조선어 학회 사건 때 투옥되기도 했던 교사 겸 국어학자 정 태진 선생, 그리고 미군 장성인 조지 패튼과 월튼 워커..
이 사람들은 1940~50년대에 모두 교통사고로 세상을 떠났다는 공통점이 있다.
그 당시의 비포장 도로 사정을 감안하면 차가 절대로 그렇게 빨리 달릴 수 없는 상황이었으며, 저 인물들이 당한 사고는 안전 벨트를 매고 있었다면 사람이 죽을 정도의 사고는 절대 아니었다. 더구나 보행자도 아니고 차량 탑승자가 말이다.

하지만 20세기 중반에 자동차에는 안전 유리 정도나 도입되었지, 안전 벨트 비스무리한 물건은 아직 비행기 조종석을 벗어나지 못한 단계였다. 사고가 나면 탑승자는 관성 때문에 앞으로 튕겨나가서 좌석이나 유리창과 부딪치고, 최악의 경우 밖으로 날아가서 땅바닥에 나뒹굴었다.
그러니 장성급 VIP라 해도 교통사고가 났다 하면 얄짤없이 사망 아니면 중상을 면할 수 없었다. 하물며 정 태진의 경우는 아예 군용 트럭 짐받이에 아슬아슬하게 낑겨 타고 있다가 차가 전복됐으니 원..

기술의 발달 덕분에 자동차가 예전보다 얼마나 더 안전해졌는지를 실감한다. 안전 유리조차도 없던 자동차 초창기엔, 믿어지지 않지만 겨우 시속 30~40km로 달리다가 정면 충돌이 나도 사람이 죽을 수 있었다. 8기통 5000cc로 자동차 최대 출력이 30~40마력이던 100년 전쯤 시절 얘기다.
한편으로, 쿨하게 벨트 따위 없이 빠르기도 엄청 빠른 고속철이라는 교통수단에 경이로움을 느낀다.

사람이 교통수단의 곁에서 얼쩡거리다가 죽거나 다쳤다고 하면, 보통은 저렇게 달리는 자동차에 치이는 교통사고를 떠올린다.
무겁고 딱딱한 쇳덩이인 자동차와 퍽 부딪치고 나서 딱딱한 아스팔트· 시멘트 바닥으로 내던져지면 사람은 신체 곳곳이 부러지고 꺾이고 긁힌다. 하지만 아예 신체가 차 밑으로 들어가서 바퀴에 깔리는 것보다야, 차라리 튕겨 나가서 내던져지고 구르는 걸로 끝나는 게 나을 것이다.

일반적인 자동차에 치인 결과가 이러한데, 하물며 훨씬 더 무거운 열차에 치이거나 깔리면 시체가 온전히 남지도 못할 것이다. 지하철 선로 투신은 이루 형언하기 어려운 끔찍한 자살 방법이다.
단, 철도에는 굳이 달리는 차량에 치이지 않고도 끔살 당하는 다른 고유한 방법이 있다. 바로 전차선에 감전되는 것이다..;;

열차가 너무 빠르게 지나가면 사람이 근처에만 있어도 빨려 들어가서 죽거나 다치듯, 고압 전차선은 굳이 완전히 접촉하지 않고 십수 cm 남짓 근처에만 도달해도 감전될 수 있다.
또한, 똑같이 감전사해도 그냥 말단 부위에 화상만 남기고 비교적 곱게 죽는 경우가 있는가 하면, 열을 너무 많이 받아서 온몸이 순식간에 새까만 숯덩이 가루가 되기도 한다.

전압과 전류, 신체 상태가 어떻게 맞물리면 저렇게 될 수 있는지 모르겠다.
우리나라 전철이야 다들 가공전차선(공중) 방식이니, 감전 사고가 나는 건 사람이 일부러 열차의 지붕으로 올라가는 뻘짓을 했을 때밖에 없을 것이다. 하지만 경전철은 제3궤조 집전식이니 그 바닥은 어찌 될지 알 수 없다. 서양에는 touch the third rail (왕창 위험한 짓을 함)이라는 관용구까지 있다.

한편, 비행기와 선박은 자동차처럼 곱게 바퀴만 굴리는 게 아니라, 주변의 유체(공기 또는 물)를 빨아들이고 뒤로 내뿜는 추진 장치가 밖에 돌출돼 있다. 그렇기 때문에 그렇기 때문에 주행 여부와 관계없이 시동이 걸려 있는 것만으로도 곁에 있으면 더욱 위험하다.

선박의 경우, 주변에서 작업하던 인부가 스크루에 빨려들어가 끔살 당할 수 있다. 이런 사고는 범선이나 심지어 증기 외륜선 시절에도 걱정할 필요가 없던 부류일 것이다.
헬리콥터의 경우, 커다란 메인 로터는 머리 위 높은 곳에서 돌아가니까 괜찮지만, 테일 로터에 사람이 부딪히는 사고가 날 수 있다. 선풍기 날개에 손가락을 다치는 것 정도와는 비교가 안 되는 심각한 부상을 야기한다.

그리고 이 바닥의 갑은 제트기의 팬에 빨려들어가는 것이다.
수십~100수십 톤에 달하는 대형 비행기를 그냥 밀어내는 정도가 아니라 공중에 띄우기까지 해야 하는데.. 엔진의 힘이 얼마나 돼야 하며, 단위 시간 동안 빨아들이고 팽창시켜 내뿜는 공기의 양이 얼마나 될지는 상상조차 하기 어렵다. 단순히 새 정도가 아니라 사람도 당연히 빨려들어갈 수 있다.

지난 2006년 1월 16일에는 미국 엘 파소 공항에서 항공 정비사가 보잉 737 국내선(컨티넨탈) 여객기의 팬에 빨려들어가는 사고가 실제로 난 적이 있다고 한다. 그리고 합성이나 주작이 아닌지 신빙성이 약간 의심은 된다만, 사고 현장의 사진도 검색해 보면 나온다. 해당 엔진 전체는 말할 것도 없고 주변 바닥까지 온통.. 사람은 뼈도 옷도 유품도 없고 형체가 전혀 없이, 그냥 시뻘건 피와 살점으로 범벅이 됐더라..;;

FPS 게임에 나오는 gib(피떡)라는 것의 더 잔혹한 실사판을 볼 수 있었다. 그냥 사람이 사지 잘리고 바닥에 피 흘리며 죽어 있는 어지간한 전쟁터나 교통사고 현장과는 차원이 다르다.
이렇게 사고가 난 뒤의 모습 말고, 심지어 옆 비행기에서 그 사람이 실제로 쏙 빨려들어가서 죽는 모습을 촬영했다는 동영상까지도 굴러다니는 게 있는데, 이건 합성 주작인 것 같다. 하지만 사건 자체는 실제로 일어난 게 맞다.

요약하자면..

  • 육상 교통수단은 그 특성상 움직이는 차체에 사람이 치이거나 깔리는 교통사고가 날 수 있다. 차와 차끼리도 서로 부딪칠 수 있다.
  • 그에 덧붙여서 철도는 전차선이 존재하는 유일한 교통수단이다 보니 차체의 운행 여부와 관계 없이, 아니 오히려 반대로 정지해 있을 때 감전 사고가 날 수 있다.
  • 다음으로, 땅 위에서 바퀴를 굴리는 형태가 아닌 교통수단들은(비행기, 선박) 추진 프로펠러에 빨려들어가는 사고가 날 수 있다.

Posted by 사무엘

2019/03/17 08:32 2019/03/17 08:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1597

* 2014년에 썼던 글을 보완하여 다시 올린다.

옛날에 도스 시절에는 일명 '외부 명령'이라 하여 별도의 프로그램 형태로 존재하는 명령들이 있었다. format.com, diskcopy.exe 같은 것들.
이것들은 자기가 소속된 도스 버전을 가려서 동작했다. 가령, MS 도스 5.0이 설치된 컴퓨터에다 도스 6.x에 존재하는 새로운 유틸리티를 복사해 와서 실행하면, 실행에 필요한 파일들이 다 있다 하더라도 '도스 버전이 다릅니다'라는 에러 메시지와 함께 프로그램이 그냥 실행되지 않았다. 이것은 운영체제의 버전을 가려 가며 실행하는 프로그램을 본인이 난생 처음으로 접한 사례였다.

Windows에도 자신의 버전을 알려 주는 API가 응당 존재한다. 하지만 이건 지금 구동 중인 운영체제가 무엇인지를 알려 주는 편의 기능을 구현할 때나 사용할 만한 기능이다. 일반적인 프로그램이라면 About 대화상자 같은 데서 말이다.
만약 프로그램이 운영체제의 버전을 가려 가며 실행해야 한다면, 단순히 운영체제의 버전을 갖고 판단하는 건 썩 좋은 방법이 아니다. 내가 실제로 사용하고자 하는 기능을 요청해 보고(CoCreateInstance, LoadLibrary/GetProcAddress 등), 그 요청의 성공 여부에 따라 실행 여부를 결정하는 게 바람직하다.

뭐, 지금은 아무 의미가 없는 예가 돼 버렸다만,
가령 내 프로그램이 유니코드 API를 사용하기 때문에 Windows 9x에서는 실행을 거부해야 한다고 치자.
그렇다면 CreateWindowExW건 RegisterClassW건 유니코드 API를 실제로 호출해 본 뒤, 그게 실패하고 GetLastError()==ERROR_CALL_NOT_IMPLEMENTED가 돌아올 때 실행을 거부하면 된다. 운영체제의 외형보다는 그 운영체제의 실제 실행 결과를 보고 판단하는 게 낫다는 게 바로 이런 의미이다.

그런 것도 다 필요 없고 운영체제의 버전 숫자를 정말로 정확하게 알아 와야 한다면,
그 경우를 위해 태초에 GetVersion()이라는 간단한 함수가 있었다. 얘는 버전과 관련된 여러가지 정보들을 비트 자릿수별로 묶은 32비트 정수를 되돌렸다.

그 정보의 의미를 C언어의 비트필드 구조체로 나타내 보면 대충 다음과 같다. 주석으로 표시된 숫자는 윈도 7 기준으로 반환되는 값들이다.
(최신 Windows 10 기준의 반환값을 소개하지 않은 이유는 후술하도록 하겠다)

union WINVERSION {
    DWORD dwValue;
    struct {
        UINT nMajorVer: 8; //6
        UINT nMinorVer: 8; //1
        UINT nBuildNumber: 15; //7601
        UINT bWin9xOrWin32s: 1; //0
    };
};

WINVERSION os;
os.dwValue = ::GetVersion();

이 함수는 아무 매개변수도 필요하지 않으며, 리턴값도 DWORD 달랑 하나이니 미치도록 가볍고 사용하기 편하다. Windows 9x와 NT 계열이 공존하던 옛날에, 지금 운영체제가 (1) NT 계열인지를 알고 싶다면 GetVersion()&0x80000000 (최상위 비트)만 하면 OK였다.
그 뒤, NT 3.x인지 4.0인지, 9x 계열의 경우 95인지 98인지 ME인지 같은 건 (2) major와 minor 번호를 보고 판별하면 됐다. (3) 빌드 번호는... 딱히 막 중요한 정보는 아닌 듯하다.

그러나 이 함수는 문제점과 한계도 보였다. 한눈에 봐도 각 비트로부터 의미 있는 정보를 추출하는 게 매우 지저분하고 번거로웠다. HIWORD, LOBYTE 삽질이 싫다면, 저런 비트필드 구조체는 프로그래머가 재량껏 알아서 만들어야 했으며, 응용 프로그램이 이 정보를 잘못 취급하는 경우도 많았다.

비교할 필요가 없는 필드까지 다 비교를 해 버리는 바람에, Windows 95 이상에서 모두 동작할 수 있는 프로그램이 Windows 95에서“만” 동작하게 고정돼 버리기도 했다. 혹은 Windows NT 4.0이 NT 3.51보다 낮은 버전으로 취급되는 촌극도 벌어졌다. (리틀 엔디언 기준으로 저 구조체를 보면, minor 버전이 major 버전보다 더 높은 자릿수에 놓여 있음)

더구나 운영체제의 정체성을 나타내는 정보는 단순히 버전 번호와 빌드 번호 이상으로 더욱 복잡해져 왔다. NT 계열의 경우 당장 서비스 팩이 있고, 이게 무슨 에디션인지도(홈? 서버? 워크스테이션? 등) 알 필요가 있는데 단순히 숫자 하나만 달랑 되돌리는 함수로는 그런 걸 알려 줄 수가 없었다.

이런 문제를 해결하기 위해 Windows 95 내지 NT 3.5에서는 OSVERSIONINFO라는 구조체를 인자로 받는 GetVersionEx라는 함수가 추가되었다. major, minor 버전 번호와 빌드 번호, 운영체제 계열이 모두 독립된 구조체 멤버로 독립하였으며, (4) 서비스 팩 내역도 완전한 문자열 형태로 되돌려 주니 버전 정보를 다루기가 편해졌다.

이 구조체는 맨 앞에 자신의 크기를 써 주게 돼 있으며, 덕분에 추후 확장이 가능한 형태이다.
Windows 2000부터는 OSVERSIONINFOEX 구조체가 추가됐다. 확장된 구조체는 서비스 팩의 번호조차도 major와 minor 꼴로 받을 수 있으며, (5) 같은 NT 계열 중에서도 클라이언트 라인과 서버 라인을 구분할 수 있다(wProductType==VER_NT_WORKSTATION / VER_NT_SERVER). Windows XP와 Server 2003은 버전 번호가 5.1과 5.2로 서로 달랐지만, 후대 버전부터는 버전 번호는 동일하고 이걸로 구분을 해야 한다. (Vista / Server 2008, 10 / Server 2016 같은..)

그리고 클라이언트 라인은 XP 이래로 오늘날의 10까지 (6) home과 pro 에디션 구분이 거의 관행이 돼 있는데.. 이건 wSuiteMask 멤버의 비트 플래그 VER_SUITE_PERSONAL (0x200)의 존재 여부로 판별 가능하다. 저 플래그가 존재하는 게 home 에디션이다.
VER_SUITE_* 다른 플래그들 중에는 Windows XP의 embedded 에디션, enterprise 에디션 같은 걸 나타내는 것들도 있으니 참고하면 된다.

요컨대 9x/NT 이후로도 클라이언트/서버, home/pro 같은 복잡한 구분이 계속 이어지는 것을 알 수 있다. 그래도 GetVersionEx 한 방이면 모든 정보를 얻을 수 있다.

이걸로 모든 이야기가 끝이 났으면 좋겠지만.. 아이고, 끝이 아니다. GetVersionEx 함수는 2010년대 이후로 마소의 정책상 사용이 더 권장되지 않는 deprecate 판정을 받고, 시간이 정지해 버렸다.
이 함수는 아무런 단서가 없는 환경에서는 Windows 8, 즉 버전 6.2보다 더 높은 값을 되돌리지 않는 샌드박스가 되었다. 실제로는 이 컴퓨터에 Windows 8.1이나 10이 돌아가고 있더라도 말이다. 이와 관련된 더 자세한 정보를 원한다면 다음 URL을 참고하시기 바란다.

이제 이 함수는 응용 프로그램에게 그 응용 프로그램보다 나중에 출시된 운영체제에 대한 정보는 주지 않기로 작정한 듯하다. GetVersionEx가 샌드박스 없이 실제 자기 버전을 되돌리는 조건은 다음과 같다.

  • 응용 프로그램의 manifest XML에(compatibility-application-supportedOS) 그 운영체제의 GUID가 등록되어 있다.
  • 혹은 응용 프로그램의 PE 헤더에 OS의 최소 요구 버전이 최신 운영체제의 버전으로 맞춰져 있다. Windows 8.1의 경우 6.3, Windows 10이라면 10.0이 되겠다.

운영체제와 함께 제공되는 메모장 같은 기본 프로그램들은 후자의 조치를 취한 상태이다. 이렇게 빌드된 프로그램에서는 GetVersionEx가 해당 버전을 정확하게 되돌린다. 하지만 이런 프로그램은 이전 버전 운영체제에서는 아예 전혀 동작하지 않으므로, 3rd-party 응용 프로그램이라면 이런 방법을 쓰기 곤란하다. 그러니 매니페스트 등록을 해야 한다.

물론 마소에서 2015년의 Windows 10부터는 기존 버전 번호 자체를 10.0으로 동결시켜 버리고 더 바꾸지 않기로 작정했다. 그러니 버전 번호 변경으로 인해 GUID를 또 등록하는 식의 혼란은 앞으로 더 없을 것이다.

운영체제의 버전의 절대값을 되돌리는 GetVersionEx 대신 마소에서 사용을 권장하는 함수는... 지금 운영체제의 버전이 응용 프로그램이 제시하는 버전보다 상대적으로 높은지 안 높은지 여부만을 되돌리는 VerifyVersionInfo 함수이다. 그리고 이걸 기반으로 IsWindows10OrGreater 같은 helper 함수들도 만들어져 있다. (VersionHelpers.h)

하지만 이 함수들도 내부적으로 GetVersionEx의 결과값을 기반으로 비교를 하는 것이기 때문에 앞서 언급한 샌드박스의 제약을 받는 건 마찬가지이다.

샌드박스 없이 운영체제의 정확한 버전을 얻어 오는 함수는 크게 두 군데에 있다.
먼저, 의외로 네트워크 API이다. 그렇다고 소켓 API 같은 건 아니고, Windows에서 독자적으로 제공하는 함수 중에 내 로컬 컴퓨터를 포함하여 원격 컴퓨터에 설치된 운영체제의 버전을 얻어 오는 함수가 있다. 대략 다음과 같이 코드를 작성하면 된다.

#include <LM.h>
#pragma comment(lib, "netapi32")

WKSTA_INFO_100 *p;
::NetWkstaGetInfo(NULL, 100, (LPBYTE *)&p);
printf("%d, %d\n", p->wki100_ver_major, p->wki100_ver_minor); //10, 0
::NetApiBufferFree(p);

저기 100은 수효를 나타내는 게 아니며 각각의 숫자들이 별개의 의미를 지님에도 불구하고, 상수 명칭이 존재하지 않아서 그냥 생으로 100을 넘겨 줘야 한다.
운영체제 버전 하나 좀 얻자고 웬 생뚱맞은 분야의 API를 써야 하는 것도 삽질스럽지만.. 저 함수를 통해서는 그냥 major와 minor 버전 번호만 얻을 수 있다. 서비스 팩이나 빌드 번호 같은 세부 정보는 얻을 수 없다.

저거 말고 다른 대안으로는.. ntdll.dll에 있는 native API인 RtlGetVersion을 써도 된다.
OSVERSIONINFO(EX)의 포인터를 받아들이고 정수값을 리턴하므로 prototype이 기존 GetVersionEx와 거의 동일하다.
단, native API 버전은 성공한 경우의 리턴값이 0이다. 리턴 타입이 BOOL이 아닌 셈이다.

얘는 Windows 8.1 내지 10 같은 요즘 운영체제에서는 잘 동작하는데, 과거의 Windows 2000에서는 GetVersionEx와 달리 서비스 팩 정보를 되돌리지 않았던 것으로 기억한다. 구형 OS에서는 오히려 기존 함수를 쓰는 게 더 낫다. 거 참..;;
Windows가 지난 20년 동안 운영체제의 버전과 제품 종류를 얻는 그 단순한 절차만 해도 얼마나 복잡하고 지저분해져 왔는지를 확인할 수 있다. 관련 여담을 몇 가지 더 남기는 것으로 글을 맺고자 한다.

  • OSVERSIONINFOEX는 C++ 상속 문법 같은 걸 이용해서 선언된 게 아닌 관계로, OSVERSIONINFO와는 언어 차원에서 아무런 연결 고리가 없다. GetVersionEx에다가 전달할 때는 OSVERSIONINFO*로 reinterpret_cast를 해 줘야 된다.
  • 과거 Windows XP에는 media center 에디션 내지 태블릿 PC 에디션 같은 바리에이션이 있었는데.. 이거 여부를 얻는 건 GetVersionEx가 아니라 GetSystemMetric라는 다소 생뚱맞은 함수에 있었다. SM_MEDIACENTER, SM_TABLETPC처럼 말이다 .
  • 끝으로, Windows 10부터는 (7) 릴리스 연-월을 나타내는 4자리 숫자가 사실상 버전 번호가 됐으니 이걸 표시해 줘야 할 것이다. 그런데 이건.. 본인이 아는 방법은 그냥 무식한 레지스트리 조회가 유일하며, 공식적인 API가 따로 있지 않다.;;;

Posted by 사무엘

2019/03/14 08:36 2019/03/14 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1596

영화 항거 외

1. 영화

올해는 3· 1 운동 발발 100주년인 해답게 이 타이밍에 맞춰 유 관순을 소재로 한 영화가 적절하게 개봉했다. 말모이에 이어 또 일제 시대 배경 영화이긴 하다만, 이것도 명분이 충분하기 때문에 본인은 관람을 하고 왔다.

사용자 삽입 이미지

이 영화는 안 그래도 3· 1 운동 자체가 아니라 유 관순의 투옥 이후 시점을 주로 다루고 있다. 그렇기 때문에 서대문 형무소 역사관을 실제로 구경하고 나면 영화의 공간 배경을 이해하는 데 매우 큰 도움이 될 거라는 점을 가장 먼저 언급하고자 한다. 그러니 제대로 감상하고 싶은 분은 사전에 저기부터 가 보시기 바란다.

본인은 9년 전, 이 블로그가 처음 생겼던 2010년 초에 가 봤다. 일반 감방뿐만 아니라 유 관순이 말년에 실제로 격리 수용됐던 지하 독방까지 직접 볼 수 있다.

  • 유 관순은 서대문(경성) 형무소에서 옥사
  • 강 우규 의사는 서대문 형무소에서 사형 (유 관순이 투옥된 시기에 서울 역 광장에서 사이토 총독의 암살을 시도했던 노인)
  • 훗날 조선어 학회 사건 연루자 두 분은 함흥 형무소에서 옥사
  • 주 기철 목사는 평양 형무소에서 옥사

지역이 이렇게 대응한다.

그리고 이 영화는 이례적으로 흔치 않은 흑백 영화라는 것도 미리 염두에 두시기 바란다. 킬 빌처럼 일부 주요 장면만 흑백인 것도 아니다(녹엽정 전투..).
현실의 형무소 장면은 죄다 흑백이고, 일부 과거 회상 장면이 컬러이다. 보통은 그 반대인 것 같은데 이례적이다.

비슷한 시기에 또 항일 운동을 소재로 한 "자전차왕 엄 복동"도 개봉했다.
하지만 스포츠로 한국이 일본을 이긴 얘기를 극화하고 싶으면 차라리 손 기정 내지 홍 덕영 골키퍼 (해방 이후 월드컵 예선 한일전!)같은 사람이나 재조명할 것이지, 참신한 소재를 찾는답시고 자전거 도둑질도 전문이었던 사람을 소재로 삼은 게 논란이 됐다. 그 사람이 하다못해 친일파· 일본놈들만 상대로 의적(?)질을 한 것도 아니다.

소재부터가 삐걱거리는데 영화 자체도 그리 잘 만든 게 아니었고, 더 고퀄인 "항거"에게 팀킬 당하니 엄 복동 얘기는 예전의 "대장 김 창수"의 말로를 가면서 대차게 망했다. 뭐, 자전거 도벽은 아예 친일 변절이나 강도살인보다는 죄질이 상대적으로 가볍긴 하다만, 저 양반이 훔친 액수도 단순 생계형으로 실드 칠 수 있는 수준이 아니었다.

2. 3· 1 운동

그럼, 영화를 벗어나 3· 1운동 자체에 대해서도 얘기를 좀 해 보자.
냉정하게 생각해 보면, 솔직히 그까짓 만세 부른다고 해서 일제가 "아 그러셨어요~? ^^"물러가고 독립이 찾아올 리는 만무하다. 더구나 3· 1 운동은 주요 배경, 명분, 동기에 핀트가 근본적으로 안 맞는 게 있었다.

(1) 1910년대 일제 무단 통치에 대한 반감과 민생고(흉년, 물가 상승)는 그렇다 치지만 (2) 고종 독살 의혹은.. 글쎄, 고종이 무슨 세종대왕 급으로 추모 받을 성군이었는지는 잘 모르겠다. 결정적으로 어디서 주워 들었는지 모르겠지만, (3) 민족 자결주의는 1차 대전 승전국인 일본의 식민지인 조선에 적용되는 내용이 아니었다.

유 관순도 그 기백이 정말 대단하긴 하지만, 너무 무모하게 매를 벌지 말고, 1년 반 정도만 빵에서 살다가 나와서 공부 더 하고 더 오래 살았으면 더 큰 일을 할 수 있지 않았을까 아쉬움이 남는다.
그래도 만세 시위 때 자기 부모를 왜놈들한테 잃고 완전히 꼭지가 돌아 버렸을 테니, 그 뒤로 왜놈을 가족과 민족의 철천지 원수로 여기고 저놈들한테 절대로 고개를 숙이지 않겠다고 고집 부린 그 악바리와 깡과 근성은 충분히 이해가 된다.

영화에서 유 관순의 감방 동료로 나오는 권 애라와 김 향화(배우 이름이 아닌 배역 이름)는 실존 인물이다. 특히 김 향화는 수원에서 활동한 기생이다. 이 시절에 기생은 우리가 흔히 생각하는 야시꾸리한 직업 종사자가 아니라, 요즘으로 치면 스튜어디스 급은 되는.. 단순 서비스 접대 이상으로 지와 미와 예능을 갖춘 사람이었다.

2차 세계 대전 태평양 전선에서는 미국이 일본놈들한테 학을 떼면서 뭐 저런 상또라이들이 있나(반자이 어택, 카미카제..) 경악했었다. 하지만 더 옛날에는 일본도 조센징들을 보곤 뭐 저렇게 지독하게 말을 안 듣는 독종 또라이들이 있나 멘탈 대미지(반자이 트라우마..)를 입고 충격을 먹었던 모양이다. 그래서 1920년대에는 문화 통치 유화책이 나오게 되었다.

흔히 호남 지역을 비하하면서 저기가 3· 1 운동 참가자 내지 투옥자가 제일 적었다는 통계를 제시하는 경우가 있다. 하지만 거기는 3· 1 운동 이전에 1890년대의 동학 운동과 1900년대의 의병 때문에 항일 인사들이 몽땅 토벌되고 씨가 마른 상태이기도 했다는 것을 감안할 필요가 있다. 통계 자체에 대한 조작과 왜곡 가능성은 고려하지 않았을 때 말이다.

3. 혹시나 했지만 역시나..

이 영화와 배경 내용에 대해서 말할 거리는 이 외에도 더 있지만, 일단 기독교 신앙이 의외로 꽤 자주 언급되는 게 인상적이고 좋았다. 유 관순은 실제로 교인이기도 했으니까..
"행함이 없는 믿음은 죽은 믿음", "시험을 면하게는 하지 않아도 이길 힘을..", "기도하는 수밖에 없음", "예수님은 바보여서 저렇게 십자가에 매달려 죽으신 줄 아냐" 무려 이 정도 분량이 대사에 포함돼 있다.

신앙 쪽으로 왜곡 없는 중립· 긍정적인 묘사 덕분에 본인은 처음엔 영화에 대한 호감도가 슬슬 올라갔다. 그러나 결말부를 보고는 기분이 완전히 잡쳐 버렸다.
정작 유 관순이 최후를 맞이하는 장면은 너무 얼렁뚱땅 대충 자막으로 때워 버리고는, 그 뒤에 어설프게 또 이상한 친일파 드립과 반일 프레임 엮기.. "혹시나 했더니 역시나였군.. ㅉㅉ" 싶었다.

정 춘영인지 누군지 출신과 생몰 시기도 모르는 웬 듣보잡 조선인 헌병이 있어서 유 관순을 내내 괴롭혔다고 한다.
이놈은 친일 부역 행적이 탄로나서 해방 후 반민특위에 의해 기소되었으나, 그 이름도 찬란한 모 할배의 특별 배려(!)로 사면되고 제대로 처벌받지 않았다. 이걸 말이라고 자막을 떡 걸어 놨으니 나도 꼭지가 돌아 버리겠다. 하지만 실상은 유 관순이 교인이었던 것만큼이나 할배도 교파까지 같은(감리교) 교인이었으며, 유 관순이 독립 운동가인 것만큼이나 반민특위를 불가피하게 해체한 배후 인물(애산 이 인)도 똑같이 항일 독립 운동가였다.

어디 '정춘영 유관순 고문'이라고 검색을 해 보아라. 정확한 기록 같은 건 없고, 같이 걸려 나오는 건 유 관순이 무슨 미꾸라지 고문을 당하고 코가 잘리고 머리 가죽이 벗겨졌다는 얘기, 아니 도시전설 괴담밖에 없다.
그렇게도 친일 부역자 조선인 헌병을 개새끼로 만들고 싶으면 영화에다가도 미꾸라지 고문 씬을 넣지 그랬냐? 일본 제국주의 악마들이 겨우 손톱 뽑기 내지 캐비닛 안에 선 채로 며칠 감금 정도만 했을 것 같은가?

그리고 크레딧 롤이 올라가는 동안이나 작품 결말부에서 주인공이 죽기 전에.. 그 이름도 유명한 "내 손톱이 빠져나가고 내 귀와 코가 잘리고 내 다리가 부러져도 그 고통은 이길 수 있사오나, 나라를 잃은 그 고통만은 견딜 수가 없습니다" 이 출처불명의 비장한 유언도 좀 나왔어야지? 안 그런가?

삼일 운동 그 자체가 조국의 독립을 가져오지는 못했지만 이 항거는 외국에까지 소개되어서 조선의 독립 의지를 알리는 데 도움이 됐다는둥, 그 정신이 지금 우리나라 헌법에도 명시돼 있다는둥, 유 관순 말고 다른 여학생· 기생의 의거도 많이 벌어졌다는둥.. 클로징 멘트로 다른 좋은 말을 얼마든지 골라 넣을 수 있었을 텐데.. 마무리를 의도적으로 저 따구로 지은 저의가 뭐냐!? 매우 유감스럽고 씁쓸했다.

4. 3· 1 운동 때 투옥된 뒤에도 천수를 누린 다른 여성

옛날에 우리나라엔 '추계 최 은희(1904-1984)'라고 무려 1920년대에 조선일보에 입사해서 여성으로서는 거의 국내 최초로 기자라는 직업에 종사한 분이 있었다.

사용자 삽입 이미지

보다시피 유 관순보다 약간 어릴 뿐 거의 같은 연배이다. 3· 1 운동에 가담하다가 붙잡혀서 세 주 남짓 옥고를 치르면서 험한 꼴을 봤지만, 그 뒤엔 풀려나서 학교를 무사히 졸업하고 기자도 됐다. 덕분에 방송을 타고 비행기도 타 보는 등, 일제 시대 조선 여자로서는 상상하기 힘든 진귀한 경험을 많이 할 수 있었다.
(참고로 3· 1 운동 당시의 소속이 유 관순은 이화학당, 저분은 경성여고보)

이분의 호인 '추계'는 추계 예술 대학교의 설립자하고는 관계 없다. 그 추계는 황 신덕(1898-1983)이라는 다른 사람의 아호인데, 저분 역시 최 은희와 동시대를 살았던 신여성이며, 3· 1 운동에 가담했고 기자 커리어까지 있는 것이 서로 굉장히 비슷하긴 하다. 아마 서로 아는 사이였지 않을까?

호 다음으로 '최 은희'라는 이름은 국내에서는 영화 배우의 이름으로 훨씬 더 유명하다. 이런 이유로 인해 두 단어를 합친 '추계 최 은희'라는 사람은 인지도가 낮으며, 언론 쪽 종사자가 아니면 잘 모를 것이다. 하지만 언론인 출신 최 은희가 영화 배우 최 은희보다 훨씬 더 무시무시하고 위대한 인물이다. 추계 최 은희는 대학을 설립한 게 아니라 자기 이름을 딴 '최은희 여기자상'이라는 것을 제정했다.

저분은 결혼 후에는 기자 커리어가 중단되었다. 허나, 1남 2녀를 낳아서 세 명 모두 박사까지 공부 시키고 유학도 보내고 전부 대학 교수로 키웠다.;; 그 중 막내딸은 이화여대 국문과 교수를 역임한 이 혜순으로, 2000년대 중반에 정년 퇴임했다.

본인은 먼 옛날에 "유쾌한 구두쇠들"(1994)이라는 책을 통해 저런 사람이 있다는 걸 알게 됐다. 공 병우 박사, 남 기심 교수, 이 혜순 교수(두 교수 다 국문과이구나.. 세부 전공은 다르지만) 등 17명의 유명인사가 공동 집필한 책인데, 다들 비범하고 사회적으로 성공하고 돈도 엄청 많이 번 사람들이다.

그런 사람들이 일상생활은 서민들 이상으로 정말 둘도 없이 검소하게 효율적으로 하면서, 옳은 일 큰 일에 아낌없이 돈을 쾌척한 얘기들이 실려 있다. 지금은 시대에 맞게 저 책 내용이 웹툰으로 각색되어서 연재되면 어떨까 싶다.
다만, 저자 중에 지금은 완전히 몰락한 방송인 서 세원 씨까지 포함돼 있는 게 참 묘하다.

이 혜순 교수는 저 책이 나온 지 10년이 넘게 지나고 나이 70을 바라보는 명예교수가 된 뒤에도 개인적으로 가장 존경하는 인물은 변함없이 자기 어머니라고 회고했다. (☞ 관련 링크)
뭐, 인생 한번 짧고 굵게 살다 가는 것도 나쁘지 않지만, 유 관순 같은 인물이 형무소를 살아서 출소해서 공부 더 하고 후세도 남겼으면 인생이 최 은희와 비슷해지지 않았을까 싶은 생각이 문득 들었다.

Posted by 사무엘

2019/03/11 08:36 2019/03/11 08:36
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1595

날개셋 한글 입력기가 올해 최초의 새 버전이 나왔다. 우연히도 3· 1 운동 100주년과 비슷한 타이밍에 말이다. 올해 초까지만 해도 이제 날개셋 한글 입력기는 당분간 더 만들 게 없을 거라고 예상했었지만 결국은 9.7까지 또 잘만 올라가게 됐다. 마치 석유가 이제는 고갈된 것 같아도 자꾸 더 채굴되는 것처럼 말이다.

물론 9.5 이후로 완전히 새로운 기능의 추가나 대규모 개편 같은 작업은 없다. 다만, 지금 체계 하에서 이미 있는 기능들의 완성도를 높이는 작업 아이템은 여전히 종종 발견되고 떠오르고 있고, 그게 버전 번호를 올려 주고 있다. 그래도 날개셋 10.0이 내 학위논문보다 먼저 나오는 일은 없었으면 좋겠다. ㅠㅠ

이번 9.7에서는 이전 글에서 언급했던 것처럼 마우스 휠의 인식 방식을 개선했으며, 글꼴 본뜨기 스크립트에 한중일 확장 한자 C/D도 추가했다. 그것 말고 프로그램의 완성도를 강화하는 변화로는 다음과 같은 것들이 있다.

1. 수정 가능한 공용 파일의 접근성 강화

날개셋 한글 입력기 프로그램이 사용하는 데이터 파일 중에는 모든 사용자가 공유하면서 사용자가 내용을 수정할 수도 있는 텍스트 형태의 파일이 있다.

  • 편집기가 사용하는 상용구 리스트(qidiom.txt)
  • 글꼴 본뜨기 절차 리스트(fontextr.txt) -- 16픽셀용과 24픽셀용이 서로 별개
  • 날개셋 제어판이 사용하는 custom 내정값 XML (scheme.xml) -- 각 언어별로 서로 별개

그런데 문제는.. 이 파일들은 여느 데이터 파일들과 마찬가지로, 관리자 권한이 없이는 내용을 변경할 수 없는 형태로 설치된다는 것이다.
본인은 이 파일들을 읽기/쓰기 겸용을 의도했지만 실제로 사용자들은 제대로 변경해 가며 활용을 할 수 없었다.

고민 끝에 이제 이렇게 조치를 취했다.
이 파일들은 처음에는 .txt.$라고 확장자 뒤에 $가 추가된 형태로 설치된다.
그리고 날개셋 프로그램에서 이 파일이 필요할 때 동일 명칭의 .txt와 .txt.$ 파일을 모두 살펴보고, .txt가 없거나 .txt.$보다 날짜가 과거이면 .txt.$를 .txt로 덮어쓰기 복사를 한다. 그래서 새로 생성된 .txt 파일을 사용한다.

ProgramData 디렉터리는 Program Files 같은 읽기 전용 디렉터리가 아니며, 응용 프로그램이 파일을 새로 생성하는 것은 가능하기 때문이다. 그리고 그렇게 일반 권한으로 동적으로 생성된 파일은 사용자가 얼마든지 고칠 수 있다.
이렇게 하면 사용자가 실수로 .txt 파일을 지워 버리더라도 .txt.$로부터 원래 파일이 자동으로 복원되는 효과도 얻을 수 있다. 그러니 더욱 좋으며, 이게 최선의 문제 해결 방식이라고 생각된다.

2. 입력 패드에 /S 옵션이 제대로 동작하지 않는 문제 해결

날개셋 입력 패드의 경우, 입력 도구를 띄웠다가 모두 닫아서 입력 도구가 하나도 없게 됐을 때 프로그램도 자동으로 종료하는 /S 옵션이 있다. 입력 패드를 특정 입력 도구만 띄우는 목적으로 간단히 활용할 수 있게 하기 위해서 이런 옵션을 제공한다.

그런데 이 옵션이 지금까지 다음과 같이 제대로 동작하지 않는 걸 뒤늦게 발견했다. 그래서 고쳤다.

  • 각 입력 도구의 자체 UI(X 버튼 또는 우클릭 메뉴) 명령을 통해서 닫아서 모두 없어진 것만을 감지했다. 입력 패드 프로그램의 트레이 우클릭 메뉴를 통해서 입력 도구를 모두 닫았을 때는 프로그램이 자동 종료되지 않았다.
  • 그리고 개수를 체크하는 코드 자체도 언제부턴가 프로그램의 소스 코드 구조가 바뀌었을 때 같이 바뀌었어야 하는 부분이 바뀌지 않았다. 그래서 1개에서 0으로 줄었는지를 확인하는 게 아니라 2개에서 1개가 됐을 때를 체크하게 잘못 동작하고 있었다.

3. 에디팅 엔진의 미묘한 버그 수정

날개셋 한글 입력기에서 완전 기초 기본 기능에 속하는 편집기의 에디팅 엔진 쪽에 아직까지도 버그가 발견되고 고칠 게 있다는 게 본인 역시 실감이 안 가지만.. 이번에 그런 게 있었다. 물론 평소에 대다수 사용자에게는 거의 티가 안 나기 때문에 10년이 넘는 세월 동안 본인에게도 발견되지 않을 수 있었다.

날개셋 편집기의 장점 중 하나는 운영체제의 TSF 인터페이스를 온전히 지원한다는 것이다. 그래서 IME들이 자기 조합 문자열뿐만 아니라 주변 텍스트 내용에 모두 접근해서 읽고 쓸 수 있다.
그러기 위해서 날개셋 편집기 역시 운영체제의 요청이 있으면 편집 중인 텍스트를 되돌리고 수정하고, 현재 블록이 잡힌 영역을 알려 준다. 또한, 텍스트가 자체적으로 수정되었다면 어디가 얼마만치 수정되었는지를 운영체제에다가 알려 주기도 한다.

문제가 발견된 곳은 내 프로그램에서 수정된 영역을 운영체제에다가 알려 주는 부분이다. 이걸 제때 해 주지 않으면 오동작이 발생한다는 건 오래 전부터 경험적으로 체득되어 있었다.
다만, 내 프로그램도 수정된 내역에 따라서 문단 정렬을 다시 하고 cursor의 좌표를 수정하고 그럭저럭 내부 정리를 완료한 뒤에 통지를 해야 하는데 그러지 못하고 착오가 있었다. 그래서 일부 특수한 조건이 만족되는 상황에서는 틀린 좌표를 알려 줬다.

운영체제가 수정 영역 정보를 어떤 용도로 참고하는지 알 길이 없으니 Windows XP 시절에는 저렇게 동작하고도 별 탈이 없었던 것 같다. 그런데.. 올해 초에 장만한 새 노트북에서는 곧장 문제가 발생했다.
운영체제는 틀린 정보를 토대로 역시나 내 프로그램을 상대로 잘못된 요청을 했다. 현재 텍스트에 존재하지 않는 행과 열에 접근하게 되었다. 담당 함수는 뻗지 않고 false를 되돌렸지만 내 프로그램은 그 상황에 대비가 되지 않았으며, 결국 초기화되지 않은 변수를 갖고 후속 처리를 하게 됐다.

이로 인해 확인된 이상 증세로는.. 길고 빽빽한 문서의 뒷부분을 작성할수록 속도가 느려지는 것, Ctrl+Z Undo의 수행 속도가 느려지거나 심지어 무한 루프에 빠지는 것이다. 논리적으로 꽤 치명적인 결함이고 crash가 발생해도 이상하지 않은데.. 이 버그는 의외로 많은 컴퓨터에서 외형적인 이상은 별로 일으키지 않았다. 괜히 늦게 발견된 게 아니었다.

어쨌든 문제를 발견하여 해결했으며, 이 참에 여러 군데의 텍스트가 동시에 수정되었을 때(찾기-모두 바꾸기, undo/redo, 여러 블록에 대한 지우기 및 텍스트 필터) 각 영역을 일일이 통지하는 게 아니라 영역을 모두 합성해서 한 번만 통지하도록 동작 방식을 수정하기도 했다.

4. -lock (caps, num, scroll) 글쇠에 램프 상태 유지 옵션 추가

날개셋 한글 입력기는 임의의 글쇠에다가 글자 입력이나 글자판 전환 같은 기능을 배당해서 쓸 수 있는데, 그 중에는 자체적인 켬/끔 램프가 존재하는 caps, num, scroll lock 글쇠도 포함된다.
이렇게 -lock 계열 글쇠를 customize해서 누를 경우, 날개셋에서 지정한 기능만 수행되고 램프 상태는 바뀌지 않게 하는 옵션이 추가되었다!

사용자 삽입 이미지

이 옵션은 편집기 계층의 단축글쇠, 또는 기본 입력 스키마가 제공하는 추가 인식 글쇠 배당 대화상자에서 볼 수 있다. 거기서는 각 글쇠별로 옵션을 지정할 수 있다.
그리고 추가적으로 고급 입력 스키마의 옵션에서도 지정할 수 있는데, 이건 한 곳에서만 지정하면 caps, num, scroll 글쇠를 customize할 때 모두 일률적으로 지정된다. 램프를 사용하는 글쇠가 딱 세 개밖에 없으며, 그렇게 자주 쓰일 만한 글쇠도 아니기 때문이다.

이들 램프가 켜지거나 꺼지는 건 키보드 하드웨어 차원에서 동작하는 강력한 기능이기 때문에 원래는 소프트웨어가 이래라저래라 제어할 수 없다. 램프 상태를 유지시키는 옵션은 날개셋 한글 입력기가 내부적으로 그 글쇠를 또 보내서 다시 꺼 버리는 식으로.. 좀 유치한 편법을 동원해서 동작한다. 하지만 그것 말고는 내가 알기로 IME 수준에서 할 수 있는 일이 없다. 키보드 드라이버 수준이라면 모르겠다만..

키보드에서 caps lock은 영문이 아닌 한글 입력 중엔 완전 잉여인 게 사실이다. 그러니 이걸 다른 용도로 사용할 수 없을지 고민하는 분들이 좀 계셔 왔는데.. 램프를 고정하는 옵션이 있으면 caps lock을 재활용하기 한결 수월해질 것이다.

5. 한글 표현 방식 탭.. 더 간소화

이건 실질적인 기능 추가나 버그 수정은 아니지만.. 지난 9.3 버전에서 크게 바뀌었던 한글 표현 방식 탭의 구조가 더 간소화됐다.
일반적인 환경에서는 진짜 씨크하게 현대 한글이냐 옛한글이냐 둘 중 하나만 고를 수 있게 했다.

사용자 삽입 이미지

여기서 '비표준 옵션도 표시'를 눌러야 한양 PUA니 유니코드 1.1이니 하는 레거시 옵션을 고를 수 있고, 거기서 또 '세부 옵션 표시'를 눌러야 종전의 세부 옵션들을 볼 수 있게 했다.

이번 새 버전도 많이 유익하게 사용되었으면 좋겠다. 올해 초까지 변함없이 후원도 해 주신 분이 계신 것에 감사드린다.
타자연습은 바뀐 것이 없지만, 이번에 한글 입력기의 소스 코드를 정리하는 과정에서 거의 쓰이지 않는 잉여 가상 함수를 하나 삭제하는 바람에.. 클래스 라이브러리의 바이너리 호환이 깨지게 됐다. 그래서 부득이하게 업데이트 됐다.

그럼 이제부터는 컴퓨터/프로그래밍 관련 여담을 좀 늘어놓고자 한다.

A. 키보드

뭐, PC 키보드에 존재하는 3대 lock 글쇠 중에서 존재감이 제일 없는 잉여는 두 말할 나위 없이 scroll lock일 것이다. 본인은 조금이라도 이걸 구분해서 동작하는 프로그램을 엑셀 말고는 지금까지 좀체 보지 못했다.
맥 계열 컴퓨터의 키보드에는 이게 존재하지도 않는다. 어지간한 노트북 키보드에서는 fn을 눌러야 접근 가능한 식으로 봉인됐다. pause 키처럼 말이다.

옛날 도스 시절에 하드웨어를 좀 특수하게 제어하는 게임은 caps/num/scroll lock을 눌러도 램프 상태가 변하지 않고, pause를 눌러도 컴퓨터 진행이 정지하지 않으며, ctrl+alt+del을 눌러도 시스템이 재부팅되지 않게 무슨 lock 같은 걸 걸어 놓고 돌아가긴 했었다. 그 옛날에 만들어진 황금도끼 도스용도 그런 프로그램 중 하나였었다. 그런 건 어떻게 구현했는지가 문득 궁금해진다.

GUI 환경에서 '복사'의 단축키로 워낙 잘 쓰고 지내긴 하지만 명령 프롬프트에서는 Ctrl+C가 프로그램의 실행을 중단하도록 인터럽트를 발생시키는 단축키였다. Ctrl+Pause(Break)는 Ctrl+C보다 수위가 더 강한 글쇠였고 말이다. 이건 소프트웨어적인 이벤트이기 때문에, 이 글쇠에 반응할지 말지를 지정하는 기능은 아마 도스 API 수준에서 있었지 싶다.

B. 명령 프롬프트에서의 문제

Windows용 한글 IME의 개발자로서 Windows의 명령 프롬프트는 참 기묘한 환경이다.
기본적으로야 운영체제가 기본 제공하는 TSF라는 인터페이스를 그대로 적용할 수 있지만 정확하게 들어맞지는 않는다. 다른 프로그램에서는 스펙에 명확하게 규정되지 않은 문제에 대해서 어떤 방법을 적용해도 동작하는데, 저기서만 미묘한 오동작이 발생해서 해결책을 찾느라 골머리를 썩인 적이 몇 번 있었다.

가령, 한글을 조합하고 있다가 다음 한글로 넘어갈 때 말이다. 지금 조합을 종료한 뒤 뒷글자 조합을 새로 시작할 수 있는가 하면, 지금 조합을 뒤에다 길이 0짜리 문자열로 유지한 뒤 그걸 재활용해서 뒷글자를 표현할 수도 있다. 마치 빈 문자열이냐 NULL이냐의 차이와 비슷한데, 어지간한 프로그램이라면 무슨 방법을 쓰든 동작이 동일해야 한다.

그런데 어떤 프로그램에서는 전자로만 해야 하고 후자 방법을 쓰면 조합이 씹히거나 끊긴다. 다른 프로그램에서는 후자로만 해야 하고 전자 방법을 쓰면 안 된다. 문제의 해결 방법이 프로그램별로 서로 다르기 때문에 IME의 소스를 더욱 지저분하게 만드는 주범 역할을 한다.
명령 프롬프트의 경우, 조합을 반드시 끊어야 하더라. 안 그러면 기존 글자가 지워지고 뒷글자로 덮어 써진다.

'새나루'는 본인이 개발한 날개셋과 더불어 오랫동안 3rd-party 한글 IME의 한 축을 담당해 왔지만 2010년대 이후로 버전업이 없이 개발이 사실상 중단됐다. 그 대신, 웬일로 한컴에서 Windows용 IME를 만들어서 아래아한글 2018에서부터 제공하기 시작했다. 한컴 IME도 명령 프롬프트에서 동일한 문제가 발생하던데, 난 이 문제를 겪어 봤기 때문에 원인을 안다.

C. 음절문자의 글쇠배열은?

한글이나 알파벳은 음소문자이다. 그렇기 때문에 글쇠배열을 적절히 만들면 양손이 각각 자음과 모음을 담당해서 최소한의 규칙성과 리듬감을 갖춘 형태로 타자를 할 수 있다.
그런데 자음· 모음 구분 없고 수십 종류의 음절이 제각기 서로 다른 글자로 배당돼 있는 일본어 히라/가타카나 또는 주음부호는 글쇠배열이 어떤 형태로 돼 있을까? 긴 글을 타자하는 경험은 어떠할까?

하긴 요즘은 대만에서도 주음부호 대신 한어병음을 더 가르치며 일본 역시 사람들이 어지간해서는 그냥 로마자로 발음을 입력하지, 골치 아픈 일본어 문자 전용 글쇠배열은 잘 쓰지 않는다고 듣긴 했다. 이거 뭐 삼성에서 훈민정음을 포기하고 Word로 갈아탔다는 것과 비슷한 얘기를 듣는 느낌이다.

Posted by 사무엘

2019/03/08 08:35 2019/03/08 08:35
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1594

1.
악기 공부하는 걸 외국어에다 비유한다면, 피아노는 기본 중의 기본이요 만국 공용어인 영어에 대응할 듯하고, 그 다음에 일본어, 독일어, 스페인어 등의 2군에 대응하는 건 학교 음악 시간에도 접하는 작고 간편한 악기(리코더, 멜로디온, 실로폰, 하모니카...) 내지 바이올린· 기타· 플루트처럼 교육과정엔 없지만 일반인에게 비교적 친숙한 악기가 될 듯하다.

3군으로 가면 2군과 비슷하지만 살짝 더 마이너한 악기들까지 포함된다. 가령, 현악기라면 바이올린 대신 첼로, 비올라, 콘트라베이스 말이다. 본인은 색소폰도 2군보다는 3군에 가깝다고 생각한다. Looking for you 때문에 색소폰을 잠시 배워 봤지, 그게 아니었으면 교회 음악으로 더 적절한 2군 악기를 골랐지 싶다.

2.
건반악기가 여러 종류가 있지만 피아노는 망치로 내부의 줄을 때려서 소리를 낸다. 오르간과 멜로디온은 페달질이나 입을 통해 공기를 따로 공급해 줘야 소리가 나며, 소리도 피아노 소리와는 다르다. 보급형 오르간은 옛날에 시골 학교나 교회에서 종종 볼 수 있었던 것 같은데 요즘은 싹 사라졌다.
피아노의 페달은 음향 바리에이션 필터 역할만 한다. 3개 중 가운데의 것은 소리를 줄이는 소음기(silence), 오른쪽 것은 크게 울림(vibration??)인데 왼쪽 페달의 역할은 무엇인지 잘 모르겠다.

그리고 피아노라는 건 외형이 전통적으로 두 계열로 나뉜다. (1) 윗뚜껑이 마치 자동차의 엔진 후드처럼 열려 있으며 표면이 직사각형도 아닌 곡선 모양인.. 일명 '그랜드 피아노', 아니면 (2) 그냥 높고 밋밋한 직사각형 상자처럼 생긴 'upright 피아노'이다.

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

집이나 학교에서는 (2)를 훨씬 더 많이 볼 수 있다. 하지만 본격적인 공연장에서는 무조건 닥치고 (1)이 필수이다. 이건 마치 학교의 보급형 풍금과 거대한 파이프 오르간의 차이와도 비슷하다.

(2)가 가격이 더 저렴하고 공간도 덜 차지하기 때문에 훨씬 더 서민 지향적이다. 하지만 (2)는 (1)에 비해서 소리가 별로 좋지 않다고 하는데.. 구체적으로 어떤 차이가 있는지는 난 잘 모르겠다. 일단 자동차의 V형 엔진과 L형 엔진이 실린더의 배치가 차이가 있듯이, 내부의 망치와 발성 장치를 배치한 방식이 어떤 형태로든 차이가 있을 것이다.
사실, (1)이 우리가 생각하는 피아노의 원형에 더 충실한 모습이며, 처음에 발명된 피아노도 원래는 (1)과 같은 모양이었다고 한다.

3.
대부분의 악기들은 사람이 간편하게 휴대할 수 있다. 하지만 어떤 악기는 사람이 혼자서 들 수 없을 정도로 거대하고 무겁다. 피아노가 대표적으로 이런 급이기 때문에 악기를 들고 오는 게 아니라(세례??) 연주자가 악기가 있는 곳으로 가야 한다(침례??).

하프는 그 경계에 속하는 것 같다. 악기의 인지도 자체는 굉장히 높은 반면, 현실에서의 존재감은 본인이 느끼기에 최소한 4군 이하.. 언어로 치면 한국인에게 무슨 알바니아· 불가리아어, 헝가리어 같은 매우 마이너한 악기이다. 일단 크기부터가 대형 하프는 높이는 거의 사람 키 만하고 무게는 40kg이 넘는다고 한다. 프로 전공자가 사용하는 최고급 물건은 단가가 거의 제네시스 이상 고급 승용차의 가격에 맞먹는다(수천만~억).

그런데 이건 개인용 악기를 매번 들고 다녀야 한다. (피아니스트가 자기 전용 피아노를 들고 다니지는 않을 텐데!) 여느 가구 옮기듯이 옮기다가 어디 잘못 건드리고 흠집이라도 났다간??
그렇기 때문에 하프는 운반만 전문으로 담당하는 업자가 있다고 한다. 페이지 터너(넘돌이 넘순이)만큼이나 음악에서 보이지 않는 조연 역할이다. 악기도 무슨 보험이라도 들어야 하지 않나 싶다.

사용자 삽입 이미지

4.
다음으로.. 악기 중에서 입으로 불어서 본체에다 바람을 주입하여 소리를 내는 물건을 관악기라고 한다.
관악기는 더 세부적으로 목관악기와 금관악기로 나뉘는데, 말은 그렇게 써 놨어도 오늘날 '목'이냐 '금'이냐 하는 실질적인 분류 기준은 악기의 재질이 아니라 악기의 메커니즘 내지 발성 방식이다.

목관악기는 숭숭 뚫린 구멍을 막는 방식을 달리해서 음높이를 표현하는 일명 '피리'형 악기의 총칭이다. 그 반면, 금관악기는 구멍이 아니라 입술 상태 내지 밸브로 음높이를 표현하는 '나팔'형 악기의 총칭이다.
그렇기 때문에 플루트나 색소폰은 각각 니켈이나 황동 같은 금속 재질이며, 특히 색소폰은 한쪽 끝이 크게 튀어나와서 나팔을 좀 닮았음에도 불구하고.. 기술적으로 목관악기로 분류된다. 둘 다 리코더처럼 구멍을 막아서 음을 표현하기 때문이다.

뭐, 플루트는 과거에는 실제로 재질도 목재인 적이 있었다고 한다. 그리고 색소폰도 입이 닿는 reed는 엄연히 목재이긴 하다. 도대체 이 자그마한 나무 조각이 무슨 역할을 하길래 이게 없으면 소리가 나질 않는다니, 악기의 물리학은 신기하기 그지없다.

5.
그런데 피리형 악기는 입술과 수평으로 평행하게 배치해서 부느냐, 아니면 수직으로 배치해서 부느냐로 나뉘는 것 같다. 플루트는 수평형이지만 나머지 리코더, 단소, 색소폰, 오보에, 클라리넷 등 대부분의 목관악기들은 수직형이다.
플루트 말고 다른 수평형 악기가 존재하는지? "울지 말고 일어나 피리를 불어라, 삘릴리 개굴개굴 삘릴릴리"라고 개구리 왕눈이에서 주인공이 부는 피리는 그래도 플루트에서 모티브를 땄는지 수평형이다.

사용자 삽입 이미지

하모니카는 일단은 수평형이긴 하지만 이걸 목관이라고 봐야 할지 금관이라고 봐야 할지는 모르겠다. 구멍 같은 건 없고, 악기에서 마우스피스에 해당하는 부위가 점이 아니라 선분인 셈인데.. 그리고 하모니카는 부는(미는) 것뿐만 아니라 빨아들이는(당기는) 동작도 있는 거의 유일한 악기이다. 반음을 표현할 수 없어서 불편하지만 크기가 아주 작아서 휴대하기엔 좋다.

6.
오보에와 클라리넷은 길이, 두께 같은 외형(...)이 서로 비슷하게 생긴 것 같다. 단지 꼭대기 부분이 외관상 명백하게 차이가 난다(아래 사진에서 꼭대기가 은색으로 뾰족한 게 오보에). 그리고 클라리넷이 좀 더 색소폰에 가까운 웅웅~은은한 소리가 나고, 오보에는 코맹맹이 같으면서도(나쁘다는 뜻은 아님) 더 고유한 음색을 갖춘 소리가 난다.

본인은 오보에의 소리가 더 마음에 들고 음반 같은 데서 확실하게 들은 기억도 난다. 그래서 둘 중 하나만 배울 기회가 있다면 오보에를 불어 보고 싶다.

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

7.
소를 진짜로 잡지 않아도 저렴하게 쇠고기 국물 맛을 내 주는 화학 조미료가 식품계에 존재하듯.. 음악계에도 소리 파형을 조작하여 실존 악기의 소리를 흉내 내 주는 신시사이저가 존재한다.
옛날에 주파수 변조만으로 수십 수백 가지의 악기를 구현했던 그 특유의 애드립 FM 음악(standard.bnk), 그리고 어지간한 PC용 운영체제에 내장돼 있는 미디 신시사이저들을 살펴보면 나름 바이올린, 피아노, 색소폰 등 기성 악기들을 구현했다고 그런다. 하지만 실물 악기의 소리와 비교해 보면 그냥 육개장 사발면과 실제 육개장의 차이와 비슷한 차이가 느껴진다.

최소한 큐베이스, 로직 같은 전문적인 오디오/음악 편집 프로그램이 제공하는 비싸고 계산량도 많은 가상 악기를 동원해야 실물 악기와 비슷해진다. 마치 페인터의 브러시 엔진이 실물 종이와 물감을 일일이 시뮬레이션 하듯.. 악기의 물리적인 구조와 공기 진동을 일일이 다 시뮬레이션 해야 실물 악기의 모든 특성을 표현할 수 있을 듯하다.
다양한 악기는 외국어뿐만 아니라 글꼴에다가도 비교할 수 있는데, 실제로 '사운드 폰트'라는 명칭이 존재한다고 한다.

8.
그러고 보니 악보와 음표· 음자리표 따위에 대해서도 취향별로 다양한 font family라는 걸 만들 수 있지 않을까 하는 생각이 든다. 하다못해 옛날 찬송가와 21세기 새찬송가만 해도 악보· 음표의 스타일이 미묘하게 달라져서 같은 공간 안에서도 새찬송가의 음표가 약간 더 큼직해졌다.

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

위의 악보들 중 우측 하단은 가사를 적은 한글만 밋밋한 굴림체인 게 아니라, 그야말로 음표와 조표들도 너무 밋밋하고 베이직한 스타일이다.
음악과 타이포그래피의 만남인가? ㅎㅎ

9.
독일어는 가히 음악인의 언어인 것 같다. 전공자들이 독일 유학을 워낙 많이 가니까 말이다. 정작 나타냄말 내지 셈여림 언어는 다 이탈리아어인데, 얘는 어쩌다가 주류에서 밀려났는지 모르겠다.

10.
끝으로.. 서양은 수학· 과학뿐만 아니라 음악· 미술도 어쩜 저렇게 눈부시게 발달했나 모를 노릇이다. "우리의 것" 발굴하는 분들에게 섭섭하게 들릴 수도 있고 어차피 지극히 주관적인 개인 생각일 뿐이긴 하지만, 본인은 국악은 막 듣기 좋거나 예술성이 크게 뛰어나다고 느껴지지 않는다.

맨날 천날 암울하게 한이 서리네 어쩌네 하고, 주류 민요라는 게 "나를 버리고 가시는 님은 10리도 못 가서 발병 난다" 이딴 식으로 찌질하게 한풀이나 하고 있다. 서양 음계처럼 음이 다양한 것도 아니고 앵앵앵 소리도(해금??) 바이올린이나 피아노에 비하면 그다지 듣기 좋은 소리라고 볼 수 없다.

국악 스타일의 찬양도 말이다. "예수님이 좋은 걸 어떡합니까" 부류는 뭐, 흥겨운 건 인정하지만.. "나 같은 죄인 살리신", "갈보리 산 위에 십자가 섰으니"처럼 막 심금을 울리고 감동적이고 깊이가 있다고 보기는 어렵다.
한반도에서 그나마 정말로 자랑스럽고 선한 게 나온 건 한글 정도가 전부가 아닐까 싶다.

Posted by 사무엘

2019/03/05 08:33 2019/03/05 08:33
, , , , , ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1593

« Previous : 1 : ... 72 : 73 : 74 : 75 : 76 : 77 : 78 : 79 : 80 : ... 221 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
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:
3049467
Today:
487
Yesterday:
2142