Media Log

마이크로소프트가 OS 업그레이드시 고의로 기존 응용 프로그램들이 동작하지 않도록 만든다는 비난을 받을 때면 나는 정말 화가 난다. 만약 어떤 프로그램이 윈도우 95에서 실행되지 않는다면 나는 이를 개인적인 실패로 받아들였다. 나는 수 많은 밤을 새어가며 윈도우 95에서 응용 프로그램들이 제대로 동작할 수 있도록 써드 파티 프로그램들의 버그까지 디버깅했다.

저작자 표시 비영리 동일 조건 변경 허락
신고

submit

VSColorOutput은 비주얼 스튜디오 2010 플러그인이다.

출력창에 나타나는 문자열들을 분석해서 예쁜 색깔로 구분지어 보여준다. 기본 필터 기능에 더해 사용자가 자신만의 필터를 등록할 수 있도록 정규 표현식을 추가할 수 있는 인터페이스도 갖추고 있다.


예쁘지 아니한가.

Visual Studio 이전 버전들도 모두 훌륭하다고 생각하지만 Visual Studio 2010은 좀 더 특별하다. 이런 좋은 확장 기능들이 많이 있는데다가 무엇보다 C++11을 사용할 수 있기 때문에.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
위대한 해커이자 이제는 소설가(?)이기도한 윈도의 대가 마크 러시노비치의 처녀작이다.
책이 처음 나왔을 때부터 재미는 있으려나, 기술적으로 배울만한 것도 있을까 관심을 가지고 있었는데, 영어로 읽기는 싫으니 번역되는 날만을 기다렸다. 그런데 오늘 드디어 떴구나! 새해 선물인가.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
Writing Solid Code - 10점
Steve Maguire 지음, 나윤석 외 옮김/높이깊이

몇 일전 deview 2011 행사 중 한 세션에서 재미있는 이야기를 들었다.
 NHN 김정민 이사의 세션이었는데, 이런 말을 했다.
애플, 마이크로소프트, HP 같은 회사에서 15년 동안 일했던 (지금은 NHN에서 일하고 있는) 송창현 이사가 예전에 우리회사에 면접을 보러 왔을 때 잘하는 게 뭐냐고 물어봤더니,
"저는 meticulous code reader입니다. 남의 코드를 아주 꼼꼼하게 읽어줄 수 있습니다."
대부분의 경력을 많이 가진 사람들은, 저는 유닉스를 10년을 넘게 다뤄서 커널 구석 구석까지 깊게 알고 있습니다. 오라클 전문가입니다 라고 말하지 저런 식으로 말하지는 않는데, 김정민 이사는 그게 상당히 인상적이고 멋있어 보였다고 한다.

나 또한 그 말이 멋있어 보인다는데에 완전히 동의한다.
저는 자바스크립트만큼은 누구보다 잘할 자신이 있습니다, 라는 말(또는 뻥)보다 훨씬 멋지지 않은가?

직장 생활을 하다보면 Meticulous code reader가 거의 없다는 것을 쉽게 알게 된다. - 나는 이전에 다니던 직장에서 여태껏 그런 사람을 딱 1명 만나봤다.
여러분이 후임이 있다고 치자. 어떤 기능을 구현해달라고 일을 주고 후임이 나중에 다 만들었습니다 했을 때, 또는 만들고 있는 도중에, 코드를 한줄 한줄 다 꼼꼼하게 읽어주고 피드백 해준 적이 있다면, 당신은 좋은 Meticulous code reader가 될 수 있는 가능성이 있다. 거의 대부분의 사람들은 그렇게 하지 않는다.

갑자기 이런 이야기를 하는 이유는, 최근에 Writing Solid Code라는 책을 읽으면서 이 책의 저자인 Steve Maguire가 그런 Meticulous code reader 라는 생각이 들었기 때문이다.
이런 사람들은 회사에 꼭 필요하다. 마이크로소프트가 10년 넘게 황제의 자리를 차지할 수 있었던 이유는 이런 사람들이 많이 있었기 때문일 것이다.

이 책에서는 정교하고 튼튼한 프로그램을 짜기 위한 많은 기술들을 배울 수 있으며, 또한 프로그래머가 프로그램을 만든다는 것 대해서 가져야할 바람직한 자세를 배울 수 있다.
매 챕터가 끝날 때에는 '생각할 점'이 나오는데, 여기에도 좋은 내용들이 참 많다. 부록에 답까지 있으니 모두 꼼꼼하게 읽어보도록 하자.
인터넷 어딘가에서 번역이 최악이라는 평가를 본 것 같은데, 이 책의 번역은 정말 잘 되었다고 생각한다. 부분 부분 약간 어색한 단어 선정이 보였던 것 같긴 하지만, 나는 왜 최악의 번역이라고 하는건지 이해할 수가 없다.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit

_countof 매크로

