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

※ 10.0 (2010)

2008 이후 2010도 참 걸출한 작품이었다.
IDE가 MS Office 엔진이 아닌 WPF 기반으로 다시 만들어졌으며, 프로젝트 파일은 현재처럼 확장자에 x자가 붙고 내부 형식이 미묘하게 달라졌다. IDE와 툴체인 및 SDK 간의 분리가 가능해지고 융통성이 생겼다.
인텔리센스 엔진이 구닥다리 ncb 파일을 버리고, 전문적인 백그라운드 컴파일러와 DB 엔진을 기반으로 전면 개편됐다. 덕분에 정확도가 6.0이나 200x 시절보다 훨씬 더 향상됐다. 그리고 이제 #include 헤더 파일에 대해서도 우클릭해서 '요 파일 열기'가 가능해졌다.

CRT와 MFC DLL에 대해 side-by-side assembly 강제 정책은 철회됐으며... C++11 문법이 초보적인 수준으로나마 도입됐다. R-value 참조자 &&라든가 auto 람다 함수를 쓸 수 있게 됐다.
다만, 내 개인적으로는 시퍼런 IDE 외형이 좀 구리고 이질적으로;; 느껴진다. 그리고 UI 요소를 customize할 때 toolbar의 폭을 마우스 드래그가 아니라 픽셀수 숫자로 입력한다던가(뜨악~);; 몇몇 UI 기능은 200x시절보다 불편해졌다.
그게 오늘날 202x까지 개선 없이 그대로 이어지고 있다. 개발 우선순위가 낮아서 그런지 이런 것까지 살펴볼 여유가 없는가 보다.

※ 2012 (버전 11)

얘는 일단 IDE의 외형이.. 그 시절 유행하던 Windows 8 metro 디자인 물을 먹었는지 아주 새끈한 은백색 풍으로 바뀌었다. 프로그램 창에서 caption이나 border 같은 non-client 영역까지 전부 운영체제의 표준 외형을 벗어난 첫 버전이 바로 2012이다.

개발툴로서는 같은 최적화 세팅에서 컴파일 속도가 2010보다 더 빨라졌고.. 정적 분석이 bundle로 제공되기 시작했다.
신택스 컬러링도 예전보다 더 컬러풀해져서 #define, typedef, num 등이 모두 구분되어 나오기 시작했다.
#if에 걸려서 컴파일되지 않는 부분이 흐려지기 시작한 건 2010부터인지 2012부터인지 모르겠다. 200x는 확실히 아니었음..

그리고 이 버전부터 서비스 팩이라는 게 없어지고 update N 이렇게 명칭이 바뀌었다. 마소 제품들은 2010년을 전후한 Windows 7, Office 2010, Visual Studio 2010이 서비스 팩이란 게 존재했던 마지막 버전이었다.
로컬 하드에 설치 저장되던 방대한 규모의 MSDN 레퍼런스도 이때부터 사실상 없어졌다.

※ 2013 (버전 12)

2012 이후로 겨우 1년 남짓 만에 메이저 버전이 또 올라갔다. 마치 Windows 8과 8.1의 관계인 것 같은데..

얘는 C++11 문법 지원이 더 강화된 것, 그리고 무엇보다 Express 에디션 대신, 개인/인디 개발자를 위한 Community 에디션이 도입된 것이 크게 기억에 남는다.
Community 에디션은 5인 이하, 매출 얼마 이하의 소규모 인디 개발자이기만 하면 무료로 사용 가능하다. Express에서는 봉인돼 있던 MFC고 x64고 다 사용 가능하다. 2010년대의 컴퓨팅 환경에서 MFC는 몰라도 이제 x64 타겟을 만들 수 없다는 건 어불성설이 됐으니까..

뭐, Visual Studio만 그런 건 아니겠지만 요즘 버전들은 시리얼 번호 입력이란 게 없이 바로 설치 가능하다. 그 대신 실행 후에 마소 계정 로그인이 필요해졌을 뿐이다. 선설치, 후접속 결제인 듯..

※ 2015 (버전 14)

얘는 CRT 체계가 Windows 10 스타일로 전면 개편된 것이 가장 중요하다. 이때부터 지금까지 툴체인의 메이저 버전이 14, _MSC_VER 값도 19xx대로 변함없이 유지되고 있기 때문이다. vcruntime140, mfc140, msvcp140 말이다. Visual Studio의 버전만 올라가지, 툴체인은 메이저 버전이 올라가지 않기 시작했다.

그리고 2010 시절에 전면 개편됐던 인텔리센스 겸 심벌 browse DB의 내부 구조도 2015의 어느 업데이트 때부터 야금야금 바뀌었다. 원래 *.sdf 파일을 쓰던 게 *.VC.db 라고 바뀌었으며, DB 엔진도 자기네 Microsoft SQL Server Compact edition을 쓰던 게 SQLite로 교체됐다. 이것도 오늘날까지 이어지는 꽤 중요한 변화이다.
2015 이전 버전은 Visual Studio를 설치하면서 MS SQL server 2008이니 어쩌구가 야금야금 같이 설치됐던 반면, 현재는 그런 관행이 없어졌다.

※ 2017 (버전 15)

얘는 프로그램의 설치 및 업데이트 시스템이 현재 형태로 전면 개편된 최초의 버전이다. 소규모 업데이트도 워낙 잦아지니 지금처럼 버전 번호에 숫자를 하나 더 추가하는 형태로 바꿨다. (그러므로 Update N라는 표기는 2012부터 2015까지만 사용된 셈..)
IDE의 기본 색상도 흰색이 아니라 약간 연보라색 같은 파란색.. 지금과 비슷해졌다. 이렇게 2010년대 전반부 버전과 후반부 버전 사이의 차별화가 진행됐다.

세월이 세월이니 C++14 문법과 라이브러리도 야금야금 도입됐다. 가령, unique_ptr뿐만 아니라 make_unique도 사용할 수 있게 됐다. 일반적인 함수뿐만 아니라 매크로 함수나 람다에다가도 가변인자를 넣을 수 있게 됐다.

※ 2019 (버전 16)

IDE의 색상에 연보라색이 2017보다 더 가미되어 채도가 올라갔다. 2017은 제목 표시줄에 Visual Studio라는 이름이 있었지만 2019부터는 그게 빠지고 최상단에 메뉴가 바로 표시되기 시작했다.
2019의 초창기 버전은 내 기억으로 win32 대화상자 리소스를 편집하던 중에 IDE가 잘 뻗기도 했었다. 여러 업데이트를 거치면서 그 버그는 다행히 고쳐졌다.

아 참, 이 2019 시기에.. 마소의 C++ 라이브러리에 꽤 흥미로운 변화가 생겼다.
Visual C++은 200x 시절부터 전통적으로 Dinkumware 사의 STL을 라이선스 받아 공급해 왔으며, 이 때문에 헤더 파일의 뒷부분에 언제나 P. J. Plauger라는 제작자와 제작사 이름이 들어가 있었다. 그랬는데 마소에서는 2019 하반기부로 이 라이브러리를 오픈소스화하고 자체 관리하기 시작했다. 그러면서 Dinkumware 관련 copyright 문구가 사라졌다.
사실, C++ 라이브러리는 갈수록 언어 구조에 종속적이고 내부 구현도 컴파일러 제조사의 재량에 종속적인 형태로 바뀌어 가는 게 요즘 추세라고 한다.

※ 2022 (버전 17)
IDE 자체가 드디어 64비트로 포팅됐다...!! 이걸로 끝..???

※ 2026
테마가 자매품인 Visual Studio Code 급으로 엄청 다양해지고 휘황찬란해졌다는 것밖에 아직 확인을 못 했다.;;

이상이다.
개인적으로 날개셋 한글 입력기의 개발이나 직장 현업 용도로 진지하게 오래 써 본 버전은 6.0, 2003, 2010, 2012, 2019, 2022 정도이다.

(1) Browse info에 대해

Visual C++은 아주 초창기 시절부터, 빌드 때 겸사겸사 browse info를 같이 생성하는(.sbr, .bsc) 기능이 있었다.
물론 이건 빌드 시간과 디스크 공간을 추가로 소모하는 작업이기 때문에 사용자가 원해서 옵션으로 지정했을 때만 수행한다. 지금도 프로젝트 설정 대화상자를 열어보면 C/C++의 아래에 Browse info라는 카테고리로 당당히 남아있다.

하지만 오늘날은 매번 빌드하지 않고도 IDE에서 소스 코드의 심벌을 실시간으로 조회하는 기술이 눈부시게 발달했다. 그렇기 때문에 이 browse info 기능은 완전히 과거 레거시가 돼서 거의 쓰이지 않는 기능이 됐다. 다만, 업계에서 이 sbr/bsc 파일을 이용해서 다른 분석을 하는 3rd-party 툴 제품이 있기는 하다고 한다.
오늘날은 소스코드를 컴파일하는 과정에서 '덤'으로 할 만한 작업은 정적 분석인 듯하다. 허나, 이젠 그마저도 on-the-fly로 수행돼서 의심 지점을 소스코드의 밑줄로 쫙 쳐서 표시하는 경지에 이르렀다.

(2) 버전 체계에 대해

Visual C++은 버전 관리 체계가 생각보다 복잡하다. 크게 세 가지 버전 시스템이 있다.

- Visual Studio IDE 자체의 버전: Help - About 대화상자에서 볼 수 있는 그 버전이다. 새로운 연도 브랜드가 출시될 때마다 메이저 버전 번호가 1씩 올라간다. 6.0 이후로 2010의 버전은 10이었고, 2015는 14, 2022의 버전은 17까지 올라갔다. 버전 13은 건너뛰었다.

- 툴체인의 버전: 오랫동안 Visual C++ IDE의 버전과 동일하다가(13을 skip한 것까지) 2015 및 Windows 10 때부터 14에서 멈췄다. CRT/MFC DLL의 ABI와도 버전이 연계되는지, 현재는 마이너 버전만 쭉 올라가고 있다. 프로젝트 세팅의 '플랫폼 도구 집합'에 해당한다.

- 컴파일러의 버전: cl.exe를 실행했을 때, 또는 소스 코드에서 _MSC_VER의 값을 넣어서 확인 가능한 버전이다. 얘는 Visual C++의 전신인 Microsoft C/C++의 버전값을 승계했기 때문에 Visual C++ 1.0 시절에 이미 800부터 시작됐다. MS C/C++의 마지막 버전이 7이었고, VC++ 1은 MS C/C++ 8과 같다고 간주됐기 때문이다.
다만, Visual C++ 2에서 4로 넘어갔을 때는 값이 200이 아니라 100만 늘었다. VC++ 6의 컴파일러 버전은 500이 아니라 400이 증가한 1200이었다. (12.0)

그 뒤 IDE의 버전이 14인 2015에서는 800이 아니라 700이 증가한 19.0에 도달했고(13 skip이 없으므로), 이때부터는 툴체인의 버전과 마찬가지로 메이저 버전의 번호가 오르지 않고 있다.

Posted by 사무엘

* 무려 2010년쯤에, 2008 버전이 최신이었던 시절에 썼던 글을 내용을 보강하고 업데이트 하여 다시 올렸다. 심지어 분량이 엄청나게 늘어나서 글을 둘로 나눴다.

※ 1.0

1993년에 출시된 Visual C++ 1.0은 Microsoft C/C++ 7.0의 차기 버전 겸 Windows NT 전속 개발툴 역할을 하기 시작했다. 이웃 BASIC 팀에서 MS Basic PDS 7의 다음 버전이 Visual Basic이라고 선례를 남겼으니, C/C++ 팀도 비슷한 작명을 도입했던 게 아닌가 싶다. BASIC은 RAD 툴로 바뀌었고 C/C++은 32비트로 갈아탔다.

물론 이때는 16비트에서 32비트로 한창 넘어가는 과도기였기 때문에 Win32s 타겟이 지원되기도 했다. 그리고 Win32s가 아닌 순수 16비트용 에디션도 나중에 출시되기는 했다. (VB 1도 Windows용 이후에 DOS용이 따로 출시됐듯이..) 하지만 VC++ 16비트용은 개발 계보가 32비트 에디션과는 상이했다.

32비트 환경에서는 메모리 모델 구분이 없는 대신, CRT에 링크 방식(static/DLL)과 멀티스레드 지원 여부라는 속성이 새로 도입되었다.
참고로 Visual Basic은 1996년엔가, 버전 4에서야 32비트가 도입됐다는 것도 기억할 점이다. 16/32비트 에디션이 따로 나왔으며, VB5부터는 32비트 전용으로 바뀌었다.

※ 1.52

얘는 16비트 Windows를 정식 지원하는 마지막 버전이어서 매우 중요하다.
프론트 엔드 IDE는 모두 16비트 Windows 프로그램인 반면, 커맨드 라인에서 동작하는 컴파일러, 링커 같은 주요 툴들은 도스 익스텐더 stub을 내장하고 있는 32비트 PE 포맷인 점이 무척 인상적이다.

※ 2.0

이제부터 완전히 32비트 전용으로 바뀌었다. 하지만 이때는 아직 Windows 95가 나오기도 전이고 NT는 인지도와 점유율이 아주 미미했었다. 그래서 VC++ 역시 아직까지는 별 존재감이 없고 주목을 못 받았다. 아직까지는 16비트 Windows에서 볼랜드의 OWL 라이브러리도 쌩쌩히 현역이었다.

Windows 95의 워드패드가 바로 듣보잡 MFC 3.0 기반이었는데, 이게 Visual C++ 2.0의 흔적이다.
그리고 이 시절 Visual C++ RISC edition 어쩌구 하던 건 Windows CE가 아니라 NT를 염두에 둔 타겟이었다. 이건 eMbedded Visual C++과는 다른 제품군이었다.

※ 4.0

DirectX에는 4라는 버전이 없듯, Visual C++에는 3.x대 버전이 없다. 내부적으로 꾸준히 버전업이 돼 온 MFC의 버전 번호에 맞춰 곧바로 4.0으로 건너뛰게 된다.
VC++ 4.0은 Windows NT뿐만 아니라 정통 95용 32비트 프로그램을 만들 수 있다는 이점으로 인해 인지도가 급격히 올라갔다. IE가 넷스케이프를 제쳤듯이 Visual C++이 Borland C++을 제치기 시작했다.

4.0에 와서야 비로소 IDE가 오늘날의 Visual C++과 비슷한 골격이 갖춰졌다. 즉 코딩, 리소스 편집, 클래스 마법사, 도움말 열람을 모두 한 프로그램에서 할 수 있는 진정한 통합 환경 Developer Studio가 이 버전부터 생겼다.
msdev.exe라는 프로그램 이름은 훗날 6.0까지 이어졌다. MFC ClassWizard라든가, ClassView도 이때 도입됐다.

※ 4.2

4.1을 거쳐 4.0이 마이너 업그레이드된 버전으로, 제법 인지도를 얻었다. ActiveX 컨트롤, STL 같은 기능이 추가되고 MFC DLL의 이름도 이때부터 MFC42로 이름이 바뀌어 큰 뼈대의 변경 없이 훗날의 6.0까지 이어졌다. MFC42는 윈도우 98 이래로 운영체제가 이제 known DLL로 인정하는 마지막 버전 숫자이기도 하니 더욱 의미가 있다.

4.2에서부터 Win32s의 지원이 중단되었다. 오죽했으면 설치할 때 “이 버전부터 Win32s를 더 지원하지 않으니, 그 환경 개발하고 싶으면 이거 설치하지 말고 옛날 버전 쓰셈!”이란 경고문까지 나온다.

※ 5.0

얘와 6은 도구모음줄과 메뉴가 MS Office 97 스타일로 바뀌었다. 다만, 5는 도움말은 여전히 RTF 기반이고 인텔리센스도 아직 없었다.
외형뿐만 아니라 내부 기능도.. 한번에 여러 프로젝트들을 담을 수 있는 workspace 개념이 이때 도입됐다. 단, dsw/dsp라는 파일 포맷 자체는 5와 6 두 버전에서만 쓰이고 이후 버전에서는 또 바뀌게 되었다.

