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

살다 보니 C#이나 파이썬도 아니고 비주얼 베이직으로 작성된 코드를 C++로 포팅해야 할 일이 있었다. C/C++로 갈아탄 뒤로는 베이직 코드는 다시는 볼 일이 없을 줄 알았는데 이거 정말 몇 년 만이냐.

들여다봐야 하는 코드는 닷넷도 아니고 비주얼 베이직 6으로 만들어진 코드였다. 하지만 GUI가 아니라 계산 알고리즘을 포팅하는 것이기 때문에 포팅이 크게 어려운 건 없었다. VB6에서 닷넷으로 넘어가면서 완전히 뒤집어엎어진 건 API 체계이지, 언어 자체가 그렇게 많이 바뀐 건 우려한 것만치 많지 않아 다행이었다. 자바와 자바스크립트의 관계에 필적하는 이질감은 아닌 것 같다.

언어가 바뀐 것은,
- 첫째, statement이던 것이 C 언어의 영향을 받아 다 일관된 함수 호출 형태로 바뀜. 그래서 매개변수 전체를 괄호로 싸야 됨. (파이썬도 3.0에서는 print가 statement에서 함수로 바뀜)

- 둘째, 타입이 예전보다 더 엄격해지고, 모든 변수는 반드시 사용 전에 선언을 해 줘야 함. 베이직은 원래 그런 걸 안 하는 언어이다가 하는 걸로 바뀌었다 보니, 변수를 선언하는 키워드가 Var이 아니라 Dim...이다. 원래는 배열을 선언할 때만 쓰는 키워드였지.
이런 추세를 정면으로 역행하는 GWBASIC의 잔재인 DefINT A-Z 같은 명령문은 당연히 퇴출이다.

- 셋째, 그리고 객체지향 패러다임에 맞춘 API의 전면 재구성이다. 예전엔 그냥 global 단위로 곧바로 호출하던 함수도 다 분야가 나뉘어서 클래스나 namespace에 소속된 메소드로 바뀌었다. 그래서 수학 함수도 바로 Sqrt라고 하면 안 되고 Math.Sqrt라고 써 줘야 하며, Math를 자주 쓴다면 Using 선언을 한 뒤에 생략해야 한다. 하긴, 비베에는 예전부터 With 키워드는 있긴 했다만.

이 정도.
요즘 언어들은 C/C++ 영향을 받아서 다들 대소문자 구분을 하는 게 유행이기 때문에, 혹시 비주얼 베이직도 그렇게 바뀌지 않았으려나 생각했다만...
의외로 명칭에 대소문자 구분을 안 하는 건 VB6이나 닷넷이나 마찬가지이다.

베이직은 원래 좀 가볍고 동적인 언어였는데, MS의 닷넷 입맛대로 대수술을 거치다 보니 그냥 C#의 표현력에 필적하는 전형적인 절차형 언어가 된 것 같은 느낌이 든다. 예전의 베이직 같은 느낌은 파이썬이 더 잘 간직하고 있는 듯.

배열 첨자도 ()로 싸고, 함수 호출 인자도 ()로 싸는 건 베이직의 특징이다. 언뜻 보기에 굉장히 혼동될 것 같은데 C++처럼 [] () 따로 연산자 오버로딩이라도 해야 하는 게 아니라면 의외로 둘이 문법 차원에서 혼동될 일은 없다. 참고로 본인은 ::와 .의 구분이 없는 객체지향 언어들에 대해서도 의아해한 적이 있었는데 이 구분 역시, 포인터만 없다면 거의 필요하지 않다.

그러고 보니 베이직은 대입도 =, 동등 비교도 =이다. A=B=1이라고 하면 C언어 식으로 치자면 A=B==1처럼 해석된다. 원래 베이직의 대입문은 Let A=1 처럼 써 줘야 맞는데 Let이 C언어의 auto만큼이나 캐잉여로 전락하는 바람에 지금 같은 꼴이 된 것이다. 그러고 보니 Let을 Dim처럼 변수 선언 키워드... 아니 C++0x의 auto처럼 쓰는 것도 괜찮을 것 같다?

Dim A as Double
Dim I as Integer

뿐만 아니라

Let A = 0.52 '자동으로 실수 확정
Let I = 5    ' 자동으로 정수 확정

이렇게도 되게 말이다. 타입이 이랬다저랬다 바뀌는 Variant가 아님. 기발하지 않은지? ㄲㄲ

베이직처럼 구문 분석이 쉬운 언어는 IDE의 인텔리센스나 코드 자동 완성 같은 기능이 C++의 그것과는 비교할 수 없이 안드로메다급으로 훨씬 더 빠르고 똑똑하고, 돌아가는 게 손에 착착 달라붙는다. 도스 시절의 퀵베이직이 이미 인텔리센스만 없을 뿐이지 그런 꿈의 프로그램 개발 환경을 어느 정도 제공하고 있었다. 빌드 속도는 두말 할 나위도 없음.

그러나 C++ 코드는 실시간으로 코드 변경 사항을 IDE가 따라잡으려면, 비주얼 스튜디오든 Source Insight든, 어쨌든 background에서 소스를 다 까 보는 작업을 하지 않으면 안 된다. 그래서 어떻게든 처리 속도를 올리려고 덕지덕지 남기는 부가 정보 데이터가 많다. 함수 이름을 바꾼 게 C/C++은 복잡한 절차를 거쳐 최소한 수 초 뒤에 IDE의 ClassView에 반영되는 반면, 베이직은 ‘즉시’이다.

이런 생산성과, C++ 특유의 졸라 가볍고 효율적인 네이티브 코드라는 두 마리 토끼를 모두 잡은 프로그래밍 언어 + 개발 환경은 정녕 없는 것일까.
하긴, 윈도우 환경에서 베이직 언어로 네이티브 코드를 생성하는 컴파일러는 MS 제품 중에는 없고 파워베이직이라는 브랜드가 있다. 하지만 인지도가 안습한 수준.

Posted by 사무엘

1. 비주얼 C++ 한글판

마이크로소프트에서 한글화한 프로그램의 UI에서 이런 저런 오역이 발견되는 건 어제 오늘 일이 아니다. 뭐, “안녕하신가, 힘세고 강한 아침!” 수준의 막장 발번역-_-은 아니지만, 이런 오역이 간간히 발견되는 주된 이유는, 번역자가 해당 소프트웨어가 다루는 분야의 용어를 잘 알지 못해서일 것이다. 그리고 어떤 문장이나 단어가 실제로 프로그램의 어느 부분에서 등장하는지를 모르는 채, 그냥 번역 리스트만 쭉 보면서 아무 문맥 정보가 없이 기계적으로 번역만 했기 때문일 것이다.

마이크로소프트가 개발한 소프트웨어 개발툴 중 비주얼 베이직은 5던가 6 시절부터 이미 한글화가 되었다. 그 반면, 가장 어렵고 하드코어한 개발툴인 비주얼 C++ 6은 한글화되지 않았으며 닷넷에서부터 통합 IDE가 제공되는 과정에서 드디어 한글화가 됐다. 그러나 베테랑 개발자 중에 한글판 IDE를 선호하는 사람은 거의 없으며, 이 점에서는 본인도 마찬가지이다.

옛날에 유니코드라는 것도 없고 PC의 환경이 극도로 열악하던 시절에는 한글판이 대놓고 영문판보다 성능이 열등했다. 텍스트 모드에서 한글 바이오스를 띄웠을 때와 띄우지 않았을 때의 성능 차이는 말할 나위도 없고, 도스 시절에 한글 QuickBasic은 성능은 둘째치고라도 그야말로 퀵라이브러리(qlb) 파일 포맷이 영문판과 호환조차 되지 않던 쓰레기-_-였다.

영문 윈도우 95는 4MB 램에서 그럭저럭 돌리는 게 가능했던 반면, 각종 무거운 한글· 한자 글꼴을 얹어야 했던 한글 윈도우 95는 최하 6~8MB 램이 필요했다. 그것도 어지간한 PC의 메모리가 4~8MB 사이이던 시절에!
난 아직도 기억이 생생한 게, 펜티엄급 노트북에서 IE4를 띄웠는데 빽빽한 영문으로 된 사이트는 비교적 매끄럽게 스크롤된 반면, 빽빽한 한글이 적힌 사이트(그냥 굴림체 비트맵 글꼴 크기)는 스크롤이 상당히 굼떴었다.

그도 그럴 것이 윈도우 세계에서는 '한글'이 그것만 특별 취급해 줘야 하는 문자가 아니었으니, 당시의 도스용 프로그램들처럼 효율적인 조합형 한글 입출력 메커니즘이 쓰이지 않았다. 게다가 한국에서 완성형이 주류 표준이다 보니 다국적 소프트웨어라면 한글을 2350자 내지 11172자의 그림문자처럼 취급할 수밖에 없었기 때문이다.

물론 세월이 흐르고 흘러 지금은 언어에 따른 성능 격차는 없기에 앞서서 측정 자체가 무의미해진 건 사실이다. 지금은 성능 격차 때문에 일부러 영문 원판 소프트웨어를 찾아 쓸 필요는 없다. 그러나 비주얼 C++ 같은 프로그램은 어차피 아무나 쓰는 프로그램도 아니고, 핵심 용어들에 대한 어설픈 번역에 이질감과 거부감이 들어서 한글판을 안 쓴다고 보는 게 타당하겠다.