2011.03.15 06:48 | Programming
_countof 매크로는 배열의 원소 개수를 돌려주는 서비스 매크로이다. 비주얼 스튜디오 2005 부터인가 제공되었던 것 같다.
StringCchCopystrcpy_s, wcscpy_s 같은 함수들을 사용할 때 편리하게 사용할 수 있다.

_countof 매크로는 다음과 같이 생겼다.
#if !defined(_countof)
#if !defined(__cplusplus)
#define _countof(_Array) (sizeof(_Array) / sizeof(_Array[0]))
#else
extern "C++"
{
template <typename T, size_t N>
char (*__countof_helper(UNALIGNED T (&_Array)[N]))[N];
#define _countof(_Array) (sizeof(*__countof_helper(_Array)) + 0)
}
#endif
#endif

C언어를 사용할 때와 C++를 사용할 때의 구현이 다르게 되어있다.
C언어에서 사용되는 방식은 대부분의 사람들이 잘 알고 있는 방식일 것이며, C++에서는 템플릿을 이용해서 배열의 개수를 구하고 있다.

여기서 궁금해해야 할 점은
  1. 템플릿을 통해 어떻게 배열의 원소의 개수를 구할 수 있는가.
  2. 도대체 왜 C와 C++을 전처리기를 사용해서까지 따로 구현했을까. 그냥 C 구현 하나만 쓰지.

1번 질문의 답은 아래 블로그에 잘 설명이 되어있다.
C++ 템플릿으로 배열의 원소 개수를 구하는 방법

2번 질문의 답은 C 구현 방식에 약간의 문제가 있기 때문이다.
배열이 아니라 포인터일 경우에 C 방식은 제대로 개수를 구해주지 못한다.
그럼 템플릿 방식은 제대로 구해주냐 하면 물론 그럴수는 없다. 그래도 컴파일 에러를 내주기 때문에 좀 더 낫다. C 방식은 컴파일이 잘 되어버리며 잘못된 결과를 돌려준다.
아래 코드를 한번 보자. 설명을 쉽게 하기 위해 매크로 이름을 바꿨다.
#define _countof_c(_Array) (sizeof(_Array) / sizeof(_Array[0]))

template <typename T, size_t N>
char (*__countof_helper(T (&_Array)[N]))[N];
#define _countof_cpp(_Array) (sizeof(*__countof_helper(_Array)) + 0)

void c_version(int* p) // int ar[] 과 같은 형식으로 넘어올 때도 마찬가지이다.
{
    printf("%d\n", _countof_c(p));
}

void cpp_version(int* p)
{
    printf("%d\n", _countof_cpp(p));
}

int _tmain(int argc, _TCHAR* argv[])
{
    int a[100];
    printf("%d\n", _countof_c(a)); // 100 올바른 결과
    printf("%d\n", _countof_cpp(a)); // 100 올바른 결과

    c_version(a); // 1 틀린 결과를 내어줘버렸다. 다행히 경고(C6384)는 발생한다.
    cpp_version(a); // cpp_version함수는 컴파일이 안된다.

    return 0;
}

여기서 배워야 할 점은,
  • C 방식 매크로를 쓸 때 언제 문제가 되는지를 알고 있어야 한다.
  • C++를 사용함에도 불구하고 해당 매크로를 C방식으로 직접 만들어서 사용하는 경우를 보았다. 그냥 _countof를 사용한다.
  • 마지막으로, 컴파일러 경고가 발생하면 무시하지 않는다.
또한, 사실 이는 _countof 의 MSDN 페이지에도 잘 나와있는 내용이다. MSDN을 읽을 때는 꼭 개요부터 See Also까지 다 읽는 습관을 들여야 한다. 특히 Remarks 섹션은 유의해야 할 사항들이나 사용자 쪽에서 궁금해 할만한 내부 구현 방식들을 다루어주므로 항상 눈을 부릅뜨고 읽어봐야한다.
저작자 표시 비영리 동일 조건 변경 허락
신고

'Programming' 카테고리의 다른 글

윈도우 드라이버를 만들 때 알아야 할 기초적인 내용들  (2) 2011.05.23
Duff's Device  (0) 2011.04.07
_countof 매크로  (0) 2011.03.15
FIELD_OFFSET 매크로  (1) 2011.03.01
PAGED_CODE 매크로  (5) 2011.02.27
디렉터리의 읽기 전용 속성  (4) 2011.02.20

submit
Windows 시스템 프로그래밍 - 9점
Johnson M.Hart 지음, 류광 옮김/정보문화사

오래전부터 이 책이 좋은 책이라는 이야기를 많이 들었었는데, 여태까지 못보고 있다가 이번에 4판이 번역되어 나온 김에 하나 구입해서 며칠동안 재미있게 읽었다.

