Media Log


윈도 인터널 6판이 곧 나오는 것 같다. 이번에는 2권으로 분리되어 나오는 것 같은데 내용도 많이 보강이 될 것 같아서 기대가 된다. 이번에 번역은 누가 하려나. 빨리 번역되었으면 좋겠다.
저작자 표시 비영리 동일 조건 변경 허락
신고

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
SysInternals의 대부분의 유틸리티들은 하나의 실행파일로 배포된다.

프로세스 모니터 같은 도구는 시스템 내에서 일어나는 모든 I/O등을 잡아채서 보여주는데 이 역시 EXE 파일 하나로 배포된다. 그렇다면 마크 러시노비치가 이것들을 유저모드 애플리케이션에서 구현했다는 말인가? 아니, 심지어 이런 것들을 유저모드에서 구현할 수나 있는 것일까?
물론 그렇지는 않다. 프로세스 모니터는 파일 시스템 레이어 상위에 장착되는 필터 드라이버와 응용 프로그램으로 구성되어져 있다. 아마도 필터 드라이버가 열심히 I/O를 엿본 다음에 그 정보를 잘 정리해서 응용 프로그램에게 전달한 뒤 응용 프로그램이 GUI로 출력하도록 구현되어져 있을 것이다.

그렇다면 프로세스 모니터의 드라이버 이미지는 어디에 숨어있는 것일까?
드라이버는 바로 EXE 파일 내의 리소스에 있다.


응용 프로그램 내에 커스텀 리소스를 하나 만들어서 그 곳에 바이너리 파일을(여기서는 프로세스 모니터 드라이버 이미지) 쑤셔 넣어둔다.
응용 프로그램이 처음 실행되면 FindResource, LoadResource, LockResource, SizeofResource 함수들을 사용해서 이 리소스를 읽어 오고 CreateFile과 WriteFile 같은 함수를 통해서 새로운 파일을(바로 그 프로세스 모니터 드라이버) 디스크 상에 만들어낸다.
이런 식으로 말이다.
HRSRC h = FindResourceW(0, MAKEINTRESOURCEW(IDR_BIN), L"BIN");
HANDLE hRes = LoadResource(0, h);
CONST CHAR* p = (CONST CHAR*)LockResource(hRes);
HANDLE hFile = CreateFileW(L"D:\\bin", GENERIC_ALL, 0, 0, CREATE_ALWAYS, 0, 0);
DWORD cb = SizeofResource(0, h);
DWORD dw;
WriteFile(hFile, p, cb, &dw, 0);
UnlockResource(hRes);
너무 간단하지 않은가?

이제 드라이버 파일이 생겼으므로 응용 프로그램 코드에서는 CreateServiceStartService 함수들을 통해서 드라이버를 설치하고 구동시킬 수 있다.
응용 프로그램이 종료 될 때는 물론 드라이버를 잘 멈추고 제거하고 파일을 지워버리는 등의 작업 또한 해주어야 할 것이다.

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. 관우 at 2011.01.05 23:15 신고 [edit/del]

    너무 궁금했는데 이렇게 간단할 줄은 몰랐네요. ㅎㅎ 잘 배워 갑니다.

    Reply

submit
유저모드에서는 CancelIo 함수를 통해서 해당 장치에 들어간 모든 I/O를 취소할 수 있고 CancelIoEx 함수를 통해서 특정 비동기 I/O만을 취소할 수도 있다.
비스타 이후부터는 CancelSynchronousIo 함수를 통해 CreateFile 같은 동기 함수도 취소할 수가 있다. 비동기가 지원이 되지 않는 함수들은 CreateFile 처럼 금방 수행되는 함수들인데, 이런 함수들을 과연 취소할 필요가 있는가 생각이 들수도 있지만, Network-redirector(SMB 같은)를 이용하여 원격지에 있는 파일에 접근할 경우 네트워크가 지연될 때 응용 프로그램에 꽤 오랜 블록킹이 발생할 수가 있다. 이런 함수를 잘 알고 이용하면 조금 더 응답성이 좋은 애플리케이션을 만들 수 있다.

사실 유저모드에서야 CancelIo를 부를 필요도 없이 애플리케이션을 꺼버리거나 I/O를 하는 장치의 핸들을 닫아버리면 알아서 취소가 되기 때문에 I/O의 취소에 대해서 그다지 고민할 일이 없지만 -대부분의 응용프로그래머들은 CancelIo같은 함수에 크게 관심을 갖지 않는다- 디바이스 드라이버에서는 조금 다르다.

