1. ARM64 지원 예정
지난 3월 말에 날개셋 한글 입력기 10.85가 나왔다.
그런데 앞으로 1~2개월 안으로 다음 버전이 매우 높은 확률로 나오게 됐고, 무엇보다도 10.x를 완전히 졸업할 수 있게 됐다.
다음 버전의 번호는 11.0으로 확정이다. 지난 2020년 5월 말에 10.0이 나왔으니 10.x를 6년 만에 넘어서는 것이다.
그 원동력은 바로.. ARM64 (AArch64)용 에디션의 개발이다.
지난 2007년, 버전 4.8에서 x64가 지원된 뒤, 거의 19년 만에 새로운 아키텍처의 지원이 추가되다니 참 감격스럽다.
이제 프로그램의 About 화면에는 프로그램 자신의 비트수뿐만(32 또는 64비트) 아니라 아키텍처 이름도 표시된다. x86 또는 ARM.
프로그램의 빌드 기준 아키텍처와, 운영체제의 아키텍처가 동일하다면 프로그램 이름에만 아키텍처가 표시된다. 그러나 둘이 다르면 운영체제의 버전에다가도 아키텍처가 따로 표시된다.
ARM64 기기에서는 기존 x86 프로그램을 모두 저렇게 실행할 수 있구나. ㄷㄷㄷㄷ 그래도 얘들은 실행 성능이 ARM64 native 앱에 비할 바는 못 될 것이다.
편집기뿐만 아니라, 다른 프로그램들과 연계해서 동작하는 외부 모듈(IME)와 입력 패드까지 ARM64용 Windows에서 잘 동작하는 걸 보니 감격스럽다.
그리고 이걸 작업하면서 기존 x86/x64의 빌드 시스템도 변경하고 뭐랄까 최신화 고도화를 했다.
믿어지지 않지만 날개셋 한글 입력기는 지난 10여 년 동안, 거의 7.x부터 10.x에 이르기까지 꽤 구형 컴파일러인 Visual C++ 2010으로 개발돼 왔다. (더 옛날 4.2, 6.0, 2003, 2008을 거쳐..)
내 프로그램은 구형 Windows를 지원하고 특정 Visual C++ 버전의 런타임 DLL에 의존하지 않기 위해서 좀 특수한 방법을 써서 빌드되는데(특히 구형 x86 32비트 에디션..), 이걸 새 개발툴로 옮기는 게 좀 부담스러웠기 때문이다.
하지만 ARM64를 지원하려면 개발툴을 강제로 업데이트 하지 않을 수 없고, 그 특수한 방법도 새 환경에 맞게 업데이트 해야만 했다.
약간의 삽질 끝에 그 방법을 ARM64 에디션에다 적용하는 데 성공했고, 동일한 방법을 x86/x64에다가도 업데이트 해서 적용시켰다. 이제 날개셋 한글 입력기는 구닥다리 Visual C++ 2010이 아니라 2022로 빌드하게 됐다.
Visual C++ 2010은 C++11을 지원한 첫 버전이었던 만큼, 요즘 기준으로 보면 최신 C++ 문법을 제대로 지원을 못 하는 게 여럿 있다.
표준 문법인 for (type a:b)를 못 쓰고 for each(type A in B)만 써야 한다거나..
클래스 멤버 함수 안에서 선언한 auto 람다 함수 안에서 바깥 멤버 변수/함수의 인식이 제대로 안 된다거나..
이런 식으로 아쉬운 게 적지 않았다. 그런 한계들이 드디어 해소됐다.
지난번에 타자연습은 4.0을 내면서 개발툴을 최신으로 바꿔 버렸는데, 뒤이어 입력기도 극악의 레거시 호환성을 그대로 유지하면서 개발 환경은 쇄신을 이뤄냈다. ARM64 지원과 함께 이 정도 변화가 생겼으니 10.85에서 11.0으로 버전업도 가능해진 것이다.
이렇게 ARM64 에디션이 나오게 된 것은..
거금을 들여 Microsoft 서피스 개발 장비를 후원해 주신 분이 계셨던 덕분이다. 프로그램 도움말의 '감사의 글'에 이분 성함이 들어갈 예정이다.
(요즘 메모리가 너무 비싸져서 컴퓨터 가격도 내가 수 년 전에 알던 그 가격이 아니던데..
AI 돌리거나 훈련시키느라 갈아넣는 컴퓨팅 자원이 늘어나는 바람에 사람이 쓰는 컴퓨터까지 부품이 비싸졌다고 한다.
이거 마치 바이오 디젤 수요 때문에 사람이 먹을 농작물 식재료 가격이 뛰는 것과 비슷한 현상 같다.)
2. 프로그래밍 이슈 I
같은 코드를 컴파일 했을 때, ARM64 네이티브 바이너리는 x64 바이너리와 크기가 의외로 그렇게 큰 차이가 나지 않았다. 사실, 마소에서는 기존 x64와 최대한 비슷하게, 이질감 없이 ARM64를 도입하려고 정말 애쓴 것 같다.
ARM64 컴에서도 x64 바이너리는 기계어 코드를 에뮬레이션 해서 돌아가기는 한다. 둘은 설계 방식이 서로 굉장히 이질적인 아키텍처일 텐데 말이다.
Windows Installer는 msi의 CPU 종류를 여전히 x86, x64, IA64 셋으로만 구분하지 여기에 ARM64를 추가하지는 않은 듯하다. (물론 IA64는 오늘날은 완전히 망하고 죽은 아키텍처이다만..)
ARM64에서는 x64와 x86 프로그램을 모두 실행할 수 있음에도 불구하고 Program Files나 System32 디렉터리에 또 무슨 Program Files (x64) 이런 변종이 추가되지는 않았더라. x64만을 위한 별도의 디렉터리 같은 건 없다. 개인적으로 무척 궁금했던 사항이었다.
물론 ARM도 처음에는 32비트 아키텍처로 시작했다가 2010년대 중후반부터 64비트로 넘어갔다. 그럼 Windows on ARM도 32비트 ARM 레거시에 대한 고려가 필요하지 않나 싶었는데.. 결론부터 말하자면 그렇지는 않은 듯하다.
모바일이나 임베디드가 아닌 PC용 Windows가 ARM으로 이식된 건 내력이 아주 짧다. ARM에서는 거의 곧장 64비트 시대가 시작됐기 때문에 ARM 32비트의 잔재는 거의 유니코드 1.0이라든가 조합형 한글 MS-DOS처럼 그냥 지원을 끊고 존재감을 없애고 짬처리 시킨 모양이다.
32비트 환경은 압도적인 레거시를 자랑하는 x86만 고려하면 된다. 하긴 Visual Studio고 Office고 카카오톡이고 다 64비트로 넘어갔으니 2020년대 중반쯤 되니 x86 32비트 프로그램을 접할 일이 생각보다 많이 줄어들었다.
구닥다리 VGA가 그래픽 카드들 간의 최소 공통분모였듯이 x86은 이제 여러 64비트 CPU들 간의 최소 공통분모가 된 것 같다. 뭐 그건 그렇고..
마소에서는 더 나아가 ARM64EC라고 한 바이너리에 x64와 ARM64의 기계어 코드가 같이 들어있는 일종의 fat binary라는 ABI도 내놓았다. 내 타자연습 프로그램은 이제 32비트와의 접점을 끊은 단독 프로그램이니 차라리 저런 형태로 빌드하는 게 도움이 될지도 모르겠는데.. 그건 앞으로 생각해 봐야겠다.
아무튼.. 마소는 x86과 ARM64는 번거롭게 서로 따로 놀게 만들지 않고 최대한 융합시키려고 하는 것 같다.
3. 프로그래밍 이슈 II
그리고 요즘 Windows API는 무슨 이유인지는 몰라도 실행 중인 프로세서 종류나 운영체제의 버전을 자꾸 샌드박스화하는 추세이다.
예전부터 있었던 구형 API로는 나중에 출시된 Windows 버전이나 새로운 CPU 아키텍처 값을 알 수 없게 하는 거. 이게 마소의 오랜 개발 방침이기라도 한 것 같다.
가령, GetSystemInfo는 현재 실행 중인 컴퓨터의 CPU 및 비트수를 알려주는 함수인데.. 32비트 프로그램이 64비트 Windows에서 실행될 때는 언제나 x86 32비트만 되돌렸다.
실제 CPU를 정확하게 알려면 굳이 Windows XP에서 새로 추가된 GetNativeSystemInfo를 써야 했다.
그랬던 것처럼, 지금 x64 프로그램은 자기가 ARM64 프로세서에서 돌아가는지 진짜 x64 전용 프로세서에서 돌아가는지를 기존 API만 써서는 알 수 없다. 그래서 IsWow64Process2 같은 새 API를 또 써야 한다. 이런 식이다.;
컴퓨터 환경뿐만 아니라 운영체제 버전도 말이다.
GetVersionEx 함수로는 운영체제 진짜 버전을 제대로 알 수 없게 된 지 10년쯤 넘었고 말이다. (Windows 8이 상한)
왜 이렇게 API를 쓸데없이 지저분하고 복잡하게 관리하는지 나로서는 도저히 모르겠다.
이런 것들이 지금 프로그램 개발하면서 개인적인 의문으로 남는다.
4. 맺는말
현재 날개셋 한글 입력기의 x86 계열 배포 패키지에는 외부 모듈이 Windows의 system 디렉터리에 설치되고 있다.
꼭 그럴 필요는 없지만 과거 Windows 9x와 XP 시절까지 존재했던 IME 프로토콜과의 호환성 때문에 그 관행이 유지되고 있다.
허나, ARM64에서는 Windows가 10/11이 원조이니 TSF 프로토콜만 지원하면 되고 IME는 전혀 고려하지 않아도 된다.
그러니 ARM64 에디션에서는 외부 모듈을 굳이 system이 아니라 내 프로그램 디렉터리에다 둘 예정이다.
생각 같아서는 system\IME 자리가 탐나기는 하는데.. 여기는 일단은 마소에서 기본 제공되는 IME들만 들어가는 곳이고 3rd party 프로그램에게 개방된 곳이 아니라고 한다.
이상이다.
ARM64 포팅 말고도 여러 자잘한 작업들을 할 게 더 있기 때문에 다음 버전이 곧장 바로 나오지는 못한다. 입력기의 경우, 한글 로마자 입력기에 자그마한 개선 사항이 들어갔다.
- 쿼티나 드보락이 아니라 그냥 현재 지정돼 있는 영문 글쇠배열에다가 한글 대응 규칙만 추가하는 옵션을 추가했다. 그래서 콜맥 같은 임의의 custom 글쇠배열도 한글 로마자 입력 용도로 바로 사용할 수 있게 했다. 이것도 진작에 필요했던 기능 같은데 이제야 실현됐다.
- '표준' 방식에서 H, U, L 글쇠의 특수 수식이 언제나 Qwerty 자리 기준으로만 배당되던 중대한 문제를 발견하여 수정했다.
그 밖에, '낱자 처리'의 보기 옵션 체크박스들을 건드리더라도 현재 낱자 목록들의 선택막대는 보존되고 남아 있게끔 UI를 개선하고자 한다. 보기 옵션은 뭔가 설정값을 실제로 변경하는 기능이 아니기 때문이다.
타자연습의 경우,
화면 DPI 150%에서 '좌우 대조' 방식으로 긴글 연습을 하면 화면 아래에 잔상이 남는 자잘한 문제를 해결할 예정이다.
그리고 영문 UI+코드 페이지를 사용하고 있을 때, 콤보박스 안의 한글 데이터가 깨지는 문제를 해결했다. 이건 원래는 존재하지 않던 현상인데 프로그램 빌드 방식이 크게 바뀌었던 4.0에서만 일시적으로 재발한 것이다.
끝으로.. 요즘 Windows에는 사용자 계정 컨트롤로도 모자라서 smart app control인지 뭔지이상한 보안 정책이 추가됐다. 디지털 서명이 없는 msi는 그냥 설치가 안 되게 막아 버리고 있어서 이것도 문제이더라.
내 홈페이지의 https 도입, 그리고 배포 패키지에 msi 도입도 더 진지하게 고민해 봐야겠다.
Posted by 사무엘
