WinCE 프로그래밍 입문자를 위한 글
-----------------------------------------------------------------------------
본 내용은 KHUG 개발자모임에서 leon 님이 올리신글을 가져온 것임을 밝힘니다.
도움이 되었으면 하는 바램입니다.
-----------------------------------------------------------------------------
Win32와 WinCE API간의 차이점
WinCE API가 Win32 API와 다른 중요한 몇가지 점:
Win32보다 작다. 이것은 Win32 API의 subset이며 Win32의 기능 한정판이다. 예를들어 윈도우 스타일의 지원이 적어졌고 컬러나 폰트에 제한된 지원만을 한다.
WinCE에 한정된 확장기능이 있다. 대다수는 터치스크린 및 디바이스 통지 지원과 같은 하드웨어 기능을 지원하기 위한 것이다. 반면에 몇몇은 CE특유기능(커맨드 바와 같은)의 지원을 위해 Win32에 상응하는 요소로 대치되었다.
Exception handling의 사용에 제한이 있다. Win32는 구조화된 exception handling을 지원하지만 CE는 C++의 exception handling 기능을 사용할 수 없다.
PC의 Win32 application를WinCE에 포팅시 주 문제는 보통 이러한 서브셋 API에서 발생할 것이다. aplication은 WinCE API의 제한과 대상 기기의 능력에 적용시켜야할 필요가 있다.
표준 MFC와 MFC for WinCE간의 차이점
MFC는 향상된 Windows application을 개발하기 위한 인기있는 도구가 되었다. MFC는 GUI application을 개발하기 위한 견고하고 포괄적인 클래스 집합을 제공한다.
MFC for Windows CE 는 표준 MFC와 기능 및 특성이 가깝도록 디자인 되었지만 특정 기능의 지원을 위한 중요한 차이점이 각 클래스에 존재한다. 더불어서 WinCE 플랫폼의 고유한 기능(command bar control같은)의 지원을 위해 표준 MFC에는 없는 클래스가 존재하기도 한다.
당신의 애플리케이션이 표준 MFC로 쓰여졌다면 MFC for WinCE와 호환이 되는지를 파악하기 위해 쓰여진 클래스, 메쏘드, 프로퍼티등을 조심스럽게 조사하여야 한다.
메모리 제약
일반적으로 WinCE 장비는 PC보다 적은 RAM을 갖을것이며 HDD와 같은 대용량 보조기억장치가 없을것이다. 대부분의 경우 성공적으로 애플리케이션을 WinCE에 포팅하려면 그 자신의 크기를 줄여야할 것이다.
애플리케이션을 WinCE로 포팅할 때 주로 쓰이는 기능에 주목하여야 한다. MS Pocket Word, MS Pocket Excel은 애플리케이션의 핵심 기능을 남긴 채 그 기능을 줄이는 방법에 대한 예이다.
애플리케이션은 가능한 적은 메모리 및 저장장치를 사용하도록 작성되어야 한다. 또한 시스템과의 협동을 통해 메모리 부족을 관리해야 한다.
Energy Limitations
(관심사항이 아니기 때문에 번역하지 않음)
Windows CE devices may have very limited energy resources. The Handheld PC (H/PC), for instance, runs on two AA batteries. Programs should be written to minimize energy consumption as much as possible. In order to conserve energy, many Windows CE devices will shut themselves down if they are not used for a period of time. Windows CE applications are expected to resume where they left off following a shut down. If a critical power shortage occurs while an application is running, that application must be able to handle the situation gracefully.
하드웨어 특성
CE는 일반적으로 작고 PC보다 기능이 떨어지는 장비를 위해 디자인되었다. 예를들면:
일반적으로 스크린은 작고, 보다 적은 화소를 가지며 컬러지원이 없다.
CPU는 느리다.
키보드와 같은 User-Interface 하드웨어의 유연성이 떨어진다.
한편, CE H/W는 적외선 통신 장비와 같은 비표준 PC 장비를 포함하는 하드웨어일 것이다. 어떤 경우라도 CE 기반 장비가 일반 PC와 비슷하리라는 가정을 버리고 대상 장비의 하드웨어 특성을 단단히 숙지하라.
애플리케이션을 하나 이상의 장비에 포팅시, 최소공통분모(lowest common denominator)를 찾아내는게 필요하며 이는 대상 기기들에의 포팅 성공을 보증한다. 애뮬레이터가 중요한 개발도구라 할지라도 애플리케이션은 최종적으로 실제 대상 기기에서 테스트되어야 한다.
테스트 및 디버깅
WinCE 개발도구는 다른 Win32 대상 애플리케이션 개발작업과 매우 유사하지만 테스트와 디버깅 방법은 중요한 차이점이 존재한다. 만약 H/PC와 같은 표준 WinCE 대상기기를 위한 애플리케이션을 개발한다면 개발도구 내의 애뮬레이터 환경에서 대부분의 개발 및 테스트 작업을 수행할 수 있다. 그러나 만약 비표준 하드웨어 플랫폼(전용장비와 같은) 애플리케이션이라면 애플리케이션의 정확성을 증명하기 위한 또다른 방법을 궁리하여야 한다. 디버깅을 위한 WinCE API(DebugActiveProcess나 DebugEvent같은)를 사용하여 in-system 디버깅 도구를 만들 수 있다. 또한 대상 기기 및 애플리케이션에 따라 WinCE의 Remote API(RAPI) 기능을 사용하여 디버깅할 수도 있다(Serial I/O가 없는 경우겠군:역자 혼잣말^^;).
어떤 경우든 애플리케이션은 대상 기기상에서 생각되어지는 모든 상황을 철저히 테스트 하여야 한다. 애뮬레이션 환경에서의 테스트 결과가 적절할지라도 신뢰하면 안된다.
--------------------------------------------------------------------------------
WinCE로 포팅하기 위한 체계적 접근
Win95용 애플리케이션을 WinCE로 포팅하기 위한 체계적 접근법은 비록 완전하진 안더라도 애플리케이션을 실행될 수 있게끔 할 것이다.
본 섹션의 의도는 포팅을 위해 철저히 기술한 것은 아니며 중요한 이슈만을 밝힌 것이다.
Windows CE API로의 이식
만약 포팅하려는 애플리케이션이 16bit 라면 우선 Win32로 포팅하라. Win32가 하위 호환성에 의해 일반적인 16bit 함수를 지원하지만 WinCE 는 지원하지 않는다.
다음, 애플리케이션에 쓰여진 모든 API(Function, message, 관련 Data type)를 조사하고 WinCE API와 호환성이 없는것은 수정하거나 대치하라. 몇가지 예를 들면:
몇가지 Win32 함수는 전혀 지원하지 않는다. 16bit Windows Function도 물론 지원하지 않는다. 이러한 함수를 대체하는 함수가 있다면 대치하고 그렇지 않으면 만들라. 예를들어, MoveTo와 LineTo와 같은 그리기 함수는 WinCE에서 지원되지 않는다. 그 대신에 PolyLine 함수를 사용한다.
몇가지 Win32 함수는 WinCE 대응함수로 대치되었다. 예를들면 도구바와 메뉴바는 하나의 CommandBar로 통합되었으며 이를 위한 새로운 API가 있다.
몇가지 Win32 함수는 한정된 기능만 제공한다. 어떤것은 하나 또는 그 이상의 매개변수가 무시된다. 어떤것은 매개변수의 옵션 범위가 줄어들었다. 예를들어 CreateWindow와 CreateWindowEX 함수는 지원하지만 WinCE는 Win32의 윈도우 스타일중에서 일부만을 지원할 뿐이다.
지원하는 데이터형은 변경이 필요하다. 모든 가능한 Win32 구조체는 지원되지만 몇몇 멤버변수는 사용되지 않는다. 또다른 구조체는 모든 범위의 옵션을 지원하지 않을 것이다.
WM_*과 EM_*을 포함하여 몇몇 메시지는 지원되지 않는다. 몇몇은 변경된채 지원된다. 예를들어, wParam이나 lParam의 내용이 틀려진다. WM_HIBERNATE과 같은 WinCE 고유의 메시지가 추가되었다.
WinCE 메모리 관리
사용 가능한 메모리의 양은 대상 기기에 종속적이다. WinCE는 메모리의 사용에 있어 대용량 기억장치와 RAM에 구분을 두지 않는다.
메모리 사용을 줄여라. 비트맵 그래픽과 같은 메모리 소비가 많은 기능은 간단히 하거나 제거하는 길을 생각하라. 필요하지 않다면 임시파일을 사용하지 말라. 경우에 따라 메모리 사용을 줄이면 수행 속도가 느려질 수도 있으므로 적합한 균형을 이루도록 해야 할것이다.
메모리가 부족해지면 WinCE는 메모리 사용를 줄이고 가용 메모리 확보 절차를 수행한다. 이 작업의 핵심은 WM_HIBERNATE 메시지 이며 이는 Win32 표준 메시지가 아니다.
참고
잘 구현된 프로그램은 메모리 부족 상황에서 협력하기 위한 WM_HIBERNATE 메시지 핸들러를 구현하여야 한다.
Managing Available Power(전원관리)
Many Windows CE devices will be battery operated and have a very limited energy supply. An active (running) CPU consumes significant quantities of energy, so avoid coding practices that use CPU cycles unnecessarily. The PeekMessage function, in particular, should be used with care, as it can keep the CPU running almost continuously.
Windows CE displays warning messages when the batteries start to run low but does not send any warning to applications. For many applications, these messages may be sufficient to ensure that the user takes appropriate action to avoid loss of data.
However, some hardware - modems, for instance - can drain batteries rapidly. If your program is going to place significant demands on the batteries, check the state of the batteries first. If they are too low to complete the procedure, the user can be advised to take appropriate action. Determining the state of the batteries can be accomplished by polling the system.
비트맵과 아이콘 적합화
일반적으로 WinCE 기기는 PC와는 다른 화면비(aspect ratio)와 작은 스크린을 장착할 것이다. 애플리케이션은 이러한 제한에 맞추어 수정되어야 하지만 고정된 값으로 작성되어선 안된다. 왜냐하면 다른 대상 기계는 또다른 화면크기와 화면비를 가질 수 있기 때문이다. 대신에 GetSystemMetrics 함수를 사용하며 화면 특성을 얻은 후 윈도우 크기를 정의하라.
가용 팔레트는 극히 한정된다. 어떤 기기는 비록 PC에 비해 제한된 팔레트를 가지지만 컬러스크린을 지원한다. 1세대 H/PC 의 대다수가 2비트 그레이 스케일 LCD만을 지원한다.
비트맵과 아이콘을 대상 기기에 적당한 형태로 하라. LCD 화면은 보기 힘들므로 가능한 대조(contrast)를 유지하라.
Unicode의 사용
WinCE는 Unicode 환경이다. 비록 text file과의 자료교환을 위해 ASCII 기능을 제공하지만 내부 텍스트 형태는 Unicode이다. ASCII 애플리케이션을 Unicode 환경으로 변환하기 위한 몇몇 가이드라인은 아래와 같다:
Tchar.h를 include하라. 변환에 필요한 모든게 들어있다.
C run-time library 대신에 Win32 string 함수를 사용하라(lstrlen 같은것).
선언시 TCHAR, LPTSTR 등을 사용하라. 그러면 ASCII나 UNICODE 선언자를 쓴것보다 쉽게 컴파일된다.
String literal에 TEXT 매크로를 써라(예:TEXT("Your Text")).
한 캐릭터는 더이상 한바이트가 아니며 스트링 끝은 두 바이트의 0이 들어감을 명심하라.
배열 포인터나 캐릭터 카운트시 sizeof(TCHAR)를 사용하면 ASCII나 UNICODE 환경에 신경쓰지 않아도 된다.
윈도우 생성 및 관리
WinCE에서 윈도우를 만들고 관리하는 것은 Win32와 대부분 동일하다. 그러나 window style 및 관리 옵션이 줄어들었다.
현저한 차이점은 윈도우가 이동시 사용자는 그 크기를 변경할 수 없다는 것이다. 크기 변경을 위한 핸들 및 버튼은 없다. 윈도우는 생성시에만 그 크기가 지정될 수 있다. 다른 애플리케이션이 활성화 되면 원래것은 향후의 (사용자에 의한)활성화 지정을 위해 태스크바에 아이콘화 할 것이다. 윈도우 크기 조정 불가라는 사실이 의미하는 것은 일반적으로 자주 쓰이는 윈도우 스타일(특히 WS_OVERLAPPEDWINDOW)이 지원되지 않는다는 것이다.
대상 기기의 화면이 작다면 애플리케이션은 전화면 윈도우가 될 것이다. 그러나 고정 레이아웃에 대한 코드를 쓰지 말라. 다른 기기는 다른 화면크기를 가지기 때문이다. 현재 대부분의 H/PC의 화면은 대략 2.5*4인치 크기에 240*480 화소이다. 어떤것은 더 큰 화면에 240*640 크기를 가지며 피치와 화면비는 물론 상이하다. GetSystemMetrics 함수를 호출하여 적절한 정보를 획득한 후 윈도우 크기를 정의하라.
WinCE 대화상자의 사용
WinCE는 모덜 및 모덜리스 대화상자(modal & modaless dialog box)를 모두 지원하며 Win95에 입각한 미리 정의된 콘트롤들을 지원한다. 그러나 모든 콘트롤 스타일을 지원하지는 않는다. 메시지 박스 또한 Win95보다 적은 스타일만을 지원한다.
WinCE는 열기 또는 다른이름으로 저장(Open, Save As)과 같은 간단한 공통 대화상자를 지원한다. 이것의 표시 형태는 Win95와 비슷하지만 가용한 콘트롤은 적다.
User Interface 컨트롤의 이식
대부분의 표준 윈도우 콘트롤 및 공통 콘트롤이 지원되지만 제약을 가지고 있다. 큰 차이점중 하나는 메뉴와 도구바가 합쳐진 single command bar로서 윈도우의 최상단에 나타나며 이를 관리하기 위한 API가 존재한다. 툴팁은 커맨드바의 버튼에서만 지원된다.
일반적으로 제한된 범위 내에서의 옵션만이 사용 가능하다.
WinCE 쓰레드의 관리
WinCE는 멀티쓰레드 운영체제이지만 Win95나 WinNT에 비해 제약을 가지고 있다. 아마도 가장 큰 차이점은 세마포어가 지원되지 않는다는 점일 것이다. 애플리케이션이 디바이스 자원을 관리하기 위한다던가의 이유로 세마포어를 사용한다면 다른 방법으로 쓰레드간 상호조정을 변경하여야 할 것이다. 예를들어 쓰레드간 동기화를 위해 임계영역(critical section)을 사용하도록 애플리케이션을 수정할 수 있다.
User Interface의 변경
유저 인터페이스는 다루어야 할 어려운 이슈중에 하나이다. 실제 일반 PC는 다소간 차이는 있겠지만 대부분 입력을 위해 마우스와 키보드를 가지고 있고 출력을 위한 스크린을 가지고 있다. 한 프로그램이 한 PC에서 수행되면 다른 모든 기계에서도 통상적으로 수행될 것이다. WinCE 기계는 PC와는 아주 다른 여러 종류의 입출력 기기를 포함하며 또한 다른 종류의 WinCE 기계와도 (입출력 기기는)상당히 다를 것이다.
실례로써, 어떤 H/PC는 마우스 대신에 작은 LCD 터치스크린을 사용한다. 스타일러스 펜으로 화면을 접촉하면 일반 PC와 마찬가지로 WM_LBUTTONDOWN 메시지가 생성된다. 스타일러스펜이 화면에 접촉되지 않으면 (마우스 커서의) 트랙킹 유지방법이 없으므로 마우스 커서는 없다.
결과적으로 하나의 마우스 버튼만이 있게되므로 WM_RBUTTONDOWN 메시지를 발생시킬 방법이 없는데 표준적인 대안은 ALT 키와 조합하여 사용하는 것이다. 다른 WinCE 기계는 PC는 물론, H/PC와도 더욱 동떨어진 모습으로 전문화될 수도 있다. 일반적인 키보드+마우스에 추가되거나 대치되어 음성인식 또는 필기인식이 사용자 인터페이스로 사용될 수도 있다. 예를들면 키보드는 메뉴 선택만을 위한 기능충족을 위해 버튼 수가 줄어들 것이다. 텍스트의 음성 출력 기능은 정보의 화면 출력을 부분적으로 혹은 완전히 대치할 것이다.
시각표시장치(Visual Display)는 광범위하게 변할것이다. 실질적으로 다른 기계사이의 크기, 화면비, 해상도등은 많은 차이가 있다. 어떤것은 컬러지원을 하지 않는다. 어떤것은 컬러지원을 하겠지만 가용 팔레트는 크게 다를것이다.
요컨데 (프로그램이)모든 WinCE 기계에서 수행될 수 있게끔 하는 간단한 길은 없다. 프로그램 포팅을 성공시키려면 대상 플렛폼의 특징과 어떤 부분의 수정이 필요한가를 모두 알아야 한다. PC 기반의 에뮬레이터는 가치있는 개발도구이지만 한계가 있다. User Interface가 잘 설계되고 동작되는지 확인하기 위해서는 실제 기계에서 테스트되어야 하는 것이 필수적이다.
WinCE의 통신 지원
WinCE는 아래의 네 가지 통신 API를 지원한다:
Winsock
Telephony (TAPI)
Remote Access Server (RAS)
Serial Communications
이러한 API들은 그에 상응하는 Win32 API의 서브셋이다.
Winsock을 통한 네트웍 지원
WinCE 네트웍 스택은 TCP/IP 프로토콜군을 지원한다. 프로그램이 Winsock을 사용한다면 아마 약간의 수정이 필요할 것이다. 또한 IrDA 표준도 Winsock 부속을 통하여 사용된다. 그러나 Winsock 상에서 약간의 제약이 있다. 특히 WSA 함수들은 극히 부분적으로만 지원된다. WSA 함수를 쓰고있다면 수정이 필요할지를 주의깊게 조사하여야 한다.
클라이언트 애플리케이션은 PPP 서브셋 하의 IPX, NetBEUI, TCP/IP를 사용하여 네트웍 연결을 할 수 있다. 특수 호스트 이름 "ppp_peer"는 연결하려는 기기의 IP 주소를 위한 proxy를 제공한다. 또한 WinCE는 SLIP도 지원한다.
Telephony (TAPI) Support
WinCE 운영체제는 TAPI 2.0이 구현되어 있다. WinCE 하의 TAPI는 outbound data call을 지원하고 outbound 다이얼링과 주소 변환이라는 기본 도구만 제공한다.
RAS Support
RAS는 소프트웨어 기반의 멀티 프로토콜 라우터이며 원격 기기(RAS Client)가 호스트 PC(RAS Server)에 연결할때 사용한다. RAS 애플리케이션은 통상 클라이언트 기기에서 실행된다. WinCE는 많은 표준 Win32 RAS 함수를 지원하지만 한 시점에 하나의 point-to-point 연결만 지원한다. 연결은 직접 직렬 연결 또는 다이얼업 모뎀에 의해 이루어진다. RAS phone-book에는 연결 설정에 필요한 정보들이 포함된다.
Serial Communication Support
직렬포트 통신을 위해 WinCE는 Win32 직렬 함수와 표준 파일시스템 함수를 지원한다. 이러한 함수들은 직렬통신포트에 대한 열기, 닫기, 조작 그리고 포트에 대한 읽기/쓰기에 사용된다. WinCE는 중첩 통신 운영을 지원하지 않지만 기기에 따라 복수 reads/writes를 지원한다.
Minimizing Registry Usage
WinCE의 레지스트리는 최소 메모리 요구량과 최대 접근속도가 가능하도록 주의깊게 관리되도록 사용하라. 아래의 가이드라인에 따라 가능한 단순하게 각 엔트리를 유지하라:
각 컴포넌트의 키 이른 길이 제한
값을 얻기 위해 필요한 키의 갯수 제한
NULL(default) 값 사용 회피
Don*t use many little values; use a few big ones. (많은 작은값들의 사용 회피; 적은 큰걸 써라(????????) )
(아마도 BYTE나 WORD에서 Bit operation을 하라는 말같군... 그런가? :-/)
일관성 유지의 목적을 위해 Win95의 키 이름붙이기 관습(key-naming conventions)을 쓰지 말것. 이것은 자주 일어나는 비효율적인 접근이다.
|
|
