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

2011/04/08 17:29 2011/04/08 17:29
, ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/493

Trackback URL : http://moogi.new21.org/tc/trackback/493

Comments List

  1. 김기윤 2011/04/09 08:22 # M/D Reply Permalink

    1. 말씀드린 적이 있는 것 같지만, 제가 접한 Visual Studio의 버전 순서는 6.0 -> 2008 -> 2010 -> 2005 입니다. 다시 말하면 2003은, 실습실에서나 어쩌다가 한번 희귀하게 구경하는게 아니면 접한 적이 전혀 없다는 말입니다. ...그러고보니 2005를 한번 쓰고나서, 다시는 쓸 일이 없어 지워볼까? 했다가 복잡하게 꼬여있는 프로그램 설치 방식 때문에 제거를 포기했습니다 (..)

    2. 저런 식으로 완벽하게 가상화를 지원하기 때문에 64bit 운영체제에서도 대부분의 32bit 프로그램들을 문제없이 돌릴 수 있는 것이군요.. 덕분에라고 할지, 아직까지도 새로 나오는 소프트웨어는 별 이유가 없으면 계속해서 32bit 로 나오더군요. 다만 램을 아주 많이 사용하는 일부 소프트웨어는 벌써 32bit 와 64bit 를 모두 지원하더군요..!

    1. 사무엘 2011/04/09 18:45 # M/D Permalink

      1. 저는 오히려 2005가 2005의 모든 특징과 장점을 완전히 포함하고 있는 2008이 있기 때문에 따로 남겨 둘 필요가 없다고 생각합니다. 특히 비스타/7 OS에서는 2005 쓰는 건 바보짓이죠. =_=
      2003은 과도기적인 변화가 있던 버전이어서 나름 고유한 의미가 있거든요.

      2. 사실, 64비트 환경에서도 과거 API들의 프로토콜상의 한계 때문에 4GB 이상의 메모리를 자유자재로 다룰 수 있는 분야는 매우 제한적이지 않겠나 싶습니다. 32비트에서 64비트로의 변화는 굉장히 더디게 진행 중이죠. 물론, 그렇다고 해서 4GB 이내의 환경에서도 64비트의 성능상의 장점은 충분합니다만.

  2. 비밀방문자 2011/04/10 06:38 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2011/04/10 23:53 # M/D Permalink

      제 프로그램은 운영체제의 일반적인 글꼴 체계를 사용하지 않기 때문에, 그렇게 할 수는 없습니다.;;;

  3. 주의사신 2011/04/10 16:40 # M/D Reply Permalink

    1. 2005와 2008이 완전히 포함관계는 아닌 것이, 2005에는 있는 Visual J#이 2008에 오면서 사라졌기 때문입니다. 그런데 J# 쓰는 사람이 있었을지 궁금하네요. 그 외에는 다 2008로 이전되었다고 해도 큰 오류는 없다고 해도 될 것입니다.

    2. Visual Studio는 반드시 버전순으로 깔아야 합니다. 6.0 -> 2003 -> 2005 -> 2008 -> 2010. 서비스팩 역시 순서대로 올려야 한다고 합니다. 안 그러면 기묘한 오류가 난다고 합니다.

    3. Visual Studio 2010을 알파인가 베타1인가를 깔아서 잠시 써 봤던 기억이 나네요. 뭔 IDE가 메모리를 300메가 씩이나 먹어 하는 생각을 했더랍니다. 최적화가 덜 되어 있었죠. 지금은 대략 틀었을 때 70~80 정도입니다.

    4. Visual Studio 2003은 버그가 너무 많아 MS도 포기한 버전이라는 전설을 들은 기억이 있는데, 반드시 그런 것은 아닌가 봅니다.

    1. 김기윤 2011/04/10 17:44 # M/D Permalink

      제 PC에는 6.0 -> 2008 -> 2010 -> 2008 SP -> 2005 순서로 깔려 있습니다. 말씀대로 기묘한 오류가 몇몇 나서 골치아픕니다 orz

    2. 사무엘 2011/04/10 23:54 # M/D Permalink

      1. J#은 가히 듣보잡 언어;;

      2. 헐, 버전 순으로 깔아야 한다니 그건 또 무슨 조화인지 모르겠습니다. ^^;;
      저는 2003과 2008만 깔아 놓고 있음.

      4. 2003보다는 최초의 닷넷 버전인 2002가 가히 버그투성이었지요.
      2003이 불안정하다는 말이 많이 들리긴 했습니다만, 2003으로 <날개셋> 한글 입력기를 버전 2.5부터 5.3x까지 6년간이나 개발해 온 저의 입장에서는 뭐 그럭저럭 쓸 만했던 것 같습니다.
      단, 리소스 편집기 다루다가 이따금씩 뻗는 버그는 확실히 있었더랬죠.

Leave a comment
« Previous : 1 : ... 1240 : 1241 : 1242 : 1243 : 1244 : 1245 : 1246 : 1247 : 1248 : ... 1670 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/09   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

Site Stats

Total hits:
1443078
Today:
408
Yesterday:
482