[Noenemy]'s microgroove

Windows Phone 7.5 Programming Bible
(윈도우 폰 7.5 프로그래밍 바이블)

김순근 저 | 904쪽 | 35,000원 | 978-89-314-4191-8 | 2011년 12월 15일 | 영진닷컴

:: 책 소개
최신 윈도우 폰 7 애플리케이션 개발의 세계로 초대합니다!

이 책은 윈도우 폰 애플리케이션 개발을 처음 시작하는 독자나 다른 분야에서 애플리케이션 개발 경험이 있는 독자들도 쉽게 익혀 바로 써먹을 수 있도록 구성되었습니다.

초반부에는 스마트폰의 등장으로 인한 국내 업계의 변화와 앞으로 벌어질 IT 기업들의 경쟁, 스마트폰의 발전 과정과 주요 특징들을 분석해봅니다. 그리고 윈도우 폰 7의 등장 배경과 코드네임 메트로, 플랫폼 아키텍처와 주요 기능에 대해 알아봅니다.

중반부에는 비주얼 스튜디오 2010을 이용해 예제들을 직접 구현해보도록 소스와 함께 주요 컨트롤들을 설명하고 있습니다. 그리고 레이아웃과 테마, 애플리케이션 바와 데이터바인딩, 격리 저장소 등 Windows Phone 7에서 동작하는 애플리케이션을 개발할 때 필요한 사항들을 소개합니다. 그리고 LINQ to SQL과 콤파스, 자이로센서, 멀티태스킹 등 망고 버전으로 업데이트되면서 추가 혹은 보완된 내용들을 소개하고 있습니다.

마지막 부분에는 마이크로소프트에서 제공하는 마켓플레이스에 대해 소개하면서 개발자 계정 등록과 함께 애플리케이션 심사 및 배포까지 알아볼 수 있습니다. 그리고 개발 환경 구축법을 부록으로 다뤄 초보자들도 손쉽게 윈도우 폰 애플리케이션 개발을 시작할 수 있도록 합니다.


:: 출판사 리뷰
"소장하고 싶은 윈도우 폰 바이블의 정수!"

2010년 3월 바르셀로나에서 열린 MWC 2010에서 처음 윈도우 폰 7이 선보인 후 마이크로소프트는 스마트폰 시장 진출을 위해 많은 노력을 했으며 마침내 7.5 버전인 ‘망고(Mango)'를 출시하기에 이르렀습니다. 한때 불타는 플랫폼 위에 서있다고 표현할 정도로 위기를 맞이한 노키아가 Windows Phone 7.5를 탑재한 스마트폰을 선보였으며 국내 삼성에서도 Windows Phone 7.5를 기반으로 하는 스마트폰을 소개하였습니다.

애플의 iOS와 구글의 Android와 더불어 Windows Phone 7 운영체제도 스마트폰 시장의 한 세력을 형성할 정도로 마이크로소프트의 스마트폰 운영체제는 성장을 거듭하고 있습니다. 앞으로 마이크로소프트의 주력이라고 할 수 있는 PC 운영체제와 클라우드 환경과 융합해 세계 IT 시장을 주름잡을 것으로 예상됩니다.

이 책은 마이크로소프트에서 발표한 Windows Phone 7 운영체제를 기반으로 하는 스마트폰에서 애플리케이션을 제작하는 방법을 다루고 있으며 초보자들도 무난하게 배울 수 있도록 구성되었습니다. 7.5 망고 버전으로 업데이트되면서 추가된 내용들을 소개하고 이에 맞는 예제들도 제공하여 윈도우 폰 애플리케이션 개발에 친숙해 질 수 있도록 구성했습니다. 그리고 중급 이상의 개발자에게는 순서대로 책의 내용을 읽지 않더라도 해당 기술을 소개하는 목차의 내용을 읽고 바로 적용할 수 있습니다.

주요 특징을 말씀드리자면~

- Windows Phone 7.5 망고 버전의 내용을 다루고 있습니다.
- 윈도우 폰 애플리케이션 개발 시작 단계부터 판매 단계까지의 모든 과정을 다루고 있습니다.
- 윈도우 폰 개발과 관련하여 군더더기 설명이 없어 바로 익히고 실전에서 사용할 수 있으며 기능별로 목차를 구성하여 궁금한 부분을 바로 찾아볼 수 있습니다.
- 책에서 다룬 예제 소스 코드를 제공합니다.

:: 이 책의 구성
Intro. IT 삼국지
스마트폰의 등장 배경과 이로 인한 국내 업계의 변화, 그리고 앞으로 벌어질 글로벌 기업들의 경쟁에 대해 살펴봅니다.

Chapter 01. 스마트폰과 운영체제
스마트폰의 진화 과정과 주요 스마트폰의 특징 및 운영체제에 대해 분석해봅니다.

Chapter 02. 윈도우 폰 7 개요
윈도우 폰 7의 등장 배경과 메트로 디자인, 그리고 플랫폼 아키텍처와 주요 기능에 대해 알아봅니다.

Chapter 03. Hello Windows Phone 7
비주얼 스튜디오 2010을 이용해 윈도우 폰에서 동작하는 애플리케이션 예제를 구현하면서 기본 구조를 살펴봅니다.

Chapter 04. 프레임과 페이지
애플리케이션을 구성하는 페이지와 이들 페이지를 이동하는 방법, 페이지 방향 전환에 대해 알아봅니다.

Chapter 05. 기본 컨트롤
윈도우 폰 7 애플리케이션 개발을 위해 사용할 수 있는 여러 컨트롤들을 알아보고 예제를 통해 사용 방법을 실습해봅니다.

Chapter 06. 레이아웃과 테마
페이지의 레이아웃을 디자인할 때 사용할 수 있는 컨트롤과 운영체제에서 설정된 테마를 이용해 일관성 있는 인터페이스를 제공하는 방법을 알아봅니다.

Chapter 07. 애플리케이션 바
페이지에서 자주 사용될 수 있는 기능들을 아이콘과 텍스트 기반의 메뉴 항목으로 구성할 수 있는 애플리케이션 바에 대해 알아봅니다.

Chapter 08. Panorama와 Pivot 컨트롤
하나의 애플리케이션에서 많은 양의 콘텐츠를 사용자에게 제공할 수 있는 Panorama와 Pivot 컨트롤에 대해 알아봅니다.

Chapter 09. 데이터바인딩
데이터바인딩을 이용해 애플리케이션에서 데이터를 처리하는 방법과 MVVM 모델에 대해 알아본다.

Chapter 10. 격리 저장소
격리 저장소를 이용해 데이터를 읽는 방법과 격리 저장소 내 디렉토리 생성, 정보를 저장하는 방법을 알아본다.

Chapter 11. 그래픽
애플리케이션에 그래픽 요소를 추가하고 방향을 전환하는 방법과 그래픽 요소를 왜곡 및 변형시키는 방법을 알아봅니다.

Chapter 12. 실행 모델과 상태관리
애플리케이션의 실행 모델과 수명 주기, 그리고 상태 변화에 따라 정보를 저장하고 복원하는 법을 알아봅니다.

Chapter 13. 데이터베이스
LINQ to SQL을 이용해 로컬 데이터베이스와 oData 서비스를 이용하는 방법을 알아봅니다.

Chapter 14. Launcher와 Chooser
공용 작업을 실행할 수 있도록 하는 Launcher와 Chooser에 대해 알아봅니다.

Chapter 15. 가속도계와 터치
가속도계와 터치 정보를 이용해 애플리케이션의 화면을 변경하거나 장치 정보를 얻는 방법을 알아봅니다.

Chapter 16. 콤파스와 자이로센서
이번 Windows Phone 7.5 망고 버전에서 지원하는 콤파스와 자이로센서, 그리고 모션 센서에 대해 알아봅니다.

Chapter 17. 멀티미디어
미디어 라이브러리를 이용하는 방법과 음악 파일 재생, 사진 애플리케이션과의 연동, 동영상 플레이어 제작 등을 실습하면서 멀티미디어 애플리케이션 개발 방법을 알아봅니다.

Chapter 18. 위치 서비스
애플리케이션에서 현재 사용자가 있는 위치 정보를 수집하는 방법과 Bing Maps 관련 내용들을 알아봅니다.

Chapter 19. 카메라
카메라 장치로부터 영상 정보를 얻고 촬영, 오토포커스, 플래시 조정, 증강 현실 기술 등에 대해 알아봅니다.

Chapter 20. 웹 서비스
윈도우 폰에서 웹 서비스를 호출 및 이용하는 방법과 LINQ to XML 기술에 대해 알아봅니다.