디바이스 드라이버가 I/O의 취소를 제대로 구현해주지 않으면, 애플리케이션이 종료될 때에 Irp가 취소되지 못하고 드라이버에게 계속 잡혀있어서 애플리케이션이 제대로 종료되지 않은 채 계속 좀비로 남아있다거나, 운영체제가 셧다운되지도 않는 몹시 나쁜 상황을 맞이할 수 있기 때문에 I/O 취소의 올바른 구현은 필수적이다. -이런 경우를 조금이라도 방지하기 위해서 윈도우즈는 5분이 지나면 해당 Irp의 데이터구조는 삭제하지 않은채 취소를 시켜준다. 이것은 엄밀히 말하면 I/O의 취소라고는 할 수 없다.

그럼 디바이스 드라이버에서는 I/O를 어떻게 취소하는가.
디바이스 드라이버에게 I/O의 취소라는 것은 단순히 STATUS_CANCELLED 상태로 Irp를 완료시키는 것이다.
Irp에는 취소 루틴의 포인터가 담겨있는데, 우리가 이곳에 취소 로직을 적절히 구현하여 넣어주면 애플리케이션이 I/O의 취소를 요청할 때 I/O 매니저가 이 취소루틴을 호출 해주고 Irp는 취소로 완료될 수 있다.
하지만 드라이버는 취소루틴에서 STATUS_SUCCESS로 완료시켜버릴 수도 있고, STATUS_CANCELLED로 리턴하더라도 그 바로 직전 I/O가 정말로 완료되었을 수도 있기 때문에 유저모드에서 CancelIo 등을 사용해서 I/O가 완전히 끝났는지 잘 취소되었는지를 검사하는 것은 사실 별로 의미가 없다. 그냥 취소 했다는 것에만 의미를 두면 된다.

취소 루틴에 대해 간단하게 이야기 했지만,  취소루틴을 구현한다는 것은 생전 만나보지 못한 어려운 경쟁 상태를 해결해야 하기 때문에 많은 어려움이 따른다.
이런 어려움을 해소해주기 위해 마이크로소프트에서는 언제부턴가 Cancel-Safe Queue 라이브러리를 제공해주고 있다.

나는 다행히도 꽤 편한 세상에서 태어났고 디바이스 드라이버의 세상에 입문한지 얼마 되지 않았기 때문에, Cancel-Safe Queue를 사용하지 않고 직접 취소를 구현하는 드라이버는 구현해보지 않았다. -진심으로 다행이라 생각한다.

Cancel-Safe Queue를 이용하면 이런 골치 아픈 동기화 처리를 직접하지 않아도 된다.
우리는 라이브러리 루틴 내에서 제공하는 몇 가지 콜백함수들만 적절히 구현해주면 되는데, Csq 라이브러리가 자신들의 취소루틴을 붙였다 떼었다 하면서 우리의 콜백 루틴들을 동기화까지 포함해서 적절히 호출해주기 때문에 우리는 취소루틴을 제공할 필요도 없다. 대단하지 않은가. 이런 방식의 라이브러리를 제공한다는 것은 보통 일이 아니다.

앞으로 점점 많이 사용될 WDF에서는 우리가 취소에 관해 알아야 할 것들이 더욱 줄어들기 때문에 이런 처리가 더욱 쉬워지는데, 아직 WDF를 공부해보지 않아서 어떻게 동작하는 것인지는 모르겠다.

Cancel-Safe Queue의 예제 코드는 WDK 샘플 코드의 /src/general/cancel 위치에 있다.

Csq를 사용하기 위해 우리가 구현해줘야 할 콜백함수들은 다음과 같다.

  • XxxCsqInsertIrp
  • XxxCsqRemoveIrp
  • XxxCsqPeekNextIrp
  • XxxCsqAcquireLock
  • XxxCsqReleaseLock
  • XxxCsqCompleteCanceledIrp

이름에서 볼 수 있듯이 자료구조에 Irp를 넣고 찾고 빼고 잠그는 루틴들을 우리가 구현해주면 되는 것이다.
즉, 자료 구조와 동기화 방식을 우리가 결정할 수 있다. 자료구조는 거의 링크드 리스트를 이용하며, 어떤 커널모드 동기화 방식을 써서 구현해도 상관없지만 성능을 위해 보통 스핀락을 사용한다.
Csq를 쓰면 전역 캔슬 락을 사용해서 구현한 기존의 드라이버들 보다 성능에도 이점이 있다.

각 콜백 함수 구현에 대한 코드는 샘플 코드에서도 찾아볼 수 있지만, 이 문서에는 설명까지 덧붙여 잘 나와있으므로 한 번쯤 읽어보는 것이 좋겠다. 보통의 경우에는 샘플 코드를 복사해서 쓰는 것으로 충분할 것이므로 여기에 따로 코드를 적지는 않는다.

