code toolbox

안녕하세요. moltak 입니다.

윈도우에서 Eclipse로 개발하면 컴파일러를 gcc를 사용하게 됩니다.

Eclipse에 CDT를 설치해서 소스코드 작성하고 gcc를 이용해 컴파일하며 gdb를 이용해 디버깅 하게 됩니다. 리눅스에서는 아주 쉽게 되는 작업이지만 처음 사용하는 저는 굉장히 어려웠습니다.

이 포스팅의 목표는 GoogleTest(이하 gtest)를 윈도우에서 gcc를 이용해 컴파일하고 eclipse에서 사용하는 것을 목표로 하겠습니다. 먼저 Eclipse와 JDK, CDT가 없으신 분은 [Eclipse에서 C, C++ 개발환경 구축하기] 를 참고하셔서 먼저 설치를 하시기 바랍니다.

먼저 gtest를 다운로드 받습니다. http://code.google.com/p/googletest/downloads/detail?name=gtest-1.5.0.zip

그 후 압축을 푼 후 아래를 따라 합니다.

실행 -> cmd -> cd gtest directory -> cd make -> mingw32-make Makefile all -> mingw32-make gtest.a

Figure 1 MinGW32-make

Figure 2 Make 수행 후

제대로 되셨다면 gtest.a 가 생성이 됩니다. .lib 라이브러리 파일은 msvc에서만 사용하는 라이브러리 파일이고 gcc는 .a라는 라이브러리 파일을 사용하게 됩니다. gtest.a 가 제대로 생성이 됐다면 이제 gtest를 사용하는 일만 남았습니다.

Figure 3 GTest 예제 코드

위 코드는 gtest를 사용하는 예제 코드입니다. 이 코드를 돌려 보도록 하겠습니다.

Eclipse를 실행시켜주세요. C++ 프로젝트를 생성 하신 후 위 코드를 작성 합니다.

이제 이클립스에서 몇 가지 설정을 해줘야 하는데요.

프로젝트 속성 -> C/C++ Build -> Settings -> GCC C++ Compiler -> Directories 부분에 gtest\include 폴더 추가해 주세요.

그리고 제가 가장 헤멘 부분. [.a] 링크하기!! 처음에 .a파일을 생성해야 하는 이유도 몰랐고 어떻게 하는지도 몰랐죠. 몇 일간 헤메니깐 답이 보이더군요. (이클립스를 이용해서 윈도우 플랫폼에서 C++ 개발하는 분들이 별로 없나 봅니다. 검색해도 잘 나오지 않던…)

다시 프로젝트 속성에 가셔서 C/C++ Build -> Settings -> MinGW C++ Linker -> Miscellaneous -> Other objects에 [gtest.a] 파일의 경로를 지정해 주시면 됩니다. 그리고 컴파일 하시면 성공!!

Figure 4 실행 화면

Figure4 그림처럼 나오면 성공입니다. ^^

이 글을 작성하고 나니깐 지난 3일간이 제가 엄청나게 삽질을 했다는 것을 알겠네요. 블로깅 양이 엄청 적은… 하지만 이제 리눅스와 윈도우에서 똑 같은 개발 환경을 갖고 프로젝트를 진행 할 수 있다는 것이 너무나 기쁘네요.

GTest를 G++로 컴파일해서 eclipse로 컴파일해서 사용했다는 것은 이제 어떤 라이브러리도 사용할 수 있다는 것을 뜻합니다. 물론 좀 복잡하게 사용해야 하지만… MSVC가 너무 잘 만들어진 IDE라서 윈도우에서는 MSVC 말고는 사용하기 힘들기도 할 것 같습니다. 하지만 Eclipse의 매력도 얕볼 수가 없는데 리눅스에서도 똑 같은 자신의 환경을 갖고 프로그래밍 할 수 있다는 큰 매력이 있다는 것입니다.

Bloger : moltak.net

googletest 환경 구축

안녕하세요. moltak입니다. 오늘은 TDD를 사용하기 위한 Google C++ Testing Frameworks를 설치해보고 예제를 돌려보겠습니다.

C++ Unit Test Framework는 굉장히 많습니다. JAVA는 JUnit과 Hamcrest라는 Framework 많이 사용하더군요. 하지만 C++은 언뜻 봐도 굉장히 많습니다. 저는 C++의 모든 Test Framework를 사용해본 것은 아닙니다. 그렇다고 Google Framework가 아주 좋다는 것도 아닙니다. 다만 사용하기 쉽고 굉장히 직관적이었습니다. (다른 Framework도 그런지는 모르겠네요. )

잔소리는 여기까지 하고 일단 사용해보도록 하겠습니다.

구글 Framework 또한 다른 라이브러리와 마찬가지로 아래 순서를 따르게 됩니다. 하나 하나 보도록 하죠.

1. Downloads

2. 설치

3. Visual Studio 설정

4. 사용하기

1. Downloads : : http://code.google.com/p/googletest/ 에 들어가서 상단에 Downloads 탭을 선택한 후 윈도우 버전 다운로드.

Figure 1 google test downloads

2. 설치 : 자신이 원하는 폴더에 압축해제. 그 후 gtest\msvc 폴더에 가서 gtest.sln 파일을 더블 클릭.

만약 버전이 안 맞아서 솔루션 파일을 변경해야 할 경우 .vcproj(프로젝트 파일)의 읽기 전용 속성을 해제하세요.

그 후 해당 솔루션을 컴파일 합니다.