Chapter 21. 푸시 알림 서비스
애플리케이션에 알림을 전달하는 방법, 애플리케이션과 마이크로소프트 푸시 알림(MSPN) 서비스 사이에 채널을 구성하고 알림 서비스를 이용하는 방법들을 알아봅니다.

Chapter 22. 멀티태스킹
이번 Windows Phone 7.5 망고 버전으로 업데이트되면서 가장 주목받는 부분이라 할 수 있는 멀티태스킹에 대해 알아봅니다.

Chapter 23. 마켓플레이스
마켓플레이스에 개발자 계정을 등록하는 과정과 애플리케이션 제출 및 판매, 평가판 제작 방법들을 알아봅니다.

Appendix. 윈도우 폰 개발자 도구



:: 대상 독자층
- 윈도우 폰 7 애플리케이션을 제작하고자 하는 독자
- 모바일 프로그래밍에 관심있는 독자
- C# 프로그래밍을 경험한 독자


:: 저자 소개
김순근(noenemy) | 한국마이크로소프트 책임연구원

경영학을 전공하였지만 어렸을 때 친구 집에 놀러가서 8비트 컴퓨터를 접했을 때의 짜릿함을 잊지 못해 지금까지 개발자의 길을 걸어오고 있다. 국내에 벤처붐이 일었던 2000년대 초에는 분산 환경에서 웹 프로그래밍을 하였고, 이후 안철수 연구소에서 5년 간 근무하면서 Win32 기반의 보안 애플리케이션을 개발하였다. 개발자 커뮤니티인 데브피아에서 ASP.NET 시샵으로 활동하였으며 ASP.NET과 VC++ 분야에서 MS MVP로 활동하였다. 현재는 한국마이크로소프트에서 오피스 제품 개발에 참여하고 있다.

• 저서 – About ASP.NET Programming, ASP.NET Programming Bible, 속전속결 C++언어, 알고리즘 입문
• 기고 및 감수 – Windows XP, 2003 서버, Exchange 서버 등 제품 한글화 기술 감수, 안철수연구소 보안컬럼 연재

추천의 말씀

윈도우 폰 앱을 실버라이트를 이용해서 개발할 수 있다는 것은 닷넷 개발자에게 매우 반가운 소식이다. 기존에 웹이나 실버라이트 애플리케이션을 개발하면서 익힌 기술을 그대로 사용할 수 있으니 말이다. 언제 어디서나 내 손 안에서 실행되는 프로그램. noenemy(놀래미)님의 책과 함께 이제 한번 만들어 보자.
김태영 | Taeyo.net 운영자, Microsoft MVP Insider

:: 목차
Intro. IT 삼국지
01. 스마트폰과 국내 업계 변화
02. 글로벌 기업들의 경쟁
2.1 마이크로소프트 - 데스크톱 운영체제의 최강자
2.2 구글 - 온라인 서비스의 최강자
2.3 애플 - 멀티미디어 기기와 컨텐츠의 최강자
2.4 스마트폰 시장에서의 진검 승부

Chapter 01. 스마트폰과 운영체제
01. 휴대폰
1.1 휴대폰의 역사
1.2 무선 통신망의 발전
1.3 휴대폰 기능의 발전
1.4 시장 점유율
02. 주요 스마트폰 운영체제의 비교
2.1 구글의 안드로이드
2.2 애플의 iOS
2.3 마이크로소프트 윈도우 모바일

Chapter 02. 윈도우 폰 7 개요
01. 윈도우 폰 7 둘러보기
1.1 새로운 변화의 필요성
1.2 외형 구성
1.3 코드네임 메트로
1.4 주요 기능
02. 윈도우 폰 7 플랫폼 아키텍처
2.1 하드웨어 계층
2.2 커널(Kernel) 계층
2.3 애플리케이션 인프라스트럭처 계층
2.4 애플리케이션 계층

Chapter 03. Hello Windows Phone 7
01. Hello Windows Phone 7
1.1 XAML로 구현하기
1.2 코드 비하인드로 구현하기
1.3 Visual Studio로 구현하기
02. 윈도우 폰 애플리케이션 둘러보기
2.1 XAP 패키지
2.2 주요 구성 파일들

Chapter 04. 프레임과 페이지
01. 프레임과 페이지 개요
1.1 프레임과 페이지
1.2 시스템 트레이와 애플리케이션 바
02. 페이지 이동하기
2.1 Navigation 네임스페이스
2.2 페이지 이동하기
2.3 페이지 이동시 데이터 전달하기
2.4 뒤로가기 버튼에 대한 처리
03. 페이지 방향 변경하기


Chapter 05. 기본 컨트롤
01. TextBlock 컨트롤
02. TextBox 컨트롤
03. PasswordBox 컨트롤
04. Button 컨트롤
05. CheckBox 컨트롤
06. RadioButton 컨트롤
07. HyperlinkButton 컨트롤
08. Image 컨트롤
09. Slider 컨트롤
10. ProgressBar 컨트롤
11. ListBox 컨트롤
12. ScrollViewer 컨트롤
13. WebBrowser 컨트롤

Chapter 06. 레이아웃과 테마
01. 레이아웃 컨트롤
1.1 Border 컨트롤
1.2 Canvas 컨트롤
1.3 StackPanel 컨트롤
1.4 Grid 컨트롤
1.5 페이지 방향과 레이아웃
02. 테마
2.1 테마 관련 리소스
2.2 테마 적용 실습하기

Chapter 07. 애플리케이션 바
01. 애플리케이션 바
1.1 애플리케이션 바 둘러보기
1.2 고려 사항
02. 예제 작성하기

Chapter 08. Panorama와 Pivot 컨트롤
01. Panorama 컨트롤
1.1 Panorama 애플리케이션
1.2 Panorama 컨트롤
1.3 PanoramaItem 컨트롤
1.4 실습하기
02. Pivot 컨트롤
2.1 Pivot 애플리케이션의 구조
2.2 Pivot 컨트롤과 PivotItem 컨트롤
2.3 실습하기

Chapter 09. 데이터바인딩
01. 데이터바인딩이란?
1.1 바인딩 모드
1.2 INotifyPropertyChanged 인터페이스
1.3 XAML에서 바인딩하기
1.4 프로그래밍 코드에서 바인딩하기
02. 엘리먼트 바인딩
2.1 실습하기
2.2 Converter 이용하기
03. 프로퍼티 바인딩
3.1 실습하기
04. 리스트 데이터바인딩
4.1 실습하기
05. MVVM과 데이터바인딩
5.1 MVVM 구성요소
5.2 MVVM 실습하기

Chapter 10. 격리 저장소
01. 격리 저장소 개요
1.1 System.IO.IsolatedStorage 네임스페이스
1.2 격리 저장소 사용 방법
02. 파일처리 예제 작성하기
03. 환경 설정 예제 작성하기

Chapter 11. 그래픽
01. 그래픽 요소들
1.1 Rectangle 클래스
1.2 Ellipse 클래스
1.3 Line 클래스
1.4 Path 클래스
1.5 Polygon 클래스
1.6 Polyline 클래스
02. 브러시
2.1 단색 브러시
2.2 그레이디언트 브러시
2.3 이미지 브러시
03. 변형(Transform)
3.1 크기 변형(Scale Transform)
3.2 회전 변형(Rotate Transform)
3.3 왜곡 변형(Skew Transform)
3.4 이동 변형(Translate Transform)

Chapter 12. 실행 모델과 상태관리
01. 애플리케이션 실행 모델
1.1 애플리케이션 수명 주기
1.2 수명 주기 예제
1.3 비활성화 시나리오
02. 페이지 상태 관리
2.1 예제 작성하기
03. 애플리케이션 상태 관리
3.1 저장소의 선택
3.2 예제 작성하기
04. 유휴 감지
4.1 사용자 유휴 감지
4.2 애플리케이션 유휴 감지
4.3 예제 작성하기

Chapter 13. 데이터베이스
01. LINQ to SQL
1.1 LINQ to SQL 개요
1.2 DataContext 정의하기
1.3 LINQ to SQL 사용법
1.4 예제 작성하기
02. oData 클라이언트
2.1 oData 개요
2.2 oData 클라이언트 사용하기
2.3 예제 작성하기

