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

1. 컴포넌트화의 필요성

전산학 중에서 소프트웨어공학이라는 것은 방대한 소프트웨어를 인간이 여전히 유지보수 가능하게 복잡도를 제어하며 설계하기, 기능과 파트별로 역할을 잘 분담시켜서 각 파트만 재사용하거나 딴 걸로 교체를 쉽게 가능하게 하기, 소프트웨어의 분량· 작업량· 품질을 정확하게 측정하고 효율적인 개발 절차를 정립하기처럼..
응용수학이나 전자공학보다는 산업공학과 가까운 측면이 있다. 단지, 얘는 유형의 제품이 아니라 무형의 코드 형태이기 때문에 여느 공산품과는 성격이 약간 다르게 취급될 뿐이다.

20세기 후반에 인공지능 연구 업계에 "AI 겨울"이 있었고 게임 업계에 "아타리 쇼크"라는 재앙이 있었던 것처럼, 프로그래밍 업계에도 "소프트웨어의 위기"라는 게 이미 1970년대에부터 있었다.

• 코딩을 너무 중구난방으로 하고 나니, 일정 규모 이상의 프로젝트에서는 도대체 유지보수가 되질 않고 그냥 처음부터 다시 새로 만드는 게 더 나을 지경이 된다.
  
• 이놈의 빌어먹을 스파게티 코드는 하는 일도 별로 없는데 쓸데없이 너무 복잡해서.. 처음에 작성했던 사람 말고는 알아먹을 수가 없고 maintainable하지가 않다.
• 소프트웨어의 개발 속도가 오히려 하드웨어의 발전 속도를 따라가지 못한다.
• 작업 기간을 줄이기 위해서 사람을 더 뽑았는데.. 웬걸, 신입들을 가르치느라 시간이 더 소요된다;;;

그래서일까..??
"무식한 goto문 사용을 자제하자"라는 구조화 프로그래밍 이후로 객체지향 프로그래밍이란 게 프로그래밍 언어와 코딩 패러다임을 완전히 정복했다. 요즘 주류 언어들 중에 '클래스', 그리고 '상속'이라는 게 없는 언어는 찾을 수 없을 것이다.;; 이게 캡슐화, 은닉, 재사용성 등 소프트웨어공학적으로 여러 바람직한 이념을 코드에다 자연스럽게 반영해 주기 때문이다.

실험적으로 시도됐던 초창기의 순수 객체지향 언어들은 유연하지만 느린 런타임 바인딩 기반의 메시지로 객체 메소드를 호출한다거나.. 심지어 정수 하나 같은 built-in type에다가도 몽땅 타입 정보 같은 걸 덧붙이며 객체지향을 구현하느라 성능 삽질이 많은 경우도 있었다.
그러나 C++은 객체지향 이념에다가 C의 저수준, 그리고 빌드타임 바인딩(경직되지만 빠른..)을 지향하는 현실 절충형 디자인 덕분에 상업적으로 굉장히 성공한 객체지향 언어로 등극했다.

2. 마소의 실험

자 그래서..
1990년대에 마소에서는 고유 브랜드인 Windows가 대히트를 치고 소프트웨어 OEM (IBM 납품..)으로 그럭저럭 먹고 살던 처지를 완전히 벗어나니.. 당장 먹고 사는 고민보다 더 본질적이고 고차원적인, 소프트웨어공학적인 고민을 시작했던 것 같다.
얘들 역시 소프트웨어를 재사용 가능한 컴포넌트 형태로 만드는 것에 관심을 많이 기울였다. 그래서 재사용을 위해 바이너리 수준의 공통 규약, 프로토콜을 만들어서 자기들의 운영체제 차원에서 밀어붙이고 홍보하기 시작했다.

이때가 마침 C에 이어 C++ 컴파일러를 개발하고 MFC라는 라이브러리도 만들고, 코딩 스타일에 본격적으로 '객체지향'이란 게 가미되기도 했던 때이다. 하지만 마소에서 추구했던 것은 단순히 언어나 개발툴 차원에서 함수나 클래스의 모음집인 라이브러리 SDK 만들고 DLL 만드는 것 이상의 수준이었다.

제일 먼저.. (1) Windows라는 이름답게, 특정 기능을 수행하는 윈도 컨트롤을 컴포넌트화한다. 리치 에디트 컨트롤을 비롯해 각종 공용 컨트롤, 웹브라우저 컨트롤 같은 것 말이다. 이 사고방식이 극대화되어 "컴포넌트를 내 폼에다가 끌어다 놓고, 프로퍼티를 설정하고 이벤트 핸들러를 구현해서 응용 프로그램을 곧바로 만든다" RAD라는 개념이 완성되었으며.. Visual Basic이라는 정말 똘끼 충만한 개발툴이 만들어지게 됐다.

도스 시절의 GWBASIC이나 QuickBasic에서 참신한 점은 그 특유의 대화식 환경이었는데, Visual Basic은 또 다른 새로운 돌풍을 일으켰다. 경쟁사인 볼랜드에서는 이런 개발 스타일을 파스칼과 C++에다가도 도입하게 됐다.

(2) 그리고 마소에서는 서로 다른 응용 프로그램에서 만든 결과물을 문서에 자유롭게 삽입할 수 있게 했다. 이름하여 OLE라는 기술이다.
가령, Windows의 워드패드는 아래아한글이나 MS Office Word에 비하면 아주 허접한 프로그램일 뿐이다. 하지만 문서 안에 그림판에서 만든 비트맵 이미지를 집어넣고, 엑셀에서 만든 차트를 집어넣을 수 있다.

별도의 수학 수식 편집기에서 만든 수식, 악보 편집기에서 만든 악보, 그리고 WordArt/글맵시 같은 프로그램으로 만든 각종 글자 꾸임 배너까지..
단순히 무식한 그림 형태로 집어넣는 게 아니라는 것이 핵심이다. 이것들은 벡터 이미지로 취급되기 때문에 크기를 키워도 화질이 깔끔하게 유지된다.

그리고 그런 출력 이미지 자체뿐만 아니라, 각 프로그램에서 취급하는 내부 원본 데이터, 즉 소스가 그대로 보존된다. 그렇기 때문에 만들었던 객체를 손쉽게 수정도 할 수 있다.
그 객체를 더블 클릭하면 프로그램 내부에서 그림판이나 악보 편집기, 수식 편집기 등이 잠시 실행돼서 객체를 수정하는 상태가 된다..;;

서로 다른 프로그램이 이런 식으로 서로 분업 협업한다니.. 신기하지 않은가? 도스 시절에는 상상도 못 한 일일 것이다.

3. 프로그래밍의 관점

그러니 Windows에서 워드처럼 뭔가 인쇄 가능한 출력물을 만드는 업무 프로그램이라면 OLE 지원은 그냥 닥치고 무조건 필수였다. 다른 OLE 프로그램의 결과물을 삽입하든(클라), 아니면 다른 프로그램에다 자기 결과물을 제공하든(서버), 혹은 둘 다 말이다. macOS나 리눅스에는 비슷한 역할을 하는 규격이나 기술이 있는지 궁금하다.

Windows 프로그래밍을 다루는 책은 고급 topic에서 OLE를 다루는 것이 관행이었다. 다만, Windows API만으로 OLE 지원을 저수준 구현하는 건 굉장히 노가다가 심하고 귀찮았다. 그래서 MFC 같은 라이브러리 내지 아예 VB 같은 상위 런타임이 이 일을 상당수 간소화해 줬었다. MFC 앱 신규 프로젝트 세팅 마법사의 경우, OLE 지원 기능의 추가 여부를 선택하는 옵션이 응당 제공되었다.

Windows라는 플랫폼의 프로그래밍에 입문하려면 창(윈도)의 스타일과 특성, 메시지 메커니즘을 알아야 할 것이고 그래픽 API라든가 셸의 구조에 대해서도 알아야 할 것이다.
그런데 그런 것뿐만 아니라 이 바닥도 완전히 독립된 별개의 프로그래밍 분야이며, 기초부터 고급까지 한데 연결된 Windows 프로그래밍의 정수라고 생각된다.

이건 제일 간단하게는 확장자 연결이나 클립보드, drag & drop 구현과도 연결고리가 있다. 이 분야 API를 제공하다 보니 COM이라는 IUnknown이 어떻고 type library가 어떻고 하는 규격이 제정되었다.
사실, Windows에 레지스트리라는 것도 맨 처음엔 확장자 연결이나 OLE 클라/서버 정보만 저장하기 위해서 만들어졌다가.. 나중에 ini를 대체하는 응용 프로그램 설정 저장 DB로 용도가 확장된 것이다.

COM 형태로 제공되는 운영체제 기능을 사용하려면 CoCreateInstance를 호출해야 하고, 이런 프로그램은 처음에 CoInitialize라는 함수를 호출해 줘야 한다. 즉, 운영체제를 상대로도 별도의 초기화가 필요하다는 것이다.
그런데 OLE 기능을 사용하려면 OleInitialize라는 함수를 사용하게 돼 있는데, 얘가 하는 일은 CoInitialize의 상위 호환이다. OLE가 COM의 형태로 구현돼 있기 때문에 그렇다. 둘의 관계가 이러하다.

굳이 OLE 관련 기능뿐만 아니라 가까이에는 DirectX, 그리고 날개셋 한글 입력기와도 관계가 있는 TSF 문자 입력 인터페이스도 다 COM 기반이다. 하지만 문자 입력은 굳이 COM이나 OLE 따위 기능을 사용하지 않는 프로그램에서도 관련 기능을 접근할 수 있어야 하기 때문에 COM 초기화 없이 관련 인터페이스들을 바로 생성해 주는 함수를 별도로 제공하는 편이다.

4. ActiveX

과거에 인터넷 환경에서 마소 IE 브라우저의 지저분한 독점과 비표준 ActiveX는 정말 악명 높았다. 그런데 ActiveX라는 건 도대체 무슨 물건인 걸까??

마소에서는 앞서 컴포넌트화했던 그 윈도 컨트롤들을 데스크톱 앱뿐만 아니라 인터넷 웹에서도 그대로 돌려서 그 당시 1990년대 중후반에 각광받고 있던 Java applet에 대항하려 했다. Visual Basic 폼 내지, 특정 프로그램의 내부에서 플래시나 IE 컨트롤 생성하듯이 꺼내 쓸 법한 물건을 웹에서 HTML object 태그를 지정해서 그대로 띄운다는 것이다.

그때는 컴퓨터의 성능이 지금처럼 좋지 못했고 지금 같은 방대한 웹 표준이 존재하지도 않았었다.
그러니 웹브라우저에서 동영상도 보고 초고속으로 돌아가는 게임도 하고, 특히 무엇보다도 금융 거래를 위한 각종 암호화 기능을 돌리기 위해서는 닥치고 웹에서 그냥 생짜 x86 native 앱을 돌리는 게 제일 편했다.

이런 컴포넌트의 이름이 OLE Control이었는데, 이걸 웹에다 특화된 형태로 신비주의 마케팅 명칭을 붙인 게 ActiveX 컨트롤이다. 아마 마소 역사를 통틀어 길이 남을 엽기적인 작명이 아닐까? 하긴, DirectX도 비슷한 시기의 작명이니까 말이다. ㅡ,.ㅡ;;

하지만 웹에서 가상 머신이 아니라 특정 플랫폼의 네이티브 코드를 직접 구동하는 건 너무 무식하고 이식성도 떨어지고 표준 친화적이지 못하니 ActiveX는 마소에서도 버림받고 늦어도 2010년대부터는 완전히 퇴출 단계에 들어섰다.
지금은 Java applet도 완전히 멸망했고, 이들의 대체제는 정말 눈부시게 성능이 향상된 JavaScript 가상 머신이라고 보면 될 것이다.

5. OLE와 관련된 과거 유행: embed된 형태로 실행

저렇게 마소에서 COM/OLE니 ActiveX를 막 밀고 양성하던 1990년대 말~2000년대 초에는 어떤 프로그램이 다른 프로그램의 내부에 embed된 형태로 실행된 모습을 지금보다 훨씬 더 자주 볼 수 있었던 것 같다. 그와 관련해서 ActiveDocument (!!)라는 기술도 있긴 했다.

당장, MS Office 97에 있었던 Binder라는 유틸은 여러 Word, Excel 따위의 문서를 한데 묶어서 자기 안에서 해당 프로그램을 띄워서 내용을 편집하는 유틸이었다. 대단한 기술이 동원됐을 것 같지만 그래도 쓸모는 별로 없었는지 후대에는 짤리고 없어졌다.

Visual C++ 6의 IDE는 “새 파일” 대화상자를 보면 통상적인 텍스트 파일이나 프로젝트/Workspace뿐만 아니라 맨 끝에 Other documents라는 탭도 있어서 MS Office 문서를 자기 IDE 안에서 열어서 편집할 수 있었다. 당연히 MS Office가 설치돼 있는 경우에만 한해서.. 아까 그 Binder처럼 말이다.
그런데 이 역시 현실에서는.. 그냥 Word/Excel을 따로 띄우고 말지 굳이 워드/엑셀 문서를 왜 Visual C++ IDE에서 편집하겠는가? 그 기능은 후대엔 없어졌다.

ActiveX 기술의 본가인 IE 브라우저야 더 말할 것도 없다.
저런 MS Office 문서를 다운로드 해서 열면 해당 앱이 따로 열리는 게 아니라, 문서 보기/편집창이 웹페이지 화면에 떴었다. 별도의 프로세스로 말이다. 그 기술이 최초로 도입된 건 IE4가 아니라 1996년의 IE3부터였다.
파워포인트 슬라이드는 그 웹페이지 화면에서 곧장 슬라이드 쇼가 시작됐다. 이건 괜찮은 기능인 것 같다.

옛날에 pdf를 보기 위해서 Acrobat Reader를 쓰던 시절엔, 이 앱도 OLE 기술을 이용해서 IE 내부에 embed된 상태로 뜨는 걸 지원했었다. 지금이야 브라우저가 자체적으로 PDF를 표시해 주는 시대이지만 말이다.;;

요즘 컴터 다루면서 OLE 개체 삽입 기능을 쓸 일이 과연 얼마나 될까?
요즘은 개체 삽입으로 프로그램을 실행했을 때, 예전처럼 프로그램이 embed 형태로 실행되는 게 아니라 그냥 별도의 창으로 따로 뜨는 편인 것 같다. 앞서 소개했던 XP 시절의 모습과는 좀 다르다.
따로 실행됐을 때는 원래 문서에 표시된 컨텐츠와 자기가 다루는 컨텐츠가 따로 노니, 전자는 검은 빗금을 쳐셔 구분해야 한다는 UI 가이드라인도 있긴 하다.

이런 것들이 다 20여 년 전의 아련한 추억이고 한물 간 유행이다.
그나저나 인터넷으로 ppt 슬라이드를 받으면 바로 열리지 않아서 불편하다. 속성을 꺼내서 ‘신뢰할 수 없는 파일 차단’을 해제해야 볼 수 있다. 이것도 chm 도움말 파일을 바로 열리지 않는 것처럼 보안 강화를 위해서 취해진 조치인지 모르겠다.