몇몇 C++ 최신 표준이 반영되어 bool이 built-in type으로 지원되기 시작했다. 그리고 이때부터 빌드하는 EXE 파일에 PE 재배치 정보가 기본적으로 생략되었으며.. 그 유명한 Rich 시그니처가 슬쩍 들어가기 시작했다.
다만, 이 5.0은 이듬해에 나온 6.0에 밀려 존재감을 완전히 상실했다. 뭔가 아래아한글 97이 나오기 전의 96이 묻혀 버린 것과 비슷하달까?

※ 6.0

개발툴계의 Windows XP 같은 만수장세 결정판이었다. 이 버전 이후로 거의 4년 가까이 버전업이 없었고, 다음 버전인 닷넷이 변화폭이 너무 크기도 했기 때문이다.

6에서는 인텔리센스(초보적인 수준), edit and continue, delay-loaded DLL 같은 획기적인 기능이 처음으로 추가되고 도움말이 별도의 MSDN 라이브러리로 독립함과 동시에 HTML 기반으로 모두 바뀌었다.
이 버전은 윈도우 9x에서 설치 가능한 마지막 버전임과 동시에 MSVCRT, MFC42 같은 known DLL만 사용하는 바이너리를 생성할 수 있는 마지막 버전이기도 하다. 주요 라이브러리를 DLL 링크하고도 DLL 배포 걱정을 할 필요가 전혀 없다는 장점이 있다.

4.2 때는 ClassView에 있는 각종 클래스, 변수 정보가 소스 파일을 매번 저장할 때에만 업데이트됐다. 이것이 내용이 바뀔 때마다 실시간으로 바뀌기 시작한 것도 5.0은 아니고 6.0부터인 걸로 기억한다.
Visual C++이 C++ 표준을 준수하지 않는다고 비판이 많긴 했지만, 라이브러리의 헤더 파일에서 .h 확장자가 없어지고 namespace std가 도입된 건 6.0부터였지 싶다.

※ 7.1 (2003)

Visual C++의 다음 버전은 처음엔, 버전 번호나 연도가 아닌 닷넷이라는 브랜드로 출시되었다.
MFC를 써서 개발된 VC 특유의 전통적인 msdev.exe는 퇴출되고 devenv라는 MS Office 내지 VB 스타일의 IDE가 등장했됐다. 이는 완전히 새로운 것이라기보다는 예전에 Visual Studio에 있던 Visual InterDev와 비슷한 형태였다. 단지 거기에다 외형만 MS 오피스 XP 스타일 UI를 그대로 물려받았다.

덕분에 Visual C++과는 영 인연이 없고 VB만의 전유물인 것 같던 Property grid가 도입되어 Visual C++ IDE 특유의 납작한 등록정보 대화상자를 대체했다. 클래스 마법사도 이 형태로 대체됐다. 도움말은 5.0 시절처럼 IDE 내부에 띄울 수도 있고 6.0처럼 외부에 띄울 수도 있는 융통성 있는 형태로 바뀌었다.
dsw/dsp 대신, sln(솔루션)과 vcproj 요렇게 프로젝트 파일의 확장자와 포맷이 바뀌었다.

이제 주류로 내세운 게 C#, 공용 언어 런타임 같은 닷넷 환경이긴 했지만 네이티브 C/C++ 쪽도 크게 향상되었다. 네이티브 wchar_t 형식이 지원되기 시작했다.
6에서 첫 도입됐던 인텔리센스도 굉장히 강력해져 특히 #define 매크로 심볼에 대해서도 동작하기 시작했다. 별도의 browse info를 만들지 않아도 선언/정의로 가기 기능을 바로 사용할 수도 있게 됐다. 닷넷 정도만 써 보면 이제 6.0은 충분히 열악함을 느끼기에 충분할 것이다.

64비트 크로스컴파일은 불가능하지는 않으나 불편하고 디버깅도 되지 않고 IDE 차원의 적극적인 보조는 못 받는 어정쩡한 위상을 차지하고 있다. 이 불완전한 면모들은 후속 버전인 8에서 보완되었다.

참고로.. 2003 이전, 2002년에 Visual Studio .NET이라는 이름으로 먼저 출시된 버전 7.0은 정말 놀라울 정도로 존재감 없이 신속히 잊혀졌다.
글쎄, 6.0 이후로 오랫동안 버전업이 없다가 닷넷과 CLR이라는 걸 도입한 첫 버전이니 너무 불안정하고 버그가 많았던 걸까? 저 제품에 대해서는 내가 아는 게 없다. 금세 .NET 2003 (7.1)으로 대체됐다.

※ 8.0 (2005)

얘도 생각해 보니 변화가 굉장히 많았다.
for 문의 변수 scope처럼 그동안 Visual C++ 컴파일러가 표준을 어기고 있던 문법을 교정했으며.. 멀티코어를 표방했는지 빌드 로그에 코어 번호가 왼쪽에 표시되기 시작했다.
CRT의 보안이 이때 크게 강화됐다. strcpy_s와 gets_s(대상 버퍼 크기), qsort_s(콜백 함수에 데이터 전달 가능), strtok_s(토큰 중복 호출 가능) 같은 함수가 새롭게 등장하고 strchr 같은 경우, C++에서는 const 포인터를 되돌리는 버전과 비const 포인터를 되돌리는 함수가 오버로딩으로 분리해 나갔다. 무척 신선한 변화라 느껴진다. STL 디버깅도 훨씬 더 편해졌다.

이 버전부터 별도의 플랫폼 SDK를 설치할 필요 없이 IDE 차원에서 x64 타겟 빌드와 디버깅이 정식 지원되기 시작했다.
그리고 이때 MSVCR80, MFC80의 배포 방식이 side-by-side assembly 방식으로 완전히 바뀌었다. 이와 덩달아, 리소스 편집기로 수동으로 해야 하던 메니페스트 생성/편집 기능도 상당 부분 자동화됐다.
이 버전부터는 생성하는 프로젝트의 디폴트 기반 인코딩이 드디어 유니코드로 바뀌었다.

UI 상으로도 이제 MS 오피스 스타일에서 독립한 새로운 외형 비주얼을 갖기 시작했으며, 도구모음줄 아이콘도 256색으로 더 화려해졌다. 전통적으로 ClassView에 클래스와 멤버들이 한 트리에 쫙 나열되던 것이 멤버는 별도의 리스트에 뜨도록 바뀌기도 했다. 도킹 창을 드래그할 때 나타나는 도킹 다이아몬드도 2005에서 첫 도입된 물건이다.
Visual Studio의 무료 에디션인 Express 에디션이 이때 첫 도입됐다. (무료이지만 MFC 없고 64비트 타겟도 미지원)

※ 9.0 (2008)

8이 질적으로 많이 바뀌었다면 9는 Windows Vista의 등장처럼 8 출시 이후에 생긴 변화를 IDE나 MFC 라이브러리 같은 데에 적극 반영하여 양적인 향상을 꾀했다. 일단 MS Office 스타일의 GUI를 손쉽게 만들 수 있는 feature pack을 MFC에 드디어 도입했다.
그리고 2005는 설치하려면 sp1에, Vista 지원 패치.. 등 덕지덕지 땜빵을 해야 할 게 많았는데 2008은 그걸 당연히 모두 기본 접수했다.

Windows Vista에서 도입된 시작 주소 랜덤화 기능이 요 2008에서 정식 추가됐다. 2008에서는 이 보안 기능을 사용하는 EXE를 만들 수 있다는 뜻이다.
10여 년 전, 5.0에서 누락되기 시작한 EXE의 재배치 정보가 2008부터는 기본적으로 다시 들어가기 시작했다. 옛날에는 fixed address를 지원하지 않는 win32s와의 호환 때문에 그게 필요했었지만, 지금은 보안 기능 때문에 필요해진 것이다.

2008은 설치하기 위해 Windows XP 이상을 요구하며(2000 지원 중단), 지원하는 타겟 플랫폼에서도 Windows 9x는 공식적으로 완전히 제외됐다. 링커 옵션에서 바이너리의 최소 요구 운영체제 버전이 4에서 5로 껑충 뛰었고, 이보다 낮은 값은 지정 자체가 안 된다.
또한 single threaded CRT 라이브러리 옵션도 없어졌다. C 라이브러리는 이제부터 무조건 multi threaded이다.

Posted by 사무엘

1. 클래식 16비트 DOS 기반 Windows: x86 하에서 여러 모드 존재

초창기 16비트 Windows는 DOS로 부팅된 컴퓨터에서 추가로 실행되던 운영환경 프로그램이었다. 자신만의 하드웨어 인식 모델, 자신만의 API, 자신만의 실행 파일 포맷이 있었지만 자체적으로 컴퓨터를 부팅시킬 능력은 없었다.
그 MS-DOS가 x86 전용이었으니 Windows도 자연스럽게 x86 전용으로 출발했다. 그 대신 그때는 x86 계열 CPU 자체가 시시각각 성장하고 변모하고 있었던지라, Windows도 그에 맞춰 다양한 실행 모드를 지원했다.

8086 real mode, 80286 standard 모드, 그리고 80386 enhanced 모드.
1.0이야 당연히 8086 real에서 시작했다. 주 메모리 최대 640KB밖에 지원을 못하는 초 열악 모드.
그러다가 Windows 2.x 시절에는 Windows/286, Windows/386 에디션이 추가로 도입됐는데.. 이거 마치 옛날에 아래아한글이 1.x 시절에 도트 프린터 에디션, 레이저 프린터 에디션을 세분화했던 것과 비슷한 느낌이 든다.;;; (폰트)

그러다가 Windows 3.0에서는 한 프로그램에서 세 에디션이 모두 같이 제공되기 시작했다.
286 표준 모드에서는 80286에서 추가된 보호 모드를 활용하여, 컴터의 메모리를 더 많이(최대 24비트, 16MB) 끌어다 쓸 수 있었다. 그리고 도스창을 연 상태에서도 백그라운드에서 딴 프로그램과의 멀티태스킹이 가능해졌다.
386 확장 모드에서는 그에 덧붙여 가상 메모리(스왑 파일 페이징)까지 더 끌어다 쓰고, 도스창을 여러 개 동시에 만들 수도 있게 됐다.

즉, Windows 3.x의 386 확장 모드는 여전히 16비트 코드 기반이지만 80386 CPU의 기능을 일부 활용했던 모드였다.
여기에다가 Win32s가 도입되고 커널이 통째로 Windows 9x로 바뀐 과정은 참 드라마틱하게 그지없다. DOS는 Windows를 띄워 주는 하부 인프라가 아니라, Windows 안에서 돌아가는 샌드박스로 위상이 바뀌었다.
수많은 DOS용 프로그램과의 호환성을 최대한 유지하면서, 또 저사양 똥컴에서의 성능도 최대한 살리면서 DOS를 도태시키는 길은 멀고도 험난했다;;

2. 1990년대 Windows NT: x86 + MIPS, Alpha, PowerPC

저런 클래식 Windows와 달리, Windows NT는 DOS와는 완전히 동떨어진 별세계 신세계 이상향을 추구했다.
x86은 지원하는 여러 CPU 중 하나일 뿐이며, 처음부터 100% 32비트 기반으로 동작했다. 지저분한 DOS나 16비트 호환성 따위는 우선적으로 고려하지 않았다.
실행 파일 포맷도 Portable Executable이라고 새로 제정하고.. 노는 물이 정말 완전히 달랐다.

Windows NT는 초창기에 x86뿐만 아니라 MIPS와 DEC Alpha를 추가로 지원해서 UNIX 일색이던 워크스테이션 시장에 도전장을 내밀었다. 원래 제일 처음 계획은 인텔 i860을 지원하는 것이었으나, 이건 모종의 사정으로 인해 이뤄지지 못했다.
NT 3.51부터 4.0 sp2까지 잠깐 동안은 PowerPC까지 추가로 지원했다. 그 당시 매킨토시가 돌아가던 그 CPU가 맞다. 물론 PC와 맥은 CPU 말고도 컴퓨터 하드웨어 규격이 매우 달랐기 때문에, 저런다고 맥에서 Windows NT PPC 에디션을 돌릴 수는 없었다.

Windows가 x86과는 특성이 상극인 RISC 구조에, 심지어 big endian인 CPU에서도 이식되어 돌아간 적이 있었다니.. 지금으로서는 참 믿어지지 않는다.
Windows NT의 개발 본진은 DEC Alpha에 가까웠다. 심지어 Alpha는 64비트 CPU이기도 했으나.. NT 3~4는 그냥 32비트 ABI를 그대로 사용했다. 이 Alpha의 후대 버전은 Windows가 진짜 64비트로 포팅되던 시절에 테스트 장비로도 쓰였다고 한다.

물론 이상향을 추구한 것에는 댓가가 따랐다. 1993~95년 사이, 어지간한 가정용 컴퓨터들이 램이 2MB~8MB 이러던 시절에 NT는 이미 12~16MB 이상을 요구했다. 그것도 한글 한자 지원 없이 오리지날 영문판이 말이다.
그 시절엔 CPU와 메모리 가격이 지금으로서는 상상하기 어려울 정도로 희귀하고 비쌌었다. 이러니 NT는 초창기엔 가정용 PC 생태계에서 도저히 발을 들일 수 없었다.

마소에서 개발하던 프로그래밍 언어/개발툴 중에 BASIC은 RAD로 지향점이 바뀌면서 Visual이라는 브랜드가 먼저 붙었다. (1991년) 그 반면, MS C는 7.0 버전에서 C++ 지원이 추가되면서 C/C++이 됐고, 그 다음 Windows NT용 32비트 타겟 빌드가 추가되면서 Visual C++ 1.0으로 다시 태어났다. 거기에다 IDE도 Programmer's workbench라고 언어 공용이던 게 Windows용 자체 에디터로 덤으로 바뀌었으니 겸사겸사 Visual이라는 단어를 붙인 듯하다.

이때는 크로스 컴파일이라는 개념이 약했는지 VC++이 x86용, MIPS용, Alpha용, PowerPC 용으로 제각기 따로 출시됐다.
아~ 그래서.. 개인적으로는 VC++ 4 시절에 PowerPC 타겟 흔적을 많이 봤던 것 같다. 그건 Windows NT를 염두에 둔 기능이지, CE용이 아니었다. 나중에 VC++ 6 IDE를 기반으로 출시됐던 eMbedded Visual C++와는 다른 제품군이었다.

3. Windows 2000: x86 단일 황금기

그 뒤.. 세기말이 되자 Windows 2000이라는 걸출한 제품이 Windows NT 5.0을 표방하며 출시됐다. 얘는 연도 숫자로나, 기술 계보로나 정말 너무 절묘한 교차점에 놓였다.
NT는 전통적으로 OpenGL이 있을지언정 DirectX 따위는 없던 운영체제였다. 그러나 2000은 일단 표면적으로는 NT 계열과 9x 계열의 통합을 추구했다. 그래서 DirectX라든가 plug & play, USB처럼 9x에 먼저 들어갔던 기능들을 대거 수용했다.

이제는 가정용 컴터들도 많이 빨라지고 램 용량도 크게 늘어서 NT 커널을 돌릴 수 있다고 여겨졌기 때문이다. 둘을 통합할 때가.. 아니, 구닥다리 DOS와 9x 커널을 퇴출시킬 때가 됐다.
이 참에, NT 구버전이 지원하던 타 CPU들은 미래가 없다고 여겨져서 때문에 지원을 끊었다. 그 대신 마소에서는 인텔의 새 밀레니엄 64비트 CPU로 여겨지던 Itanium을 지원하겠다고 벼르고 있었는데.. 이게 사실상 베이퍼웨어 나가리로 끝나 버렸다.

이런 이유로 인해 Windows 2000은 NT 계열임에도 불구하고 마치 9x처럼 사실상 x86 전용 운영체제로 출시됐다. 그리고 2000년대 초, 2000과 그 다음 XP 시기가 어찌 보면 32비트 x86의 황금기였다.
램은 128~256MB대.. 주소 공간이 부족하지 않고 32비트로 적당히 커버 가능해서 정수도 4바이트, 포인터도 4바이트.. 딱딱 절묘하게 떨어졌기 때문이다.
컴퓨터 클럭 속도는 기하급수적으로 증가하던 무어의 법칙의 끝물 상태였고, CPU도 x86 only에 가까운 상황.. 얼마나 깔끔하냐? 그 와중에 구닥다리 9x는 역사 속으로 사라져 가고.. 모든 게 파편화 없이 한데 집중됐었다. 새천년에 말이다.