Chapter 14. Launcher와 Chooser
01. Launcher와 Chooser
1.1 Launcher
1.2 Chooser
1.3 에뮬레이터 지원 환경
02. Launcher 사용하기
2.1 EmailComposeTask
2.2 MarketplaceDetailTask
2.3 MarketplaceHubTask
2.4 MarketplaceReviewTask
2.5 MarketplaceSearchTask
2.6 MediaPlayerLauncher
2.7 PhoneCallTask
2.8 SearchTask
2.9 SmsComposeTask
2.10 WebBrowserTask
2.11 BingMapsTask
2.12 BingMapsDerectionsTask
03. Chooser 사용하기
3.1 CameraCaptureTask
3.2 EmailAddressChooserTask
3.3 PhoneNumberChooserTask
3.4 PhotoChooserTask
3.5 SaveEmailAddressTask
3.6 SavePhoneNumberTask
3.7 AddressChooserTask
3.8 GameInviteTask

Chapter 15. 가속도계와 터치
01. 가속도계
1.1 Microsoft.Devices.Sensors 네임스페이스
1.2 Accelerometer 클래스
1.3 실습 1 : 좌표 읽어오기
1.4 실습 2 : 화면 내 이미지 이동하기
02. 터치
2.1 터치 제스처의 종류
2.2 Touch API 이용하기
2.3 Manipulation 이벤트 이용하기
03. 장치 정보 얻기
3.1 장치 확장 속성
3.2 예제 작성하기

Chapter 16. 콤파스와 자이로센서
01. 콤파스 센서
1.1 콤파스 센서 개요
1.2 Compass 클래스
1.3 예제 작성하기
02. 자이로스코프 센서
2.1 자이로스코프 센서 개요
2.2 Gyroscope 클래스
2.3 예제 작성하기
03. 모션 센서
3.1 모션 센서 개요
3.2 Motion 클래스
3.3 예제 작성하기

Chapter 17. 멀티미디어
01. Microsoft.Xna.Framework.Media 네임스페이스
1.1 MediaLibrary 클래스
1.2 MediaPlayer 클래스
02. 음악 플레이어 제작하기
2.1 Songs 컬렉션 얻기
2.2 음악 재생하기
03. Pictures 이용하기
3.1 extras 메뉴 연동하기
3.2 share 메뉴 연동하기
04. 동영상 플레이어 제작하기
4.1 MediaElement 컨트롤
4.2 SimplePlayer 만들기

Chapter 18. 위치 서비스
01. 위치 서비스
1.1 위치 서비스 개요
1.2 주요 고려 사항들
02. System.Device.Location 네임스페이스
2.1 GeoCoordinateWatcher 클래스
2.2 GeoPositionAccuracy 열거형
2.3 GeoPositionStatus 열거형
2.4 예제 작성하기
03. Bing Maps 컨트롤 이용하기
3.1 Bing Maps 컨트롤
3.2 예제 작성하기
3.3 Bing Maps 키 발급 받기

Chapter 19. 카메라
01. 카메라 API
1.1 Camera 클래스
1.2 PhotoCamera 클래스
1.3 CameraButtons 이벤트
02. 예제 작성하기
2.1 화면 구성 및 카메라 초기화
2.2 포커스 설정 및 사진 촬영하기
2.3 플래시 모드 변경하기
2.4 사진 해상도 설정하기
2.5 하드웨어 버튼 이용하기
2.6 증강현실을 이용한 오버레이 구현하기

Chapter 20. 웹 서비스
01. 웹 서비스 개요
1.1 웹 서비스 개요
1.2 네트워크 프로그래밍
1.3 XML 데이터 이용하기
02. Open API 이용하기
2.1 Open API 개요
2.2 네이버 실시간 검색 순위 API
2.3 예제 만들기
03. RSS Reader 만들기
3.1 RSS
3.2 예제 만들기

Chapter 21. 푸시 알림 서비스
01. 푸시 알림 서비스
1.1 푸시 알림 원리
1.2 푸시 알림의 종류
1.3 푸시 알림 서비스 프로토콜
1.4 HttpNotificationChannel 클래스
02. 푸시 알림 예제 만들기
2.1 웹 서비스 구성하기
2.2 푸시 알림 보내기
2.3 푸시 알림 받기
03. 추가 고려사항들
3.1 알림 채널 설정하기
3.2 응답 코드 및 문제 해결 방법
3.3 전원 상태와 푸시 알림
3.4 타일 스케쥴 설정하기

Chapter 22. 멀티태스킹
01. 멀티태스킹 개요
02. 백그라운드 오디오
2.1 Microsoft.Phone.BackgroundAudio 네임스페이스
2.2 예제 작성하기
03. 백그라운드 파일 전송
3.1 백그라운드 전송 API
3.2 Microsoft.Phone.BackgroundTransfer 네임스페이스
3.3 예제 작성하기

Chapter 23. 마켓플레이스
01. 윈도우 폰 마켓플레이스
02. App Hub 멤버쉽
2.1 App Hub 관련 주요 정책
2.2 App Hub 멤버쉽 가입하기
03. 개발용 장치 등록하기
3.1 Zune 소프트웨어와 싱크 관계 설정하기
3.2 App Hub 사이트에 장치 등록하기
04. 애플리케이션 제출하기
4.1 사전 확인 사항
4.2 애플리케이션 제출하기
05. 평가판 애플리케이션
5.1 평가판 애플리케이션
5.2 실습하기

Appendix. 윈도우 폰 개발자 도구
01. 다운로드 및 설치하기
02. 제품 등록하기
03. 프로젝트 템플릿 선택하기

Windows Phone 개발툴 CTP 버전이 MIX10 행사에 맞춰서 3월에 공개 되었었는데, 4월 말에 April Refresh 버전으로 업데이트 되었습니다.

현재 Windows Phone 개발자 포럼 사이트에 공개된 샘플 프로젝트의 상당수가 3월에 최초 공개된 개발툴 버전으로 작성되었기 때문에 April Refresh 버전의 Visual Studio에서는 빌드시 오류가 발생할 수 있습니다. SDK의 클래스 구조가 상당 부분 변경되었기 때문입니다.

이 중에서 흥미로운 것은 WP7에서 실행되는 app가 시스템의 어떠한 리소스에 접근할 수 있는가에 대해서 capability 기반의 보안모델을 새로 적용한 것이 흥미롭습니다. (완전 새로운 개념은 아닙니다. 이미 안드로이드 마켓에서는 이러한 모델을 사용하고 있으니까요.)


오늘 기존에 작성된 WP7용 샘플 프로젝트를 VSWP April Refresh 버전에서 열었더니 다음과 같은 안내 메시지가 나오길래 관련 내용을 찾아보다가 간단히 글을 써볼까 합니다.

• Networking : App에서 네트워크 자원을 사용할 수 있는지
• Location : App에서 위치 정보를 위한 GPS 자원을 사용할 수 있는지
• Microphone : App에서 폰의 마이크 자원을 사용할 수 있는지
• Medialib : App에서 폰 내의 음악, 동영상 같은 미디어 라이브러리에 접근할 수 있는지(Zune library 이겠죠)
• Gamer services : App에서 게임을 위한 XBOX live 서비스에 접근할 수 있는지
• Phone dialer : App에서 전화걸기 기능을 사용할 수 있는지
• Push Notification : App에서 푸시 알림을 받을 수 있는지
• Web Browser Component : App에서 웹 브라우저 기능을 사용할 수 있는지

따라서 App 개발시에 해당 app에서 사용하는 리소스에 대해서만 매니페스트에 지정하시기 바랍니다.

아래 문서에서도 이 내용에 대해서 언급하고 있으니 참고하시기 바랍니다.
http://blogs.msdn.com/b/jaimer/archive/2010/04/30/windows-phone-capabilities-security-model.aspx

 

Unclassified Program은 driver의 기본적인 안정성 테스트를 진행하는 것으로 해당 driver의 기능(functionality)를 인증하는 프로그램이 아닙니다.

만약 Windows Logo 취득보다는 driver signing만을 위한 목적으로 DTM test를 진행한다면 Unclassified program을 이용하는 것도 좋은 방법이 될 수 있습니다.

The Unclassified Program does not validate device and driver functionality. Therefore, devices and drivers that are submitted for driver signature under the Unclassified Program are not eligible to use either the Basic or Premium logo.

You can use the Unclassified Program to obtain a signature for a driver even if a Basic or
Premium logo program is defined for the device or driver category. However, such signed drivers and devices will not qualify to use the logo. Neither can you use such drivers and devices in a system that you are submitting for a Premium logo.

For further details about the Unclassified Program, refer to Policy-0021 on the LogoPoint tool. The Device Fundamental requirements are also available on LogoPoint.

