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

예전에 했던 말도 있지만.. 암튼 지난 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.0부터 9x/ME까지
가난하지만 파이가 가장 큰 16비트 도스 진영을 특별히 공략한 전용 제품이다. 그러니 x86 전용. 가난한 컴에서 리소스를 최대한 짜내야 했던 관계로 코드는 쑤제 어셈블리어가 가득했으며, 어차피 이식성도 없었다.

※ NT 3~4
9x 같은 현실 절충이 아니라, 이상과 이식성을 추구한 컨셉을 살려 x86뿐만 아니라 Alpha, MIPS를 지원했다. 특히 NT 4의 경우 PowerPC까지 지원하여 지원하는 아키텍처가 가장 많았다. 실행 파일 포맷의 이름을 괜히 Portable Executable이라고 지은 게 아니었다.
Alpha의 경우 64비트 아키텍처이긴 했지만, Windows 자체는 여전히 32비트로만 동작했다. 물론 그때는 메모리 용량상으로 64비트는 어차피 전혀 의미가 없었으며, 단지 같은 클럭으로 32비트보다 대용량 데이터를 더 빠르게 처리한다는 점에서만 의의를 둘 수 있었을 것이다.

참고로 OS/2는 Windows NT에 준하는 귀족 된장(?) OS임에도 불구하고 이식성이 없이 x86 전용이었다. 이식성 있는 코드 위주로 개발되지 않았기 때문이다.

※ 2000
NT 계열이지만, 이제 한물 가고 망했다고 간주되는 아키텍처들에 대한 지원을 대거 끊어서 사실상 x86 전용이 됐다. 인텔에서 발표 예정인 IA64 Itanium 아키텍처와 연계하여 최초의 레알 64비트 OS로 거듭나려 했지만 CPU의 출시가 늦어지는 바람에 제대로 성사되지 않았다.

※ XP
이제야 x86 (32비트)과 Itanium (64비트) 에디션이 동시에 발매되었다. 하지만 Itanium는 알고 보니 정말 대차게 망한 관계로, 얘를 정식으로 지원하는 Windows는 XP가 처음이자 마지막이 됐다. -_-;;
그 대신 x86과 잘 호환되는 x64 내지 x86-64라는 새로운 아키텍처가 64비트 PC의 대세가 되었다. PC도 이제 메모리가 슬슬 4GB 방벽에 걸릴 타이밍이 되기도 했고.

그래서 2005년, 이미 SP2까지 출시되고 나서야 Windows XP는 x64용 에디션이 나왔다. 허나 정말 존재감 없이 지나가 버렸으며, XP는 대외적으로 여전히 싱글 코어 + 32비트 OS의 상징이라는 이미지가 압도적으로 더 강하다.

※ Vista와 7
Itanium은 칼같이 짤렸고 그 대신 x86 (32비트)과 x64 (64비트) 패턴이 나란히 정착했다. 7부터는 서버 에디션은 이제 32비트가 없이 64비트 에디션만 나오고 있다.

※ 8과 그 이후
저기에다가 모바일용 CPU인 ARM 에디션이 새롭게 추가됐다만, 이 에디션은 키보드 달린 일반 컴퓨터에서 볼 일은 딱히 없을 것 같다. 이 구도가 당분간 계속 이어질 듯.

이렇듯, Windows는 운영체제의 버전이 바뀌면서 지원 플랫폼도 은근히 자주 바뀌어 왔다. 이 외에도 운영체제 별 문자 입력 시스템의 변천사라든가 다국어 글꼴 시스템의 변천사를 다뤄도 무척 재미있을 것 같다.

다국어 하니까 짚고 넘어갈 사항으로는..
Windows NT는 3.51부터 한글화되어 나왔다. 그러나 한글판이 나온 건 1996년, 이미 95도 나오고 NT 4.0이 나오기 몇 달 전이었던지라 3.51의 한글판은 별로 주목받지 못했다. 그러니 NT 3.51이 윈도 3.x의 셸 기반이었다고 해서 NT 3.51의 한글판이 한글 윈도 3.x의 투박한 비트맵 바탕체를 썼다거나 하지는 않았다.