단적인 예를 들어 보겠다. 아래 스크린샷을 보라.

먼저, output 창에 있는 컴파일 에러 로그를 보자. Illegal case를 '대/소문자가 잘못되었습니다'라고 오역한 건, 비주얼 C++이 처음으로 한글화된 200x 이래로 지금의 무려 2010에서까지 고쳐지지 않았다. 번역자가 C++ 프로그래밍에 전혀 무지하거나, 이 문장이 어느 문맥에서 쓰이는지를 하나도 알지 못한 채 번역했음이 분명하다. 세상에 C++이 컴파일러 차원에서 코드의 대소문자 오류를 분간해 주는 언어였던가. ㄲㄲ

비주얼 스튜디오 2010은 C#에 이어 C++까지도 코드의 오류가 있는 부분에 빨간 점선을 그어 준다. 물론 C++ 코드는 C# 코드보다 분석하기 훨씬 더 힘들기 때문에, 이는 내부적으로 완전한 형태의 컴파일러를 백그라운드로 돌림으로써 상당한 양의 CPU 오버헤드와 디스크 용량을 대가로 치른 끝에 구현된 편의 기능이다.

마우스를 case문 에러가 있는 곳으로 가져가 보면, 에러 메시지가 뜻밖에도 컴파일러가 뱉은 것과는 표현이 다르다. 그런데 '스위치'라고? 이건 case를 대소문자라고 옮긴 것보다는 덜 심각한 오역이지만, 이 역시 번역자가 문장을 제대로 이해를 못 하고 번역한 것 같다. 혹시 기능을 켜고 끄는 물리적인 스위치를 생각한 건 아닐까? 스위치를 음역하지 말고 그냥 'switch문'이라고 옮기는 것이 더 정확할 것이다.

2. 비주얼 스튜디오 2010의 GUI customization

비주얼 스튜디오와 MS 오피스 제품(지금처럼 리본 UI가 도입되기 전)은 그야말로 자신만의 화려하고 강력한 GUI를 갖추고 있었다. 메뉴와 도구모음줄은 운영체제가 자체 제공하는 녀석이 아닌 독자 구현 버전을 썼으며, 정말 과잉 투자 잉여라는 생각이 들 정도로 모든 GUI 구성 요소를 사용자 입맛에 맞게 바꿀 수 있었다. 도구모음줄의 배치는 두말 할 나위도 없고, 등록해 놓을 명령, 그리고 심지어 아이콘 그림과 기능 명칭까지도!

내 기억이 맞다면 이거 원조는 MS 오피스 97이다. BCG나 Xtreme toolkit처럼 이런 GUI 엔진만 짝퉁으로 구현하여 미들웨어 형태로 파는 업체도 응당 있을 정도였다.

이런 GUI 엔진이 탑재된 프로그램은 메뉴에 Tool(도구) - Customize(사용자 지정)라는 명령이 있었고, 이 대화상자는 약간 특이하게 동작을 했다.
보통 modal 대화상자가 떠 있는 동안은, 상위의 응용 프로그램 윈도우는 그 대화상자를 닫을 때까지 전혀 반응을 하지 않게 된다.
그런데 그 Customize 대화상자는 비록 modal 형태이지만, 그게 떠 있는 상태에서 마우스로 도구모음줄을 클릭하거나 메뉴를 누르면 도구모음줄이 반응을 했다. 도구모음줄 아이콘을 드래그하여 배치를 바꾸거나 없애거나, 콤보 상자의 경우 폭을 조절할 수 있고 우클릭하여 아이콘이나 설명문을 고칠 수 있었다.

즉, 평소에 도구모음줄을 우클릭하면, 나타내거나 감출 도구모음줄을 선택하는 메뉴만 뜨지만, Customize 중에 도구모음줄을 우클릭하면 해당 도구모음줄 아이콘을 고치는 더 세부적인 명령이 떴던 것이다.
메뉴에서 자주 쓰는 기능을 도구모음줄에다가도 좀 올려 놓으려면, 메뉴를 연 뒤에 해당 기능을 원하는 도구모음줄에다가 Ctrl+드래그만 하면 끝이었다.

그런데... 그런데... 비주얼 스튜디오 2010은 GUI 엔진이 싹 바뀌면서 저런 예외적이고 특이한 기능을 다시 구현하기가 대략 곤란했는지..
Customize 대화상자와 도구모음줄이 자연스럽게 연동하는 기능이 완전히 없어졌다.
대화상자가 떠 있는 동안은 도구모음줄을 전혀 건드릴 수 없다.

도구모음줄을 고치는 걸 전적으로 대화상자 안에서만 해야 한다.
내가 원하는 명령을 도구모음줄에다가 좀 추가하려고 했는데, 내가 원하는 도구모음줄과 내가 원하는 명령을 일일이 복잡한 리스트에서 찾으면서 정말 불편하고 번거롭기 그지없었다.
그리고 콤보 상자(빠른 찾기, 솔루션 플랫폼, 빌드 configuration 바꾸는 것 등)의 폭을 좀 바꾸려고 했는데 세상에나...
폭을 픽셀 단위 숫자로 입력해야 한다. -_-

예전에는 마우스 드래그로 간편하게 됐던 것이 상당히 퇴보한 게 아닐 수 없다..;;
난 개인적으로 GUI 운영체제에서, 화면으로 결과를 당장 볼 수 있는 값을 숫자 하나 달랑 입력받게 해 놓은 UI를 싫어한다. 가령, 객체를 회전하는 것만 해도 MS 오피스는 회전축을 잡고 마우스로 드래그함으로써 결과를 실시간으로 보면서 쉽게 할 수 있는데, 아래아한글 2007은 각도를 숫자로 입력해야 하고, 만족스러운 각도가 나올 때까지 사용자가 시행 착오를 겪어야 한다.;;

그런데 그런 불편한 방식을 비주얼 스튜디오 2010이 답습한 셈이다.
Customize 기능을 없앨 수는 없으니까, 그냥 이런 형태로 대충 대체 UI를 집어넣은 거라는 인상을 지울 수 없다.;;

딱 하나 좋아진 게 있다면,
예전의 customize 방식은 편리한 대신, 편법 UI인 만큼 오로지 마우스로만 접근 가능하고 키보드로는 하는 게 아예 불가능했는데 이제는 대화상자를 다루는 것이니 키보드로도 얼마든지 가능해졌다는 것.
사실, 가장 이상적인 건 둘을 모두 갖추는 것이긴 한데 이건 비주얼 스튜디오 2010에서 아쉬운 면모가 아닐 수 없다.

아울러 덧붙이자면, VS 2010도 Alt+F11을 눌러서 매크로 편집기를 열어 보면 그건 하나도 안 바뀌었고 예전의 VS 2008 IDE가 거의 그대로 뜬다.

Posted by 사무엘

전산학 전공자 내지 IT 분야 종사자에게는 상식으로 통용되는 당연한 개념이다만..
오늘날 범용(generic-purpose) 컴퓨터에서 돌아가는 소프트웨어는 크게 세 가지 형태로 나뉜다.

1. 로컬

흔히들 PC로 대표되는 컴퓨터에서 stand-alone으로 동작하는 전통적인 프로그램이다. Windows야 그렇다 치더라도 오피스, 비주얼 스튜디오 같은 업무용 프로그램은 아직 로컬 프로그램의 아성을 무너뜨릴 영역이 없다.
가장 역사가 길고, 가장 빠르고 효율적으로 동작하며, 특정 컴퓨터 아키텍처(기계어)와 운영체제의 실행 파일 포맷에 종속적이다. 그래서 이쪽 개발 환경은 전통적으로 C/C++ 같은 저수준 최적화 언어가 강세이다.

물론 클라이언트가 아닌 서버 프로그램은 성격이 약간 다르긴 하나, 서버 프로그램 자체는 역시 서버라는 로컬 컴퓨터 자신의 자원만을 이용하여 동작한다. 여객 운송과 화물 수송의 차이와 비슷한 맥락이다. 그리고 사실은, 다음에 설명할 2.웹 프로그램을 돌려 주는 기반도, 클라이언트든 서버든 1.로컬 프로그램들이 다 마련해 주고 있다. 그러니 로컬 프로그램은 앞으로도 없어질 수는 없다. 단지 전체 소프트웨어에서 차지하는 비중이 줄어들 뿐이다.

옛날에는 불특정 개인 사용자를 대상으로 하는 상업용 제품은 패키지 형태로 발매되곤 했지만, 오늘날은 인터넷의 발달과 극심한 불법 복제로 인해 이런 전통적인 형태의 배포의 비중이 굉장히 줄어들었다. 오늘날 국산 패키지 소프트웨어는 아래아한글과 V3 말고 있나? -_-;; 또한 보안 위협으로 인해 이런 프로그램 역시 한번 설치하고 끝이 아니라 끊임없는 보안 패치와 업데이트의 필요성이 커져 있기도 하다.

2. 웹

개인용 컴퓨터의 성능이 굉장히 향상되고 그에 따라 웹 표준이 발달하면서 웹브라우저, 정확히 말해 WWW는 단순히 그림과 하이퍼링크가 동원된 문서라기보다는 거의 프로그래밍 플랫폼처럼 오래 전부터 바뀌었다.