이 루틴들을 다 구현했으면 IoCsqInitialize 함수로 적절한 곳에서 초기화를 하며 콜백 함수들을 등록시켜준 뒤에, Irp가 들어올 때 IoCsqInsertIrp함수를 통해 큐에 집어넣고 나서 I/O 작업을 한다. 작업이 끝나면 IoCsqRemoveIrp함수를 통해 큐에서 빼고 잘 제거된지 확인 한 후에 여느 때처럼 IoCompleteRequest 함수로 Irp를 완료시켜주면 된다. 도중에 애플리케이션들로부터 취소가 요청되면 Csq가 적절히 우리가 작성한 취소 로직들을 이용하여 취소를 수행 해줄 것이다.

위의 설명에서 몇 가지 추가 설명을 해야 할 것들이 있는데, 콜백함수는 우리가 직접 부르는 것이 아니다. 우리 코드에서는 IoCsqInsertIrp처럼 IoCsqXxx 루틴들을 사용 한다. 이 루틴들이 내부에서 우리의 콜백함수를 적절한 곳에서 호출해줄 것이다.

초기화 할 때 IoCsqInitialize가 아니라 IoCsqInitializeEx함수를 이용하면 IoCsqInsertIrpEx 함수를 통해 추가적인 컨텍스트를 담을 수 있다. 이런 추가적인 컨텍스트는 우리가 Queue를 사용하는데 있어서 더 많은 유연함을 가능하게 한다. 

Csq를 사용할 때는 Csq에 관련된 데이터구조가 Irp->Tail.Overlay.DriverContext[3] 에 보관된다.
그러므로 Csq를 사용할 때는 이름이 DriverContext라고 해서 이 곳에 함부로 아무 데이터나 담아서는 안되겠다. 참고로 유저모드 파일시스템 드라이버 프레임워크인 Dokan에서는 Csq를 사용하지 않고 직접 취소루틴을 구현했는데, DriverContext[2]와 [3]에 추가적인 데이터를 담아 사용하고 있다.

위에서 작업이 끝나면 IoCsqRemoveIrp 함수를 통해 큐에서 빼고 잘 제거되었는지 확인하라고 했는데, 이는 그 사이에 취소가 들어왔을 경우 큐에서 이미 빠져버렸을 수 있기 때문이다. 만일 NULL이 리턴되었다면 도중에 취소 요청이 들어와 큐에서 이미 빠진 것이다. 그 Irp는 곧 XxxCsqCompleteCanceledIrp 루틴에 의해 완료되게 될 것이고 이 Irp를 우리가 또 완료시켜서는 안된다.

마지막으로 IRP_MJ_CLEANUP 디스패치 루틴에서는 내 디바이스의 핸들이 닫히는 경우에 큐에 Pending되어 있는 Irp들을 모두 완료 시켜주어야 한다.

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. 디바이스 드라이버 at 2010.10.25 12:44 신고 [edit/del]

    우연히 찾게 되었는데 무척 좋은 글 잘 읽고 갑니다.^^

    Reply

submit
ReactOS의 새로운 버전이 1년여 만에 릴리즈 되었다.

윈도우즈를 공부하는 사람들에게 이 정도 수준의 참고할만한 프로젝트가 또 있을까.

리버싱 지식이 전혀 없는 나로서는 윈도우 내부가 궁금할 때마다 항상 ReactOS의 코드에서 답을 찾고는 하는데, 이는 정말 많은 도움이 된다.

혹시 이런 프로젝트를 아직까지 모르고 있었다면 당장 코드를 다운받아서 몽땅 태깅해놓고 필요할 때마다 살펴보자.

아직은 구현이 안된 코드들도 상당히 많은데, 빨리 빨리 발전해서 더 많은 코드들을 참고할 수 있었으면 좋겠다.

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

submit
Windows Internals 제5판 - 10점
마크 러시노비치 외 지음, 안철수 연구소 기반기술팀 옮김/에이콘출판


악. 기다리고 기다리던 Windows Internals 5th가 드디어 번역본이 나왔다.

이 책을 처음 훑어 봤을 때는 데이빗과 마크 이 자식들이 대체 무슨 이야기를 하고 있는 건지, 왜 이 따위 얘기를 하는건지 아무것도 이해할 수가 없었다.

4판 서문에 저자들이 제프리리처에게 감사를 전하는 문구가 있는데 내용이 너무 웃긴다.

Thanks to our friend Jeffrey Richter, for writing the "What about .NET and WinFX" sidebar in Chapter1 and for continuing to remind us over many dinners together of his view on how few people should care about what we talk about in this book.