Windows 자체가 한글판이 나온 건 무려 2.1때부터라고 한다. 하지만 1980년대 말에 우리나라 IT 인프라에서 뭘 그리 바랄 게 있겠는가..? 이 역시 3.0이 나오기 얼마 전일 정도로 시기가 매우 늦기도 해서 존재감은 거의 부각되지 않고 싹 묻혔다. 저 광고 말고는 스크린샷이고 기록이고 뭐고 아무것도 없다.

Posted by 사무엘

※ 프로세서 정보 얻기

현재 컴퓨터의 CPU 아키텍처 종류를 얻는 대표적인 함수는 GetSystemInfo이다. SYSTEM_INFO 구조체의 wProcessorArchitecture 멤버의 값을 확인하면 된다.
그런데, 64비트 컴퓨터에서 64비트 운영체제를 실행하고 있더라도 32비트 프로그램은 언제나 이 값이 0, 즉 32비트 x86이 돌아온다. 이는 호환성 차원에서 취해진 조치이다. 기존의 32비트 x86용 프로그램은 새로운 API를 쓰지 않으면 자신이 64비트 x64에서 돌아가고 있다는 걸 까맣게 모르며, 전혀 알 수 없다.

자신이 돌아가고 있는 환경이 진짜 x64인지 확인하려면 GetNativeSystemInfo라는 새로운 함수를 써야 한다. 이건 Windows가 최초로 x64 플랫폼을 지원하기 시작한 윈도우 XP에서 추가되었다. 이 함수가 존재하지 않는 운영체제라면 당연히 64비트 환경이 아니다.

64비트 프로그램이라면 그냥 기존의 GetSystemInfo만 써도 x64를 의미하는 9가 돌아온다. GetNativeSystemInfo는 동일한 코드가 32비트와 64비트로 컴파일되더라도 모두 정확한 동작을 보장한다는 차이가 존재할 뿐이다.

또한, 같은 64비트라도 아이테니엄(IA64) 환경에서는 기존 GetSystemInfo도 32비트 x86 프로그램에서 아키텍처를 x86이라고 속이지 않고 정확하게 IA64라고 알려 준다. 왜냐하면 IA64는 x86과는 명백하게 다른 환경이기 때문에 다르다는 걸 알려 줄 필요가 있기 때문이다. 뭐, 지금은 IA64는 완전히 망했기 때문에 일반인이 접할 일이 없겠지만 말이다.

※ 시스템 메모리 정보 얻기

메모리 양을 얻는 전통적인 함수는 GlobalMemoryStatus이다.
그러나 32비트 프로그램이라도 현재 컴이 64비트 운영체제를 사용하여 램이 4GB보다 많이 있는 걸 제대로 감지해서 표시하려면, 윈도우 2000에서 새로 추가된 GlobalMemoryStatusEx 함수를 써야 한다.

그리고 빌드되는 실행 파일의 헤더에 large address aware 플래그가 켜져 있어야 한다. 비주얼 C++ 기준 Linker → System → Enable Large Addresses를 yes로 지정해 주면 된다. 64비트 플랫폼에서는 이 값이 기본적으로 yes이지만, 32비트 플랫폼에서는 기본값이 no이다.
large address aware이 켜져 있지 않으면 32비트에서는 사용 가능한 가상 메모리가 아예 4GB가 아닌 2GB로 반토막이 난 채 표시된다. 포인터의 최상위 1비트를 비워 준다.

그리고 64비트 바이너리에 대해서는 사용 가능한 가상 메모리의 양이야 언제나 있는 그대로 운영체제가 알려 주지만, 해당 바이너리에 이 플래그가 없으면, 운영체제는 아예 상위 32비트를 비워 줘서 DLL 같은 걸 LoadLibrary해도 언제나 32비트 영역 안에서만 주소를 잡는다. 포인터까지 4바이트짜리 int와 구분 없이 작성된 구식 코드들의 64비트 포팅을 수월하게 해 주기 위한 조치이다.

참고로 64비트 전용 프로그램이라면 Ex 대신 기존의 GlobalMemoryStatus만 써도 괜찮다. 받아들이는 구조체의 크기가 int가 아니라 SIZE_T이기 때문에, 32비트 플랫폼에서는 32비트이지만 64비트 플랫폼에서는 자동으로 64비트가 설정되기 때문이다. Ex 함수는 플랫폼의 비트 수에 관계없이 숫자의 크기가 언제나 64비트 크기를 보장해 줄 뿐이다.

