1. 독특한 윈도우 클래스
Windows의 GUI에는 버튼, 리스트박스, 에디트 컨트롤 등의 잘 알려진 제1군 컨트롤 윈도우들이 있고, 공용 컨트롤이라는 제2군 윈도우도 있다. 이런 것들은 누구나 널리 사용하라고 클래스 이름도 널리 알려져 있다.
그런데 Spy++로 들여다보면, 정식으로 공개되지 않았지만 이런 클래스들이 공용으로 쓰이는 것 같다. 정체가 무엇인지 궁금하다.
- NetUIHWND: MS Office 프로그램들, 그리고 심지어 워드패드와 그림판에서도 리본이 이 클래스 이름으로 만들어져 있다. 마소에서만 내부적으로 사용한다. (Visual C++의 MFC 확장판에서 제공되는 리본은 마소 오리지널이 아님)
- DirectUIHWND: task dialog 내부, IE 브라우저의 탭, 탐색기 제어판에서 뭔가 웹페이지처럼 꾸며진 대화상자들에서 종종 쓰인다. 클래스 스타일에 CS_GLOBALCLASS도 버젓이 지정돼 있다. 마소 내부에서 사용하는 GUI 엔진 윈도우 같은데..
- HwndWrapper[모듈이름;;GUID]: 닷넷이나 WPF처럼 통상적인 Windows API나 기성 컨트롤이 아닌 다른 프레임워크를 이용해서 GUI를 꾸미는 프로그램 같다. 내가 아는 프로그램 중에는 Visual Studio 2010과 그 이후 버전, 그리고 아래아한글(+ 타 오피스 제품 포함) 요 두 프로그램만이 이런 스타일이다.
2. 파일 및 디렉터리의 삭제, 디스크 제거
Windows는 프로그램을 memory-mapped file 형태로 불러온다는 특성으로 인해.. 실행 중인 프로그램을 삭제할 수 없다. 그래서 실행 중인 프로그램을 제거하거나 업데이트 하는 것도 좀 어려운 편이다.
실행 중인 프로그램 파일을 '개명'하는 건 가능하다. 여기서 개명이란 같은 드라이브 안에서의 디렉터리 이동도 포함한다.
이런 Windows와 달리 macOS나 리눅스는 실행 중인 프로그램 파일을 삭제할 수 있다.
허나, 실행 중인 프로그램의 current directory를 당장 삭제할 수 있는 운영체제는 내가 아는 한도 내에서는 없다. 삭제 예약만 해 놓은 뒤, 프로그램이 종료되거나 디렉터리가 딴 데로 바뀌었을 때 삭제되는 게 그나마 제일 관대한 처분이다.
프로세스의 current directory는 USB 메모리를 안전하게 제거할 수 없다고 운영체제가 꼬장 부리면서 사용자를 귀찮게 하는 요인 중 하나이기도 하다.
특히 Windows의 경우, 파일 열기/저장 공용 대화상자를 열어서 USB 메모리를 조회하면 해당 프로그램의 current directory도 거기로 바뀌기 때문에 대화상자를 닫은 뒤에도 저런 꼬장이 발생할 가능성이 높아진다.
뭐, 사용자가 USB 메모리를 물리적으로 강제로 제거해 버리는 것에는 장사 없다. 과거의 디스켓이나 광학 드라이브도 매체를 강제로 꺼낼 수 있었으니 말이다. 하지만 이런 일이 발생하면 운영체제의 관점에서는 current directory가 갑자기 없어지는 것이나 다름없고, 거기에 파일이 열려 있던 것들도 다 꼬여 버린다. 프로세스가 아닌 스레드를 강제 종료하는 것만큼이나 좋지 않은 현상이다.
디스크 내용을 날리고 싶지 않으면 사용자도 가능한 한 그런 짓은 하지 않는 게 좋다.
3. Windows의 런타임 환경
Windows에서 전통적인 API 기반의 네이티브 코드 데스크톱 프로그램 말고 선보였던 프로그램 실행 환경으로는..
먼저 2000년대(XP..)엔 .NET이란 게 있었다. 얘는 네이티브가 아니라 가상 머신에서 돌아갔고, 언어도 C#가 주류였다. C++에는 C++/CLI라는 변종 언어가 도입됐다.
그 뒤 2010년대(8..)엔 메트로 UI와 함께 C++/CX라는 변종 언어가 도입됐다. 얘는 데스크톱 환경은 아니지만 의외로 네이티브 코드 기반이었다.
.NET이 표방했던 것이 언어의 통합이라면, Windows 8이 표방했던 것은 기기(PC와 모바일?)의 통합이었다. 그래서 오죽했으면 시작 버튼을 없애는 초강수까지 뒀었다.
그러나 Windows 8은 망했으며, 결정적으로 Windows Phone/Mobile도 안드로이드와 iOS에 완전히 밀렸다. 이젠 마소에서도 그쪽 사업을 접었다. 그 대신 Windows 10은 ARM용이 정식으로 출시되어서 그 CPU에서 네이티브 데스크톱 앱을 그대로 돌릴 수 있게 됐다.
그럼 이 와중에 메트로 앱을 돌리는 Windows Runtime이라는 건 무슨 존재의 의미를 갖게 되는지 난 궁금하다. 답을 잘 모르겠다.
그냥 데스크톱 앱보다 글자 큼직하고 시각적으로 flat하고, 안드로이드 용어로 치자면 material design스러운 외형을 제공하는 GUI 엔진 그 이상도 이하도 아니어 보이는데..??
쉽게 말해 기존 공용 컨트롤이 '제어판'을 가동한다면 이 UI 엔진은 '설정'을 가동한다는 것이다.
마소에서 새로운 걸 시도한 것이 언제나 다 성공적이고 오래 유지된 건 아니었던 듯하다.
그래서 GDI+는 닷넷 시절에 잠깐 뜨다가 Direct2D 부류로 대체됐고, 오히려 운영체제의 근간으로서 넘사벽급의 짬밥을 자랑하는 재래식 GDI보다도 존재감이 없어졌다.
Edge 브라우저는 잘 알다시피 재개발되어서 사실상 크롬과 다를 바 없는 브라우저가 됐다. 마소의 지난 20여 년의 개발 트렌드를 회고해 보니 이런 분석과 결론이 나온다.
4. 이모지, 날개셋 입력 패드
Windows 10의 1803버전쯤부터는 win+.을 눌러서 이모지 문자표를 꺼내는 기능이 추가되었다.
날개셋 한글 입력기에서는 지난 9.81 버전부터 자체적으로 이모지 문자표가 추가되었다. 그럼 이건 언뜻 보기에는 기능 중복처럼 보이지만 실제로는 꼭 그렇지 않다.
운영체제의 이모지 문자표는 마우스로 딴 델 클릭하기만 해도 사라져 버리는 반면, 날개셋의 입력 도구는 그렇지 않다. 더구나 결정적으로 이 문자표는 날개셋 편집기에서 자체 입력기를 지정해 놓았을 때는 사용할 수 없다.
그리고 내 프로그램에서는 선택된 이모지를 복사하기, 그리고 cursor가 가리키는 이모지를 문자표에서 찾아서 역으로 표시하기 같은 기능도 갖추고 있다.
예전에도 언급했듯, 2018~19년에 걸쳐 추가된 ‘필기 인식’과 ‘이모지’는 날개셋의 고유 기능이 아니라 운영체제가 제공하는 기능을 자체적인 UI 껍데기를 씌워서 제공하는 대표적인 입력 도구이다. Full feature를 갖춘 한글 IME로서 저런 기능도 한 프로그램 내부에서 제공할 필요가 있기 때문이다.
뭐 그건 그런데.. 운영체제에서 기본 제공하는 이모지 문자표는 응용 프로그램에다가 어떤 방식으로 이모지 문자를 보내는 걸까? 그게 갑자기 궁금해졌다. 쟤는 기술적으로는 ‘날개셋 입력 패드’과 비슷하게 훅킹을 사용해서 IME 메시지를 보낼 것 같은데..
프로그램이 TSF를 감지하는지 여부를 따져서 지원하면 TSF 방식으로 문자를 보내고, 그렇지 않으면 기존의 IME 메시지를 보낸다는 것을 확인할 수 있었다. IME 메시지만을 사용하는 날개셋 입력 패드보다 더 고차원적이다. 사실, TSF를 지원해야만 메트로 앱에서도 이모지를 입력할 수 있을 것이다.
날개셋 입력 패드를 처음 개발하던 시절에 본인도 개인적으로는 TSF 방식을 뚫어 볼까 생각을 했었다. 이게 성공하면 외부 모듈뿐만 아니라 입력 패드도 편집기와 비슷하게 주변 문자를 자유자재로 변형하면서 신기한 기능을 제공할 수 있다.
그러나 외부 모듈 하나만 개발해 봐도 내 경험상 TSF는 기술 난이도가 헬이고 응용 프로그램별로 제멋대로 동작하는 구현의 파편화가 너무 심하다. 더구나 그 TSF의 혜택을 보는 프로그램은 매우 소수이며, 편집기와 외부 모듈 다음으로 입력 패드 자체도 사용 빈도가 매우 낮은 제3군의 실험적인 유틸일 뿐이다.
그렇게 TSF를 뚫어 봤자 훅킹은 어차피 메트로 앱에서는 통하지도 않기 때문에 그 단계에서 막히니..
시간과 노력 대비 타산이 맞지 않는다는 결론을 얻어서 그 이상의 연구는 포기했다. 입력 패드는 write-only인 IME 프로토콜만 사용하는 데스크톱 앱 전용 프로그램으로 굳어져서 오늘에 이르고 있다.
5. 유니코드 5.2 자모
아시다시피 지난 10여 년 전에 KS X 1026-1 및 유니코드 5.2에서 옛한글 자모가 여럿 추가되었다. 시기가 시기이다 보니 연속된 공간을 쭉 확보하지 못하고 덕지덕지 지저분하게 추가되었지만, 그래도 잘 살펴보면 프로그래머의 관점에서 복잡함과 불편함을 최소화하는 방식으로 추가되었음을 알 수 있다.
답부터 말하면, 어떤 글자가 한글 초성인지 중성인지 종성인지 판별하기 위해 과거(유니코드 1.1)에는 A<=X<=B라는 영역 검사 하나만이 필요했다. 이제는 그래도 그 영역 검사가 각 성분별로 하나씩만 더 추가되면 된다.
- 초성은 U+1100부터 1159까지 하던 영역에서 끝부분을 115E로 늘린 뒤(5개 추가), A960부터 A97C라는 새로운 영역 한 곳만 더 살펴보면 된다.
- 중성은 U+1160부터 11A2까지 하던 영역에서 끝부분을 11A7로 늘린 뒤(5개 추가), D7B0부터 D7C6이라는 새로운 영역을 더 살펴보면 된다.
- 종성도 그런 식으로 기존 영역을 조금 확장하고 나서 새로운 영역을 더 살펴보면 된다.
잘 알려져 있지 않지만, KS X 1026-1은 종성에 ㅇ으로 시작하는 겹받침(ㅇㄱ, ㅇㄲ, ㅇㅇ, ㅇㅋ)을 그냥 이응이 아닌 옛이응으로 수정한 규격(잠수함 패치..)이기도 하다.
그리고 KS X 1026-2는 정규화 규칙을 추가로 규정해서 현대 한글을 옛한글 자모의 조합으로 표현하는 것을 금지하고, 현대 한글 글자마디와 옛한글 자모가 합성되는 것도 명시적으로 금지했다. 한 한글은 오직 한 가지 방식으로만 표현되게 했다.
Windows는 2012년에 나온 8부터 저게 반영됐고, 날개셋 편집기에서는 지난 2015년에 나온 8.0 버전에서야 반영됐다. 저 표준을 제정한 분과 개인적으로 얘기까지 나누며 설명을 들은 뒤에야 말이다. 엇, 그러고 보니 둘 다 8부터네?!?
유니코드 2.0에서 한글 글자마디 11172자를 따 온 건 예전에 서울 올림픽 유치 성공만큼이나 역사에 길이 남을 위대한 쾌거였다. 현대 한글이 그렇게 정립된 뒤에 옛한글도 저렇게 됨으로써 한글 코드 논란은 완전히 종식됐다.
그 뒤로 유니코드 자체도 2003년쯤이던가 4.0에서 U+10FFFF라는 상한을 명확하게 정하고, 이 이상 글자를 더 등록하지는 않을 것이라고 못을 박았다. 그 이상은 UTF-16으로는 더 표현할 수가 없기 때문이다. 그래서 UTF-8도 4바이트 방식까지만 사용하고 5~6바이트 방식은 봉인했다.
따라서 현재 유니코드에 정의된 모든 평면이 고갈되고 글자들로 꽉 차는 날이 온다면.. 유니코드 위원회는 해산될 것이다. 지금의 문자 코드 체계는 지구와 현 인류 문명이 송두리째 멸망하지 않는 한 쭉 이어질 것으로 보인다.
Posted by 사무엘