4. 2000년대: Itanium과 x64의 명암

Windows의 역사상 어떤 형태로든 64비트 ABI라는 게 등장한 게 저 1990년대 중후반, Itanium 포팅을 할 때였다. PE 실행 파일의 포맷을 확장하고, 플랫폼 SDK에 INT_PTR이라든가 GetWindowLongPtr 이런 게 등장한 게 그 때라는 뜻이다.

하지만 IA64라고 불리는 Itanium은 처절한 실패로 끝났고, 21세기 초부터는 x64라는 x86 호환 CPU가 64비트 PC 시대를 주도하기 시작했다. 얼리어답터 컴덕이 아닌 일반인들은 컴퓨터 램의 용량이 실질적으로 4GB를 넘어선 2000년대 중후반, Windows Vista나 7쯤부터 64비트를 체감한 듯하다.

Windows는 일반인 클라이언트 제품군에서는 XP에서 딱 한 번 IA64를 지원하고는 학을 뗐다.
서버 제품군에서는 Vista에 대응하는 Server 2008까지 IA64를 조금 더 지원했고, 그 다음부터 지원을 끊었다.
그 대신 서버 제품군은 32비트 x86 전용 에디션을 클라보다 훨씬 일찍 끊었다.

클라에서는 Windows 10까지만 해도 x86 전용 에디션도 출시해 오다가 2020년대 11에 와서야 중단했다.
그러나 서버에서는 IA64를 약간 더 오래 지원한 대신, 그 Server 2008부터 x86을 끊고 x64로 완전히 갈아탔다. 클라와 서버의 컴퓨터 특성이 서로 다르기 때문일 것이다.
개발툴인 Visual C++은 2005부터 x64로 크로스 컴파일을 정식 지원하기 시작했다.

5. 2010년대 말: ARM64의 추가 도입

그 뒤, 마소는 2010년대 중반엔 경영진이 싹 바뀌었다. 새 경영진은 기존 CE나 폰/모바일 제품군을 포기하고 정리했다. Android/iOS와의 경쟁에서는 승산이 전혀 없다는 결론을 내렸으며, Windows 8 시절 같은 삽질은 더 하지 않기로 했다.
그 대신 Windows on ARM이라 해서 데스크톱용 기존 운영체제를 ARM64로 그대로 포팅해서 오늘에 이르고 있다.

너무 자명한 얘기지만, ARM64는 클라 제품군 한정이다. 서버 제품군을 그렇게 포팅하지는 않는다.
얘는 마소에서 ARM64EC니, ARM64X니 하는 온갖 하이브리드 규격도 만들어서 x64와 최대한 같이 포용하려 애쓰는 중이다.
예전의 Itanium처럼 호환성 없는 별개 취급을 하지 않고 있다.

2010년대 초, Windows RT 시절에 잠깐 나돌았던 ARM32는.. 2000년대 초 IA64와는 좀 다른 의미로 낙동강 오리알로 전락하고 역사 속으로 사라졌다. 한쪽이 64비트 삽질이었다면 다른 쪽은 모바일 삽질이라 하겠다.

이상이다.
한때는 온갖 CPU들이 난립하다가 x86으로 천하통일 되는 것 같았는데.. 지금은 그 뒤에 x64와 ARM64가 올라타서 상황이 좀 더 복잡해졌다. 날개셋 한글 입력기 작업을 하다가 이 이야기를 하고 싶어서 이렇게 글을 써 보았다.

한때, 1990년대부터 2000년대 초까지는 (1) 컴퓨터의 단일 코어 속도가 크게 증가했었다..
그 다음으로 1990년대 중후반부터는 (2) RAM이건 디스크건 메모리가 용량이 크게 증가하고 가격이 싸졌다. 이때쯤부터 C드라이브 디렉터리와 파일 구조를 DOS 시절처럼 몽땅 한데 조회하는 게 거의 무의미해지고 불가능해졌다.
끝으로, 2000년대부터는 (3) 인터넷 속도가 급격히 빨라지고 심지어 무선화까지 됐다.

이런 기술이 발달하고 저렴하게 널리 보급된 덕분에 일반 사용자들도 과거에 상상도 할 수 없었던 방대한 규모의 소프트웨어를 컴퓨터로 아무렇지 않게 돌릴 수 있게 됐다.

* 덧붙임: Windows CE

1990년대 중반, 가정용 PC에서는 Windows 95가 이제 막 정착했고 NT는 아직 별나라이던 시절에.. 마소에서는 PC보다 작은 기기에다가도 win32 API를 심어서 Windows 생태계를 가꿀 생각을 했다. 이름하여 Windows CE라는 게 이때 태동했다.

CE가 지원했던 CPU 중에는 NT에서 지원했던 MIPS, PowerPC 같은 것도 있었고 심지어 ARM32에다 x86도 있었다.
하지만 컴퓨터에 오로지 CPU만이 구성요소의 전부인 게 아니고, CE는 근본적으로 ‘임베디드’ 환경을 추구했다. CPU의 특성이나 메모리, 파일 시스템, 비디오, 소프트웨어 환경 등이 범용 컴퓨터와는 완전히 딴판이다. 그렇기 때문에 일반적인 Windows 프로그램을 돌리지는 못한다.

Windows CE용 프로그램을 개발하는 환경은 기존 Visual C++에다가 해당 플랫폼용 툴키트를 구매해서 추가로 설치하는 형태로 세팅했다. 2000년대 초에는 eMbedded Visual C++라고 IDE가 통째로 새로 나오기도 했었으나.. 그건 얼마 못 가 단종됐다.

Windows 9x가 21세기로 진입하지 못하고 세기말에 맥이 끊겼다면.. CE는 2010년 초쯤에 명맥이 끊겼다.
CE 커널은 9x와 달리 wide char로 대표되는 유니코드 버프는 당연히 받은 채로 시작했다. 하지만 2000년대 말의 트렌드이던 64비트 환경으로 포팅되지는 못했다. 동작 환경의 특성상, Itanium이나 DEC Alpha와도 접점이 당연히 없었다.

그 대신, 마소에서는 CE 커널을 스마트폰에다 얹을 생각을 했다. CE 커널이 한때는 PDA에도 쓰였으니 이는 자연스러운 귀결이었다. 그래서 통상적인 임베디드용 CE는 Windows Embedded Compact라는 이름으로 제품을 유지하고, CE를 기반으로 Windows Mobile을 만들고 나중엔 이름을 Windows Phone으로 대놓고 바꿨다.

나중에 마소는 Windows Phone을 CE가 아니라 NT 커널을 기반으로 다시 만드는 무리수까지 둬 봤지만.. 안드로이드나 iOS 같은 신흥 모바일 강자를 꺾을 수는 없었고 실패했다.
이런 사건을 거쳐 오늘날, 2020년대 기준으로 CE는 원래의 나와바리이던 임베디드 제품들의 유지보수 이상으로 신규 개발은 끝나고 성장이 멈춘 플랫폼이 됐다. 시장이 특수하기 때문에 무슨 Windows 9x가 사라진 것처럼 사라지지는 않겠지만.. 그야말로 고인물로 전락한 셈이다.

Posted by 사무엘

지금 올리는 이 글은 원래는 이전의 새 버전 소개 글과 같이 올라갔어야 했다.
하지만 이 내용까지 같이 저 때에 맞춰 넣어서 글을 완성할 여유가 도저히 없어서 부득이하게 글을 둘로 나누게 됐다. ㄲㄲㄲㄲ
뭐, 글을 쓰고 보니 분량이 워낙 길어진지라, 별도의 글로 분리한 게 다행히 더 좋은 모양새가 되긴 했다.

1. 타자연습: 히스토리 기능의 부재가 아쉬워

연습글별로 예전에 마지막으로 연습하던 위치를 기억하기, 그리고 제일 최근에 열어서 연습했던 연습글을 기억하기.

이건 지금까지 여러 사용자들께서 건의했으며 본인도 지원의 필요를 느끼고 있었고, 이번에 어지간해서는 같이 구현하려 했다. 어떤 형태로 구현할지에 대해서도 얼추 구상을 마쳤다.
하지만 이건 아쉽게도, 죄송하게도 이번 4.0에서 실현되지 못했다. 또 다음 버전을 기약해야 하게 됐다.

일단 지금 형태 있는 그대로라도 '64비트화'라는 거대한 0순위 과업이 생겼다 보니.. 신규 기능은 우선순위에서 밀렸다.
게다가 이건 아무래도 사용자의 계정에 새로운 데이터가 영구적으로 추가되는 '큰 기능'이다. 이걸 구현해 넣기에는 지금 프로그램의 로직, 계정 파일 포맷 등등이 마음에 안 들고 많이 구려서-_-;;;
이것부터 최적화하고 작업을 더 장기적인 안목을 보면서 하는 게 낫겠다는 결론을 내렸다.
지금 이 구조에서 저 기능만 간신히 넣는 건 너무 삽질스러워 보였다.;;

그래도 이번 4.0을 계기로 날개셋 타자연습도 오랜 겨울잠에서 깨어나고 먼지를 털어냈다.
이제 최신 개발 환경에서 신형 API나 최신 C++ 문법도 아무 제약 없이 쓰면서, 여건이 허락하는 한 프로그램을 계속해서 발전시켜 나갈 것이다.

2. 타자연습: 게임 음악 관련 불만

타자연습을 x64 환경으로 포팅하면서 알게 된 사실인데.. 마소는 64비트 Windows에서는 DirectMusic의 지원을 사실상 끊었다.
관련 인터페이스들을 다 싹 없앤 건 아니고 directmusic performance 계층만 없앴지만.. 이거 없앤 게 사실상 DMusic을 몽땅 없앤 거나 마찬가지이다.

도대체 왜??
아무리 waveform 음원이 대세이고 MIDI는 현업 게임들에서 도태됐다지만, 내 프로그램처럼 소규모 초저예산 게임에서는 미디 음악을 여전히 쓰기도 한다.

그럼 더 구닥다리인 MCI API로 돌아가리?
음악 음색도 안 좋고, 로딩 때 랙도 너무 심하고, 게다가 메모리에 로딩된 미디 데이터를 바로 재생하지 못하고 임시 파일을 써서 불러들였다가 도로 지우는 삽질.. 이건 도저히 쓸 게 못 되었다.

마소에서 미친 짓을 했으니, 나도 미친 짓을 하기로 했다.
음악만 별도의 32비트 호스트 exe로 따로 떼어내서 재생한 것.. 기능의 퀄리티 상으로 DirectMusic을 대체할 물건이 도저히 정말 전혀 없더라.
내가 프로그램을 이 따위로 비효율적으로 만들게 된 건 전적으로 마소 때문인 줄이나 알아라.

아울러, 내가 타자연습은 이 참에 ARM64용 빌드도 시험삼아 만들어 볼까 생각했으나.. 일단 보류했다.
사실상 x86 32비트에서밖에 못 쓰는 저 음악 문제도 있고, 그리고 Visual Studio의 설치 배포 프로젝트가 플랫폼을 여전히 x86, IA64, x64 셋 중 하나로밖에 지정을 못 하기 때문이다.

Windows on ARM 나온 지도 이미 수 년이 지나지 않았냐? 거기서는 msi를 도대체 어떻게 만드는지?
Visual Studio의 컴파일러 툴킷은 ARM64용이 있는데, 배포 프로젝트에는 저 플랫폼이 왜 없는 걸까?
이런 것도 마음에 안 든다. =_=;;

3. 입력기: 외부 모듈의 버그 신고

지금까지 마소 IME는 괜찮은데 내 프로그램만 한글 입력이 제대로 동작하지 않는다는 신고가 들어온 건 다음과 같다.

(1) LoL 게임=_=.. 신고 메일에 따르면 게임 중의 대화(?) 창에서는 한글 모드로 안 들어가고 영문만 입력되며.. 게임을 마치고 나온 대기 로비의 대화창에서는 한글 입력이 된다고 한다.
난 LoL을 전혀 하지 않고 프로그램 구조를 모르기 때문에 이에 대한 지원은 전혀 할 수 없다. 혹시 비슷한 현상을 겪는 분이 또 있으신지 제보를 기다린다. 스샷과 정확한 재연 방법도..

(2) 텔레그램 메신저, 그리고 AppFlowy라는 프로그램에서. 한글 입력이 덧난다거나, 한글 모드에서 입력하는 비한글 문자(세벌식 자판의 숫자, ※ 등)가 씹히고 제대로 입력되지 않는 현상이 있더라.
AppFlowy의 경우, 일반적인 입력란은 OK인데, 페이지를 하나 생성해서 제목 다음으로 본문을 입력하는 곳까지 갔을 때 오동작이 발생한다.

개인적으로는 응용 프로그램을 어떻게 만들어야 저런 오동작을 재연할 수 있는지 참 궁금하다만;;
아마 금방 쉽게 해결 가능한 문제는 아니어 보인다. 아마 해결된다면 저런 프로그램만을 위한 보정 동작이 추가될 가능성이 높다. 특히 (2) 같은 유형의 오동작 말이다.
(1)은 현재로서는 보안 프로그램으로 인한 통째로 차단이 의심된다.

아무쪼록 버그 신고를 한다면 날개셋 개발자는 그 프로그램에 대해 전~혀 모른다고 생각하고,
오동작이 일어나는 지점까지 모든 과정을 차근차근 알려주셔야 한다. 아무 입력란에서나 문제를 쉽게 재연할 수 있는 게 아니라면 말이다.
그 프로그램을 사용하기 위해서 무슨 가입, 계정 생성, 로그인 같은 게 필요한지도 안내가 필요하다.

4. Windows 최신 동향: IME 쪽

(1) 지난 몇 년 동안 Windows 동네에서는 한글 IME와 관련된 동작이 생각보다 많이 바뀌었다.
우와~~ composition의 모양이 검은 사각형이 아니라 밑줄로 바뀌었으며, capslock 같은 걸 눌러도 조합이 풀리지 않고 유지된다. 게다가 한글 조합 중에 ctrl+bksp를 눌러도 드디어 단어를 모두 지울 수 있다. (날개셋은 이전부터 이미 가능했음)

이런 건 긍정적인 변화인 것 같다. 여러 정황상 한글 IME의 동작을 중국· 일본어 IME의 동작에 맞춰 일치시킨 듯하다.

(2) Windows Terminal과 Google chrome 브라우저는 오랫동안, 지난 수 년 동안 내 프로그램 기준으로는 '보정'이 필요한 특이한 프로그램이었다.
그랬는데 지금 보니까 언제 고쳐졌는지 그 보정을 안 해도 별다른 오동작 없이 동작하도록 버그가 수정된 듯하다.
이제 그 보정 옵션은 특정 앱에 종속적인 다른 편의 기능을 제공하는 용도로 활용해도 될 것 같다.

(3) 전통적으로 한글 조합이 끝났을 때는 WM_IME_END_COMPOSITION이 오고 그 다음에 WM_IME_COMPOSITION이 뜬금없이 왔었다.
이거 30년 전 Windows 95 시절부터 변함없는 동작이었는데 이제는 후자 다음에 진짜 마지막으로 전자 END_COMPOSITION으로.. 논리적으로 맞게 바뀌었다.

이것도 긍정적인 변화이긴 하지만.. 일부 저 잘못된 동작에 딱 맞춰 동작하는 소수의 프로그램에서 오동작을 일으키는 건 어쩔 수 없다.
조합 모양과 저런 자잘한 동작들을.. 날개셋도 옵션 형태로 조만간 수용하고 업데이트 해야 할 것으로 보인다.

5. Windows 최신 동향: 나머지