※ 32비트 프로그램이 지금 내가 64비트 운영체제에서 동작하고 있는지 감지하기

딱 그 목적을 위해 IsWow64Process라는 함수가 있다. 이것 역시 윈도우 XP 이상에서 추가되었다.

※ 윈도우 시스템 디렉터리에 접근하기

64비트 운영체제는 잘 알다시피 시스템 디렉터리가 64비트용과 32비트용으로 두 개 존재한다.
32비트와 64비트 프로그램에 관계없이 GetSystemDirectory는 언제나 C:\Windows\system32를 되돌린다.
그리고 윈도우 XP에서 추가된 GetSystemWow64Directory라는 함수가 있어서 역시 32비트와 64비트에 관계없이 C:\Windows\SysWow64를 되돌린다. 다만, 운영체제 자체가 64비트가 아닌 32비트 에디션이라면, 후자의 함수는 에러를 리턴한다.

그러니 의외로 이 함수는 플랫폼에 관계없이 절대적으로 같은 결과를 되돌리는 듯한데, 문제는 64비트 운영체제는 32비트 프로그램에 대해 시스템 디렉터리를 기본적으로 redirection한다는 것이다. 즉, 64비트 운영체제는 32비트 프로그램이 C:\Windows\System32를 요청한다고 해도 SysWow64의 내용을 보여주지 진짜 64비트용 시스템 디렉터리의 내용을 보여주지 않는다.

만약 32비트 기반으로 응용 프로그램 설치 관리자나 파일 유틸리티 같은 걸 만들 생각이어서 진짜로 64비트 시스템 디렉터리에 접근을 하고 싶다면, 운영체제에다 별도의 함수를 호출해서 요청을 해야 한다. 그래서 처음에는 Wow64EnableWow64FsRedirection라는 함수가 추가되었다. 이걸로 잠시 예외 요청을 한 뒤, 내가 할 일이 끝난 뒤엔 다시 설정을 원상복귀해야 했다. 왜냐하면 64비트 시스템 디렉터리에 접근 가능하게 해 놓은 예외 동작을 그대로 방치하면, 나중에 다른 32비트 모듈들이 32비트 시스템 디렉터리에 접근하지 못하게 되기 때문이다.

그런데 MS에서는 함수 디자인을 저렇게 한 것을 후회하고, 위의 함수의 기능을 Wow64DisableWow64FsRedirection과 Wow64RevertWow64FsRedirection 쌍으로 대체한다고 밝혔다. MSDN을 읽어 보면 알겠지만, 64비트 접근 여부 설정치를 마치 stack처럼 다단계로 저장했다가 다시 원상복귀를 더 쉽게 할 수 있게 만들려는 의도이다.

※ Program Files 디렉터리에 접근하기

64비트 운영체제는 응용 프로그램 디렉터리도 64비트용과 32비트용이 두 개 존재한다.
운영체제가 사용하는 특수 디렉터리의 위치를 얻어 오는 함수의 원조는 SHGetSpecialFolderPath이며, 이것은 윈도우 운영체제의 셸의 구조가 크게 바뀌었던 인터넷 익스플로러 4 시절에 처음 도입되었다. 그때는 특수 디렉터리들을 CSIDL이라는 그냥 정수 ID로 식별했다.

그랬는데 윈도우 비스타부터는 이 함수의 역할을 대체하는 SHGetKnownFolderPath라는 함수가 추가되었고, 이제는 식별자가 아예 128비트짜리 GUID로 바뀌었다. 문자열 버퍼도 구닥다리 260자짜리 고정 배열 포인터를 받는 게 아니라, 깔끔하게 별도의 동적 할당 형태가 되었다.

64비트 운영체제에서 64비트 프로그램은 64비트와 32비트용 Program Files 위치를 아주 쉽게 얻어 올 수 있다. 32비트를 가리키는 식별자가 따로 할당되어 있기 때문이다. 그러나 32비트 프로그램이 64비트 운영체제의 64비트 위치를 얻는 것은 위의 두 함수로 가능하지 않다. SpecialFolder 함수는 64비트만을 가리키는 식별자 자체가 없으며, KnownFolder함수도 32비트 프로그램에서 FOLDERID_ProgramFilesX64 같은 64비트 식별자를 사용할 경우 에러만 돌아오기 때문이다.

