1. 새 노트북과 새 폰
본인은 2010년대 초중반까지 노트북은 맥북을, 폰은 삼성 안드로이드 폰을 사용해 왔다. 그랬는데 노트북은 이제 성능이 너무 뒤쳐졌으며 배터리 용량도 너무 감소했다.
그리고 폰도 하필 약정이 끝날 무렵부터 배터리가 급격히 빨리 줄어들기 시작했으며, 그로부터 몇 달 되지 않아 걸핏하면 툭툭 꺼지기 시작했다. 폰이 꺼지지 않도록 잘 간수하는(?) 게 마치 옛날에 집안 불씨가 안 꺼지게 간수하는 것 같은 일이 됐다. 서비스센터를 방문해 보니 배터리나 전원 단자 문제가 아니라 순전히 메인보드의 문제라는 말을 들었다.
이런 이유로 인해 본인은 2019년 초의 비슷한 시기에 전화기와 노트북을 모두 교체하게 됐다. 폰은 고맙게도 남아도는 준중고 기기를 그냥 주신 분이 직장에 계셔서 본인은 신규 개통도, 번호 이동도 아닌 기기 변경이란 걸 했다. 그리고 졸지에 생각지도 않았던 아이폰 유저의 대열에 합류했다.
그 반면, 노트북은 맥OS를 굳이 더 쓸 필요를 느끼지 않아서 오랜만에 국산 일반 Windows 기계로 복귀했다. 예전과 반대로 전화기를 애플 것으로 쓰게 된 셈이다.
내가 원하는 노트북 컴터는..
굳이 그렇게 무리하게 얇거나 가볍지는 않아도 된다. 화면 해상도도 그냥 Full HD 1920*1080 급이면 넉넉하고 충분하다. 굳이 2000 안 넘어가도 된다.
또한, 요즘은 무선 인터넷 인프라가 워낙 널리 깔렸으니 광학 드라이브나 유선 랜 단자쯤은 본체에 안 달려도 크게 불편하지는 않은 지경이 된 거 같다.
다만, 램은 8기가가 뭐야 8기가.. 장난하나? 안 그래도 추후 확장하기도 어려운 주제에..
뭐, 저걸로도 Windows 10 깔고 작업 자체는 가능하다. 하지만 개발툴, 가상 머신, 5개 이상 탭을 열어 놓은 크롬 브라우저, 문서 작업을 위한 오피스 등등을 한꺼번에 너끈히 구동하면서 5년 정도 버티려면 요즘은 정말 못 해도 12기가 이상은 달아야 된다.
(메모리가 부족해서 프로그램을 그렇게 많이 한꺼번에 돌리지 못하면? 고성능 CPU라든가, 요즘 놋붉들이 그렇게도 강조하는 큼직한 화면이 별 의미가 없다. 그 넓은 화면에다가 여러 프로그램들을 도배하려 해도 메모리에서 결국 병목이 걸린다!)
Windows 7 이래로 10까지 Windows의 최소/권장 사양의 메모리 용량이 계속 똑같이 1GB/2GB(64비트 기준)인 건.. 개인적으로 좀 사기극이고 허위 과장 광고라고 생각한다. 전혀 현실적이지 않다.
그리고.. 본인은 아재 사고방식이어서 그런지, SSD를 영 미덥지 않게 생각해 왔다. 빠른 건 좋지만 용량이 너무 부족하기 때문이다. 하지만 세월이 흐르니 SSD의 가격도 놀라울 정도로 많이 떨어지고 512GB급 물건도 나오다니 기술의 발달에 경이로움을 느낀다.
기계식과 전자식의 차이는 확연히 드러난다. SSD가 아니면 이 정도 성능과 용량을 자랑하는 노트북 컴이 이렇게 조용하고 가볍고 빠르게 돌아갈 수가 없을 것이다.
2. 새 컴파일러
컴퓨터를 새로 세팅하면서 Visual C++도 드디어 최신 버전을 깔아 봤다. 전에도 얘기한 적이 있지만 IDE, 플랫폼 SDK, 그리고 컴파일러 툴킷이 서로 완전히 분리되고 제각기 따로 노는 게 가능해진 것은 매우 바람직한 변화이다. 그리고 IntelliSense DB를 저장하는 방식이 예전의 MS SQL Server Compact Edition (*.sdf)에서 SQLite (*.vc.db)로 바뀌어 있더라.
날개셋 한글 입력기의 소스를 빌드해 보니 다음 사항들만 '경고'로 걸리고 나머지는 문제 없이 컴파일 된다.
(1) GetVersionEx 함수를 사용하는 부분이 deprecated로 처리됐다. Windows 8.1 내지 10부터는 운영체제의 세부 버전을 체크하는 방식이 이 함수를 사용하지 않는 다른 쪽으로 바뀌었기 때문이다. 다만, 옛 함수가 strcpy 내지 gets처럼 보안 위험 때문에 deprecated 된 건 아니다.
(2) C++에서는 포인터를 정수형으로 typecast 하기 위해서 잘 알다시피 reinterpret_cast 연산자를 사용하는데, 포인터형보다 작은 크기인 char, short, UINT(64비트 환경 한정)로 바꾼다면 언제나 경고가 뜨게 됐다. 이건 static_cast로 형변환을 한 단계 더 거쳐야 된다.
(3) delay-load 콜백 함수의 포인터를 보관하는 전역변수가 보안 강화를 위해 const 형태로 바뀌었다. 이 변수는 이제 실행 도중에 값이 변경될 수 없으며, 우리 코드에서 이 변수를 정의하면서 단 한 번 주소를 지정해 줄 수만 있다.
const PfnDliHook __pfnDliNotifyHook2 = _DelayDLLNotifyHook; 이런 식으로 말이다.
이 변수는 실행 파일의 read-only 영역에 보관되기 때문에 const_cast 같은 연산자를 이용해서 값을 강제로 변경하려 하면.. 그냥 crash가 발생하게 된다.
1은 그냥 어쩔 수 없고, 2는 경고가 안 뜨도록 코드를 고치고, 3은 조치를 취했다.
3. 날개셋 한글 입력기의 개선 사항
이렇게 개인용 컴퓨터가 바뀌고 개발 환경이 바뀌자, 날개셋 한글 입력기에 고칠 점이 몇 가지 눈에 띄기 시작했다. 요런 것들을 반영하면 또 0.01 정도 버전 숫자를 올릴 수 있을 것 같다.
(1) 이제 Windows 10이 세상을 평정했으니.. About 대화상자에 표시되는 운영체제 버전 정보에서도 10일 때는 년/월 형태의 세부 버전 번호(1709, 1809 같은)가 나타나게 했다. 아래 그림의 위/아래가 before과 after이다.
(2) 입력 패드는 지금 떠 있는 도구들을 모두 닫으면 프로그램을 곧장 종료하게 하는 /S 옵션이란 게 있는데.. 이게 프로그램 내부 구조를 개편하는 과정에서 언제부턴가 제대로 동작하지 않게 된 것을 뒤늦게 발견했다. 다음 버전에서는 고쳐질 예정이다.
(3) 글꼴을 본뜰 때 CJK 확장 한자 B뿐만 아니라 그 뒤의 C, D도 추가로 본뜨게 했다. 지난번 emoji에 이어서 글꼴 본뜨기 스크립트가 또 바뀌었다.
이쪽 SIP(보충 한자 평면) 한자들은 글자 수가 너무 많은데 일상생활에서 별로 쓰이지 않는 것들이고, BMP(기본 다국어 평면)보다 지원 시기가 훨씬 더 늦은 점으로 인해.. 지원하는 글꼴들도 통상적인 BMP 영역 한자용 글꼴과는 달리 비트맵 글립이 들어있지 않은 편이다.
그래서 16픽셀 글꼴은 썩 보기 좋지 않으며, 24픽셀은 돼야 볼 만하다.
(4) Vista 이래로 줄곧 그랬는지 아니면 8/10에서 보안이 강화돼서 그런 건지는 모르겠지만.. UAC를 켜 놓은 상태에서 ProgramData 디렉터리에는 새로운 파일을 생성할 수는 있지만 프로그램이 설치해 놓은 파일을 사용자가 임의로 고치는 건 안 되는가 보다.
본인은 거기에 있는 파일은 사용자가 마음대로 수정할 수 있다고 가정하고 글꼴 본뜨기 스크립트 같은 일부 파일은 사용자가 곧장 열어서 사용할 수 있게 했었다. 그런데 그렇게 할 수 없다면... 데이터 파일을 운용하는 방식을 바꾸든가 해야 할 것 같다. 비슷한 문제를 날개셋 타자연습의 연습글 목록 xml에서 이미 한번 겪은 바 있다.
(5) 지금까지 사용자에게서 옛한글 관련 동작 때문에 예기치 않은 오동작 의심 증세 문의를 많이 받았다. 옛한글은 일상생활에서는 안 쓰이다시피하니.. 다음 버전에서는 프로그램을 기본 설치했을 때 '세벌식 옛한글'을 아예 빼 버릴까도 고민 중이다.
장기적으로는 한글 표현 옵션 탭에서도 한양 PUA 내지 유니코드 1.1 레거시는 더 꽁꽁 숨겨 놓고 접근하기 어렵게 할 계획이다. 이제 쓰일 일이 없어졌으니 말이다.
(6) 그리고 좀 더 유의미한 변화로.. 휠 내지 노트북 터치패드를 아주 미세하게 굴렸을 때의 스크롤 동작을 개선했다. 이에 대해서는 다음 항목에서 더 자세히 설명하도록 하겠다.
4. 세밀하게 움직이는 휠
마우스 휠이란 게 PC에 도입된 지 20년이 넘었다. 휠이 도는 단위는 기본적으로 칸 단위로 구획이 나뉘어 있으며, 한 칸 돌 때마다 WHEEL_DELTA (120)이라는 값이 전달된다. 120이라는 값은 약수가 많아서(2*2*2*3*5) 다양하게 쪼개기 편한 수라는 이유로 선택된 것이다.
마소에서는 지금은 마우스 휠이 칸이라는 덩어리 단위로 돌아가지만, 미래에 연속된 단위로 아주 부드럽고 세밀하게 돌아가는 휠도 등장할 수 있을 거라고 예상했다. 그래서 단순히 움직인 칸 수가 아니라 거기에 delta를 곱한 값을 되돌리게 여유를 두고 메시지를 설계했다.
저게 1990년대 중후반의 일이다. 하지만 본인은 부드럽게 세밀하게 돌아가는 마우스 휠은 아직까지 구경하지 못했다. 그 대신 그 동작은 노트북의 터치패드/트랙패드가 물려받았다. 처음에는 손가락의 궤적을 따라 마우스 포인터를 옮기는 기능밖에 없었지만 나중에는 패드의 오른쪽 끝을 수직으로 문지른다거나, 아무 곳이나 두 손가락으로 수직으로 문지르는 것을 스크롤로 따로 인식하게 된 것이다.
그 스크롤 요청을 하는 방식이 예전에는 그 윈도우에 대해서 SetScrollInfo/Pos 함수를 호출하고 WM_H/VSCROLL 메시지를 생성하는 것이었다. 화면 캡처 프로그램이 제공하는 스크롤 캡처 기능이 어떻게 구현됐겠는지를 생각하면 된다.
그랬는데 요즘은 WM_MOUSEWHEEL을 보내는 게 대세이다. 터치패드의 종류에 따라 동작이 케바케이긴 하지만, 이때 옛날 동작과의 호환을 유지하기 위해 WHEEL_DELTA의 배수 단위로 스크롤 요청을 하는 경우도 있고, 아니면 문지른 속도에 따라 그 이하의 값을 보내는 경우도 있다. 2010년대부터는.. 스크롤 하다가 손을 급격하게 확 떼면 스크롤도 마치 관성을 받은 듯이 한동안 지속되다가 멈추는 동작까지도 구현돼 있다.
스크롤 요청을 받은 윈도우가 그림이나 웹페이지처럼 원래 픽셀 수준의 부드러운 스크롤을 지원하고 있다면 WHEEL_DELTA로부터 산출한 비율만치 자연스럽게 스크롤을 하면 된다.
하지만 픽셀이 아닌 글자 줄 수 단위로 이산적이고 각진(?) 스크롤을 지원하는 윈도우는 사정이 다르다. 너무 작은 delta 값은 나눗셈 과정에서 아예 0으로 버려지고 없어져서 스크롤이 전혀 처리되지 않을 수 있다. 내부적으로 델타 값을 보관하고 있다가 그 합이 양수나 음수로 WHEEL_DELTA의 배수가 됐을 때 줄을 옮기도록 다소 번거로운 조치를 취해야 한다.
그런데 동일한 각속도로 굴렸어도 120 단위만 지원하는 휠을 굴렸을 때와, 그 이상 정밀한 휠을 굴렸을 때 들어오는 delta값의 규모가 서로 같지 않다. 휠의 종류를 얻을 수 있는 API는 내가 알기로 없다. 그렇기 때문에 그 종류는 WM_MOUSEWHEEL 메시지 때 날아오는 값들을 보며 얼추 짐작을 해야 한다. (120보다 작은 값이 들어오질 않는가?)
Windows의 리스트 박스에서 마우스 휠을 굴려 보면, 처음에는 목록이 한 줄 정도는 픽셀 단위로 답답하게 굼뜨면서 스크롤 되다가 그 뒤 나중에는 줄 단위로 비교적 빠르게 스크롤 되는 걸 볼 수 있다. 이게.. 휠의 종류와 동작 방식을 감지하는, 한번 "간보는" 동작이 아닌가 개인적으로 생각한다.
날개셋 한글 입력기에서 이런 정밀한 휠을 지원하도록 조치가 취해진 곳은 날개셋의 고유한 에디트 컨트롤, 문자표 리스트, 그리고 편집기의 화면 인쇄(300% 이상의 배율로 확대했을 때)창이다. 사실, 내 것이 아닌 어떤 노트북 PC에서 날개셋 편집기에서 휠 스크롤이 잘 안 된다는 걸 오래 전부터 어렴풋이 경험하긴 했는데 그 당시에는 그다지 문제 의식을 못 느끼고 넘어갔던 것 같다.
처음에는 휠을 굴렸을 때 키보드 포커스를 받고 있는 창이 스크롤 됐지만 Windows 8인가 10부터는 마우스 포인터가 놓여 있는 창이 스크롤 된다. 그리고 저렇게 정밀한 휠이 도입되고, 세로 스크롤뿐만 아니라 가로 휠 스크롤 메시지도 도입되니.. 휠도 마치 고해상도 dpi만큼이나 지금까지 은근히 많이 변했다.
Posted by 사무엘
