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

호박 농사 근황을 전했으니 다음으로 날개셋 프로그램의 개발 소식도 전하도록 하겠다.
이번 9월 동안 날개셋 한글 입력기는 ARM64 플랫폼의 지원과 관련하여 굉장히 흥미진진한 기능 개선과 개발이 진행됐다.
그 발단은 기존 11.0이 ARM64용 MS Office 프로그램에서 전혀 동작하지 않는다는 버그 신고 메일이었다. 이 글에서는 그 내역을 공개하고자 한다.

지난 7월에 11.0 버전은 프로그램들을 모두 ARM64 방식으로 빌드하고 테스트 하는 단순한 방식으로 만들어졌다.
그렇게 했더니, 날개셋 외부 모듈이 순수하게 ARM64 방식으로 빌드된 프로그램에서는 잘 동작했다. 그러나 ARM64EC라고, ARM64 네이티브이긴 하지만 x64 명령어도 에뮬레이션으로 같이 지원하는 ABI 환경에서는 동작하지 못했다.

ARM64EC 프로세스에서는 x64 또는, 똑같이 ARM64EC 방식으로 빌드된 DLL만 동작 가능하다. 그리고 반대로 x64 프로세스에서도 같은 x64 또는 ARM64EC 방식 DLL을 실행할 수 있다. EC는 emulation compatible의 이니셜이라나..?? 비트 수가 다른 16-32비트, 32-64비트 간에는 thunking이라는 말을 썼는데 같은 64비트끼리는 그냥 에뮬레이션을 하는가 보다.
그 반면, 순수 ARM64는 저런 식으로 x64 바이너리와 소통을 할 수 없다.

마소에서 굳이 ARM64EC라는 걸 번거롭게 만든 이유는.. 그야말로 천문학적으로 방대한 프로그램들을 한순간에 ARM64로 다 포팅하는 게 현실적으로 어렵기 때문이다. x64 레거시를 최대한 활용하기 위해서이다. 그렇기 때문에 한 덩치 하는 거대한 프로그램이 ARM64EC 방식으로 만들어지는 경향이 있다. 저 MS Office처럼 말이다.

그래서 Windows on ARM에서는.. 꽤 삽질스럽고 번거로워 보이지만, 한 파일로 순수 ARM64와 ARM64EC에 모두 대처 가능한 ARM64X라는 변칙적인 fat binary를 도입했다. Windows 10 시절엔 없었고 11에서 새로 추가된 모양이다.
얘들은 크기가 매우 크다. 그리고 이건 당연한 말이지만 EXE는 해당사항 없고 오로지 DLL만을 위한 옵션이다.

과거에 x64 플랫폼이 처음 도입됐을 때는 Program Files와 Program Files (x86), 그리고 system32와 SysWow64처럼 프로그램 디렉터리를 비트수 별로 분리하는 방식이 쓰였다.
그러나 ARM64 기기에서 x64를 포용할 때는 디렉터리를 또 분리하기가 난감하니 EC라는 요상한 ABI를 도입하고 fat binary를 도입한 것으로 보인다.

순수 ARM64 앱에서만 돌아가는 게 확실한 DLL은 예전처럼 ARM64 방식으로만 빌드하면 된다.
그러나 IME처럼 아무 임의의 EXE에서 로딩될 수 있는 범용적인 DLL은 ARM64X 방식으로 빌드해야 하더라. Windows의 시스템 DLL들도 이 방식으로 빌드됐다.

그래서 내 한글 입력기 역시.. 제일 먼저 (1) dll 기반 바이너리들을 모두 ARM64X 방식으로 빌드함으로써 외부 모듈의 제일 급한 문제를 해결했다. 이제 내 프로그램의 ARM64 에디션은 MS Office에서도 잘 동작한다.
이렇게 빌드함으로써 4MB 남짓이던 배포 패키지의 크기도 4.5MB 정도로 약간 더 커졌다.

그리고 이것만 하면 싱거우니 (2) About 대화상자에도 실행 환경과 관련된 정보를 더 추가했다.
현재 날개셋 한글 입력기가 순수 ARM64인지 아니면 ARM64EC인지?? 그리고 ARM64EC인 경우는 날개셋을 사용하는 실행 파일이 x64인지 아니면 ARM64EC인지? 요걸 추가로 알려주게 했다.

• 운영체제의 버전과 기준 아키텍처
• 날개셋 한글 입력기의 아키텍처
• 외부 모듈 한정으로, 구동 중인 EXE 프로그램의 아키텍처

32비트 x86 에디션의 경우, Windows 9x에서 16비트 프로세스가 실행 중인 것을 감지하는 기능이 있었다.
16비트 exe의 내부에서는 32비트 DLL이 GetModuleHandle(NULL)을 호출했을 때 일반적인 32비트 EXE 같은 주소가 아니라 그냥 kernel32.dll 같은 높은 주소가 돌아오기 때문이다. (NT 계열에서는 그냥 ntvdm.exe의 주소가 돌아오기 때문에 해당사항 없음)