(출처: Unclassified Signature Program http://www.microsoft.com/whdc/winlogo/drvsign/dqs.mspx)

다음은 submission 가격에 대한 정책입니다.

Unclassified program도 다른 WLK submission과 동일하게 1회에 $250의 비용이 소요됩니다.

Billing Policies

Updated: August 21, 2006

Authorized Testing Fees for Devices and Systems

This section provides the WHQL fee schedule and payment instructions for WHQL testing fees.

Fee Schedule

Fees are payable only in U.S. funds by check or wire transfer.  For submissions $750.00 (U.S.), or less, credit cards are accepted.

Testing fees for previous platform submissions are charged by the Windows operating system family. There will be no additional fee for additional platforms submitted under a single Windows family.

Note: The Windows Vista Premium logo also covers the logo for Windows Vista Basic. Logs for Windows Vista Basic do not need to be included if a Windows Vista Premium submission is made.

(1): Includes Windows Vista all operating systems, Windows XP all operating systems, Windows 2003 all operating systems.  $250.00 fee per operating system family submitted for testing.

(2): $100.00 per submission regardless of the number of operating systems submitted.

• Input
• UI rendering
• Media
• Deep Zoom
• Controls
• Layout
• Data binding
• Isolated storage
• Networking(HttpWebRequest, WebClient)
• XAML
• XAP packaging
• XML serializtion
• WCF(Windows Communication Foundation)

• Gesture-aware controls (tab, flick 등을 인식)
• Manipulation events
• TextBox 컨트롤에서 SIP(Software Input Panel) 지원 (화상키보드)

현재 Silverlight 4 RC 버전이 소개되어 있는데 향후 Windows Phone 7에서 일부 기능이 제공될 가능성이 있습니다.

보다 자세한 내용은 다음 문서를 참고하시기 바랍니다.

출처 : http://msdn.microsoft.com/en-us/library/ff426931(v=VS.96).aspx

지난 3월에 Las Vegas에서 있었던 MIX10 컨퍼런스(http://live.visitmix.com/)에서 화두는 그동안 베일에 가려져 있던 Windows Phone 7에 대한 것이었습니다. 그 만큼이나 Windows Phone 7 App 개발에 대한 많은 세션이 진행되었고 참석자들의 관심도 매우 많았다고 합니다.

실제 제품은 빠르면 북미 시장에 올해 가을 정도에 출시될 것으로 보입니다. MIX10 행사장에서는 3개의 prototype 단말기가 선보였다고 하죠.

Windows Phone 7은 시작화면부터 현재 6.5 버전까지 나와있는 Windows Mobile과 전혀 다릅니다. 기존의 Windows Mobile이 Windows PC 환경을 모바일 장치에서 구현하려는 컨셉이었던 것에 반해 Windows Phone 7은 일반 사용자에게 친숙하게 개발하기 위해 출발점부터 다르게 시작했다고 할 수 있습니다.

기존 Windows Mobile과의 하위 호환성을 과감히 버리면서 까지 full change를 하게 된 것은 아이폰의 보급화에 따른 IT 환경의 변화, 사용자들의 요구사항이 변화한 것을 기존의 Windows Mobile 컨셉으로는 더 이상 충족시킬 수 없다는 위기감을 느꼈기 때문이라고 생각됩니다.

[그림] Windows Phone 7의 시작 화면

운영체제의 변경과 함께 Windows Phone 7에서 실행되는 애플리케이션의 환경도 완전히 달라졌습니다. 가장 큰 특징은 Managed Code만 실행된다는 것입니다. 즉, Windows Phone 7용 애플리케이션을 개발하려면 VC++과 같은 unmanaged code가 아니라 C#과 같은 managed code를 이용해서 작성해야 한다는 의미입니다.

현재 CTP 버전으로 공개된 Visual Studio 2010 CTP for Windows Phone이나 Expression Blend Beta 4에서는 C# 언어만 지원하고 있습니다. 향후에는 VB.NET 과 같은 다른 .NET 언어도 지원될 것으로 예상됩니다.

Windows Phone 7용 애플리케이션은 다음과 같이 Silverlight과 XNA라는 큰 두 개의 축으로 구분됩니다.

[그림] Windows Phone App Platform

Application을 개발하려면 이 둘 중에서 어떠한 기술을 이용해서 개발할 것인지를 먼저 선택해야 합니다. 이 둘은 다음과 같은 차이점을 가지고 있습니다.

Silverlight – 일반 애플리케이션을 위한 개발 모델. 기존에 Win Form application을 개발하는 방법과 동일하게 개발이 가능합니다. Windows Phone App을 위해 제공되는 기본 컨트롤(TextBox, Button, ProgressBar 등)을 이용해서 빠른 개발이 가능하며, Event Driven 방식으로 동작합니다.

XNA - XBOX와 Windows 게임 개발을 위한 플랫폼입니다. 기존의 DirectX를 이용한 개발 방법의 연장선에 있습니다. Silverlight이 event driven 방식이라면, XNA는 화면 frame에 기반한 개발방법입니다. 즉 예를 들어 30fps라면 1초에 30장의 이미지가 연속적으로 보여지는 것을 의미하는데, XNA는 각 시점에 보여질 프레임 이미지를 직접 구성할 수 있습니다.

즉, 일반 애플리케이션을 개발하려면 Silverlight을 이용해서 개발하고, 게임 개발을 하려면 XNA를 이용하시면 됩니다.

기존에 WPF나 Silverlight 개발에 익숙하신 분들은 바로 Windows Phone 7 애플리케이션 개발을 시작하실 수 있습니다. XNA를 이용해서 게임 개발을 하셨던 분들도 Windows Phone 7 게임을 만드시는데 어려움이 없을 겁니다.

현재 IT 업계들이 각자 3 스크린 모델(TV, PC, Mobile에서 모두 동일한 사용자 경험을 제공)을 구축하려고 노력하고 있습니다. Windows Phone 7에서 Silverlight과 XNA를 중심 축으로 선택했다는 것은 향후 TV와 PC 환경에서도 동일한 방향으로 나아가지 않을까라고 조심스럽게 예상 해볼 수 있습니다.

WP7 개발시에 필요한 개발 도구들입니다.

먼저 Visual Studio 2010 Express 버전 및 Silverlight, XNA 4.0, 그리고 WP7 emulator입니다. MIX10 행사에 공개되었죠.

Windows Phone Developer Tools CTP (VS2010 Express + Emulator + Silverlight + XNA 4.0 for Phone)
http://www.microsoft.com/downloads/details.aspx?FamilyId=2338b5d1-79d8-46af-b828-380b0f854203&displaylang=en

다음은 Silverlight 애플리케이션을 디자인하는데 최적화된 도구인 Expression Blend 4 beta for Windows Phone 입니다.

Microsoft Expression Blend 4 Beta
http://www.microsoft.com/downloads/details.aspx?FamilyID=6f014e07-0053-4aca-84a7-cd82f9aa989f&displaylang=en

Microsoft Expression Blend Add-in Preview for Windows Phone
http://www.microsoft.com/downloads/details.aspx?FamilyID=47f5c718-9dec-4557-9687-619c0fdd3d4f&displaylang=en

Microsoft Expression Blend SDK Preview for Windows Phone
http://www.microsoft.com/downloads/details.aspx?FamilyID=86370108-4c14-42ee-8855-226e5dd9b85b&displaylang=en

Preview에 Beta 버전이다 보니 실행 중에 비정상 종료되거나 오동작을 하는 경우가 좀 있습니다. 그리고 현재 공개되어 있는 SDK도 앞으로 계속 변경되거나 추가될 가능성이 있습니다만, WP7가 어떤 모습으로 출시될지, 그리고 어떠한 방법으로 애플리케이션을 개발해야 될지를 먼저 볼 수 있는 좋은 기회이므로 관심 있는 분들은 설치해서 둘러 보시기 바랍니다.

그리고 다음은 관련 자료를 얻을 수 있는 사이트들입니다.

Windows Phone 7 시리즈 공식 사이트
http://www.windowsphone7series.com/

Expression 공식 사이트
http://www.microsoft.com/expression

Silverlight 공식 사이트
http://www.silverlight.net/

XNA Developer Center
http://msdn.microsoft.com/en-us/aa937791.aspx

XNA Creators Club Online
http://creators.xna.com/en-US/

Charles Petzolds’s Programming WP7 Series free ebook
http://www.charlespetzold.com/phone/index.html

Zune HD는 애플 IPod touch에 대항하기 위해서 2009년 가을에 출시된 마이크로소프트의 full touch multi media player 입니다.

XNA game studio 3.0 버전부터 Zune 용 소프트웨어를 XNA를 이용해서 개발 할 수 있게 되었는데, 최근에 출시된 Zune HD용 애플리케이션을 작성하려면 XNA 3.1 버전을 설치해야 합니다.

여기서는 Zune HD용 애플리케이션을 개발하기 위한 환경을 구축하는 과정을 간략히 정리하고자 합니다.

우선 XNA 애플리케이션을 개발하기 위해서 필요한 개발 시스템의 최소 요구 사항은 다음과 같습니다.

개발 시스템 요구 사항

• 운영 체제: Windows Vista 서비스 팩 1, Windows XP 서비스 팩 3
• 개발 도구: Visual C# 2008 Express Edition 또는 Visual Studio 2008(본 문서는 Visual Studio 2008을 기준으로 작성됨)
• 하드웨어: DirectX 9.0c와 Shader 모델 1.1을 지원하는 그래픽 카드(Shader 모델 2.0 권장), Zune HD 장치 (펌웨어 3.0 이상)

위와 같은 장비에 다음과 같은 순서로 필요한 개발 환경을 구축합니다.

• XNA Game Studio 3.1 버전 설치하기
  http://www.microsoft.com/downloads/details.aspx?FamilyID=80782277-D584-42D2-8024-893FCD9D3E82&displaylang=en
• XNA Game Studio 3.1 Zune Extensions 설치하기
  http://www.microsoft.com/downloads/details.aspx?FamilyID=48f7ba37-8ba7-4d16-8873-0b7f83ef77f9&displaylang=en
• 위 과정을 마쳤으면 설치된 폴더에서 XNA Game Studio Device Center를 실행합니다.
• Add Device를 선택하고, 개발용 Zune HD 장치를 추가합니다.
• 만약 Zune Software가 실행 중이라면 이를 종료합니다.
• Visual Studio 2008에서 XNA용 애플리케이션을 개발하고 F5 키를 누르면, Zune HD 장치로 배포되고 라이브 디버깅이 가능합니다.

아마 향후 펌웨어가 업데이트 되면 Zune HD에서 Silverlight으로 개발한 애플리케이션도 지원하지 않을까라는 추측을 해봅니다만, 아직 이에 대한 공식적인 발표가 없는 상태입니다. 어쨌든 현재로서는 Zune HD용 애플리케이션을 개발하려면 XNA와 C#을 이용해서 개발할 수 밖에 없는 상황입니다.

그룹 정책 편집기(Gpedit.msc)를 이용하면 컴퓨터와 사용자의 작업 환경에 대한 여러가지 설정이 가능합니다.

예를 들면 패스워드의 길이나 복잡도, 변경 주기 같은 내용을 설정함으로써 보다 사용자가 보안 등급이 높은 패스워드를 사용할 수 있도록 할 수 있습니다. 또는 특정 사용자가 제어판에서 정해진 항목 외에 설정을 변경함으로써 발생할 수 있는 문제를 방지하기 위해서 특정 제어판 항목을 비활성화 시킨다든지 등의 수많은 Windows policy가 제공되고 있습니다.

이는 주로 네트워크 관리자에 의해서 해당 망 내에 존재하는 컴퓨터들의 유지 보수 및 관리를 쉽게 하기 위해서 Active Directory와 연동되어 관리 목적으로 많이 사용됩니다.

[그림] gpedit.msc 실행화면

가끔 gpedit.msc로 설정되는 windows policy가 해당 시스템의 어떠한 registry 설정과 관련이 있는지 확인할 필요가 있습니다.

주로 ProcMon 같은 툴을 이용해서 policy 변경시에 어떠한 registry 항목이 변경되는지 모니터링을 해서 찾았었는데, 다음 문서에서 이에 대한 내용이 정리되어 있음을 확인할 수 있었습니다. 아래 다운로드 페이지에서 확인하고 싶은 운영체제의 버전에 해당하는 엑셀 파일을 다운로드 하셔서 policy 항목을 찾으면 이에 대한 정보를 확인할 수 있습니다.

Group Policy Settings Reference for Windows and Windows Server
http://www.microsoft.com/downloads/details.aspx?FamilyID=18c90c80-8b0a-4906-a4f5-ff24cc2030fb&displaylang=en

XNA는 XBOX와 Windows용 게임 애플리케이션을 .net 기반으로 통합해서 개발할 수 있도록 제공되는 framework 입니다. 2008년 10월에 Version 3.0이 출시되면서 휴대용 멀티미디어 장치인 Zune 용 애플리케이션도 XNA를 이용해서 개발 할 수 있게 되었습니다.

이를 이용해서 개발된 애플리케이션은 XBOX Live Marketplace에 업로드해서 유료로 일반 사용자에게 판매할 수 있고, 이를 통해 수익을 올릴 수 있습니다. (Apple의 AppStore와 유사한 개념입니다.)

가장 최근에 출시된 3.1 버전의 경우 Avartar, Video Playback 등의 추가 기능을 포함하고 있으며, 3.1 extension for Zune HD를 설치하면 Visual Studio 2008을 이용해서 Zune HD용 애플리케이션도 개발이 가능합니다. 앞으로 계속해서 새로운 기능들이 추가될 예정으로 있다고 합니다.

다음은 GDC(Game Developer Conference) 2009에서 소개된 세션 자료입니다. 참고하시기 바랍니다.

GDC 2009 : XNA Game Studio Program Overview
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ced54340-d2ad-44bd-8a77-22339ed86e08

GDC 2009: XNA Game Studio XDK Extensions, Certification, and You
http://www.microsoft.com/downloads/details.aspx?FamilyID=964F0247-9202-4CC0-893D-5519F30C1CCB&displayLang=en

그리고, 다음은 XNA 개발자 센터 사이트입니다. 관련 커뮤니티나 블로그에서 정보를 얻을 수 있습니다.

XNA Developer Center
http://msdn.microsoft.com/en-us/aa937791.aspx

Windows 운영체제는 thread라는 최소 실행단위에 의해서 프로그램이 실행되는데, 여러 개의 thread가 각각 교대로 CPU에 의해서 매우 빠른 속도로 실행되면서 마치 동시에 여러 응용 프로그램이 함께 실행되는 것과 같은 결과를 보여주고 있습니다. Thread Scheduling이란 이렇게 시스템에서 실행 중인 여러 개의 thread 간에 어떠한 thread를 실행할 지, 그리고 다음에는 어떠한 thread를 실행할 지에 대해서 결정하는 매카니즘입니다. 오늘은 thread scheduling이 발생하는 유형에 대해서 간단히 알아보도록 하겠습니다.

(원래 내용은 Windows Internals 6장의 내용을 바탕으로 작성되었으며 그림은http://www.microsoft.com/mspress/books/sampchap/4354c.aspx에서 발췌하였습니다.)

1. Voluntary Switch (자발적인 교체)

아래 그림처럼 현재 Priority 19로 running 상태에 있던 thread가 스스로 wait 상태로 들어가면서 Priority 17에서 ready 상태에 있던 thread로 교체되는 시나리오를 생각해 볼 수 있습니다. WaitForSingleObject나 WaitForMultipleObjects와 같은 함수를 호출하면서 어떠한 object의 상태가 변경될 때까지 wait 상태로 들어감으로써 다른 thread에게 실행 권한을 넘겨주는 경우입니다.

2. Preemption (선점)

이는 현재 running 상태에 있던 thread가 다른 thread에 의해서 밀려나는 것을 의미합니다. 더 높은 우선순위를 가지고 Wait 상태에 있던 thread가 깨어나거나, 다른 thread의 우선 순위가 오르거나 또는 현재 thread의 우선순위가 낮아짐으로써 다른 thread에게 선점 당하는 경우에 해당합니다.

아래 그림은 Priority 16으로 실행 중이던 thread가 Wait 상태에서 깨어난 Priority 18의 thread에게 실행 제어권을 넘겨주고 다시 waiting queue에 들어가는 경우를 보여주고 있습니다.

3. Quantum End (퀀텀 만료)

Quantum이란 한 thread가 running 상태로 실행될 수 있는 기간으로 일정 시간 동안 CPU에 의해서 실행이 되면 다른 thread가 실행될 수 있도록 스스로 제어권을 물려주게 됩니다.

이 Quantum의 길이는 운영체제마다 다릅니다. 예를 들어 Winodws 2000 Pro와 Windows XP는 기본값으로 2 clock을, Windows Server system에서는 12 clock을 부여합니다. 이는 서버 장비의 경우 Quantum을 조금 더 길게 부여함으로써 실행 중이던 서비스를 처리할 수 있는 시간을 충분히 주고 성능을 높이려는 의도입니다. 대신 일반 사용자 PC의 경우 사용자와 키보드, 마우스를 이용해서 interaction이 많으므로 보다 짧은 quantum을 부여합니다.

4. Termination (종료)

ExitThread가 호출되거나 TerminateThread에 의해서 강제로 종료되는 경우에 해당합니다.

지난 주 전 세계적으로 Windows 7이 정식 출시됨에 따라 기존의 Windows Vista 출시와는 달리 시장에서 좋은 평가를 받고 있고, IT 전반적으로 큰 이슈가 되고 있는 것 같습니다. 이에 따라 인터넷 상에서 연일 Windows 7에 대한 각종 정보를 쉽게 찾아볼 수 있게 되었습니다.

그 중에 UCC 동영상 중에 관심을 끄는 것이 Windows 7의 부팅 속도가 얼마나 빠른지에 대해서 보여주는 것이었습니다. 자세한 시스템 사양은 모르겠지만 시스템의 전원버튼을 누른 후에 10 여 초 내에 부팅이 완료되는 모습이었습니다. 물론 운영체제를 설치한 후에 이런 저런 프로그램이나 서비스가 등록되면 조금씩 부팅 속도가 늦어지겠지만 기존 운영체제에 비해서 부팅 속도가 눈에 띄게 빨라진 것이 사실입니다.

요즘은 가전제품들도 전원을 키면 실제 기능이 동작하는데 시간이 많이 걸리는 경우가 있는데, 하드웨어와 운영체제의 발달에 따라 컴퓨터의 부팅 속도가 곧 가전제품 만큼이나 빨라질지도 모르겠습니다.

Windows 7에서는 기존 운영체제와 비교했을 때 부팅 속도를 향상 시키기 위해 다음과 같이 크게 3가지 부분을 변경한 것으로 알려져 있습니다.

1. parallelizing device enumeration

부팅 시점에 많은 시간이 소요되는 부분이 시스템에 부착되어 있는 device들을 enumeration하고 이에 대한 device tree를 구성하는 과정입니다. 그런데 이러한 장치들이 시스템 부팅 과정에 있어서는 그만큼의 시간을 소요할 정도로 중요한 부분이 아닙니다. 이러한 enumeration 작업은 PnP의 queue에 담겨진 후에 수행되는데, 이때 이 작업을 비동기(asynchronous) 처리하도록 속성을 지정함으로써 다른 작업과 병렬로 처리될 수 있도록 변경되었습니다.

2. driver re-initialization

드라이버 파일이 메모리에 로드되면 해당 드라이버의 시작지점인 DriverEntry 함수가 호출됩니다. 이 함수 내에서는 PnP manager에 IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_READ 등과 같은 처리를 수행할 함수를 등록하는 작업을 주로 수행합니다. 문제는 이러한 작업이 부팅을 수행하는 중에는 상대적으로 우선순위가 낮다는 것입니다. 이러한 이유로 Windows 7에서는 DriverEntry 함수가 호출되는 시점이 system device의 enumeratin이 완료된 이후에 callback 되도록 queuing 되도록 변경되었습니다.

3. Session 0 initialization

Windows Vista에서부터 Service 프로그램은 session 0라는 별도의 세션으로 분리하여 악성코드에 의해서 SYSTEM 권한을 hijacking 당하는 것을 막고 보안 위험성을 줄이게 되었습니다. 시스템에 등록된 여러 서비스들은 Services.exe에 의해서 서비스 프로그램 간의 종속성을 확인한 다음에 어떠한 순서로  실행될 지가 결정되게 됩니다. 즉, 특정 서비스가 먼저 실행된 후에야 실행될 수 있는 종속성이 있기 때문에 이로 인해서 부팅 속도에 어느 정도 영향을 미치게 됩니다. Windows 7에서는 서비스들이 모두 시작 완료되는 시간을 단축시키기 위해서 Session 0의 초기화 과정을 조금 일찍 시작합니다. Windows Vista에서는 device tree가 만들어진 이후에 이 과정이 시작되지만, Windows 7에서는 그 이전에 실행되어 device enumeration과 병렬로 작업이 진행됩니다.

이상 Windows 7에서 부팅 속도를 빠르게 하기 위해서 변경된 주요 3가지 내용을 알아보았습니다. 전체적으로 큰 변화보다는 부팅 속도를 빠르게 하기 위해서 각 부팅 단계별로 어느 작업이 가장 중요한지 우선순위를 정하고 중점적으로 진행해야 하는 작업을 정하고 해당 작업에 집중할 수 있도록 조절하였다고 보시면 되겠습니다.

Windows 7에서 사용자 UI 관련해서 많은 부분들이 개선되거나 추가 되었는데, 그 중에 하나가 바탕화면 이미지가 일정 시간 단위로 계속 변경되는 슬라이드 쇼 기능입니다. 바탕화면은 사용자가 컴퓨터를 사용할 때 가장 자주 접하게 되는 화면으로 각자 좋아하는 이미지를 이용해서 바탕화면을 꾸며서 사용하는 경우가 많습니다. 하지만 매번 보는 바탕화면이 지겨울 수도 있기 때문에 슬라이드쇼 기능을 이용해서 다양하게 변화하는 바탕화면을 즐길 수 있게 되었습니다.

이 기술은 기존에 바탕화면 테마에 추가된 기능으로서 테마 파일(.theme)에 [Slideshow]라는 섹션에 관련 정보를 추가함으로써 간단히 구현할 수 있습니다.

자세한 내용은 아래 문서를 참고하시기 바랍니다.

Creating and Installing Theme Files

http://msdn.microsoft.com/en-us/library/bb773190(VS.85).aspx

1. Slideshow section의 주요 내용

다음은 [Slideshow] section의 세부 속성에 대한 내용입니다.

[Slideshow] Section

Windows 7 and later.

Note  This section is optional. If you do not include this section in your .theme file, the system uses the desktop background image specified in the [Control Panel\Desktop] section. If you include this section, you must specify slide show settings here.

Your theme's background can be a slide show either of images stored locally or of images served by an RSS feed. The [Slideshow] section of the file contains the following attributes:

The following examples show how a .theme file specifies the slide show to include a set of images stored locally.

Ex1) 특정 폴더 내의 모든 이미지를 슬라이드 쇼 하는 방법에 대한 예

[Slideshow]
Interval=1800000
Shuffle=1
ImagesRootPath=%SystemRoot%\Web\Wallpaper

Ex2) 특정 폴더 내에서 특정 이미지 리스트에 대해서 슬라이드 쇼 하는 방법에 대한 예

[Slideshow]
Interval=1800000
Shuffle=1
ImagesRootPath=%ProgramFiles%\fabrikam\wallpaper
Item0Path=%ProgramFiles%\fabrikam\wallpaper\ocean.jpg
Item1Path=%ProgramFiles%\fabrikam\wallpaper\mountain.jpg
Item2Path=%ProgramFiles%\fabrikam\wallpaper\river.jpg

2. RSS feed 이용하기

특히 로컬디스크에 있는 이미지 뿐만 아니라 RSS feed를 이용해서 웹 상에서 존재하는 이미지를 슬라이드 쇼에 이용할 수 있습니다.

다음은 슬라이드 쇼에 사용할 수 있는 RSS feed의 한 예입니다.

RSS feed : http://specials.msn.com/RSSFeed.aspx?cp-documentid=5484790

Ex3) RSS feed를 이용해서 background image를 변경하는 테마를 만드는 방법에 대한 예