(1) 언제부턴가 날개셋 한글 입력기에서 제공되는 필기 인식 기능이 동작하지 않고 있다.
Windows 10/11의 어느 빌드에서부터 내 프로그램이 지원하는 방식인 필기 인식 라이브러리를 빼 버렸다. 그건 구버전 레거시로 치부하고 자기들은 또 다른 새로운 인터페이스로 갈아탄 것 같다. 나름 이것도 Windows Vista 때부터 있던 인터페이스인데..
어휴~ 이건 또 어찌 대응 가능할지 모르겠다. 금방 되기는 어려울 듯..

(2) 그리고 win 10/11 초창기에 비해 현재는 이모지의 렌더링 속도가 엄청나게 느려졌다. 내 프로그램에서 이모지 문자표를 꺼내 보면 창이 뜨고 목록이 스크롤되는 게 무진장 굼뜨는 걸 알 수 있다.
운영체제에서 제공하는 컬러 이모지 폰트가 더 정교해지고 복잡해져서 그런 것 같은데.. 내 프로그램에서 이모지를 실시간으로 점진적으로 표기하고, 한번 표시한 이모지의 비트맵을 캐싱하는 식으로 UI와 성능을 개선해야 할 듯하다.

(3) 지난 Windows 11 2022년쯤 버전부터 운영체제의 인쇄 대화상자가 새끈하게, 혹은 이상하게 바뀌었다. 이게 싫다면서 다시 익숙한 옛날 클래식 대화상자로 되돌려 달라는 청원도 많으나, 마소에서는 들을 생각이 없는 듯하다.
새 대화상자는 아시다시피 인쇄 미리보기가 한데 통합도 돼 있다. 이걸 지원하려면 응용 프로그램이 Windows 11의 새로운 인터페이스를 구현해 줘야 하는데..

문제는 본인은 저걸 지원하는 프로그램, 인쇄 미리보기가 나오는 프로그램을 지금까지 단 하나도 못 봤다. 심지어 메모장이나 그림판처럼 마소 자기들이 만든 프로그램조차도 저걸 지원하지 않으니 도대체 뭐 어쩌라는 건지 궁금해진다.;;;
아마 날개셋 편집기도 이 대화상자를 미리보기까지 정식 지원하는 건 하루아침에 금방 될 것 같지 않다. 개발 우선순위가 아주 낮다. ㄲㄲㄲㄲㄲ

(4) 영문 Qwerty 글쇠배열의 대안으로 드보락이 오랫동안 유명했다. 그러나 2010년대쯤부터는 콜맥이 드보락의 지위를 위협하는 지경에 도달한 것 같다. 본인은 날개셋에서 세벌식과 콜맥을 같이 사용 중이라는 사용자 피드백을 지금까지 굉장히 많이 받았다.
콜맥이 얼마나 유명해졌으면 Windows 11 언제부턴가 콜맥 키보드 드라이버도 내장되어서 정식으로 지원되기 시작했다.

콜맥은 숫자· 기호가 기존 쿼티와 일치하고 이질감도 덜하다는 게 장점인 것 같다. 쿼티와는 완전히 다른 드보락과 다른 점이다.

(5) 이 와중에 요즘 Windows에서는 워드패드가 퇴출돼 버렸다.
mac의 TextEdit나 리눅스의 gedit는 서식 있는 텍스트(간편 워드 프로세서)와 plain text를 동시에 취급할 수 있다. Windows 메모장은 그렇지 않은데 왜 워드패드를 없앴는지.. 이것도 참 이해할 수 없는 일이다. 마소 Word의 축소판 같은 대안이 있는 것도 아닌데 말이다.

RTF는 원래 규격이 그렇게 정의돼 있는지 모르겠다만, 그닥 유니코드 친화적이지 않다. 한중일 2바이트 문자는 몽땅 다 \' 라는 탈출문자와 함께 16진수 바이트 시퀀스 형태로 바꿔서 표시하게 돼 있다.;; 이 때문에 한글· 한자가 들어간 rtf는 실제 용량보다 덩치가 굉장히 커진다.

'코드 번호로 변환' 텍스트 필터에는 C언어 정수 및 문자 리터럴, URL 등 여러 known prefix를 제공하고 있는데, 다음 버전에서는 RTF의 저 prefix도 추가할 예정이다. Windows에서 워드패드가 사라진 와중에 RTF 파일을 읽는 데 도움이 되라고 말이다.

Posted by 사무엘

1990년대 초중반 16비트 시절, 특히 Windows 3.x 시절엔 분야별로 이런 괴수들이 있었다.
30여 년 전의 아재 얘기이고 예전에 이 블로그에서도 다뤘던 얘기도 있지만 이렇게 한데 다시 정리해 본다.

1. 콜백 함수의 메모리 보정

80386 이전에는 CPU 차원에서 메모리 가상화 내지 보호라는 게 존재하지 않았다. 그런 환경에서 멀티태스킹이라든가 64KB 이상 메모리 접근을 구현하려다 보니 프로그래밍이 지금과는 비교할 수 없이 구리고 불편한 구석이 많았다.
운영체제에다 내가 만든 대화상자 콜백 함수를 하나 지정하려 해도 그 포인터를 바로 못 넘겨주고 이 콜백의 소유자가 누군지 레지스터에다 써 넣는 thunk를 감싸서 줘야 했다.

그래서 함수 전처리/후처리 thunk를 생성해 주는 MakeProcInstance와 FreeProcInstance라는 API가 제공됐는데..
마소의 직원도 아닌 Michael Geary라는 프로그래머가.. 빌드된 실행 파일을 살짝 후처리만 함으로써 저런 번거로운 절차 없이 콜백 호출이 되게 하는 기법을 발견해서 공개했다. (☞ 링크)

이건 이 바닥 업계를 크게 놀라게 했다. Windows를 개발한 마소에서도 자기들이 생각한 것보다 더 간편한 방법이 있었다는 것에 놀랐고, 이 기법을 차기 버전인 Windows 3.1에다 시스템 차원에서 정식 적용했다.

즉, 제3자 프로그래머는 Windows 3.0과의 호환성을 생각한다면 일일이 thunk를 만들어 주든가, 아니면 저 FixDS라는 툴로 후처리를 하면 되고..
3.1만 생각하면 된다면 저런 것 없이 프로그램을 편하게 만들면 된다.

2. 32비트 extender

Windows 3.x는 enhanced 모드에서 386 CPU에서 제공되는 멀티태스킹 관련 일부 기능만 사용할 뿐, 일단은 DOS와 마찬가지로 16비트 프로그램이었다.
그런데, 심지어 1993년에 Windows NT 3.1과 함께 PE 실행 파일과 Win32 API라는 게 정식으로 공개조차 되기 전에..!!!!
마소가 아닌 제3자 싸제 개발사에서 Windows 3.1을 위한 32비트 extender 런타임을 만든 경우도 있었다.

에 그러니까.. 옛날 도스용 게임에서 사용하던 DOS/4GW 같은 런타임의 Windows판이며, Win32s 같은 물건을 마소 말고 딴 데서 만들었다는 것이다. 미친;;
C/C++ 컴파일러로 유명했던 Watcom에서 Win386이라는 익스텐더를 만들었으며, 데이터베이스 앱인 Foxpro가 대표적으로 얘를 기반으로 동작했다. (☞ 관련 링크)

3. 32/16비트 flat thunk

Windows 95가 개발된 뒤, 마소에서는 32비트 코드와 16비트 코드 사이의 호환성 계층을 뚫어 주는 일에 진심이었다.
32비트 EXE에서 레거시 16비트 DLL의 함수를 호출하려면 뭐 thunk compiler를 돌려서 뭘 감싸 주고 메모리 주소를 무슨 세그먼트로 바꾸고 어쩌구저쩌구.. 했는데~

그 당시 Windows 95 Programming Secrets의 저자인 Matt Pietrek은 리버스 엔지니어링을 통해 마소에서 공개하지 않은 내부 API를 끄집어냈다.
이걸로 훨씬 더 간단하게 16비트 코드로 들어가는 방법을 공개하니 마소에서 그 당시에 크게 놀랐다고 한다. (☞ 관련 링크)
그 당시에 32비트 프로그램에서 시스템 리소스가 몇 % 남았다고 정보를 표시하는 건 이런 경로를 거쳐서 16비트 API를 호출해서 알아 온 것이었다.

4. 통째로 한글화

하긴, 꼭 외산 소프트웨어 말고 개인적으로 ‘한메한글 for Windows’도 굉장히 대단한 작품이었다고 생각한다.
Windows 3.x라는 준 운영체제를 통째로 마개조해서 없는 문자를 인식하게 만든 거니까.. 유니코드 시대가 도래하기 전에 말이다.

영문 원판에다가 한메한글만 씌운 게.. 마소 한국 지사에서 만든 정식 한글판보다 더 가볍고 성능이 뛰어났다. 그래서 그 시절 컴잘알들은 Windows를 그렇게 사용하기도 했다.
물론 16비트 시절에는 시스템이 불안정한 대신, 단독으로 시스템 전체에 영향을 주는 프로그램을 만들기도 훨씬 더 쉬웠었다.

그러고 보니 Windows 3.x 시절에는 껍데기 셸도 통째로 싸제 프로그램으로 갈아치우는 게 가능했다.
구닥다리 MDI 프로그램인 '프로그램 관리자' 말고 Norton Desktop을 띄운다거나, 한컴에서도 아래아한글 3.0x 시절에 '한컴 셸'이라고 꽤 괜찮은 유틸리티를 같이 선보인 적이 있었다.
이런 셸을 띄우면 Windows도 macOS라든가 NextSTEP 같은 타 운영체제와 더 비슷한 외형으로 바뀌었었다.

싸제 셸 프로그램 트렌드는 Windows 95에서 내 컴퓨터와 탐색기를 담당하는 전능하신 explorer 셸이 등장하면서 종결됐다. 이것도 참 재미있는 옛날 추억이다.;;

5. 비공식 그래픽 모드

끝으로, Windows 얘기는 아니지만..
Michael Abrash라는 프로그래머는 VGA 그래픽 카드의 스펙을 잘 뜯어보다가 제조사에서 정식 공개한 적 없는 기능을 찾아내서 발표했다.
그 당시 게임에서 많이 사용하던 320*200 mode 0x13 말고, 320*240 같은 해상도를 지원하는 일명 mode X 말이다. (☞ 관련 링크)

이 사람이 개발한 기술은 Doom 다음으로 Quake라는 FPS 게임에 도입됐다.
우리나라에서 옛날에 개발됐던 아마추어 슈팅 게임인 ‘85되었수다 / 삭제되었수다’도 내 기억이 맞다면 일반적인 mode 13h 말고 저 mode X 파생 그래픽 모드를 사용했었다.

Posted by 사무엘

1. 거대한 실행 파일

전통적으로 Windows 운영체제가 깔린 PC에서 볼 수 있는 엄청 큰 DLL 중 하나는.. 마소 Office 제품들이 사용하는 공용 라이브러리인 mso.dll 이다.
Program Files\Common Files\microsoft shared\OFFICExx 디렉터리에 있는 파일인데, 20여 년 전에 이미 크기가 10수 MB가 됐고, Office 2013의 64비트 버전 기준으로 36MB를 넘었다.

저 파일은 리소스나 데이터가 별로 없고, 대부분이 순수하게 코드만으로 저 크기이다.
오피스의 경우, 리소스들은 언어별로 별도의 리소스로 분리가 잘 돼 있기 때문이다.

그 뒤, 요즘은 웹 브라우저의 렌더링 엔진이 왕창 거대한 단일 DLL 자리를 차지하는 편이다.
Windows의 system 디렉터리에 있는 mshtml.dll 도 64비트 기준 20MB를 넘는다. 얘는 Internet Explorer 브라우저의 Trident 엔진 파일인데.. IE는 요즘 죽었으니까 제끼고.

많은 사람들이 사용하고 있을 크롬 브라우저의 코어 엔진인 chrome.dll은 거의 220MB에 달한다.
이게 내가 현재까지 알고 있는 제일 큰 DLL이다. 파일에서 적어도 3/4 가까이는 코드가 차지하고 있는 DLL 중에서 말이다.
그도 그럴 것이 요즘 웹 브라우저 엔진은 단순히 HTML을 파싱하는 문서 렌더러가 절대 아니고... 거의 독자적인 운영체제, 가상 머신, 프로그래밍 언어 런타임 급이 됐기 때문이다. 미치도록 거대할 수밖에 없다.

Visual Studio Code도 주 실행 파일인 code.exe가 160MB가 넘으니 엄청 큰 편이다. 얘도 파일 안을 들여다보면 무식한 리소스빨이 아니며, 전체의 3/4 가까이는 순수 기계어 실행 코드이다. 심지어 1년쯤 전엔 150MB대였던 걸로 기억하는데 업데이트를 거듭하면서 더 커졌다~!
그에 비해 내 한글 입력기는 코어 dll이 딱 1MB가 될까말까이다.;; 거기에다 기본 플러그 인 로딩까지 하면 1.5MB 정도 된다.;;

2. 버전 넘버링

마소의 Visual Studio와 Office는 Windows와 더불어 마소를 먹여 살리는 핵심 제품이다.
그런데 얘들은 2010년대 중반, Windows 10 무렵부터 버전을 크게 올리지 않고 깨작깨작 소수점 둘째 자리만 건드리는 게 관행이 됐다. 겉으로 크게 표시되는 연도 버전 말고, 내부의 번호 버전 말이다.

VS는 2015부터, Office는 2016부터 16.x 버전이 유지되고 있다. 그나마 VS는 2022가 출시되면서 번호가 17.x로 올라가긴 했지만, _MSC_VER의 값은 여전히 19xx대 고정이다.
뭐, Windows 역시 10부터 내부 파일들의 버전 역시 10.x 고정이긴 하다. 얘는 10을 끝으로 새 버전 브랜드를 더 만들지 않을 것처럼 얘기했다가 결국 11, 12를 내면서 입장을 번복하게 됐는데.. 그래도 11도 겉으로만 그럴 뿐, 내부 번호는 여전히 10이다.

10년 넘게, 거의 20년 가까이 1.0도 아니고 0.x대 버전을 유지하고 있는 건 DOSBox 내지 putty 정도인 것 같다.
그 반면, 웹브라우저 쪽은 크롬이 주 버전 번호를 팍팍 올리는 관행을 만들었다. 얘는 버전이 12도 아니고 이미 12x을 넘어섰다. 무려 백 자리..

Java의 경우, 한때 1.3, 1.4 이렇게 번호를 올리다가 2010년대부턴가 그냥 7, 8, 9로 넘버링 방식을 바꿨다. 주 번호를 계속 1로 유지하는 게 별 의미가 없다고 판단한 듯하다.
애플 진영도 macOS X이라고 해서 한때 10.1, 10.2, 10.3 ... 이러다가 나중에는 11, 12, ..., 14.x로 주 번호를 올리기 시작했다. Windows와 macOS 모두 버전의 주 번호에서 10을 떼어냈는데.. 내 한글 입력기는 언제쯤 10을 졸업할지? =_=;;

3. UI 트렌드

(1) 소프트웨어에서 자신의 종합적인 옵션/preference를 설정하는 명령이 있는 메뉴는? 보통은 '도구' 메뉴의 맨 끄트머리에 있는 게 관행인데, (마소 UI 디자인 가이드라인) 이게 약간 케바케 성향이 있는 것 같다. 크로스 플랫폼 제품 중에는 편집이나 심지어 파일 메뉴에 배치된 경우도 있다.

Windows 3.1 시절 옛날에는 아예 '옵션'이라는 메뉴가 따로 있기도 했다. 하지만 그런 관행은 95의 도입과 함께 거의 사라졌다. 수십-수백 개에 달하는 옵션들을 지정하는 단일 대화상자가 탭이나 웹페이지 형태로 거대하게 바뀌었을 뿐.
옛날에 아래아한글 2.0은 1.5x 이후로 기능 추가와 구조 변화가 워낙 많았던 제품인지라, 새로 추가된 옵션들이 '선택사항 - 기타'의 부메뉴로 중구난방으로 쭈루룩 달렸던 게 개인적으로 인상적이었다.;;;