32비트 프로그램이 64비트 Program Files 위치를 얻는 거의 유일한 공식적인 통로는 의외의 곳에 있다. 바로 환경변수이다.

::ExpandEnvironmentStrings(_T("%ProgramW6432%\\"), wt, 256);

위의 환경변수를 사용한 코드는 32비트와 64비트에서 동일하게 64비트용 Program Files 위치를 되돌려 준다.

결론

이렇듯 32비트에서 64비트로 넘어가면서 윈도우 API의 복잡도와 무질서도는 한층 더 높아졌음을 우리는 알 수 있다. 가능한 한 급격한 변화와 단절을 야기하지 않으면서 새로운 기능을 조심스럽게 추가하려다 보니 지저분해지는 건 어쩔 수 없는 귀결이다.

프로그램 배포 패키지를 32비트 exe 하나만 만들어서 64비트와 32비트 플랫폼에서 모두 쓸 수 있게 하면 좋을 것 같다. 32비트 플랫폼에서는 32비트 바이너리만 설치되고, 64비트 플랫폼에서는 비록 32비트 EXE라도 64비트 프로그램 디렉터리들을 모두 건드릴 수 있어야 한다. 그런 프로그램을 만들려면 이 글에서 언급된 테크닉들을 모두 알아야 할 것이다. 설치 프로그램이니 UAC 관리자 권한이 필요하다는 manifest flag도 내부적으로 넣어 주고 말이다.

아, 그러고 보니, 윈도우 9x 시절에는 시스템 디렉터리가 16비트와 32비트로 나뉘어 있지도 않았다. NT 계열로 와서야 system과 구분하기 위해서 system32가 별도로 생기긴 했지만, 16비트용 시스템 디렉터리의 위치를 얻는 별도의 API는 존재하지 않았으며, 사실 필요하지도 않았다. 16비트 프로세스는 이제 NTVDM 밑에서 돌아가는 완전 고립된 별세계로 전락했기 때문이다.

Posted by 사무엘

※ 비주얼 스튜디오 2003

지금은 바야흐로 2011년. 비주얼 C++ 2010이 나온 지 이미 1년이 지났고 C++0x 규격까지 등장한 마당에, 그 옛날 버전인 비주얼 C++ 닷넷 2003 관련 블로그 포스트를 아직도 적지 않게 찾을 수 있어서 본인은 놀랐고 한편으로 동질감을 느꼈다.
본인도 <날개셋> 타자연습을 비롯해 여러 legacy 프로젝트들을 여전히 VS 2003으로 관리하고 있다.

특히 2005와 그 후대 버전들은 MFC 라이브러리가 너무 심하게 bloat되어서 본인은 업그레이드할 의욕을 대략 상실했다.
static link를 할 엄두를 못 내겠는데, dynamic link 정책도 영 괴상한 방식으로 바뀌니..
MFC 라이브러리보다도 덩치 더 큰 포토샵, MS 오피스급의 초대형 상업용 프로그램을 개발할 때라면 모를까, 이건 소규모 프로그램 개인 개발자에겐 영 아니라는 생각이 든다.

그래도 듣자하니 2010은 msvcr100과 mfc100을 굳이 winsxs 매니페스트 방식을 안 쓰더라도 자기 local 디렉터리에서 로딩 가능하게 바뀌었다고 하던데, 그건 그나마 다행인 점이다. 전세계에서 터져 나온 개발자들의 불만을 비주얼 C++ 팀이 받아들인 모양이다. Class wizard도 부활하는 등, 2010이 꽤 참신한 변화를 많이 했다. 2005->2008은 연도 차이가 3임에도 불구하고, 2일 뿐인 2008->2010보다 변화량이 훨씬 더 적었다.

잡설이 길었는데..
운영체제인 윈도우 비스타는 시스템 계층에서 바뀐 게 많다 보니, 예전의 2000/XP와는 달리 비주얼 스튜디오, 혹은 비주얼 C++에게 그리 자비롭지 않았다. 비스타뿐만이 아니라 7도 마찬가지.