웹 프로그래밍의 최대 매력은 로컬을 월등히 능가하는 범용성과 기계 독립성, 생산성이다. 브라우저에서 사이트 접속만 하면 바로 실행..;; 마치 게임처럼, 클라이언트와 서버, 코딩과 디자인 등을 두루 아우르는 종합 예술처럼 보이기도 한다. 가령, 옛날에는 GWBASIC이나 LOGO로 어린 학생들에게 그래픽 프로그래밍 교육을 시켰다면, 지금은 그냥 HTML5만 써도 될 것이다.

물론, 로컬 개발에 비해서는 혼자 독립적인 작품을 만든다는 느낌이 좀 덜 들며-_-, 기술이 아직까지 안정화해있지 않은 면모가 있고, 로컬 컴퓨터 자체를 세밀하게 제어할 수 없으며 성능이 떨어진다는 한계도 있다. 가령, 오피스 제품군이 웹 애플리케이션으로 완전히 대체될 날은 과연 글쎄?
그러나 앞으로 웹 프로그래밍의 비중은 절대 무시 못 할 것이고 수요도 없어지지 않을 것이다.

3. 앱

스마트폰에서 동작하는 '로컬' 프로그램이라고 볼 수 있지만, 그 성격이 역시 1과는 사뭇 다르다.
스마트폰 자체는 PC보다 성능이 떨어지기 때문에, 로컬에서 모든 처리를 마친다기보다는 서버에다 input을 보내서 받은 output을 보여주는 형태의 앱이 많다. 또한 스마트폰은 화면이 작고 PC 같은 빠른 문자 입력을 할 수 없기 때문에, PC와는 다른 독자적인 GUI가 필요하다. 터치스크린은 마우스와 완전히 동일한 포인팅 UI가 아니다. (대표적으로 hovering이란 게 없다) 다만, PC에는 없는 기울임, 흔들림, 방향, 현재 위치 같은 특수한 입력을 받아들일 수 있다.

스마트폰은 PC만치 사용자가 컴퓨터 내부를 완전히 손쉽게 제어할 수 있는 물건은 아니다. 그래서 PC용 프로그램보다는 더 엄격한 과금 체계를 갖추고 프로그램을 배포하여 수익을 낼 수 있다.
스마트폰 앱은 역사가 짧기 때문에 PC 같은 지저분한 호환성 잔재 같은 게 덜하고, 일찍부터 자바든 C#이든 객체지향 언어와 가상 기계 바이트코드 기반의 프로그래밍 환경이 잘 구축돼 있다. 깔끔한 최신 프로그래밍 인프라가 기본으로 제공된다는 뜻이다.

오늘날 스마트폰 CPU는 ARM 아키텍처밖에 없지만, 그래도 커널 말고 다른 응용 프로그램들은 네이티브 코드가 아니다. 그런 .NET이나 자바 같은 가상 기계 자체가, 1~3(로컬, 웹, 앱) 사이의 이질감을 낮추고자 만들어진 것이기도 하고 말이다.
아울러, CPU의 성능이 좋아졌을 뿐만 아니라 LCD 디스플레이 소자가 보편화하고 통신 기술이 발달하면서 스마트폰 같은 물건도 대중화될 수 있었다.

20세기 중반까지만 해도 컴퓨터는 곧 메인프레임-단말기 모델이었다.
컴퓨터라는 게 무진장 비싼 물건이고 자원이 귀하다 보니, 모든 처리는 중앙 컴퓨터에다 맡기고 각 사용자는 단말기로 서버에 접속해서 명령 프롬프트에서 서버의 기능을 사용하곤 했다. 그때는 컴퓨터는 대학, 연구소, 정부 기관, 군대의 전유물이었고, 개인용 컴퓨터라는 개념을 감히 떠올리기조차 쉽지 않았었다. (알파넷이 미국이 아닌 소련에서 발명되었다고 생각해 보자. 그게 오늘날의 인터넷으로 발전할 수 있었을까? -_-)

그러다가 20세기 말에는 PC가 대세가 되었다. 개인용 컴퓨터 하나만으로 어지간한 일은 다 할 수 있게 되었다. 비유하자면, 만원버스에 시달리면서 출퇴근하다가 번듯한 자가용이 생긴 셈.
PC의 사고방식으로는 소위 PC 통신은 어쩌다 한 번씩만 다른 컴퓨터에 접속하는 특별한 작업이며, 웹브라우저 역시 오피스 패키지처럼 별도로 구입해서 사용하는 특수한 프로그램일 뿐이다.

그 후 오늘날 대세라고 회자되고 있는 건 일명 클라우드 컴퓨팅이다. 개인용 컴퓨터가 무진장 작아지고 통신 인프라가 발달한 덕분에, 예전처럼 부족한 자원을 공유하려고 컴퓨터들을 연결하는 게 아니라 진짜 유비쿼터스 세상이 돼서 컴퓨터들을 연결한다. PC 통신 시절에만 해도 하이텔 단말기가 있었는데 오늘날의 스마트폰에 비하면 얼마나 격세지감인가!

전세계 컴퓨터가 다 인터넷에 연결되고 클라이언트와 서버의 구분이 무의미해지고, 궁극적으로는 (거의) 모든 작업이 웹 프로그램만으로 해결되고 모든 자료가 웹에 저장되는 세상이 온다. 예전에는 PC끼리 자료 전송을 위해서 플로피 디스켓이나 USB 메모리를 썼는데, 이제는 사용자의 로컬 컴퓨터나 스마트폰 그 자체가 플로피 디스켓이나 USB 메모리와 마찬가지가 된다는 뜻.

이걸 역시 자동차에다 비유하자면 이렇다. 사람이 직접 자가운전을 하니까 교통사고가 발생하고 도로가 막히고 여러 문제가 생기다 보니, 전세계 도로가 한데 통제되고 지능형 임대 자가용이나 궤도 교통수단이 생겨서 모든 사람들이 그걸 간단히 이용하는 형태가 된 셈이다.
물론 이게 온전히 실현되려면 시스템적으로나, 보안 쪽으로나 해결해야 할 문제가 많다.

Posted by 사무엘

* 옛날에 썼던 이 글과 연계되는 내용이다.

비주얼 스튜디오 2010을 드디어 회사에 깔아 봤다. 극심한 뒷-_-북.
인터넷 익스플로러 9만 보고도 “세상에 MS가 이런 UI의 프로그램도 만들다니, 오래 살고 볼 일이다”란 생각을 한 적이 있는데, VS 2010도 과연 그러하다.
개인적으로 시커먼 남색 배색이 별로 마음에 들지는 않다만..;;. 어째 이런 비주얼을 만들 생각을 했을까 싶다.

듣던 대로 IDE의 GUI 껍데기는 밑바닥부터 완전히 바뀌어서 다시 작성되었다.
닷넷 200x 시절은 비록 비주얼은 살짝 다를지언정 그래도 MS 오피스 엔진의 흔적이 남아 있었고 닷넷 초창기 버전인 2002/2003은 아예 오피스 XP의 GUI를 그대로 차용했었는데, 이제 비주얼 스튜디오의 GUI는 오피스와는 전혀 관계 없는 독자적인 엔진 기반이다.
그러고 보니 비주얼 C++ 6은 MFC를 사용하여 오피스와는 관계 없는 독자적인 GUI였는데... ^^;;

윈도우 운영체제의 모든 GUI는 메뉴에서 상하 화살표를 누르고 있으면, 비록 사용 불능(disabled)이라 할지라도 모든 항목이 순서대로 순회된다. 난 이게 MS 사의 전통인가 싶었다. 운영체제의 표준 메뉴부터 시작해 MS 오피스 등 MS에서 만든 역대 제품들을 모두 살펴보기 바란다.
그러나 VS 2010의 메뉴는 불능 항목는 아예 선택되지 않고 skip된다. 이 점에서는 과거 도스용 아래아한글의 동작과 비슷해졌다.

하다못해 이런 사소한 메뉴 GUI의 동작에서부터도 본인은 MS에서 만든 프로그램 같지 않은 이질감이 곧바로 느껴졌다.
덧붙이자면 VS 2010의 메뉴는 언제나 화면이 확 펼쳐지지 Fade나 Slide 같은 애니메이션 효과가 나타나지도 않는 것 같다.

IDE의 로딩 시간과 덩치는 확실하게 크고 아름다워졌다.
단, 인텔리센스는 확실히 예전 버전보다 더 똑똑해진 게 느껴져서 편하다. *.ncb 파일 대신 다른 방식의 인텔리센스 DB를 쓰는데, 역시 프로젝트 하나당 수십 MB씩 용량을 무지막지하게 차지하는 건 변함없다.
닷넷 시절 거의 10년 가까이 사용해 온 Document Explorer 기반 도움말(MSDN) 시스템도 갈아엎었다고 하는데 자세한 내역은 잘 모르겠다. 단, 매크로 IDE는 과거의 비주얼 스튜디오 2008 IDE를 그대로 쓰고 있음.

프로그래머용 에디터에 화면 확대/축소 기능이 생겨서, 단순히 글씨 크기만 바꿀 때는 옵션 대화상자를 꺼낼 필요가 없게 된 건.. 상당히 참신하다. 그래도 조절을 할 수 있으니까 유용하다.
<날개셋> 편집기도 글씨 크기 조절 기능 건의가 지금까지 한두 번 들어온 게 아니니 말이다. =_= (하지만 프로그램의 구조와 개발 방향의 특성상, 실현 가능성은 제로)