Posted by 사무엘

1. 프로젝트 -- IDE의 관점과 빌드 스크립트의 관점

C/C++ 빌드 시스템에서 프로젝트란, 한 바이너리.. exe, dll, lib, so, a, out 따위를 만들어 내기 위한 1개 이상의 파일들의 묶음을 말한다. 그리고 여러 바이너리들을 생성하는 여러 프로젝트의 묶음을 Visual Studio 용어로는 솔루션이라고 부른다.

프로젝트를 구성하는 파일 중, 컴파일러가 처리하는 각각의 소스 파일(c/cc/cpp)은 '번역 단위'(translation unit)이라고 불린다. 1개의 번역 단위는 1개의 obj 파일로 바뀌게 된다.
그런데 요즘은 프로그래머의 편의와 작업 생산성을 위해 통합 개발 환경(IDE)이란 게 즐겨 쓰이며, 이런 IDE에서 취급하는 프로젝트는 make 같은 재래식 툴에서 취급하는 빌드 스크립트(makefile 같은)와는 완전히 일치하지 않는 관계이다.

프로젝트 파일에 들어있는 정보를 기계적으로 추출해서 makefile을 생성하는 것은 비교적 쉽게 가능하다. 그러나 makefile로부터 역으로 IDE용 프로젝트 파일을 재구성하는 것은 더 귀찮고 번거롭다.
프로젝트 파일에는 빌드가 아닌 IDE 내부에서 의미를 갖는 각종 설정 정보들이 더 들어있으며, makefile은 절차형 스크립트로서 프로젝트 파일만으로 표현할 수 없는 각종 조건부 빌드 로직이 들어있을 수 있기 때문이다.

일례로, IDE의 프로젝트 파일에는 소스 파일들을 다단계 폴더 형태로 묶고 분류해서 표시하는 기능이 있다. 이런 계층 구조 정보는 전적으로 사용자의 편의를 위해 존재할 뿐, 빌드할 때는 전혀 쓰이지 않는다. 어차피 다 똑같이 일렬로 늘어놓아서 컴파일 하고 링커로 넘겨주는 파일들일 뿐이기 때문이다.

또한 이 계층 구조는 그 소스 파일들이 놓여 있는 디렉터리 구조와는 전혀 무관하게 지정 가능하다. 하지만 현실에서는 프로젝트에서의 파일 grouping을 실제 디렉터리 구조와 동일하게 해 주는 게 사람을 덜 헷갈리게 하고 좋을 것이다. 특히 여러 사람이 유지 보수하는 프로젝트라면 더욱 말이다.

한 프로젝트를 구성하는 소스 코드들이 반드시 동일한 디렉터리에 있어야 할 필요는 없지만.. 특별한 사정이 없는 한 컴파일된 출력 파일은 오로지 한 곳에서만 생성된다.
그렇기 때문에 서로 다른 디렉터리에 있더라도 한 프로젝트에 이름이 동일한 파일이 여럿 있지는 않는 게 좋다.

오픈소스 DB 라이브러리인 sqlite는.. amalgamation이라고 해서 4MB짜리.. 거대한 sqlite3.c 파일 하나로 라이브러리 전체의 기능을 제공하는 엄청난 용자짓도 하던데..;;; 이건 극단적인 예이다.
들고 다니고 관리하기 편하고 빌드가 깔끔하고 최적화가 잘 되는 장점이 있지만, 컴파일러나 IDE가 파싱 하다가 체할 수 있고 코드 분석이나 디버깅이 잘 안 되는 단점도 있을 수 있다. 요즘도 보수적인 IDE나 디버깅 업계에서는 줄 수가 64K를 넘는 소스 파일을 좋아하지 않는 편이다.;;.

2. 정적 분석

어떤 프로그램에서 구조적인 메모리 오류나 보안 결함을 찾아내는 검증 도구 내지 방법은 크게 ‘동적 분석’과 ‘정적 분석’으로 나뉜다.
전자는 빌드한 프로그램을 가상의 샌드박스 안에서 직접 실행해 보면서 문제점을 찾는다. 그러나 후자는 프로그램을 실행하지 않고 소스 코드만 쭉 훑으면서 문제점을 찾아 낸다. 둘은 손실 압축과 무손실 압축, 실시간 렌더링과 오프라인 렌더링만큼이나 서로 영역이 다르다.

서버처럼 무한 대기· 무한 루프를 돌며 반영구적으로 돌아가는 프로그램을 동적 분석으로 검증하는 건 쉽지 않다. 프로그램이 동일 지점에 돌아왔을 때 다른 메모리 문제 없이 항상성이 보장된다는 걸 겉으로 드러나는 상태만 보고 얼추 때려잡을 수밖에 없다.

그러나 정적 분석은 프로그램의 실행 형태와 전혀 무관하게.. 무한루프건 배배 꼬아 놓은 지수함수 시간 복잡도의 재귀호출이건 무관하게.. “코드의 양이 유한하다면 분석을 위한 시간 복잡도도 유한하다”, “동일한 코드를 컴파일하는 데 걸리는 시간의 최대 수십 배 정도”이니 신통하지 않을 수 없다.

물론 정적 분석은 100% 정확하지 못하며 오탐 오진도 많다.
그런데, 각종 구조체와 포인터를 넘나들면서 진짜 너무 복잡하게 꼬여 있는 메모리를 일일이 추적을 못 하는 건 차라리 수긍을 하겠다만.. 이거 뭐 사람만도 못한 너무 황당한 오진을 하거나 간단한 문제도 못 잡아 내는 경우가 있어서 좀 아쉬웠다.

정적 분석은 그 정의상 프로그램을 “실행해 보지 않고” 코드를 분석해 주는데..
개발툴과 연계해서 “빌드는 같이 하면서” 문제를 추적하는 놈이 있는가 하면, 빌드조차 없이 진짜 코드 외형만 들여다보고 분석하는 놈도 있는 것 같다. 둘은 개발 이념이 서로 다르다.
후자가 정확도가 더 떨어지겠지만, 그래도 사용하기는 더 쉽다. 프로젝트나 makefile 세팅 없이 그냥 방대한 h와 cpp/c 묶음을 압축해서 던져 주기만 하면 분석이 되기 때문이다. 마치 Soure Insight와 비슷한 유도리가 있다.

솔직히 정적 분석을 위해서는 코드가 특정 플랫폼용으로 반드시 빌드가 돼야 할 필요가 없을 것이다. 가령, 32비트에서는 괜찮은데 64비트에서만 메모리 오프셋 문제를 일으키는 코드라면.. 그건 어차피 이식성 문제가 있는 코드이니 정적 분석 툴이 지적해 줘야 할 것이다.

내가 C/C++ 정적 분석으로부터 기대하는 아이템들은 다음과 같은 것들이다. 그런데 이것도 생각보다 스펙트럼이 다양한 것 같다.

• memcpy, malloc 같은 함수에서 버퍼 크기 계산 잘못한 것, 문자열의 경우 null문자 공간을 빼먹은 것, 0초기화를 하지 않은 것 등등 (C 코드 한정.. 제일 지저분)
• 함수가 자기 지역변수의 주소를 리턴
• memory leak 내지 dangling pointer 가능성이 있는 것
• C++에서 아직 초기화되지 않은 멤버 변수를 다른 멤버의 초기화에 동원하는 것 (이거 굉장히 교묘한 실수인데 왜 컴파일러에서 지적해 주지 않을까?)
• a=a++ 같은 이식성 떨어지는 코드, 잠재적인 코딩 실수

3. #include의 미묘한 면모

C/C++에서 #include가 하는 일은 말 그대로 다른 텍스트 파일을 현재 컴파일 중인 번역 단위에다가 끌어오는 게 전부이다. 외부 패키지나 라이브러리를 지정하는 기능이 없다. C/C++에는 Java의 import, C#의 using 같은 깔끔한 명령이 없다.
그 대신, #include를 남용하면 프로젝트에 정식으로 포함되어 있지 않은 파일을 끌어들여서 이에 대한 의존도를 생성할 수 있다.

개인적으로는 <xxx>가 아니라 "xxx" 형태의 include는.. 컴파일러가 프로젝트에 포함돼 있는 파일만 쓰도록 하고, 프로젝트에 없으면 파일이 디스크 상에 존재하더라도 없다는 에러를 내게 하는.. 그런 옵션이 좀 있었으면 좋겠다.
왜냐하면 의도하지 않았던 파일이 잘못 인클루드 되는 바람에 컴파일러가 난독증을 일으키고 사람은 사람대로 빡치는 일도 얼마든지 있을 수 있기 때문이다.
또한, 프로젝트에 포함되지 않은 채 #include 된 파일은 수정됐어도 걔를 #include하는 소스가 고쳐지지 않았다면 재컴파일 되지 않아서 다른 오동작을 유발할 수도 있다.

#define뿐만 아니라 #include로도.. 파일 내용 전체를 꼼꼼하게 파싱하지 않고 편의 시설을 제공하는(syntax coloring, 간단한 문법 체크, 선언/정의로 가기, 함수 목록 추출 따위) IDE 에디터를 농락하고 오동작을 유발할 수 있다.
가령, "}" 요 문자 하나만 달랑 들어있는 소스 파일을 하나 만든 뒤,