구닥다리 6.0은 그런 최신 OS에서 동작 자체는 한다만, 설치하는 과정에서 무슨 문제가 있을 수 있다고 하고(OLEView 같은 일부 컴포넌트),
2003은 비스타에서 대놓고 좀 잡다한 문제를 일으킨다. 하지만 MS는 VS 2003 지원은 2006년 중반의 SP1을 끝으로 이제 완전히 끊었다. 비스타 이후부터는 버려진 자식. -_-;;

그 잡다한 문제 중 유명한 게 뭐냐 하면, Find in files 기능.
윈도우 비스타/7에서 VS 2003으로 이 명령을 내리고 있으면 IDE가 응답 없이 그대로 멎어 버렸다. 파일 검색 기능을 쓸 수 없다는 소리. 그런데 이건 개발자가 밥먹듯이 써야 하는 기능인데, 이거 없으면 불편해서 프로그램 개발 어떻게 하라고? -_-;;;

이 문제를 해결하는 방법은 의외로 간단하다.
탐색기로 DEVENV.EXE를 찾아가서 Alt+Enter로 속성을 꺼낸 후, 호환성 탭에서 시각 테마를 꺼 버리면 된다. 이 팁을 올린 각종 블로그 포스트에는 한국어와 영어를 불문하고 "너무 좋은 정보군요.", "알려 주셔서 대단히 고맙습니다", "퍼 갑니다" 댓글들이 즐비하다. 아직도 VS 2003 쓰는 개발자가 많다는 뜻 되겠다. X86 아키텍처와 PE 방식 실행 파일이 존재하는 한, C++, Win32 API, 네이티브 코드 자체가 근본적으로 유행을 그렇게 타는 분야가 아니니 말이다.

비주얼 C++ 2003은 MS 오피스 XP와 동일한 GUI 기반이며, 어차피 comctl32 6.0 기반의 시각 테마를 쓰지도 않는 프로그램이다. 그러니 프로그램 외형이 딱히 달라지지도 않는다.
단, 그 비주얼 C++로 실행한(디버거를 붙인 F5든, 붙이지 않은 Ctrl+F5든) 나의 프로그램도 시각 테마가 무시된 채 실행되므로 그건 주의해야겠다. 물론, 탐색기 같은 걸로 따로 실행하면 문제 없음.

덧붙이자면 VS 2003은 도킹 윈도우 같은 걸 드래그하여 이동할 때 점선으로 윤곽이 나타나는데, 이 역시 알다시피 Aero 하에서는 동작이 굉장히 굼뜬다.
이것이 VS 2005부터는 개선되어 파란 도킹 다이아몬드도 생기고 비주얼이 산뜻해졌으나, 어차피 2005조차도 비스타에서 제대로 돌아가지 않긴 마찬가지이다.

SP1에다가 비스타 패치까지 다 복잡하게 설치해야 한다. 문제는 SP1과 비스타 패치 각각이 VS 2005를 처음 설치하는 것만치 시간이 욕 나오도록 오래 걸린다는 것. ㅆㅂ
윈도우 비스타보다 늦게 나온 2008부터가 드디어 비스타에서 별 트러블 없이 잘 돌아가며, 내장하고 있는 플랫폼 SDK도 윈도우 비스타 기준 최신이다.

※ 32비트 프로그램이 64비트 프로그램 디렉터리에 접근하기

잘 알다시피 64비트 윈도우에서도 시스템 디렉터리의 경로는 32비트와 마찬가지로 windows\system32이다. 64가 아니다.
그럼 64비트 윈도우 내부에서 32비트 시스템 파일들이 들어가는 경로는 windows\SysWOW64이다.

그런데 본인은 며칠 전 굉장히 놀랐다.
GetSystemDirectory를 호출하는 코드를 32비트로 빌드하나, 64비트로 빌드하나, 실행 결과는 windows\system32로 동일했기 때문이다. 왜 그럴까?

이는 일종의 가상화 내지 redirection 메카니즘 때문이다.
64비트 윈도우에서 동작하는 32비트 프로그램은 애초에 64비트 윈도우 시스템 디렉터리로 접근을 아예 할 수 없다. system32와 syswow64가 모두 보이긴 하지만, system32 디렉터리를 들여다보면 운영체제가 보내 주는 것은 어차피 syswow64의 정보뿐이다. 그 안에서만 놀아야 한다.