뭐, IDE와 GUI 얘기는 여기까지 하고...
비주얼 스튜디오는 2005 이후에 3이 더해진 2008 버전보다도, 2가 더해진 2005나(2003에서 버전업) 2010이(2008에서 버전업) 변화 사항이 많았다.
다만, 2003과 2010은 그 해 4월에 출시되었고 2005는 그 해 말(10~11월), 그리고 2008은 아예 2007년 말에서 2008년 초에 가깝기 때문에 실제 출시 간격은 2년 반에서 큰 차이가 없다고 볼 수도 있겠다.

역사적으로 MS 제품들이 2000년대 중반에 운영체제는 XP와 비스타 사이, 오피스는 2003과 2007 사이, IE는 6과 7 사이에 간격이 굉장히 길었다. 이에 반해 비주얼 스튜디오는 그런 제품들과는 무관하게 버전업이 꾸준히 되어 온 셈이다.

과거 MSVCR71.DLL, MFC71.DLL에 이어, MSVCR100.DLL과 MFC100.DLL도 이젠 그냥 편하게 윈도우 시스템 디렉터리에 들어가 있다. 정말 감개무량하다. VS 2005와 2008이 사용하는 CRT/MFC DLL만(80, 90) 잠깐 winsxs 밑으로 숨었었는데, 그 방식이 배포하기가 너무 불편해서 다시 일반 DLL 로딩 방식으로 되돌아간 것이다.

VC 6의 유물이던 클래스 마법사가 다시 생긴 것도 신선한 충격. 굳이 MFC 기반 프로젝트가 아니어도 유용해 보인다.
하긴, 6 시절까지만 해도 클래스 마법사가 효율적으로 소스를 파싱하라고 메시지 맵에 //AFX_MSG 같은 이상한 주석 부호도 있었는데.. 그게 필요 없어진 게 닷넷부터이다.

VC 2010은 모처럼 C++ 언어 문법도 제법 확장되었으니 이것도 짚고 넘어가지 않을 수 없겠다.

auto와 nullptr은 가뭄에 단비 같은 유용한 키워드이다.
전자는 본인이 예전에도 논평했듯이, 번거로운 타이핑과 typedef를 획기적으로 줄여 준다.
그리고 후자는 숫자로 쓰이는 0과 포인터로 쓰이는 0을 확실하게 구분하여 C++ 함수의 오버로딩 때 모호성을 해소해 준다. explicit과 비슷한 맥락에서 추가되었다고도 볼 수도 있겠다.

다만, 기존 코드와의 명칭 충돌을 최대한 피하기 위해 null이나 NULL, 심지어 nil도 아닌 nullptr로 예약어가 정해졌다는 건 감안할 필요가 있음.
또한, 기왕 auto가 추가됐을 정도면 상위 클래스를 자동으로 가리키는 super 같은 키워드도 C++에 같이 좀 추가하지 하는 아쉬움이 있다. 비주얼 C++은 MS 확장 차원에서 __super가 있긴 한데 말이다.

문득 드는 생각인데, 순수 가상 함수를 선언할 때 쓰이는 0은 숫자에 가까울까, 포인터에 가까울까?
숫자의 성격이 강하다면 0 대신 false를 써도 되겠고, 포인터의 성격이 강하다면 0 대신 nullptr을 쓰면 되겠다. 하긴, true와 false는 진작부터 C++ 예약어로 추가됐는데 말이다. 이제 C++에는 0을 의미하는 키워드가 둘 존재하게 됐다.

뭐, 요약하자면, 덩치가 딥다 커졌는데, 커진 만큼 덩치값 하는 편의 기능도 많고 기능면에서 바뀌고 향상된 것도 많다. 다만, 비주얼은 내 눈에는 여전히 좀 이질적임. ㅋㅋ
간단하게 VC 2010으로 <날개셋> 한글 입력기 프로젝트를 빌드도 해 봤다. 개발용으로는 2010으로 언제쯤 완전히 갈아탈지는 미지수이다.

<날개셋> 한글 입력기는 1.x부터 2.4까지는 VC 6.0을 썼고, 2.5부터 5.3x까지는 6년 동안 VC 2003을 썼다. 그러다가 5.5부터는 지금까지 약 2년간 VC 2008을 쓰는 중. 2005는 64비트 에디션을 빌드할 때만 잠깐 쓰다가 이마저도 2008로 곧 대체됐다. ^^;;

난 개인적으로 비주얼 C++에 대해 실현 가능성이 별로 없는 두 가지 희망 사항이 있다.

첫째, MFC나 플랫폼 SDK 같은 공통 프로그래밍 요소들의 인텔리센스 정보들은, 매번 번거롭게 각 프로젝트별로 중첩해서 들어가는 게 아니라 이미 만들어져 있는 걸 공유할 수 있으면 좋겠다. 이것만 해도 인텔리센스 파일 크기가 엄청나게 줄어들 것이다. -_-;;

그리고 둘째, 운영체제의 legacy known DLL인 msvcrt.dll과 mfc42.dll에다가 바로 링크하는 기능도 좀 있으면 좋겠다. 런타임 dll을 배포하지 않고, static link 하지 않고도 작은 바이너리 배포를 할 수 있게 말이다.

덩치가 커지는 것 자체가 문제가 아니라, '불필요하게' 덩치가 그것도 꽤 부담될 정도로 커지는 게 문제이다. I hate bloatwares. -_-

Posted by 사무엘

윈도우 운영체제가 제공하는 파일 목록 탐색 API로는 FindFirstFile, FindNextFile가 있다.
사실, 도스 시절에도 C언어에는 내부적으로 도스 API를 사용하는 _findfirst, _findnext 같은 함수가 있었는데, 윈도우 API 역시 그 인터페이스를 거의 그대로 차용했다.

파일을 탐색하는 동작은 state가 존재하는 costly한 작업이기 때문에, 파일을 여닫는 것처럼 핸들을 주고받는 과정이 수반되며, 탐색이 끝나고 나면 그 핸들을 반드시 닫아 줘야 한다.
state가 존재하는 덕분에, 파일 탐색을 하는 도중에 다른 디렉터리에 대해 다른 파일 탐색 작업을 시작할 수도 있다. 이게 가능해야 재귀적으로 하위 디렉터리 다단계 탐색을 할 수 있을 것이다. 참고로 C 표준 함수 중 strtok 함수는, state가 존재함에도 불구하고 state 핸들값을 별도로 받지 않아서 디자인상 문제가 있는 함수라고 까였음..

본인은 운영체제가 제공하는 파일 탐색 함수의 인터페이스에 대해 다음과 같은 불만이 있다.
먼저, 파일 탐색 동작을 식별하는 핸들값 HANDLE과, 파일이 계속 존재하는지를 판단하는 BOOL값을 따로 관리해야 한다는 것이다. FindFirstFile은 HANDLE을 되돌리고, FindNextFile은 BOOL을 되돌린다. 그래서 이들을 가지고 for문이라도 만들려면 두 변수를 모두 갖고 있어야 한다. (말만으로는 실감이 잘 안 갈 테니, 관심 있으신 분은 파일 탐색 루틴을 직접 짜 보기 바란다.)

MFC의 CFileFind는 기존 API 함수를 거의 그대로 캡슐화했지만 다행히 FindFirstFile에 해당하는 FindFile 함수도 동일하게 FindNextFile과 마찬가지로 BOOL을 되돌려서 그나마 낫다.
또한 소멸자는 자동으로 FindClose를 호출해 주며, 지금 찾은 파일에 대한 정보를 별도의 GetFilePath 같은 멤버 함수를 통해 얻어 올 수 있다. 그래서 아래와 같은 형태로 loop을 작성하면 된다.

CFileFind fnd; BOOL b;
for(b=fnd.FindFile(L"*.txt"); b; b=fnd.FindNextFile())
  Use(fnd.GetFilePath());

본인은 한술 더 떠서 이렇게 독자적으로 만든 클래스를 즐겨 사용한다. 생성자와 소멸자를 빼면 다들 연산자 오버로딩이다.

class CMyFileFind {
public:
  CMyFileFind(PCTSTR pszFile);
  ~CMyFileFind();
  const WIN32_FIND_DATA *operator ->() const;
  operator bool() const;
  void operator++(int);
};

for(CMyFileFind fnd(L"*.txt"); fnd; fnd++)
  Use(fnd->cFileName);

짠~
파일 탐색을 생성자에서 바로 시작할 수 있고, WIN32_FIND_DATA에 파일 정보가 존재하는지의 여부를 bool 형변환 연산자가 바로 알려준다. 그리고 ++ 연산자가 다음 파일 탐색을 의미하며, -> 연산자를 통해 찾은 파일 정보를 곧바로 얻을 수 있다. 깔끔하지 않은가? ㄲㄲ

개인적으로, FindNextFile 함수는 더 발견된 파일이 없는 경우 주어진 찾기 핸들을 자동으로 close해 버리는 기능도 있으면 좋겠다.
파일 탐색 기능에 앞으로 되돌아가는 기능이 있는 것도 아닌데(=PrevFile 같은 거라도..;;), 더 찾을 파일이 없으면 이 핸들은 닫아 버리는 것 말고 도대체 다른 용도가 있는가? 놔 둘 이유가 전혀 없다.
이렇게 되면 파일을 찾다가 중간에 멈추는 게 아닌 이상, FindClose를 번거롭게 또 호출해야 할 필요가 없어져서 좋을 것이다.