도대체 그런 주제로 책을 쓰면 몇 명이나 사보겠냐. Windows via C/C++ 을 이길수 있을 것 같아? 라고 밥먹는 중에 놀려대는 모습이 왠지 상상이 간다.

디바이스 드라이버를 만들어보면서 이 책의 내용들이 조금 더 잘 이해가 되기 시작했다. 그리고 특정 개발자들에게는 정말 중요한 내용이라는 것도 알았다.

내 실력이 부족한 것이 주 원인이었지만 기존 4판에서는 번역도 조금은 불만족스러웠고 잘못된 그림이나 오타 등도 많아서 답답했다.
그것보다 더 중요한 것은 비스타 이후 변경된 많은 내용들이 4판에는 없었다는 것인데, 그래서 5판이 빨리 번역되어 나오기를 간절히 기다려왔다.

실력있는 사람들이 작업한 만큼 많은 것을 배울 수 있을 것 같아서 가슴이 설렌다.
책 값이 조금 비싸긴 하지만, 뭐 좋은 책이니깐 이 정도 쯤이야.
신고
  1. Favicon of http://namoda.springnote.com BlogIcon 나모 at 2010.10.28 14:15 신고 [edit/del]

    지난 주에 교보에 들렸다가 이 책을 보고 바로 구입했습니다. 오늘 도착했는데 Windows via C/C++ 옆에 놔두니 다른 출판사의 책이지만 옆면은 비슷하네요. 둘 다 Microsoft Press 라서 그런가요?

    Reply

submit
Programming The Microsoft Windows Driver Model 2nd Edition - 10점
Walter Oney 지음, 소현우 옮김/정보문화사

드라이버 공부를 하기 위해 이런 저런 책들을 찾아봤는데 이 책 만큼 좋은 책은 없는 것 같다.

이 책은 WDM 드라이버를 만들기 위해서 알아야 할 모든 내용을 다루고 있는데, 2004년도에 국내에 번역이 되었고 Windows XP 까지 다루고 있으며, 현재는 절판되었다.

비스타나 Windows 7이 나왔다고해서 이 책의 3판이 나올 것 같지는 않다.
이제는 새 책이 나오더라도 WDF에 대한 책이나 몇 권 더 나오고 말지 않을까. 그나마 드라이버에 관한 새 책이 나오더라도 어디에서도 번역하려하지 않을까봐 두렵다.

이 책은 전체적으로 사람들이 궁금해할만한 내용들에 대해서 잘 설명해주고 있으며, 그 중 5장의 Irp의 처리과정은 이 책의 꽃이라 할 수 있다. 나는 이 챕터를 5번도 넘게 읽은 것 같다.
맨 처음 읽을 때는 도대체 무슨 소리인지 알수가 없었지만 한번씩 다시 읽을 때마다 점점 명확해져 가는 것을 느낀다.

책의 내용 중 설명이 부족하거나 잘 이해가 가지 않는 내용이 있으면 ReactOS의 코드를 함께 살펴보고는 하는데, 이는 아주 많은 도움이 된다.
물론 ReactOS의 구현이 윈도우즈의 구현과 완전히 같을 것이라 믿어서는 안되지만 참고용으로 보기에는 아주 훌륭하다.
ctags 같은 도구를 통해 전체 코드를 태깅 해놓고 필요할 때 빠르게 찾아갈 수 있도록 해두면 좋을 것이다.

재미있는 것은, ReactOS의 코드를 읽으면서 코드 작성자 중 눈에 익은 이름을 하나 발견했는데 바로 Windows Internals 5판의 공동저자로 참여한 Alex Ionescu 였다.

어느 날, 이런 ReactOS가 잘 돌아는갈까 갑자기 궁금해져서 이미지를 받아 설치해봤었는데, Windows 95보다도 못한 그 조잡함에 경악을 하며 동시에 마이크로소프트가 얼마나 대단한지 새삼 깨달았다.
ReactOS는 10년넘게 개발되면서 아직도 버전이 0.3인데, 얼른 얼른 발전해서 참고할 수 있는 코드들이 더 많아졌으면 좋겠다.

다음 글들은
osronline
osronline
과 msdn에서 찾은 윈도우즈의 Irp 처리 방식을 다루는 좋은 문서들이다.
이 책에서 이미 이 내용들을 다 설명하고 있지만, 함께 참고해서 읽다보면 이해를 도와줄 것이다.
신고
  1. at 2010.09.29 00:14 [edit/del]

    비밀댓글입니다

    Reply
  2. at 2011.01.07 12:14 [edit/del]

    비밀댓글입니다

    Reply
  3. at 2011.01.14 01:44 [edit/del]

    비밀댓글입니다

    Reply
  4. at 2012.08.27 20:27 [edit/del]

    비밀댓글입니다

    Reply

submit