컴퓨터 소프트웨어에서 뭔가 기능은 동일하지만 프로토콜(입출력)이 다른 두 시스템을 최상위 계층에서 중재하여 서로 이어 주는 메커니즘을 '썽킹(thunking)'이라는 용어로 표현하는 것 같다. 영한사전에 제대로 등재돼 있지도 않은 신조어인데 정확한 어원이 궁금하다. 영문 위키백과는 a subroutine that is created, often automatically, to assist a call to another subroutine라고 풀이를 하며, 그래서
- Windows 9x에서 유니코드(W) API 호출 요청이 왔을 때, 매개변수 값을 적당히 조절해서 그에 상응하는 Ansi API를 대신 호출하고 출력 결과도 wide string 기준으로 보정하는 것
- C++의 멤버 함수 포인터에서 다중 상속된 클래스의 멤버 함수를 호출하기 전에 this 포인터의 오프셋을 보정해 주는 전처리 함수 (보정 정보가 포인터의 내부에 있지 않고 그냥 또 다른 함수를 생성해서 때우는 경우)
이런 것들도 다 넓게는 썽크/썽킹이라고 부른다. 그리고 썽킹을 수행하는 함수를 썽크 함수라고 한다. 다만 Windows에서 썽킹은 컴퓨터 아키텍처의 장벽을 극복하는 호환성 유지 작업을 가리킬 때 주로 쓰인다. 16비트와 32비트 사이, 그리고 요즘은 32비트와 64비트 사이에서 말이다.
그래서 그런 썽킹 시스템을 WoW라고 부른다. 월드 오브 워크래프트...가 아니라 Windows on Windows의 약자로, 말 그대로 Windows 위에서 Windows를 또 가상으로 구동한다는 뜻이다.
오늘날 우리가 사용하고 있는 x86-64 아키텍처는 과거 32비트 IA32의 superset 구도로 설계되었다. 그래서 32비트 x86 코드도 에뮬레이션이 아니라 네이티브 직통으로 실행 가능하기 때문에 Windows 입장에서는 소프트웨어적으로 32비트와 64비트를 모두 지원하기 위해 특별히 힘든 일을 해 줘야 할 건 없다. 64비트 시대에도 어마어마한 32비트 유물들은 비록 바이너리 형태가 아무리 지저분하더라도 결코 외면할 수 없는 물건임이 입증된 셈이다. 비록 성능을 추구했다고는 하지만 x86 코드를 거북이처럼 에뮬레이션으로 돌리고 다른 문제점도 많았던 IA64는 정말 시원하게 망해서 인텔의 흑역사가 됐다.;;
32비트와 64비트는 한 주소 공간 안에서 코드가 섞이는 게 전혀 불가능하며, 서로 교류하는 방법은 API나 커널 오브젝트 차원에서의 IPC 메커니즘밖에 선택의 여지가 없다. 특히 WM_COPYDATA 메시지는 16, 32, 64비트까지 세대를 넘어 두루 통용되는 대단히 훌륭한 해결사이다.
그러나 16비트와 32비트가 공존하던 시절에는 상황이 훨씬 더 지저분했다. 기존 소프트웨어와의 호환성, 그리고 부족한 PC 메모리 같은 현실적인 한계 때문이었다.
그 시절에는 기술적으로 다음과 같은 형용사가 붙은 썽킹들이 존재했다. 썽킹이 무슨 CPU 에뮬레이션까지 하는 건 물론 아니고, 주로 한 일은 최신 32비트 가상 메모리 주소와 구닥다리 16비트의 세그먼트-오프셋 주소를 그냥 상호 변환하는 것이었다.
1. Universal: 16비트 플랫폼에서 16비트 EXE가 32비트 DLL을 실행
이건 가장 원초적인 썽킹이며, 쉽게 말해 Win32s의 기술 수준이 여기에 해당한다.
2. Generic: 32비트 플랫폼에서 16비트 EXE가 32비트 DLL을 실행
이것은 32비트 Windows 9x/NT 계열이 모두 지원하는 썽크로, 방향이 universal과는 반대이다.
본인은 IME 개발자로서 이 썽킹의 존재를 자연스럽게 인지하고 있었다. 16비트 프로그램에서도 <날개셋> 한글 입력기 외부 모듈이 동작했기 때문이다. 물론 곧 오류가 나고 제대로 사용하기는 어렵지만.
Windows 9x의 경우, 16비트 프로세스 내부에서 돌아가는 32비트 코드는 마치 Win32s처럼 극도로 가난한 16비트 컴퓨터의 끔찍한 제약들이 고스란히 적용되었다. 스레드를 생성할 수 없으며 스택 크기도 기본 1MB 이상이 아니라 64KB 미만으로 팍 줄었다. 그러니 복잡한 재귀호출이나 큰 배열조차도 함부로 만들면 안 됐다.
Windows NT는 모든 운영체제의 코드가 32비트 이상이다. 하지만 그렇다고 해서 16비트 코드를 실행하는 기능 자체가 아예 없는 건 아니었으니 16비트 프로그램이 32비트 코드를 사용하기 위한 최소한의 썽킹 계층은 마련하고 있다.
16비트 EXE 안에서 동작하는 32비트 dll이 GetModuleFileName(NULL)을 해 보면 9x 계열의 경우, 16비트 EXE 이름이 아니라 그냥 kernel32.dll이 돌아온다. 그러나 NT 계열은 ntvdm.exe가 돌아온다. 16비트 코드는 아예 샌드박스 안에서 고립된 채 돌아가고, 얘와 연계하여 동작하는 32비트 DLL은 여전히 32비트 문맥이 완전히 보장된다.
3. Flat: 32비트 플랫폼에서 32비트 EXE가 16비트 DLL을 실행
이것은 Windows 9x에만 존재한다. 20여 년 전에 Windows 95가 나오고 제품의 32비트 에디션을 출시하긴 해야 하는데 방대한 16비트 기반 DLL 엔진 같은 걸 차마 다 32비트로 포팅할 시간이 없을 때, 차선책으로 쓰라고 도입된 솔루션이다.
Universal은 그냥 32비트로 빌드만 하면 혜택을 입을 수 있고 Generic도 해당 16비트 EXE에서 LoadLibrary32Ex32W나 CallProc32W 같은 썽킹 API만 새로 사용하면 썽킹이 가능한 반면, Flat 썽킹을 활용하려면 thunk 컴파일러를 이용해서 상호 교신하고자 하는 32/16비트 바이너리들에 썽크 중재용 DLL을 추가로 넣어 줘야 한다.
1~3은 성격과 용도가 제각각 다르다는 걸 알 수 있다.
과거에 아래아한글이 최초의 Windows 버전인 3.0이 개발되었을 때, 시행착오로 인해 universal 썽크만 생각했지 flat 썽크를 고려하지는 못한 듯하다. 그래서 내가 듣기로는 Windows 3.1 + win32s에서는 실행되었는데 정작, 곧 출시된 Windows 95에서는 어처구니없게도 동작하지 않았다고 한다. (NT는 모르겠음)
아래아한글이 100% 완벽하게 32비트로만 개발됐으면 이런 일이 없었을 텐데 아마 내부적으로 호환성 때문에 16비트 코드가 일부 존재했던 모양이다. 그리고 내가 들은 이런 소문들이 사실이라면, Universal 썽크는 Win32s + 32비트 EXE에서 도로 16비트 DLL을 로딩하는 것도 지원하긴 했나 보다. Windows 95에서 추가로 해야 하는 썽킹이 없이도 뭔가 되는 일이 있었으니까 말이다.
어쨌든 이 때문에 Windows 95가 발매된 1995년 말엔 그 문제를 해결한 3.0b가 신속하게 나와야 했다. 소문에 따르면 3.0a도 있었는데 이건 3.0 원판보다도 존재감이 "더" 없는 것 같다.
이런 썽킹은 커널 레벨에서 발생하기 때문에 뭔가 정보를 잘못 줘서 에러가 나더라도 애플리케이션 레벨에서는 디버깅조차 할 수 없다. 더 깊게 들어가지 않은 채로 그냥 에러가 난다는 뜻이다. 이런 건 커널 레벨 디버거를 써서 살펴봐야 한댄다.
비록 제대로 안 돌아가는 제품을 돈 주고 사서 쓰다 고생한 사용자들에게서 욕도 많이 먹었겠지만, 그래도 그 열악한 환경에서 그 방대한 도스용 프로그램을 그 제한된 시간과 예산 하에서 Windows용으로 뚝딱 포팅을 한 건 대단한 일이긴 해 보인다.
Windows 9x 시절에 썽킹과 관련된 대표적인 테크닉 중 하나는 32비트 프로그램이 지금 시스템에 남은 리소스 퍼센티지를 얻어 오는 것이었다. 그 값을 얻으려면 32비트 프로그램이 32비트 user32.dll이 아니라 16비트 user.exe의 함수를 호출해야 했기 때문에 일종의 flat 썽킹이 필요했다.
물론 운영체제가 제공하는 rsrc32.dll이 제공하는 함수를 호출하는 방법도 있지만(얘는 rsrc16.dll로 내려가고), 걔네들이 하는 일을 별도의 dll 없이 직통으로 수행하는 꼼수가 있는데.. 이건 분량이 길어지는 관계로 나중에 다시 다루도록 하겠다.
자, 그럼 썽킹과 관련된 다른 얘기도 슬슬 좀 꺼내 보겠다.
본인은 에디트, 리스트 같은 기성 컨트롤들에 보이는 명령 메시지들의 값이 16비트 시절과 32비트 이후 시절이 서로 다르다는 것을 비교적 최근에 알고서 놀랐다.
과거에는 LB_ADDSTRING, EM_SETSEL 같은 메시지들이 WM_USER 이후 영역에 있었다. 그러나 32비트에서는 이것들이 WM_USER 이내의 시스템 메시지 영역으로 옮겨졌다. 아마 대화상자 내부에서 다른 사용자 메시지들과의 충돌을 막으려는 의도도 있고, 또 얘는 WM_GET/SETTEXT처럼 프로세스 간에 문자열을 주고받을 때 운영체제가 자동으로 메모리 보정을 해 준다는 의미에서 시스템 메시지로 승격된 게 아닌가 싶다.
대화상자에서 어떤 컨트롤이 WM_GETDLGCODE 메시지에 대해 DLGC_HASSETSEL를 되돌리면 걔는 포커스를 받았을 때 텍스트 전체를 선택하라는 EM_SETSEL 메시지를 받는다. 자신이 에디트 컨트롤을 자체 구현하고 있다면 이 메시지를 저렇게 처리하면 된다.
그런데 Windows 9x에서는 저 메시지가 안 오고 WM_USER+1에 속하는 정체불명의 괴메시지가 오곤 했다. 알고 보니 저건 16비트 시절의 EM_SETSEL과 같은 값이었다.
이런 레거시들 사연들은 모를 때보다 알 때가 프로그래밍에 훨씬 더 도움이 된다. 물론 그렇다고 해도 32비트 프로그램에다가도 Windows 9x는 왜 16비트 기준의 메시지를 보내는지는 알 수 없는 일이다. Windows의 썽킹 계층은 메모리 주소/포인터 변환뿐만 아니라 GUI에서는 이런 메시지의 변환까지도 도맡아 했다고 한다.
지금은 공용 컨트롤들의 메시지가 WM_USER 밖의 영역에 있다. 얘들은 애초부터 프로세스간의 메모리 보호가 잘 되는 32비트 운영체제와 함께 등장하기도 했고 또 알다시피 복잡한 플래그들이 들어간 복잡한 구조체를 주고받다 보니, 운영체제가 inter-process간에도 메모리 보정을 해 주지 않는다.
다른 프로세스에 있는 리스트/트리 컨트롤에다가 데이터를 등록하려면 얄짤없이 훅 프로시저를 써서 그 프로세스의 문맥 안에서 해당 컨트롤을 조작해야 한다. 사실, 남의 프로세스의 GUI 컨트롤을 조작하는 변태적인 작업이 왜 필요한지는 모르겠지만 말이다.
잘 알다시피 16비트 시절엔 DLL 전역변수들이 한데 공유됐으며, 제2, 제3 EXE들이 연결됐을 때 PROCESS_ATTACH 통지가 없었다고 한다. 그러니 DLL 함수는 exe들이 자기 DLL의 context를 매번 함수 인자로 전해 줘야 했겠다. 초기화/해제도 당연히 수동으로 직접 해야 했으나.. crash가 발생해서 해제를 제대로 못 하고 레퍼런스 카운트가 꼬이면 그건 그대로 시스템 자원 누수로 이어졌다.
요즘은 레퍼런스 카운트 관리가 엉망이더라도 프로세스가 종료되면 그 프로세스가 갖고 있던 자원은 100% 회수되는 게 보장된다. 그리고 요즘은 실행이 강제 종료 당한 스레드에서 스택 메모리가 자동 회수되지 않는 것 정도만이 그나마 in-process leak인 반면, 그 시절엔 툭하면 시스템 차원에서의 자원 누수와 고갈을 아주 쉽게 야기할 수 있었다. Windows 9x는 도스와 시스템 영역 메모리가 보호되지 않는 것 정도 때문에만 불안정했지만 3.1은 이보다 훨씬 더 막장이었다.
컴퓨터 환경을 더 좋게 만들기 위한 노력은 단순히 물리적으로 회로 집적도를 높이는 것만으로 되는 게 아니며 그 자원을 효율적으로 활용할 수 있게 소프트웨어적으로도 머리를 엄청 많이 써야 했다는 걸 알 수 있다.
Posted by 사무엘