Program Files 디렉터리는 그렇지 않아서 32비트 프로그램이 32비트용 경로와 64비트 경로로 모두 따로 접근이 가능하다. 하지만 어차피 known path를 운영체제 차원에서 얻는 방법이 없다. 64비트 프로그램은 64비트용 경로와 32비트용 경로에 모두 접근 가능하지만 32비트 프로그램은 64비트용 경로를 얻을 수 없다.

이렇게 가상화를 너무 잘 해 주기 때문에, 심지어 64비트 OS에서도 32비트 프로그램은 GetSystemInfo 함수를 호출하더라도 멀쩡한 64비트 x64 컴퓨터를 32비트 x86으로만 인식한다. 이 OS가 진짜 64비트인지 32비트 프로그램도 알려면, GetNativeSystemInfo라는 새로운 함수를 써야 한다.

32비트 윈도우에서 <날개셋> 한글 입력기 64비트 에디션은 당연히 설치가 되지 않지만, 64비트 윈도우에서 32비트 에디션은 설치가 가능하다. 이 경우, 편집기나 변환기 같은 프로그램이야 별 차이 없이 쓰겠지만, 외부 모듈이나 입력 패드는 당연히 64비트 프로그램에서 제대로 쓸 수 없다.

그래서, 64비트 윈도우에서 <날개셋> 32비트 에디션이 설치되었을 때, "에디션을 잘못 고르신 것 같은데, 가능하면 64비트 쓰시져?" 하는 경고 메시지를 띄워 주고 싶다. 그런데, 32비트 프로그램이 자기 주변이 64비트인지 파악하기가 의외로 쉽지 않아서 고민이다. 운영체제가 64비트인 경우, 자신이 64비트 모듈과 병행 설치도 되어 있는지 체크를 해야 하는데 파일 시스템이 워낙 저렇게 샌드박스화해 있으니 말이다. =_=;;

※ TlsGetValue와 에러 코드

파일을 읽어서 주어진 일을 처리하는 함수를 만들었다. 이 함수는 파일을 찾지 못하면 false를 즉시 리턴하며, 그 후 이 함수가 호출한 CreateFile 함수가 남긴 GetLastError 값을 바탕으로, 응용 프로그램은 에러 메시지를 찍는다는 게 본인의 계획이었다.

그런데 이 함수가 선언한 각종 객체의 소멸자 함수가 뭔가 처리를 하면서, 또 GetLastError 값을 바꿔 버리기 때문에 정작 파일 조작이 실패한 이유를 밖에서 알 수가 없게 되는 경우가 있었다.
도대체 어디서 에러 코드가 바뀌지? MSDN을 뒤져보다 본인은 깜짝 놀랄 수밖에 없었다.

일반적으로 윈도우 API 함수들은 동작이 실패했을 때만 에러 코드를 설정한다. 그러나 TLS 값을 되돌리는 TlsGetValue 함수는 성공일 때도 에러 코드를 에러 없음을 의미하는 0으로 설정함으로써, 예전 함수의 에러 코드를 덮어써 버린다. 왜냐하면 리턴값 0만으로는 진짜 TLS 슬롯 값이 0인지, 아니면 실패를 의미하는 0인지 알 수 없기 때문이다.

TlsGetValue 함수는 C/C++에 언어적으로 존재하지 않는 새로운 scope를 만드는 것이나 마찬가지인 함수이기 때문에 밥먹듯이 자주 호출된다. 성능이 매우 중요함에도 불구하고 이 함수는 예외적으로 언제나 에러 코드를 건드리도록 설계되어 있다.

이게 에러 코드인지, 정상적인 리턴값인지 알 수 없는 예로 GetExitCodeThread/Process 함수가 있다.
STILL_ACTIVE라는 값이 리턴되었는데, 이게 해당 스레드나 프로세스가 종료하면서 진짜로 리턴한 값인지, 아니면 그게 아직 종료되지 않은 상태인지.. 알 게 뭐야..;;
개인적으로 함수를 왜 저렇게 설계했는지 모르겠다. 어지간하면 성공/실패 여부를 별도의 인자에다가 따로 되돌리게 하는 게 훨씬 안전할 텐데.

Posted by 사무엘

Posted by 사무엘