저자는 이 책을 리차드 스티븐스의 유명한 고전인 APUE에 대응하는 윈도우 버전이라고 말했지만 책을 읽는 내내 자꾸 비슷한 주제를 다루는 제프리 리처의 Windows via C/C++과 비교가 되는 것은 어쩔수가 없었다.

책 중간의 동기화 오브젝트를 다루는 부분에서는 이 책이 Windows via C/C++보다 훨씬 구체적이고 많은 실례들을 들어 설명을 하고 있으며(제프리보다 재밌게 설명하는 것은 아니지만) 그 이후에 나오는 소켓과 파이프, 윈도우즈 서비스 그리고 오브젝트 보안에 대한 내용들은 Windows via C/C++에서는 다루지 않는 내용이다.
맨 마지막 챕터에서 보안 디스크립터로 ACL을 조작하는 내용은 제프리의 책뿐 아니라 다른 책들에서도 쉽게 다루지 않는 보기 힘든 내용이다. 윈도의 파일들을 리눅스 스타일의 권한(rwx--로 관리되는)처럼 관리할 수 있게 하는 재미있고 실용적인 예제와 함께해서 더 좋았다.

간간히 유닉스 시스템과 비교해서 설명해주는 저자의 코멘트들 또한 이 책의 큰 장점이다.
부록에서는 윈도 API의 유닉스와 CRT 대안 함수들을 표로서 제공해주기도 한다.

제프리리처 책의 모든 챕터를 이제는 2-3번씩 읽어서 윈도우 시스템 프로그래밍에 대해 꽤 많이 알게 되었다고 생각했는데, 이 책을 읽으면서 아직도 많은 부분을 제대로 이해 못하고 있구나 하고 느꼈다. 속상한 일이다.

책에서 옮긴 단어중 신호, 일꾼쓰레드, 스택 위넘침 등은 약간 부자연스럽긴 하지만 내용을 이해하는데는 아무런 문제가 없었다. 하지만 딱 한가지 단어가 나를 힘들게 했는데 그것은 '회부' 라는 단어였다. 가상 메모리를 커밋한다고 할 때 바로 그 커밋을 뜻하는데, 잘 매치가 되지 않아서 머리 속으로 계속 Replace를 했다.

부록에는 여러가지 I/O 방식들에 대한 성능 테스트가 나와 있다.
나는 블로그나 잡지 같은 곳에서 프로그램 성능 테스트를 해봤더니 결과가 어떻더라라고 하면 의심을 하고 잘 믿지 않는 편인데, 그것은 많은 사람들이 페이지 폴트나 캐시 등의 잡음을 고려하지 않고 테스트를 하기 때문이고, 또 그런 것들을 미리 알고 있다 하더라도 완벽히 잡음을 제거하기가 힘들기 때문이다.

책을 읽는 동안 이 책의 저자가 상당히 부지런하고 꼼꼼한 사람이라는 느낌을 받아서 벤치마크 결과에 대해 믿음도 가고 기대를 많이 하고 있었는데, 이 저자 역시 실수를 범해 누군가가 이미 벤치마크의 오류를 지적했었나보다.
아래 페이지에서 저자의 코멘트를 볼 수 있다.
http://jmhartsoftware.com/comments_updates.html
램이 1.5기가가 달린 윈도 XP가 페이지 폴트의 영향 때문에 성능이 몹시 떨어져서 나왔는데,  나중에 다시 테스트해서 올리겠다고 한다. 이런, XP하고 비스타의 I/O 성능 비교가 가장 궁금했는데.
어쨌거나 이것들을 다시 테스트 해보는 일은 엄청 귀찮을텐데 5판을 낼 때쯤에나 다시 해보지 않을까 걱정이 되기도 한다.

제프리 리처의 책이 더 이상 새 버전이 안나오는 것은 정말 아쉬운 일인데, 이 책은 5판도 6판도 계속 해서 쓰여졌으면 좋겠다.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
내 블로그에 프로세스 모니터 사용법이라는 검색어로 들어오는 사람들이 많아서 언젠가 한번 포스팅 해봐야겠다는 생각을 하고 있었다.
프로세스 모니터에 대해 궁금했던 사람들이 조금이라도 도움을 얻고 돌아가기를 바란다.

프로세스 모니터는 SysInternals에서 만든 수 많은 도구들 중 애플리케이션의 분석과 디버깅을 위한 가장 멋진 도구 중 하나이다.

나는 처음에 이 툴을 켜는 것을 무진장 싫어했다.
일단 실행하면 이상한 메세지들이 미친듯이 많이 내려와서 시스템을 엄청 느리게하는 것이 싫었기 때문이다.

하지만, 꾹 참고 얼마 동안만 사용하다 보면 이 툴이 왜 훌륭한지, 그리고 사용자를 충분히 많이 배려해서 만들었음을 깨닫게 될 것이다.