(2) 데스크톱 프로그램이건, 웹사이트건.. '다크 모드'를 제공하는 게 요즘 완전 유행이 됐다.
글쎄, Windows에서 이거 전신은 '고대비 검정'이 아닐까 싶은데.. 이건 사용자 취향보다는 장애인 접근성이나 특수한 디스플레이 환경을 고려한 기능이었다.
아울러, 아이콘들의 디자인이 알록달록 대신 단촐해지면서 그림보다는 픽토그램에 더 가까워진다. 표현 형태도 벡터 폰트에 더 가까워졌다.

(3) SNS가 발달하면서 어디서나 사람 언급은 @, 키워드 태그는 #.. 이게 관행이 됐다.
이모지에다 별도의 문자 코드를 배당한다니 이게 도대체 무슨 일인가 싶었다만.. 이제는 게시글에 대한 피드백(좋아요, 놀라워요, 화나요 등등)조차도 거의 국제 표준을 제정해도 될 것 같다. 정말 2, 30년 전에 ICQ니 msn 메신저니, 네이트온 쓰던 시절에는 상상도 못 했던 관행이 생겼다.

(4) 리눅스 셸이 GNOME이냐 KDE냐 하는 건, 통신사를 SKT 쓰냐 KT 쓰냐 하는 것처럼 느껴진다. ㄲㄲㄲㄲ
개인적으로는 우분투+GNOME 말고 딴 건 접해 보지 못했다. 우분투가 대세인 듯..

(5) 어떤 컴퓨터를 원격으로 접속해서 사용하는 방법이란 게 전통적으로 (1) 명령 프롬프트(터미널), (2) 파일 시스템(FTP)으로 나뉘는 편이었다. 하지만 요즘은 컴터 성능과 네트워크 속도의 향상 덕분에 GUI 셸, 데스크톱을 통째로 가져와서 원격으로 쓰기도 한다. 이를 구현하는 프로토콜은 표준으로 채택된 게 있는지, 아니면 제품별로 다 찢어져 있는지 궁금하다.
이건 '텍' 같은 전산 조판 언어로 코딩하듯이 문서를 만들던 게, 그냥 GUI 위지윅 워드 프로세서로 바뀐 거나 마찬가지다.

(6) 크롬 브라우저에 있는 adblock 애드인은 단순히 웹사이트 한구석에 붙은 구글 광고만 차단하는 줄 알았더니만.. 유튜브의 짜증나는 6초~15초짜리 광고들까지 몽땅 차단 박고 스킵시켜 주는구나.. 오오~ 매우 놀랍다.
그런데 유튜브의 엔지니어들도 바보가 아닐 것이고 광고주의 자기들 밥줄을 끊는 짓은 단속하지 않을까..?? 창과 방패의 싸움이 계속될 듯하다.
유튜브를 exploit하는 두 가지 방법이 광고 차단이랑 동영상 다운로드인 셈이다.

4. 소프트웨어 업데이트

요즘은 소프트웨어의 보안 취약점 내지, 이를 이용해 증식하는 악성 코드가 야기하는 문제가 심각하다. 특히 랜섬웨어한테 자기 컴터나 심지어 직장 업무용 컴터가 털렸다는 소식은 본인조차 주변 지인으로부터 심심찮게 들었을 정도이다. 교통사고로 지인 누구가 다쳤다는 소식에 근접할 정도로 꽤 가까워지고 흔해졌다.

마소에서 보안, 보안 노래를 부르면서 모든 사용자에게 보안 업데이트를 끄지도 못하는 반강제로 주입시키고, 심지어 정품 인증에 실패한 불법 복제 Windows에다가도 보안 업데이트만은 무료로 꼬박꼬박 시켜 주는 건 다 이유가 있다.
악성 코드한테 털려서 좀비가 된 컴터는 다른 멀쩡한 컴터한테도 해를 끼치기 때문이다.

소프트웨어가 단순히 기능 추가나 자기 동작 차원의 버그 수정만 필요하다면 업데이트를 이렇게 귀찮을 정도로 강요할 필요가 없다. 하지만 지금은 보안 업데이트가 인간한테 주요 전염병 백신과 비슷한 존재가 돼 버렸지 말이다.

하지만 그럼에도 불구하고 요즘 Windows 업데이트는 너무 과한 구석이 있다. 악성 코드가 아니라 업데이트 서비스 네놈이 평소에 컴터 CPU를 과도하게 잡아먹고, 긴급히 컴터를 쓰고 싶은 상황에서도 세월아 네월아 재부팅을 강요한다.
그래서 요즘은 Windows를 부팅시켜 놓고 몇 주~몇 달째 계속 부팅 상태를 유지하며 켜 놓는 게(완전히 끄지 않고 절전 모드 전환도 포함) 사실상 불가능하다. 업데이트 설치 핑계로 지들이 제멋대로 재부팅을 해 버리기 때문이다.

옛날에 Windows 9x 시절이야 운영체제가 불안정하고, 16비트 영역의 메모리 리소스가 고갈됐기 때문에 컴을 오래 켜 놓을 수 없었다. 그때는 재부팅 정도가 아니라 운영체제 재설치까지 주기적으로 해야 했을 정도였다.
지금이야 그런 미개한 요인들이 당연히 전혀 존재하지 않는다. 그런데도 컴을 오래 켜 놓지 못한다는 거다. 이게 말이나 되냐?

5. 터미널 환경에서의 동작

개발자? 프로그래머? 소프트웨어 엔지니어? 암튼 이 바닥 종사하는 사람은 일반인들보다는 컴퓨터에서 GUI가 아니라 '명령 프롬프트'를 다룰 일이 더 많다.
Windows의 명령 프롬프트는 말할 것도 없고 PowerShell, Visual Studio Code, putty, Windows Terminal, 리눅스의 명령 프롬프트 등.. 다양한 프로그램에서 터미널을 쓰다 보면..

화면에 뜬 텍스트를 블록 잡고 복사하는 간단한 조작을 좀 하고 싶은데 키보드나 마우스 동작이 미묘하게 서로 달라서 불편을 겪곤 한다.
putty는 우클릭만으로 명령어 붙여넣기가 되는 반면, 어떤 데서는 그게 휠 클릭이고 우클릭은 일반적인 컨텍스트 메뉴 표시이다.

어떤 곳에서는 블록을 잡고 나서 Ctrl+C로 복사를 시키는 반면, 어떤 데서는 그랬다가는 실행 중지 Ctrl+C가 곧이곧대로 전달된다. 한 프로그램의 단축키와 동작에 익숙해졌는데 딴 프로그램에서는 그게 통하지 않아서 개인적으로 혼란스러웠다. =_=;;
개인적으로는 터미널의 GUI 차원에서 특정 문자열이 등장했을 때 highlight 시키는 기능, 그리고 구획을 나눠서 clear을 시키면 최신 구획의 텍스트만 다 날리는 기능 같은 게 있었으면 좋겠다.

터미널은 컴퓨터에 접근해서 뭔가 조작을 하는 제일 저렴하고 효율적인 방법임이 틀림없다. 이거 아니면 파일 시스템만 다루는 FTP.. 하지만 요즘은 컴터 성능과 네트워크 속도가 받쳐주다 보니 아예 원격 데스크톱 GUI 화면을 통째로 쏴 주는 가상화도 가능해졌고, 이게 터미널과 FTP 기능까지 상당 부분 흡수한 상태이다. 인터넷이 괜히 WWW가 닥치고 짱이 된 게 아니듯이 말이다.

6. 나머지 불편하거나 궁금한 거

(1) 10여 년 전, Windows 7쯤이었나? SSD 하드라는 게 처음 도입됐을 때 말이다. 하드디스크가 통째로 램 드라이브로 바뀌는 거나 마찬가지였기 때문에 부팅 속도가 획기적으로 빨라져서 신기하다고 난리였다.
그러나 Windows 10이니 11이니 하는 지금은..?? C 드라이브에 다들 SSD를 쓰고 있는 세상인데도 부팅 시간이 옛날에 재래식 하드로 Windows XP나 7을 부팅하는 것과 비슷하게 느껴진다.

디스크 속도가 올라간 것 이상으로 Windows도 더 무거워지고 이것저것 불러들이는 게 많아졌기 때문일 것이다. 에휴~
옛날에 디지털 카메라가 싸구려 기종이라도 폰카보다 좋은 게 물리적인 zoom 기능 말고도.. 부담 없이 끄고 켜는 게 가능하고 부팅이 아주 신속하게 된다는 것이었다. 디카에는 컴퓨터가 들어있긴 하지만 '범용 컴퓨터'가 들어있는 건 아니었기 때문이다.;;

(2) Windows 10/11의 시작 메뉴에서 검색란에다가 타이핑을 했는데 원하는 프로그램 검색이 안 되고 멀뚱멀뚱 있는 버그 말이다. 정말 악명 높지 않았는가?
글쎄, 내가 완전 최신 버전을 쓰고 있지는 않아서 잘 모르겠지만, 설마 아직까지 그 버그를 달고 다니지는 않으리라 추측한다.
이건 개인적으로 Win10의 사용 경험을 크게 악화시킨 버그였다. 사용자가 현실에서 엄청 자주 사용하게 될 기능이 이 따위로 동작하다니, 품질 관리를 도대체 어떻게 한 건지?

(3) Windows 8 시절부터 전통적으로 전해 내려오던 메트로 앱 '메일'이 요 근래에는 New Outlook으로 몰래, 쓰윽 대체된 듯하다. 수십 년 전에 있었던 Outlook Express의 후신이 등장한 것 같다만.. 개인적으로는 내가 관심 없고 사용하지 않는 프로그램이 제멋대로 설치되는 건 비호감이다. 이건 그놈의 보안하고도 아무 관련 없는 사항이지 않은가.

그리고 마소에서도 화상 회의 앱에 관심이 생겼는지 Microsoft Teams라는 걸 만들었는가 보다. 내가 실행하지도 않은 녀석이 제멋대로 깔려서 CPU를 잡아먹고 있길래 바로 강제 종료하고 제거해 버렸다.
악성코드를 빌미로 지들이 악성코드처럼 구는 거는 난 절대 용납 못 한다.

(4) 이건 PC가 아니라 잠시 스마트폰 얘기이다만.. 사용자가 입력하는 텍스트를 자동 완성 내지 오타 교정한답시고 사용자가 진짜로 의도한 문자열까지 제멋대로 바꿔 버리는 거 말이다. 아이폰이 여전히 악명 높은가 보다.
주변에서 이렇게 의도하지 않은 오타를 내는 사람을 많이 봤고, 나도 아이폰 쓰던 시절엔 이것 때문에 난감한 일을 몇 번 겪어 봤다.

난 내가 입력한 텍스트에는 내가 직접 책임을 지고 싶어서.. 마소 워드가 기본 제공하는 자동 고침 기능조차도 오지랖 불편함을 느끼는 사람이다. (대소문자, 줄표 등등~~) 자동 고침을 할 거면 그걸 철회하고 사용자의 원래 텍스트로 되돌리는 UI라도 주변에 눈에 띄게 넣든가.. 아이폰은 내 기억으로 그런 게 없었다.

(5) 어느 컴퓨터에나 프로그램 설치/제거 리스트를 보면.. 서버 개발자도 아닌 엔드 유저한테 MS SQL server는 누가 언제 왜 잔뜩 설치하는지 모르겠다. 도대체 어디에 쓰이는 물건인 걸까..??? 최신 버전도 아니고 그냥 2008인데 말이다.
옛날 win7 시절에는 '실버라이트'라는 제품도 슬그머니 깔리곤 했는데 그건 망했기 때문에 요즘은 눈에 띄지 않는다.

(6) Visual Studio라든가 아래아한글 같은 프로그램은 자체적인 설치 관리자 내지 업데이터를 보유하고 있는 제품이다. 그런데 뭔가 새 마이너 버전이 나와서 업데이트를 찍으면.. 업데이터 자기 자신부터 업데이트 되는 경우가 엄청 잦다. 그냥 심심하면 업데이트 된다.
업데이터는.. 일관된 체계로 버전 체크를 하고 새 패키지를 다운로드하고 파일 복사, 덮어쓰기, 삭제하는 기능이 전부일 텐데.. 한번 잘 만들어 놓고 나면 고칠 일이 거의 없을 텐데?? 내부적으로 뭐가 그렇게 자주 바뀔 게 있는지 개인적으로 매우 궁금하다.

Posted by 사무엘

1. Windows의 컴퓨터 비트 수 변화

과거에 주류 PC 환경이 (1) 16비트에서 32비트로 바뀌면서 소프트웨어 개발 환경이 크게 바뀌었다.
int와 WPARAM, handle, 포인터가 모두 4바이트 크기로 바뀌었고, 이로 인해 메시지도 몇몇은 스펙이 불가피하게 바뀌었다.
좌표계의 기본 단위도 다들 32비트로 확장됐고, 이로 인해 GDI 함수들이 상당수가 Ex 버전으로 바뀌었다. 왜냐하면 예전처럼 x, y 좌표 둘을 long 하나에다 묶어서 전달할 수가 없어졌기 때문이다.

하지만 선점형 멀티스레드가 지원되고 그 전에 모든 프로세스들이 자기만의 독립된 주소 공간을 갖는다는 건.. 과거엔 정말 상상도 못 할 혜택이다.
8비트야 거의 임베디드 급의 열악한 환경이니 멀티태스킹 따위는 별나라 얘기였다. 16비트 시절엔.. 어정쩡하게 아주 불편하고 힘들게 가능했던 반면.. 32비트가 되니 주소 공간도 넉넉하고 이제 좀 그럭저럭 할 만해진 것이다.

그리고 32비트에 와서는 예전에 깐깐하게 구분해야 했던 게 이제는 구분이 필요 없어지고(예: HINSTANCE vs HMODULE, far vs near), 예전에는 꼭 할당하고 해제해 줘야 했던 게 지금은 그럴 필요가 없는 등(resource 관련 API, MAKEPROC 따위).. 프로그래밍 하기가 전반적으로 더 간편해지고 편리해지기도 했다.

그에 비해 (2) 32비트에서 64비트로의 변화는 뭐.. int와 포인터의 크기가 달라진 것으로 인한 자잘한 충돌과 이식성 문제가 고작이다. 4GB 한계가 없어지기만 했을 뿐, 체감되는 변화는 아주 미미하다.
Windows의 경우, int는 물론 long조차도 여전히 32비트 크기로 유지된다. 그러나 WPARAM은 64비트로 확장됐다.

전에도 한번 얘기했듯이 게임기는 1990년대 후반, PC는 2000년대 후반, 스마트폰은 2010년대 후반이 돼서야 슬슬 64비트 시대에 들어섰다.
이런 곳은 비트 수가 점진적으로 늘어났기 때문에 기존 코드와의 호환성이 중요했다. 그렇기 때문에 포인터만 빼고 int나 long은 4바이트로 할지 8바이트로 할지 고민이 많은 편이었다.

그 반면.. 슈퍼컴퓨터 전용 아키텍처가 있던 시절 말이다. 197, 80년대에 처음부터 64비트로 시작했던 컴터 환경에서는 레거시 고민 따위 없었다. Cray 같은 플랫폼에서는 쿨하게 처음부터 int고 포인터고 몽땅 다 무식하게 64비트 모델을 채용한 곳도 있었다고 한다. 물론 오늘날이야 int까지 8바이트인 컴퓨팅 환경은 없다고 봐도 되지만..
그리고 저런 옛날 컴퓨터들은 데이터를 취급하고 연산하는 단위만 64비트였다. 아무리 슈퍼컴이라 해도 자기네 메모리 용량이 4GB에 미치지는 못했기 때문에 64비트 컴퓨팅이 곧 64비트 addressing을 의미하지는 않았다고 한다. addressing까지 다 되는 64비트 CPU는 1990년대가 돼서야 등장했다. (MIPS, DEC Alpha 따위) 아하~

