Windows® CE의 세계에 처음 입문하는 사용자는 즐겁고 놀라운 경험을 하게 될 것입니다. 1996년에
Windows CE 1.0이 출시된 이후 Microsoft에서는 컴팩트 버전의 Windows와 이 버전에 사용되는 소프트웨어를 개발하기 위한
도구를 지원하고 확장해 오고 있습니다. 현재 수백 종류의 다양한 장치가 Windows CE를 통해 작동됩니다. 가장
널리 알려진 장치는
Pocket PC와 HPC(Handheld PC)입니다.
하지만 기타 여러 장치가 Windows CE에 구축됩니다. 가정용 오락
부문에서 TV 셋톱 박스 및 Sega Dreamcast가 Windows CE를 사용합니다. 산업 자동화 부문에서는 프로그램 가능 논리 컨트롤러
및 기타 내장 장치가 Windows CE에 구축됩니다. 몇 가지 예를 들면, 이동 데이터 수집 장치, 이동 전화, 바코드 판독기, 자동 현금
지급기, 디지털 카메라 등이 Windows CE 기반의 장치 목록에 추가할 수 있는 장치입니다.
Windows CE용 소프트웨어를
처음으로 개발하는 사용자는 다양한 선택을 할 수 있습니다. 사용자는 Windows CE 기반의 응용 프로그램을 개발하기 위한 다양한 종류의
도구를 선택할 수 있습니다. 가장 작고 빠른 코드 개발을 위해 사용자는 C 또는 C++을 사용하여 Win32R API를 작성할 수 있습니다.
C++ 클래스 프레임워크를 원하는 사용자는 MFC 라이브러리를 사용할 수 있습니다. 또한 ActiveXR 컨트롤 및 구성 요소를 만들기 위해
ATL이 지원됩니다. Visual basic®을 자주 사용하는 사용자의 경우 eMbedded Visual Basic을 사용하여 Windows
CE를 대상으로 하는 Visual Basic 기반의 응용 프로그램을 만들 수 있습니다. 내장 Visual Basic은 브라우저 기반의
VBScript와 데스크톱에 사용되는 Visual Basic의 중간 형태입니다. 이 외에도 다른 도구가 추가로 출시될 예정입니다. 향후
MicrosoftR .NET 이니셔티브의 출시가 시작되면서, Windows CE용 C# 컴파일러와 함께 Windows CE용 .NET
Framework 런타임 라이브러리가 예정되어 있습니다. 현재도 Windows CE는 상당히 우수하지만 더욱 향상될 것입니다.
이
문서의 목적은 Windows CE로 수행할 수 있는 작업에 대해 설명하고 사용자가 개발 도구를 선택하도록 돕는 것입니다. Windows CE에
처음 입문하는 사용자를 위해 이 문서는 Windows CE 3.0에서 지원되는 Win32의 정확한 하위 집합을 특히 강조하면서, 개발자를
중심으로 Windows CE를 설명합니다. 이 문서의 뒷부분에서는 기존의 Windows CE용 개발 도구와 함께 이 도구의 상대적인 장점과
단점에 대해 알아봅니다. 또한 두 개의 예제 응용 프로그램을 만들었습니다. 하나는 eMbedded Visual Basic으로 작성된
VBEdit이라는 텍스트 편집기이고, 다른 하나는 Win32용 EDITOR라는 프로그램입니다. 두 프로그램에 대한 소스 코드는 이 문서의 상단에
있는 링크에서 구할 수 있습니다. 두 예제를 학습하면 Windows CE 개발과 관련된 내용을 확인할 수 있습니다.
Windows 2000 Light
Windows CE는 출시된 지 얼마 되지
않았기 때문에 이와 관련된 상당한 오해가 있습니다. Wall Street Journal의 한 기사는 Windows CE를
"Windows 98-Lite"라고 불렀습니다. 하지만 Windows 98은 부분적으로 16비트 코드 베이스를 기반으로 하기 때문에 이 설명은
부정확합니다. Windows CE는 고급 메모리 관리자, 다중 스레드 프로그래밍을 지원하는 스케줄러, 그리고 최신 고급 운영 체제의 모든 기능을
지원하기 때문에 오히려 Windows 2000의 라이트 버전으로 간주하는 것이 적합합니다. 단 한 가지 예외는 페이지 파일에 대한 지원입니다.
하지만 Windows CE는 하드 드라이브가 없이 작동하도록 설계되었다는 점에서 이 점은 문제가 되지 않습니다. 초기 개발 팀이 추구했던 설계
목표에 따라 Windows CE를 설명할 수 있습니다.
Windows CE: 추가 기능 및 생략 기능
Windows CE에는
데스크톱의 하위 집합 기능이 포함되어 있습니다. 하지만 이 하위 집합이 불완전성을 의미하지는 않습니다. Windows CE에 포함된 기능은
세심하게 선택된 하위 집합이므로, 사용된 메모리에 따라 측정된 비용 대비 기능의 이점을 조정해 줍니다. 가장 유용하고 널리 사용되는 강력한
기능이 데스크톱 버전의 Windows에서 Windows CE로 이식되었습니다.
그럼 생략된 기능은 어떤 것입니까? 불필요한 기능들은
엄격하게 생략했습니다. 예를 들어, 텍스트 그리기 기능은 두 개에서 단 하나로 바뀌었습니다. 또 다른 생략된 기능은 데스크톱에서의
레거시(Win16) 응용 프로그램 지원입니다. 따라서 프로그램 설정을 저장하기 위해 레지스트리 함수를 사용하는 Windows CE에서는 .INI
파일에 대해 읽고 쓰는 작업을 지원하지 않습니다. MAPI(Messaging API)와 같이 크기가 상당한 기능은 생략되었습니다. MAPI를
지원하지 않는 대신, Pocket OutlookR의 받은 편지함에 체계적으로 액세스하기 위한 메시지 저장 API가
있습니다.
일반적으로, 사용자 응용 프로그램에서 필요한 기능을 위한 다양한 지원이 제공됩니다. 때로 사용자는 Windows CE로
단축할 수 없는 기능에 대해 실망할 수도 있습니다. 이 기능은 Win32 함수 호출, MFC 클래스 또는 Visual Basic 컨트롤이 될 수
있습니다. 이 기능 중의 하나를 만나는 경우, 대개 다른 방법으로 작동을 수행할 수 있습니다. 하지만 일부 경우에는 처음부터 기능을 새로
작성하거나 Windows CE 버전의 응용 프로그램에서 이 기능을 제거해야 합니다.
유니코드
Windows CE는 텍스트 문자열에서 유니코드 문자를 필요로 하는
Microsoft 최초의 운영 체제입니다. 유니코드는 컴퓨터 회사들의 컨소시엄에 의해 만들어지고 국제 표준 기구에 의해 인정된 문자 집합입니다.
유럽 및 북미 언어에서 사용되는 단일 바이트 문자 집합 또는 극동 아시아 언어에서 사용되는 이중 바이트 문자 집합과는 달리, 모든 유니코드
문자는 2바이트를 차지합니다.
Win32, MFC 또는 Visual Basic과 같은 모든 Windows CE용 프로그래밍 API는
텍스트 문자열을 위해 유니코드에 상당히 의존하고 있습니다. 유니코드가 프로그래밍에 미치는 영향은 Windows CE 기반의 프로그램이 데이터를
외부 세계에서 가져오느냐의 여부에 달려 있습니다. PC에서 만들어진 데이터 파일을 사용하는 경우 사용자는 문자열을 유니코드로 변환할 필요가
있습니다. 상당수의 모뎀은 단일 바이트 문자열을 사용하여 상태 정보를 송신하고 명령 문자열을 수신합니다. Joshua Trupin의 기사에서
설명된 GPS 장치와 같은 다른 장치도 마찬가지로 단일 바이트 문자열을 사용합니다. Win32 기반의 코드를 작성하는 경우 사용자는 이 모든
장치에 대해 적절한 변환을 수행해야 합니다.
유니코드 전용 방식에서 사용자가 주의해야 하는 몇 가지 특수한 문제가 있습니다. 이
중에서 두 가지는 네트워킹과 관련이 있으며 한 가지는 Visual Basic과 관련이 있습니다. 소켓을 작업하는 경우, 모든 문자열 매개 변수는
유니코드가 아니라 ANSI 문자열입니다. 유니코드 전용 방식이 모든 부문에서 널리 사용된다는 점에서 이 점은 상당히 놀라운 사실입니다. 그
이유는 기술적인 면에서 Windows Sockets 기능이 Win32 API의 한 부분이 아니라는 점과 관련이 있다고 생각합니다. 실제로
Winsock은 새로운 API를 만들기 위해 협력하는 네트워크 프로그래머 그룹에 의해 만들어졌습니다. Winsock에서 유니코드를 사용하면 틀림
없이 일부 응용 프로그램이 깨질 것입니다.
두 번째 문제는 WinInet(Windows Internet) API와 관련이
있습니다. 이 기능을 위해서 사용자는 문자열을 사용하는 각 기능에 대한 ANSI 및 유니코드 버전을 구할 수 있습니다. 예를 들어,
Windows CE 기반의 장치에서 지원되는 InternetOpenA 및 InternetOpenW를 즉시 구할 수 있습니다.
세
번째 문제는 eMbedded Visual Basic에서 제공되는 FileSystem 컨트롤에 있습니다. 데스크톱 버전의 Visual Basic과
달리 파일 액세스를 위한 내장 명령문이 없는 대신, ActiveX 컨트롤을 사용해야 합니다. ActiveX 컨트롤은 ANSI와 유니코드를 모두
읽을 수 있지만, ANSI 문자열만을 쓸 수 있습니다. 유니코드 문자열을 파일에 쓰기 위해 고유의 Win32 함수를 사용하는 해결 방법을
VBEdit 예제 응용 프로그램에서 볼 수 있습니다.
그림?1은 유니코드와 비유니코드(ANSI) 문자열을 서로 변환하기 위한 함수를 설명합니다. 개인적으로 선호하는
함수는 C 런타임 함수인 mbstowcs와 wcstombs입니다. 이 함수는 최소한의 매개 변수를 차지하므로 쉽게 사용할 수 있습니다. 이 두
함수는 C Runtime Library에서 제공되는 반면에 매우 유용하여 코어 Windows CE 라이브러리(coredll.dll)에
추가되었습니다. 따라서 Windows CE용 Visual Basic 기반의 응용 프로그램에서 이 함수를 사용할 수 있습니다.
커널
Windows CE는 뛰어난 코어 운영 체제 지원을
자랑합니다. 사용자가 Windows 2000의 핵심 기능에 익숙하다면 데스크톱의 거의 모든 기능을 사용할 수 있습니다. Windows CE는
다중 프로세스 운영 체제이지만, 32개의 프로세스 제한이 발생할 수 있습니다. 이 제한은 데스크톱 버전의 Windows에서는 나타나지 않습니다.
Windows CE는 다중 스레드 운영 체제이며, 스케줄러가 CPU 시간을 분배하는 방식을 제어하는 상위 수준을 제공하는 256개의 스레드 우선
순위가 있습니다. 데스크톱 버전의 Windows에 있는 4가지 동기화 개체(임계 영역, 뮤텍스, 세마포어 및 이벤트)가 Windows CE에도
존재합니다.
Windows CE는 종료 처리(__try 및 __finally)와 함께 Win32 예외 처리(__try 및
__except 키워드)를 지원합니다. 이 처리를 사용하면 수학의 경우 불량 포인터, 오버플로 및 언더플로, 그리고 0으로 나누기 오류와 관련된
문제를 발견하기 위해 코드에 안전 네트를 만들 수 있습니다. Win32 예외는 존재하지만 C++ 예외는 존재하지 않습니다. C++ 프로그래머는
이 함수를 try, catch 및 throw과 같은 키워드에 의해 액세스되는 Win32 예외와 동등한 개체 지향으로
인식합니다.
데스크톱 버전의 Windows와 마찬가지로 Windows CE도 동적 연결 라이브러리를 기반으로 만들어집니다. 사용자는
데스크톱에서 친숙한 kernel32.dll, user32.dll 및 gdi32.dll와 같은 DLL이 coredll.dll이라는 단일 주
라이브러리로 대체되었다는 사실을 곧 알게 될 것입니다. 데스크톱에서와 마찬가지로 DLL에는 코드, 데이터 및 리소스가 저장될 수 있습니다. 또한
데스크톱과 마찬가지로 프로그램을 DLL에 통계적으로 연결하거나, LoadLibrary(또는 DLL을 메모리로 로드하고 잠그기 위한
LoadDriver)를 호출하여 동적으로 연결할 수 있습니다.
데스크톱 버전의 Windows에서 커널 수준의 일부 지원이
생략되었습니다. 그 중의 하나가 Windows 2000에서 나타나는 Lightweight 스케줄링 개체인 파이버에 대한 지원입니다. 또한
Windows 2000의 고급 보안 모델과 보안 설명자 및 액세스 제어 목록을 Windows CE에서는 사용할 수 없습니다. 하지만
Windows CE가 SSL(Secure Sockets Layers) 및 암호화 API를 지원하기 때문에, 보안이 완전히 배제된 것은
아닙니다.
메모리 관리
일반적으로 Windows CE는 소형 장치의 소용량 메모리 풀에서
배터리를 사용하여 휴대용으로 작동하도록 설계되었습니다. Windows CE는 Endian 32비트 프로세서를 필요로 하며, 페이지된 가상
메모리를 사용하여 실행되도록 설계되었습니다.
각 Windows CE 프로세스에는 32MB의 가상 주소 공간이 있습니다. 이 공간은
2GB의 주소 공간을 제공하는 데스크톱 버전의 Windows에 비해 상당히 작습니다. 처음에는 이 공간이 상당한 차이처럼 보입니다. 하지만
일반적인 Windows CE 기반의 장치에 16MB 및32MB의 물리적인 RAM이 장착된다는 점을 감안한다면, 가상 주소 공간이 부족하기 전에
물리적인 메모리가 먼저 부족하게 될 것입니다. 대용량 개체와 작업해야 하는 응용 프로그램은 다른 방법으로, 기가 바이트 크기의 주소 공간에서
공유 메모리를 할당합니다.
최소의 footprint를 강조하는 Microsoft에서도 메모리와 관련된 함수에 대해서는 인색하지
않았습니다. 한 가지 예외로 GlobalAlloc 계열의 함수는 전체 Win32 메모리 API가 Windows CE에 존재합니다. 사용자는
VirtualAlloc를 호출하여 페이지를 할당하고, malloc, LocalAlloc 또는 C++ 연산자를 사용하여 전용 힙으로부터 페이지를
할당합니다. 데스크톱에서와 동일한 종류의 스레드 로컬 저장소가 Windows CE에 존재합니다. 이 저장소는 TlsAlloc를 호출하여 동적으로
할당되거나 __declspec (스레드) 키워드와 함께 사용되어 통계적으로 할당됩니다. 데스크톱과 마찬가지로 사용자는 MapViewOfFile을
호출해서 공유하려는 메모리 및 32MB 제한을 위반하는 개체를 할당할 수 있습니다.
데스크톱과의 또 다른 중요한 차이는
Windows CE가 페이지 파일을 지원하지 않는다는 점입니다. 따라서 실행 파일(.EXE and .DLL)의 일부를 메모리에 로드할 수 있는
반면에, Windows CE에는 대용량 컴퓨터용으로 만들어진 운영 체제에 존재하는 종류의 가상 메모리를 만들기 위한 pagefile.sys
파일이 없습니다.
개체 저장소
Windows CE는 데이터 저장소를 위해 파일
시스템, 레지스트리(데스크톱 버전의 Windows 레지스트리와 거의 동일) 및 데이터베이스와 같은 세 가지 위치를 제공합니다. 세 가지 위치는
모두 개체 저장소라는 RAM 영역에 존재합니다. Windows CE 3.0에서 개체 저장소는 최대 256MB가 될 수 있습니다. 이전 버전에서
Windows CE의 제한은 16MB였습니다.
파일 시스템은 데스크톱과 동일한 최대 경로 길이(260바이트 또는 MAX_PATH)를
가지는 계층 디렉터리 구조를 지원합니다. 이와 같은 일반적인 길이 제한은 사용자가 데이터 파일을 Windows CE 기반의 장치와 Windows
기반의 PC 사이에서 임의로 이동할 수 있음을 의미합니다. 데스크톱과의 한 가지 차이는 드라이브 문자(A:, C:, D: 등)가 Windows
CE에서는 지원되지 않는다는 점입니다.
개체 저장소 자체는 RAM 이미지로 저장되지만, Windows CE는 플로피 디스켓, 하드
드라이브 및 CD와 같은 마그네틱 미디어를 쉽게 수용할 수 있습니다. 상당수의 장치에는 플래시 메모리를 사용하는 저장소 카드를 연결할 수 있는
CF(Compact Flash) 슬롯이 있습니다. 이 카드의 메모리는 파일 시스템을 확장하기 위해서만 사용할 수 있으며, 프로그램 실행 가능
공간을 확장하지는 않습니다.
COM 및 DCOM 지원
지정된 Windows CE 구현은 두
가지 기본적인 유형의 지원을 제공합니다. Windows CE 버전 2.0에서 도입된 기본 COM 지원은 종속 프로세스 서버를 위한 지원으로
구성됩니다. 종속 프로세스 서버는 구성 요소 및 실행을 호출 응용 프로그램의 주소 공간에 포함하고 있는 DLL입니다. 기본 지원에는 구성 요소
메모리 관리(CoTaskMemAlloc), 복합 파일(StgCreateDocfile) 및 자동화(Visual Basic에 함수 및 메서드를
표시하는 기능)가 포함됩니다.
HPC 및 팜탑 PC와 같은 Windows CE 2.0을 실행하는 장치는 모두 기본 COM 지원을
제공합니다. 또한 Pocket PC와 같은 새로운 Windows CE 3.0에서도 동일한 수준의 지원이 제공됩니다. 이와 같은 모든 장치는
DLL 기반의 COM 개체를 만들고 액세스하는 함수를 기본적으로 제공합니다.
데스크톱 버전의 Windows에서 COM 클라이언트 및
서버를 개발하는 사람들은 DLL 기반의 COM 개체가 세 가지 기본적인 유형의 COM 개체 중의 하나에 불과하다는 사실을 알고 있습니다. 다른
두 개의 개체는 로컬 서버와 원격 서버입니다. 로컬 서버는 동일 컴퓨터에 클라이언트로 존재하지만 다른 주소 공간에서 실행됩니다. 원격 서버는
완전히 다른 컴퓨터에서 실행됩니다.
Windows CE 3.0은 이와 같은 두 개의 추가 COM 서버를 지원하며, 두 서버를
DCOM 구성 요소로 일괄 취급을 합니다. 이 방식은 사용자에게 친숙한 데스크톱 버전의 Windows와는 다른 구성입니다. 데스크톱 버전에서
DCOM은 일반적으로 원격 서버 및 비로컬 서버에 대한 지원만을 말합니다. 이 차이는 시간의 우연에 의한 것일 수 있습니다. 데스크톱에서 종속
프로세스 서버 및 로컬 서버에 대한 지원이 동시에 도입되었지만, 원격 서버에 대한 지원은 나중에 도입되었습니다. 반면에 Windows CE에서의
COM에 대한 지원은 처음에는 Windows CE 2.0에서 종속 프로세스 서버 지원으로 구성되었습니다. 다른 두 가지 유형은 Windows
CE 3.0에서 사용할 수 있게 되었습니다.
사용자 인터페이스
데스크톱과 마찬가지로 Windows CE 기반의 시스템은
그래픽 출력 화면을 사용할 수 있으며 상당히 유사한 사용자 인터페이스 개체 집합을 제공합니다. 중요한 차이로 Windows CE 기반의 장치는
작은 디스플레이 화면을 사용하는 경향이 있습니다. 따라서 일반적인 데스크톱은 최소 1024x768의 해상도에서 실행되지만, Pocket PC는
VGA(240x320) 화면이 장착되어 제공됩니다.
Windows CE는 공용 대화 상자(단, 데스크톱의 8개 대화 상자 중에서
4개만 제공) 및 컨트롤과 같은 다양한 사용자 인터페이스 도우미를 제공합니다. 공용 컨트롤을 사용하므로, 데스크톱의 하위 집합만이 존재합니다.
하지만 위에서도 말했듯이 이 하위 집합은 데스크톱 버전의 Windows에서 사용할 수 있는 최고의 컨트롤을
나타냅니다.
Windows CE는 사용자가 컴퓨터와 상호 작용하기 위한 몇 가지 새로운 방식을 제공합니다. 사실 포인팅 장치의 한
종류인 터치스크린은 그다지 새롭지 않습니다. 개인적인 기억으로 Hewlett-Packard에서 적어도 10년 전에 터치스크린이 달린 PC를
만들었습니다. 하지만 이 PC는 유행하지 못하고 이 개념은 잊혀졌습니다. 수많은 Windows CE 기반의 장치에는 이 기능이 장착되어서,
마우스를 대신하는 편리한 방법을 제공합니다. 프로그래밍 방식으로 터치스크린은 마우스와 동일하게 간주됩니다. 예를 들어, 데스크톱에서와 마찬가지로
Win32를 사용하는 프로그래머에게는 WM_MOUSEMOVE 메시지가 나타나며, Visual Basic을 사용하는 프로그래머에게는
MouseDown 및 MouseUp 이벤트가 나타납니다.
중요한 혁신 분야는 음성 인식 부문입니다. 음성 인식은 차량 제품용
Windows CE에서 최초로 도입되었습니다. 여기서 음성 인식은 키 패드보다 안전한 방법을 제공합니다. 하지만 안전이 문제가 아니더라도 음성
입력은 정보 시스템에 이미 영향을 미치기 시작한 분야입니다. 음성 인식은 휴대폰 또는 무선 기반의 전화를 컴퓨터 단말기로 연결해서 인간과
컴퓨터의 상호 작용이 향상되도록 보장합니다.
그래픽
데스크톱 버전의 Windows는 계속 그래픽 시스템으로 존재해
왔습니다. 이 사실은 Windows CE도 마찬가지입니다. 그래픽 출력 라이브러리의 크기는 데스크톱보다 작아졌지만, Windows CE는 그래픽
출력에 매우 적합한 지원을 제공합니다. 데스크톱에는 GDI(Graphics Device Interface), DirectDrawR(Windows
95에서 처음 도입된 게임 API) 및 OpenGL(Silicon Graphics에서 라이센스를 획득한 3D 게임 패키지)과 같은 세 가지
기본적인 그래픽 라이브러리가 있습니다.
Windows CE는 데스크톱에서 사용할 수 있는 약 325개의 GDI 기능 중에서
85개를 제공합니다. 이 사실이 Windows CE가 그래픽 출력을 충분히 지원하지 않는다고 들릴 수도 있지만 사실은 그 반대입니다. 사용자는
데스크톱 GDI에서 그릴 수 있는 임의의 텍스트 문자열, 선, 다각형 또는 비트맵을 그릴 수 있습니다. 또한, 그리는 중에 회전시킬 수도
있습니다. 지원되지 않는 유일한 기능은 인치, cm(센티미터) 또는 트윕 단위로 그릴 수 있는 좌표 매핑 기능입니다. 그 대신, 모든 그림은
픽셀 단위가 되어야 합니다.
Microsoft에서는 Windows CE 2.01을 지원하는 장치인 Sega Dreamcast와 함께
고성능 그래픽 API인 DirectDraw에 대한 지원을 내놓았습니다. Windows CE 3.0에서 DirectDraw를 보다 광범위하게
사용할 수 있으며 Pocket PC에도 포함되어 있습니다. 현재로서는 Windows CE 버전에서 OpenGL을 지원하지
않습니다.
인터넷
인터넷의 중요성은 부인할 수 없습니다. 따라서 Windows CE에서 수많은
인터넷 지원을 발견하는 것은 놀라운 일이 아닙니다. 모든 버전은 하위 수준의 네트워크 통신 API인 소켓을 항상 지원합니다. 실제로, 거의 모든
Windows CE 기반의 장치에 존재하는 적외선 장치에 대한 지원은 부분적으로 소켓을 사용하여 제공됩니다.
Windows CE는
언제나 WinInet API를 지원합니다. 이 API는 웹 서버 연결(HTTP)을 직접 제어할 뿐만 아니라 FTP 서버에 연결해 줍니다.
브라우저 측면과 관련해서 Windows CE는 다양한 선택을 제공합니다. 기본적인 측면에서 모든 프로그램은 HTML 뷰어
컨트롤을 호스팅할 수 있습니다. Windows CE 도움말 엔진(peghelp.exe)에서 사용하는 컨트롤과 동일한 이 컨트롤은 서식 있는
텍스트를 기본적으로 표시합니다. 사용자는 이 컨트롤을 Visual Basic 기반의 프로그램이 아닌 임의의 C 또는 C++ 프로그램에 포함시킬
수 있습니다. 사용자는 GIF 또는 JPEG와 같은 모든 그래픽 이미지를 스스로 표시해야 하기 때문에 이 컨트롤이 처음에는 뛰어나지 않을 수도
있습니다.
Windows CE는 Microsoft Pocket Internet Explorer 및 Microsoft Internet
Explorer 4.0의 두 가지 웹 브라우저를 지원합니다. Pocket Internet Explorer는 Windows CE를 위해 처음부터
새로 작성되었습니다. 출시된 이 브라우저는 매우 작은 크기(1.3MB)로 기본적인 검색을 지원합니다.
두 번째 브라우저는
Internet Explorer for Windows CE입니다. 이 브라우저는 데스크톱 버전의 Internet Explorer 4.0,
Service Pack 2에서 이식되었으며, 크기가 3.1MB로 Pocket Internet Explorer보다 상당히 크고 또한 데스크톱에
있는 대부분의 벨과 신호(프레임, CSS(Cascading Style Sheets), 동적 HTML)를 지원합니다. 하지만 이 브라우저는
JScriptR만 지원하고 VBScript를 지원하지 않으며, 클라이언트 측 데이터 바인딩(DATASRC 및 DATABIND 속성)과 같은 일부
기능도 지원하지 않습니다.
개발 도구 선택
최초의 Windows CE 버전이 출시된 이후로
Microsoft에서는 해당 플랫폼에서 사용할 수 있는 개발 도구의 목록을 추가해 왔습니다. 현재는 Platform Builder 3.0 및
eMbedded Visual Tools 3.0과 같은 두 가지 기본 개발 도구가 있습니다. Platform Builder를 여기서 언급한 이유는
Platform Builder가 출시되어 있으며 상당수의 응용 프로그램 개발자들이 이 프로그램의 용도와 사용 여부에 대해 궁금해 하기
때문입니다. 개인적인 견해로는 소수의 개발자가 이 프로그램을 사용할 것입니다. 이 프로그램 대신 사용되는 도구는 eMbedded Visual
Tools 3.0입니다.
Platform Builder는 Windows CE 자체의 사용자 정의 설정을 만들기 위해 사용할 수 있는
도구입니다. 사용자가 Windows CE를 레이저 프린터, 평판 스캐너, 디지털 카메라 또는 휴대폰에 포함시키려는 OEM이 될 수도 있습니다.
사용자는 Platform Builder를 사용하여 속성 시트 및 대화 상자에 대한 지원을 포함할지 여부를 결정할 수 있습니다. Windows
CE를 오랫동안 사용해 오는 사용자라면 이 도구의 이전 이름인 Windows CE Embedded Toolkit를 기억할 수도
있습니다.
Platform Builder에는 명령줄 및 GUI 구동의 두 가지 다른 작동 모드가 있습니다(그림?2 참조). 두 가지 모드는 기본적으로 동일하지만 그래픽 프런트 엔드가 배우기에 좀더 쉽습니다. 사용하는
모드에 상관 없이 사용자는 BIB(Binary Image Builder) 파일을 편집해서 포함하려는 요소를 선택합니다. 또한 사용자는 포함하려는
장치 드라이버 및 포함하려는 API의 일부분 뿐만 아니라 포함하려는 응용 프로그램 및 응용 프로그램 지원 파일을 지정할 수 있습니다. 이 외에도
장치를 처음 실행시키는 경우의 설정을 시스템 레지스트리에 지정할 수 있습니다.
하드웨어, 장치 드라이버 및 운영 체제를 포함하는
플랫폼이 일단 만들어지면, 다음 단계는 응용 프로그램 소프트웨어를 만드는 것입니다. Platform Builder의 한 가지 우수한 기능은
사용자 정의 SDK를 만들어서 현재 버전의 플랫폼을 사용하는 응용 프로그램 개발자의 노력을 지원하는 기능입니다.
eMbedded
Visual Basic 3.0 패키지는 Visual StudioR와 유사한 Windows CE 기반의 개발을 위한 일체형 환경입니다. 이
패키지는 4개의 개별 제품에서 필요했던 모든 지원을 단일 패키지로 만듭니다. 이전의 Windows CE용 응용 프로그램 개발 제품과는 달리,
eMbedded Visual Basic 3.0은 Visual C++R 및 Visual Basic용 도구에 대한 단순한 추가 기능은 아닙니다. 그
대신 eMbedded Visual Basic 3.0은 두 가지 환경에서 필요한 모든 지원을 단일 독립형 패키지로 제공합니다. 사용자는 배달
비용을 지불하고 이 패키지를 Windows 웹 사이트(http://msdn.microsoft.com/isapi/gomscom.asp?TARGET=/PocketPC/developer.asp)에서
주문할 수 있습니다. 이 패키지에서 사용자는 이 문서에서 이전에 설명된 4개의 프로그래밍 인터페이스를 각각 액세스할 수 있습니다. 저자는
Visual Basic, Win32, MFC 라이브러리 및 ATL과 같은 4개의 인터페이스에 대해 차례로 살펴볼 것입니다.
통합 개발 환경
eMbedded Visual Tools 설치하는
경우, eMbedded Visual Basic 3.0, eMbedded Visual C++ 3.0, 및 API Text Viewer의 세 가지
항목이 사용자의 시작 메뉴에 추가됩니다. Windows CE를 이전에 개발했던 경험에 상관 없이 이 세 가지 도구의 이름 및 이와 관련된
아이콘은 누구에게나 친숙하지 않을 것입니다.
그림 3 eMbedded
Visual Basic 3.0
하지만 이 도구를 실행하게 되면 사용자는 상당히 친숙함을 느낄 것입니다. eMbedded
Visual Basic 3.0은 Visual Basic 6.0과 상당히 유사합니다(그림 3 참조). 마찬가지로 eMbedded Visual
Basic C++ 3.0은 데스크톱의 Visual C++ 6.0과 상당히 유사합니다(그림 4 참조).
그림 4eMbedded
Visual C++ 3.0
Windows CE용 개발 도구의 이름과 구성이 변경되었더라도 실제로는 매우 친숙하다는
사실을 여기서 처음으로 알 수 있습니다. eMbedded Visual Basic의 메뉴를 간단히 살펴보면 Visual Studio에서 몇 가지
기능이 빠져 있지만 대부분의 주요 기능은 그대로 사용되고 있음을 알 수 있습니다. eMbedded Visual C++은 사실상 Visual
C++ 6.0의 복제품입니다. 두 제품에서 서로 다른 부분을 찾는 것이 상당히 어려울 것입니다. 두 환경은 모두 친근한 편집기, 메뉴 및 설정
창을 특징으로 하며, 응용 프로그램을 작성하기 위한 시작점을 제공합니다. 하지만 이 영역에서 eMbedded Visual C++ 환경은 보다
풍부한 컬렉션을 제공합니다. 마법사를 사용하여 Win32 및 MFC 응용 프로그램을 만들 수 있으며 또한 ATL 구성 요소를 만들 수 있습니다.
eMbedded Visual Basic 기반의 새로운 프로젝트를 만드는 경우 사용자는 무형(formless) 프로젝트, 팜탑 프로젝트,
Pocket PC 프로젝트 및 HPC Pro(Handheld PC Pro) 프로젝트와 같은 4가지 프로젝트 유형 중에서 하나를 선택해야 합니다.
Visual Basic 6.0에서 10여 개의 프로젝트를 사용하던 개발자는 틀림 없이 유연성의 부족을 그리워할 것입니다. 하지만 향후 릴리스에서
프로젝트가 추가로 나타날 것으로 예상됩니다.
eMbedded Visual Basic 및 eMbedded Visual C++은 모두
그림?5에 설명되어 있는 원격 도구 집합을 지원합니다. 이 도구를 사용하려면 Windows CE 기반의 장치가
직렬, USB 케이블 또는 네트워크를 통해서 개발 워크스테이션에 연결되어야 합니다. 저자는 이와 같은 도구들을 동시에 또는 다른 시간에 사용하고
있습니다. COM 및 ActiveX 컨트롤을 작업하는 경우 원격 레지스트리 편집기가 특히 유용하다는 사실을 알았습니다. 파일 뷰어를 사용하면
파일을 Windows CE 기반의 장치로 복사할 수 있습니다. 하지만 실행 파일에 대해서는 이 도구를 사용하지 않습니다. 왜냐하면, 복사는 빌드
프로세스의 일부로서 자동으로 실행되기 때문입니다. 가끔 응답하지 않는 프로세스를 중단하기 위해서 프로세스 뷰어를 사용할 필요가 있습니다. 감시
및 확대는 데스크톱에서와 동일하게 작동하므로 여기서는 더 이상 설명하지 않습니다.
eMbedded Visual Basic 및
eMbedded Visual C++의 핵심 부분은 응용 프로그램을 다운로드하고 디버깅하기 위한 지원입니다. Windows CE를 사용하는
개발자의 핵심 문제는 새로운 프로그램을 실제 장치로 로드한 다음 이 장치에서 디버깅을 수행하는 것입니다. 이 기능은 매우 적절하게 지원되고
있으며 사용자는 직렬 회선을 통하거나 네트워크를 사용하여 다운로드할 수 있습니다. 둘 중에서 선호되는 방법은 네트워크를 통해서 다운로드하고
디버깅하는 방법입니다. 여기서 중요한 문제는 속도입니다. 특히 코드를 일일이 검사하는 경우, 디버거 명령이 장치로 전달되어 실행되고 다시
전달되는 동안 수 초를 기다리는 것은 고통스럽습니다.
이 고통을 줄이기 위해서 eMbedded Visual Basic에는
Windows CE 에뮬레이터가 제공됩니다. Windows CE를 실행하는 각 유형의 장치에 대한 에뮬레이터가 존재합니다. Windows CE
기반의 프로그램을 에뮬레이터에서 실행하면 개발 프로젝트의 초기 단계에서 프로그램을 정밀하게 조절할 수 있습니다. 에뮬레이터는 Windows
NTR 4.0 또는 Windows 2000에서 실행될 수 있지만 유니코드 비지원으로 인해서 Windows 95, Windows 98 또는
Windows Me에서는 실행되지 않습니다.
그림?6은 Pocket PC용 에뮬레이터에서 실행되는 예제 응용 프로그램인 VBEdit을 나타냅니다. 각 대상
장치에는 자체의 에뮬레이터가 필요합니다. 따라서 사용자가 Windows CE용으로 개발하는 경우, HPC에 대해 하나의 에뮬레이터가 존재하고
HPC Pro에 대해 다른 에뮬레이터가 존재하며, 팜탑 PC와 Pocket PC에 대해 각각 에뮬레이터가 존재합니다.
물론 사용자는
사용 가능한 모든 장치에서 모든 소프트웨어를 테스트하고 디버깅해야 합니다. 그 이유는 간단합니다. 에뮬레이터는 실제 장치에서 나타나는 작동과
완전하게 동일한 작동을 제공하지는 않기 때문입니다. 에뮬레이터는 에뮬레이트된 장치에서 공용 코드 베이스를 사용하는 대신 서로 다른 코드 베이스를
사용합니다. 전체 에뮬레이션은 상당히 양호하지만, 사소한 차이로 인해서 최종 테스트에서는 에뮬레이션을 신뢰할 수 없습니다.
Visual Basic을 사용한 신속한 응용 프로그램 개발
모든 버전의
Visual Basic을 사용하여 Visual Basic 기반의 데스크톱용 프로그램을 작성한 경우, 사용자는 자신의 지식을 사용하여
Windows CE용 응용 프로그램을 만들 수 있다는 사실에 만족해 할 것입니다. 실제로 Visual Basic 및 eMbedded Visual
Basic 사이에는 여러 가지 유사한 점이 있습니다. 동시에 Windows CE는 소형 장치에서 실행되도록 설계되었습니다. 이 때문에
Visual Basic 팀은 크기가 상당히 줄어든 버전의 Visual Basic을 만들었습니다.
eMbedded Visual
Basic의 가장 중요한 핵심은 컴파일러를 포함하지 않는다는 사실입니다. Pocket Visual Basic 로더 프로그램인
PVBLOAD.EXE가 실행되는 경우 호출되는 인터프리터에서 응용 프로그램이 실행됩니다. eMbedded Visual Basic 환경은 .EXE
파일을 만드는 대신 사용자의 프로그램이 포함된 .VB 파일을 만듭니다. 정상적인 Windows CE 실행 파일과는 달리, 임의의 Windows
CE 기반의 장치로 복사될 수 있는 CPU 독립 파일이 있습니다. Windows CE 기반의 장치에서 Visual Basic 기반의 프로그램을
실행하기 위해서는 이와 같은 독립 파일 이외에 장치에 종속되는 런타임 라이브러리와 기타 지원 파일이 필요합니다.
데스크톱에서와
마찬가지로 eMbedded Visual Basic을 사용하면 선언문을 사용하여 임의의 동적 연결 라이브러리를 호출할 수 있습니다. 예를 들어,
다음은 Win32 MessageBox 함수를 호출하기 위한 선언입니다.
Public Declare Function MessageBoxW Lib "coredll"
(ByVal hWnd As Long,
ByVal strText As String, ByVal strCaption As String,
ByVal uType As Long) As Integer
Visual Basic 런타임은 ByRef 대신 ByVal을 사용하여 문자열 매개 변수를 참조하는 특이한 규칙을 데스크톱 버전의
Visual Basic에서 상속받았습니다. Visual Basic 팀의 한 구성원에 의하면 Visual Basic에서 문자열은 포인터에 대한
포인터라고 합니다. ByVal은 포인터가 전달되도록 하고 ByRef는 포인터를 포인터로 전달합니다. 이전에 선언된 함수를 호출하려면 다음과 같은
명령문을 사용합니다.
MessageBoxW frmMain.hWnd, "Clicked on Menu", "VBEDIT", vbOKOnly
함수의 이름에 추가로 W가 붙어 있음을 알 수 있습니다. 그 이유는 Windows CE가 유니코드 문자만을 지원하기 때문입니다.
Windows NT에서 함수의 이름은 A(ANSI) 또는 W(Wide)가 추가된 문자열을 사용합니다. 이 규칙은 두 개의 다른 문자 집합이
충돌하지 않고 공존하도록 허용합니다. Windows CE는 Win32의 이와 같은 특성을 상속받았으며, 사용자는 문자열을 사용하는 Win32
함수를 호출할 때마다 이 사실을 기억해야 합니다. 문자열을 사용하지 않는 함수(예: MessageBeep)는 변경되지
않습니다.
불행히도 Visual Basic 런타임은 유형 명령문을 지원하지 않습니다. 즉, 사용자는 고유의 구조를 정의할 수
없습니다. 이 경우는 구조에 대한 포인터를 필요로 하는 DLL 함수를 직접 호출할 수 없기 때문에 문제가 됩니다. 물론 이 문제는 대부분 해결할
수 있습니다. 사용자는 호출하려는 모든 DLL 함수를 포함하는 고유의 DLL을 만들 수 있습니다. Windows CE에서 DLL을 호출하려면 C
또는 C++을 사용해야 합니다. 즉, 사용자는 eMbedded Visual C++을 사용해야 합니다. 이 환경에서 제공되는 내장 마법사가
DLL을 신속하게 만들어 줍니다.
Visual Basic 런타임의 또 다른 요점은 지원되는 유일한 데이터 유형이 VARIANT라는
점입니다. 만약 사용자가 COM 및 자동화를 공부하고 있다면, 이 데이터 유형은 복합 유형(C 프로그램에서 union)임을 알 수 있습니다. 이
유형은 기본적인 수치 데이터 유형을 포함할 정도로 크기가 충분합니다. 또한 이 유형은 포함된 요소가 short 정수 또는 long 정수인지,
short 부동 소수 또는 long 부동 소수인지 또는 문자열인지를 식별하는 플래그를 가지고 있습니다.
단일 데이터 유형을 지원하는
주요 장점은 간결성입니다. 내부적으로 모든 함수에 대한 매개 변수는 동일하며 함수가 반환하는 유형도 마찬가지로 동일합니다. VARIANT 전용
시스템의 주요 단점은 메모리 오버헤드입니다. 사용자가 2바이트 Integer 또는 4바이트 Long 값을 저장하는 경우에 상관 없이 기본적인
VARIANT는 16바이트를 차지합니다. VARIANT는 2바이트 값에 대해 700%의 세금을 나타내고 4바이트 값에 대해 300%의 세금을
나타냅니다. 무엇보다도 실제로 필요한 크기 이상의 배열을 만들지 마십시오. Visual Basic에서 ReDim 문이 지원되므로 사용자는 배열의
크기를 원하는 대로 조정할 수 있습니다. Visual Basic 런타임에서도 배열이 지원됩니다.
하지만 이 점은 그다지 심각한
문제가 아닙니다. 일반적으로 대규모 응용 프로그램 개발자는 대부분의 복잡한 문제를 DLL 또는 ActiveX 컨트롤에 숨깁니다. 사용자가 필요로
하는 대부분의 변수들은 사용자 인터페이스를 관리하고 구성 요소 사이의 상호 작용을 관리하는 데 사용될 것입니다.
API Text
Viewer 도구를 데스크톱에서 사용했던 개발자는 eMbedded Visual Basic에서도 이 도구를 사용한다는 사실에 만족해 할 것입니다.
이전에 언급했던 것처럼, 이 뷰어는 시작 메뉴의 eMbedded Visual Tools 다음에 위치합니다. 이 뷰어는 Visual Basic에서
Win32 함수를 호출하기 위한 함수 선언, 상수 및 구조 유형 정보를 제공합니다. eMbedded Visual Basic은 사용자 정의 유형을
지원하지 않으므로 함수 선언과 상수만이 유용합니다. 정의 파일을 간단히 살펴보면 Windows CE에서 지원되는 Win32 함수가 모두
나타나지는 않았음을 알 수 있습니다. 예를 들어 CreateWindow 함수가 빠져 있습니다. 빠져있는 임의의 함수에 대해 Visual
Basic에서 입력 파일(WIN32API.TXT)을 사용하도록 선택하고, user32.dll, kernel32.dll 또는 gdi32.dll
대신 Windows CE 라이브러리인 coredll.dll을 사용하도록 선택할 수 있습니다.
VBEdit?예제 응용 프로그램
VBEdit은 eMbedded Visual
Basic 3.0을 사용하여 저자가 작성한 응용 프로그램입니다(그림?6 참조). 사용자가 Visual Basic에 익숙하다고 가정하면, Windows CE용으로 작성한 처음
응용 프로그램은 데스크톱에서 작성한 것보다 더 노력이 필요할 것입니다. 저자가 VBEdit을 작성한 경우가 바로 그랬습니다. 예상보다
eMbedded Visual Basic에 존재하는 함수가 적었기 때문에 작업이 추가로 소요되었습니다. 일반적으로 간과하는 또 다른 사실은 하나의
컴퓨터에서 만든 다음 다른 컴퓨터에서 실행하면 시간이 더 소요된다는 점입니다. Visual Basic 런타임 및 지원 ActiveX 컨트롤과
같은 모든 지원 파일을 다운로드하는 것과 마찬가지로 응용 프로그램을 다운로드하는 것도 시간이 소요됩니다. 일단 파일이나 프로그램이 다운로드
되더라도, 이 파일이나 프로그램이 올바른지 확인하기 위해서 매번 검사를 수행합니다.
VBEdit을 사용하여 유니코드 텍스트 파일을
만들고 편집할 수 있습니다. 사용자 인터페이스는 텍스트를 처리하는 대부분의 실제 작업을 수행하는 단순한 편집 컨트롤(또는 Visual
Basic의 용어로 텍스트 상자)입니다. 이 프로그램에 있는 대부분의 코드는 다양한 메뉴 선택 기능을 다루고 있습니다. 저자는 공용 대화 상자
컨트롤, 파일 시스템 컨트롤 및 Pocket PC 메뉴 컨트롤과 함께 제공되는 표준 집합의 일부였던 세 가지 ActiveX 컨트롤을
통합하였습니다.
프로그램 설계를 마친 후 응용 프로그램 설치 마법사를 실행해 보았는데, 이 마법사는 프로그램을 배달하는 데 필요한
모든 것을 패키지로 통합합니다. 그림?7에는 이 패키지에 포함된 파일이 나열되어 설명되어 있습니다. 작성된 코드는 분석을 마친 후에 표시를
하므로, (이 파일에 리버스 엔지니어링을 수행하는 수고를 하지 않으려는 경우) 사용자는 원본 소스 코드를 읽을 수 없습니다. 프로그램 자체의
크기는 겨우 8KB입니다.
프로그램이 작성되는 동안 290KB의 ActiveX 컨트롤이 추가로 필요했습니다. 개인적인 생각으로는
프로그램에서 이 컨트롤을 오버헤드로 간주하는 것이 합리적입니다. 그 이유는 이 컨트롤의 경우 특정 Pocket PC에 설치되지 않기 때문입니다.
파일의 최종 집합은 Visual Basic 런타임을 구성하며, 특정 Pocket PC 장치의 ROM에 존재합니다. 557KB의 이 이미지는
프로그램을 실행하기 위한 전체 비용의 일부로 여기에 표시되어 있습니다. 그렇지만 사용자는 대상 장치의 ROM에 파일의 최종 집합이 존재하는지
결정해야 합니다. 존재하지 않는 경우, 이 파일 집합을 대상 장치의 개체 저장소에 설치해야 합니다. 개체 저장소를 압축하면 무료로 2배 압축을
사용하여 비용을 줄일 수 있습니다.
Win32?Windows용 매크로 언어
Windows의 선구자이며 저자인
Charles Petzold는 언젠가 저자에게 “Windows API는 ‘Windows의 매크로 언어’라고 말했습니다.” 실제로 Windows
API는 Windows 프로그래밍에서 사용할 수 있는 최하위 수준의 API를 제공하며, 가장 작고 빠른 응용 프로그램을 작성하는 방법을
제공합니다. 비록 Win32를 사용하여 전체 응용 프로그램을 작성하지 않더라도, 사용자는 채용된 프로그래밍 기술에 상관 없이 Win32를
사용하여 코드의 일부를 특정 형태 또는 다른 형태로 작성할 필요가 있습니다.
Windows CE에서 Win32는 운영 체제가
원래부터 지원하는 유일한 프로그래밍 API이기 때문에 중요합니다. Windows의 운영 체제가 단 하나의 API를 지원하는 것은 이번이
처음입니다. 그림?8에서처럼 모든 버전의 Windows는 적어도 MS-DOSR API를 지원합니다. Windows NT 및
Windows 2000의 경우 5개의 API가 지원됩니다. 하지만 Windows CE에서는 Win32만 지원됩니다.
Hello Again
Win32에서 프로그래밍을 이제 막 시작한 사용자라면
eMbedded Visual C++ 마법사의 유용성을 알게 될 것입니다. 특히 몇 번의 마우스 클릭만으로도 사용자는 모든 사람이 좋아하는 최초의
프로그램인 Hello World를 만들 수 있습니다. Win32에서의 프로그래밍에 익숙한 사용자라도 마법사가 만든 코드를 다시 검토하기를 원할
것입니다. 그 이유는 매우 명확하게 예증되는 장치 전용 호출 함수가 일부 존재하기 때문입니다. 특히 Pocket PC를 사용하기 시작한 사용자는
SIP(Software Input Panel)를 사용하는 방법을 알려고 할 것입니다. 그림 9는 Pocket PC 에뮬레이터의 두 가지 예제
SIP를 나타냅니다.
그림 9 SIP(Software
Input Panel)
그렇다면 SIP를 사용하는 이유는 무엇입니까? 중요한 문제는 Windows CE 기반의 장치와
마찬가지로 Pocket PC에서 화면 영역이 부족하다는 점입니다. 하지만 이 장치에는 키보드가 없기 때문에 사용자는 텍스트를 입력하거나 편집하기
위해 SIP를 사용해야 하며, SIP는 귀중한 화면 공간을 차지합니다. 일부 경우에 사용자의 프로그램은 SIP를 자동으로 표시할 것입니다.
포커스가 편집 컨트롤로 전달되는 때가 바로 이 경우입니다. 다른 경우로 사용자는 SIP를 조작하여 SIP가 나타나고 사라지게 하거나 또는
키보드에서 필체 인식기로 SIP를 변경할 수 있습니다. 이와 같은 모든 경우에 사용자는 창의 크기를 조정하고, 일부 스크롤 막대의 위치를
이동하고, 그림의 크기를 조정하는 등의 적절한 방식으로 응답하기를 원합니다.
eMbedded Visual C++ IDE를 사용하여
만들어진 Hello World 프로그램은 SIP를 다루는 방법을 학습할 수 있는 우수한 출발점을 제공합니다. 불행히도 최종 단계에서 Pocket
PC가 몇 가지 변경되었으며, 이와 같은 변경으로 인해서 사용자는 마법사가 만든 Hello World 프로그램을 편집해야 합니다. 그림?10은 eMbedded Visual C++ IDE 마법사가 특정 Hello World 프로그램에 삽입하는
SIP 핸들링을 설명합니다. 사용자는 자신의 Win32 기반 Pocket PC 프로그램에 이와 같은 SIP 핸들링을 포함하려고 할
것입니다.
그림?11은 SIP 핸들링을 보호하기 위해 Hello World 응용 프로그램에서 변경하려는 두 가지 사항을
간단히 설명합니다. 이 변경 사항은 상당히 간단하지만 변경 여부를 결정하기 위해 약간의 시간이 소모됩니다. 우선 데이터 구조를 초기화해야
합니다. 이 작업은 여러 위치에서 수행할 수 있지만, 저자가 선호하는 방식은 WM_CREATE 메시지에 대한 응답으로 이 작업을 수행하는
것입니다.
case WM_CREATE:
memset(&s_sai, 0, sizeof(SHACTIVATEINFO));
s_sai.cbSize = sizeof(SHACTIVATEINFO); // New!
hwndCB = CreateRpCommandBar(hWnd);
break;
두 번째 사항은 SIP 도우미 함수 중의 하나인 SHHandleWMActivate를 호출하여 WM_ACTIVATE 메시지에 응답하는
것입니다. 이 함수를 호출하는 가장 큰 이점은 SIP를 수용하도록 프로그램 주 창의 크기를 조정할 수 있다는 점입니다. 창의 크기가 적절하지
않은 경우 SIP에서 그림의 일부가 잘리기 때문에, 사용자 프로그램에서 전체 클라이언트 영역을 표시하려는 경우에 이 이점이 특히 중요합니다.
또한 크기가 적절하게 조정되지 않은 창은 스크롤 막대가 나타나는 경우에 명확해 집니다. SIP는 크기가 부적절한 창에 부착된 스크롤 막대를
잘라냅니다. 다음은 이 사항을 처리하는 코드입니다.
case WM_ACTIVATE:
SHHandleWMActivate(hWnd, wParam, lParam, &s_sai, 0);
break;
일반적인 Hello World 응용 프로그램에서 마지막으로 변경하려는 한 가지 사항은 캡션 막대에 확인 단추를 추가하는
것입니다. 이렇게 하면 개발 중인 응용 프로그램을 쉽게 종료할 수 있습니다. 이 작업을 위한 코드는 CreateWindow 호출을
CreateWindowEx에 대한 호출로 변경하는 것입니다. 다음은 저자가 선호하는 코드를 나타냅니다.
hWnd = CreateWindowEx(WS_EX_CAPTIONOKBTN, szWindowClass, szTitle,
WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL,
hInstance, NULL);
이전에 Pocket PC를 사용한 경험이 없는 사용자는 프로그램 종료를 위해 전용 단계가 필요한 이유가 궁금할 것입니다. 일반적인
시스템과 마찬가지로 시스템 메뉴가 존재하지 않습니까? 사실 일반적으로는 그렇지 않습니다.
Pocket PC는 PC보다는 오히려
정보 응용기기처럼 작동하도록 의도되었습니다. 즉, 토스트 기계와 마찬가지로 시스템 상의 프로그램은 언제나 사용할 수 있다고 가정합니다. 사용자는
응용 프로그램을 종료하지 않으며 계속해서 실행합니다. 비록 메모리가 부족한 경우에는 Windows CE는 프로그램을 종료하도록 요청하지만 이
과정은 사용자의 작동이나 인지가 없이 수행됩니다. 변경 사항이 입력되는 경우 사용자는 데이터를 저장하지 않으며 자동으로 저장됩니다. 프로그램은
사용자의 확인을 요청하지 않으며, 사용자가 확신한다고 가정합니다. 사용자가 임의의 내용을 삭제하는 경우 이 내용은 완전하게
삭제됩니다.
다시 말하면, 프로그램을 개발하는 동안 사용자는 프로그램의 캡션 표시줄에 확인 단추를 만들려고 할
것입니다. 그러면 확인 단추가 대화 상자에 나타날 것입니다. 하지만 공급되는 Pocket PC 기반의 응용 프로그램에는 일반적으로
닫기 메뉴, 확인 메뉴, 또는 사용자가 응용 프로그램을 닫거나 닫기를 고려하도록 요청하는 데스크톱 트래핑이 없습니다.
Win32에서의 텍스트 편집기 응용 프로그램
Windows CE 상에서
Visual Basic와 Win32의 차이를 보다 명확하게 이해하기 위해서 다른 텍스트 편집기 프로그램을 작성했습니다. Visual Basic
버전과 마찬가지로 Win32를 사용하는 버전(EDITOR)도 시스템에 내장된 편집 컨트롤을 사용하여 유니코드 텍스트를 파일 시스템에 쓰고
읽으며, 또한 클립보드를 지원합니다. VBEdit과 마찬가지로 Win32 기반의 이 편집기는 내장 공용 대화 상자를 사용하므로 사용자는 열려는
파일을 선택할 수 있으며, 파일을 저장하기 위해 이름과 위치를 선택할 수도 있습니다.
파일 열기 및 닫기와 관련된 항목에서는
Pocket PC에서 파일이 보이는 방식에 주목할 필요가 있습니다. 왜냐하면 데스크톱과는 다른 방식으로 보이기 때문입니다. 여기서 관심의 대상은
실제로 존재하는 보기와 사용자가 볼 수 있는 보기의 두 가지 보기입니다. 실제로 존재하는 보기는 데스크톱에서와 상당히 비슷한 계층 파일
시스템입니다. 여기에는 Windows 하위 디렉터리와 Program Files 하위 디렉터리가 있으며, 이 두 디렉터리에는 사용자가 데스크톱에서
볼 수 있는 항목들이 포함되어 있습니다. 다른 하위 디렉터리인 Windows\Start에는 사용자가 시작 메뉴에서 볼 수 있는 모든 항목에 대한
실행 파일(또는 실행 파일에 대한 링크)들이 포함되어 있습니다. 간단히 말해서 사용자는 파일 시스템을 검색하는 동안 상당히 친숙함을 느낄
것입니다. 이 검색 작업은 원격 파일 뷰어를 사용하여 쉽게 수행할 수 있습니다.
항목들은 사용자에게 다소 다르게 보입니다. 특히
공용 대화 상자를 사용하면 사용자는 내 문서라는 이름의 디렉터리만을 볼 수 있습니다. 파일 시스템을 사용자에게 나타내기를 꺼리는 프로그램에 대해
공용 대화 상자가 사용자에게 보여줄 수 있는 내용은 사용자 파일을 저장하기 위해 준비된 영역입니다. 이렇게 하면 사용자가 OS 또는 응용
프로그램 파일을 손상시킬 수 없기 때문에 이것은 적절한 방법입니다.
물론 개발자 유형의 사람들은 언제나 실제로 존재하는 내용을
보려고 합니다. 다행히도 Pocket PC 버전의 데스크톱 파일 탐색기와 거의 동일한 파일 탐색기 프로그램이 있습니다. 이 유틸리티를 사용하면
CF 카드 슬롯에 연결될 수 있는 CF 저장소 카드뿐만 아니라 모든 하위 디렉터리를 볼 수 있습니다.
EDITOR를 작성하기 위해서
먼저 일반적인 Hello World 프로그램을 사용했습니다. 이 프로그램은 프로그램에 대해 244라인의 유리한 이점을 제공했습니다. 프로그램이
SIP와 제대로 작동하도록 일단 수정이 되면, VBEdit과 동일한 작동을 얻기 위해서 약 200라인이 다시 필요합니다. VBEdit에 대해서는
3개의 ActiveX 컨트롤의 도움말을 포함하여 단 132라인의 코드가 필요합니다. 순수한 코드 라인의 관점에서 보면 Visual Basic이
앞서 있습니다.
하지만 최종 실행 이미지의 관점에서 보면 Win32 기반의 프로그램이 확실하게 앞서 있습니다. CPU별로
8-10KB에서 측정해 보면 Win32 기반 프로그램의 footprint가 훨씬 작습니다. 토크 표시된(컴파일된) 버전의 Visual Basic
코드의 크기는 8KB에 불과하지만 ActiveX 컨트롤을 위해 약 300KB를 추가해야 합니다. 물론 직접적인 비교를 하려면 Win32
라이브러리의 비용을 추가해야 할 것입니다.
저자는 Win32 API에 상당히 치우쳐 있습니다. 이 API는 데스크톱에서 거의
사용되지 않지만(현재 전체 개발의 5% 정도가 Win32를 사용) 저자에게는 Windows CE 기반의 개발을 위해 가장 선호하는
API입니다.
MFC?새로운 Windows API
1985년에 Microsoft에서 최초의
Windows 운영 체제를 소개했을 때는 사용이 쉽도록 설계된 환경이었습니다. 하지만 코드 작성이 쉽도록 설계된 환경은 아니었습니다. 이 때문에
Microsoft에서는 프로그래머의 효율성을 위해 MFC 라이브러리를 만들었습니다.
MFC는 C++에서 액세스할 수 있는
Windows API를 개체 지향적으로 캡슐화해 줍니다. 또한 MFC는 Win32 API의 수많은 까다로운 문제를 숨겨주는 프레임워크를
제공합니다. 동시에 MFC에는 특정한 유형의 복잡성이 도입되어서, 다소 학습이 어려울 수도 있습니다. 하지만 이 문제는 다양한 형태의 마법사로
사용할 수 있는 도움말 유틸리티에 의해 어느 정도 해결될 수 있습니다. 이 유틸리티는 메시지 핸들링, COM, ActiveX 핸들링 및 자동화
등을 구성합니다. 또한 한 가지 예를 들면 CString 문자열 클래스와 같은 다양한 도움말 클래스가 있습니다. 이 클래스는 복잡한 작업의
처리를 현저히 간소화합니다.
Windows CE에서 MFC 프로그래밍과 관련된 한 가지 문제는 런타임 라이브러리의 크기와 관련이
있습니다. Pocket PC 플랫폼에서 mfcce300.dll의 크기는 276KB(x86 프로세서 기반의 장치)에서 506KB(Power PC
기반의 장치)입니다. 물론 재배포 가능 요소(redistributable)가 ROM에 존재하는 플랫폼에서는 이것이 그다지 문제가 되지 않습니다.
Pocket PC 및 HPC Pro와 같은 장치가 바로 이 경우입니다.
두 번째 문제는 여러 버전의 MFC 라이브러리가 존재한다는
점입니다. 실제로 이 문제는 DLL Hell의 원인 중의 하나입니다. DLL Hell은 모두 동일한 이름을 가지는 라이브러리 집합에서 비슷하지만
약간씩 다른 서비스를 가지는 라이브러리가 많을 경우에 발생하는 문제입니다. Windows CE의 HPC Pro Edition에서는 MFC
라이브러리의 이름이 mfcce211.dll입니다. 이 문제는 해결이 불가능하지는 않지만, 소프트웨어 테스트 및 구축 팀에게 시간과 노력이
요구되는 복잡한 문제입니다. 이 문제를 초기에 다루지 않을 경우에는 지원 및 교육 그룹에게 문제가 넘겨질 뿐입니다.
Win32를
사용할 것인가 아니면 MFC를 사용할 것인가 하는 문제는 특정 시점에서 기존 코드 베이스와 개발 및 지원 인력을 고려하게 됩니다. 데스크톱용
Windows 프로그래밍에서 Windows CE용 MFC 프로그래밍으로 전환했던 MFC 프로그래머는 일반적으로 양호한 결과를 보고하고
있습니다.
ATL?인터넷 구동 구성 요소
1995년 Microsoft의 한 친구는
Microsoft에서 인터넷 구동 구성 요소를 만들기 위한 새로운 소규모 라이브러리를 출시할 준비가 되었다고 알려 주었습니다. 물론 이
라이브러리는 ATL이었으며 지금까지 오랫동안 사용되고 있습니다.
COM은 현재 공급되는 모든 Microsoft 운영 체제에서 매우
중요한 기술입니다. 사용자는 COM 개체를 Win32, MFC 또는 ATL과 같은 모든 형식에서 구현할 수 있습니다. Win32를 사용하는 한
가지 이유는 가장 효율적이고 간단한 방법을 제공하기 때문입니다. Win32의 단점은 복잡한 ActiveX 구성 요소를 만드는 경우 사용할 수
있는 지원이 많지 않다는 점입니다.
MFC도 한 가지 옵션이며, MFC의 ActiveX 지원은 매우 우수합니다. MFC 응용
프로그램을 만들 준비가 이미 된 경우, MFC에서 내장 COM 지원을 사용하는 것이 상당히 합리적입니다. 하지만 이전에도 말했듯이, MFC에는
런타임 라이브러리가 오버헤드로 존재합니다. MFC의 구조로 인해서 COM에 필요한 특정 조각을 잘라내고, 실제로 필요하지 않은 조각을 남겨두는
것이 어렵습니다. 따라서 간단한 COM 개체를 만들려는 경우에는 MFC의 오버헤드로 인해서 파일 시스템에서 값비싼 메모리를 사용하는 것이
적합하지 않습니다.
ATL은 C++ 템플릿 라이브러리의 경량성과 결합된 개체 지향 C++ 방식의 이점을 제공하기 위해
만들어졌습니다. ATL 구성 요소는 필수적인 Win32 구성 요소보다 약간 무겁습니다. 하지만 사용자는 지원 코드를 구성하고 만들어 주는 마법사
형태로 eMbedded Visual C++ IDE에서 도움을 얻을 수 있습니다.
한 가지 장점은 ATL을 사용하여 Windows
CE에서 실행되는 ActiveX 구성 요소를 만들 수 있다는 점입니다. 또한 ATL을 사용하여 eMbedded Visual Basic에서
실행되는 ActiveX 컨트롤을 만들 수 있습니다. 하지만 ActiveX 컨트롤용 코드 자체는 Visual Basic이 아니고 ATL
라이브러리에서 템플릿을 사용하는 C++가 것입니다.
결론
Windows CE 기반의 응용 프로그램을 만들기 위해 어떤 API와
도구를 사용할 것입니까? 모든 사람은 각자 선호하는 API와 도구가 있으며 저자도 선호하는 API와 도구가 있습니다. 사용자가 선호하는 API가
Windows CE에서 지원되는 경우, 사용자는 틀림 없이 이 API를 사용할 것입니다. 하지만 좋은 도구를 사용하는 것이 작업의 핵심은
아니며, 일정과 예산 범위에서 우수한 소프트웨어를 공급하는 것이 중요하다는 사실을 기억해야 합니다.
가장 성공한 소프트웨어
개발자라고 해서 반드시 모든 도구를 완전하게 알고 있고 작업에 가장 적합한 도구를 선택한다고는 생각하지 않습니다. 사용자는 언젠가 이 도구들을
모두 사용해 볼 것입니다. 대부분의 경우 사용자는 두 개 이상의 도구를 동시에 사용할 것입니다. 결국 Win32를 사용하기 위해서
eMbedded Visual Basic은 한층 강화되었습니다. MFC는 Visual Basic과 Win32 사이의 합리적인 절충안을 제공합니다.
또한 ActiveX 컨트롤을 만드는 경우 ATL은 우수한 기반을 제공합니다. 결론적으로 Windows CE용 프로그래밍을 시작하는 사용자는
저자와 마찬가지로 수많은 선택권을 가질 수 있습니다.
Paul Yao는 Windows 프로그래밍
및 Windows CE의 전문가이며, Windows 프로그래밍과 관련되어 최초로 출판된 저서의 공동 저자입니다. 그의 회사는 Windows 및
Windows 관련 기술을 전문적으로 교육하고 있습니다. 자세한 정보는 웹 사이트(http://www.paulyao.com/)를 참조하십시오.
? 최종수정일: 2001년 1월 8일
|
Top of Page
