|
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 | 31 |
|
신입 개발자를 위한 조언 개발자를 위한 드래곤볼 신영진 codewiz@gmail.com, http://www.jiniya.net 일곱 개를 모으면 소원을 들어주는 드래곤볼이 있다면 개발자에겐 어떤 모습일까? 필자가 생각하는 드래곤볼 일곱 개를 모아보았다. 2008년에는 모든 개발자가 용왕님께 소원을 빌 수 있기를 기대해본다. 일성구: 배움의 시작은 겸손이다 모든 배움은 겸손에서 시작된다. 자신이 모든 것을 알고 있다는 자만심으로는 아무것도 배울 수 없다는 사실을 명심해야 한다. 개발자에게 겸손함이란 다른 개발자들의 삽질을 존중해주는 것을 말한다. 그것은 책이 될 수도 있고, 온라인 문서가 될 수도 있고, 오픈 소스 프로그램의 코드가 될 수도 있다. 항상 이러한 것들을 가까이 두고 익히는 것을 게을리하지 말아야 한다. 이성구: 기초체력은 가장 큰 재산이다 동일한 실력을 가진 두 선수의 승부는 늘 기초체력으로 귀결된다. 그만큼 기초체력은 중요하다. 개발자에게 기초체력이란 코드를 작성하는 능력이다. 이는 라이브러리나 API의 사용법을 말하는 것은 아니다. 자신의 생각을 코드로 표현하는 능력을 말한다. 이런 능력은 라이브러리나 API에서 제공하지 않는 기능을 만들어 보거나 복잡한 문제에 대한 논리를 세우고 코드를 작성하는 훈련을 통해서 기를 수 있다. 삼성구: 검증, 또 검증 지식을 배우는 데 있어서 가장 주의해야 할 것은 권위의 오류에 빠지지 않는 것이다. MSDN 샘플이니깐, 유명한 책의 예제 코드니깐, 선배 개발자의 코드니깐 이라는 이유로 그 내용을 맹목적으로 믿어서는 안 된다. 왜냐하면 누구나 실수할 수 있기 때문이다. 새롭게 익힌 내용은 검증 과정을 통해서 자신의 것으로 만들도록 하고, 그 방법에 문제가 없더라도 더 좋은 방법이 없는지 고민하는 습관을 가지도록 해야 한다. 그럴 때 비로소 그 지식은 진정 자신의 것이 된다. 더불어 한 가지 더 경계해야 할 것은 그냥이다. 컴퓨터는 논리를 기반으로 동작하는 계산기이다. 거기에 그냥이라는 이유는 없다. 따라서 프로그램이 동작하는 과정은 모두 정확하게 개발자의 머릿속에서 재현되고 그려질 수 있어야 한다. 이러한 습관이 바탕이 되면 디버깅 시간을 단축시킬 수 있다는 보너스 효과도 있다. 사성구: 꿀통을 찾아라 개발은 문제 해결 과정의 연속이다. 선배 개발자들의 문제 해결 능력이 뛰어난 이유는 그들의 경험의 폭이 크다는 것도 있지만, 자신이 모르는 문제가 발생했을 때 나름대로 그것에 관한 정보를 찾을 수 있는 수단을 마련해두고 있기 때문이기도 하다. 인맥, 보유 서적, 인터넷 검색엔진 어떤 것이든 될 수 있다. 중요한 것은 자신이 모르는 문제에 대한 정보로 가득 찬 자신만의 꿀통을 찾는 것이다. 오성구: 원리를 이해하자 라이브러리와 프레임워크 독립적인 개발자가 되도록 노력해야 한다. 이는 그런 것들을 사용하지 말라는 말이 아니다. 그러한 무기를 사용할 때에는 적어도 자신이 사용하는 것이 어떤 원리로 동작하는지 정확하게 이해한 후에 사용해야 한다는 것이다. 모르는 도구를 함부로 다룬 결과는 감당할 수 없는 현실뿐이다. 육성구: 주는 만큼 배운다 많은 개발자들이 가르쳐주는 것은 손해라고 생각한다. 지식이란 무형의 자산의 특징을 제대로 이해하지 못해서 생기는 오해이다. 지식은 나눌수록 커지고 발전한다. 한번이라도 다른 사람을 가르쳐본 사람은 그 말을 쉽게 이해할 수 있다. 가르치는 과정을 통해서 자신의 논리의 모순점을 찾을 수도 있고 자신이 미처 놓치고 있었던 부분에 대해서 점검할 수 있기 때문이다. 칠성구: 결국은 사람이다 컴퓨터만 잘 다루는 개발자는 반쪽 개발자밖에 되지 않는다. 혼자 만들 수 있는 프로그램은 한계가 있기 때문이다. 그래서 소프트웨어 개발은 항상 다른 개발자, 내지는 다른 팀들과의 유기적인 협업을 통해서 이루어진다. 이 과정에서는 다른 어떤 능력보다 커뮤니케이션 능력이 중요하다. 개발자가 가져야 할 마지막 무기는 사람을 이해하고 포용할 수 있는 따뜻한 가슴이다. |
|
64비트 윈도우의 경우에는 32비트 시스템 DLL과 64비트 시스템 DLL을 모두 가지고 있습니다. 64비트 DLL들은 System32 폴더에 들어있고, 32비트 DLL들은 SysWOW64 폴더에 들어 있습니다. 64비트용 kernel32.dll 파일을 디스어셈블링 하려고 한다면 아마 대부분 다음과 같이 할 겁니다. 1. 64비트용 IDA를 실행한다. 2. System32에 있는 kernel32.dll을 연다. 3. 분석된 내용을 살펴본다. 하지만 위와 같이 하면 백날해도 64비트 버전의 kernel32.dll은 볼 수 없습니다. 왜냐하면 64비트 윈도우의 경우 기본적으로 32비트 프로세스에게는 System32 폴더를 SysWOW64로 맵핑시켜 두기 때문입니다. 즉, System32에 있는 kernel32.dll을 열지만 실제로는 SysWOW64에 있는 kernel32.dll이 열리는 겁니다. 64비트용 IDA도 프로그램 자체는 32비트이기 때문이죠. 따라서 64비트 시스템 DLL을 디스어셈블링 하기 위해서는 다음과 같이 해야 합니다. 1. System32에 있는 kernel32.dll을 다른 폴더로 복사한다. 2. 64비트용 IDA를 연다. 3. 복사한 파일을 연다. 4. 분석된 내용을 살펴본다. olly, immunity 모두 64비트 디버깅은 지원하지 않더군요. 아직 64비트 디버깅 환경은 불모지대인 것 같습니다. 물론 windbg가 있긴 하지만 손에 안익어서 그런지 영 적응이 안되는군요. |
|
어제 VC++ 팀 블로그에 올라온 글을 보다가 Channel9 동영상을 보게 되었습니다. http://channel9.msdn.com/Showpost.aspx?postid=359749 동영상을 보면 세 명이 나오는데 남자 두 명은 MS 직원이고(??), 여자 한 분은 VC++ MVP인 Kate Gregory 아줌마 입니다. 동영상 보고 나니 아줌마 팬이 된 것 같습니다. 말도 잘하고 여러가지 C++에 대한 생각도 저랑 비슷한 것 같네요. 물론 영어를 잘 못해서 제 멋대로 이해한 건지도 모르겠습니다. ㅋㅋㅋ Channel9도 스크립트 서비스를 해줬으면 좋겠다는 생각이 드는군요. 그러면 영어 공부에 정말 도움이 될 것 같은데 말입니다. Kate Gregory 아줌마 블로그에 재미난 정보가 올라와 있더군요. "How do I"란 동영상 시리즈로 개발할 때 막히는 부분에 관한 짧은 코딩 과정을 담은 비디오 클립입니다. 리눅스의 HOWTO의 동영상 버전 정도로 생각하면 될 것 같습니다. ㅋㅋ 재미난 것들이 많네요. 이제 코드도 비디오로 배우는 시대가 오고 있나 봅니다. 후훗~ 아래는 네이티브 코드관련 동영상들 입니다. http://msdn2.microsoft.com/en-us/visualc/bb496952.aspx |
제가 집에서 원래 사용하던 마우스는 마이크로소프트 익스플로러 3.0 버전 새로 나온 것 이었습니다. 마우스가 워낙 인기가 있다보니 단종됐다가도 다시 나오곤 하더군요. 좀 커서 손이 부담스러웠는데 쓰다보니 또 익숙해지고 그랬습니다. 그렇게 불편함 없이 사용하다 버튼이 고장나서 한 번만 클릭을해도 더블 클릭이 되는 현상이 발생하더군요. 억지로 참고 쓰다, 버튼 스왑해서 쓰다가 결국 그냥 마이크로소프트의 노트북용 무선 레이저 마우스로 교체했습니다.  마우스 감도도 좋고, 무선이니깐 편하기도 하고 좋았습니다. 그런데 왠걸 이 놈은 이상하게 휠이 자꾸 저의 의도처럼 움직이질 않더군요. 파폭이나, 탐색기같은데는 괜찮은데 소스 인사이트가 특히 이상하더군요. 한참을 휠을 돌려야 겨우 한 페이지 정도 올라가는게 아니겠습니까? 인터넷을 찾아봐도 관련 정보를 찾을 수가 없었습니다. 그러다 어제 소리통 코드를 짜다가 소리통의 재생 목록 스크롤도 소스 인사이트처럼 버벅 거린다는 사실을 알게 되었죠. 그리고 그 레이저 마우스의 심오함을 MSDN을 통해서 알게되었습니다. ㅋㅋ일반적으로 휠 마우스가 날려주는 WM_MOUEWHEEL 메시지의 WPARAM에는 delta값이 넘어옵니다. 휠을 얼만큼 스크롤을 시켰냐하는 것이죠. 돌리는 방향은 양수, 음수로 계산합니다. 일반적으로 구형 마우스의 경우에는 이 값은 거의 변동 없이 WHEEL_DELTA의 배수로 넘어옵니다. WHEEL_DELTA가 120으로 정의되어 있기 때문에 +120, -120, +240 따위의 값으로 넘어오는 거죠. 그래서 보통은 휠 코드를 아래와 같이 많이 작성합니다. [CPP]LRESULT CPlayListBox::OnMouseWheel(UINT, short delta, CPoint) { UINT lines; SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, &lines, 0); VScroll(-delta / WHEEL_DELTA * lines); return 0; }[/CPP] lines는 한번 스크롤 시켰을 때 얼마씩 페이지를 넘길지를 정해둔 값 입니다. 보통 제어판에서 설정하도록 되어있습니다. 위 코드는 delta가 120이면 lines만큼, 240이면 2*lines만큼 스크롤을 시킵니다. 구형 마우스에서는 별 문제 없이 동작하죠. 왜냐하면 delta값이 항상 WHEEL_DELTA의 배수로 넘어오기 때문입니다. 하지만 제가 새로 장착한 그 레이저 마우스는 틀렸습니다. 친절하게도 사용자가 조금 휠을 돌리면 28따위의 작은 값을 보내주는게 아니겠습니까? 따라서 쌩하고 한바퀴를 돌리기 전까지 절때 delta값이 120이상 나오지 않고, 결국 WHEEL_DELTA로 나눈 값은 0이 되어서 스크롤이 안됐던 겁니다. 물론 MSDN에는 이것에 대해서 상세하게 코멘트가 되어 있었습니다. 사용자가 조금 돌린만큼 친절하게 알려주는 마우스들도 있기 때문에 그 값을 저장해서 WHEEL_DELTA만큼 됐을때 스크롤을 시키거나 아니면 부분 값으로 스크롤 시킬 수 있는 만큼 스크롤을 시키라고 되어 있더군요. 그래서 휠 코드를 아래와 같이 고쳤습니다. [CPP]LRESULT CPlayListBox::OnMouseWheel(UINT, short d, CPoint) { static int delta = 0; UINT lines; SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, &lines, 0); delta += d * lines; if(abs(delta) < WHEEL_DELTA) return 0; VScroll(-delta / WHEEL_DELTA); delta %= WHEEL_DELTA; return 0; }[/CPP] 특별한 건 없고, 값을 저장 시켜 두었다가 스크롤 시킬 수 있는 만큼이 되면 스크롤을 시켜줍니다. 이 코드로 변경하고 나니 스크롤이 정말 친절하게 잘 되더군요. 저의 의도대로 한줄씩 할 수도 있고, 한번에 팍팍 내려갈 수도 있었습니다. 이런 짓을 해보기 전까지는 그 레이저 마우스의 휠에 어떤 특별한 기능이 있다는 것을 알지 못했습니다. 그러나 이제는 그 마우스를 사용하면 한줄씩 스크롤을 할 수 있다는 사실을 알게되었죠. 노트북에서 사용하는 마우스도 바꾸어야 겠습니다. 한 번 편리함을 경험하고 난다음 돌아가기란 쉽지 않죠. 세 줄씩 휙휙 넘어가는 마우스의 불편함이란 ^^;; XP에서의 WHEEL_DELTA 위의 내용은 모두 Vista에서 테스트했던 내용입니다. 집에있던 레이저 마우스를 회사에 들고와서 XP에서 테스트 해보았습니다. 그런데 도저히 컨트롤을 해도 한줄씩 스크롤을 할 수가 없더군요. 왜 그럴까 하다가 간단한 휠 테스트 프로그램을 만들어 보았습니다.  휠에 넘어오는 delta값을 출력해본 것 입니다. 죄다 120의 배수임을 알 수 있습니다. 어떻게 돌려도 무조건 120의 배수가 나오죠. 그렇다면 전용 드라이버를 설치하지 않아서 그런 것일까하는 생각에 시디를 뜯어서 인텔리 마우스 전용 드라이버를 설치해 주었습니다. 설치하고 나서도 결과는 별반 차이가 없더군요.  제어판에 마우스 등록 정보를 살펴봤습니다. 전용 드라이버답게 다양한 옵션이 추가되었더군요. 그 중에 하나가 위에서 보이는 가속 스크롤 기능입니다. 체크를 하고 테스트를 해보았습니다.  뭔가 120으로 떨어지지 않는 숫자가 많이 보이죠. 그런데 안타깝게도 120아래에 있는 숫자는 보질 못했습니다. 즉 아무리 조금 돌려도 XP에서는 기본 120은 먹고 들어가더군요. ㅠㅠ 결국은 한 줄씩 스크롤을 할 수 없다는 이야기 일까요? 하드웨어가 좋아도 운영체제가 구리면 기능을 다 사용하지 못하는 경우도 있나봅니다. ㅎㅎ |
|
제가 가진 몇 안되는 디바이스 드라이버 책 중에 하나가 "Windows 2000 디바이스 드라이버"입니다. 질럿님께서 번역하셔서 더 애착이 가는 책이기도 합니다. ㅋ 물론 설명이 다른 책에 비해서 훨씬 쉬운 것도 한 가지 장점이 아닌가 생각해 봅니다. 각설하고 그 Windows 2000 디바이스 드라이버의 400 페이지를 보면 시스템 스레드를 종료하기 위해서 시스템 스레드를 대기하는 코드가 나옵니다. 코드를 발췌하면 아래와 같습니다. [CPP]KeWaitForSingleObject( &pDE->pThreadObj, Executive, KernelMode, FALSE, NULL); ObDereferenceObject(&pDE->pThreadObj);[/CPP] pDE->pThreadObj는 PETHREAD로 선언된 변수입니다. 별 생각없이 이 코드를 그대로 DriverUnload에 붙였더니 공포의 블루스크린이 마구 뜨더군요. 그런데도 첨에는 왜 뜨는지를 이해하질 못했습니다. 디버그 로그를 보니 단지 스레드가 종료되지 않았다는 것은 알 수 있었습니다. 더 훼이크 스러운건 KeSetEvent나 KeWaitForSingleObjects로 넘어가는 대부분의 인자가 &variable 형태라는 것 입니다. 그래서 더욱 헤맸습니다. 제가 내린 결론는 위 코드가 *아마도* 잘못된 것이 아닐까하는 것입니다. KeWaitForSingleObject의 인자로는 PVOID가 들어갑니다. 커널 오브젝트의 포인터죠. KEVENT라는 커널 이벤트 객체가 있다면 PKEVENT가 인자로 넘어가는 겁니다. 따라서 pDE->pThreadObj는 ETHREAD의 포인터인 PETHREAD로 선언된 변수이기 때문에 굳이 다시 주소 연산자를 사용해서 주소를 넘길 필요가 없습니다. 위 코드에서 &부분을 뺀 다음 테스트를 해보니 정상적으로 동작을 하더군요. ObDereferenceObject 함수도 마찬가지입니다. |