void func
{
  ......
#include "right_curling_bracket.c"

이렇게만 하면 얘는 문법에 맞는 코드가 된다.
또한, 따옴표로 둘러싸인 문자열을 잔뜩 넣은 뒤,

static const char BIG_STRING_DATA[] =
  "XXXXX"
#include "more_string_dadta.c"
  "ZZZ";

이런 식으로.. 거대한 테이블 데이터의 내용을 외부 파일 인클루드를 통해 조달할 수도 있다.
단지, #include는 자기 안의 코드만 대치 가능할 뿐, 같은 전처리기의 레벨을 넘나들지는 못한다. 즉,

#ifdef
#include "file_containing_sharp_endif.c"

이렇게 때우는 건 허용되지 않는다. 저 #if에 상응하는 #else나 #endif 따위는 반드시 지금 소스 파일에 존재해야 한다.

끝으로.. #include 대상인 "xxx"나 <yyy>는 C언어의 관할을 받는 문자열 리터럴이 아니다. 그렇기 때문에 \ 탈출문자가 적용되지 않으며, 디렉터리를 표현할 때 역슬래시를 두 번 \\ 찍을 필요가 없다. 사실은 Windows건 어디에서건 더 보편적인 / 를 쓰는 게 더 좋을 것이다.

#include 대상으로 매크로 상수를 지정해 줘도 된다. 이걸 사용한 예는 본인의 경험으로는 FreeType 라이브러리가 지금까지 유일하다.
다만, #include 경로는 C 문자열 리터럴이 아닌 관계로, "aaa" "bbb" 라고 끊어서 썼을 때 자동으로 "aaabbb"라고 이어지는 처리도 되지 않는다. 이런 식의 변태적인(?) 활용은 가능하지 않다는 걸 유의하자.

4. 빌드 절차의 디버깅

뭔가.. 빌드 스크립트와 컴파일러의 동작을 디버깅 하는 기능이 좀 있었으면 좋겠다.
breakpoint를 잡고 나서 F5 Run을 하는 게 아니라, F7 '빌드'를 누른다.
일반적인 디버깅이라면 빌드된 프로그램이 그 지점을 실행할 때 break가 걸리겠지만, 이때는 컴파일러가 그 지점을 읽기 시작했을 때 break가 걸린다.

break가 걸리고 나면 이 시점에서 현재 정의돼 있는 #define 심벌들을 몽땅 조회하고 실제 값과 정의된 곳(헤더 파일? 컴파일러 옵션?)을 추적할 수 있다. 치환 결과에 또 매크로가 들어있더라도 당연히 계속 까 볼 수 있다.
각종 #pragma 옵션이 지정된 내역, 옵션 스택, #line이 적용된 것도 당연히 확인 가능하다.

프로그램 실행 디버깅에서 step into / over / out이 있는 것처럼..
#include에 대해서는 마치 함수 호출처럼 step into를 할 수 있다. 어느 디렉터리에 있는 헤더 파일이 선택됐는지, 현재 컴파일러의 스택 상으로 include 깊이가 얼마나 되는지를 살펴볼 수 있다.
경우에 따라서는 <>, ""에 따라서 탐색 순서도 추적 가능하다. 요 디렉터리에 없어서 다음으로 이 디렉터리, 다음으로 저 디렉터리 같은 순이다.

#error나 #pragma warning 같은 건 아예 별도의 로그 창으로 찍히게 할 수도 있다.
흠, 좀 잉여력이 풍부해 보이긴 하지만, 그럴싸하지 않은가? =_=;;
웹브라우저에서 '개발자 모드'가 있는 것처럼.. 이런 기능이 있으면 개발자가 자기가 내력을 다 알지 못하는 방대한 프로젝트와 빌드 시스템에 처음 적응할 때 도움이 될 것 같다.

Posted by 사무엘

Windows는 태생적으로 ‘유니코드 = 2바이트 단위 인코딩’이라는 걸 전제에 깔고 만들어졌다.
거기에다 유니코드라는 게 없던 쌍팔년도 도스 시절과의 호환성을 너무 중요시해서 그런지, 2바이트가 아닌 1바이트 단위 인코딩 쪽은 일명 ANSI라 불리는 국가별 지역구 문자 코드에 오랫동안 얽매여 있었다. (cp949 따위)

그래서 이쪽 진영은 ‘유니코드의 1바이트 단위 인코딩’에 속하는 UTF-8의 지원이 맥이나 리눅스 같은 타 운영체제에 비해 굉장히 미흡한 편이었다.
가령, 파일의 경우 앞에 BOM을 꼭 넣어야만 ANSI가 아닌 UTF-8이라고 인식했는데.. 그러면 이건 말짱 도루묵이어서 지원하지 않는 것과 별 차이 없었다.

이러니 한 git 저장소에다가 넣고 여러 플랫폼에서 공통으로 사용하는 소스 파일의 경우, 영문이 아닌 한글로 주석은 무서워서 넣지도 못할 지경이었다.
Windows만 ANSI cp949를 선호하니 이건 타 운영체제의 IDE에서는 인코딩을 번거롭게 수동 지정하지 않는 한, 제대로 인식을 못 했다. 거기서 다시 저장을 하면 한글 내용은 당연히 다 날아갔다.

Windows에서도 UTF-8로 인식시키려면 파일 앞에다 BOM을 집어넣어야 하는데, 이러면 Windows 말고 타 컴파일러에서는 이게 배탈을 일으켰다.
정말 거지 같은 상황이었다. Windows는 1993년 NT 첫 버전부터 나름 유니코드를 염두에 두고 설계된 물건임에도 불구하고, 이런 분야에서는 전혀 유니코드에 친화적이라는 티가 느껴지지 않았다.

무려 2010년대 중후반이 돼서야 Visual C++ 2017인가 2019쯤에서야 드디어 BOM이 있건 없건 소스 파일의 인코딩을 다 UTF-8로 인식시키는 옵션이 추가됐다. 아마 202x 버전쯤에서는 이게 디폴트 옵션이 돼야 할 것이다.
그리고 언제부턴가 메모장이 편집하는 파일의 기본 저장 인코딩이 ANSI 대신 UTF-8로 바뀌었다.

응용 프로그램뿐만 아니라 Windows 자체도 10의 후대 패치를 통해 일단 명령 프롬프트의 인코딩에 UTF-8 지정이 가능해졌다. CHCP 65001 말이다.
단, 이런 명령 말고 프로그램 상으로 UTF-8 기반의 명령 프롬프트 환경을 어떻게 생성하는지는 잘 모르겠다. 검색해 보면 있겠지.. 배치 파일과 명령 argument를 몽땅 다 유니코드로 줄 수 있어야 진정한 유니코드화일 텐데 말이다.

다음으로 2019년쯤엔가 굉장히 큰 변화가 생겼는데..
유니코드를 지원하지 않는 구닥다리요 과거 Windows 9x의 잔재로나 여겨지던 각종 ...A 함수 말이다.
A 함수도 ANSI가 아닌 UTF-8 인코딩으로 문자열을 취급함으로써 유니코드를 지원하게 하는 통로가 뚫렸다.
그래.. 내가 원하던 게 이거였다. 진작에 좀 지원해 줄 것이지..!!

물론 Windows가 내부적으로는 문자열을 몽땅 UTF-16 방식으로 처리하고 있고, 2000년대부터는 ..A 함수 같은 건 만들지도 않는다. 그러니 ..A 함수의 유니코드화가 막 획기적으로 대단한 일은 아닐 것이다.
그러나 이렇게 해 주면 1바이트 단위로 문자열을 취급하는 각종 오픈소스 라이브러리에 대해서 골치 아프게 문자열을 변환하고 W 함수를 호출하는 thunk를 만들지 않아도 유니코드 파일명에 접근할 수 있어서 기존 코드의 포팅이 굉장히 수월해진다.

이 ANSI 코드 페이지라는 개념은 원래 시스템 global한 설정이며, 변경한 뒤에는 재부팅이 필요할 정도로 보수적인 속성이었다.
그런데 이걸 응용 프로그램마다 샌드박스를 씌워서 다른 값으로 가상화할 수 있고 심지어 UTF-8로 지정 가능해진 것은 고해상도 DPI 설정과 양상이 굉장히 비슷하다. 이것도 시스템 global이다가 응용 프로그램 단위로, 심지어 모니터 단위로 세부 지정과 변경이 가능해졌기 때문이다.

응용 프로그램의 매니페스트 정보를 통해 지정한다는 점마저도 동일하다. application → windowsSettings에 있다~!

<activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>

20여 년 전에는 마소에서 unicows라고, 응용 프로그램이 Windows 9x에서 ...W 함수를 호출하면 문자열들을 변환해서 A 함수로 재호출해 주는 호환 layer를 개발· 배포한 적이 있었다. 한 프로그램이 2000/XP에서는 유니코드를 지원하고, 9x에서는 유니코드를 지원하지 않아도 기본적인 실행만은 되라고 말이다.
이제는 A 함수로도 UTF8 인코딩을 통해 유니코드에 접근하는 통로가 생겼다니, 참 오래 살고 볼 일이다.

또한, 이렇게 세월이 흐르면 Windows에서도 2바이트 완성형 CP949는 2바이트 조합형만큼이나 점점 보기 힘들어지고 역사 속으로 사라지지 싶다. 마치 플래시나 IE6, 보안이 안 좋은 http가 퇴출되듯이 말이다.
Windows가 일찍부터 유니코드를 지원했다고는 하지만 실질적으로 재래식 1바이트 인코딩의 퇴출을 가능하게 한 것은 UTF-8의 도입이라고 봐야 할 것이다.

한편, 웹이야 살아 있는 프로그램이 아니라 문서이니.. EUC-KR이니 CP949이 더 오래 남아 있을 것이다. 그러고 보니 내 홈페이지부터가 블로그 말고 HTML 페이지는 다 구닥다리 ANSI 인코딩을 쓰고 있구나. =_=

※ 여담: 2바이트 인코딩의 문자 집합 크기

우리나라의 KS X 1001 완성형 2바이트 한글 코드는 ISO/IEC 2022라는 옛날 규격에 맞춰서 94*94 = 8836 크기의 격자 안에 완성형 한글 2350자와 상용 한자 4888자, 그리고 나머지 1000여 자에 달하는 특수문자를 배당해 놓았다.

그 뒤 CP949, 일명 마소 확장완성형은 현대 한글 11172자에서 2350자를 제외한 나머지 한글 8822자를 KS X 1001이 사용하지 않는 2바이트 문자 조합에다가 억지로 집어넣었다.
KS X 1001이 lead byte와 tail byte 공히 0xA1부터 0xFE까지만을 사용하는 반면, CP949는 영역이 더 넓다. 특히 tail byte로는 알파벳 A~Z, a~z까지 사용한다.

그런데 이 ISO/IEC 2022 격자 크기 8836과, 비완성형 한글 수 8822는 값이 놀라울정도로 비슷하다. 우연인지, 의도된 결과인지 모르겠다.;;
한글 글자 수 11172와, 16*16픽셀 8*4*4벌 도깨비 한글 폰트의 크기 11520도 꽤 비슷하게 느껴진다. 이건 진짜로 의미가 서로 전혀 무관하기는 하다만 말이다.

Posted by 사무엘

Windows API에서 LoadLibrary는 말 그대로 실행 파일(exe/dll)을 현재 프로세스의 주소 공간에다 불러들여서 거기 있는 코드를 실행하거나 리소스를 추출하게 해 주는 함수이다.
그리고 얘의 심화 버전은 LoadLibraryEx이다. Ex 버전은 옵션을 추가로 받아서 절대 경로 없이 파일명만 주어졌을 때 디렉터리를 탐색하는 순서를 지정할 수 있고, 파일이 이미 load되어 있을 때 레퍼런스 카운트 변경 여부 같은 것도 수동 지정할 수 있다.

하지만 그런 옵션들은 현업에서 잘 쓰이지 않는다. 저 함수에서 실질적으로 자주 쓰이는 옵션은.. DLL에서 리소스를 추출할 준비만 하고, 코드를 실행할 준비--기준 주소 재배치, DllMain 함수 실행--는 생략해서 로딩 속도를 좀 더 향상시키는 LOAD_LIBRARY_AS_DATAFILE이다. 특히 x86, x64, ARM 같은 아키텍처를 불문하고 동일 DLL에 있는 리소스 데이터를 추출하려면 이 '간소화' 플래그를 반드시 지정해야 한다(다국어 UI 리소스 같은..).

그런데 문제는.. 이 DATAFILE 간소화 로딩이란 게, 과거에는 "리소스 추출에만 특화"이라는 자기 본연의 기능에도 모종의 이유로 인해 뭔가 2% 부족한 구석이 있었다는 것이다.

Windows 9x 시절에는 이 제약이 제일 심했다. 간소화 로딩된 DLL 핸들에 대해서는 (1) 리소스를 제일 저수준에서 탐색하는 EnumResourceLanguages/Names/Times 및 Enum/Find/LoadResource 계열 함수만 사용할 수 있었다. 이들보다 상위 계층에서 동작하는 Load*계열 함수들은(string, menu, bitmap, image 따위) 지원되지 않았다. 그러니 간소화 로딩의 활용성이 부족했으며, 여전히 기존 full(?) 방식 로딩을 해야 하는 경우도 있었다.

허나, 한편으로는 저 제약이 그렇게까지 본질적이고 치명적인 문제가 아니었다.
Windows 프로그램에서 리소스 전용 DLL을 사용하는 주 목적은 다국어 UI 제공.. 아니면 대화상자· 메뉴 같은 표준 리소스가 아니라 자기 자신만 사용하는 custom 데이터의 저장이기 때문이다.

그리고 표준 리소스들도 특정 언어에 속하는 놈을 지정하려면 "DLL 핸들 + 리소스 ID"만으로는 어차피 충분치 않다. FindResourceEx와 LoadResource의 결과값인 메모리 포인터를 줘야 하며, 함수도 LoadMenuIndirect, DialogBoxIndirect처럼 뒤에 indirect라는 단어가 붙은 '저수준 버전'을 써야 한다.

그렇기 때문에 리소스 추출용 간소화 방식으로 load한 DLL은 저수준 함수로만 다룰 수 있더라도 그럭저럭 사용할 만했다. 그런데 여기에는 다른 이상한, 자잘한 문제도 있었다.

DialogBoxIndirect 함수는 대화상자 리소스를 "모듈(인스턴스) 핸들 + 리소스 ID"가 아니라 대화상자 템플릿 포인터 하나로만 곧장 지정함에도 불구하고, 모듈 핸들을 여전히 인자로 받는다. 내부적으로 CreateWindowEx 함수를 호출할 때 모듈 핸들이 필요하기 때문이다(대화상자 자신, 그리고 내부의 child 컨트롤들 생성).

그런데 (2) 이때 리소스 추출 간소화 방식으로 load한 DLL의 핸들을 주면.. 구형 운영체제에서는 여러 문제들이 발생했다.
일단, 자기 자신이 내부적으로 사용하는 커스텀 컨트롤--표준 컨트롤이 아니고, CS_GLOBALCLASS 등록된 커스텀 컨트롤도 아닌 놈--이 만들어지지 않는다. 이건 CreateWindowEx 함수의 특성상 자연스러운 귀결이지만, 그 이상으로..

내 기억이 맞다면 대화상자의 배경색이 일반적인 회색이 아니라 흰색으로 바뀌고 좀 만지다 보면 프로그램이 뻗었다. Windows 9x뿐만 아니라 나름 NT 계열인 2000에서도 말이다.
그 이유는 딱히 알 수 없었다. 그저 경험적으로 이런 DLL 핸들을 집어넣어서는 안 된다고 날개셋 한글 입력기 소스의 주석에도 엄청 옛날에 적혀 있었다.

물론 이 역시 본질적이고 치명적인 문제는 아니다.
윈도우의 생성과 관련해서 전달하는 인스턴스/모듈 핸들은 그 윈도우의 클래스를 등록한 주체를 식별하는 용도이다. 애초부터 리소스가 전혀 아니라 코드와 관계가 있다. 그러니 여기는 애초에 리소스 추출 간소화 방식으로 load된 DLL이 들어갈 자리가 아니다. 그런 DLL을 집어넣은 것은 사실상 프로그래머의 실수에 지나지 않는다.

하지만 이쯤 되니 의문이 생긴다. 프로그래머가 아무리 실수할 수 있기로서니, 그걸 넘겨주면 단순히 custom 컨트롤이 생성되지 않는 것 이상으로 왜 다른 이상한 부작용까지 발생한 것일까? 차라리 깔끔하게 에러와 실패 처리를 하는 것도 아니고 말이다.
DLL을 일반적인 방식으로 load하는 것과 datafile(리소스 특화 간소화) 방식으로 load하는 것은 내부적으로 무슨 차이가 있는 걸까?

오늘날의 32비트 및 64비트 Windows 환경에서는 DLL을 로딩한 결과 핸들(HMODULE / HINSTANCE)은 그 파일 내용을 가리키는 데이터 포인터와 거의 동급이라고 여겨진다. 파일을 memory-mapped file 형태로 통째로, 혹은 약간의 보정만 거쳐서 읽어들인 첫 지점이다. 쉽게 말해 그 핸들이 가리키는 메모리에는 EXE 파일 시그니처인 MZ부터 쭉 나온다는 것이다.

그리고 실행 파일은 메모리 주소가 언제나 64KB의 배수 단위로만 배당된다는 것도 이 바닥에서 프로그래밍 좀 한 사람들은 아실 것이다. 그 말인즉슨, 일반적으로 HMODULE 내지 HINSTANCE의 값은 64KB의 배수이며, 하위 word가 언제나 0이 된다는 뜻이다.
하지만 특수한 상황에서는 이런 조건을 만족하지 않는 핸들도 있을 수 있다.

(1) 먼저, 과거의 Windows 9x 환경에서는 16비트 프로그램에서 호출한 LoadLibrary의 리턴값이 대표적인 예이다. 얘들은 핸들의 크기 자체가 16비트밖에 안 되니 리턴값과 내부 의미 역시 32비트 프로그램과는 완전히 다른 형태여야 한다.
물론 이미 32비트 형태로 빌드된 프로그램이야 이런 거 신경 쓸 필요가 전혀 없으며, 16비트와 32비트 프로그램을 모두 한데 관리하는 운영체제의 관점에서나 구분이 필요하다.

(2) 그리고 LoadLibraryEx + datafile 방식으로 불러들인 dll 핸들도 형태가 약간 달라진다. 운영체제의 버전에 따라 차이가 있지만 일단 해당 DLL의 preferred base는 완전히 무시되며, 굳이 64KB라는 큼직한 단위로 주소가 배당되지 않는다.
결정적으로는 최하위 비트에 1이 추가돼서(= 홀수!!) 얘는 datafile 방식으로 생성되었다는 것을 나타낸다. 메모리 주소로서의 DLL 핸들은 하위 16비트에 어차피 유의미한 정보가 담겨 있지 않으니.. 그 잉여 공간에다 이런 정보를 보관한다는 뜻이다.

요컨대 HMODULE / HINSTANCE는 16비트 프로그램 또는 datafile 방식에 한해서는 64KB의 배수 단위인 깔끔한 포인터가 아니게 된다. 그런데 과거에는 운영체제 내부에서 이런 변칙적인 핸들을 취급하는 방식이 서로 충돌했던가 보다.

kernel32는 이 DLL이 datafile 방식으로 load되었다는 것을 식별하기 위해서 핸들값에다가 1을 추가했다. 하지만 user32의 대화상자 표시 함수는 datafile 방식에 대해서는 전혀 관심이 없으며, 이 핸들값이 하위 16비트가 비영인 것을 보고는 이건 16비트 모듈이라고 인식해 버렸다. 그리고 16비트 프로그램과의 하위 호환을 위한 보정 처리를 수행했다.

그 보정 처리 중에는 대화상자 내부의 각 에디트 컨트롤들에 대해 고유한 데이터 세그먼트를 생성하는 것도 있었다.
아시다시피 에디트 컨트롤, 특히 multiline으로 동작하는 놈은 혼자서 수백, 수만 바이트에 달하는 텍스트를 저장할 수 있다. 모든 컨트롤들이 한 64KB 데이터 세그먼트를 공유할 게 아니라 각각이 고유한 세그먼트를 갖는 게 낫다. 이것을 대화상자 표시 함수가 내부적으로 해 줬다.

(그럼 이건 특별히 메모리가 많이 필요한 에디트 컨트롤에 대해서 고유한 스타일을 줘서 그 컨트롤이 알아서 처리하면 되지, 이런 걸 왜, 어떻게 상위 윈도우인 대화상자에서 처리하는지는 잘 모르겠다. 그리고 그런 식이면 에디트 컨트롤뿐만 아니라 리스트나 콤보박스도 수천 개의 아이템을 추가하느라 메모리가 많이 필요할 때가 있을 텐데 걔네들은 어떻게 처리되는지도.. 개인적으로는 잘 모르겠다. ㄲㄲ)

어쨌든.. 대화상자를 생성할 때 datafile DLL의 핸들이 지정되면 저런 복잡한 이유로 인해 16비트 보정이 수행되는데.. 실제로 대화상자를 돌리는 이 프로그램은 16비트 프로그램이 아니다. 그래서 보정 처리가 제대로 되지 않고 프로그램이 죽는 등 갖가지 오동작과 이상 현상이 발생한다고 한다. 그래서 그랬던 것이군~!! (☞ 더 자세한 설명)

대화상자에도 스타일이 있다. 하지만 이건 윈도우 스타일의 형태로 지정해 주는 게 아니고 DialogBox 계열 함수에다가 인자로 전하는 것도 아니며, 그냥 대화상자 리소스 템플릿에 박혀 들어가는 값일 뿐이다. 그러니 다른 스타일 플래그들에 비해 인지도가 매우 낮으며 프로그램 코드에서 볼 일이 없다시피하다.

이 대화상자가 다른 대화상자의 child로 들어갈 수 있음을 나타내는 DS_CONTROL, 용도가 좀 모호하긴 하지만 [?] 모양의 도움말 버튼을 우측 상단에다 표시하는 DS_CONTEXTHELP 같은 건.. 오늘날까지도 유효하다. 하지만 16비트 시절의 잔재이고 오늘날은 아무 의미 없는 플래그도 있다.

대표적으로 DS_3DLOOK은.. Windows 95/NT4부터는 대화상자들이 처음부터 기본적으로 버튼과 동일한 은색/회색이고 각종 테두리도 양각 음각 입체(?) 효과가 적용되어 나오므로 존재의 의미가 없어졌다.
그리고 DS_LOCALEDIT라는 놈이 있는데.. 얘는 자기 내부의 모든 에디트 컨트롤들이 고유한 데이터 세그먼트가 아니라 기본 제공되는 단일 64K 세그먼트를 공유하게 해서 메모리를 아끼는 플래그이다. 에디트 컨트롤에 많아야 수십~수백 자밖에 들어가지 않는다는 게 보장되면 사용해 볼 만한 옵션이었다. 32비트 이후부터는 아무런 의미가 없어졌지만..

그리고 이렇게 DS_LOCALEDIT 옵션이 적용된 대화상자는 아까처럼 Windows 9x에서 datafile DLL 핸들을 지정해 주더라도 16비트 보정 처리가 행해지지 않기 때문에 오동작· 오류도 발생하지 않았다고 한다.
물론 이 문제는 Windows NT 계열을 넘어 16비트 프로그램 자체가 존재하지 않는 64비트 운영체제의 관점에서는 더욱 무의미한 지나간 옛날 추억이 되었을 뿐이다.

16비트에서 32비트로 넘어갈 때는 16비트 환경에서도 far이니 huge니 하면서 어떻게든 16비트 코드에서 64KB를 초과하는 메모리 영역을 다루려고 애썼으며, 반대로 32비트 주소 공간에서 16비트 코드를 수용하고 실행하려고 온갖 발악을 했었다. 하지만 32비트와 64비트는 서로 완벽하게 격리된 채 공존할 뿐, 상대방 영역을 전혀 건드리지 않는다는 차이가 있다.

이상이다.
여담이지만 날개셋 한글 입력기의 소스를 뒤져 보니.. 어떤 DLL을 datafile 방식으로 읽어들인 상태에서는 그 DLL에 대해서 VerQueryValue 같은 버전 정보 확인 API도 제대로 동작하지 않았다는 주석이 적혀 있다. 그래서 버전 리소스를 수동으로 직접 파싱하는 방식으로 기능을 구현했다.
Windows Vista 이상 또는 심지어 9x 계열에서도 괜찮았으며 2000/XP에서만 문제가 발생했다고 하는데.. 이 역시 LoadLibraryEx 함수의 부작용이 아니었나 추측해 본다. 과거에 일반 로딩과 datafile 특화 로딩은 내부 동작이 여러 모로 차이가 컸던 모양이다.

Posted by 사무엘

2021년이 되니 마소 진영으로부터 신선한 소프트웨어 소식이 전해지는 게 좀 있다.
1위는 단연 Windows 11이다.
Windows 10 이후로 주 버전명을 불변으로 고정할 거라더니, 그 정책을 6년 만에 번복하게 됐다. (Windows 10이 처음 나온 게 2015년) 업데이트로 찔끔찔끔 제품을 바꿔 나가는 것에 한계를 느낀 모양이다.

새 버전은 이제 32비트 전용 CPU의 지원을 끊고 64비트로만 나올 예정이다. 이건 뭐.. 서버 제품군에서는 이미 10년도 더 전, Vista인가 7인가 그때부터 32비트의 지원을 끊은 상태이기 때문에 전혀 새삼스러울 게 없는 결정이다. 또한 가정용 개인용 PC도 램 크기가 4GB를 넘어간 지는 이미 10년 이상 전의 일이기는 마찬가지다.

이야 그러면 버전의 명명 방식도 번호(1~3) → 연도(9x, 20xx) → 브랜드명(XP, Vista)이다가 이제 다시 번호로 회귀하는 건가 싶다(7~11). 역시 역사는 돌고 돈다. 7~8 시절에는 커널 버전과 저 번호가 일치하지 않았었는데, 10부터는 커널 버전도 대외적인 버전 번호와 일치하게 됐다.

그리고 운영체제뿐만 아니라 개발툴인 Visual Studio도 말이다. 2019 이후로 3년째 16.9.x까지 마이너 업데이트만 계속하고 있어서 이제 쟤도 메이저 업데이트를 중단했나 싶었는데.. 그렇지는 않다. 2022가 나올 예정이라고 한다.
게다가 2022는 devenv.exe IDE가 드디어 100% 64비트 기반으로 만들어진다. 이것만으로도 메이저 업데이트의 명분은 충분하다고 하겠다.

아니 그럼 지금까지는 64비트가 아니었나? 응, 의외이지만 아니었다. xcode라든가 Android Studio 같은 타 개발툴과는 상황이 다르다.
마소의 제품 중에서도 운영체제인 Windows는 XP/Vista 때 이미 x64 에디션이 나왔고 Office도 10년도 더 전의 2010부터 x64 에디션이 나왔던 반면.. 정작 개발툴 IDE는 기술적인 난관 때문인지 64비트 포팅이 굉장히 늦었다.

물론 컴파일러야 x64 타겟은 네이티브와 32-64 크로스 모두 당연히 진작부터 제공됐다. 하지만 Visual Studio IDE 자체는 여전히 32비트 바이너리였다. 그렇기 때문에 수만 개의 소스 파일들로 구성된 방대한 프로젝트를 열고 소스 코드의 인텔리센스 데이터를 관리하는 것엔 아무래도 한계가 있었다.

그래도 신기한 건 이 32비트 IDE로도 64비트 바이너리의 디버깅까지 32비트의 것과 아무 차이 없이 자연스럽게 할 수 있었다는 점이다. 원래 32비트 프로세스는 64비트 프로세스 주소 공간을 들여다보거나 훅킹 코드를 주입할 수 없다는 걸 생각하면 굉장히 신기한 일이다. Visual Studio IDE가 디버깅을 위한 64비트 호스트 프로그램을 별도로 구동하고, 얘가 32비트 IDE와 IPC(프로세스 간 통신)을 굉장히 정교하게 잘 했던 것으로 보인다.

이렇게 Visual Studio가 32비트 IDE로나마 64비트 개발과 디버깅을 정식으로 지원하기 시작한 건 무려 2005 버전부터였다.
그로부터 17년이나 뒤에야 IDE가 정식으로 64비트 기반으로 만들어지니.. 이때부터는 64비트 바이너리를 저런 별도의 디버깅 호스트 없이 IDE에서 직통으로 디버깅을 할 수 있을 것이다. (이젠 반대로 32비트 프로세스를 디버깅 할 때 디버깅 호스트를 따로 마련해야 할 듯) 취급 가능한 프로젝트의 규모가 64비트에 걸맞게 엄청 커지는 건 덤이고 말이다.

Visual C++에서 생성되는 Windows 프로젝트의 기본 configuration이 ANSI (1바이트 문자 집합) 대신 유니코드로 바뀐 첫 버전도 내 기억으로 2005이지 싶다. TCHAR이 char에서 wchar_t로 바뀌었듯, 프로그램들도 하나 둘 64비트로 포팅되면서 순수 32비트 프로그램은 갈수록 보기 어려워지는 게 느껴진다.

하긴, 과거 레거시의 압박이 훨씬 덜한 안드로이드나 iOS 같은 모바일 진영은 과거에 연연할 게 없으니 진작에 64비트로 다 갈아탔다.
요즘은 경전철이라고 해서 협궤를 쓰는 게 아니듯, 쬐끄만 스마트폰용 CPU조차도 다 64비트이다. 안드로이드와 iOS 모두, 32비트 앱의 지원은 PC보다도 더 일찍 진작에 다 끊었다.

Posted by 사무엘

1. 경고와 에러

C/C++ 컴파일러가 소스 코드를 컴파일 하는 중에 내뱉을 수 있는 메시지는 흔히 에러 또는 경고라는 두 종류로 나뉜다. 그런데 이걸 더 세분화하면 에러의 앞에는 수위가 더 높은 ‘심각한 에러’(fatal error)라는 게 있다.

얘는 컴파일 중에 컴파일러 자체가 뻗거나 메모리가 부족할 때처럼, 외부 요인에 의해 컴파일이 더 진행될 수 없을 때 나는 편이다. 그런 게 아니면 소스 코드가 문법상으로는 이상이 없지만 각종 수식이나 명칭 선언이 괄호가 너무 깊게 들어가고 복잡할 때, 리터럴 데이터 같은 게 너무 많아서 도저히 감당이 안 될 때, #include 깊이나 #define 치환 단계가 너무 깊을 때..

한 마디로 컴파일러의 한계 때문에 코드 생성이 안 되는 것이 심각한 에러로 분류되는 편이다. 이건 통상적인 컴파일 에러와는 성격이 다르기 때문이다. 참, #include 파일을 아예 찾을 수 없는 것, 그리고 #error로 대놓고 에러를 발생시킨 것 역시 추가적으로 심각한 에러의 범주에 든다.

일례로, int a = 999999999999999999999999; 이런 거야 상수가 너무 커서(32비트 범위 초과) 토큰의 스캐닝 단계에서 튕겼기 때문에 일반 컴파일 에러이다.
하지만 int tbl[] = { 10,45,34,33, ... }; 다음에 숫자가 한 100만 개쯤 있다거나,
char msg[] = "......" \ 이런 리터럴이 100MB쯤 이어져서 컴파일이 실패하는 것은 심각한 에러가 되는 셈이다.

그리고 괄호들이 닫히지 않은 채로 구문을 종료하는 세미콜론이 나오면 일반 에러이지만.. 그 상태로 파일 내용이 끝나 버리면 보통 심각한 에러로 간주된다.

에러 말고 경고는.. 컴파일러들이 경고를 이미 여러 단계로 분류해 놓은 편이다. 가령, 초기화되지 않은 변수를 사용하는 것은 다소 심각한 수위의 경고이지만.. 선언만 해 놓고 사용하지 않은 변수는 상대적으로 덜 심각한 경고이다.

또한 요즘은 정적 분석기가 함수 인자의 annotation까지 참조해서 미주알고주알 지적해 주는 잠재적 오류 가능성도 경고의 연장선이라고 볼 수 있다. "null 포인터를 참조할 가능성이 있다, 버퍼 오버런이 발생할 수도 있다" 따위 말이다.
요즘 세상에 코딩을 글쓰기에다 비유하자면 컴파일· 빌드는 인쇄· 배포에 대응하고, 정적 분석은 맞춤법 검사기와 비슷해 보인다.

2. 빌드 툴들이 말귀를 도무지 못 알아들을 때 확인해 볼 사항

• 그 소스 파일이 프로젝트에 포함돼 있긴 한가? 포함돼 있더라도 혹시 exclude from build 이런 낚시 옵션에 걸려 있지 않은가?
  
• 문제의 구간이 #if 조건을 만족하는 구간에 속해 있는가?
  
• 명칭이 이상한 매크로 때문에 다른 엉뚱한 형태로 치환되고 있지는 않은가? (주로 C)
  
• C++의 경우, 복잡한 namespace나 using 으로 인한 문맥 차이가 존재하지 않는가?
  
• 링크 에러의 경우, extern "C"로 인한 name mangling 방식 차이가 존재하지 않는가?

3. 빌드 속도

특별히 다른 부하가 걸린 게 없는 멀쩡한 개발자용 평균 사양의 2~3GHz급 컴터에서.. 2000줄 이하의 평범한 복잡도의 C++ 소스 파일이.. (IOCCC 입상작급 기괴한 난독화, 다단계 템플릿, namespace, #define 떡칠, 다중 다단계 상속 등의 남발.. 이 아닌 "평범한". -_-)
그것도 네트웍도 아닌 로컬 환경에서, 더구나 딱히 빡세게 최적화를 걸지도 않은 디버그 빌드가 컴파일하는 데 개당 0.8초 이상씩 걸리는 건.. 본인은 납득하기 어려운 상황이라고 간주한다. 소스 코드의 #include 구조 및 빌드 시스템에 문제가 있을 가능성이 높다.

당장 precompiled header가 제대로 적용돼 있는지, 덩치 큰 라이브러리 헤더의 연쇄 인클루드와 파싱이 무식하게 매번 반복되고 있지 않은지부터 확인해야 한다. 저건 컴터한테나 인간에게나 좋지 않은 상황이다.
DB 테이블로 치면 primary key 지정이나 인덱싱과 비슷한 최적화가 필요하다.

4. 안드로이드 앱용 JNI 라이브러리의 빌드

(1) 안드로이드 앱을 개발할 때, 겉에서 돌아가는 java 내지 kotlin 코드 기반의 프로그램이야 로컬 환경에서 Android Studio로 간편하게 빌드할 수 있다. 이 IDE는 Windows용과 mac용이 모두 깔끔하게 존재한다.
하지만 이 앱이 내부적으로 사용하는 native code 라이브러리들의 빌드 환경은 내 경험상 mac이건 리눅스건 여전히 유닉스 기반 터미널에 의존하고 있다. Windows에서 바로는 안 된다는 게 특이한 점이다.;; JNI 쪽 빌드도 IDE와 연계해서 같이 되게 할 수는 없는지..

(2) 디버깅도 앱은 breakpoint와 step in/out/over, 지역변수 값 확인, call stack 같은 통상적인 방법론이 IDE 차원에서 모두 지원되는 반면, 그 아래의 라이브러리는 그렇게 할 수 없다. 그런 내부 동작은 로그 printf 신공에 의존해서 추적하는 수밖에 없으니 몹시 불편하다.

(3) 그래도 이런 라이브러리들은 빌드 시스템이 멀티코어/멀티스레드 환경과 굉장히 잘 연계하는 편이다. 그래서 고성능 빌드 서버에서 make -j8 , -j16 이런 식으로 코어 수를 늘려 주면 빌드 속도가 정말 눈에 띄게 매우 빨라진다.
그런데 이 시설에도 이 기능에도 매우 아쉬운 점이 있는데... 코어 수가 늘어나면 빌드 에러 메시지도 진짜 정신없게 중구난방으로 튀어나와서 확인이 어려워진다는 것이다.

Visual Studio처럼 메시지의 앞에 코어 내지 프로젝트의 번호라도 좀 찍어 주면 읽기가 좀 더 수월할 텐데 말이다.
그리고 터미널 접속 프로그램의 본좌인 putty에는 특정 단어나 문자열이 등장했을 때 highlight를 시켜 주는 간단한 기능이 좀 있었으면 좋겠다.

putty는 20년이 넘게 0.x대의 버전 번호를 고수하고 있고, 유니코드(W)가 아닌 ANSI API를 사용하는 게 이색적이다.
ANSI API, 0.x 버전, 크로스 플랫폼 공개 소프트웨어라는 점에서는 DOSBOX하고도 무척 비슷하다.

5. 구조체 전방 선언의 부작용(?)

C/C++ 코드에서는 모듈 간의 include 의존도(= coupling)을 낮추기 위해서 자신이 내부적으로 취급하는 구조체는 불완전하게 전방 선언만 명칭만 노출하는 경우가 많다. 외부에서는 전방 선언 구조체의 포인터만 핸들 마냥 갖고 있고, 실제 조작은 실제 내부 구조를 아는 함수의 호출을 통해서를 하는 것이다. 뭐, 이게 C++이 말하는 정보 은닉과도 일맥상통하는 개념이며, 충분히 바람직한 디자인 패턴이다.

하지만 디버깅을 하는 상황이라면 어떨까..??
조작하는 함수로 들어가기 전에, 즉 밖에서 breakpoint를 걸었다. 이때도 이 포인터가 가리키는 구조체 내용을 좀 조회할 수 있었으면 좋겠는데 그게 Visual Studio IDE에서 안 돼서 답답했던 경우가 많다. 그렇다고 구차하게 소스 코드를 고쳐서 디버깅일 때에 한해서 감춰 놓은 내부 구조체 몸체 선언 include를 시키고 싶지도 않다.
특정 상황에 한해서 컴파일 때는 참고하지 않는 다른 소스 코드의 디버깅 정보를 가져오는 기능이 있으면 좋을 것 같다.

6. 나머지

(1) 컴파일러와 링커는 오늘날까지도 환경 변수라는 게 쓰이는 얼마 안 되는 분야이기도 하다. 환경 변수라는 게 명령줄에서 실행 파일을 자동으로 찾는 PATH, 그리고 컴파일러가 사용하는 기본 include 및 라이브러리 디렉터리... 이것 말고는 쓰이는 곳이 정말 드물지 않은가? 자체적인 환경 설정 파일 같은 게 동원될 법도 한데 컴파일러와 링커는 GUI 프로그램이 아니다 보니 좀 더 저수준이면서 실행되는 세션별로 사용자가 값을 더 간단하게 변경할 수도 있는 환경 변수를 대신 선택한 것 같다.

(2) 과거에 도스용 Turbo C/C++ 같은 물건은 굳이 프로젝트 파일을 안 만들어도 소스 하나만 단독으로 달랑 열어서는 곧장 빌드해서 돌려 볼 수 있었다. 그러나 요즘 개발툴들은 단순 텍스트 에디터 이상의 매우 복잡하고 방대한 물건이기 때문에 그렇게 할 수 없다. Hello world! 한 줄짜리 프로그램을 만들더라도 최소한의 프로젝트 세팅은 한 뒤에야 빌드와 디버깅이 가능하다.

(3) 그리고 요즘 개발툴들은 여러 소스 파일들을 한데 묶은 프로젝트로도 모자라서.. 프로젝트도 여러 개를 한데 묶은 '솔루션, workspace'라는 개념으로 운용된다는 것이 주지의 사실이다. 이 정도는 돼야 좀 규모 있는 소프트웨어를 원활히 개발 가능하기 때문이다.

(4) 컴터 프로그램 개발을 하다 보면.. 디버깅 로그가 실시간으로 뜨게 해 놓은 채로 디버기 프로그램을 구동하고 일정 주기로 결과를 확인할 때가 있다.
그런데 이때 프로그램이 출력하는 로그만 넣는 게 아니라, 사용자가 로그에다가 인위로 "=======" 같은 가로줄 같은 걸 즉석에서 추가할 수 있으면 좋겠다는 생각이 든다. 한 프로그램에서 동작 시험을 여러 번 할 때 로그의 영역을 하기 위해서이다.

(5) 앞으로는 "주 메모리에 로드되어 실행된 프로그램 / 하드디스크에 설치돼 있는 프로그램 / 원본 설치 패키지"라는 소프트웨어의 통상적인 3단계 구분이 더 모호해지고 단순화되지 않을까 생각된다.
일단 웹 프로그램은 설치라는 과정이 없는 게 확실하며, 메모리 계층에서 보조 기억장치와 주 메모리의 구분이 모호해지는 것도 이런 추세를 더욱 부채질할 테니 말이다.

Posted by 사무엘

1. 비트 연산 관련 버그

프로그래머가 살면서 설마 컴파일러의 버그를 볼 일이 얼마나 될까? 이건 마치 버스· 트럭· 택시 등 운전으로 먹고 사는 기사 아저씨가 잘 가다가 차량의 엔진 결함이나 급발진을 경험하는 것만큼이나 끔찍한 경험일 것이다.

본인은 최적화 옵션을 빡세게 주고 나면 Visual C++ 컴파일러가 비트 연산 쪽으로 유난히도 말귀를 못 알아먹는 현상을 종종 목격했다.
7년쯤 전에 VC++ 2010 기준으로 (1) bit rotate 연산을 <<, >> | 따위로 구현한 게 제대로 동작하지 않는 것을 목격했다. 그 함수만 #pragma를 줘서 최적화를 강제로 꺼야 오류가 발생하지 않았다.

그리고 2019년쯤에는 (2) WORD, BYTE 따위를 비슷한 연산으로 한데 합쳐서 DWORD를 만들려고 했는데.. 이것도 변수 내용을 강제로 로그를 찍으면 문제가 없지만 간단하게 값만 되돌리게 하면 틀린 값이 돌아왔다.
인라인 함수, 매크로 함수, 최적화 강제 해제 등 별별 방법을 써도 소용없어서 결국은 무식하게 memcpy로 값을 오프셋별로 강제 복사해서 문제를 회피해야 했다.

그 뒤, 19.5.x급으로 그 당시로서는 최신 업데이트가 적용됐던 Visual C++ 2019에서 더욱 황당한 일을 겪었다.
내가 하고 싶은 일은 8비트 char 값을 그대로 부호 없는 형태로만 바꿔서.. 즉, -3을 253으로만 바꾼 뒤 다른 산술 연산 처리를 하는 것이었다. 그런데 (3) 컴파일러가 말귀를 못 알아듣고 숫자를 32비트로 취급하면서 앞에 0xFFFFFF00를 제멋대로 붙였다.

숫자는 내가 기대한 것보다 엄청나게 큰 값으로 바뀌었으며, 프로그램은 이 때문에 오프셋 계산을 잘못해서 메모리 오류가 발생했다. 내가 아무리 강제 형변환 연산을 집어넣어 줘도 오류는 없어지지 않았다. 계산값에다가 원래는 할 필요가 없는 &0xFF 필터링을 강제로 하거나, 이 역시 최적화를 꺼야만 오류가 사라졌다. 이런..

이 세 사례는 모두 비트 연산 + 최적화와 관련된 컴파일러의 난독증이라는 공통점이 있었다. 2010으로 32비트 코드를 빌드하던 시절이나, 2019로 64비트 코드를 빌드하던 시절이나 마찬가지이니.. 딱히 버전과 아키텍처를 가리지도 않는 것 같다.

더 자세한 정황을 나열하지 못하는 이유는 이것들이 전부 방대한 회사의 코드를 취급하다가 발생한 일이기 때문이다. 그래서 동일 문제를 재연할 수 있는 최소한의 케이스를 따로 분리할 수가 없다. 그 함수만 텅 빈 프로젝트에다가 떼어내서 돌리면 당연히 문제가 발생하지 않는다.
하지만 동일 코드를 사용하여 macOS, 안드로이드 등 타 플랫폼에서 돌아가는 제품에서는 버그가 발생하지 않으니 이건 일단 Visual C++만의 문제라고 봐야 할 듯하다.

2. UTF-8 지원 여부와 미스터리한 오동작

Windows는 전통적으로 ANSI 인코딩(?) 천국이던 운영체제였다. 그래서 유니코드 자체는 진작부터 지원했지만 UCS-2 내지 UTF-16 같은 별도의 2바이트 단위 인코딩 형태로만 지원하는 것을 선호했다. 1바이트 단위 인코딩인 UTF-8의 형태로 지원하는 것에는 대단히 보수적이고 인색했다.

오죽했으면 Visual C++이 취급하는 리소스 스크립트 *.rc라든가 resource.h의 기본 포맷도 유니코드 기반으로 바뀌긴 했는데.. UTF-8이 아니라 UTF-16으로 바뀌었다. 거 참..

그래도 세월이 흐르니 마소에서도 대세를 거스를 수 없는지라, 명령 프롬프트에서 제한적이나마 65001 UTF-8 코드 페이지를 지원하기 시작했다. Windows 10 19xx 버전부터는 메모장이 기본으로 지정하는 텍스트 저장 인코딩이 UTF-8로 바뀌기도 했다.
심지어 Visual C++ 컴파일러 역시 UTF-8 인코딩의 소스 코드를 인식하기 시작했다. 단...!! 이건 2% 부족한 아쉬운 면모가 좀 있다.

바로.. 파일 앞부분에 BOM이 있을 때만 UTF-8로 인식한다는 것이다. 그렇지 않으면 그냥 ANSI이다.
소스 코드의 인코딩을 강제로 지정하는 옵션이 소스 코드 내부에 #pragma 같은 형태로 좀 있었으면 좋겠지만 그렇지는 않다. #pragma code_page라는 게 있긴 한데, C 문법을 일부 빌려 온 리소스 스크립트에만 쓰인다.
파일 내부 대신, 컴파일러의 옵션으로 /source-charset:utf-8 요런 게 존재하고, 줄여서 그냥 /utf-8이라고만 해도 된다.

생각해 보면 설정이 하나만 있는 것으로 충분하지 않다. 소스 코드 자체는 인코딩이 UTF-8인데 그 안에서 L로 둘러싸이지 않은 "한글"이라는 문자열 리터럴은 KS X 1001로, 즉 길이가 4바이트이고 전체 크기가 5바이트인 문자열을 의도한 것일 수 있다. 그렇게 실제로 의도된 인코딩을 지정하는 옵션은 /execution-charset이라고 따로 있으며, /utf-8은 두 charset을 모두 utf-8로 지정한 것과 같은 효과를 낸다.

그런데 컴파일러는 그렇게 인식시키면 되지만 에디터의 동작에 여전히 함정이 남아 있다.
BOM도 없고 딱히 한글· 한자 같은 문자도 없이 모든 문자열이 간단한 1바이트 숫자· 알파벳 따위로만 구성된 평범한 파일의 경우, Visual Studio IDE는 얘를 기본적으로 ANSI 인코딩 파일로 간주한다. 그 파일에 나중에 한글· 한자가 부주의하게 추가된다면 인코딩이 영락없이 잘못 지정될 수 있다. 이 기본 동작을 고치는 방법이 있는지는 난 아직 모르겠다.

그런데 그렇다고 BOM을 넣어 버리면..?? BOM은 Windows 동네에서나 통용되지, 리눅스 등 타 운영체제에서는 그냥 민폐 덩어리인 문자이다. 소스 파일의 앞에 저런 문자가 떡 있으면 컴파일러가 잘못 먹고 체하는 수가 있다.
그러니 한 소스를 여러 플랫폼에서 공유하는 경우, 모든 코드의 인코딩은 그냥 닥치고 BOM 없는 UTF-8로 통일하는 게 안전하다. 이 문제에 관한 한은 Visual C++이 타 빌드 툴들의 표준 관행에 맞춰 줘야 한다. BOM는 이식성을 저해하기 때문이다.

모종의 이유로 인해 Visual C++에서 소스 코드의 인코딩이 잘못 인식되면 빌드 과정에서 깨진 문자가 있다고 C4819라는 경고가 발생한다. 깨진 문자가 주석 내지 조건부 컴파일에 걸려서 어차피 빌드되지 않는 영역에 있을 때는 저게 딱히 문제될 게 없다. 단지, 문자열 리터럴 내부에 들어있던 한글· 한자가 깨지면 심각한 문제가 될 것이다.

그런데 내 경험상.. 주 번역 단위에 해당하는 소스 파일과, 걔가 인클루드 하는 헤더 파일 간에 인코딩이 다를 때도 상당히 골치 아픈 문제가 발생하곤 했다.
C4819 말고도 C4828이라고 파일의 줄 수가 아닌 오프셋 운운하면서 굉장히 기괴한 경고가 떴다. 최신 컴파일러에서는 이 경고가 삭제되었는지 조회되지도 않더라.

그리고 정말 믿을 수 없지만 컴파일러가 완전히 뜬금없는 에러를 내면서 동작을 멈췄다. 실제로 문법 오류가 전혀 없는 구문에서도 쓸데없는 에러가 발생했으며, 그 소스 파일에 실제로 존재하지 않는 칸 번호를 언급하기도 했다.
이렇게만 말하는 나도 황당하고 읽는 분들도 상황을 받아들이지 못하시겠지만.. 내가 실제로 겪은 상황이 저랬다.

이 역시 회사에서만 겪었기 때문에 정확· 엄밀하게 재연 케이스를 만들지는 못하겠다. 아까 얘기했듯이 (1) /utf-8 옵션을 global하게 준 상태에서 소스와 헤더 파일들의 인코딩이 충돌 난 것, 그리고 아마도 (2) precompiled 헤더를 쓰는 소스와 그렇지 않은 소스가 한 프로젝트 안에서 좀 뒤섞여 있는 것, (3) namespace와 using이 좀 복잡하게 얽혀서 인텔리센스도 오락가락 하는 상황인 것이 다 조금씩 영향을 주지 않았을까 생각된다.

이 난국은 모든 코드의 인코딩을 BOM 없는 UTF-8로 정리하고, 모든 코드에다가 한글로 dummy string을 만들어서 Visual Studio IDE가 파일을 ANSI (cp949) 인코딩으로 잘못 저장하는 일이 없게 조치를 취함으로써 해결되긴 했지만..
그때 그 문제가 왜 발생했으며 그 상황을 어떻게 재연할 수 있는지는 모른 채 미스터리로 남게 되었다.

회사에서는 길지 않은 기간 동안에도 이 정도의 이상한 버그를 몇 차례 경험했는데.. 개인적으로 날개셋 한글 입력기를 20여 년 가까이 만들어 온 동안은 컴파일러의 버그를 경험한 적이 거의 없다는 것이 참 신기하다. IDE야 불필요하게 다운되거나 뻗는 버그를 여럿 경험했지만 컴파일러가 문제를 일으킨 적은 없었다.
모든 코드가 깔끔하게 KS X 1001 레거시 인코딩이고, 회사 코드보다는 규모가 작고 모듈 구조가 깔끔하고, 전부 precompiled 헤더를 사용하기 때문이 아닌가 생각한다.

소스 코드의 인코딩이 UTF-8이 아니거나, UTF-8이더라도 앞에 BOM이 있는 것 자체를 경고로 처리하는 건 너무 과격할까? 그리고 #include에서 경로 지정을 /가 아닌 \로 한 걸 경고로 처리하는 옵션도 있으면 좋겠다. 이런 건 Windows 환경에서나 통용되지 밖에서는 전부 민폐 에러 요인이 되기 때문이다. 본인이 직장의 공동 작업 과정에서 종종 실수했던 적도 있는 사항들이다.

3. 인텔리센스의 오동작

끝으로, 이건 실제로 생성된 exe/dll의 동작과 관계 있는 치명적인 문제는 다행히 아니지만.. Visual C++ IDE가 텍스트 에디터에서 사용하는 인텔리센스도 일부 특이한 상황에서는 말귀를 못 알아듣고 오동작할 때가 있다.

본인이 겪은 경우는 클래스(가령 A)의 선언 내부에 MFC의 DECLARE_DYNAMIC 같은 복잡한 custom 매크로를 넣은 뒤, 곧장 private/public/protected 같은 접근 권한 지정자가 나올 때이다. 그러면 인텔리센스가 그 뒤에 이어지는 멤버 및 내부 enum/class (가령 B) 따위 선언을 파싱을 제대로 못 한다. ClassView를 보면 A의 멤버 목록에 B의 멤버들이 잘못 표시되며, B 선언 이후에 등장하는 A의 진짜 멤버들은 전혀 인식되지 않는다.

ClassView뿐만 아니라 텍스트 에디터에다 불러온 소스 코드에서도 각종 경고와 에러 밑줄이 A의 멤버들이 누락된 것처럼 쭈루룩 뜬다.
그렇기 때문에 A 클래스의 구현부에서는 인텔리센스와 자동 완성, 심벌 위치 조회 같은 기능들을 활용하지 못하면서 코딩을 꽤 불편하게 해야 한다.

이런 초보적인 문제는 Visual C++ 6 ncb 시절에나 보던 게 아니었나? 왜 발생하는지 모르겠다.
최신 업데이트를 적용한 Visual C++ 2019에서도 동일하게 발생한다. 본 컴파일러가 아니라 인텔리센스 컴파일러이니 딱히 특정 Visual C++ 컴파일러 툴킷만의 문제도 아닐 것이다.

뾰족한 해결책은 없고, 인텔리센스를 헷갈리게 하는 그 문제의 매크로를 클래스 선언의 맨 앞이 아니라 맨 뒤로 옮김으로써 문제를 회피할 수 있었다. 흠...

4. 도킹 하다가 뻗음

역시 컴파일러가 아닌 IDE 얘기이고, 옛날 버전에서만 발생하는 문제이기 때문에 지금 큰 의미는 없지만..
Windows 10 19xx대 버전부터인가 Visual Studio 2013 (그리고 아마 2015도)에서 각종 문서 편집 창이나 보조 윈도우(출력, 속성, 디버그 등등)를 어디에든지 도킹을 해서 붙이면 프로그램이 뻗어 버린다.

2010이 언제부턴가 실행될 때 Microsoft.Vsa.tlb 파일이 없다는 에러를 내는 것과 비슷한 현상인 것 같다. 그래도 얘는 정상 실행은 되고 프로그램 사용에 문제가 없는 반면, 저건 창을 내 마음대로 배치할 수 없게 만들고 프로그램이 뻗기까지 하기 때문에 상당히 심각한 문제이다.
저런 단순 UI는 운영체제건 VS건 한번 만들고 나서는 고칠 일이 없는 기능일 것 같은데.. 둘 다 내부적으로 뭘 건드리길래 이런 부작용이 발생하는 걸까..??

하긴, 더 옛날엔 Visual Studio 2005도 Windows Vista에서 실행하려면 sp1에다가 Vista 지원 추가 패치까지 설치해야 겨우 돌릴 수 있었다. 아래아한글 2005와 2007도 Vista 이후의 운영체제에서 실행하려면 업데이트부터 대판 설치해야 했었으니 이런 예가 전혀 없지는 않구나.

어떤 프로그램이 후대의 운영체제에서 단순히 GUI나 외형의 glitch 정도가 발생하는 걸 넘어 아예 뻗고 실행이 안 되는 건.. 대부분 보안 강화 때문이지 싶다. 문서화되지 않고 미래에 얼마든지 달라질 수 있는 특성이나 동작에 의존하게 프로그램이 만들어진 경우야 걔의 잘못이겠지만, 흔한 경우는 아닐 것이다.

Posted by 사무엘

1. make, build

요즘 소프트웨어라는 건 여러 개의 실행 파일들로 구성되고, 그 각각의 실행 파일들도 수십~수백 개에 달하는 소스 코드들로 구성된다. 이를 빌드하려면 단순 배치 파일이나 스크립트 수준으로는 감당하기 어려울 정도로 많은 옵션과 입력 파일 리스트들을 컴파일러 및 링커에다가 일일이 전해 줘야 한다. 기존 소스 코드들을 빌드하는 시나리오를 짜는 것조차도 일종의 프로그래밍처럼 된다.

그래서 이런 빌드 시나리오를 기술하는 파일을 makefile이라고 하며, 이 시나리오대로 컴파일러와 링커를 호출해서 빌드를 수행해 주는 별도의 유틸리티가 make라는 이름으로 따로 존재한다. 얘는 이전 빌드 때 만들어져 있는 obj 파일과 소스 파일과의 날짜를 비교해서 새로 바뀐 파일만 다시 컴파일 하는 정도의 지능도 갖추고 있다.
그리고 이름이 저렇게 고정 불변이며, 한 디렉터리에 하나씩만 존재하는 것으로 여겨진다. 프로젝트는 디렉터리별로 독립적이므로..

그런데 소스 말고 헤더 파일은? 조금 어렵다. 이게 수정되면 역으로 얘를 인클루드 하는 소스 파일들도 재컴파일이 돼야 하는데, make 유틸이 C/C++ 컴파일러나 전처리기는 아닌지라, 그걸 자동으로 파악하지는 못한다. 이건 makefile 스크립트 내부에서 각 소스별 헤더 파일 의존성을 사람이 수동으로 지정해 줘야 한다. 이를 기술하는 문법이 따로 있다.
이건 매번 풀 빌드 명령을 내리는 것보다 분명 편리하지만 그래도 사람이 의존성을 잘못 지정할 경우 빌드가 꼬일 수 있는 잠재적 위험 요인이다.

이렇듯 C/C++ 공부 좀 해서 본격적인 프로그램을 개발하거나 기존 제품을 유지 보수하려면, 언어 자체 말고도 다른 툴이나 스크립트를 알아야 할 것이 이것저것 생긴다. 이 바닥도 체계가 정말 복잡하기 때문에, 잘 모르는 사람은 말 그대로 소스까지 다 차려 놓은 오픈소스 프로젝트를 멀쩡히 받아 놓고도 빌드를 못 해서 돌려보지 못하곤 한다. 최소한 Visual C++ 솔루션 파일 하나 달랑 열어 놓고 F7만 누르면 바로 짠~ 빌드 되는 물건은 아니기 때문이다.

물론 그런 복잡한 시스템들은 훨씬 더 복잡한 상황을 간편하게 제어하고 관리하고 프로세스를 자동화하기 위해 도입되었겠지만.. 그마저도 초보 입문자에게는 쉬운 개념이 아니다.
Visual Studio 같은 개발툴들이 그런 make 절차를 얼마나 단순화시키고 프로그램 개발을 수월하게 만들어 줬는지 짐작이 된다. 당장 include 의존성을 자동으로 파악하는 것만 해도 말이다.

이런 개발툴 덕분에 프로그래머가 makefile 스크립트를 일일이 건드려야 할 일이 없어졌다. makefile은 해당 개발툴이 읽고 쓰는 프로젝트 파일로 대체됐으며, 얘는 비록 텍스트 포맷이긴 하지만 사람이 수동으로 편집해야 할 일은 거의 없다. 한때는 포맷이 제각각이었는데 요즘은 xcode건 비주얼이건.. 껍데기는 XML 형태인 것이 대세가 됐다. 스크립트라기보다는 설정 데이터 파일에 더 가까워진 셈이다.

Visual C++도 지금 같은 번듯한 IDE가 갖춰진 버전은 적어도 1995년의 4.0이다. 그때의 IDE 이름은 Developer Studio이었다. 이 시절에는 얘도 IDE와 별개로 유닉스 유틸과 비슷한 스타일의 make를 따로 갖추고 있었으며, 프로젝트 파일로부터 make 스크립트를 export해 주는 기능도 갖추고 있었다. 그러나 그 기능은 후대의 버전에서 곧 없어졌다. 명령 프롬프트로 빌드를 하는 건 그냥 IDE 실행 파일의 기능으로 흡수되었다.

2. cmake

유명한 대규모 크로스 플랫폼 오픈소스 프로젝트를 받아 보면 분명 Windows를 지원하고 Visual C++로 빌드도 가능하다고 명시돼 있는데, 그 빌드라는 게 내가 생각하고 이해 가능한 방식으로 행해지는 건 아닌 경우가 있다.
한때 직장에서 이미지 처리와 인식 때문에 OpenCV며 Tesseract며 머신러닝 라이브러리까지 C/C++에서 돌리겠답시고 삽질을 좀 한 적이 있었는데.. 이때 이런 식으로 지금까지 듣도 보도 못했던 프로젝트 구조와 빌드 방식 때문에 식겁을 하곤 했다.

압축을 풀거나 git으로 생성된 저장소를 아무리 들여다봐도 sln, vcxproj 같은 파일은 보이지 않는다. 먼저 MinGW에다 cmake 같은 유닉스 냄새가 풍기는 런타임을 설치해야 한다. 그래서 cmake를 돌리고 나면 자기 혼자 무슨 라이브러리 같은 걸 한참을 받더니 그제서야 디렉터리 한구석에 Visual C++용 솔루션과 프로젝트 파일이 생긴다.

소스를 사용자 자리에서 일일이 빌드해서 쓰는 것도 모자라서 빌드 스크립트 자체도 사용자 자리에서 즉석에서 동적 생성되는 모양이다. 흠..;
그 생성된 솔루션 파일을 Visual C++에서 열어서 빌드를 해 보면.. 비록 컴파일러는 마소 것을 쓰더라도 소스 파일이 선택되고 빌드되는 방식은 절대로 Visual C++ IDE의 통상적인 스타일대로 진행되는 게 아니다.

솔루션/클래스 view에는 아무것도 뜨는 게 없으며, 빌드되는 파일을 열어도 인텔리센스 따위 나오는 게 없다. 이 상태로 Visual C++ IDE에서 곧장 코드를 읽으면서 편집할 수 있지 않다. IDE에서는 그냥 debug/release나 win32/x64 같은 configuration을 변경하고 빌드 명령만 내릴 수 있을 뿐이다.

이런 프로젝트는 Visual Studio도 반드시 거기서 쓰라고 하는 버전만 써야 한다. 가령, 2017을 쓰라고 했으면 IDE까지 꼭 2017을 깔아야 한다. 2019에다가 컴파일러 툴킷만 2017을 설치하는 식으로는 안 통한다. 도대체 프로젝트를 어떻게 꾸며야 이런 빌드 환경이 만들어지는지 나로서는 알 길이 없다.

알고 보니 얘는 프로젝트의 Configuration type이 Utility 내지 Makefile로 잡혀 있었다. Visual C++에서 빌드되는 일반적인 프로젝트라면 저건 EXE, DLL, static library 중 하나로 지정하는 속성인데, 그런 것으로 지정돼 있지 않다.

그렇기 때문에 이 프로젝트에서 Visual Studio IDE는 그냥 명령줄을 실행해 주는 셔틀 역할밖에 안 한다. Visual C++ 컴파일러가 호출되는 것도 IDE가 원래 동작하는 방식으로 호출되는 게 아니다. 세상에 C/C++ 프로젝트를 이런 식으로 만들 수도 있다는 것을 어렴풋이 경험하게 됐다.

요컨대 cmake는 기존 make 툴의 또 상위 계층이며, 얘만으로도 기능이 굉장히 많고 덩치가 큰 프로그램이다. qt가 소스 레벨 차원에서 Windows와 리눅스와 맥을 모두 지원하는 범용 GUI 프레임워크로 유명하다면, cmake는 범용 빌드 시스템 관리자인 셈이다. qt를 기반으로 개발되는 GUI 앱의 프로젝트를 cmake 기반으로 만들면 진짜로 한 소스와 한 프로젝트로 Visual C++과 xcode와.. 음 리눅스용 IDE는 뭔지 모르겠지만 아무튼 진정한 크로스플랫폼 프로그램을 개발하고 관리할 수 있을 것으로 보인다.

맥OS야 요즘은 다 유닉스 스타일의 터미널을 갖추고 있으니 빌드 내지 패키지 관리 툴이 Windows보다는 이질감이 덜하다. 그러나 맥도 리눅스와 완전히 동일하게 호환되는 건 아니라는 건 감안할 필요가 있다.
그나저나 같은 x64 환경이면 GUI 말고 a.out급의 명령 프롬프트 실행 파일은 리눅스와 맥이 바이너리 차원에서 호환되나?? 아마 그렇지는 않지 싶다.

3. Source Insight

Source Insight라고 프로그래밍 및 소프트웨어 개발로 먹고 사는 사람이라면 다들 알 만한 유명한 개발툴이 있다. 단순 텍스트 에디터보다는 코드 구조 분석과 심벌 조회 기능이 훨씬 더 정교하게 갖춰져 있지만, 그렇다고 Visual Studio 같은 급으로 특정 플랫폼용 컴파일러나 디버거와 밀접하게 연결돼 있는 IDE도 아니다. 위상이 둘의 중간쯤에 속하는 독특한 물건이다.

즉, Source Insight는 각종 언어들 컴파일러의 ‘프런트 엔드’ 계층에만 특화돼 있다.
얘가 굉장히 독특한 점이 뭐냐 하면.. 전문 IDE와 달리, 실제 컴파일 결과에 꼭 연연하지 않고 유도리가 있다는 점이다. 그래서 코드에 컴파일 에러가 좀 있더라도 괜찮고, 심지어 #if #else로 갈라지는 부분까지 개의치 않고 특정 심벌이 정의된 부분을 몽땅 한꺼번에 조회 가능하다.

그래서 프로젝트와 configuration이라는 걸 꼭 바이너리를 빌드하는 단위로 만들 필요 없이, 전적으로 사용자가 심벌을 조회하고 코드를 분석하고 싶은 큼직한 단위로 만들 수 있다. 생각해 보니 이게 Source Insight의 강점이다.
Visual Studio나 Android Studio 같은 IDE만 쓰면 되지 이런 게 왜 필요하냐고..?? 응, 필요하고 유용하더라. 틈새시장을 잘 공략한 제품 같다.

그나저나 최근에 회사 업무 때문에 SI 3.5 버전을 쓸 일이 있었는데.. 본인은 또 한 번 굉장히 놀랐다.
2019년 11월에 릴리스 됐다는 프로그램이 알고 보니 구닥다리 노인학대의 종결자인 무려 Visual C++ 6으로 빌드돼 있었기 때문이다.;; ㅠㅠㅠㅠ 실행 파일 헤더에 기록돼 있는 링커 버전, 섹션간의 4KB 단위 패딩(옛날 스타일), 생성돼 있는 기계어 코드의 패턴으로 볼 때 확실하다.

게다가 유니코드 기반도 아니었다. 도움말을 보니 여전히 Windows 9x를 지원한다고 쓰여 있다. 요즘 같은 시대에 레거시 OS 종결자인 프로그램이 날개셋 말고 더 있었구나;;
회사에서만 쓰는 프로그램이어서 많이 다뤄 보지는 못했지만 쟤들도 자기 제품에다가 분명 최신 C++1x 문법을 구현했을 텐데, 그걸 자기들이 제품 코딩을 할 때 좀 써 보고 싶은 생각은 하지 않았을까..?? 피치 못할 사정이 있어서 VC6을 그렇게 오랫동안 써 온 건지 궁금하다.

그나마 2020년에 출시된 SI 4.0에서는 유니코드를 지원하고 많은 변화가 있었다고 한다. 거기서는 자기네 개발툴도 새 버전으로 갈아타지 않았겠나 추측해 본다.

4. Visual C++

그리고 나의 사랑하는 툴인 Visual Studio.. 얘는 2019 이후로 202x이 나오려나 모르겠다. 지난 2년 동안 꾸준히 소규모 업데이트 형태로만 버전업을 거듭한 끝에, 무려 16.9.x 버전에 진입했다.
업데이트가 너무 잦아서 좀 귀찮은 감이 있긴 했지만, IDE 자체의 안정성은 야금야금 눈에 띄게 강화되어 왔다. 그 예를 들면 다음과 같다.

• 예전에는 컴에 절전/최대 절전을 반복하다 보면 IDE의 글꼴이 내가 변경하기 전의 것으로 되돌아가곤 했는데 그 오동작이 어느 샌가 발생하지 않게 됐다. 상당히 성가신 버그였다.
  
• 가끔 대화상자 리소스 편집기를 열 때 IDE가 응답이 멎던 현상이 이제 더는 발생하지 않는다.
  
• 또 가끔은 프로젝트 대렉터리 내부에 RCxxxx, *.vc.db-??? 등 임시 쓰레기 파일이 프로젝트를 정상적으로 닫은 뒤에도 지워지지 않고 남아 있었던 것 같은데.. 이제는 그런 문제가 확실히 해결됐다.

예전에도 언급한 적이 있지 싶은데, 난 Visual Studio IDE가 서로 다른 프로세스 인스턴스끼리도 연계가 더 자연스럽게 됐으면 좋겠다.

• 다른 인스턴스에서 이미 열어 놓은 솔루션을 또 열려고 시도한다면 그냥 그 인스턴스로 이동하기
• 다른 인스턴스에서 만들어 놓은 문서창끼리도 한 탭으로 묶거나 떼어내기 지원 (크롬 브라우저처럼)

그리고...

• BOM이 없는 파일의 인코딩, 또는 새 파일을 첫 저장할 때의 기본 인코딩을 utf-8로 인식해 줬으면 좋겠다.
• 탭이 설정된 대로뿐만 아니라, 주변 파일의 모양을 보고 탭인지 공백 네 칸인지 얼추 분위기를 파악해서 동작하는 기능이 있으면 좋겠다.
• 프로젝트별로 소스 파일 곳곳에 지정된 책갈피와 breakpoints들의 세트들을 여럿 한꺼번에 저장하고 불러오는 기능이 있으면 좋겠다. 디버그를 위해 실행할 프로그램과 인자도 여러 개 한꺼번에 관리하고 말이다.

끝으로.. Visual C++은 2015부터가 Windows 10과 타임라인을 공유한다. 이때 CRT 라이브러리의 구성 형태가 크게 바뀌었다. vcruntime이 어떻고 ucrtbase가 어떻고.. 그리고 Visual Studio 2015~2019는 재배포 패키지도 한데 통합됐다.

그래서 그런지 요즘은 Visual C++이 설치되어 있지 않아도 시스템 디렉터리를 가 보면 msvcp140, mfc140 같은 DLL은 이미 들어있다.
20여 년 전의 msvcrt와 mfc42 이래로 운영체제의 기본 제공 DLL과 Visual C++의 런타임 DLL이 일치하는 나날이 찾아온 건지 모르겠다.

Posted by 사무엘

1. 아이콘 불러오기

창(그 자체 또는 클래스)에다가 아이콘을 지정하기 위해 흔히 LoadIcon 함수가 쓰인다.
얘는 원래 고정된 32*32 크기의 기본 아이콘 하나만을 달랑 가져오는 함수로 출발했다. 허나 Windows 95부터는 글자 크기와 같은 16*16 작은 아이콘이라는 것도 추가됐고, 나중에 XP쯤부터는 24*24, 48*48 같은 다양한 중간 크기가 도입됐다.

거기에다 화면 DPI까지 가변화가 가능하지, 256픽셀 대형 아이콘까지 도입됐지.. 이거 뭐 아이콘이라는 건 이제 도저히 단일 크기 이미지라고 볼 수 없는 물건으로 바뀌었다. 한 아이콘이 다양한 크기와 색상 버전을 가질 수 있다는 점에서 과거의 비트맵 글꼴과 약간 비슷한 위상이 됐다.

한편, 원래 마우스 포인터(cursor)와 아이콘은 기술적인 원천과 본질이 거의 같은 물건이었다. 작은 정사각형 크기의 이미지 비트맵과 마스크 비트맵의 쌍으로 표현된다는 점에서 말이다. 마우스 포인터는 거기에다가 hot spot 위치 정보가 추가됐을 뿐이었다.
그랬는데 마우스 포인터는 애니메이션이라는 바리에이션이 생겼고, 아이콘은 크기 바리에이션이 생겼다고 보면 되겠다. 동일한 특성을 같이 공유하다가 서로 다른 방향으로 기능이 추가된 것이다.

Windows 95에서는 창이나 창 클래스에다가 아이콘을 지정할 때 큰 아이콘과 작은 아이콘을 구분해서 지정할 수 있게 했다. 그래서 WNDCLASS에는 멤버가 하나 더 추가된 Ex버전이 만들어졌다. WM_SETICON 메시지도 아이콘의 대소 종류를 지정하는 부분이 wParam에 추가됐다.

그리고 LoadIcon 함수 자체도.. Ex가 추가된 건 아니고, 비트맵, 아이콘, 포인터까지 다양한 크기를 모두 처리할 수 있는 완벽한 상위 호환 LoadImage에 흡수되었다. 스펙을 보면 알겠지만 기능이 정말 많다.

하지만 내 경험상, 굳이 Ex 버전을 쓰지 않고 WNDCLASS의 hIcon에다가 큰 아이콘만 LoadIcon으로 지정해 주더라도.. 동일한 ID의 아이콘에 큰 아이콘과 작은 아이콘이 모두 있다면 별도의 처리가 없어도 괜찮았다. 프로그램 타이틀 창에 작은 아이콘은 그 별도의 작은 아이콘으로 자동으로 지정되는 듯하다. 큰 아이콘을 흐리멍텅하게 resize한 놈이 지정되는 게 아니라는 뜻이다.

그래서 본인은 지금까지 프로그램을 개발하면서 굳이 WNDCLASSEX와 RegisterClassEx를 사용한 적이 없었다. 큰 아이콘과 작은 아이콘이 ID까지 다른 서로 완전히 다른 아이콘일 때에나 이런 전용 함수가 필요한 듯하다.
단, 윈도우 클래스를 등록하는 상황이 아니라 대화상자 같은 데서 WM_SETICON으로 아이콘을 지정할 때는 큰 아이콘과 작은 아이콘을 LoadImage 함수로 구분해서 일일이 지정해 줘야 했다.

참고로 Windows에서 아이콘이라는 건 메모리 관리 형태가 크게 세 종류로 나뉜다. (1) 메시지박스에서 흔히 볼 수 있는 ! ? i 표지처럼 시스템 공통 공유 아이콘, (2) 응용 프로그램의 아이콘 리소스를 직통으로 가리키기만 하는 공유 아이콘, (3) 그게 아니라 자체 메모리를 할당하여 동적으로 독자적으로 생성된 놈.

(3)만이 나중에 DestroyIcon을 호출해서 제거해 줘야 한다. (2)는 해당 모듈의 생존 주기와 동일하게 관리된다. (1)이야 뭐 언제 어디서나 유비쿼터스이고..
그리고 RegisterClass 계열 함수가 특례를 보장해 주는 건 역시 리소스 기반인 (2) 한정이다.
wndClass.hIcon = LoadIcon(hInst, IDI_MYICON) 이렇게 돼 있던 곳에서 LoadIcon(...)의 결과를 CopyIcon( LoadIcon(...))으로 감싸서 아이콘의 형태를 (3)으로 바꿔 보시라. 그러면 그 프로그램의 제목 표시줄에 표시된 작은 아이콘은 큰 아이콘을 resize한 뭉개진 모양으로 곧장 바뀔 것이다. 이것이 차이점이다.

사실, Visual Studio의 리소스 에디터 상으로는 구분이 잘 되지 않지만, 응용 프로그램 모듈(EXE/DLL)에 저장되는 리소스 차원에서는 단순 아이콘(RT_ICON)과 아이콘 집합(RT_GROUP_ICON)이 서로 구분되어 있다. 후자는 전자의 상위 호환이다. RegisterClass는 이를 감안해서 동작하지만 HICON 자료형이나 LoadIcon 같은 타 함수들은 일반적으로 그렇지 않은 것으로 보인다.

이럴 거면 wndClass.hbrBackground에 (HBRUSH)(COLOR_WINDOW+1)이 있는 것처럼 hIcon에도 (HICON)IDI_MYICON 이런 게 허용되는 게 더 깔끔하겠다는 생각도 든다.

자, 이 정도면 아이콘 지정에 대해서 더 다룰 게 없어야 하겠지만.. 그렇지 않다. LoadImage 함수에 약간의 버그가 있다.
얘는 (1) 시스템 공용 아이콘에 대해서는 요청한 크기에 맞는 버전을 되돌리지 않고 가장 큰 놈 또는, 걔네들 용어로는 캐시에 보관돼 있는 크기의 이미지만을 되돌린다. 즉, 기존 LoadIcon과 다를 바 없이 동작한다.

특정 크기에 해당하는 아이콘을 정확하게 되돌리라고 별도의 함수까지 만들었는데 그건 (2), (3) 계층에 해당하는 custom 아이콘에 대해서만 동작한다. (1)에 대해서는 글쎄, 성능 때문인지 호환성 때문인지 잘못된 동작을 일부러 방치해 버리고는 더 고치지 않는 듯하다.

그렇기 때문에 시스템 공용 아이콘의 16픽셀급 작은 버전을 이 함수로 얻을 수 없다.
Windows Vista부터는 사용자 계정 컨트롤이라는 보안 기능이 추가되어서 관리자 권한을 나타내는 방패 아이콘(IDI_SHIELD)이 추가되었다. 얘도 UI 텍스트와 함께 작은 크기로 그려야 할 텐데.. LoadImage로는 256픽셀짜리 대형 아이콘만 얻을 수 있기 때문에 이걸 16픽셀로 줄여서 그리면 보기가 흉하다.

마소에서는 LoadImage 함수의 버그를 고친 게 아니라 Vista부터 LoadIconMetric이라는 함수를 추가했다.
얘를 사용하면 시스템 공용 아이콘에 대해서도 정확한 크기를 얻을 수 있다.
얘는 아이콘을 언제나 (3)번 형태로 동적 할당해서 되돌리기 때문에 다 사용하고 나서는 DestroyIcon을 해 줘야 한다. 처리하기 간편한 shared, read-only 속성을 포기하고 정확한 동작을 하도록 로직을 바꾼 것 같다.

그 외에 SHGetStockIconInfo라는 함수도 있어서 얘를 사용하면 한 마디로 탐색기에서 쓰이는 각종 디스크 드라이브, 폴더, 돋보기, 네트워크 등의 표준 셸 아이콘을 얻을 수 있다.

2. DrawFocusRect

Windows에서 대화상자를 키보드로 조작하다 보면, 현재 포커스를 받아 있는 각종 버튼(라디오/체크 박스 포함)이라든가 리스트 아이템에 가느다란 점선 테두리가 쳐진 것을 볼 수 있다. 이것은 DrawFocusRect라는 함수를 이용해서 그려진 것이다.

마소에서는 키보드 포커스를 받아 있는 GUI 구성요소에다가는 요 함수를 호출해서 점선으로 테두리를 그려 줄 것을 GUI 디자인 표준으로 명시하고 있다. 뭐, 일반 프로그래머라면 버튼 같은 커스텀 컨트롤을 직접 구현하거나 owner-draw 리스트박스를 만들 때에나 숙지할 만한 개념이다. 다른 요소들을 다 그리고 나서 맨 마지막으로 focus 테두리를 그려 주면 된다.
다만, 에디트 컨트롤은 애초에 깜빡이는 캐럿(caret; cursor)이 포커스에 대한 시각 피드백 역할을 하고 있기 때문에 또 점선 테두리를 그려 줄 필요가 없다.

이 점선은 이미 아시겠지만 xor 연산을 가미한 반전색이다. 원래 색과 반전 색이 교대로 등장하는 아주 단순한 패턴이다.
요즘 세상에 테두리는 그냥 알파 채널을 가미한 옅은 실선으로 그려도 될 것 같지만, 이 분야는 구닥다리 GDI 레거시 API와의 호환 문제도 있어서 그런지 여전히 옛날 그래픽 패러다임이 쓰이고 있다. 이 xor 테두리는 계산량 적고 간편할 뿐만 아니라, 다시 한번 그리라는 명령을 내리면 싹 사라지고 원래 이미지로 돌아온다는 특성도 있어서 더욱 편리하다.

이 테두리는 두께가 오랫동안 1픽셀로 고정되어 있었다. 하지만 1픽셀만으로는 너무 가늘어서 눈에 잘 띄지 않고 시각 장애인의 접근성에 좋지 않다는 의견이 제기되었다. 게다가 모니터의 해상도가 갈수록 올라가고 100%보다 더 높은 확대 배율도 등장하다 보니, 1픽셀 고정 두께의 한계는 더욱 두드러지게 됐다.

이 때문에 Windows XP부터는 제어판 설정에 따라 2픽셀 이상의 focus 테두리도 등장할 수 있게 됐다.
이 조치가 응용 프로그램에서 특별히 문제가 될 일은 거의 없겠지만, DrawFocusRect로 평범한 직사각형을 안 그리고 1~2픽셀 남짓한 두께의 수직선· 수평선을 그려 왔다면 선이 의도했던 대로 그려지지 않을 수도 있다. 같은 영역에 선이 두 번 그려지면서 점선이 없어져 버리기 때문이다.

DrawFocusRect는 기술적으로 사각형 테두리 모양으로 50% 흑백 음영 비트맵을 브러시로 만들어서 PatBlt() 한 것과 완전히 동일하다. raster operation은 PATINVERT (흑백 xor target)이고 말이다. 그러면 원래색 / 반전색이 교대로 등장한다.
xor이 아니라 and라면 과거 Windows 9x/2000의 시스템 종료 대화상자의 배경처럼 "검정 / 원래색"이 교대로 등장하면서 화면이 반쯤 어두워지는 걸 연출할 수 있을 텐데.. 이 래스터 연산 코드는 따로 정의돼 있지 않은 것 같다.

그런데.. Windows의 GDI API에서 흑백 비트맵은 자체적인 색이나 팔레트 따위가 없으며, 현재 DC의 글자색과 배경색이 DC에 select된 비트맵의 색깔로 쓰인다.
그렇기 때문에 DrawFocusRect로 정확하게 반전 점선 테두리를 그리려면 호출 당시에 해당 DC의 글자색과 배경색을 반드시 black & white로 해 줘야 한다. 시스템 색상 따질 것 없이 RGB(0,0,0)과 RGB(255,255,255)로 하드코딩하면 된다.

이렇게 해 주지 않으면 마지막으로 텍스트를 찍던 당시의 글자색 및 배경색이 무엇이냐에 따라서 focus 테두리의 색깔이 정확하게 반전색이 되는 게 아니라 들쭉날쭉 날뛰고 지저분해질 수 있다.
이건 꽤 중요한 사항인데 왜 MSDN 같은 문서에 전혀 소개되어 있지 않았나 모르겠다. 나도 10수 년째 모르고 있다가 요 얼마 전에야 깨달았다.

또한 50% 음영은 굉장히 단순하고 자주 쓰이는 패턴인데.. 브러시나 비트맵을 stock object로 제공을 좀 해 주지, 왜 안 하나 모르겠다. 요즘 같은 트루컬러, 알파채널 이러는 시대보다도 모노크롬, 16색 이러던 옛날에 더 필요했을 텐데 말이다.
CreateCaret 함수로 caret을 생성할 때는 일반적인 비트맵 핸들 대신 특수한 상수를 넣어서 50% 음영 모양을 지정하는 게 있는데.. caret보다는 다른 형태로 쓰이는 경우가 더 많다.

다음은 파란 배경에 대해서 잘못 그려진 테두리(위: 반전색+검정)와, 맞게 그려진 테두리(아래: 반전색+원래색)의 예시이다.

3. 비트맵 윤곽으로부터 region을 곧바로 생성하는 방법의 부재

Windows에서 region은 사각형이 아닌 임의의 비트맵 영역을 scan line들의 집합 형태로 표현하는 자료구조이며, 창을 사각형이 아닌 임의의 모양으로 만드는 데 쓰이는 수단이기도 하다. 이 블로그에서 예전에 한번 집중적으로 다룬 적이 있다. (☞ 예전 글)
Windows에서는 사각형이 아닌 임의의 복잡한 모양의 region을 생성하기 위해서 다각형, 원, 모서리간 둥근 사각형 등 여러 API를 제공하며, 집합 연산 비스무리하게 기존 region과 영역을 합성하는 CombineRgn이라는 함수도 제공한다.

그런데 이것만으로는 여전히 좀 2% 부족한 구석이 있다.
region을 생성할 때 사용되는 원· 다각형 그리기 함수의 결과와, 실제 DC에다 원· 다각형을 그리는 함수의 결과가 픽셀 단위로 100% 정확하게 일치하지 않을 때가 있다. 그래서 딱 정확하게 영역 안에다가 테두리를 깔끔하게 그리는 게 난감하다.

그리고 아예 만화 캐릭터 같은 모양의 창을 만들 때는.. 저렇게 벡터 이미지가 아니라 임의의 마스크 비트맵으로부터 그 윤곽 영역대로 region을 바로 생성할 수 있는 게 좋은데 의외로 그런 함수가 없다.

뭐, region의 내부 자료구조에 접근해서 복잡한 region을 직통으로 생성하는 방법도 없지는 않지만(정말 생짜 직사각형들의 집합..;; ) 이 역시 귀찮다는 건 어쩔 수 없다.
이 때문에 비트맵 그림으로부터 region을 생성하는 코드를 보면.. 비트맵 내용대로 한 줄 한 줄 CombineRgn(RGN_OR)로 한눈에 보기에도 정말 느리고 비효율적인 방법을 쓰고 있다.

layered window의 color key를 쓰면 투명색을 더 편리하게 구현할 수 있긴 하다. 허나, 창 아래의 그림자(CS_DROPSHADOW)는 region을 통해 지정된 경계하고만 정확하게 연계한다. 그렇기 때문에 애니메이션이 아닌 데서는 구닥다리 region도 여전히 필요하다.

이 분야는 다른 그래픽 API 같은 대안이 있는 것도 아닌데 마소에서 GDI API의 지원에 왜 이리 인식한지 모르겠다.;;

Posted by 사무엘

Windows 환경에서는 프로그램이 자기 화면(창)에다 뭔가를 그리고 표시하는 걸 보통은 WM_PAINT 메시지가 왔을 때 한다.
하지만 반드시 그때만 그림을 그릴 수 있는 건 아니다. 키보드나 마우스 입력(특히 뭔가 드래그)이 들어와서 특정 지점에 대한 시각 피드백만 즉각 주고 싶을 때, 혹은 타이머를 걸어서 일정 시간 주기로 반드시 뭔가를 그리고 싶을 때는 InvalidateRect라든가 WM_PAINT에 의존하지 않고, 프로그램이 직통으로 DC를 얻어 와서 그림을 그려도 된다.

화면 그리기뿐만 아니라 키보드 입력 인식도 마찬가지이다.
반드시 WM_KEYDOWN/UP 메시지를 통해서만 키보드 입력을 인식할 수 있는 건 아니다. 마우스 메시지를 처리 중일 때도 shift나 ctrl 같은 modifier key가 같이 눌렸는지, 혹은 caps/num/scroll lock 램프가 현재 켜져 있는지를 함수 호출 하나로 간편하게 알 수 있다.
그런 modifier 글쇠조차 매번 WM_KEYDOWN/UP때만 감지할 수 있다면.. 응용 프로그램이 지역 변수의 범위를 넘어서는 지저분한 key state 관리자를 둬야 할 것이고, 코딩이 굉장히 번거롭고 불편해질 것이다.

옛날에 도스 시절에 키 입력을 감지하는 건 꽤 번거로웠던 걸로 본인은 기억한다.
문자가 아닌 화살표, home/end, page up/down 같은 글쇠에 대해서는 0번(null) 문자가 prefix 명목으로 오고, 동일 함수를 한번 더 호출해서 실제 값(아마 스캔 코드)을 얻는 형태였다. 그러고 보니 저건 나름 dead key라는 개념이 구현된 셈이다.

그것 말고 ctrl이나 shift, 각종 lamp 글쇠는 저런 방식으로도 잡히지 않았기 때문에 또 다른 도스 API를 동원해야 했다. 요것들은 키보드 버퍼를 차지하지 않고, 컴퓨터가 바쁠 때 아무리 누르고 있어도 삑삑 소리를 발생시키지 않는 조용한 특수글쇠이기 때문이다.;;

글쇠를 누르는 것 말고 떼는 것을 감지하는 것도 본인은 도스 시절에 개인적으로 경험한 적이 없다.
글쇠를 누르고 있는 동안 해당 문자를 일정 간격으로 반복해서 접수해 주는 것은 컴퓨터 하드웨어 차원에서 행해지는 일인데.. 그런 키보드 속도에 구애받지 않고 누른 것과 뗀 것 자체만을 감지하는 건 특히 게임 만들 때의 필수 테크닉이다.
그랬는데 Windows에서는 모든 글쇠들이 한 치의 차별 없이 WM_KEYDOWN과 WM_KEYUP 메시지 앞에서 평등해지고 가상 키코드값을 부여받게 됐다니~! 정말 혁명 그 자체였다. 프로그래밍 패러다임이 싹 바뀌었다.

가상 키코드는 기반이 전적으로 소프트웨어에 있는 계층이기 때문에 같은 하드웨어에서도 차이가 날 수 있다. 가령, 같은 글쇠에다 가상 키코드를 부여하는 방식은 Windows와 mac이 서로 다를 수 있으며, Windows는 사용하는 키보드 드라이버에 따라서도 차이가 날 수 있다.

Windows의 가상 키코드는 caps lock 내지 shift의 영향을 받지는 않기 때문에 a건 A건 코드값이 같다. 하지만 num lock의 영향은 받기 때문에 키패드 0~9 숫자와 키패드 화살표의 코드값이 서로 다르다. 키패드 numlock 숫자는 진짜 숫자키의 숫자와도 가상 키코드가 다르다.
가상 키코드와 달리 스캔 코드는 각각의 물리적인 글쇠들에 고정불변으로 부여되어 있다. 좌우로 두 개 있는 shift처럼 가상 키코드가 동일한 글쇠는 스캔 코드로 방향을 구분할 수 있다.

요컨대 스캔 코드는 저수준이고 가상 키코드는 고수준이다. 여기에다가 문자 글쇠는 message loop에서 TranslateMessage 함수를 거침으로써 caps lock(대소문자)까지 고려한 실제 입력 문자가 담긴 WM_CHAR로 바뀐다.
WM_CHAR가 생성되는 과정(가상 키코드와 스캔 코드로부터 문자를 얻기)이 별도의 함수로 제공되기도 한다. 바로 ToUnicode 내지 ToAscii이다.

배경 설명이 좀 길어졌는데..
현재 어떤 글쇠가 눌러졌는지 여부를 알려주는 대표적인 함수는 GetKeyState이다. 인자로는 가상 키코드를 주면 되고, 리턴값으로는 2비트의 유의미한 정보가 담긴 BYTE값이 돌아온다.
최상위 비트 0x80은 이 key가 지금 눌렸는지의 여부이고, 최하위 비트 1은 눌렸다 뗐다 toggle 여부이다. 3대 lock들의 램프 점등 여부는 &1을 해 보면 알 수 있다.

심지어 GetKeyboardState 함수는 모든 가상 키코드값에 대한 키보드 상태를 배열 형태로 한꺼번에 되돌려 준다.
컴퓨터 키보드의 글쇠는 많아야 100여 개이지만 가상 키코드의 범위는 0~255라는 바이트 규모이므로 가상 키코드를 할당할 공간은 아주 넉넉한 셈이다.

그런데 Windows에는 GetAsyncKeyState라는 함수도 있다. 무엇이 비동기적이라는 얘기이며 GetKeyState와는 어떤 차이가 있는 걸까..?
GetKeyState는 현재 스레드의 메시지/input 큐 기준으로 WM_KEYDOWN/UP 메시지가 마지막으로 처리되었던 그 순간의 키보드 상태를 일관되게 쭉 되돌린다. 한 메시지가 처리되던 도중에 사용자가 어떤 글쇠를 누르거나 떼더라도 값이 변함없다.
한 컴퓨터에 키보드야 하나만 존재하겠지만, 각 응용 프로그램의 UI 스레드별 키보드 상태는 이론적으로 서로 제각각으로 다를 수 있다.

그 반면, GetAsyncKeyState는 그런 것과 상관없이 시스템 전체의 현재 키보드 상태를 실시간으로 반영해서 알려준다. 그리고 이유는 알 수 없지만 GetKey*는 최상위 bit 크기가 BYTE인 반면, GetAsyncKey*는 최상위 bit 크기가 WORD이다.
둘 다 함수의 리턴 타입은 short로 잡혀 있다. 하지만 전자는 눌려 있는 글쇠를 0x80으로 표현하는 반면, 후자는 0x8000으로 표현한다.

그러면 마우스 휠을 Ctrl을 누른 채로 굴렸는지 감지하고 싶을 때 GetKey*와 GetAsyncKey* 중 무엇을 쓰는 게 좋을까?
프로그램이 사용자의 키보드· 마우스 입력에 0.1초 안으로 정상적으로 반응하고 있는 상태라면 두 함수는 유의미한 차이를 보이지 않는다.

GetAsyncKey*는 내 프로그램이 작업을 하느라 수 초 동안 응답이 멎은 중에 사용자가 ESC를 누른 것 정도나 잡아내는 용도로 쓰면 된다. 아니면 애초에 자기 GUI 창이 없는 콘솔 프로그램에서 키 입력을 감지하는 것 말이다. 얘는 심지어 포커스가 다른 프로그램에 가 있을 때에도 특정 글쇠가 눌린 것을 감지할 수 있다.

이와 달리 GetKey*는 메시지 처리 단위로 실행 결과가 '동기화'돼 있으며, 정확하게 자기 스레드의 UI에 포커스가 가 있을 때 글쇠가 눌린 것만 감지해 준다. 그러니 일반적인 상황에서 우리에게 필요한 것은 대체로 GetAsyncKey*가 아니라 그냥 GetKey*이다.

Async가 붙은 놈이건 안 붙은 넘이건, 이들 함수는 글쇠가 눌린 것을 감지만 하지, 그걸 처리한 것으로 퉁쳐 주지는 않는다. 내 작업 루틴에서 ESC가 눌린 것을 감지해서 하던 작업을 중단했다 하더라도 UI에서 WM_KEYDOWN + VK_ESCAPE 메시지가 가는 것은 변함없다.
이럴 거면 GetAsyncKey*를 호출할 게 아니라 Peek/Get/DispatchMessage로 메시지를 정식으로 처리하는 게 더 낫다. GetAsyncKey*는 쓸 일이 더욱 줄어드는 셈이다.

Posted by 사무엘