프로세스 모니터를 통해 그동안 너무 많은 문제를 해결했기 때문에, 나는 이제 이 툴의 신봉자가 되어버렸다.
마크 루시노비치는 그의 블로그의 한 포스트에서 스승이었던 데이비드 솔로몬이, "야 임마, 뭔가 의심가면 먼저 프로세스 모니터로 확인해 봐" 라고 말하곤 했었다 했다. 우습게도 지금 마크는 자신의 딸에게 똑같은 말을 한다고 한다.
"아빠, 이거 학교 숙제인데 잘 모르겠어요."
"그럼 프로세스 모니터로 확인해보거라."
ㅡ.ㅡㅋ

농담처럼 이야기 했지만, 정말로 이 말을 믿고 따라야한다.

  • 응용 프로그램이 내 컴퓨터에서만 오동작 할 때.
  • 프로그램 성능의 발목을 잡는 병목점이 어딘지 찾고 싶을 때.
  • 특정 프로그램이 도대체 내부에서 무슨 짓을 하는지 분석하고 싶을 때.
  • DLL이 로드되고 언로드 되는 것을 확인하고 싶을 때.

그리고 이 외 모든 이상하고 골치 아픈 문제들에 대해서 프로세스 모니터가 기꺼이 친구가 되어줄 것이다.
위 마크의 포스트에서도 시스템 부팅이 심하게 느린 원인을 프로세스 모니터를 통해 멋지게 밝혀낸 내용이 쓰여있다.

프로세스 모니터의 주요 5가지 기능은 다음과 같다.


좌측의 아이콘부터,
  • 레지스트리 활동 모니터링
  • 파일 시스템 활동 모니터링
  • 네트워크 활동 모니터링
  • 프로세스와 쓰레드 활동 모니터링
  • 이벤트 프로파일링

다섯가지 아이콘을 모두 클릭해서 프로세스의 모든 활동을 살펴 볼 수도 있지만, 로그가 너무 많아지면 문제에 집중하기 힘들기 때문에 원하는 특정 기능만을 활성화 시키면 된다.

하지만 레지스트리나 파일 시스템 둘 중 하나만 클릭해보더라도 얼마나 많은 로그가 쌓이는지 보고는 깜짝 놀라게 될 것이다. 아무 프로그램도 안 띄워놓고 있더라도 파일 시스템과 레지스트리는 눈에 안보이는 서비스나 백그라운드 애플리케이션들에 의해 항상 바쁘다.

이를 좀 더 편하게 추려내기 위해 프로세스 모니터는 강력한 필터링 기능을 또한 제공한다.


처음 프로세스 모니터를 켜면 위와 같이 필터링 대화상자나 나타난다.
초록색 아이템은 관심있어 하는 내용이고, 빨강색 아이템들은 관심이 없으니 캡쳐 하지 말라는 뜻이다.
위 그림에서 처럼 프로세스 이름으로 필터링 할 수도 있고, 파일의 경로나 쓰레드 아이디, 어떤 특정한 동작을 하는지의 여부로도 필터링 할 수가 있다. 알고 싶은 내용에 대해서만 로그가 나오도록 필터링 옵션에 숙달되는 것이 프로세스 모니터를 사용하는데 있어서 가장 중요한 점이다.

또한 위 그림에서 맨 좌측에 있는 체크박스들은 꽤 근래에 생긴 편리한 기능이다.
자신이 자주 쓰는 옵션들로 필터들을 한번 넣어 놓은 뒤, 다음번 실행시에는 체크박스만 껐다 켰다 하면서 쉽게 제어할 수 있다.


메뉴의 필터 부분을 보면 방금 설명한 필터 기능을 제외하고, 주목할 기능이 3가지가 더 있다.


Enable Advanced Output을 켜면 파일 시스템 활동을 관찰할 때 Operation이 아래 그림처럼 나타난다.


커널 쪽에서 프로그래밍 경험이 있는 사람들이라면 각 디스패치 루틴들과 대응된다는 것을 알 수 있을 것이다.

Advanced Output 옵션을 사용하지 않는다면 아래 그림처럼 일반 응용 프로그래머들에게 좀 더 익숙한 Win32 인터페이스 이름으로 출력된다.

Advanced Output 이라고 해서 항상 좋은 것은 아니며, 자신이 어떤 부분에 관심이 있는지에 따라서 양쪽을 번갈아가면서 사용하면 된다.