과거에 그렇게 16-bit라는 문구가 찍히던 자리에 이제는 x64라는 문구를 찍는 로직이 추가되었다. ARM64EC 코드가 ARM64가 아니라 x64에서 실행될 때 말이다. 아주 재미있는 변화이다.
이 참에 외부 모듈의 x64 에디션이 ARM64 컴터에서 설치와 등록이 시도된 경우, "이 컴터에서는 ARM64 에디션을 사용해 주세요" 경고 메시지도 표시하게 했다. ARM64에서 x64 에디션을 설치하면 외부 모듈이 x64와 ARM64EC 앱에서밖에 동작을 못 할 것이기 때문이다. (순수 ARM64 앱에서는 동작 불가)

외부 모듈에서 ARM64EC 지원 작업은 이렇게 마무리됐다.
하지만 이게 전부가 아니다. 그 다음으로, hooking을 통해 문자 입력을 구현하는 (3) 입력 패드에도 아주 흥미진진한 작업이 진행됐다.
이 프로그램은 모든 프로그램에서 동작하기 위해서 64비트와 32비트 프로그램이 같이 동작하는 형태로 만들어졌다.
system-global hook은 CPU 아키텍처별로 다 따로 만들어서 운용해야 하기 때문이다.

x86과 x64 둘만 고려하면 되던 시절에는 프로그램 로직이 간단한 편이었다. 그러나 여기에 ARM64를 추가하자니 프로그램을 여러 군데 고치고 확장해야 했다.

host와 guest를 단순히 비트 수만으로 분별할 수 없으니 CPU 아키텍처를 명시해야 하며, ARM64는 x86뿐만 아니라 ARM64EC로 guest를 두 가지를 고려해야 한다.
그리고 반대로 x86도 parent host로 가능한 대상이 오로지 x64 단일이 아니라 ARM64일 수도 있는 것을 고려해야 한다.
코딩에서 일대일(단수)이던 게 일대다(복수)로 바뀌는 건 생각보다 복잡한 변화이다.
표로 정리하면 이렇다. 이 모든 것이 단일 소스 코드의 조건부 컴파일만으로 조절된다.

그래도 ARM64EC 프로세스에서 hook을 만들고, hook procedure DLL을 ARM64X 방식으로 만들어 주니 ARM64EC 앱과 x64 앱에서도 메시지를 가로채고 변조해서 문자 입력 기능을 구현할 수 있었다.
이로써 외부 모듈과 입력 패드가 ARM64 자체뿐만 아니라 ARM64 Windows에서 실행되는 모든 CPU 방식을 제대로 지원하게 되었다. 만세~! 마소가 ARM64는 과거의 Itanium처럼 서로 생까는 별개의 CPU로 취급하지 않고 x64와 최대한 융합을 도모한다는 게 느껴졌다.

이것만으로도 다음 버전 11.01 이상은 9월이나 10월쯤에 나올 수 있게 됐다. 하지만 달랑 이것뿐만 아니라 다른 개선 사항도 가능한 한 많이 들어갔으면 좋겠다.
이상이다. 2020년대 들어서 날개셋 한글 입력기의 개발 속도가 끔찍히 느려졌음에도 불구하고, 프로그램을 꾸준히 사용해 주시고 후원도 해 주신 분들이 계신 것에 진심으로 감사드린다.

※ 참고: ARM32는?

사실, ARM이라는 건 예로부터 Android 운영체제를 돌리는 스마트폰용 CPU 아키텍처로 더 유명했다. 얘는 처음에는 32비트로 시작했다가 2010년대 후반쯤부터 순식간에 데스크톱 PC와 동일하게 64비트로 넘어갔다.
글쎄, Visual C++에서도 32비트 ARM 플랫폼이 타겟으로 존재는 하던데 이건 뭔지..??

지난 2012~13년 Windows 8 시절에, Windows NT 커널이 32비트 ARM용으로 포팅되어 Windows RT라는 서피스의 전신뻘 기기에 들어간 적이 있었다.
그러나 이건.. 마소에서 ARM CPU 기반의 모바일 기기에 대한 개념이 부족해서 삽질했던 흔적에 더 가깝다. 그 시절에 Windows 8은 아예 시작 버튼이 없었다는 걸 생각해 보자;;;

3rd party 개발자들은 Windows RT 환경에서는 native 데스크톱이 아니라 metro 앱만 만들 수 있었다. 그리고 내 기억이 맞다면 저 기기는 일반적인 데스크톱 PC처럼 임의의 앱을 마음대로 설치할 수 있는 형태가 아니었다.
이 정도면 스마트폰이 아니라 아예 피처폰을 추구한 건지? Windows on ARM이 64비트 기반으로 나중에 괜히 따로 나온 게 아니었다.

ARM32는 퇴물로 전락한 데다, x86처럼 유의미한 호환성 자산도 전혀 아니었다. 그래서 금세 정리되고 잊혀졌다. 적어도 데스크톱용 Windows 생태계에서는 말이다.
그러니 본인은 날개셋 한글 입력기도 ARM 환경에서는 처음부터 64비트만 고려하면 된다는 걸 이번 기회에 확실하게 도장을 찍었다. 32비트를 지원하는 건 x86만으로 족하다.

Posted by 사무엘