이 찾기 핸들의 자료형은 HANDLE이다. 하지만 파일이나 스레드 같은 커널 오브젝트가 아니어서 그런지, CloseHandle이 아니라 반드시 FindClose 함수로 닫아야 한다. 그리고 실패를 의미하는 값이 NULL이 아니라, 마치 CreateFile의 실패값처럼 INVALID_HANDLE_VALUE (-1)이다. 이런 인터페이스가 뒤죽박죽인 건 윈도우 API의 디자인 결함인 것 같다. memory-mapped file을 만드는 CreateFileMapping의 실패값은 또 NULL임.. -_-;;

또한, 파일과 디렉터리를 구분 없이 찾는 것도 개인적으로 무척 불만이다.
그래서 이 탐색 결과를 담고 있는 구조체에 대해서 dwFileAttributes&FILE_ATTRIBUTE_DIRECTORY 체크부터 꼭 해 줘야 한다.
또한, 이런 디자인으로 인해, 어떤 디렉터리 내부에서 파일은 *.txt 같은 와일드카드로 찾고 디렉터리는 와일드카드 없이 다 찾으려면 검색을 두 번 수행해야 한다. 디렉터리 이름은 언제나 전체 검색이지 이걸 와일드카드로 찾는 일은 오늘날 전혀에 가깝게 없기 때문이다. DIR *.txt /S 같은 걸 구현하는 걸 생각해 보면 쉽게 이해가 될 것이다.

와일드카드를 해석하는 작업은 보통 운영체제가 알아서 해 준다. 하지만 도스와 윈도우는 전통적으로 이 알고리즘이 굉장히 단순하기 그지없어서 * 같은 경우 문자열의 뒤에만 붙일 수 있다. A*T.*P 같은 식의 패턴을 쓸 수는 없다는 뜻.
하지만 프로그래밍 언어나 런타임의 제작사에 따라서는 파일 탐색 기능을 제공하면서 와일드카드 해석은 독자적으로 하는 경우도 있다. 가령, 파이썬은 운영체제의 와일드카드 해석 루틴을 사용하지 않으며, 도스에서 구동되던 DJGPP도 디렉터리 아예 구분자로 \ 대신 유닉스처럼 /를 쓰는 등, 파일 경로 해석 자체를 독자적으로 한다.

이상 파일 탐색 관련 잡설이었다.
파일에서 뭔가 검색, 탐색을 한다고 하면 파일 내부에 있는 특정 문자열을 검색하는 것과, 파일 목록을 추출하는 것, 그리고 열어 놓은 파일 내부에서 읽거나 쓰는 지점을 이동하는 seek가 모두 가능하다.
그리고 특정 파일에 대해서 크기나 날짜 같은 부가 정보를 얻는 기능은, 열어 놓은 파일 핸들을 상대로 수행하는 것과 파일을 열지 않고 수행하는 것이라는 두 양상으로 나뉜다는 특징이 있다.

Posted by 사무엘

예전에 본인이 글로 쓴 적도 있고, 상식 차원에서 이미 아시는 분도 있겠지만..
프로그래밍 언어마다 문자열을 다루는 방식엔 차이가 존재한다.
C/C++은 null-terminated 문자열이라는 단순하고 독특한 체계를 사용하는 반면, 다른 언어들은 그렇지 않다.
그렇기 때문에, 문자열 상수가 실행 파일 내부에 어떤 형태로 박혀 있는지를 추적하면, 이 프로그램이 무슨 언어로 만들어졌겠는지 추측이 어느 정도 가능하다.

과거의 도스 시절에는 볼랜드 사에서 개발한 터보 시리즈의 컴파일러가 인기가 많았다. C/C++과 파스칼이 기억에 남는다. 이 볼랜드 제품은 당시 타사의 컴파일러가 제공하지 않던 두 가지 독자적인 기능이 있었다. 하나는 깔끔하게 잘 만들어진 IDE(에디터)였고, 다른 하나는 BGI(볼랜드 그래픽 인터페이스)라고 일컬어지는 그래픽 API였다.

한 IDE에서 프로그램을 바로 빌드-실행-디버그할 수 있으니 프로그램 개발 생산성이 뛰어나고 굉장히 편리하다. 이에 덧붙여, 그래픽은 그렇잖아도 printf 같은 표준화된 API 규격이 전무해서 ‘싸제’ 라이브러리에 의존할 수밖에 없던 영역인데, 자체 개발 라이브러리가 있다 보니 볼랜드의 컴파일러는 폭발적인 인기를 모을 수밖에 없었다.
bgidemo라고 유명한 그래픽 API 예제 프로그램도 있었는데 기억하는 분이 있으려나 모르겠다. QBasic용 예제 프로그램인 nibbles, gorilla 게임과 비슷한 시기에 만들어진 그 시절 추억이다.

아래의 스크린샷은 이 BGI 라이브러리를 사용해서(=링크해서) 만들어진 어느 EXE 파일 내부를 들여다본 모습이다. 그래픽 라이브러리이다 보니 내부적으로 출력하는 에러 메시지 문자열, 가령 No error, (BGI) graphics not installed, 심지어 Out of memory in flood fill 같은 친숙한 문자열이 내장되어 있음을 알 수 있다. 그런데 동일한 문자열들 사이에 한 놈은 ▲, →, ← 같은 이상한 기호가 듬성듬성 끼어 들어가 있다. 왜 그럴까?

기호가 없는 프로그램은 C언어(=터보 C)로 만들어진 프로그램이다. 왼쪽의 16진수값을 보면 알겠지만, 이들은 모든 문자열들이 그냥 0번 문자로 구분되어 있다.
그러나 기호가 있는 프로그램은 파스칼로 만들어진 프로그램이다. ▲, →, ←은 다음에 뒤따르는 문자열의 길이를 의미한다. 예를 들어 “▲Graphics hardware not detected”를 보면 ▲의 코드 번호는 0x1E, 즉 30인데 그 에러 메시지의 길이는 30바이트임을 알 수 있다. 얘네는 반대로 문자열들 사이에 0번 문자가 전혀 존재하지 않는다.

실제로 C/C++ 말고 String이 built-in type으로 존재하는 언어들은 이렇게 글자 수를 따로 저장해 놓는 방식으로 문자열들을 관리한다. 베이직으로 만들어진 프로그램도 QuickBasic이든 PowerBasic이든 문자열 상수들을 들여다보면 비슷한 결과를 얻을 수 있다. 그래서 이런 언어는 문자열의 길이를 구하는 함수의 시간 복잡도가 O(1)인 반면, C언어만 strlen의 시간 복잡도는 O(n)이다.

베이직 언어들은 문자열의 길이가 16비트 정수로 저장되던 반면, 터보 파스칼은 문자열 길이를 달랑 8비트 크기로 저장하여, 문자열의 길이가 256자를 넘을 수 없다는 한계가 존재했다. 흠;;

파스칼로 만든 프로그램을 들여다보면 Runtime error 같은 문자열도 존재한다. 이 역시 C/C++로 만들어진 프로그램에서는 디버그 빌드가 아닌 이상 있을 수 없는 개념이다. C/C++은 배열 첨자 범위의 검사조차도 안 할 정도로 런타임 에러라는 개념 자체가 존재하지 않는-_- 언어이기 때문이다. 그저 컴퓨터 다운(도스 시절)이 아니면 segmentation/page fault(요즘 같은 보호 모드 운영체제에서)-_-만이 존재할 뿐. -_-;;

그 반면, %d, %s이라든가 Null pointer assignment 같은 문자열이 있다면 그건 99.9% C 라이브러리가 들어갔다는 뜻이고 그 프로그램은 C/C++로 작성되었다고 유추할 수 있다.

덧붙이는 말

1. 볼랜드는 BGI 라이브러리만큼이나 텍스트 모드용 GUI? TUI? 툴킷으로 Turbo Vision이라는 라이브러리를 개발한 것으로도 유명했다. MS가 도스용 비주얼 베이직을 잠시나마 개발했다면 볼랜드에는 이런 게 있었던 셈. 당장 터보 C++과 파스칼의 IDE부터가 이를 사용해서 개발되기 시작했다. 비록 C/C++과 파스칼에서 모두 지원되긴 했지만 이 언어의 주 개발 및 지원 언어는 파스칼이었지 싶다. MS가 베이직을 좋아한다면, 볼랜드는 전통적으로 파스칼을 더 좋아하는 회사였다. (그러니까 훗날 델파이까지 만들었지)

지금은 세월이 세월이다 보니 소스가 완전히 풀려서 이이 프로젝트는 오픈소스 진영에서 관리되고 있다. 내 기억이 맞다면 DJGPP의 IDE인 Rhide가 이 Turbo Vision의 오픈소스 버전으로 개발되었다.
그리고 우리나라에서 PC 경진대회가 정보 올림피아드로 최초로 바뀌었던 1996년(13회), 대회의 채점 프로그램이 Turbo Vision 기반으로 개발되어 있던 걸 본인은 분명히 봤다.

2. 오늘날 윈도우용 네이티브 EXE/DLL이 만들어지는 출처는, 내 감으로는 비주얼 C++이 적게 잡아도 70% 이상, 그 뒤에 소수의 오픈소스 프로젝트용으로 gcc, 그리고 끝으로 델파이 정도가 고작인 것 같다. 볼랜드는 그 후로 다른 회사에 인수되면서 이름도 여러 번 바뀌고(InPrise, CodeGear, Embarcadero 등...;;) 우여곡절을 많이 겪었는데 걔네 입장에서는 옛날의 영광이 그리울 법도 할 것 같다.