The following example is a template for a .theme file that creates a desktop background slide show using images from an RSS feed. Follow these steps to customize the template:

1. Copy the following example and paste it into a text editor.

2. Replace {themename} with the name you want to appear in the Personalization Control Panel themes gallery.

3. Replace {rssfeedurl} with the full path to a compatible RSS feed.

4. Save the changes as a file with the ".theme" extension.

[Theme]
DisplayName={themename}

[Slideshow]
Interval=1800000
Shuffle=1
RssFeed={rssfeedurl}
// 이하 생략

원래 바탕화면 배경이미지에 대한 것은 HKCU\Control Panel\Desktop의 wallpaper(REG_SZ) 항목에 이미지파일의 경로를 저장하도록

되어 있습니다. 슬라이드쇼 기능은 새로 보여줄 이미지 파일을 로컬 디스크에 임의의 경로로 저장하고 이 레지스트리 키 값을 해당 이미지 파일로 변경합니다. 그리고 일정 시간이 되면 다른 이미지 파일로 이를 교체함으로써 슬라이드쇼의 기능을 구현하도록 되어 있습니다.

특히 RSS feed 기능을 이용하면 로컬에 있는 이미지 파일이 아니라 바탕화면 이미지를 배포하는 웹 서버를 통해서 늘 새로운 바탕화면을 구독할 수 있는 기능도 사용할 수 있습니다.