3. VS 설정

VS2005~2008 : 도구->옵션->프로젝트 및 솔루션->VC++ 디렉터리

VS2010 : 프로젝트 옵션에서 설정해야 합니다.

포함 파일과 라이브러리 파일 경로 설정.

• 포함파일에 \include 경로 설정
• 라이브러리 파일에 \msvc\gtest\debug 경로 설정

Figure 2 Visual Studio Setting

위 그림처럼 하시면 됩니다.

Google Testing Framework는 런타임 라이브러리가 다중 스레드 디버그(/MTd) 이기 때문에 우리의 프로젝트 설정도 위 처럼 바꿔 줘야 합니다.

프로젝트 설정 -> 구성 속성 -> C++ -> 코드 생성 -> 런타임 라이브러리 -> 다중 스레드 디버그(/MTd)

Figure 3 런타임 라이브러리 변경

그 후 라이브러리 링크

이렇게 하시면 기본적인 설정 방법은 끝이 났습니다. 다른 라이브러리와 사용법이 같기 때문에 쉽게 하셨을 것 같네요.

4. 사용

이제 진짜로 사용해보도록 하죠.

문법은 위 그림과 같습니다. (http://soupim.tistory.com/48 참조)

사용 하실 때는 아래 소스처럼 하시면 쉽게 사용이 가능하십니다.

Figure 4 사용 예제 소스

저는 Test Fixtures를 사용해서 테스트를 수행하곤 하는데요. 이 방법이 Java나 다른 책에서 설명하는 TDD기법과 아주 유사합니다.

Figure 5 Test Fixtures 사용 예제

여러분들도 위 방법을 사용해서 테스트를 수행해보세요. 그리고 테스트 이름은 한글로 하는 것이 좋다고 하더라고요. (채수원 : 고품질 쾌속개발을 위한 TDD 실천법과 도구(한빛미디어))

위 책을 보고 있는데요. 상당히 좋습니다.

Figure 6 실행 화면

5. 정리

이렇게 해서 Google Testing Framework 설치와 사용법이 설명이 끝났습니다. 많이 사용해 보시고 저한테도 알려주셨으면 감사하겠습니다. ^^

그리고 Google Test UI도 있는데요. 아래 경로로 찾아 들어가시면 됩니다.

Figure 7 Google Test UI

위 손가락 위치에 가시면 다운 받으실 수 있습니다. 상당히 보기 편하더라고요. 다른 Unit Test 툴처럼. 하지만 저만 그런지는 모르겠으나. 굉장히 느립니다. 5초 이상 걸리는 것 같습니다. 다른 분들도 한번씩 사용해 보세요. 더 보기 좋답니다. ^^

이만 마치도록 하겠습니다.

Bloger : moltak.net

드라이버를 공부하시려면 꼭 기억해야 될 내용이 있습니다. 일반적인 드라이버를 짤 때 우리는 아래 그림과 같은 문장을 사용합니다.

이 그림이 뭘 의미 하는 걸까요? 바로 콜백함수의 등록입니다. NDIS 드라이버도 마찬가지지만 콜백을 잘 끼워 맞추기만 하면 됩니다.

콜백의 기능, 전체적인 콜백 호출 흐름, 각 콜백 안에서 호출해야 할 API들을 파악했다면 NDIS의 절반 이상을 이해한 것이라고 합니다. (참조: http://xeraph.com/4787739)

IntermediateDriver의 초기화는 처음 공부하는 저에게는 상당히 어렵더군요. (사실 아직도 이해하는 중입니다.)

이 글에서는 일반적인 드라이버의 DriverEntry와 Intermediate 드라이버의 DriverEntry를 비교하겠습니다. 그래서 어떻게 다른지 개략적으로 설명하고 다음 글에서부터 본격적으로 분석을 해보도록 하겠습니다.

Intermediate 드라이버의 예제는 DDK 폴더 안의 passthru라는 예제가 있습니다. 그 예제를 기반으로 설명하겠습니다.

일반적인 드라이버의 경우 IoCreateDevice를 호출해서 드라이버를 생성하게 됩니다. 그 후 심볼릭(Symbolic) 링크를 만들고 MajorFunction(DDK WDM 문서 참조)의 콜백함수를 지정하는 것으로 넘어가게 됩니다.

하지만 NDIS 드라이버의 경우 많이 다릅니다. 우리가 작성하려고 하는 NDIS Intermediate Driver의 예를 들자면 여러 초기화 과정이 필요하게 됩니다.

passthru의 DriverEntry 함수를 보시면 크게 네 개의 초기화 단계(아래 그림 참조)로 나눌 수 있습니다.

또한, DDK 문서(참고: moltak.net: NDIS Driver 02) Intermediate Driver)에 MiniportXxx, ProtocolXxx함수를 노출시켜야 한다고 설명하고 있습니다.

그래서 NDIS의 초기화 단계는 Miniport, Protocol Driver의 콜백함수를 설정해야 합니다.

1. NdisMInitializeWrapper을 호출하고 NdisWapperHandle에서 리턴된 핸들을 지정한다.

2. 드라이버의 MiniportXxx 함수들을 등록하기 위해서 NdisIMRegisterLayeredMiniport를 호출하고 스텝 1에서 얻어진 핸들을 인자로 보낸다.

NdisMinitializeWrapper 함수를 호출해서 NDIS_HANDLE을 얻어 올 수 있습니다.(NdisWrapperHandle 변수)

그리고 이 변수를 이용해서 우리는 MiniportXxx와 ProtocolXxx를 노출 시켜줄 수 있습니다.

위 소스에서 MChars라는 변수에 여러 가지 콜백함수를 설정하고 있는 것을 볼 수 있습니다.

현재는 이것을 통해서 콜백을 등록하고 가장 아래 있는 NdisIMRegisterLayeredMiniport를 이용 MiniportXxx를 등록한다고만 아시면 됩니다. (자세한 설명은 다음 블로깅을 통해 하도록 하겠습니다.)

3. 만약 드라이버가 그 자신을 밑의 NDIS 드라이버에게 다음에 바인드 한다면 드라이버의 ProtocolXxx 함수들을 등록하기 위해서 NdisRegisterProtocol을 호출한다.

위 소스도 ProtocolXxx함수를 노출시키기 위해서 하는 것입니다. 각종 콜백함수를 등록하고 아래에 있는 NdisRegisterProtocol을 통해 인터미디엇 드라이버의 ProtocolXxx함수들을 노출시킵니다. 각 콜백함수의 내용은 복잡하고 역할은 아직 잘 모릅니다. (알아야 할게 너무 많네요ㅠㅠ)

4. 만약 드라이버가 MiniportXxx와 ProtocolXxx함수들 둘 다를 드러낸다면, 드라이버의 미니포트 하위경계와 프로토콜 상위경계에 대해서 NDIS 라이브러리를 형성하기 위해서 NdisIMAssociateMiniport를 호출한다.

우리는 MiniportXxx와 ProtocolXxx함수를 노출하길 원합니다. (노출하기 원하지 않다면 한 개의 핸들만 넣어도 되는 건지는 확실하지 않네요. ㅠㅠ)

NdisIMAssociateMiniport 함수는 NDIS에게 미니포트와 프로토콜을 위한 특정 lower와 upper 인터페이스들이 각각 같은 인터미디엇 드라이버에 속한다는 것을 알립니다.

여기까지 해서 DriverEntry에 대한 개략적인 설명이 끝났습니다. 원본 소스파일은 ddk\src\network\ndis\passthru\driver\passthru.c 파일을 참조하시기 바랍니다.

다음은 인터미디엇 드라이버의 DriverEntry에서 Miniport를 등록하는 부분을 더욱 세세하게 설명을 하도록 하겠습니다. 내용이 많아서 몇 챕터로 쪼개서 해야겠네요. 아무튼 모두들 즐공! 즐프! 하세요.

Bloger: moltak.net

NDIS 드라이버는 Miniport, Intermediate, Protocol 타입의 네트워크 드라이버들을 제공합니다.

3타입의 네트워크 드라이버들이 어떤 역할을 하는지 차근차근 알아보도록 하겠습니다.

1. Miniport Driver

Miniport Driver(이하 미니포트 드라이버)는 두 가지 역할을 수행합니다.

그림에서 보시는 바와 같이 NIC(Network Interface Card)바로 위에 위치해 있습니다. 미니포트 드라이버는 NIC을 통해 데이터를 보내고 받는 것을 포함해서, NIC을 관리합니다. 또, Intermediate Driver(이하 인터미디엇 드라이버)와 같은 상위 레벨 드라이버들과 통신합니다.

미니포트 드라이버는 NDIS 라이브러리를 통해 NIC과 그리고 상위 레벨 드라이버들과 통신합니다. NDIS 라이브러리는 미니포트가 호출하는데 필요한 운영체제의 모든 시스템 함수들을 캡슐화하는 NdisXxx함수들을 익스포트 합니다. 미니포트 드라이버는 상위 레벨 드라이버들이 미니포트 드라이버에 접근하기 위해서 또는, 자기 자신을 위해서 NDIS가 호출하는 엔트리 포인트들(MiniportXxx 함수들)을 익스포트 해야 합니다. 송/수신 연산들(패킷을 보내고 받고 하는 것을 말하는 듯)은 미니포트 드라이버들과 NDIS 상위 레벨 드라이버들간에 상호 작용입니다.

- 전송 계층 드라이버가 전송하고자 하는 패킷들을 가지고 있을 때, 전송 계층 드라이버는 NDIS라이브러리에 의해 익스포트 되어지는 NdisXxx 함수를 호출합니다. NDIS는 그러고 나서 미니포트에 의해 익스포트된 적당한 MiniportXxx함수를 호출함으로써 미니포트에게 패킷을 전달합니다. 패킷을 받은 미니포트 드라이버는 적당한 NdisXxx함수들을 호출함으로써 전송을 위해 NIC에게 패킷을 포워드 합니다.

- NIC이 패킷을 수신할 때, NDIS 혹은 NIC의 미니포트에 의해 처리될 수 있는 하드웨어 인터럽트를 포스트 할 수 있습니다. NDIS는 적당한 MiniportXxx함수를 호출함으로써 NIC의 미니포트 드라이버에게 알립니다. 미니포트 드라이버는 NIC으로부터 데이터 전송을 설정하고 그리고나서 적당한 NdisXxx 함수를 호출함으로써 바인드된 상위레벨 드라이버들에게 수신된 패킷의 존재를 (Indicate)알립니다.

2. Intermediate Driver

드라이버 계층도에서 보면 인터미디엇 드라이버는 Protocol Driver(이하 프로토콜 드라이버)와 미니포트 드라이버들 사이에 위치합니다. 그래서 "위"의 프로토콜 드라이버와 "아래"의 미니포트 드라이버들과 통신을 수행해야 합니다.

- Lower Edge에서 인터미디엇 드라이버는 NDIS가 미니포트 드라이버와 통신하기 위해 호출하는 프로토콜 엔트리 포인트들(ProtocolXxx 함수들)을 노출합니다. 미니포트 드라이버가 인터미디엇 드라이버를 볼 때 인터미디엇 드라이버는 프로토콜 드라이버가 되는 것으로 나타납니다.

- Upper Edge에서 인터미디엇 드라이버는 NDIS가 프로토콜 드라이버와 통신하기 위해 호출하는 미니포트 엔트리 포인트들(MiniportXxx 함수들)을 노출합니다. 프로토콜드라이버가 인터미디엇 드라이버를 볼 때 인터미디엇 드라이버는 미니포트 드라이버가 되는 것으로 나타닙니다.

- 인터미디엇 드라이버 요약 정리: 인터미디엇 드라이버는 upper edge에서 MiniportXxx 함수들의 subset을 익스포트 합니다. 하지만 실제로 물리 NIC을 관리하지는 않습니다. (NIC의 관리는 Miniport Driver가 합니다.) 그 대신에, 인터미디엇 드라이버 위의 프로토콜들이 바인드 할 수 있는 하나, 혹은 그 이상의 가상 어댑터들을 익스포트 합니다. 그리고 프로토콜 드라이버들은 인터미디엇 드라이버에 의해 익스포트되어지는 가상 어댑터들이 물리 NIC이 되는 것으로 보이게 됩니다.

프로토콜 드라이버가 가상 어댑터(인터미디엇 드라이버가 익스포트 한)에 요구 혹은 패킷들을 보낼 때, 인터미디엇 드라이버는 이런 요청과 패킷을 아래 미니포트 드라이버에 전달하게 됩니다.

- 인터미디엇 드라이버는 일반적으로 다음과 같이 사용됩니다.

다른 네트워크의 사이를 변환하기 위해: 예를 들어, Ethernet과 Token Ring 전송 계층들과 ATM 미니포트 사이에 인터미디엇 드라비어의 함수는 Ehternet과 Token Ring 패킷들을 ATM패킷들로 맵하거나 그 반대로 맵합니다.

패킷들을 필터하기: 방화벽 같은 것을 만들 때 사용합니다.

하나 이상의 NIC과 관련해서 패킷 전송의 균형을 맞춘다: 패킷을 분산합니다.(??)

3. Protocol Driver

드라이버들의 NDIS 계층도에서 가장 위에 있는 프로토콜 드라이버는 TCP/IP혹은 IPX/SPX 스택과 같은 전송 프로토콜 스택을 실행하는 전송 계층 드라이버내에서 가장 낮은 레벨 드라이버로서 사용됩니다. 전송 계층 드라이버는 패킷들을 할당하며 어플리케이션이 보내는 데이터를 패킷에 복사하며, 또 이러한 패킷들을 NDIS 함수들을 호출함으로써 낮은 레벨 드라이버에게 보냅니다. 프로토콜 드라이버는 낮은 레벨 드라이버로부터 들어오는 패킷들을 수신하기 위해 프로토콜 인터페이스를 제공합니다. 전송 계층 드라이버는 수신된 데이터를 요청된 클라이언트 어플리케이션에 전송합니다.

Lower Edge에서 프로토콜 드라이버는 인터미디엇 드라이버들과 미니포트 NIC드라이버들에 인터페이스 합니다. 프로토콜 드라이버는 패킷들을 보내기 위해서 NdisXxx함수들을 호출하고, Lower 레벨 드라이버들에 의해 유지된 정보를 읽고 설정하고 운영체제 서비스들을 사용합니다. 프로토콜 드라이버는 NDIS가 수신한 패킷들을 위로 전송하기 위해서 그리고 Lower 드라이버들의 상태를 알기 위해, 혹은 자신의 목적을 위해 호출하는 엔트리 포인트들(ProtocolXxx 함수들)의 집합을 익스포트 합니다.

Upper Edge에서 전송 계층 프로토콜 드라이버는 프로토콜 스택에서 상위 레벨 드라이버에 대한 private 인터페이스를 갖게 됩니다.

4. 정리

위 그림은 이제까지 설명해왔던 내용을 알기 쉽게 나타내 주는 그림입니다. (제 개인적인 생각)

위 그림에서는 Intermediate Driver가 빠져 있습니다. 대신 Wrapper가 포함되어 있죠. 이 것을 보고 여러가지로 생각 할 수 있겠지만 오늘 공부한 내용을 토대로 생각해 본다면 Intermediate Driver는 단순히 Miniport Driver의 Wrapper로 생각할 수 있다는 것입니다. (Miniport <-> Intermediate <-> Protocol 의 관계를 생각해 보세요) Intermediate Driver를 Miniport에 대한 Wrapper로 생각한다면 이해하기가 더 쉽습니다. 어떤 요청이던지 저 방어망을 치고 있는 Wrapper를 뚫지 않고서는 Miniport에게 갈 수가 없습니다. 그리고 Wrapper는 Upper Edge에 대해서는 자신이 Miniport인 것처럼 행세 할 것이며 Lower Edge에 대해서는 Protocol인양 행세 할 것입니다.

다만 NIC과 Miniport Driver와의 관계는 좀 이상하긴 하지만 그거 빼고는 맞는 것 같습니다. (아하하하하하;;)

이 글에서 가장 중요한 것은… 바로 제 프로젝트를 완수 하려면 어떤 드라이버에서 해도 상관 없지만 보통 Intermediate Driver에서 수행한다는 것입니다. (사실 Miniport에서도 할 수 있고 Hook Driver를 만들어서도 할 수 있습니다.)

Bloger: moltak.net

Chapter1 네트워크 드라이버 디자인 가이드에 대한 로드맵

Windows2000(XP, 2003 포함)은 세가지 기본 타입의 커널 모드 네트워크 드라이버들을 제공합니다. 이 세가지 타입에 대해서 정확히는 아니더라도 대략적으로 알고 있어야 차후 드라이버를 작성할 때 선택해서 할 수 있을 것입니다. 그러니 세 개다 살펴 보도록 하겠습니다. 그 전에 먼저 Windows의 Network Layer 부 터 알아보도록 하겠습니다.

위에 보시는 것이 Windows의 Network Layer입니다.

[참조: http://subsub.windowstest.net/bbs/view.asp?tb=ndis&no=221 ]

보통 Network 드라이버를 짤 때 NDIS와 TDI를 사용하게 됩니다. 만약 TDI Filter를 개발한다면 얻을 수 있는 것은 IP, Port, Application Protocol(TCP 이후의 데이터)를 얻을 수 있으며 모니터링, 변조, 차단등을 할 수 있다고 합니다. NDIS Protocol Driver를 개발한다면 Ethernet Header, IP Header, TCP Header, App Protocol까지 모든 Raw Packet의 정보를 얻을 수 있다고 하네요. 하지만 직접적인 변조, 차단을 할 수 없다고 합니다. 그것을 하기 위해서는 NDIS Intermediate 드라이버나 NDIS Hook Driver 혹은 WFP(Windows Filtering Platform) 드라이버를 작성해야 한다고 합니다.

1. Miniport NIC Drivers

미니포트 드라이버는 직접 NIC을 관리하고 상위 레벨 드라이버들에 대한 인터페이스를 제공한다. (NDIS DDK 문서)

2. Intermediate Drivers

인터미디엇 프로토콜 드라이버는 legacy 전송 드라이버와 같은 상위 레벨 프로토콜 드라이버들과 미니포트 사이에 인터페이스이다. 일반적인 인터미디엇 프로토콜 드라이버를 개발하는 일반적인 이유는 존재하는 legacy 드라이버와 전송 드라이버에 알려지지 않은 새로운 미디어 타입을 위한 NIC을 관리하는 미디포트 사이에 미디어 전환을 행하는 거다.

3. Protocol Drivers

상위 레벨 프로토콜 드라이버는 TDI 인터페이스를 실행하거나 네트워크 사용자들에 대한 서비스들을 제공하기 위해 상위 edge에 또 하나의 어플리케이션 특정 인터페이스를 행한다. lower edge에 이러한 타입의 드라이버는 다음 lower 드라이버로부터 들어오는 패킷들을 수신하고 패킷들을 프로토콜 인터페이스에 제공한다. 또 하나의 타입의 프로토콜 드라이버는 연결 지향 콜 매니저이다. 콜 매니저는 프로토콜 드라이버인 연결 지향 클라이언트들을 위해 서비스들을 콜 설정하고 tear-down 을 제공한다.

Windows2000에 의해 제공되는 또 하나 타입의 커널 모드 드라이버는 필터 hook 드라이버이다. 필터 패킷들에 사용되는 필터-hook 드라이버는 운영체제에 의해 제공되는 IP 필터 드라이버의 기능을 확장한다.

작성하려고하는 드라이버 타입의 상관없이 Part 1, Network Drivers Design Guide 의 Chapter 2-3을 읽어야 한다. 이러한 장들은 Windows2000네트워크 아키텍처와 프로그래밍 고려 사항들을 토론한다. 또한 Part5, Chapter 1을 읽어야 한다. 이 장은 네트워크 요소들을 인스톨하기 위해 사용된 네트워크 INF 파일들을 토론한다. 만약 네트워크 드라이버가 예를 들어 바인딩을 제어하기 위해 notify 객체를 요구한다면은, Part 5, Chapter 2를 읽어라.

읽어야 할 추가적인 chapters들을 알기 위해, 다음 그림에서 적당한 드라이버 타입을 클릭하라. 이것은 드라이버 타입의 선택을 재 정의하도록 하고 그 섹션으로 점프할 것이다.

Miniport Drivers

작성할 다음과 같은 타입을 선택한다.

Connectionless Miniport

만약 Ethernet, FDDI, 혹은 Token Ring과 같은 비연결 지향 네트워크 미디어을 위해 NIC을 제어하는 미니포트를 작성한다면은,

Part 2, Chaters 1-7, 9을 읽어라.

WAN Miniport

만약 WAN NIC을 제어하는 미니포트를 작성한다면은,

Part 2, Chapters 1-9를 읽어라.

Connection-Oriented Miniport

만약 ATM 혹은 ISDN과 같은 연결 지향 네트워크 미디어을 위한 NIC을 제어하는 미니포트를 쓴다면은,

Part 2, Chapters 1-7, 9
Part 4, Chapter 1을 읽어라.

Integrated Miniport Call Manager(MCM)

만약 콜 매니저 서비스들을 제공하는 연결 지향 NIC을 제어하는 미니포트를 작성한다면은,

Part 2, Chapters 1-7, 9
Part 3, Chapter 2
Part 4, Chapter 1 를 읽어라.

Intermediate Drivers

작성할 인터미디엇 타입을 선택한다.

With a Connectionless Lower Edge

만약 lower edge가 비연결지향 미니포트들에 대한 인터페이스를 제공하는 인터미디엇 드라이버를 작성한다면은

Part 3, Chapter 1을 읽어라.

With a Connection-Oriented Lower Edge

만약 lower edge가 연결 지향 미니포트들에 대한 인터페이스를 제공하는 인터미디엇 드라이버를 제공한다면은,

Part 3, Chapter 1
Part 4, Chapter 4를 읽어라.

Protocol Drivers

작성할 프로토콜 드라이버의 타입을 선택한다.

With a Connectionless Lower Edge

만약 lower edge가 비연결지향에 대한 인터페이스를 제공하는 프로토콜 드라이버를 작성한다면은,

Part 3, Chapters, 2를 읽어라.

With TDI upper edge

TDI upper edge를 가지는 프로토콜를 작성한다면은

Part 3, Chapters, 2, 3, 4, 5를 봐라.

With Winsock support

만약 Winsock 지원을 제공하는 프로토콜을 작성한다면은,

Part 3, Chapters, 2, 3, 4, 5, 6을 봐라.

Connection-Oriented Client or Call Manager

만약 연결 지향 미니포트들에 대한 인터페이스를 제공하는 연결 지향 클라이언트를 작성하거나, 연결 지향 콜 매니저를 작성한다면은

Part 3, Chapter 2
Part 4, Chapter 1을 봐라.

Filter-hook Drivers

Part 6, Chapter 1을 봐라.

Bloger: moltak.net

오늘은 메모리 구조에서 가장 복잡하다고 느끼는 세그먼테이션에 대해서 정리하겠습니다.

x86에서는 segmentation과 paging 기법을 이용하여 [가상 메모리] 를 만들고 프로그램들을 실행시키게 됩니다.

그림 1 Physical Address 변환 과정

가상 메모리는 세그먼테이션 과정을 거치고 페이징 과정을 거쳐서 실제 메모리가 나오게됩니다.

이때 세그먼테이션에는 Selector와 Offset이 들어가게 되는데 Selector는 이 챕터의 제목인 세그먼트 레지스터를 말합니다. Offset은 가상주소를 말합니다.

그냥 말로 서술하면 보기 힘드니 숫자를 붙여서 설명을 해 드리겠습니다.

세그먼테이션 과정

1. 가상주소를 물리 주소로 바꾸려면 Selector(세그먼트 레지스터)와 Offset(가상주소)이 필요합니다.
2. Selector는 16bit 이며 Descriptor Table의 Index를 가리킵니다. (그림 참조)
3. Selector(세그먼트 레지스터)는 Descriptor table의 Segment Descriptor(그림 참조)를 가리킵니다.
4. Segment Descriptor의 Base 주소와 가상주소를 합쳐서 선형 주소를 만들어 냅니다.

세그먼트 디스크립터 안의 내용은 굳이 설명하지 않아도 될 것 같네요. 다만 Base Address 0-15만 알면 될 것 같습니다. Base Address 필드는 실제 세그먼트를 통해 메모리에 접근할 때 더하는 값입니다. 아까 세그먼트 디스크립터의 Base주소와 가상주소를 더해서 32bit 선형 주소를 만든다고 했었죠? 그때 사용 되는 것입니다.

이제까지 저는 세그먼트 레지스터가 16bit라고 설명을 했지만 사실 80bit 입니다. 나머지 64bit은 왜 설명 안 했냐? 하신다면 했습니다. 위에서 말한 세그먼트 디스크립터가 바로 세그먼트 레지스터의 안 보이는 나머지 64bit입니다. 왜 80bit으로 만들었는지 잘 모르겠지만 많이 추측 하는 것은 세그먼트 레지스터는 자주 사용하고 자주 사용한다면 속도가 빠른 레지스터에 올리는 것이 더 낫다고 생각됩니다.

이젠 세그먼트 레지스터를 직접 보도록 하겠습니다. Ollydbg와 Windbg를 사용하겠습니다.

Ollydbg에서 열면 6개의 세그먼트 레지스터를 볼 수 있습니다. x86은 6개의 세그먼트 레지스터가 있습니다. 그 중 노란색으로 표시된 FS 레지스터를 보겠습니다.

FS는 Selector로 동작되며 INDEX, TI, RPL(그림 참조)필드로 이루어져 있는 것을 알 수 있습니다.

그래서 이진수로 표현하면 0000 0000 00111 0 11 가 나옵니다. 앞에 13비트는 테이블에서의 세그먼트 디스크립터 위치고 그 다음 1 비트는 GDT인지 LDT인지(인터넷 참고)를 나타내며 다음 2비트는 권한(인터넷 참고)을 나타냅니다. 중요한 것은 7번째를 가리키고 있다는 것입니다.

위 그림을 보시면 선택되어 있는 부분이 FS레지스터가 가리키는 세그먼트 디스크립터입니다. Ollydbg에 나온 값이랑 똑같네요.

여기까지 해서 세그먼트 레지스터와 선형 주소를 만드는 것을 보았는데요. 생각보다 어렵다고 느끼실 수도 있습니다. 하지만 조금만 공부하시고 더 자료를 찾아 보시면 정리를 완벽히 하실 수 있을 겁니다.

그럼 모두 즐공 하세요.

Bloger: moltak.net

IA 32(x86) CPU는 크게 5종류의 레지스터가 있습니다.

범용 레지스터, 인덱스 레지스터, 포인터 레지스터, 부동 소수점 레지스터, 플래그 레지스터가 그것이며 각각 사용용도가 모두 다릅니다.

레지스터들 앞에 붙어있는 E는 Extended의 약자로서 현재 사용되는 x86 architecture는 80386에서 점차 발전해 나갔습니다.

그래서 현재 많이 사용되는 Pentium 이나 Core 2DUO 같은 프로세서들도 80386과 거의 비슷합니다. 물론 엄~~청 나게 발전 되었지만요. 

사실 저도 심볼 심볼만 하고 있었지 이 녀석이 무엇인지 어떤 역할을 하는지 잘 몰랐습니다.

저는 친절한 임베디드 시스템 블로그(http://recipes.egloos.com)를 참고 했습니다.

(개인적으로 굉장히 좋은 사이트라 생각합니다... 못 믿으시겠다면 어서 방문을 ㄱㄱㄱ)

http://recipes.egloos.com/5009181 여기를 보면 심볼에 대한 정보가 굉장히 잘 나와있습니다.

심볼이란 Linker가 쓰는 기본 단위로써, Link를 한 후 에는 자신만의 주소를 갖게 되는 특별한 단위를 말한다. 

(이 부분이 젤 중요합니다.)

위에 진하게 되어 있는 곳을 보죠. 그 중 빨간색이 가장 중요한데요. "자신만의 주소를 갖게 된다" 이 부분 입니다.. 

우리가 C로 프로그램을 짜고 디버깅을 할 때 생각해 보죠. 우리는 그 변수에 할당된 값들을 볼 수 있습니다.

 이 때 이것들의 주소가 없다면? 당연히 볼 수 없겠죠?? 하지만… 우리는 모든 변수들의 값들을 볼 수 있습니다. 

왜냐? 주소를 갖고 있기 때문입니다. 지역변수 들은 비록 EBP, ESP로 할당된 스택 프레임 안에 들어 있지만. 

일단은 주소를 갖고 있죠? 근데 이것들은 심볼이라는 것이 없습니다. 위에서 보면 "자신만의 주소"를 갖게 되는 특별한 단위라고 했는데 왜 심볼이 없냐 하면… 이 지역변수 주소는 "자신만의 주소"는 아니죠? 스택 프레임은 각 함수마다 할당되었다 사라졌다 합니다. 그 주소는 여러 변수에 의해서 계속 쓰이게 됩니다. 그래서 지역 변수는 "심볼이 없다"라고 볼 수 있겠네요.

이 분은 Symbol을 Global이라고 부르십니다(왠지 교주 찬양하는 것 같네요 -_ -;;). Global 은 프로그램이 시작하고 끝날 때까지 없어지지 않는 것들을 말하죠? 거기에 해당되는 것들이 뭐뭐 있을 까요? 함수, 전역변수, static 변수가 있죠? 위에서 말한 것 처럼 자신만의 주소를 갖게 되는 것도 이런 Global 밖에 없습니다. 나머지는 전부 stack, heap이죠…. 할당 되고 해제 되는…

자자 계속 할게요. Symbol의 이름은 그 Symbol이 갖는 메모리 영역의 시작 주소를 가리키는 Linker만의 pointer라고 하네요. 우리가 디버깅 할 때 VS에서는 자동으로 pdb 파일이 생성되죠?

(모른신다고 하면 안됩니다. 여기 증거가ㅋㅋ)

이때도 symbol의 이름이 사용된다고 합니다. 또한 우리가 C, CPP 파일을 컴파일 하면 object file(이 녀석은 소스 파일마다 생성됩니다.)

이 생성되는데 이 안에는 Linker를 위해서 symbol table을 놔둔다고 합니다. 여기 안에는 source code에 의해서 참조되는 symbol들의 이름과 위치 정보가 들어 있으며, 다른 파일에 정의되어 있는 symbol정보를 쓸 경우에는 그 정보가 해당 file에 없기 때문에 그 object 파일 안에 있는 symbol table은 완전하지 못하다고 하네요. 이런 불완전한 symbol들은 linker에 의해서 처리하여 다른 파일에 있는 symbol을 연결하여 사용할 수 있도록 만든다고 합니다. 이 symbol 정보들은 메모리에 올라오는 것이 아니며…. 오직 linker만이 이 정보들을 쓴다고 하네요. 그리고 binary(윈도우는 PE, 리눅스는 elf)로 만들어 질 때 이 symbol들을 주소로 모두 변환한다고 합니다. (네 그래서 native code안에는 symbol 정보가 없습니다.)

여기까지가 제가 공부한 내용이네요. 요약해서 뭔 말인가 하면. 이 symbol정보들은 global 한 정보들을 말하며 실제 실행 파일 안에는 들어가 있지 않다. 왜냐면 linker만 사용하기 때문에 그리고 실행파일로 만들 때 object file 안의 symbol 들을 모두 주소로 변환하니깐. 이제 좀 이해가 되기 시작하네요…(감사합니다 히언님ㅋ)

Bloger: moltak.net

이제 심볼이란 것이 무엇인지 정확이 알았으니…

IL Code에 왜 심볼 정보가 포함되는지 알아 봐야죠??

저번 시간에 Native Code에 왜 심볼정보가 포함되지 않는지를 봤었죠??

(못봤으면 참고: http://moltak.net/entry/Symbol이란)

간단히 설명하자면 심볼은 linker가 쓰는 것으로 binary가 생성되면서 심볼정보는 다 지운다고 했었습니다.

(정확히 말하면 모두 주소로 변환)

그래서 C언어를 어셈으로 보면 알아 먹기가 힘들었죠.

하지만 IL Code는 안에 심볼정보가 포함되어 있기 때문에 원래 짠 코드 그대로 볼 수 있습니다.

(참고: 쩔철이네 블로그)

처음 심볼이 뭔지 제대로 알지도 못할 때 진 MVP인 철에게 물었습니다.

어째서 IL코드에는 심볼정보가 포함되는 거야? 하구요. 철은 범용적인 것 보다는 .NET에 특화된 말을 했습니다.

(철이 말: 즉.. .Net에서는 이런 "언어간 상호 운영성"을 위해서 CLS가 존재하고, CLR은 이에 기인하여 생성된 IL코드를 기반으로 명령을 수행한다는 것이지요..

여기서 서로 다른 언어에서 동일한 Type이나 기능이지만 언어간에 서로 다른 형태의 Keyword를 사용할 수 있기 때문에..

IL코드의 생성이 필요하게 되었고, 이렇게 서로 다른 Keyword를 사용하는 언어간 동일한 동작을 보장하기 위해 어떤 동일한 명령으로 변환시키기 위해서 "IL코드에 심볼들이 포함 될 수 밖에 없었다."라는 것이 제가 내린 결론입니다.)

네…. 맞는 말인 것 같지만… 너무 복잡하네요. 쉽게 풀어서 설명해보죠.

다음 내용들은 ezbeat(http://ezbeat.tistory.com/182)블로그를 참고했습니다.

(모르는게 나오면 지인들의 힘을 빌리는 것이 참…. 편하고 좋더군요 ㅋㅋ)

자자 이제 정리해보죠. 사실 참 쉬운 것들이었습니다.

제가 자주 사용하는 C, C++은 Native Code를 생성해 내게 됩니다. 이게 뭐냐 하면 하드웨어에 종속되어 있는 코드입니다. 바로 어셈블리어죠.

위에 있는 그림처럼 처음 보는 사람은 절대 그 내용을 알 수 없는 내용들이 가득 차게 됩니다.

하지만 .NET, Java 같은 경우는 좀 다릅니다.

이것들이 만드는 코드는 하드웨어에 종속되어 있는 코드가 아닌 플랫폼에 종속된 코드를 만들게 됩니다. 바로 IL 코드입니다. 여기서 플랫폼이란 .NET Framework나 JVM이 되겠네요.

그리고 이 플랫폼들을 거쳐서 Native Code가 튀어나오게 되는 것입니다. 그리고 이 언어들은 한줄 한줄씩 컴파일되면서 실행되는 JIT(Just In Time) 컴파일을 하게 됩니다.

실행이 되는 순간에 동적으로 컴파일이 되어야 한다는 것입니다.

근데 컴파일을 하려면 결국 무엇이 필요하냐 면… 네 맞습니다. 바로 Symbol이 필요하죠. 그래서 IL 코드에는 Symbol 정보가 필요합니다.

자 이제 IL 코드에는 왜 심볼정보가 필요한지 아시겠죠??

간단히 말하자면… 실행이 되어야 하니까 필요합니다. 하하하하 쉽네요. ㅋㅋ

Bloger: moltak.net

1. WDK - Windows Vista RTM 을 다운 받아 설치

2. http://www.hollistech.com/Resources/ddkbuild/ddkbuild.htm 에서 ddkbuild 를 받아 압축을 풀고 vs .net 이 참조 가능한 패스에 복사한다.( C:\Program Files\Microsoft Visual Studio .NET 2005\Vc7\bin

3. DDKBUILD 에게 사용할 DDK version 을 알려주기 위해 약간의 편집을 해야 한다. ( 설치한 DDK 경로 설정 )

4. 프로젝트 생성 -> 메이크 파일을 선택

5. 디버그 구성 구성 설정에서 그림과 같이 설정.

6. 참고로 드라이버는 일반 어플리케이션과는 달리 debug build/release build 라고 하지 않는다. 
Debug build checked build
Release build free build

7. Visual Studio .Net의 intellisense 기능활용하기.

lib\wxp, inc\ddk, inc\api 폴더추가.

아래 챕터 처럼 다 했다면 다 성공했다.

이젠 Flash에 쓸 차례다. 혹시 전원을 뽑아 봤나? 뽑으면 알겠지만.. 걍 죽는다.ㅋ

프로그램 다 사라짐ㅋ 처음에 엄청 어이없었다. ㅋㅋ

하지만 Flash 메모리에 쓰지 않았으니 사라지는게 당연하겠지 라고 생각하고 있다.

암튼 시작~

Flash에 쓰려면 PROM File로 포멧을 변경해야 한다. 위 그림처럼 PROM File Formatter를 더블 클릭하자.

위 그림처럼 메뉴가 뜨는데 나도 잘 모르지만 위 처럼하면 그냥 된다.

위 그림 처럼 Next를 누르다가 파일 한번 선택해 주고 또 Next를 누른다. 중요한것은 마지막 화면인데 화면창이 Add Device라고 쓰여져 있는게 보이나?? 다른 장치가 있으면 추가한다던데 해본적이 있어야지ㅋ 그냥 NO를 선택하자.

이젠 단순히 그림을 보고 따라가면 된다. 블로깅은 여기서 마치겠다.ㅋㅋ