printf/scanf가 받는 % 문자는 이식성 면에서 매우 큰 문제를 일으킬 수 있다. 기계 종류와 운영체제/컴파일러(정확하게는 CRT 라이브러리)의 종류에 따라 미묘한 차이가 존재하기 때문이다.

이런 잡음이 제일 없던 꿈 같은 시절은 단연 32비트 시절이다. 포인터와 정수가 전부 4바이트가 됨으로써 %d와 %ld 같은 골치아픈 구분도 없어졌고, 포인터도 far/huge 같은 구분이 없어져서 모든 것이 32비트 단위로 끝이 났기 때문이다. %d, %x, %u 하나만으로 컴퓨터에서 통용되는 거의 모든 정수를 바로 읽고 쓸 수 있던 시절. -_-

* * * * * *
Note 1
  참고로 정수가 아닌 실수는?
16비트 시절에는 터보 C/C++에 무려 10바이트 크기의 실수인 long double이 있었고, 파스칼에는 아예 6바이트짜리 Real이라는 기괴한 실수가 존재했다. CPU의 machine word가 16비트 크기이고, GPU는커녕 부동소숫점 전용 프로세서(FPU)마저 흔치 않아서 이런 연산도 소프트웨어적으로 직접 구현하는 게 당연시되던 시절이었으니까 그런 게 존재 가능했다.
요즘 세상엔 무조건 32비트 float 아니면 64비트 double이지, 저런 건 상상도 못 할 개념일 것이다. 픽셀 크기조차도 옛날에는 트루컬러 24비트이다가 요즘은 컴퓨터가 더 처리하기 편한 형태인 32비트이다.
* * * * * *

하지만 이렇게 32비트 천하통일 시대에 끝이 보이기 시작한 것은, 64비트 컴퓨터가 속속 등장하고 문자열도 일반적인 8비트 크기가 아닌 16비트 단위의 소위 wide string이 공존하게 되고부터이다.

그럼, 이번에도 역시 숫자부터 예를 들어 보겠다.

32비트 윈도우 + 비주얼 C++의 CRT는
32비트 정수를 주고받을 때는 당연히 그대로 %d나 %u를 주면 되고 별도의 크기 지정자가 필요 없다. 하지만 64비트 정수에 대해서는 I64라는 접두사를 넣어서 %I64d처럼 해야 한다.

이 규칙은 64비트에서도 완전히 동일하게 적용되기 때문에 이식이 쉽다.
특히 호환성을 극도로 중요시하는 윈도우는 64비트 기계에서도 int 형을 32비트 4바이트로 책정한 관계로, 64비트에서도 %d가 아닌 %I64d를 해 줘야 32비트 영역을 넘어서는 정수를 읽거나 쓸 수 있다. 64비트 기계이더라도 숫자는 일단 변함없이 32비트가 주류라는 인상을 넣은 것이다.

* * * * * *
Note 2
  윈도우즈 문화권은 왜 이리도 호환성에 목숨을 걸까?
간단하다. 그쪽은 오픈소스 진영과는 근본적으로 분위기가 다르기 때문이다.
모든 것이 투명하게 소스 공개이고, 사용자들이 다 컴퓨터를 능수능란하게 다루는 능동적인 해커들인 세상에서는 뭔가 소프트웨어를 업데이트해도 줘도 못 먹는 사람이 없이 물갈이도 금방 된다. 소프트웨어 계층에 breaking change가 잦더라도 재컴파일 한 번으로 '끗'이며, 그렇게 문제가 되지 않는다.

하지만 여기는 사정이 다르다. 마우스로 느릿느릿 아이콘 클릭밖에 못 하고 악성 코드에 속수무책으로 당하는 컴맹도 많다. 또한 돈 내기 싫어서 구닥다리 OS를 계속 고집하는 사람도 많다. 오로지 MS라는 회사가 모든 내부 사정을 관장하고 고객을 다 떠먹여 줘야 한다. 그러니 무조건 한번 만들어 놓은 것에 대한 유지 관리가 편리한 시스템을 만들어야 하며, 새 제품을 단절 없이 많이 팔려면 하위 호환성이라는 보수적인 가치를 최우선 순위로 두고 목숨 걸 수밖에 없는 것이다.
* * * * * *