3. BGI 라이브러리와 파워베이직--얘 역시 전신이 볼랜드 사의 터보 베이직이긴 했지만--의 그래픽 라이브러리는 이상하게도 VGA mode 13h를 지원하지 않아서 개인적으로 아쉬웠었다. (퀵베이직은 지원했는데...) 해상도가 너무 낮아서 한글· 한자 같은 문자를 찍는 데는 부적격이었지만 256색 덕분에 게임 만들 때는 필수이던 그래픽 모드이다. 그게 지원됐으면 그 당시 게임 만들기가 훨씬 더 수월했을 텐데 말이다.

Posted by 사무엘

어지간한 중급 이상 수준의 기능을 갖춘 텍스트 에디터나 워드 프로세서들은 일명 ‘칼럼 블록’ 기능을 제공한다. 아래아한글은 도스 시절부터 ‘구역’이라고 하여 동일 기능을 제공했으며, 단축키는 F4였다. 일반 블록의 단축키는 F3이고 말이다. 마우스로는 그냥 드래그는 일반 블록이고 Alt+드래그가 칼럼 블록으로 통용되고 있다. 칼럼 블록을 만드는 키보드 단축키가 통일되어 있는지는 잘 모르겠다.

칼럼 블록이 일반 블록의 복붙 동작과는 어떤 차이가 있으며 얼마나 유용한지 일일이 구차하게 설명하지는 않겠다. 칼럼 블록은 불연속적인 여러 줄들의 일부를 통째로 선택할 수 있을 뿐만 아니라, 붙이는 동작도 여러 줄에다가 내용을 끼워 넣는 식으로 달라진다. <날개셋> 편집기는 전문적인 에디터를 표방하면서 개발되고 있지는 않기 때문에, 현재 (아쉽게도) 칼럼 블록을 지원하지는 않는다.

그런데 칼럼 블록을 구현할 때 현실적으로 부딪히는 문제가 있다. ‘붙이기’를 할 때 클립보드의 내용이 일반 블록인지 아니면 칼럼 블록인지를 어떻게 판별할 거냐는 것이다.
제일 간단한 방법은 응용 프로그램이 별도의 플래그를 갖고 있는 것이다. 클립보드에다가는 일반 블록처럼 텍스트만 복사해 놓으나, 이 블록이 칼럼 블록이라면 플래그를 켠다. 그래서 붙이기를 할 때 플래그가 켜져 있으면 칼럼 형태로 붙인다.

윈도우 탐색기가 파일을 클립보드에다 복사(Copy)한 것인지 오린(Cut) 것인지 판별할 때도 내부적으로 이런 자체 플래그를 쓴다. 파일은 오려 놓는다고 해서 실제로 파일을 지워 버릴 수는 없으므로, 자체적인 표식밖에는 구분할 방법이 없으니 말이다. 파일의 오리기는 텍스트의 오리기와 다르다. 더 나아가면, 엑셀 같은 스프레드 시트의 오리기도 마찬가지임.

하지만 이 방법을 쓸 경우, 칼럼 블록을 복사해 놓고는 다른 응용 프로그램에서 텍스트를 또 복사했을 때, 그 텍스트도 칼럼 형태로 붙여진다는 문제가 있다. 국산 에디터인 AcroEdit, 그리고 유명한 개발 IDE인 Source Insight가 칼럼 블록을 이런 식으로 구현했고 저런 동작을 보이는 것을 확인했다.
내부 플래그 방식으로 칼럼 블록을 구현했다면, 클립보드 내용이 외부에서 바뀌었을 때 내부 칼럼 플래그를 끄는 기능도 구현해야 할 것이다.

이런 방식 말고, 클립보드 차원에서 아예 자신만이 인식 가능한 별도의 포맷을 등록하는 방법도 있다. 칼럼 블록은 그 포맷으로 복사한 후, 붙이기를 할 때 그 지정 포맷이 존재하면 일반 형식이 아닌 칼럼 형식으로 붙여 넣는 것이다.
물론, 칼럼 블록을 복사하더라도, 다른 프로그램이 내용을 일반 블록 형태로 붙여넣을 수도 있게 일반 텍스트 형식으로도 복사는 해 놓는다.

국산 에디터인 EditPlus, 그리고 MS 비주얼 스튜디오 IDE는 이렇게 칼럼 블록은 별도의 클립보드 포맷을 써서 복사해 놓는 것을 확인했다. 이렇게 하면 칼럼 블록을 오로지 자기 프로그램에서 생성한 클립보드 데이터를 통해서만 인식할 수 있기 때문에 앞서 언급했던 오동작이 발생할 여지가 없다.

EditPlus의 식별자는 “EditPlus Column Selection”이요,
비주얼 스튜디오의 식별자는 “MSDEVColumnSelect”이다. 다른 프로그램들은 어떨지 모르겠다.
워드 프로세서들은 어차피 자기네 고유 포맷을 쓰는 게 관행이기 때문에 칼럼 블록만을 위한 고유 포맷을 만들지는 않는 듯하다. (아래아한글과 MS 워드의 경우)

개인적은 생각은, CF_TEXT 같은 것처럼 칼럼 블록을 위한 텍스트도 운영체제 차원에서 표준 클립보드 포맷을 도입하면 좋지 않을까 싶다. 내부적으로 전세계의 수많은 텍스트 에디터들이 자신만의 고유 포맷으로 칼럼 블록을 표현하고 있을지 알 수 없는 노릇이기 때문이다. 그게 제정되면 칼럼 블록도 에디터들마다 공유가 가능할 것이다.

Posted by 사무엘

아래 코드를 실행하면 놀랍게도..
입력된 숫자에 대한 팩토리얼 값이 출력된다. 단, 플랫폼은 x86 한정으로..;;
(뭐, 컴퓨터가 돌아가는 원리를 아는 사람이라거나 맨날 기계어 코드 들여다보는 게 직업인 사람이라면 전혀 새삼스러운 일이 아니겠지만)

비주얼 C++뿐만이 아니라 도스용 DJGPP로도 프로그램이 잘 동작하는 걸 확인했다. 둘 다 IA32 아키텍처인 건 동일하니까 이는 당연한 귀결.

int main(int argc, char* argv[])
{
 BYTE instrs[]={
  0x55,
  0x8B,0xEC,
  0x83,0xEC,0x08,
  0xC7,0x45,0xFC,0x01,0x00,0x00,0x00,
  0x8B,0x45,0xFC,
  0x89,0x45,0xF8,
  0xEB,0x09,
  0x8B,0x4D,0xF8,
  0x83,0xC1,0x01,
  0x89,0x4D,0xF8,
  0x8B,0x55,0xF8,
  0x3B,0x55,0x08,
  0x7F,0x0C,
  0x8B,0x45,0xFC,
  0x0F,0xAF,0x45,0xF8,
  0x89,0x45,0xFC,
  0xEB,0xE3,
  0x8B,0x45,0xFC,
  0x8B,0xE5,
  0x5D,
  0xC3
 };

 PVOID pv = instrs;
 int (*pfn)(int) = reinterpret_cast<int (*)(int)>(pv), y;
 while(1) {
  printf("? "); scanf("%d", &y); if(y<1) break;
  printf("%d\n", pfn(y));
 }
 return 0;
}

프로그래밍 언어의 인터프리터 내지 just-in-time 컴파일러를 만든다거나,
가상 기계 에뮬레이터를 만드는 것은 어렵지 않다.
결국 핵심이 뭐냐 하면 컴퓨터가 직통으로 실행하는 코드 자체를 실행 시간에 메모리에다 생성하는 건데,
함수 포인터가 가리키고 있는 게 바로 저런 것들이다.

물론, 위에서처럼 실행해야 할 코드가 완전히 고정돼 있는 경우라면
소스 코드에다 인라인 어셈블리를 집어넣으면 되겠지만, 그 코드는 데이터 영역에 들어가는 게 아니라 소스 코드(text) 영역에 그대로 포함되어 버리게 될 것이다.

위의 팩토리얼 함수는 물론 컴파일러가 생성해 준 코드를 복사한 것이다.
최적화를 안 한지라, 간단한 for 루프 하나밖에 없는 함수가 코드 길이가 꽤 길다.
최적화를 하고 나면 정상적인 함수 입출력 껍데기에 해당하는 코드조차도 거추장스러운지 생성되지 않아서
그걸 저렇게 따로 떼어내서 쓸 수가 없었다.

Posted by 사무엘

1. 닷넷 기반 프로그램의 특징:

- 뜨는 데 시간이 좀 오래 걸린다.
- 파일 내부를 들여다보면 전통적인 네이티브 프로그램처럼 kernel32, user32, gdi32 따위가 아니라, mscoree.dll에 대한 Dependency만 있다.
- 생성하는 GUI 윈도우들의 클래스를 보면 WindowsForm10 이런 명칭으로 시작한다.
- 같이 들어있는 DLL들이 '뭐.뭐' 이런 식으로 대소문자가 섞이고 중간에 마침표도 있는 등, 이례적으로 이름이 긴 경향이 있다. 네이티브 EXE/DLL은 그런 식으로 작명되는 경우가, 금지되거나 불가능한 건 절대 아님에도 불구하고, 거의 없다. 유닉스 내지 심지어 도스 시절 8.3 영향을 받은 짧고 암호 같은 영어 알파벳 조합이 아직까지 대세.