이전에도 소개 드린 바 있지만 Windows 운영체제의 커널은 여러 구성요소로 구성되어 있습니다. 그러다 보니 내부를 구성하는 함수의 종류도 많고 그 양도 많습니다. 운영체제를 위해 구현된 많은 함수들은 어느 구성요소에 속하는 함수인지를 구분하기 위해서 함수명 앞에 Prefix를 사용하고 있습니다.

커널 함수들의 Prefix를 간단히 정리하면 다음과 같습니다.

Io_ : I/O Manager
Ps_ : Process Structure Module
Mm_ : Memory manager
Ex_ : Executive (heap 관리, 동기화 처리 등)
Ob_ : Object Manager
Se_ : Security Reference Monitor
Rtl_ : Runtime Library Component (자주 사용되는 utility function들)
Zw_ : Kernel-mode에서 호출되는 Native API들
Ke_ : thread나 processor 사이의 low level 동기화를 위한 함수
Hal_ : HAL(Hardware Abstraction Layer)

C 언어를 이용해서 프로그램을 개발해 본 분이 있다면 main() 함수가 entry function의 역할을 한다는 것을 알고 있을 것입니다. 작성한 응용 프로그램이 실행된 후에 처음으로 불려지는 함수가 됩니다. 실제로는 C runtime library가 먼저 초기화 작업을 한 후에 개발자가 작성한 main() 함수를 호출하는 형태입니다. 아무튼 개발자가 작성하는 코드 중에서는 가장 먼저 실행되는 현관문과 같은 역할을 수행합니다.