얘기가 좀 옆길로 샜는데.. 아무튼 Windows는 16비트에서 32비트로 넘어갈 때 변화가 좀 있었고, 32에서 64비트로의 변화는 미미한 편이었다. 그럼 Windows의 역사상 16비트에서 32비트로의 전환만이 대격변이었던 것일까?
꼭 그렇지는 않았다. 오히려 더 옛날, (3) Windows 1 (+2)과 3 사이는 플랫폼 SDK의 변화, C 컴파일러의 변화 등의 단절이 더 심했다.

Windows 1과 2는 아직도 리얼 모드 내지 끽해야 286 표준 모드에서 멀티태스킹을 구현하던 정말 암울한 시절이다.
Windows의 오랜 역사를 좀 아는 guru라면, 20세기에 Windows에서 가장 혁신적인 변화는 바로 95나 NT도 아니고 3.0에서 "386 확장(enhanced) 모드"가 정식 도입되었던 사건이라고 말할 정도이다. (☞ 링크)

그랬기 때문에 Windows 1과 3은 같은 16비트 기계어에 같은 NE 포맷임에도 불구하고 1용 프로그램이 후대의 3 내지 9x에서 제대로 실행되지 않을 가능성이 매우 높았다.
게다가 저 1980년대의 구닥다리 C 컴파일러는 함수를 정의하는 문법조차 ANSI가 아닌 기괴한 K&R 방식이었다니.. 소스 레벨의 호환성도 기대하기 어렵겠다. 더 자세한 건 여기 글을 참고하시라. (☞ 링크)

2. 마소의 16비트 P-code 기술

마소와 관련된 옛날 이야기가 계속 이어진다. 이 블로그에서 본인이 지금까지 이 얘기를 한 번도 꺼낸 적이 없었다니 놀랍다.;;
네이티브 기계어가 아니라 다른 중립적인 바이트코드 기반으로 돌아가는 '가상 기계 프로그램'이라 하면 흔히 Java (JVM)나 C# (.NET, CLR) 같은 것만 떠올리기 쉽다. 이런 건 최소 32비트 이상의 컴퓨팅 환경에서 등장한 런타임 환경이다. 고유한 클래스 라이브러리도 갖고 있고 쓰레기 수집기도 제공한다.

하지만 마소는 창립하자마자 그 허접한 197, 80년대 8비트 컴퓨터로 제일 먼저 만들었던 게 BASIC 인터프리터였다. 현대적인 가상 머신 정도로 거창하지는 않지만, 그래도 고유한 바이트코드 가상머신 기술을 보유해서 16비트 컴퓨팅 시대까지 잘 써먹었다.

마소에서는 그 바이트코드를 스스로 P-code라고 불렀다. P는 pseudo-, portable, packed(조밀) 등을 뜻했다고 한다. 그리고 그걸 Basic뿐만 아니라 C/C++ 언어 컴파일러에다가도 접목했었다. 아니, 베이식은 그렇다 치지만 기계어 직통 컴파일이 당연시되는 언어이던 C/C++에다가는 성능(= 실행 속도) 희생까지 감수하면서 도대체 왜..?

이 바이트코드는 크기가 작았기 때문이다. 이게 packed의 의미이다.
같은 프로그램 소스를 비슷한 최적화 수준으로 컴파일 했을 때, 네이티브 x86 기계어 코드보다 훨씬 더 작은 크기로 표현할 수 있었다. 심지어 P-code를 해독하는 가상머신 코드의 오버헤드(9K 남짓?)를 포함시키더라도 수지맞는 장사였을 정도라니.. 이건 뭐 실행 파일 압축 기능까지 약간이나마 겸한 셈이었다.

컴퓨터 역사의 관점에서 볼 때 x86 자체도 골수 CISC 구조로서, 현대적인 아키텍처 대비 기계어 코드가 조밀하고 크기가 아주 작은 축에 드는 아키텍처라고 여겨진다. (그 대신 읽어들이고 디코딩하는 난이도가 쥐약이고, 저전력 모바일과 상극)
그런데 마소의 P-code는 그 악명 높던 x86 기계어보다도 더 조밀하고 작다니.. 그 시절에 얼마나 메모리가 비싸고 귀했고 메모리를 어떻게든 아껴야 했는지가 실감이 간다. PC에서도 386 486 같은 32비트 CPU는 진작에 등장하고 값도 내려갔지만.. 메모리가 아직 병목이었다. 이게 더 싸지고 풍부해진 뒤에야 본격적으로 Windows 95/NT가 쓰일 수 있었다.

Visual Basic이야 exe를 생성한다 해도 런타임 dll이 따로 필요하고 내부 코드는 P-code 기반이었다. 1997년에 출시된 5.0.. 최초로 32비트 전용으로 출시된 이 버전에 이르러서야 네이티브 코드 컴파일 기능이 도입됐다.
C/C++의 경우, MS C/C++ 7.0과 Visual C++ 1.x 시절.. 16비트 한정으로 이런 기능이 있다가 32비트부터는 폐기됐다. 그 대신, 16비트이기만 하면 플랫폼은 DOS와 Windows를 모두 지원했다.

따지고 보면 Windows NT의 32비트 PE (portable executable)는 저런 P-code와는 접점이 없었던 셈이다. 32비트 Visual Basic 5나 6을 쓰지 않는 한 말이다
자세한 것은 이 링크의 설명을 참고하시라. 마소의 전설적인 P-code에 대해서 구체적으로 소개한 글은 "Microsoft P-Code Technology" by Andy Padawer이 유일한 것 같다.

QuickBasic이나 GWBASIC은 소스 코드를 고유한 바이너리 포맷으로 저장하는 기능이 있었다. 이건 세상 그 어느 프로그램 개발 환경에서도 없는 기능이었지 싶다.
그 반면, 저 P-code는 소스 코드가 아니라 나름 기계어를 표방하고 컴파일된 코드였다는 차이가 있다.

3. 마소와 볼랜드 프로그래밍 툴의 Windows 지원 내력

(1) 아마 예전에 이 얘기를 한 적이 있었을 텐데..
1980년대 말부터 마소와 볼랜드에서는 주요 프로그래밍/개발툴을 내놓으면서 뭔가 교육용 저가 보급형 제품군에다가는 각각 Quick과 Turbo라는 스피디한 브랜드명을 붙였고, 기업용 기함급 모델에다가는 그냥 자기 회사 이름을 붙였었다.

(2) 1990년대 초엔 C 컴파일러에는 C++의 지원이 추가되었다. 그래서 지원 언어 표기가 C/C++이라고 바뀌었다.
마소의 경우, QuickC는 Microsoft C를 먼저 만들다가 곁다리로 병행하며 잠깐 만들었던 제품이다. 이건 C++ 지원 없이 겨우 2.0에서 맥이 끊겼다. 그 대신 이전부터 만들어 오던 MS C 6의 다음 버전이 MS C/C++ 7이 되었다(1992). 그리고 이거 다음 버전부터는 그 이름도 찬란한 Visual 브랜드가 시작됐고, C는 떼어낸 채 Visual C++ 1로 넘어갔다.

저 때는 1993년 무렵이었다. Visual C++은 Windows NT와도 역사를 함께한다. 이게 마소에서 최초로 내놓은 32비트 C/C++ 컴파일러이며, Windows NT 내부의 각종 프로그램들을 빌드하는 용도로, 즉 자체적으로도 쓰였기 때문이다.
물론 Visual C++도 1.5까지는 16비트 버전이 같이 나오긴 했었다. 그리고 대외적인 버전 번호는 1로 리셋됐지만 얘 역시 MS C를 계승한 제품이라는 흔적은 MSC_VER이던가 그 매크로 상수의 번호에 남아 있다.

(3) 한편, 볼랜드 진영에서는 Turbo C 2.0의 다음 작품이 Turbo C++ 1.0이 되었다. 제품명과 버전이 다 리셋됐다니 좀 이례적이다.
그리고 그 다음 버전인 Turbo C++ 2때부터 같은 버전의 Borland C++도 나란히 나오기 시작했다고는 하는데.. 실질적으로 Turbo와 Borland의 구분이 생겼다고 일반인들이 존재감을 인지하는 첫 버전은 3이다.
Turbo C++은 3인가 3.1에서 맥이 끊겼다. 그 뒤 적어도 4~5 버전부터는 Borland C++만 나오다가 RAD 툴인 C++ Builder 1로 넘어갔다.

(4) 그 시절 C/C++ 컴파일러 업계에서는 C++ 지원뿐만 아니라 Windows 플랫폼의 지원도 중요한 이슈였다.
마소는 DOS에 이어 Windows를 만들던 본가였고, C는 어셈블리어와 더불어 자기들 제품을 만들 때 사용되는 주력 언어이기도 했다. 그러니 MS C는 처음부터 Windows를 지원하는 게 너무 당연한 일이었다.

1980년대 중반, 정말 구닥다리 MS C 4~5 시절부터.. 그야말로 전설적인 Windows 1.x, 2.x 프로그램을 만들 수 있었다. 단, QuickC는 DOS용 버전 2.x대와 별개로 QuickC for Windows 1.0이 딱 한 번만 나오고 말았던 듯하다. 요컨대 마소는 QuickC의 Windows 버전만이 버전 리셋을 했고, 볼랜드는 C++ 컴파일러를 구현할 때 버전 리셋을 했다.

그에 비해 볼랜드 제품에서 Windows 지원이 추가된 건 버전 3.x부터로, C++까지 지원되고 난 이후의 일이다. Windows용 32비트 extender까지 미리 만들었던 Watcom 같은 업체하고는 개발 방향이 많이 달랐던 것 같다. 그 대신 볼랜드에서는 OWL이라고 꽤 잘 만든 객체지향 프레임워크를 연구 개발했다.
이렇듯, Windows 지원과 관련해서는 볼랜드와 마소 개발툴 간에 이런 내력의 차이가 있었던 셈이다.

(5) 자, 그럼 C/C++ 다음으로 파스칼의 세계로 가면..
볼랜드에서 Turbo Pascal을 내놓으면서 1980년대를 호령하고 재미를 봤다. 도스 아니면 기껏해야 OS/2에서 말이다. 그러다가 1990년대 초, Turbo Pascal 6 타이밍 때 TP for Windows를 1.0과 1.5 두 차례 내놓았다. 아마 5.x던가 6이던가..
이때 ObjectPascal이라는 객체지향 문법이 언어에 도입되기도 했지만 이건 TP의 버전에 영향을 주지 않았다. 그 대신 Windows용을 1.0부터 다시 내놓았다는 점이 Turbo C++과는 다르다.

그러다가 Turbo Pascal 버전 7이 Borland Pascal 7과 나란히 출시됐으며.. 이 BP7은 TP for Windows 2를 통합· 포함한 형태가 됐다. 제품 라인업 한번 복잡하네..;;
TPW는 about 대화상자에 수학자 파스칼 얼굴이 그려져 있는 반면, BPW는 그렇지 않다는 차이가 있다.;;;

1992년에 출시된 Borland C++ 3.1, 그리고 Borland Pascal 7이 도스와 Win16을 풍미했던 장수만세 안정판으로 여겨진다.
Borland C++은 C++ Builder로 넘어가기 전 1993~1995년 사이에 자체적으로 버전이 4~5까지 올라가기도 한 반면, BP는 델파이로 넘어가기 전에 딱히 버전업이 없었다.
심지어 Delphi도 1995년의 첫 버전 1은 Win16, 16비트용이었고 버전 2부터 Win32로 넘어갔으니, 32비트화도 C++보다 늦은 셈이다.

한편, 마소는?? 처음에 Microsoft Pascal을 1980년대에 4.x 버전까지 개발했었다. 하지만 이건 Turbo Pascal과의 경쟁에서 승산이 없다고 판단했는지 접었다. 그렇게 접기 직전에 경쟁사 제품처럼 뽀대나는 IDE를 얹은 QuickPascal 1.0을 최후의 발악 차원에서 한번 내놓았을 뿐이다. Windows 지원 같은 것도 당연히 없었고 제품의 맥이 끊겼다.
볼랜드에서는 Turbo Basic을 만들었다가 반대로 마소의 QuickBasic 대비 승산이 없다고 생각해서 포기해 버렸으니.. 행보가 서로 정반대인 셈이다.

Posted by 사무엘

예전에 했던 말도 있지만.. 암튼 지난 30여 년에 달하는 컴퓨터의 역사를 곱씹어 보는 건 재미있다~!

1. 인텔 CPU

(1) 인텔 8086은 유구한 x86 시대의 서막을 연 기념비적인 16비트 CPU이다(1978). 나중에 출시된 8088은(1979) 거기에서 외부 데이터 버스만 8비트로 낮춰서 성능을 약간 디버프 했지만 가격도 낮췄다.
80186의 존재감은 비행기에서 보잉 717의 존재감과 아주 비슷하게 듣보잡이다. -_-;; 애초에 PC보다는 임베디드용으로 만들어진 8086의 변종이었다.

(2) 80286의 제일 큰 존재 의의는 보호 모드의 첫 지원이지만.. 이게 많이 부족하고 불완전해서 역시 듣보잡으로 묻혔다. CPU로서 80286은 그냥 클럭 속도 더 빨라진 8086이나 다름없고, 현실적으론 컴퓨터 완성품으로서 AT (286 기반)가 XT (8088 기반)보다 나아진 점이 훨씬 더 많이 와 닿곤 했다. 2HD 고밀도 디스켓, 배터리 기반 시계, 키보드 속도 조절 등..
그에 비해 101키 키보드, VGA 컬러 그래픽이나 하드디스크는 XT에도 일단 장착 가능은 했던 구성요소이다.

(3) 80386은 드디어 32비트 CPU이다. 32비트 정도는 돼야 어지간히 큰 정수라든가 부동소수점을 원활히 표현할 수 있고, 메모리 주소 공간도 넉넉히 확보해서 보호 모드 가상 메모리 같은 것도 구현할 수 있다.
오리지널 DX는 외부 데이터 버스와 메모리 주소 버스도 모두 32비트인 반면, 염가 다운그레이드 에디션으로 나중에 출시된 SX는 이게 각각 16비트, 24비트였다. 과거 8086과 8088의 관계와 거의 동일하다.

(4) 80486도 DX와 SX 구분이 있었는데, 이때는 단순히 부동소수점 코프로세서가 기본 내장된 게 DX이고, 안 그런 게 SX였다. 거기에다 486은 DX조차도 클럭 속도를 더 끌어올린 DX2, DX4 이런 구분이 있었다.
이때 'VESA 로컬 버스' 규격 갖고 많이 떠들곤 했다. 천상 486 전용 규격으로 쓰이다 말았지만..
그리고 캐시 메모리라는 게 들어가기도 하고.. 486이 386에 비해 많이 발전하긴 했었다.
1990년대 중반, 486? 펜티엄쯤부터 컴퓨터 본체의 모양이 모니터 아래에 가로로 놓는 게 아니라 모니터 옆에 세로로 놓는 형태로 슬슬 바뀌어 정착했다.

(5) 펜티엄은.. 외부 데이터 버스가 CPU의 레지스터보다도 더 큰 64비트로 확장됐다. 물론 그렇다고 펜티엄이 아키텍처 차원에서 64비트 CPU인 건 아니었다.
인텔 셀러론의 초창기 버전은 펜티엄 2에서 L2 캐시 메모리가 없는 보급 염가판이었다. 그런데 이게 아예 전혀 없으니까 성능이 너무 떨어져서 나중에는 캐시가 약간이나마 장착되기도 했다.

이렇듯, 컴퓨터의 성능에는 클럭만 영향을 끼치는 게 아님을 알 수 있다.
그리고 한때는 옵션으로 주어졌던 요소들이 나중엔 다 기본으로 포함돼 들어가고 다른 새로운 기능이 옵션으로 도입된다.

2. Windows 운영체제