Drop Filtered Events 라는 것은 역시 최근에 생긴 너무 반가운 기능이다.
기본적으로 프로세스 모니터를 켜고 나면, 필터를 아주 정교하게 설정해서 원하는 로그만 출력되게 했다고 할지라도, 화면에만 안 나올 뿐이지 다른 모든 내용들이 캡쳐된다.
이는 메모리를 몹시 많이 잡아먹고 시스템을 느려지게 하는데, 위 기능을 사용하면 관심없는 이벤트들은 캡쳐하지 않고 바로 버리게 된다.
하지만, 시스템이 조금 느려지더라도 모든 내용을 버리지 않고 간직하고 있는 것이 유용할 때가 종종 있다. 로그를 보는 도중 다른 아이디어가 생각나서 필터를 변경했을 때 예전 내용들을 다 가지고 있다면 곧바로 확인해 볼 수 있지만, Drop해버리면 프로세스 모니터를 껐다 켜서 다시 캡쳐해야한다. 기능을 잘 이해한 채 적절히 사용하면 된다.


Highlight 기능 역시 로그를 쉽게 보는데 도움을 준다.

위 그림은 윈도 탐색기가 수행하는 파일 오퍼레이션 중, 파일 생성/오픈 요청이 성공한 경우만을 하이라이팅 하는 것을 보여준다.
이 정도로 간단한 경우에는 프로세스 모니터의 하이라이팅도 편리하지만 조금 더 복잡해지면 설정하는 것이 꽤나 귀찮고 색깔도 하나라서 눈도 아프다.
그래서 그런 경우에 나는 로그를 통째로 vim에 붙여넣은 뒤 vim을 통해 여러 색깔로 하이라이팅해서 보고는 한다. 이 방법에 관심이 있다면 아래 글을 참고하면 된다.
로그 뷰어로써의 Vim, 멀티 하이라이팅


프로세스 모니터로 캡쳐한 내용을 파일로 저장할 수도 있다. 보통 PML이나 CSV 형식 중 하나로 저장하는데, 나는 PML 포맷으로 저장해서 프로세스 모니터로 열어보는 것을 선호한다. CSV로 저장한 뒤 엑셀 같은 프로그램으로 열어볼 수도 있다.

이 로그들을 처음부터 바로 파일로 저장할 수는 없을까 하는 생각이 들 수도 있다.
자신이 작성하고 있는 커널 쪽 코드에 오류가 있으면 블루스크린을 만나게 되거나, 시스템 전체가 멈춰버리는 경우가 생길 수 있는데, 이런 경우 프로세스 모니터를 켜놓고 있어도 시스템이 꺼져버리는 등 로그가 날라가기 때문에 내가 지정한 파일로 저장한다면 유용할 수 있다. 이것은 File 메뉴의 Backing Files 옵션에서 설정 가능하다.
바로 밑에서 설명할 프로세스 모니터에 커스텀 로그 출력하는 방법과 함께 사용하면 더욱 도움이 될 것이다.


응용 프로그램이나 드라이버가 프로세스 모니터를 통해 자신들만의 로그 메세지를 출력하는 것도 가능하다.
이렇게 할 때의 장점은 여러가지가 있다.

  • 프로세스 모니터가 캡쳐하는 파일이나 레지스트리 작업들과 함께 내 커스텀 로그 메세지를 한 눈에 볼 수 있다. 물론 순서가 뒤죽박죽 되지 않도록 프로세스 모니터가 잘 동기화 해준다.
  • 프로세스 모니터가 시간, 프로세스 이름, 쓰레드 번호 등의 부가 정보를 다 기록해주기 때문에 자신의 Logger에서 이런 것들을 구현할 필요가 없다.
  • 프로세스 모니터의 강력한 필터링과 하이라이팅 기능도 공짜로 이용할 수 있다.
  • 프로세스 모니터를 켜야만 로그를 쓰는 작업에 대한 오버헤드가 생긴다. 즉, 프로세스 모니터가 꺼져있으면 프로세스 모니터로 로그를 전송하지 않기 때문에 응용 프로그램의 속도 저하가 발생하지 않는다. -디바이스를 한번 오픈해보는 오버헤드는 있다.

프로세스 모니터로 커스텀 로그를 출력하는 자세한 방법은 아래 글에서 확인해볼 수 있다.
프로세스 모니터에 디버깅 메세지를 인젝션하기

얼마전에 소개했던 filetest 프로그램과 프로세스 모니터는 환상의 짝궁이기도 하다. filetest.exe 프로세스만을 캡쳐하도록 필터링해 놓은 뒤 원하는 I/O를 시도해보고 프로세스 모니터의 반응을 살펴보면 파일 시스템이 어떻게 동작하는지 쉽게 배울 수 있다.

위에서 설명한 사용법 들에 익숙해지면 프로세스 모니터를 통해 직접 문제를 해결할 수 있을 것이고, 또 이를 여러번 시도 할수록 자신만의 문제 해결 기법 아이디어을 갖게 될 것이다.

이런 몇몇 참신한 기법들에 대해서는 -위에 나왔던 시스템 부팅이 느린 현상을 해결한 포스트처럼- 이미 마크 루시노비치의 블로그나 Sysinternals의 세미나 자료를 통해서 많이 공개되어 있으니 부지런히 찾아다니면서 익혀두면 피가 되고 살이 될 것이다.
저작자 표시 비영리 동일 조건 변경 허락
신고

