※ 비주얼 스튜디오 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 사무엘