• Windows 3.0은 MDI 창, VGA와 본격적인 컬러 지원을 위한 장치 독립 비트맵(DIB), WinHelp(!!!) 같은 획기적인 기능을 도입했고, 3.1에서는 OLE, 트루타입 글꼴, 공용 대화상자를 도입함으로써 현대의 Windows 근간을 닦았다.
• 거기에다 Windows 3.0은 386 확장 모드라는 걸 도입해서 80386 이상 CPU에서 지원되는 보호 모드 멀티태스킹 기능을 일부 사용하기도 했다. 하지만 앱이 전반적으로 돌아가는 건 다 16비트 기반이다.
• Windows NT는 저렇게 도스 진흙탕인 기존 Windows와는 달리, 미래를 바라보며 개발됐다. DEC Alpha라는 64비트 CPU용 에디션이 있기도 했으나.. 이때는 컴퓨터의 메모리도 4GB보다 훨씬 모자랐고 Windows 역시 그냥 32비트 모드로 동작했다고 한다. 포인터 8바이트니 INTPTR이니 그런 거 없었다는 뜻..

그렇기 때문에 Windows의 역사상 최초의 진정한 64비트 프로그래밍을 개막한 아키텍처는 IA64였다.
그 전 20세기의 NT4 시절에는 DEC Alpha뿐만 아니라 PowerPC네 MIPS네 여러 자잘한 아키텍처를 지원하다가 말았고, 2000년대부터는 x64와 ARM64가 살아남았으니 2000년대 초가 중대한 전환점이었다.

허나, 그 전환점의 중심에 서 있던 IA64는 좋은 타이밍을 날리고 장렬히 자폭했다... =_=;; 사실은 IA64가 채택했던 VLIW라는 설계 방식부터가 성능 대비 단점과 위험 부담도 너무 큰 방식었다. 마치 자동차 엔진에서 통상적인 왕복 엔진이 아니라 로터리 엔진처럼 말이다.
이런 사연으로 인해 Windows 2000은 NT 계열의 개발 역사상 전무후무하게 오로지 x86 전용으로만 출시되는 이변이 벌어졌었다. 무슨 9x처럼 말이다.

• Windows 98은 마우스 휠과 멀티모니터를 최초로 공식 지원하기 시작했다.
• Windows 2000/ME에서는 일부 마우스의 옆구리에 달려 있는 추가 버튼을 L, R 말고 X-button이라는 이름으로 최초로 지원하기 시작했다. 아마 전통적인 상하 스크롤 말고 좌우 스크롤 휠도?
• Windows 7은 SSD와 멀티터치 디스플레이를 최초로 공식 지원하기 시작했다.

아울러,

• USB 메모리를 별도의 드라이버 설치 없이 자체적으로 인식하기 시작한 건 2000/ME부터다.
• XP/Vista 어느 때쯤부터 이제 와이파이도 별도의 프로그램/드라이버 설치 없이 자체적으로 잡기 시작했다.
  무슨 프로그램 띄워서 모뎀 전화를 걸어서 인터넷 접속하고, 그 뒤부터 연결 시간이 올라가던 게 1990년대 말쯤 일이었는데.. 참 격세지감이다.

3. 하드웨어의 발전 양상

성능 증가

• 1990년대 동안은 클럭 속도가 뻥튀기 하듯 폭증했다.
• 1990년대 후반부터는 메모리 양이 폭증했다. Windows 95~98 사이 말이다.
• 2000년대 이후부터는 무선 인터넷 네트웍 속도가 폭증해 왔다.

64비트화

• 워크스테이션/슈퍼컴 쪽은 모르겠고, 개인과 가정 레벨에서는 1990년대 말에 게임기부터 가장 먼저 64비트 CPU를 도입했다. 내 기억으로 닌텐도64..;;
• PC는 2000년대 초에 IA64가 대차게 망하는 바람에 한 타이밍을 완전히 놓쳤고, 2000년대 중반쯤 램 용량이 실제로 4GB를 넘긴 뒤에야 64비트가 대중화됐다. Windows 2000/XP가 아니라 Vista/7 타이밍이다.
• 스마트폰 업계는 2010년대 중반쯤에 슬슬 64비트로 전환이 시작돼서 2010년대 말엔 32비트 앱에 대한 지원을 끊네 마네 하는 상태가 된 것 같다.

오늘날 경전철이라고 해서 협궤를 쓰는 게 아니듯, 주머니에 넣어 다니는 작은 모바일 컴퓨터라고 해서 16/32비트 따위를 쓰지는 않는다. 커다란 화면에다 현란한 천연색 3D 그래픽과 고화질 동영상을 찍으려면 64비트 고성능 CPU는 필수이다. 물론 고성능 CPU는 전기도 많이 먹으니 고성능 배터리도 필수..

4. 그래픽

(1) 그래픽 가속이라고 하니까 게임용 3차원 그래픽 렌더링이라든가 동영상 코덱 같은 것만 떠올리기 쉬운데.. 사실은 2D 기반의 통상적인 GUI 구현을 위해서도 작은 수준의 하드웨어 가속이 오래 전부터 쓰여 왔다.
마우스 포인터라든가(깜빡이지 않는 것, 마우스 포인터 자취 표시, 포인터 주변의 그림자).. 화면 스크롤도 다 가속의 결과물이다. CPU 연산 기반으로 도트를 옮기는 수작업이 아니다.

(2) Windows의 그래픽 API (GDI)는 너무 범용적이고 장치 독립적으로 만들어졌다 보니, 당장 화면에 그려지는 픽셀 도트 값을 알아 내거나 색깔 바꾸기, 메모리 내용을 그대로 비트맵으로 간주해서 뿌리기 같은 간단한 작업조차도 오버헤드가 크고 일이 쉽지 않았다.
비디오 메모리에다 숫자 하나만 쓰면 끝날 일을 뭐 펜을 만들고 브러시를 만들고 DC에다 select시키고.. 운영체제 차원에서 직통 접근을 허용하지 않았던 것이다.

그러던 것이 Windows 3.0에서 DIB가 도입됐고, Windows 95 내지 NT 3.5에서 CreateDIBSection 계열 함수가 추가됨으로써.. 메모리 내용을 비트맵으로 그대로 뿌리는 일은 그럭저럭 가능해졌다. 옛날 WinG가 제공했던 기능도 다 이런 것들이었다. ‘비트맵 고속 전송’
다른 3D 가속 같은 거 전혀 없이 이거 하나만으로 Windows에서 Doom을 포팅하고 돌릴 수 있게 됐다.;;

Doom은 3D 전용 가속 기능이 없이 CPU와 초보적인 그래픽 가속만으로 만들어진 마지막 3D FPS였던 셈이다.
이거 마치 인어공주가 CG 없이 100% 셀 애니로만 만들어진 마지막 디즈니 애니인 것과 비슷한 느낌이다.

(3) 하긴, 옛날에는 그래픽 파일의 압축이라는 것도 원시적인 run-length 방식이 고작이었다. 더 빡세게 압축된 GIF나 PNG 파일 하나 열려면 386급 이상 컴퓨터가 필요했고, 디코딩도 훨씬 더 오래 걸렸었다. 하물며 JPG는 뭐 말할 것도 없고..
동영상조차도 1990년대 초중반에 Video for Windows 이러면서 나돌던 AVI는 쌩 run-length 압축인 게 많았다. 화질이나 압축률은 완전 허접 수준이었다.

WinAMP로 486/펜티엄 급 Windows 95 PC에서 128kbps짜리 mp3을 하나 재생하면 CPU 사용률이 10~20%까지 치솟았는데.. 이 역시 아련한 추억이다.
지금 우리가 전화기로도 당연하게 감상하는 디지털 멀티미디어 데이터들이 불과 2~30년 전에는 이렇게 가볍게 다뤄지던 물건이 전혀 아니었다. 그나마 가볍게 다루려면 기술 수준이 더 낮은 아날로그 매체만으로 만족해야 했다.;;

5. 나머지

(1) 64비트와 멀티코어는 서로 다른 별개의 분야이지만 거의 같은 시기에 태동해서 동시에 도입됐다(Core 2 Duo). plug & play와 USB하고 비슷한 관계인 것 같다. Win95/98 시절엔 USB 없이 직렬 포트에다가 프린터나 스캐너를 연결하고는 "새 하드웨어 발견.." 이러기도 했었다는 것 기억 나시는가? =_=;;
아울러, 모니터가 와이드 화면이 대세가 된 것도 2000년대 중반쯤으로 64비트니 멀티코어니 하던 때와 시기가 아주 비슷하다.;;

(2) 2000년대 초중반, 사운드 카드가 '인텔 사운드맥스'인지 뭔지 아무튼 메인보드에 내장돼 들어갔다. 그래픽 카드도 어지간히 까다로운 게임을 하는 게 아니라 기본 기능은 그냥 메인보드 내장으로 퉁쳐졌다.

(3) 요즘 노트북이나 스마트폰은 너무 얇아져서 뭔가를 꽂는 단자조차 너무 간소화되는 것 같다. 이건 개인적으로 좀 불편하게 느낀다.;;
가령, 구형 맥북은 큼직한 USB-A를 바로 꽂을 수 있지만 요즘 맥북은 그렇지 않고 C형만 꽂을 수 있다. 그리고 구형 갤럭시는 컴터용 이어폰을 바로 꽂을 수 있는 반면, 요즘 갤럭시는 그렇지 못하다.

(4) 범용적인 컴퓨터 말고 다른 기계들의 사정은 어떨까?
가정용 게임기, 업소용 오락기.. 이 둘도 차이가 있을 것 같고 내비게이션, 노래방 기계, 그리고 VR 게임기에 쓰이는 컴퓨터도 평범한 가정용 CPU 기반은 아닐 것 같은데.. 심지어 x86 계열이 아닐지도..??
요즘은 폰에 밀려서 디지털 카메라라는 물건이 많이 도태했지만, 그래도 부팅이 엄청 빨리 되는 것과 zoom이(= 렌즈빨) 더 뛰어난 건 디카만의 독자적인 장점이다. 그런 기기를 프로그래밍 하는 건 아무래도 임베디드 영역이지 싶다.

Posted by 사무엘

1. 컴포넌트화의 필요성

전산학 중에서 소프트웨어공학이라는 것은 방대한 소프트웨어를 인간이 여전히 유지보수 가능하게 복잡도를 제어하며 설계하기, 기능과 파트별로 역할을 잘 분담시켜서 각 파트만 재사용하거나 딴 걸로 교체를 쉽게 가능하게 하기, 소프트웨어의 분량· 작업량· 품질을 정확하게 측정하고 효율적인 개발 절차를 정립하기처럼..
응용수학이나 전자공학보다는 산업공학과 가까운 측면이 있다. 단지, 얘는 유형의 제품이 아니라 무형의 코드 형태이기 때문에 여느 공산품과는 성격이 약간 다르게 취급될 뿐이다.

20세기 후반에 인공지능 연구 업계에 "AI 겨울"이 있었고 게임 업계에 "아타리 쇼크"라는 재앙이 있었던 것처럼, 프로그래밍 업계에도 "소프트웨어의 위기"라는 게 이미 1970년대에부터 있었다.

• 코딩을 너무 중구난방으로 하고 나니, 일정 규모 이상의 프로젝트에서는 도대체 유지보수가 되질 않고 그냥 처음부터 다시 새로 만드는 게 더 나을 지경이 된다.
  
• 이놈의 빌어먹을 스파게티 코드는 하는 일도 별로 없는데 쓸데없이 너무 복잡해서.. 처음에 작성했던 사람 말고는 알아먹을 수가 없고 maintainable하지가 않다.
• 소프트웨어의 개발 속도가 오히려 하드웨어의 발전 속도를 따라가지 못한다.
• 작업 기간을 줄이기 위해서 사람을 더 뽑았는데.. 웬걸, 신입들을 가르치느라 시간이 더 소요된다;;;

그래서일까..??
"무식한 goto문 사용을 자제하자"라는 구조화 프로그래밍 이후로 객체지향 프로그래밍이란 게 프로그래밍 언어와 코딩 패러다임을 완전히 정복했다. 요즘 주류 언어들 중에 '클래스', 그리고 '상속'이라는 게 없는 언어는 찾을 수 없을 것이다.;; 이게 캡슐화, 은닉, 재사용성 등 소프트웨어공학적으로 여러 바람직한 이념을 코드에다 자연스럽게 반영해 주기 때문이다.

실험적으로 시도됐던 초창기의 순수 객체지향 언어들은 유연하지만 느린 런타임 바인딩 기반의 메시지로 객체 메소드를 호출한다거나.. 심지어 정수 하나 같은 built-in type에다가도 몽땅 타입 정보 같은 걸 덧붙이며 객체지향을 구현하느라 성능 삽질이 많은 경우도 있었다.
그러나 C++은 객체지향 이념에다가 C의 저수준, 그리고 빌드타임 바인딩(경직되지만 빠른..)을 지향하는 현실 절충형 디자인 덕분에 상업적으로 굉장히 성공한 객체지향 언어로 등극했다.

2. 마소의 실험

자 그래서..
1990년대에 마소에서는 고유 브랜드인 Windows가 대히트를 치고 소프트웨어 OEM (IBM 납품..)으로 그럭저럭 먹고 살던 처지를 완전히 벗어나니.. 당장 먹고 사는 고민보다 더 본질적이고 고차원적인, 소프트웨어공학적인 고민을 시작했던 것 같다.
얘들 역시 소프트웨어를 재사용 가능한 컴포넌트 형태로 만드는 것에 관심을 많이 기울였다. 그래서 재사용을 위해 바이너리 수준의 공통 규약, 프로토콜을 만들어서 자기들의 운영체제 차원에서 밀어붙이고 홍보하기 시작했다.

이때가 마침 C에 이어 C++ 컴파일러를 개발하고 MFC라는 라이브러리도 만들고, 코딩 스타일에 본격적으로 '객체지향'이란 게 가미되기도 했던 때이다. 하지만 마소에서 추구했던 것은 단순히 언어나 개발툴 차원에서 함수나 클래스의 모음집인 라이브러리 SDK 만들고 DLL 만드는 것 이상의 수준이었다.

제일 먼저.. (1) Windows라는 이름답게, 특정 기능을 수행하는 윈도 컨트롤을 컴포넌트화한다. 리치 에디트 컨트롤을 비롯해 각종 공용 컨트롤, 웹브라우저 컨트롤 같은 것 말이다. 이 사고방식이 극대화되어 "컴포넌트를 내 폼에다가 끌어다 놓고, 프로퍼티를 설정하고 이벤트 핸들러를 구현해서 응용 프로그램을 곧바로 만든다" RAD라는 개념이 완성되었으며.. Visual Basic이라는 정말 똘끼 충만한 개발툴이 만들어지게 됐다.

도스 시절의 GWBASIC이나 QuickBasic에서 참신한 점은 그 특유의 대화식 환경이었는데, Visual Basic은 또 다른 새로운 돌풍을 일으켰다. 경쟁사인 볼랜드에서는 이런 개발 스타일을 파스칼과 C++에다가도 도입하게 됐다.

(2) 그리고 마소에서는 서로 다른 응용 프로그램에서 만든 결과물을 문서에 자유롭게 삽입할 수 있게 했다. 이름하여 OLE라는 기술이다.
가령, Windows의 워드패드는 아래아한글이나 MS Office Word에 비하면 아주 허접한 프로그램일 뿐이다. 하지만 문서 안에 그림판에서 만든 비트맵 이미지를 집어넣고, 엑셀에서 만든 차트를 집어넣을 수 있다.

별도의 수학 수식 편집기에서 만든 수식, 악보 편집기에서 만든 악보, 그리고 WordArt/글맵시 같은 프로그램으로 만든 각종 글자 꾸임 배너까지..
단순히 무식한 그림 형태로 집어넣는 게 아니라는 것이 핵심이다. 이것들은 벡터 이미지로 취급되기 때문에 크기를 키워도 화질이 깔끔하게 유지된다.

그리고 그런 출력 이미지 자체뿐만 아니라, 각 프로그램에서 취급하는 내부 원본 데이터, 즉 소스가 그대로 보존된다. 그렇기 때문에 만들었던 객체를 손쉽게 수정도 할 수 있다.
그 객체를 더블 클릭하면 프로그램 내부에서 그림판이나 악보 편집기, 수식 편집기 등이 잠시 실행돼서 객체를 수정하는 상태가 된다..;;

서로 다른 프로그램이 이런 식으로 서로 분업 협업한다니.. 신기하지 않은가? 도스 시절에는 상상도 못 한 일일 것이다.

3. 프로그래밍의 관점