유명한 닷넷 프로그램으로는 MS Keyboard Layout Creator, Paint .NET이 있다. 비록 닷넷 기반으로 비주얼 베이직.NET과 C++ managed extension 같은 언어도 있긴 하지만, 그래도 90%이상의 여건에서는 닷넷이 곧 C#이나 마찬가지이다.

게임 자체는 모르겠지만, 최소한 게임과 관련된 툴 정도는 C#으로 만드는 게 충분히 승산이 있는 단계에 이른 것 같다. 스타크래프트의 StarEdit처럼 고객이 사용하는 툴이든, 게임 개발사 내부에서 디자이너나 기획자가 쓰는 툴이든 말이다. C#은 일종의 가상 기계 프레임워크 기반이면서도 로컬 환경 역시 적당하게 잘 공략한 것 같다. 이제 MFC는 덩치가 커져도 너무 커졌고, C#은 빌드 속도 같은 생산성 면에서 C++을 압도적으로 능가한다.

게임 클라이언트에 이어 게임 서버까지 C#으로 만들어 돌리는 날이 과연 올지는 모르겠다. 컴퓨터의 성능이 계속 향상되니까 괜찮을 거라는 말이 있지만, 그래도 과거에 C/C++은 어셈블리와 일대일 대응하는 최소한 네이티브 코드 생성 언어이지 않았던가.
다만, 아직은 C# 프로그램이 네이티브에 비해 느린 건 둘째치고라도, 앞서 말했듯이 좀 무겁다는 인상이 짙게 느껴진다. (뜨는 데 걸리는 시간) 이게 좀 개선됐으면 좋겠다. 듣자하니, MS는 내부적으로는 C# 코드를 산뜻한 네이티브 코드로 빌드해 주는 컴파일러를 보유하고 있다는데..;;

2.
본인, 전공이 전공이다 보니 소위 '국어 정보 처리' 분야의 프로그램들을 좀 접했다. 형태소 분석, 말뭉치 검색 등.
비주얼 C++ + MFC로 만들어진 게 다수이지만 2005년 이후부터는 C#을 쓴 것도 심심찮게 보인다. 다만, '깜짝새'라고 유명한 프로그램이 있는데, 얘는 이례적으로 델파이로 개발됐다.

이런 프로그램들은 그 특성상, 결과 데이터를 마치 스프레드 시트처럼 row-column 형태의 출력하는 경우가 많다. 그런데 순수하게 처리를 하는 비용뿐만이 아니라, 처리가 끝난 결과 데이터를 해당 리스트 컨트롤에다 등록하는 데 걸리는 시간도 만만찮아서 본인은 그게 불만이다. 결과 출력하느라 리스트 컨트롤의 스크롤바가 쫘르륵~~ 변하는 모습을 보고 있으면 좀 민망하다. 불필요한 화면 refresh가 수천, 수만 회 발생하고 있다는 뜻이지 않은가?

대용량의 데이터를 그런 형태로 출력할 때는, owner-draw라든가 virtual list control 테크닉을 써서, 결과 데이터를 일일이 리스트 컨트롤로 복사하는 게 아니라, 그때 그때 출력을 내가 직접 하도록 해야 한다. 이렇게만 하면 프로그램의 체감 동작 속도가 월등히 빨라지며 메모리도 크게 아낄 수 있다.
도스 시절이었다면 리스트 컨트롤 같은 컴포넌트라는 개념 자체가 없었을 터이니 이런 비효율 자체가 존재할 여지가 없었을 것이다. 물론, 소프트웨어의 재활용성면에서 도스는 어차피 빵점인 열악한 환경이니 도스 시절이 마냥 좋다는 건 아니다.

저런 프로그램들이 어떤 여건 속에서 개발되었는지 잘은 모르겠다. 허나, 열악한 자금과 시간에 쫓기면서 공밀레 공밀레 하면서 만들어진 프로그램이라면, 개발자가 아무리 날고 기는 천재 프로그래머라고 해도 답이 없다. 품질을 보증할 수 없고, 이런 자그마한 곳에서의 사용자 배려 따위는 절대로 기대할 수 없다. 이는 개인의 프로그래밍 실력과는 하등 관계 없는 문제이다.

그 반면에 <날개셋> 한글 입력기가 가히 변태적인 수준의 최적화를 자랑하며 개발되고 있는 이유는 시간과 돈에 전혀 구애받지 않고 전적으로 개인의 자아 실현을 위해 만들어지는 프로그램이기 때문이다. -_-;; 언제까지나 그런 태도로 프로그램을 만들 수는 없으니까 그게 문제지만.
이런 문제를 이쪽에 계시는 교수님들도 인지는 하고 있지만, 우리나라 IT 인프라에 전반적으로 딱히 답이 안 보이는 문제이니 어쩔 수 없다.

3.
C/C++ 부류의 type 시스템은 액세스(MS Access)와 비슷하고,
파이썬 부류의 type 시스템은 엑셀(MS Excel)과 비슷하다. 진짜 딱 대응하는 것 같다.

스프레드 시트인 엑셀은 아무 셀에 아무 타입의 데이터나 바로 집어넣을 수 있으며, 그러면 그 형태를 엑셀이 알아서 인식해서 출력해 준다. 날짜는 날짜처럼, 문자열은 문자열처럼, 숫자는 숫자처럼 오른쪽 정렬을 해서.
그러나 데이터베이스 프로그램인 엑세스는 테이블을 설계할 때 모든 애트리뷰트와 각 애트리뷰트에 들어갈 수 있는 값의 타입을 지정해야 하며, 딱 그 값만 넣을 수 있다. 문자열은 길이 제한까지도 생각해야 한다. 정말 딱딱하고 까다롭다.

엑셀은 셀의 값들에 서식도 자유롭게 지정할 수 있고 Undo도 얼마든지 가능하다. 엑세스는 그런 게 없으며, 테이블을 수정한 게 파일에도 바로 반영된다.

그러나 수십, 수백만 개에 달하는 데이터를 검색하고 한꺼번에 고치고, 테이블 간의 관계를 분석하는 동작에서 엑셀과 엑세스의 효율은...;; 더 설명이 필요하지 않을 것이다.

그럼에도 불구하고 엑세스 급의 전문적인 성능이 필요한 경우는 매우 드물다. 일반 사용자들은 어지간한 중소 규모의 데이터나 다룰 것이고 이때는 친근한 엑셀이 대부분의 경우 훨씬 더 도움이 될 것이다.

4.
PC 파워 유저라면, 윈도우용 EXE 파일에는 리소스라는 별도의 데이터 섹션이 있다는 걸 알 것이다. 윈도우용 EXE는 이례적으로 자체 아이콘을 갖춘 파일 포맷인데, 그것도 바로 리소스라는 형태로 들어있다. 운영체제는 EXE/DLL의 리소스를 조작하는 API를 제공하며, 이를 이용하면 프로그램의 메뉴, 메시지 문자열을 고쳐서 허접하게나마 프로그램을 한글화(자국어화)할 수도 있다. 물론, 모든 프로그램에 그런 테크닉이 통하는 건 아니지만.

이 일을 프로그래밍을 통해서 하려면 BeginUpdateResource, UpdateResource, EndUpdateResource라는 함수를 쓰면 된다. 다만, 윈도우 9x는 이 기능을 지원하지 않았으며 그건 NT에서만 지원됐다. 그런 기능을 어차피 일반 사용자가 쓸 일은 없었을 테니까.
그런데 신기하게도 그 당시 윈도우 9x에서 실행된 비주얼 C++ 6은, 32비트 EXE/DLL의 리소스를 고칠 수는 없었던 반면, 16비트 EXE/DLL의 리소스를 고쳐서 저장할 수는 있었다.

윈도우 API를 쓴 건지, 아니면 16비트 바이너리는 비주얼 C++의 자체 기능으로 파일을 건드렸는지는 잘 모르겠다. 다만, 16비트 바이너리와 32비트 바이너리는 리소스를 저장하는 방식이 상당히 다르기 때문에 아마 자체 기능이 아니었겠나 싶다. 근본적으로 32비트 바이너리는 wide character 유니코드를 사용하지만 16비트 바이너리는 그렇지 않다. 그래서 과거에 윈도우 3.1에다가 Win32s를 설치하면 각종 시스템 DLL뿐만이 아니라 유니코드 변환 테이블인 NLS 파일들도 잔뜩 설치됐던 것이다.

Posted by 사무엘

오늘날, 어떤 데이터(개념상 Document라고 불리는)를 메모리에 완전히 읽어들여서 사용자가 그 데이터를 편집할 수 있는 업무용 프로그램에는... 거의 필수로 undo 기능이 있다.
이건 우리가 잘 실감을 못 해서 그렇지 사용자에게 심리적으로 굉장한 안정감을 주는 편리한 기능이다. 뭘 잘못해서 망쳐 놓더라도, '미리 저장 -> 지금 문서를 저장 안 하고 예전 문서를 다시 불러오기' 같은 뻘짓을 안 해도 Ctrl+Z만 누르면 만사 OK.