이와 유사하게 Windows 응용 프로그램을 위해서는 WinMain()이라는 함수를 구현하도록 되어 있고, 다른 프로세스에 의해서 실행 시점에 로딩되어 사용되는 DLL 파일의 경우에는 DllMain()이라는 entry function을 구현하도록 되어 있습니다.

동일한 개념으로 device driver를 개발할 때 entry function이 되는 것이 바로 DriverEntry() 라는 함수입니다. 이 함수는 작성한 driver file이 메모리에 로드 되는 시점에 system thread(I/O manager)에 의해서 불려지는 함수입니다. 따라서 작성된 driver에서 초기화 작업을 진행할 것이 있으면 이 함수 내에서 구현하는 것이 좋습니다. 주의할 것은 DriverEntry() 함수는 driver module이 메모리에 로드 될 때 한 번만 호출 되는 것으로 해당 driver file이 이미 로드 되어 있는 상황에서 device를 새로 추가했다고 해서 다시 호출되는 것이 아닙니다. 이 점을 고려해서 DriverEntry() 함수에 포함되어야 할 코드인지를 주의하셔서 초기화 작업을 진행하시기 바랍니다.

다음은 MSDN 사이트에서 확인한 DriverEntry 함수에 대한 내용입니다. (http://msdn.microsoft.com/en-us/library/ms795702.aspx 참고)

DriverEntry가 호출 될 때 전달되는 첫 번째 인자로 I/O manager가 생성한 Driver Object의 주소를 넘겨받는데, driver 실행에 필요한 기본적인 값들에 대해서 이 구조체의 초기값을 설정해야 줘야 합니다. 예를 들면 IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_READ 등에 대한 처리를 어느 함수에서 처리할 것인지를 I/O manager에 알려줘야 해당 요청이 있을 때 적절한 dispatch handler routine이 호출됩니다.

예를 들면 다음과 같은 코드 작성이 가능합니다.

pDriverObject->MajorFunction[IRP_MJ_CREATE] = MyCreateFunction;
pDriverObject->MajorFunction[IRP_MJ_CLOSE] = MyCloseFunction;
pDriverObject->MajorFunction[IRP_MJ_READ] = MyReadFunction;
pDriverObject->MajorFunction[IRP_MJ_POWER] = MyPowerFunction;
pDriverObject->DriverExtension->AddDevice = MyAddDeviceFunction;

그리고 driver 내부에서 사용되는 object나 type, resource 등에 대한 초기화 작업을 진행하면 됩니다. 이 과정에서 동적으로 생성한 메모리가 있으면 적절한 해제 작업을 하고 리턴해야 합니다.

초기화 작업에 완료했으면 리턴 값으로 STATUS_SUCCESS를 리턴 합니다. 만약 어떤 이유로 초기화가 제대로 진행되지 못했다면 http://msdn.microsoft.com/en-us/library/aa489610.aspx 문서를 참고하셔서 관련 내용이 이벤트 로그에 남겨질 수 있도록 적절한 NTSTATUS 값을 리턴하시기 바랍니다. NTSTATUS 값은 http://msdn.microsoft.com/en-us/library/aa489585.aspx에서 확인할 수 있습니다.

다음에는 WDM에서 사용되는 주요 함수 중에서 AddDevice 함수에 대해서 간단히 정리해보도록 하겠습니다.

WinDbg를 이용해서 Kenel debugging을 하려면 디버깅 대상이 되는 Target machine과 이를 디버깅 및 컨트롤 하는 Host machine, 그리고 이 두 컴퓨터를 연결하기 위한 COM, IEEE1394, USB 등의 케이블이 필요합니다. Target machine에서 발생하는 문제점을 파악하기 위해서는 이렇게 물리적으로 분리된 컴퓨터를 이용해서 Kernel debugging을 하는 것이 좋습니다만, 이렇게 PC를 2대 마련하는 것이 쉽지 않습니다.

만약 분석하려는 문제점이 물리적인 장비가 아니라 Virtual PC에서도 재현이 되는 것이라면 간단히 하나의 PC에서 Virtual PC를 이용해서 Target machine을 가상으로 실행해서 Kernel debugging 하는 것이 가능합니다. (다만, Virtual PC나 VMWare와 같은 가상 머신에서 하드웨어 관련 이슈는 확인이 불가능한 경우가 많습니다.)

오늘은 Virtual PC를 이용해서 Kernel debugging 하는 방법을 알아보도록 하겠습니다.

1. Virtual PC 2007 설치하기
http://www.microsoft.com/downloads/details.aspx?FamilyId=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en

2. Virtual PC 2007에 Target OS 설치하기
본 문서에서는 Windows XP를 Virtual PC에 설치한 것으로 가정합니다. 만약 기존에 만들어진 VPC 이미지가 있다면 해당 파일을 복사한 뒤에 등록해서 사용하면 됩니다.

3. 디버깅하려는 Target OS를 선택하고 ‘Settings’ 클릭. (단, 해당 VPC는 반드시 Power off 상태여야 합니다.)

4. ‘COM1’은 선택하고 'Named pipe’에 “\\.\pipe\debug”라고 입력합니다. 예로서 debug라는 이름을 사용했습니다만 이름은 임의로 정하시면 됩니다. 나중에 Host Machine의 WinDbg에서 여기서 지정한 이름으로 Named pipe로 연결을 시도할 것입니다.

5. ‘OK’를 클릭합니다.

6. Target VPC를 부팅한 후

- Windows XP 일 경우 : c:\boot.ini 파일을 열고 다음과 같이 /debug 옵션을 추가합니다.

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /debug /debugport=COM1 /baudrate=115200 /fastdetect /NoExecute=OptIn

- Windows Vista 이상일 경우 : 관리자 권한으로 prompt 창을 열고 다음 명령을 수행한다.

bcdedit –debug on
bcdedit –dbgsettings serial debugport:1 baudrate:115200

이로써 Target machine으로 사용될 VPC 이미지에 대한 setting은 완료되었습니다.

이제 Host machine에서 WinDbg에서 kernel debugging을 위해 설정하는 방법을 알아보도록 하겠습니다.

1. WinDbg를 실행합니다.

2. File 메뉴에서 ‘Kernel Debugging…’를 선택하고, Port:에 “\\.\pipe\debug”라고 입력합니다.

3. ‘확인’을 누르면 다음과 같이 WinDbg는 지정한 named pipe를 이용해서 Target machine과 연결될 수 있도록 대기합니다.

4. VPC를 재부팅 한 후 부팅 옵션에서 ‘debug enabled’ 항목을 선택합니다.

5. WinDbg 화면에서 다음과 같이 Kernel debugger가 연결되었음을 확인할 수 있습니다.

이렇게 Target machine이 연결되었으면 Vitual PC를 이용한 Kernel debugging을 할 수 있도록 환경이 설정 되었음을 의미합니다.

지난 번에 설명한 바 있지만 device driver에는 여러 종류가 있습니다. 이를 크게 분류하면 다음과 같습니다.

• Bus driver - 특정 bus에 attach된 device들을 enumeration 하고 이를 관리
• Function driver - 특정 device의 동작에 대한 기능을 제공
• Filter driver – Bus 또는 Function driver의 상/하위에 위치하여 기능을 확장하거나 동작을 모니터링 하는 데 사용

그리고 각 device에 대해서 운영체제는 DEVICE_OBJECT라는 구조체 형태로 이를 관리합니다. driver의 type에 따라서 다음과 같이 각각 다른 device object로 이를 표현합니다.

• PDO – Physical Device Object.  Bus driver가 사용하는 device object
• FDO – Function Device Object. Function driver가 사용하는 device object
• FiDO – Filter Device Object. Filter driver가 사용하는 device object

예를 들어 device 들은 다음과 같은 layer를 구성하여 존재하게 됩니다.

FiDO   FiDO   FiDO
  ↑        ↑        ↑
FDO    FDO    FDO
  ↑        ↑        ↑
FiDO   FiDO   FiDO
  ↑        ↑        ↑
PDO    PDO    PDO
     ↑     ↑     ↑
          FiDO
            ↑
          FDO
            ↑
          FiDO
            ↑
          PDO

그렇다면 이렇게 layer를 구성하는 device driver들은 어떠한 순서로 loading이 될까요? 여기서 driver의 loading이란 가상 메모리에 drvier file의 image가 맵핑 되는 것을 의미합니다. 이는 시스템에 의해서 각 driver의 AddDevice가 호출되는 순서와 관련이 있습니다. 시스템이 AddService를 호출하는 순서는 다음과 같습니다.

Device Lower Filters

–> Class lower filters

–> Function drivers

–> Device Upper Filters

–> Class Upper Filters

각 AddDevice 함수들은 DEVICE_OBJECT 구조체를 만들고 해당 PDO의 root stack에 링크 시킵니다. 즉, 실제 메모리에 로딩되는 순서보다는 AddDevice가 호출되면서 PDO 내에 stack에 링크되는 순서에 의해서 device stack이 구성되도록 구현되어 있습니다.

Pnp(Plug and Play)를 지원하는 device는 내가 어떠한 device인지를 bus 측에 전달하도록 구성되어 있습니다. 운영체제에서는 이를 이용해서 새로 시스템에 부착된 device가 있는지 확인하고 새로 추가된 device id에 적절한 driver가 있는지 찾고 설치할 수 있도록 합니다.

PnP device가 있기 이전에는 먼저 하드웨어를 시스템에 부착한 뒤에 항상 해당 device에 대한 드라이버 및 필요한 모듈을 직접 설치했습니다. PnP 기술의 도입으로 부착된 device에 대한 identification이 가능해졌고 이를 통해서 해당 device에 적절한 driver 파일을 이미 가지고 있으면 이를 이용하고 아니면 웹 상에서 드라이버 파일을 찾거나 하는 기능도 가능해졌습니다. 즉, 사용자 입장에서는 device을 설치하는 과정이 보다 쉬워지게 되었습니다.

특히 최근에는 대부분의 device들이 USB 형태로 제작되는데 이를 통해서 대용량의 데이터를 빠르게 전송할 수 있기도 하고, USB 자체적으로 hot plugin/out을 지원하므로 운영체제의 재부팅 없이 언제든 device를 추가하고 제거 가능합니다.

그렇다면 이러한 PnP device는 어떠한 과정을 거쳐서 새로운 device가 추가되었음을 확인하고 관련 설치작업을 진행하게 되는 것일까요? 오늘은 이러한 절차에 대해서 알아보도록 하겠습니다.

다음은 전반적인 PnP device의 설치 과정을 도식화한 것입니다.

1. 사용자가 새로운 device를 시스템에 추가합니다.

2. 추가된 device가 있음을 해당 bus에서 인식하고, bus driver는 bus로부터 새로운 장치가 추가되었다는 hot-plug notification을 받습니다. bus driver는 이러한 사실을 PnP Manager에게 IoInvalidateDeviceRelations API를 호출함으로써 알립니다.

PnP manager는 IRP_MJ_PNP/IRP_MN_QERY_DEVICE_RELATIONS IRP를 해당 bus에 요청해서 새로운 PDO list를 얻습니다.

3. Kernel mode PnP manager는 User mode PnP manager에게 새로운 device가 추가되었음을 알립니다. User mode PnP manager는 설치 과정을 진행합니다.

4. User mode PnP manager는 device 설치를 위해서 newdev.dll을 rundll32.exe를 이용해서 새로운 프로세스를 생성합니다.

5. 생성된 프로세스에서 SetupAPI와 CfgMgr API를 호출함으로써 해당 장치에 대해 설치 가능한 driver 리스트를 만듭니다. 만약 해당 device에 대해서 사용 가능한 driver가 있으면 이를 이용하고, 없으면 device manager 상에서 unknown으로 표시합니다.

6. Class installer와 co-installers가 DIF 요청을 처리하게 설치 과정에 참여할 수 있습니다. 설치에 해당 device의 INF 파일의 Version 섹션에서 제공하는 Class와 ClassGUID를 이용해서 어떠한 device setup class를 사용할 지를 결정합니다.

7. 드라이버를 로드하고 해당 device를 start 시키기 위해 다시 제어를 kernel mode PnP manager로 전달합니다.

8. Kenrel mode PnP manager는 해당 function driver 및 기타 필요한 filter driver를 로드하고, 각 driver에 대해서 AddDevice routine을 호출합니다. 필요한 경우 IRP_MN_START_DEVICE를 device driver에 전달해서 해당 device를 start 시킵니다.

9. (optional)DIF_NEWDEVICEWIZARD_FINISHINSTALL 요청을 보내서 Install 완료 페이지를 보여주는 등의 작업을 진행할 수 있습니다.

10. 모든 작업이 완료되었으면 DIF_FINISHINSTALL_ACTION을 보냅니다.

*참고문헌

• Programming the microsoft Windows Driver Model 2nd ed. chapter 2, Walter Oney, MSPress
• Device and Driver Installation Example (http://msdn.microsoft.com/en-us/library/ms791103.aspx)

앞서 64bit 플랫폼에서 32bit용으로 개발된 기존 어플리케이션이 실행될 수 있도록 해주는 Wow64에 대해서 알아본 바 있습니다. 이번에는 그 세부 내용으로 Registry Redirection에 대해서 알아 보도록 하겠습니다.

‘Redirection’이란 용어는 다른 루트로 자동으로 이동시킨다는 의미입니다. 즉, Wow64를 이용해서 32bit 응용 프로그램이 시스템 레지스트리의 특정 경로에 접근하려고 할 때 64bit 응용 프로그램이 사용되는 공간을 함께 사용하는 것이 아니라 별도의 레지스트리를 사용할 수 있게끔 자동으로 redirection 하는 기능을 말합니다. 이로써 32bit 응용 프로그램에 의해서 64bit 플랫폼에서 사용되는 레지스트리의 값이 임의로 변경되는 것을 막을 수 있기 때문에 전체적으로는 시스템 안정성을 높일 수 있게 됩니다.

리디렉션이 되는 경로는 자동으로 Wow6432Node라는 키 하위로 맵핑 됩니다. 예를 들어 HKEY_LOCAL_MACHINE\Software는 HKEY_LOCAL_MACHINE\Software\Wow6432Node로 변경되어 사용됩니다. 이러한 행위는 시스템 내부적으로 자동으로 이뤄지는 것이며 이러한 맵핑 경로는 향후 새로운 운영체제나 플랫폼에서 변경될 수도 있기 때문에 응용 프로그램에서 Wow6432Node로 직접 접근해서는 안됩니다.

이러한 Redirection이 모든 레지스트리 키에 대해서 발생하는 것은 아닙니다. 플랫폼에 종속적인 키들은 redirection 되어 물리적으로 독립적인 저장공간을 가지게 되지만, 그 외에 32bit 응용 프로그램과 64bit 응용 프로그램 및 플랫폼이 공유할 수 있는 키는 동일한 저장공간을 그대로 이용하게 됩니다.

예를 들어 HKEY_LOCAL_MACHINE\Software는 Redirection이 발생하지만, HKEY_LOCAL_MACHINE\Software\Classes는 Sharing되어 사용됩니다. 어떠한 항목이 Redirection 또는 Sharing 되는 지에 대해서는 아래 문서에 정리되어 있으므로 참고하시기 바랍니다.

그 외에 Registry Redirection에 대한 전반적인 내용 및 각 항목에 대한 세부 내용을 확인하려면 아래 문서를 참고하시기 바랍니다.

Registry Redirector
http://msdn.microsoft.com/en-us/library/aa384232(VS.85).aspx