그러니 Windows에서 워드처럼 뭔가 인쇄 가능한 출력물을 만드는 업무 프로그램이라면 OLE 지원은 그냥 닥치고 무조건 필수였다. 다른 OLE 프로그램의 결과물을 삽입하든(클라), 아니면 다른 프로그램에다 자기 결과물을 제공하든(서버), 혹은 둘 다 말이다. macOS나 리눅스에는 비슷한 역할을 하는 규격이나 기술이 있는지 궁금하다.

Windows 프로그래밍을 다루는 책은 고급 topic에서 OLE를 다루는 것이 관행이었다. 다만, Windows API만으로 OLE 지원을 저수준 구현하는 건 굉장히 노가다가 심하고 귀찮았다. 그래서 MFC 같은 라이브러리 내지 아예 VB 같은 상위 런타임이 이 일을 상당수 간소화해 줬었다. MFC 앱 신규 프로젝트 세팅 마법사의 경우, OLE 지원 기능의 추가 여부를 선택하는 옵션이 응당 제공되었다.

Windows라는 플랫폼의 프로그래밍에 입문하려면 창(윈도)의 스타일과 특성, 메시지 메커니즘을 알아야 할 것이고 그래픽 API라든가 셸의 구조에 대해서도 알아야 할 것이다.
그런데 그런 것뿐만 아니라 이 바닥도 완전히 독립된 별개의 프로그래밍 분야이며, 기초부터 고급까지 한데 연결된 Windows 프로그래밍의 정수라고 생각된다.

이건 제일 간단하게는 확장자 연결이나 클립보드, drag & drop 구현과도 연결고리가 있다. 이 분야 API를 제공하다 보니 COM이라는 IUnknown이 어떻고 type library가 어떻고 하는 규격이 제정되었다.
사실, Windows에 레지스트리라는 것도 맨 처음엔 확장자 연결이나 OLE 클라/서버 정보만 저장하기 위해서 만들어졌다가.. 나중에 ini를 대체하는 응용 프로그램 설정 저장 DB로 용도가 확장된 것이다.

COM 형태로 제공되는 운영체제 기능을 사용하려면 CoCreateInstance를 호출해야 하고, 이런 프로그램은 처음에 CoInitialize라는 함수를 호출해 줘야 한다. 즉, 운영체제를 상대로도 별도의 초기화가 필요하다는 것이다.
그런데 OLE 기능을 사용하려면 OleInitialize라는 함수를 사용하게 돼 있는데, 얘가 하는 일은 CoInitialize의 상위 호환이다. OLE가 COM의 형태로 구현돼 있기 때문에 그렇다. 둘의 관계가 이러하다.

굳이 OLE 관련 기능뿐만 아니라 가까이에는 DirectX, 그리고 날개셋 한글 입력기와도 관계가 있는 TSF 문자 입력 인터페이스도 다 COM 기반이다. 하지만 문자 입력은 굳이 COM이나 OLE 따위 기능을 사용하지 않는 프로그램에서도 관련 기능을 접근할 수 있어야 하기 때문에 COM 초기화 없이 관련 인터페이스들을 바로 생성해 주는 함수를 별도로 제공하는 편이다.

4. ActiveX

과거에 인터넷 환경에서 마소 IE 브라우저의 지저분한 독점과 비표준 ActiveX는 정말 악명 높았다. 그런데 ActiveX라는 건 도대체 무슨 물건인 걸까??

마소에서는 앞서 컴포넌트화했던 그 윈도 컨트롤들을 데스크톱 앱뿐만 아니라 인터넷 웹에서도 그대로 돌려서 그 당시 1990년대 중후반에 각광받고 있던 Java applet에 대항하려 했다. Visual Basic 폼 내지, 특정 프로그램의 내부에서 플래시나 IE 컨트롤 생성하듯이 꺼내 쓸 법한 물건을 웹에서 HTML object 태그를 지정해서 그대로 띄운다는 것이다.

그때는 컴퓨터의 성능이 지금처럼 좋지 못했고 지금 같은 방대한 웹 표준이 존재하지도 않았었다.
그러니 웹브라우저에서 동영상도 보고 초고속으로 돌아가는 게임도 하고, 특히 무엇보다도 금융 거래를 위한 각종 암호화 기능을 돌리기 위해서는 닥치고 웹에서 그냥 생짜 x86 native 앱을 돌리는 게 제일 편했다.

이런 컴포넌트의 이름이 OLE Control이었는데, 이걸 웹에다 특화된 형태로 신비주의 마케팅 명칭을 붙인 게 ActiveX 컨트롤이다. 아마 마소 역사를 통틀어 길이 남을 엽기적인 작명이 아닐까? 하긴, DirectX도 비슷한 시기의 작명이니까 말이다. ㅡ,.ㅡ;;

하지만 웹에서 가상 머신이 아니라 특정 플랫폼의 네이티브 코드를 직접 구동하는 건 너무 무식하고 이식성도 떨어지고 표준 친화적이지 못하니 ActiveX는 마소에서도 버림받고 늦어도 2010년대부터는 완전히 퇴출 단계에 들어섰다.
지금은 Java applet도 완전히 멸망했고, 이들의 대체제는 정말 눈부시게 성능이 향상된 JavaScript 가상 머신이라고 보면 될 것이다.

5. OLE와 관련된 과거 유행: embed된 형태로 실행

저렇게 마소에서 COM/OLE니 ActiveX를 막 밀고 양성하던 1990년대 말~2000년대 초에는 어떤 프로그램이 다른 프로그램의 내부에 embed된 형태로 실행된 모습을 지금보다 훨씬 더 자주 볼 수 있었던 것 같다. 그와 관련해서 ActiveDocument (!!)라는 기술도 있긴 했다.

당장, MS Office 97에 있었던 Binder라는 유틸은 여러 Word, Excel 따위의 문서를 한데 묶어서 자기 안에서 해당 프로그램을 띄워서 내용을 편집하는 유틸이었다. 대단한 기술이 동원됐을 것 같지만 그래도 쓸모는 별로 없었는지 후대에는 짤리고 없어졌다.

Visual C++ 6의 IDE는 “새 파일” 대화상자를 보면 통상적인 텍스트 파일이나 프로젝트/Workspace뿐만 아니라 맨 끝에 Other documents라는 탭도 있어서 MS Office 문서를 자기 IDE 안에서 열어서 편집할 수 있었다. 당연히 MS Office가 설치돼 있는 경우에만 한해서.. 아까 그 Binder처럼 말이다.
그런데 이 역시 현실에서는.. 그냥 Word/Excel을 따로 띄우고 말지 굳이 워드/엑셀 문서를 왜 Visual C++ IDE에서 편집하겠는가? 그 기능은 후대엔 없어졌다.

ActiveX 기술의 본가인 IE 브라우저야 더 말할 것도 없다.
저런 MS Office 문서를 다운로드 해서 열면 해당 앱이 따로 열리는 게 아니라, 문서 보기/편집창이 웹페이지 화면에 떴었다. 별도의 프로세스로 말이다. 그 기술이 최초로 도입된 건 IE4가 아니라 1996년의 IE3부터였다.
파워포인트 슬라이드는 그 웹페이지 화면에서 곧장 슬라이드 쇼가 시작됐다. 이건 괜찮은 기능인 것 같다.

옛날에 pdf를 보기 위해서 Acrobat Reader를 쓰던 시절엔, 이 앱도 OLE 기술을 이용해서 IE 내부에 embed된 상태로 뜨는 걸 지원했었다. 지금이야 브라우저가 자체적으로 PDF를 표시해 주는 시대이지만 말이다.;;

요즘 컴터 다루면서 OLE 개체 삽입 기능을 쓸 일이 과연 얼마나 될까?
요즘은 개체 삽입으로 프로그램을 실행했을 때, 예전처럼 프로그램이 embed 형태로 실행되는 게 아니라 그냥 별도의 창으로 따로 뜨는 편인 것 같다. 앞서 소개했던 XP 시절의 모습과는 좀 다르다.
따로 실행됐을 때는 원래 문서에 표시된 컨텐츠와 자기가 다루는 컨텐츠가 따로 노니, 전자는 검은 빗금을 쳐셔 구분해야 한다는 UI 가이드라인도 있긴 하다.

이런 것들이 다 20여 년 전의 아련한 추억이고 한물 간 유행이다.
그나저나 인터넷으로 ppt 슬라이드를 받으면 바로 열리지 않아서 불편하다. 속성을 꺼내서 ‘신뢰할 수 없는 파일 차단’을 해제해야 볼 수 있다. 이것도 chm 도움말 파일을 바로 열리지 않는 것처럼 보안 강화를 위해서 취해진 조치인지 모르겠다.

Posted by 사무엘

Windows는 태생적으로 ‘유니코드 = 2바이트 단위 인코딩’이라는 걸 전제에 깔고 만들어졌다.
거기에다 유니코드라는 게 없던 쌍팔년도 도스 시절과의 호환성을 너무 중요시해서 그런지, 2바이트가 아닌 1바이트 단위 인코딩 쪽은 일명 ANSI라 불리는 국가별 지역구 문자 코드에 오랫동안 얽매여 있었다. (cp949 따위)

그래서 이쪽 진영은 ‘유니코드의 1바이트 단위 인코딩’에 속하는 UTF-8의 지원이 맥이나 리눅스 같은 타 운영체제에 비해 굉장히 미흡한 편이었다.
가령, 파일의 경우 앞에 BOM을 꼭 넣어야만 ANSI가 아닌 UTF-8이라고 인식했는데.. 그러면 이건 말짱 도루묵이어서 지원하지 않는 것과 별 차이 없었다.

이러니 한 git 저장소에다가 넣고 여러 플랫폼에서 공통으로 사용하는 소스 파일의 경우, 영문이 아닌 한글로 주석은 무서워서 넣지도 못할 지경이었다.
Windows만 ANSI cp949를 선호하니 이건 타 운영체제의 IDE에서는 인코딩을 번거롭게 수동 지정하지 않는 한, 제대로 인식을 못 했다. 거기서 다시 저장을 하면 한글 내용은 당연히 다 날아갔다.

Windows에서도 UTF-8로 인식시키려면 파일 앞에다 BOM을 집어넣어야 하는데, 이러면 Windows 말고 타 컴파일러에서는 이게 배탈을 일으켰다.
정말 거지 같은 상황이었다. Windows는 1993년 NT 첫 버전부터 나름 유니코드를 염두에 두고 설계된 물건임에도 불구하고, 이런 분야에서는 전혀 유니코드에 친화적이라는 티가 느껴지지 않았다.

무려 2010년대 중후반이 돼서야 Visual C++ 2017인가 2019쯤에서야 드디어 BOM이 있건 없건 소스 파일의 인코딩을 다 UTF-8로 인식시키는 옵션이 추가됐다. 아마 202x 버전쯤에서는 이게 디폴트 옵션이 돼야 할 것이다.
그리고 언제부턴가 메모장이 편집하는 파일의 기본 저장 인코딩이 ANSI 대신 UTF-8로 바뀌었다.

응용 프로그램뿐만 아니라 Windows 자체도 10의 후대 패치를 통해 일단 명령 프롬프트의 인코딩에 UTF-8 지정이 가능해졌다. CHCP 65001 말이다.
단, 이런 명령 말고 프로그램 상으로 UTF-8 기반의 명령 프롬프트 환경을 어떻게 생성하는지는 잘 모르겠다. 검색해 보면 있겠지.. 배치 파일과 명령 argument를 몽땅 다 유니코드로 줄 수 있어야 진정한 유니코드화일 텐데 말이다.

다음으로 2019년쯤엔가 굉장히 큰 변화가 생겼는데..
유니코드를 지원하지 않는 구닥다리요 과거 Windows 9x의 잔재로나 여겨지던 각종 ...A 함수 말이다.
A 함수도 ANSI가 아닌 UTF-8 인코딩으로 문자열을 취급함으로써 유니코드를 지원하게 하는 통로가 뚫렸다.
그래.. 내가 원하던 게 이거였다. 진작에 좀 지원해 줄 것이지..!!

물론 Windows가 내부적으로는 문자열을 몽땅 UTF-16 방식으로 처리하고 있고, 2000년대부터는 ..A 함수 같은 건 만들지도 않는다. 그러니 ..A 함수의 유니코드화가 막 획기적으로 대단한 일은 아닐 것이다.
그러나 이렇게 해 주면 1바이트 단위로 문자열을 취급하는 각종 오픈소스 라이브러리에 대해서 골치 아프게 문자열을 변환하고 W 함수를 호출하는 thunk를 만들지 않아도 유니코드 파일명에 접근할 수 있어서 기존 코드의 포팅이 굉장히 수월해진다.

이 ANSI 코드 페이지라는 개념은 원래 시스템 global한 설정이며, 변경한 뒤에는 재부팅이 필요할 정도로 보수적인 속성이었다.
그런데 이걸 응용 프로그램마다 샌드박스를 씌워서 다른 값으로 가상화할 수 있고 심지어 UTF-8로 지정 가능해진 것은 고해상도 DPI 설정과 양상이 굉장히 비슷하다. 이것도 시스템 global이다가 응용 프로그램 단위로, 심지어 모니터 단위로 세부 지정과 변경이 가능해졌기 때문이다.

응용 프로그램의 매니페스트 정보를 통해 지정한다는 점마저도 동일하다. application → windowsSettings에 있다~!

<activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>

20여 년 전에는 마소에서 unicows라고, 응용 프로그램이 Windows 9x에서 ...W 함수를 호출하면 문자열들을 변환해서 A 함수로 재호출해 주는 호환 layer를 개발· 배포한 적이 있었다. 한 프로그램이 2000/XP에서는 유니코드를 지원하고, 9x에서는 유니코드를 지원하지 않아도 기본적인 실행만은 되라고 말이다.
이제는 A 함수로도 UTF8 인코딩을 통해 유니코드에 접근하는 통로가 생겼다니, 참 오래 살고 볼 일이다.

또한, 이렇게 세월이 흐르면 Windows에서도 2바이트 완성형 CP949는 2바이트 조합형만큼이나 점점 보기 힘들어지고 역사 속으로 사라지지 싶다. 마치 플래시나 IE6, 보안이 안 좋은 http가 퇴출되듯이 말이다.
Windows가 일찍부터 유니코드를 지원했다고는 하지만 실질적으로 재래식 1바이트 인코딩의 퇴출을 가능하게 한 것은 UTF-8의 도입이라고 봐야 할 것이다.

한편, 웹이야 살아 있는 프로그램이 아니라 문서이니.. EUC-KR이니 CP949이 더 오래 남아 있을 것이다. 그러고 보니 내 홈페이지부터가 블로그 말고 HTML 페이지는 다 구닥다리 ANSI 인코딩을 쓰고 있구나. =_=

※ 여담: 2바이트 인코딩의 문자 집합 크기

우리나라의 KS X 1001 완성형 2바이트 한글 코드는 ISO/IEC 2022라는 옛날 규격에 맞춰서 94*94 = 8836 크기의 격자 안에 완성형 한글 2350자와 상용 한자 4888자, 그리고 나머지 1000여 자에 달하는 특수문자를 배당해 놓았다.

그 뒤 CP949, 일명 마소 확장완성형은 현대 한글 11172자에서 2350자를 제외한 나머지 한글 8822자를 KS X 1001이 사용하지 않는 2바이트 문자 조합에다가 억지로 집어넣었다.
KS X 1001이 lead byte와 tail byte 공히 0xA1부터 0xFE까지만을 사용하는 반면, CP949는 영역이 더 넓다. 특히 tail byte로는 알파벳 A~Z, a~z까지 사용한다.

그런데 이 ISO/IEC 2022 격자 크기 8836과, 비완성형 한글 수 8822는 값이 놀라울정도로 비슷하다. 우연인지, 의도된 결과인지 모르겠다.;;
한글 글자 수 11172와, 16*16픽셀 8*4*4벌 도깨비 한글 폰트의 크기 11520도 꽤 비슷하게 느껴진다. 이건 진짜로 의미가 서로 전혀 무관하기는 하다만 말이다.

Posted by 사무엘