소프트웨어 GUI 가이드라인 교과서를 보면, 소프트웨어는 사용자에게 '용서'(forgiveness)라는 덕목을 발휘해야 한다는 말이 나온다. 사용자가 아무리 바보짓을 하더라도 이를 최대한 추스리고 수습하고 원상복귀 할 수 있어야 한다는 뜻.
컴퓨터 프로그램은 기독교의 하나님 같은 존재가 아니다. “자유 의지가 있으니, 하늘나라든 지옥이든 선택에 따른 책임도 전적으로 네 몫이다” 주의가 아니다. 그러니 인간의 삶에도 Undo가 있으면 참 좋을 텐데 현실은 그렇지 못하니 참으로 안습이다. 오히려 '말은 하고 못 줍는다', '엎질러진 물', '소 잃고 외양간 고친다' 같은 냉정한 속담만이 있을 뿐이다.

잡설이 길어졌다만,
역사적으로 Undo라는 개념이 허접하게나마 가장 일찍부터 존재한 분야는 그래픽 프로그램이었다.
걔네들은 원래부터 문화가 좀 독특해서 마우스의 비중이 매우 높으며, 우클릭이 Context menu의 의미로 쓰이지도 않을 정도이다.
그리고 근본적으로 마우스라는 게 키보드보다 실수를 훨씬 더 하기 쉬운 입력 장비이고, 한 번의 동작으로 수백· 수천 개의 픽셀이 한꺼번이 바뀔 수 있기 때문에 Undo가 없으면 안 된다.

문득 든 생각: 그래픽 프로그램을 이용해서 마우스로 Freehand drawing을 하는 도중에 bksp 키를 누르면.. 직전의 수 픽셀 단위로 곡선을 철회하는 기능이 있으면 좋을 것 같다. 정교한 도트 노가다 할 때 유용할 것 같다. 보통 Ctrl+Z 누르면 그렸던 선 전체가 한 방에 날아가 버리잖아?

물론 Undo라는 건 그렇게 쉽게 구현할 수 있는 기능이 아니며 메모리 오버헤드가 크다.
더구나, 과거에 Undo 기능이 있던 프로그램은 딱 한 단계밖에 취소가 되지 않았었다. Ctrl+Z를 누르면 직전 작업을 취소했다가, 다시 살렸다가 하기만을 반복할 뿐이었다. (메모장.. 정확히 말하면 윈도우 운영체제의 에디트 컨트롤도 딱 그 수준의 1단계 Undo를 지원한다.)
수십, 수백 단계의 작업을 고스란히 취소하고 취소 내역을 다시 철회(redo)까지 하는 command history 수준의 multi-level undo 기능은 1990년대까지만 해도 MS 워드 같은 소수의 상업용 대형 프로그램에서나 볼 수 있었다.

이런 프로그램은 Document의 내용을 변형하는 모든 명령들이 체계적으로 분류가 돼 있다. 그래서 편집 메뉴를 열어 보면 단순히 '실행 취소 / 재실행'이라고만 돼 있는 게 아니라 '삭제 취소 / 취소된 자동 완성 재실행'처럼, 무슨 명령이 직전에 취소되었고 무엇을 재실행할지 명령의 이름까지 메뉴에 친절하게 표시돼 있기도 한다.
그 반면, Undo/redo를 염두에 두지 않고 Document를 고치는 코드가 제멋대로 섞여 있던 프로그램에다가 어느덧 갑자기 multi-level Undo/redo 기능을 최초로 추가할 일이 생겼다면 아마 십중팔구 코드를 다 갈아엎는 대공사를 해야 할 것이다.

컴퓨터의 성능이 열악하던 도스 시절엔, Undo와 Redo가 모두 존재하는 프로그램은 매우 드물었다.
아래아한글 1.x는 좀 특이한 경우인데, 줄 끝까지 지우기· 단어 지우기 같은 몇몇 지우기 명령으로 인해 지워진 텍스트만을 1회에 한해 되살리는 Undo 기능이 있었다.
그 후 아래아한글 2.0에서 97은 그 Undo의 단계가 3회로 늘었을 뿐이었다. 내 기억이 맞다면, 이 기능은 최근 3회의 주요 지우기 단축키(메뉴에 등재되지 않은)에 의해 지워졌던 텍스트 중 하나를 골라서 커서가 있는 곳에다 삽입해 주는 기능에 불과했다. 원래 있던 위치에 되돌려 놓는 것도 아니고... -_-

Ctrl+X(오려두기)야 본문이 클립보드에 고스란히 들어가 있으니 별도의 Undo 버퍼에다 저장할 필요가 없고,
Ctrl+E(지우기)로 지워진 텍스트는 의도적으로 되살리기가 전혀 되지 않는다고 도움말에 친절하게 안내까지 돼 있었다. ^^;;
그것 말고 문서나 표 레이아웃을 잘못 건드려서 망쳤다거나 하는 더 중요한 기능에 Undo 따위는.. “Undo 뭥미? 그거 먹는겅미? 우걱우걱...”이었다. 그냥 이전 문서를 새로 불러오는 수밖에..
이런 불편한 프로그램을 옛날 사람들은 어떻게 쓰고 지냈을까?

그래서 아래아한글 2002는 256단계 undo가 지원된다고 잔뜩 광고를 하고 다녔었다. MS 제품들은 진작부터 지원한 기능인데도 말이다. 하긴, 그것 말고도 글자 크기 제한이 드디어 없어지고 글자색 제한이 없어진 것도 개인적으로 무척 마음에 들긴 했다. better late than never이다.

<날개셋> 한글 입력기의 편집기 프로그램은 1.x와 2.x 시절에는 Undo 비슷한 기능도 전혀 없었다. 3.0에 가서야 32단계의 multi-level undo가 추가되기는 했으나... 글자 하나, 한글 낱자 하나 입력되는 모든 단계가 histroy에 기록된지라 실용성이 시원찮았다.
그것이 지금의 형태로 개선되 것이 4.2 버전부터이다. 연속된 에디팅 동작뿐만이 아니라 불연속적인 에디팅 동작을 한 history로 통합하는 기능까지 추가되어, 여러 블록을 동시에 삭제한 것이나 Replace All 명령을 내린 것도 한 번에 취소가 가능해졌다.

사실 <날개셋> 편집기의 에디팅 엔진은 아직 좀 효율적이지 못한 구석이 있다. Undo/redo 명령을 내리면 그 부분이 아무리 사소하더라도 문서 전체의 레이아웃을 싹 다시 하고, 화면 전체를 새로 그린다. 그렇기 때문에 수~수십 MB짜리 텍스트를 연 뒤에 Ctrl+Z를 꾹 누르고 있기가 겁난다. 본인은 이 프로그램을 만든 사람이고 프로그램의 내부 디테일이 어떤지를 잘 알기 때문에 그러기가 더욱 꺼려진다.

2004년에 만든 3.0 이래로 그냥 brute-force 알고리즘을 그 부분만은 아직까지 최적화를 못 했다. 한글 입력 부분과 직접적인 관계가 없고, 딱히 크게 티가 나는 부분이 아니다 보니 지금까지 방치되어 온 것이다. <날개셋> 한글 입력기 6.0의 다음 버전은 이 부분을 개선하여, 이제 안심하고 Ctrl+Z를 꾹 누를 수 있는 프로그램이 될 것이다.

Undo 기능과 관련된 얘깃거리를 두 가지만 더 꺼내고 글을 맺겠다.

첫째, 예전에 한번 언급한 적이 있듯이, 프로그램들이 Undo는 거의 예외 없이 Ctrl+Z로 정착해 있는 반면 Redo는 단축키가 프로그램마다 일치하지 않는 경우가 있다. MS의 관행은 Ctrl+Y인 듯하지만 Ctrl+Shift+Z인 프로그램도 있다.
아래아한글은 도스 시절에 Ctrl+Y가 지우기 명령의 일종이기 때문에 주의해야 한다. Redo를 생각하고 눌렀다가는 Redo는커녕 텍스트를 지우면서 후폭풍으로 기존 Undo history까지 모두 날려 버리기 때문이다!

둘째, Multi-level undo를 잘 구현한 프로그램이라면, 문서의 modified 플래그 처리도 잘 되어야 한다. 무슨 말이냐 하면, 문서를 저장했다가 어딘가를 건드린 후(= modified 플래그 켜짐), Ctrl+Z를 눌러 그 작업을 철회한다면 문서는 당연히 다시 unmodified 상태로 바뀌어야 한다.
그리고 반대로, 저장한 문서에 대해서 Undo를 해서 modified 상태가 됐더라도, 그걸 다시 Redo로 철회했다면 문서는 unmodified로 되돌아가야 한다. 논리적으로 당연한 얘기이다. <날개셋> 편집기는 multi-level undo가 처음으로 지원되기 시작한 3.0 때 이거 하나는 아주 철저하게 잘 구현해 뒀다.

비주얼 C++ 에디터, 그리고 국산 에디터인 EditPlus는 이 플래그 처리가 잘 된다. MS 오피스 제품도 마찬가지.
그러나 AcroEdit는 이게 되지 않아서 불편하며, 아래아한글도 2007은 처리가 되지 않는다. WordPad 역시 지원 안 함.

Undo나 Redo 같은 Command history 기능은 문서의 modified 상태까지 예전으로 되돌리는 명령이기 때문에 문서를 건드리는(modified 플래그를 언제나 켜는) 동작보다 상위에서 돌아가야 할 텐데, 이 점을 미처 고려를 못 한 것 같다. Undo나 Redo나 문서를 고치는 기능인 건 매한가지이기 때문에 무조건 modified 상태로. ^^

Posted by 사무엘