단, 딱 하나 문제가 될 수 있는 것은 소위 INT_PTR 타입으로, 32비트 기계에서는 32비트이지만, 64비트에서 실제로 64비트 크기로 확장되는 정수이다. 이게 진짜로 포인터의 크기와 같으며 machine word와 크기가 일치함이 보장되는 정수이다.

이런 정수를 다루는 프로그램의 이식성을 위해서 %Id가(64만 빼고) 별도로 추가되었지만, 이건 반대로 구형 CRT에서는 지원되지 않는 걸로 알고 있다.
그래도 다행인 건, binary format이 아니라 사람이 읽을 수 있는 문자열 형태로 숫자를 읽고 쓰는데 32비트 크기를 넘어서는 범위를 다루는 일은 굉장히 드물다는 것. 차라리 실수를 다루면 다뤘지 정수가 그러는 일은 드문 편이다.

참고로, 가변 인자 함수가 호출될 때, 모든 정수형은 기본적으로 int 형으로 promote가 일어난다. char이든 short이든 다 32비트 내지 64비트 크기로 폭이 증폭된다는 것이다. float는 double로 바뀐다. 그렇기 때문에 float나 double이나 동일하게 %f나 %g로 출력 가능하다. 단지, 값이 아니라 포인터가 전달되는 scanf를 호출할 때는, float에 대해서는 %f를, double에 대해서는 %lf라고 반드시 타입 구분을 엄격히 해 줘야 할 것이다.

64비트 정수를 전달할 때는 32비트 기계에서는 스택에 push가 두 번에 걸쳐 일어나지만, 본디 64비트이던 기계에서는 역시 한 번만에 인자 전달이 끝난다. 그렇기 때문에 %d %d %d 해 놓고 실제로 32, 64, 32비트의 순으로 변수를 전달했다면 32비트 기계에서는 마지막 숫자가 꼬이겠지만(push는 128비트, 하지만 pop은 96비트) 64비트는 둘째 정수가 범위만 32비트 내부에 있다면 세 숫자가 모두 제대로 출력이 된다(push와 pop 모두 64*3비트 동일).
물론 이 경우, 둘째 %d를 %I64d로 해 줘야 32와 64비트 기계에서 모두 잘 동작하는 portable 코드를 만들 수 있다.

윈도우 외의 다른 운영체제는 사정이 어떤가 모르겠다. 64비트 정수를 출력할 때 32비트 기계에서는 %lld, 심지어 64비트에서는 %ld 이렇게 차이가 존재한다고도 하는데.. =_=;;
gcc 자체가 I64와는 다른 관행을 사용하는데 기계마저 64비트로 가고 나면 이거 이식성 면에서 재앙이 발생하지는 않으려나 우려된다.

다음으로 문자열이 있다.
알파벳 이외의 문자는 다룰 일이 없는 서버나 게임 엔진 같은 아주 특수한 프로그램을 개발하는 게 아니라면 이제 유니코드 문자는 대세가 되어 있다. 물론 UTF8도 쓰이고 유닉스 계열 운영체제에서는 심지어 UTF32도 쓰이지만, 그래도 유니코드 문자열을 컴퓨터 메모리 상으로 저장하는 데 비용 대 효율이 가장 뛰어난 방법은 UTF16이다. 특히 윈도우는 NT 시절부터 이렇게 16비트 단위의 wide string을 내부적으로 다뤄 와서 wchar_t = 곧 unsigned short나 다름없을 정도이다.

printf는 ansi 버전과 wide 버전이 존재하며, format으로 지정해 주는 문자열과 %s로 전달하는 문자열의 타입은 대체로 일치한다. ansi 버퍼에다가 wide string을 출력한다거나 그 반대로 해야 하는 경우는 드물다. 하지만 그런 일이 아주 없는 것은 아니다.

이럴 때 윈도우에서는 %hs, %ls라는 지정자를 주어 h는 버퍼 크기와 상관없이 무조건 ansi, l은 버퍼 크기와 상관없이 무조건 wide라고 지정을 할 수 있게 했다. gcc 쪽은 잘 모르겠다.

그래서 함수 오버로딩이 지원되는 C++ 스트림이 짱이라는 말이 있을 정도이니까. 아무 곳에서나 그저 무조건 OK.

Posted by 사무엘