'Softwares' 카테고리의 다른 글

리눅스 3.0 시대  (0) 2011.05.25
ACE 6.0 static build  (2) 2011.03.06
프로세스 모니터 사용법  (6) 2011.01.14
2010년 분야별 최고의 오픈소스들  (5) 2011.01.09
파일 조작 테스트를 위한 훌륭한 도구 소개  (4) 2010.12.27
VirtualBox 4.0 베타  (0) 2010.12.07
  1. Favicon of http://nyolong.egloos.com BlogIcon 뇨릉 at 2011.01.19 14:04 신고 [edit/del]

    얼마전에 FileMon을 받으려더 Process Monitor와 통합이 되어서 저도 이툴 한번 써봤었는데요. ㅋ
    전 간단히 파일모니터하는데만 썼었는데 참 괜찮은 툴 같습니다 ^^

    Reply
  2. BlogIcon tack at 2011.01.24 16:08 신고 [edit/del]

    전 크롬을 사용중인데 이상하게 Highlight 기능 역시... 아래 그림이 안나오네요 :(
    헌데 Explorer.exe에 대한 내용이 원래 이렇게 많나요? ㅎㅎ

    Reply
    • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2011.01.24 17:14 신고 [edit/del]

      에 정말요? 저도 크롬쓰는데 잘 나오는데.
      다른 장소에서도 잘 나오고요. 용량이 조금 크긴 한데 다른 문제가 있는건지 모르겠네요.

submit
마크 루시노비치가 그의 블로그에 레드스크린이나 핑크 스크린을 만드는 쓸데없는(?) 포스팅을 하면서 곁다리로 윈도 인터날 6판을 언급하였다.

윈도 인터날 6판은 모두 예상하던대로 윈도7과 윈도2008 R2의 내용이 메인으로 다루어지게 되며 올해 여름(!)에 나올 예정이라 한다. -윈도 인터날 5 한글판을 산지 얼마 되지도 않았는데.

5판이 번역서가 나올때 까지는 1년이 걸렸다. 원서를 찔끔 찔끔 보면서 번역서가 나오기를 목이 빠지도록 기다렸었다.
어떤 출판사에서 번역하더라도 상관없으니 이번에는 좀 빨리 번역서가 나왔으면 좋겠다. @.@

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. Favicon of http://nyolong.egloos.com BlogIcon 뇨릉 at 2011.01.19 14:07 신고 [edit/del]

    Windows Internals 5판 사놓고 못보고 있는데.. 6판 빨리도 나오는군요 ㅋ

    Reply

submit
윈도우즈 API를 사용하다보면 종종 reserved라는 파라메터를 접하게 된다.

LONG WINAPI RegQueryValueEx(
  __in         HKEY hKey,
  __in_opt     LPCTSTR lpValueName,
  __reserved   LPDWORD lpReserved, //This parameter is reserved and must be NULL.
  __out_opt    LPDWORD lpType,
  __out_opt    LPBYTE lpData,
  __inout_opt  LPDWORD lpcbData
);

도대체 마이크로소프트는 이딴 수법을 왜 쓰는 것일까?

첫번째는 나중에 함수의 기능이 추가되거나 쉽게 확장될 수 있도록 하기 위해서이다. 이 추가적인 파라메터로 인해 인터페이스를 변경하지 않고도 쉽게 기능을 넣을 수 있다.
문서상에서 많은 reserved 파라메터들이 반드시 NULL을 넣어야 한다고 쓰여있는데, 이렇게 해두면 추후 함수가 변경될 때 이전 클라이언트 코드들과 구분을 하기가 용이해진다.

두번째는 윈도우즈 내부에서 호출하는 경우이다. 외부에서 노출된 winapi를 사용하는 클라이언트들에게는 NULL을 넣도록 하고, 내부에서는 다른 용도로 특별한 값을 넣어서 사용하는 것이다.

세번째 이유는 첫번째 이유와 반대이다.
처음 해당 함수가 생길 당시에는 reserved 파라메터는 실제 다른 어떤 용도로 쓰이고 있었다. 시간이 한참 지나고 해당 필드의 의미가 퇴색되고 더 이상 필요 없게 되어 버리자, 파라메터를 제거하는 대신 이름을 reserved로 바꾸어 버렸다. 물론 이전 코드들과의 호환성을 지켜주기 위함이다.

또 다른 이유는 구조체에 불필요한 패딩 데이터를 포함시키지 않고 차라리 reserved용도로 사용하려는 것이다.
struct IconDirectoryEntry {
    BYTE  bWidth;
    BYTE  bHeight;
    BYTE  bColorCount;
    BYTE  bReserved;
    WORD  wPlanes;
    WORD  wBitCount;
    DWORD dwBytesInRes;
    DWORD dwImageOffset;
};
위 구조체에서는 4번째 필드인 bReserved가 패딩 데이터를 채우는 대신 그 자리에 차라리 reserved용 데이터를 집어 넣었다는 것이 명백히 드러난다.

저작자 표시 비영리 동일 조건 변경 허락
신고

submit
이제는 마이크로소프트에 흡수된 구 Sysinternals가 만든 여러 유용한 툴 중 Process Monitor는 내가 가장 좋아하는 툴이다.
많은 사람들이 Process Explorer만을 사용하는데, 아마도 Process Explorer의 직관적인 사용자 인터페이스 덕분이리라.
Process Monitor는 잘 사용하려면, 툴에도 익숙해져야 하지만 Windows API를 많이 알고 있어야 하기 때문에 개발자가 아닌 QA팀 같은 곳에서는 사용하기 힘들다.
하지만 프로세스가 수행하는 모든 동작들을 잡아채서 보여주기 때문에 어떤 응용프로그램을 분석할 때 유용한 많은 정보들을 얻어 낼 수 있다.

DbgView 또한 우리 개발자들이 디버깅 할 때 많이 사용하는 애플리케이션 중 하나다. 응용프로그램이나 디바이스 드라이버에서는 OutputDebugString이나 DbgPrint 같은 함수로 로그를 작성한 후 이 툴을 통해서 프로그램의 상태를 추적하고는 한다.

파일 시스템 필터드라이버를 만들게 되면 이 두가지를 같이 병행하고 싶은 경우들이 생길 수 있다.
응용프로그램들이 어떤 Irp를 보내는지를 모니터하고, 내 필터 드라이버는 어떤 동작을 하는지를 함께 보고 싶은 것이다.

두가지 툴을 번갈아 가면서 쳐다보는 일은 순서를 제대로 예측하기가 어렵기 때문에 정말 열받는 일인데, 이번에 프로세스 모니터에서 이런 기능을 해결하기 위한 인터페이스가 하나 추가되었다.

이 아이디어는 디버깅 애플리케이션으로 유명한 존 로빈스생각해내고 제안했는데, 현재 MS 최고의 프로그래머 중 하나인 마크 루시노비치를 자신의 꼬붕 프로그래머라고 농을 치는 것이 너무 웃긴다.

What I really wanted was for my trace statements to be part of the Process Monitor viewing so that way it would be trivial mapping the I/O activity to operations in my code. Fortunately, I have a personal developer at my disposal that is keen to tackle these kinds of challenges. He’s a very nice guy named Mark Russinovich who happens to be the author of Process Monitor. Mark is always eager to hear feature requests for his tools and I think he’s implemented at least 30 features in Sysinternals tools over the years that I thought would be great to have. Don’t hesitate to email Mark with feature ideas so he can be your personal developer as well.

존 로빈스의 유머 감각은 정말 끝내주는데 그의 디버깅 애플리케이션만큼 웃기는 컴퓨터 책을 아직도 만나보지 못했다.
이런 멋진 해커이자 명저자가 다시는 책을 안쓰기로 결정한 것은 정말 슬픈 일이다.

어쨌거나 마크는 콘트롤 코드를 하나 추가해서 DeviceIoControl 함수를 통해 인터페이스 할 수 있도록 기능을 제공해주었고, 최신버전의 프로세스 모니터를 보면 도움말에서 아래 코드를 찾아볼 수 있다.

#define FILE_DEVICE_PROCMON_LOG 0x00009535
#define IOCTL_EXTERNAL_LOG_DEBUGOUT (ULONG) CTL_CODE( FILE_DEVICE_PROCMON_LOG, 0x81, METHOD_BUFFERED, FILE_WRITE_ACCESS )

int main( int argc, char * argv[] )
{
  HANDLE hDevice = CreateFile( L"\\\\.\\Global\\ProcmonDebugLogger", 
                       GENERIC_READ|GENERIC_WRITE,
                       FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
                       NULL,
                       OPEN_EXISTING,
                       FILE_ATTRIBUTE_NORMAL,
                       NULL );

  if ( hDevice != INVALID_HANDLE_VALUE ) {
    WCHAR text[] = L"Debug out";
    DWORD textlen = (_wcslen(text)+1) *sizeof(WCHAR)
    DWORD nb = 0;

    BOOL ok = DeviceIoControl( hDevice,
               IOCTL_EXTERNAL_LOG_DEBUGOUT, text, textlen, NULL, 0, &nb, NULL );

    if ( ok ) {
      printf( "wrote %d\n", i );
    } else {
      printf( "error 0x%x\n", GetLastError() );
    }
  } else {
    printf( "error %d opening Process Monitor\n", GetLastError() );
  }
  return 0;
}
존 로빈스는 .NET과 C/C++에서 좀 더 편하게 사용할 수 있는 Wrapper 코드를 만들어서 올려놓았다.
커널 드라이버에서 사용하고 싶다면,
ZwDeviceIoControl
ZwDeviceIoControlFile 함수를 통해서 직접 Wrapper를 작성해야 한다. 존도 이제는 늙어서 커널 코드는 만들어주기가 귀찮은가보다.


이런 식으로 애플리케이션이나 드라이버에서 프로세스 모니터에게 직접 디버그 메세지를 보낼수가 있다.

기존에 OutputDebugString이나 DbgPrint로 찍은 함수를 Process Monitor가 잡아채서 찍어주는 것이 아니고, 우리가 직접 커스텀 함수를 호출해야만 로그 메세지를 보낼 수 있는 것에 주의하자.
즉, 꽁짜로 얻을 수 있는 것은 아니고 기존에 사용하던 애플리케이션이나 드라이버의코드를 고쳐야 한다는 것.(래퍼 함수를 작성하고, 필요한 곳에서 호출하는 만큼의 비용은 지불해야 한다.)

저작자 표시 비영리 동일 조건 변경 허락
신고

submit
레이몬드 첸의 윈도우 개발 282 스토리 - 10점
레이몬드 첸 지음, 손광수 옮김/ITC(아이티씨)
윈도우즈 프로그래머라면 꼭 구독해야 할 블로그로 하나를 꼽으라면 단연 레이몬드 첸의 The Old New Thing 일 것이다.

그의 블로그는 포스팅이 꽤나 자주 올라오는데, 보통 한번에 2개씩 올라오고 하나는 기술적인 이야기 다른 하나는 잡소리이다.

윈도우즈 프로그래머가 관심있어 할만한, 그리고 얻어갈만한 주제들로 글을 쓰는데다가 유머감각도 꽤 있기 때문에 그의 블로그는 재미있다.


이 책은 2006년에 그의 블로그의 글들을 모아서 발행되었으며, 2007년에 번역서가 출간되었다.
처음 이 책이 나왔을 때 나는 UI 프로그래밍에 관심이 많아서 그 쪽으로 많이 읽었는데, 이번에 다시 읽을 때는 파일 시스템이나 윈도우 시스템 내부의 이야기를 중심으로 읽었다.

물론 재밌기도 할 뿐더러, 그의 놀라운 지식과 통찰력들을 많이 배울 수 있어서 좋은 주말이었다.

기술적으로만 보면 NTFS의 터널링이나 디렉터리의 읽기 전용 속성에 대한 내용이 가장 기억에 남지만, 그보다도 더 인상 깊었던 것은 쉽게 지나칠뻔 했던 어떤 챕터에서 나온 다음 문장이었다.

만약 어떤 애플리케이션이 윈도우 95에서 실행되지 않는다면(애플리케이션의 버그로 인하여) 필자는 이를 개인적인 실패로 받아들였다. 그리고 수많은 밤을 새면서 이들이 윈도우 95에서 실행될 수 있도록 하기 위해 서드파티 프로그램들의 버그를 수정했다.

얼마나 많은 개발자들이 버그를 남의 탓으로 돌리는지를 잠깐만 생각해보면, 왜 마이크로소프트의 윈도우가 이렇게 성공할 수 있었는지, 그리고 그가 왜 세계 최고의 프로그래머라는 소리를 듣는지를 조금이나마 이해할 수 있다.

2007년 이후 그의 블로그에 엄청난 양의 포스팅이 쌓였는데, 이제 2권을 낼 때가 되지 않았나 싶기도 하다. 2권을 낸다는 글을 얼마전에 어디선가 본거 같기도 한데(그게 이 책을 다시 찾은 이유였지만) 꿈에서 봤는지 아무리 찾아봐도 찾을 수가 없었다.

이렇게 얻어갈 것도 많으면서 재밌게 읽히는 책은 많지 않다.
빨리 2권이 나와서 내게 또 하나의 즐거움을 줬으면 좋겠다.

신고
  1. Favicon of http://blogs.technet.com/sankim BlogIcon sankim at 2010.08.01 22:33 신고 [edit/del]

    제 블로그 방문해 주셔서 가사합니다.
    근데 허헉.. 한글번역본이 있군요? 번역 상태는 어떤가요?

    Reply
    • Favicon of http://www.petabytes.org BlogIcon 김재호 at 2010.08.01 22:50 신고 [edit/del]

      음 글쎄요. 다른 블로그들에는 번역이 엉망이라고 많이 쓰여있던데 저는 그렇게 나쁘지는 않았습니다. 단지 용어의 선택이 아쉬운 부분들이 많기는 했는데, 주의 깊게 읽으면 괜찮아요^^;

  2. fullc0de at 2011.06.18 16:16 신고 [edit/del]

    저도 번역본 읽다가 원서 사본 1인 ㅋㅋ

    Reply

submit