Windows CE

1. Windows CE란( What is Windows CE? )

Windows CE는 지능적인 작동을 요구하는 가전 기기, 제어 장치 및 휴대용 장비를 운영하기 위해 개발된 작고 이식성이 뛰어난 OS이다.

2. Windows CE를 배워야 하는 이유

새 술은 새 부대에 담아야 하듯 Desktop과는 다른 환경을 지니는 모빌컴퓨터 환경에는 그에 적합한 OS가 필요하며 Windows CE는 현재 Java와 더불어 모빌 컴퓨터의 OS로 주목받고 있다. 문제는 두 OS중 대세가 무엇인지를 예측하는 것이데. 개인적으로는 2가지 이유에서 Windows CE가 승자가 될 것으로 생각된다. 첫째, 모빌 컴퓨터는 Desktop PC와 전혀 무관하게 사용될 수 없다. 모빌 컴퓨터는 Desktop과 유기적으로 Data를 교환해야 하는데 이미 Windows 환경은 Desktop환경의 표준이며 이를 계승하는 Windows CE는 사용자에게 별 거부감 없이 받아들여 질 것이다. 둘째, MS가 적극적으로 지원하기 때문이다. 과거의 전적으로 볼 때 MS는 모빌 컴퓨터 환경에서 역시 독점적인 위치를 확보하려 전력 투구 할 것이며 이런 MS를 막기란 쉽지 않을 것이다. 설령 Java가 초기에는 Windows CE에 비해 우위에 있을 수 있을지라도 결국에는 Browser싸움의 경우와 마찬가지로 Java를 수용한 Windows CE가 최후의 승자가 되지 않을까 생각된다. Windows CE는 Win32를 계승하므로 이미 많은 응용 프로그램 개발자를 확보하고 있는 셈이다. 결국 OS가 살아남기 위해서는 OS를 지원하는 응용 프로그램이 많아야하는데 Windows CE는 이런면에서 Java에 비해 우월한 위치에 있다.

3. Windows CE를 이용하는 장치( Which devices benefit from Windows CE ? )

1996년 9월 16일 페가수스로 명명되었던 Windows CE를 발표하면서 MS는 Windows CE가 다음과 같은 분야에서 사용될 수 있다고 발표했다. 소형 모빌 컴퓨터(HPC, Wallet PC, Palm PC, Auto PC), 무선 통신 기기(디지털 호출기, 셀룰러 폰), 차세대 오락/멀티미디어 기기. 특수 목적용 인터넷 접속기(인터넷 TV, 디지털 셋탑 박스)등 정보화 기기에서 사용될 수 있다고 발표했다. 현재 Windows CE를 이용한 제품이 발표되었으며 많은 업체가 Windows CE의 지원을 약속하고 있다. Windows CE가 사용되는 대표적인 분야는 Handheld PC, Palm-size PC, AutoPC이다.

4. Windows CE의 특징(Windows CE Overview)

1) 순수 32비트 운영체제로 크기가 작다.

2) Win32 API의 Subset을 사용한다.

3) 여러 종류의 CPU를 지원한다.

4) 데스크탑과 동일한 개발환경 지원.

5) 모듈성이 강하다. : Windows CE는 60개 정도의 컴포넌트로 이루어졌으며 이들을 H/W에 맞게 적절히 결함하여 OS를 구성할 수 있다.

6) 이식성이 좋다. : 다음과 같은 프로세서를 지원한다.

회사
프로세서

AMD
x86, SC400

히타치
SH3, SH4

IBM
PowerPC

Intel
x86

모토롤라
MPC821

NEC
Vr4100, Vr4102, Vr4111, Vr4300

필립스
R3910, Poseidon

도시바
TX3912





7) 통신기능 지원이 좋다 : HPC에는 Windows CE의 연결성이 잘반영되는데 적외선 포트, 시리얼 포트, 타입-II PC 카드 슬롯을 지원한다. 적외선 포트는 HPC간 무선 통신용, 시리얼 포트는 HPC와 Desktop PC간 파일의 동기화에 사용된다. Windows CE는 TAPI와 WinSock을 지원한다.

5. Windows CE를 실행하기위한 H/W조건

Windows CE를 실행하기 위해서는 최소 256KB ROM, 350KB RAM, 32-Bit CPU와 내부 스케줄링을 위한 Timer가 필요하다. 그러나. 대체로 사용자의 요구를 처리하고 그 결과를 출력하기 위한 입출력 기능을 추가하기 위해서는 1.5-2.5MB ROM이 필요하다.



Introduction to Windows CE Software Development Kit

Windows CE는 Communication, Entertainment, mobile computer에 이르는 광범위한 장치의 OS를 위해 디자인된 open and scalable Windows OS이다. WindowsCE의 융통성있는 modular구조로 다양한 형태의 소형장치에서 사용되기 위한 요구를 충족한다.( Windows CE는 Modular한 성격을 지닌다)

Window CE는 Win32를 채택하여 Windows CE-based device와 Windows NT-base Desktop간의 호환성을 보장할 수 있도록 했다. Windows CE SDK는 Win32 SDK로부터 파생되었으므로 Win32에 익숙한 개발자는 적은 노력으로 Windows CE프로그램을 개발할 수 있으며 사용자에게는 Windows와 유사한 look and feel을 제공한다.(Windows CE SDK는 Win32로부터 파생되었으며 그로인해 개발자와 사용자 모두에게 이익을 준다)

그러나, Windows CE는 Win32와는 다른 특성 또한 지니고 있다. The small-factor diskless H/W의 제약으로 인해 system resource를 사용하고 관리하는데 제약이 따른다. API의 option에 제약이 있고 때에따라서는 새로운 함수, 구조가 제공된다.(Window CE는 Win32를 기반으로 하였으나 Windows CE가 동작하게 될 H/W의 소형화 특성상 Win32 API사용에 제약이 따를 수 있으며 Win32에서는 제공되지 않는 새로움 함수가 제공되기도 한다)

Windows CE SDK는 다음과 같은 category로 구성된다. System Service, User Interface, Communication, Desktop Connectivity, Application Interface, COM-Based Object Services

Windows CE Operating System Architecture

Windows CE는 몇 개의 중요한 software module로 구성되어 있으며 이들간에는 Win32 compatible interface를 통해서 통신한다. 각 모듈은 많은 종류의 configurable component를 포함하고 있어서 feature-level service를 제공한다.

Windows CE Kernel, Windows CE Graphics Windowing and Events subsystem. Kernel은 thread, memory, resource를 관리하며 DLL을 이용함으로써 메모리 효율을 높힌다.

GWE module은 Windows NT User와 GDI가 결합되어 줄어든 형태로 볼 수 있다. GWE는 2-bits-per-pixel color display, overlapping windows, event management, controls, interprocess communication, and UNICODE를 지원한다.

Windows CE의 나머지 부분은 shell, file system, perdistent storage, database, communication, desktop connectivity, internet browsing, e-mail, and COM-based object service같은 부가적인 서비스를 제공한다.( Windows CE는 몇 개의 module로 구분될 수 있다. Kernel은 Thread와 memory를 관리하는 기능을 하며, GWE는 Graphic과 Event와 관련된 서비스를 제공한다)

Aboud System Service

Windows CE SDK는 application developer에게 메모리를 관리하고, notification을 사용하고, object store를 조작하고, power consumption을 최적화하고, GDI나 MGDI를 이용해 프로그램을 작성하는 방법을 제공하는데 이를 system service라고 한다.(당연히 system과 관련되 API을 SDK에서 지원해야 한다)

About Managing Memory

Windows CE는 두가지 형태태 ROM과 RAM을 지원한다. backup battery는 RAM을 non-volatile메모리로 만든다. ROM에는 DLL, 번들 프로그램, 리소스가 들어있다. RAM은 storage memory와 program memory로 나뉜다. storage memory는 registry와 file system이 사용하며 파일시스템 속의 모든 파일은 압축되어 저자된다. 프로그램 메모리는 시스템과 실행중인 프로그램에 의해 stack과 heap으로 사용된다. storage memory와 program memory에 대한 partition은 사용자가 정의한다. Windows CE는 번들 프로그램과 user installed program을 서로 다르게 처리한다. 번들 프로그램은 ROM에서 직접 실행하며 user-installed program은 파일 시스템에 압축된 형태로 저장되어 있다가 실행될 때 프로그램 메모리로 압축이 풀리면서 load되서 실행한다.

Windows CE는 on-demand paging의 가상메모리를 지원한다. 시스템은 사용가능한 메모리를 확인하여 limited memory condition이 발생하지 않게 한다.

Windows CE는 서로 다른 형태의 메모리(stack, heap, static and virtual memory)에 대한 할당, 해제, 모니터링을 위한 함수를 제공한다.

(Windows CE는 일반적으로 시스템의 자원이 제한된 영역에서 주로 사용되게 되므로 메모리를 효율적으로 사용하는 것은 매우 중요하다. Windows CE는 ROM과 RAM을 가지고 있는데 ROM은 시스템과 관련된 실행 파일과 데이터가 저장되고 RAM에는 사용자가 설치한 프로그램이 저장되고 실행되는 역할을 한다. RAM은 Registry와 FileSystem을 포함하는 Storage memory와 프로그램을 실행하기 위한 program memory로 나뉜다. storage memory에는 사용자가 설치한 파일이 압축된 형태로 저장되며 실행될 때는 압축이 해제되면서 program memory로 load되어 실행된다.)

About Using Windows CE Notifications

Notification은 시스템이 어떤 사건이 발생했음을 사용자나 application에 알려주는 signal이다. 이때 event는 시스템 event나 timer event가 될 수 있다.

Notification은 LED가 깜빡이거나, Dialog Box, sound가 실행되거나 기계적인 진동이 있을 수 있다. 전형적인 notification application은 schedule book이 된다. 사용자가 설정한 날짜와 시간에 대해 시스템이 이를 감지하면 taskbar에 icon을 만들 게 된다. Windows CE SDK는 event에 대한 notification에 대해 event에 대한 notification을 등록하거나, notification의 state를 결정하거나, option을 선택하거나, event를 처리하거나 하는 따위의 많은 API를 지원하게된다.

(notification에 대한 처리는 Windows 프로그램에서 새로운 사실이 아니다. 단지 시스템이 직접 notification을 처리할 수 있다는 것과 notification을 발생하는 level이 약간 다를 뿐이다. 어째든 Windows CE가 휴대용 장비에서 사용된다면 notification은 자주 사용될 것이다)

About Managing Power Consumption

Windows CE는 battery를 가능한 지속시키기 위해 능동적인 power management를 지원한다. OS는 현재 장치의 동작상화에 따라 적절한 power consumption level을 자동으로 선택한다. Windows CE는 full-speed mode, idle, suspend mode를 지원하다. 게다가 Windows CE power management system은 battery의 life time을 모니터 해서 사용자에게 battery를 교체해야할 시점을 알려준다.

(Windows CE가 Windows와 다른점은 이 Power Management에 관한 점이다 )

About Object Store

Object Store는 Windows CE에서 영구적인 데이터를 저장하기 위한 장치로 사용된다. 물리적으로는 non-volatile, battery-backed RAM이 사용된다. Object Store는 3개의 기본 요소를 지닌다.

File System : 3가지 형태의 file system이 사용된다. ROM-based file system, RAM-based filesystem, diskdrive, flash memory, SRAM을 위한 FAT file system이 그것이다. working directory에 대한 개념만이 다르고 모두는 유사하다.

The Registry :

Database : Windows CE는 built-in database manager가 있다. 이 database는 single-level hierarchy만을 지원하며 다중 database가 허용된다. Windows CE Database System API는 object searching과 sorting같은 기능을 지원한다.

Windows CE는 Object store에 대해 Transaction mode로 동작해서 accidental system interrup에 대해 data를 보전하게 된다.

About GDI

Windows CE의 GDI는 장치에 독립적으로 graphical output을 출력하기 위한 함수와 관련된 구조체의 집합이다. 이 함수들은 Win32 GDI와 매우 유사하다.

About Process and Threads

Windows CE는 multithreaded Win32 프로그래민 모델을 제공한다.Windows CE는 선점형 멀티 태스킹으로 priority-level에따라 스케줄링하게 된다. 동일한 priority를 지니는 process간에은 동일한 CPU시간을 sharing하지만 low priority process는 high-priority process에게 양보한다.

비록 Windows CE Kernel이 single address space만을 지원하지만, 다른 프로세스가 서로 간섭되는 것을 방지한다.

About User Interface Service

Windows95나 Windows NT와 마찬가지로 Windows CE에서 control은 사용자가 응용프로그램과 데이터를 교환하기 위한 친근한 인터페이스를 지원한다. Windows CE interface는 shell, windowing environment, windows control, common control, menu, dialog box와 다른 control을 지원한다.

About Windows CE Shell Service

Windows CE Shell은 OS의 입장에서는 사용자 인터페이스이며 desktop window, command bar, task bar, control panel과 recycle bin을 포함하고 있다. 이런 control들은 모든 응용프로그램에서 공통으로 사용되며 shell은 문서를 access하고, 응용프로그램을 실행하고, task간 전환, file system을 browsing 등에 대해 편리한 사용자 인터페이스를 제공한다. Windows CE 의 Shell은 Win32 Shell API의 Subset이며 몇 개의 새로운 함수가 Windows CE에 추가되기도 했다.

Shell Notification API는 응용프로그램의 이름과 event를 시스템에 등록할 수 있도록 해 특정한 event가 발생하면 그와 함께 등록된 응용프로그램을 실행하도록 한다. shell은 system resource를 coordinate하는 책임이 있다.

(Shell의 기능은 사용자에게 응용프로그램을 실행하거나 관리할 수 있는 기능을 제공하는 것으로 Windows CE에서 사용하는 Shell은 Win32 Shell API가 기반이된다. Shell은 또한 notification과 system resource를 관리하는 책임을 가지고 있다)

About Windowing Environment

Windows CE SDK는 application's user interface가 생성되고, 해제되고, 관리되어지는 window environment를 구성할 수 있는 많은 API을 제공한다. Windows CE application's user interface에는 caret, clipboard, cursor, icon, keyboard accelerator, keyboard input, message and message queue와 window control이 있다.

(Windows란 용어가 의미하듯이 window 환경을 지원하기 위한 충분한 API를 지원해야 한다. 즉 window을 생성,해제,관리할 수 있는 기능과 window와 관련된 interface( caret, cursor, icon, keyboard accelerator, keyboard input, message, message queue와 같은 것을 지원하게 된다)

About Communications

Windows CE는 다른 장치와 communication하기 위한 standard Wind32 interface를 지원한다. 이런 API 다음과 같은 기능을 하게 된다. 1. serial or dial-up LAN을 통해 desktop PC와 통신한다. 2. IrDA protocol을 사용해 적외선 통신을 지원한다. 3. serial device간의 standard communication 4. modem간 standard communication 5. internet에 대한 standard communication 6. remote file access에 대한 지원.

Windows CE communication API는 다음과 같은 6개의 categories로 구분된다. 1. WinSock의 subset, 2.Remote File Server connection and management. 3.Wind32 serial function 4. networking function 5. internet client service 6. a subset of TAPI

(Windows CE는 충분한 communication기능을 가지고 있어야 한다. Windows CE의 용도가 휴대용 장치를 동작시키기 위한 목적으로 사용되므로 장치간의 원활한 데이터 교환을 위해서는 communication기능이 반드시 필요하다. Windows CE는 desktop과의 데이터 교환을 위해 serial과 LAN을 사용하고, Windows CE를 사용하는 장치간의 IrDA통신, modem을 지원하고 Communication API는 6개의 categories에 해당하는 기능을 지원한다 )

About Desktop Connectivity

Desktop Connectivity는 다음과 같은 도구를 언급한다. 1. File Filter, 2.Tools for importing and exporting file. 3.RAPI 4.Functions for enabling a RAPI client to request services from RAPI server 5. Application setup tool 6. For installing a Windows CE application from a desktop PC 7. Connection manager 8. establishing and maintaining the connection between the desktop application and the Windows CE device

About Application Interface

Windows CE는 built-in application이 있다. Contacts, A database application for personal information management, inbox, a mail application to provide users with access to electronic mail

About COM-Based Object Services

COM-based Object Service는 Microsoft Component Object Model에 기반한 software component의 object-orient development에 관한 함수와 구조체에 대해 기술한다. 2종류의 service가 있다. 1.COM 2. Automaion

(잘 모르겠다).

Functions, Macros and Structures Used in Hello Windows CE

Hello Windows CE라고 불 리는 프로그램를 예로 standard Windows Programming과 Windows CE프로그램밍의 다른점을 기술한다.

The Windows CE WinMain Functions

다른 Windows-base program과 마찬가지로 WinMain은 Windows CE 응용프로그램의 entry point가 되며 다르것과 마찬가지로 4개의 입력파라메타를 전달받게 된다.(약간 차이가 있음)

hInstance . 이 program에 대한 handle. Windows-based program과 동일하다.

hPrevInstance. Windows CE에서는 사용되지 않으며 항상 NULL이 된다.

szCmdLine. Command Line 파라메타로 UNICODE에 적합하게 wide string에 대한 pointer가 된다. LPSTR에서 LPTSTR로 바뀌었다.

nCmdShow. 어떻게 Window가 display되야 하는지를 결정하는 flag. Windows CE는 Windows 95가 지원하는 모든 flag를 지원하지는 않는다.

(WinMain( )이 entry point로 사용되나 몇몇 제약이 있다. UNICODE를 사용하거나, display형태기 제한받게 된다)

Registering the Window Class for Windows CE

application이 window를 생성하기전에 RegisterClass를 호출해서 window class를 등록해야 한다. Windows CE는 WNDCLASS의 모든 항목을 지원하지 않으며 그 항목은 NULL로 setting한다. 지원되지 않는 항목은 style, hCursor, lpsaMenuName

(하나의 style만을 지원하는데 어떤 style이지? )

Initializing Command Controls

InitCommandControl함수는 common DLL이 command bar를 위해 load되도록한다.

Creating the Window

CreateWindow는 생성할 Window의 apperance와 function을 특징짓는다. Windows CE의 CreateWindow함수는 Windows 95와 동일한 함수파라메타를 사용하다. 기본으로 초기화하는 것이 가장좋은 방식이다.

Painting the Window and the Message Loop

The Window Procedure

WM_CREATE

Windows95-based program과 마찬가지로 message는 window procedure에서 처리된다. WM_CREATE message를 Windows CE가 받은 경우 2개의 Windows CE만의 유일한 함수가 호출된다. 1. CommandBar_Create. empty command bar를 생성한다. 2. CommandBar_AddAdornments. help와 close button을 command bar에 추가한다. help button이 눌리면 WM_HELP가 발생하고 close button이 눌리면 WM_CLOSE가 발생한다. CommandBar_AddAdornments는 OK Button을 추가할 수 있는데 이 버튼이 눌리면 WM_COMMAND에 IDOK가 발생한다. "Hello Windows CE"프로그램은 프로그램이 시작할 때 sndPlaySound( )를 호출한다. 이때 재생하는 사운드는 ROM에 번들로 저장되어있는 리소스를 사용한다. Windows CE는 16-bit wav file을 지원하나 추천되지는 않는다. 8-bit 11.025KHz나 그 이하의 파일을 사용하는 것이 바람직하다.

WM_PAINT

WM_PAINT는 언제 clinet 영역이 다시 그려져야 하는 지를 알려주게 된다. 예제 프로그램은 5개의 함수를 호출한다. BeginPaint와 EndPaint는 Windows95-based와 동일하게 동작한다.

WM_HIBERNATE

Windows CE장치는 low memory를 가지고 있으므로 시스템은 메모리를 모니터해 일정한 용량아래로 떨어지면 적당한 조치를 취해야 한다. 이 과정에서 중요한 역할을 하는 것이 WM_HIBERNATE 메시지다. 이 메시지는 low-mwmory situation이 발생하면 이를 응용프로그램에 알려준다.

The TEXT Macro

Hello Windows CE에서 사용되는 몇몇 함수는 text string을 파라메타로 받아들인다. 이 함수에서는 TEXT Macro를 사용해서 ANSI String을 UNICODE로 변환하고록 한다.

Porting Windows 95 to Programs to Windows CE

Windows CE로의 porting과 관련하여 언급할 주요 사항은 다음과 같다.

1. Win32와 Windows CE API간의 차이 2. Standard MFC와 Windows CE MFC간의 차이점 3.Memory제약과 out-of-memory recovery 4.Energy limitation 5. widely varying hardware characteristic and limitations 6.testing과 debugging간의 차이.

Difference Between the Win32 and Windows CE APIs

Windows CE API는 Standard Win32 API와 몇가지 중요한 차이를 보이고 있다.

1. It is similar, Win32의 subset만이 지원되며 지원되는 것 중에는 제한된 기능만을 제공하는 것이있다.

2. There are Windows CE-specific extensions, 다양한 장치를 지원하기 위한 API가 제공되며, Win32의 것을 대신하는 것도 있다.

3. exception handling에 제약이 있다. Win32의 structured exception handling은 지원하나, C++ exception handling은 지원하지 않는다.

(당연히 Windows CE는 Win32의 subset이므로 Win32중 제한된 기능만을 지원하게 될 것이며 Windows CE가 Desktop보다는 제약이 많은 시스템 환경에서 사용하게 되므로로 그런 하드웨어를 처리하기 위한 함수를 포함하고 있어야 한다 )

Difference Between Standard MFC and MFC for Windows CE

Windows CE용 MFC는 Standard MFC의 기능과 특성을 가능한 유지하고자 한다. 그럼에도 불구하고 사용할 수 있는 class와 각 class가 지원하는 특징 사이에는 큰 차이가 있다. Windows CE는 독자적인 class를 포함하고 있다. 가령 command bar control같은 기능.

(API나 MFC모두 차이가 있게지만 가능한 그 정도를 최소화 하려고 했을 것이며 이곳에서는 구체적인 예가 없으므로 매뉴얼을 찾아보는 수밖에 없다)

Memory Limitation

Windows CE장치는 일반적으로 desktop에 비해 사용가능한 메모리 양이 훨씬 적다. 대부분의 경우, 성공적으로 포팅을 하기 위해서는 메모리를 줄이는 것이 중점을 두어야 할 필요가 있다. 따라서, 자주 사용되는 기능만을 포함한 츠로그램을 작성하는 것이 프로그램의 사이즈를 줄이는 데 도움이 된다. 프로그램은 가능한 적은 메모리를 사용하는데 중점을 두어 작성하여야 한다. 또한 메모리를 관리하기 위해 시스템과 협력해야 한다.

(가능한 메모리를 아끼면서 프로그램을 작성하여야 한다. 불필요한 기능과 쓸데 없는 리소스를 배제하고 코드를 최적화하는 것이 필요하리라, Windows CE에서는 최소한의 메모리를 사용하는 것이 매우 중요하다. )

Energy Limitation

Hardware Characteristics

Windows CE는 desktop에 비해 smaller and less powerful한 장치에서 동작하기 위해 설계되었다. 예를 들어, screen이 작고, CPU는 느리고, 사용자 인터페이스는 less flexible하다. 반면 desktop에서는 지원되지 않는 장치를 Windows CE 장치에는 부착된 경우가 있다. 따라서 프로그램을 포팅할 때는 모든 장치에서 공통으로 사요할 수 있는 부분이 무엇이고 아닌지를 알아여 한다.

Testing and Debugging

Windows CE용 프로그램을 작성하는 것은 Win32프로그램을 작성하는 것과 매우 유사하다. 그러나, testing 과 debugginbg시에 중요한 차이가 있다. 만일 Windows CE영 프로그램을 작성한다면 대부분의 test와 debugging이 eulator에서 이루어 지게 된다.

A Systematic Approach to Porting Application to Windows CE

Porting to the Windows CE

만일 application Win16-based이면 일단 이를 Win32로 변환하는 것이 좋다. Win32는 하위 호화성을 유지하나 Windows CE는 그렇지 못하다. application에서 사용된 모든 API를 면밀히 검토해 Windows CE와 campatible하지 않는 것은 개조하거나 변경한다. 1. Win32함수가 지원되지 않을 수 있다. 2.Win32함수가 Windows CE equivalents로 대체된 것이 있다. tool and menu bar combined into a single command bar. 3.Win32가 지원되나 기능에 제약이 따른다. 4.지원되는 데이터 형의 변경이 필요하다. 5.몇몇 메시지가 지원되지 않는다.

(Win32프로그램을 Windows CE프로그램을 포팅하는 것은 그리어려운 작업은 아닐 것이다. 일단 Win32의 subset을 Windows CE가 사용한다(비록 부분적으로는 API에 제한이 있을지라도)

Managing Windows CE Memory

사용가능한 메모리는 장치에 의존적이므로 target platform의 용량을 확인해야 한다. Windows CE는 메모리를 사용하거나 mass storage를 동일한 방법으로 사용한다.

Windows CE프로그램에서는 메모리와 storage의 사용을 줄여야 한다. bitmapped-graphic같은 memory-intensive feature는 간단히 하거나 제거하는 것이 좋다. 정말필요하지 않으면 temporary file은 사용하지 않는다. 메모리 리소스가 tight해지면 Windows CE는 메모리 사용을 줄이고 사용가능한 메모리를 일정 수준으로 복귀하는 과정을 거치게 된다. 이런 프로시져는 WM_HIBERNATE 메시지로 이루어 진다. WM_HIBERNATE가 어떻게 동작하는지는 Managing Memory Section에서 언급한다.( Windows CE에서 가장 중점을 두어야 하는 부분은 메모리 관리에 관한 부분으로 가능한 불필요한 코드를 제거하고 메모리를 복귀시키는 부분을 코딩해야 한다)

Managing Available Power

Porting the Graphics Device Interface

대부분의 PC 응용프로그램들이 Windows CE에는 적합하지 않은 GDI를 가지고 있다. 따라서, 포팅전에 수정이 필요하다. OS를 작게 만들고 H/W의 제약에 의해 많은 Win32 GDI함수가 지원되지 않고 제약이 따른다. Windows CE 2.0과 함께 GDI Subsystem은 MGDI로 바뀌었다. MGDI는 전혀 새로운 display subsystem을 지원하며 이는 Windows NT에 가까운 기능을 제공한다.( 메모리 및 H/W의 제약에 따라 지원되지 않는 GDI함수가 많거나 지원한다 하더라고 사용상의 제약이 많다. Windows CE 2.0에서는 기존의 GDI를 변경한 MGDI를 사용한다)

Adapting Bitmaps and Icons

Windows CE장치는 Desktop PC에 비해 적은 스크린과 aspect ratio를 지니고 있다. 이런 제약조건에 적합하게 응용프로그램에 대한 수정이 불가피하다. 그러나, static layout를 사용하지 않는 것이 좋다.

Using Unicode

Windows CE는 UNICODE System이다. 비록 text file의 exchange를 지원하나, native format은 UNICODE이다. ASCII Code를 Unicode로 변환하기 위한 guideline은 다음과 같다.

Tchar.h를 포함한다.=> C run-time함수보다 Win32 string function을 사용한다. => TCHAR, LPTSTR를 사용해 쉽게 ASCII나 UNICODE로 compile한다.=>TEXT Macro를 string literal에 사용한다.=>문자가 더 이상 한 바이트가 아니다. 문자의 끝이 2바이트의 0으로 되어 있다. => array pointer나 char count를 증가시킬 때 sizeof(TCHAR)를 사용한다.

(UNICODE를 사용할 때의 주의할 점이 위에서 언급하고 있다)

Creating and Managing Windows

Windows CE에서 Window를 생성하고 관리하는 것은 Win32에서와 매우 동일하다. 그러나, 적은 window style과 manage option만을 가지게 된다. 아마도 가장 큰 차이점이라면 window가 이동할 수는 있지만 resize가 불가능한 점이다. window는 window가 생성될 때 설정된 size값을 지니고 있게 된다. Resize가 불가능하다는 것은 WS_OVERLAPPEDWINDOW가 지원되지 않는다는 의미이다.(WS_OVERLAPPEDWINDOW가 지원된다고 본 것같은데?)

Using Windows CE Dialog Box

Windows CE는 modal, modeless와 Windows95에서 제공하는 control을 지원한다. 그러나, 모든 control style이 지원되지는 않는다. Windows 95에 비해 적은 option을 지니지만 MessageBox를 지원한다.

Porting User Interface Controls

대부분의 standard Windows control과 common control이 지원된다. 그러나, 몇몇 제약이 있다. 가장큰 차이는 menu와 toolbar가 command bar로 통합된 점이다.

Managing Windows CE thresholds

Windows CE는 multithreaded OS이다. 그러나 Windows95/NT에 비해 몇몇 제약이 있다. 가장 큰 제약은 semaphore를 지원하지 않는다는 것이다.

Modifying the User Interface

Supporting Windows CE Communications

Windows CE는 다음과 같은 4개의 communication API를 지원한다.

.WinSock .TAPI .RAS .Serial Communication

Network Support Via Winsock

Windows CE Network Stack은 TCP/IP를 지원한다. 만일 응용프로그램에서 network traffic을 다루기 위해 winsock을 호출하였다면 거의 변경이 필요없다. IrDA specification은 WinSock annex로 부가되었다.



Managing Memory

비록 Windows CE가 개발자에게 복잡한 graphically oriented application을 개발할 수 있는 많은 tool을 제공하지 만 그런 응용프로그램은 많은 양의 RAM을 요구한다. HPC는 desktop에 비해 제한된 메모리를 지니며 이런 제한된 환경에서 성고적인 프로그램을 작성하기 위해서는 프로그램을 변경해야 한다.

Overview of Memory On the HPC

Windows CE는 가상 메모리를 가지고 있다. 이는 memory가 at granularity of a page로 할당된다. page는 OEM종속적이다. (1KB or 4KB) 사용자는 PCMCIA를 사용해 메모리를 추가할 수 있다. OS와 번들 프로그램은 ROM에서 in place로 실행된다. 이런 프로그램과 관련되서 stack, heap storage와 관련된 적은 양의 메모리만 필요하나 data와 관련된 경우에는 다른 곳이 저장된다. 2MB가 최소의 메모리 요구사항이나. 대부분의 업체는 그 이상을 공급한다. 4MB가 desktop에 비해 적은 양이나 이또한 program실행을 위해 사용되지는 않는다. HPC의 경우는 disk가 없으므로 RAM이 데이터를 저장하기 위한 공간으로 사용된다. RAM의 효과적인 사용이야말로 HPC용 프로그램을 개발하기 위한 가장 중요한 사항이다.

The Basic Layout of RAM on the HPC

RAM은 두 개의 영역으로 구분된다. Storage memory, Program Memory.

Storage Memory

Storage Memory는 desktop PC의 RAM disk와 유사하다. 이는 data와 non-system application을 저장하기 위해 사용한다. Storgae memory의 3가지 section은 서로 다른 Win32 API를 이용해 access된다.

1. The Windows CE system registry는 Windows 95나 Windows NT와 유사하다. Standard Win32 registry function을 사용한다. 2. 응용프로그램과 data는 file storage에 저장된다. 3. database관련.

Using Windows CE Registry

메모리 요구량을 줄이고, access time을 줄이고, registry key size를 제한하기 위해 다음과 같은 guidline을 따른다.

.각 key의 이름을 제한한다 .subkey level을 제한한다.

.null name을 사용하지 않는다 .많으면서 적은 크기의 registry value를 사용하지 않는다.

.Window95의 key-naming convention을 사용할 필요가 없다.(사용자가 볼 수 없으므로)

Program Memory

Program memory는 system and non-system program의 stack과 heap을 위해 사용된다.

Windows CE Address Space

Program Memory가 관리되는 것을 이해하기 위해서는 먼저 Windows CE의 메모리 구조를 살펴봐야 한다. Windows CE가 초기화될 때에는 4GB의 메모리가 할당되고 모든 progess에 의해 공유된다.이 주소는 kernel에 의해 실제의 메모리로 사상된다. version 1.0에서는 주소 공간이 33개의 32MB"slot"으로 나위었다. 이 slot외부의 데이터를 access하면 access violation을 발생한다. 각 process에는 개별 slot이 할당되며 slot zero는 현재 실행중인 process를 위해 예약되었다( 무슨 소리?)

Memory Paging

Memory는 at the granularity of a page로 할당된다. Page size는 OEM종속적이다. 현재는 1KB나 4KB가 할단된다. Version 1.0에서는 RAM-resident code와 data page는 application이 실행되는 동안 program memory로 load되어 실행된다. Version 1.01은 RAM-resident application에 대한 demand paging을 지원한다. demand paging과 함께, 만일 RAM의 shortage가 발생하면 kernel에 의해 현재 실행되지 않는 page는 제거되었다가 필요시에 다시 load된다. kernel은 어떤 page가 least need한지를 비교하지 않고 무작위로 없앤다. PCMCIA Card의 메모리에 대해서는 demand paging이 지원되지 않는다.(version 1.01) 이 경우에는 모든 프로그램이 Program memory로 load되어 실행된다.

Writing Mmory Efficient Application for Windows CE

Memory Pages

평균적으로 한 page의 절반 가량의 메모리가 낭비되므로 larger page는 더 많은 메모리를 낭비하게 된다. 작은 page size는 많은 OS overhead를 요구한다. It also decrease the amount of memory that can be addressed from the translation look aside buffer(TLB)-potentially reducing its effectiveness. 주어진 장치의 실제 메모리 size는 OEM-dependent하다. RAM usage는 major concern이므로 page size는 가능한 작게 유지된다.현재는 1KB나 4KB가 page size로 사용되며 a good rule of thumb는 memory allocation decision을 할 때에는 1kB의 page size를 사용하는 것이 좋다.

Types of Memory Allocation

응용프로그램이 메모리를 할당할 수 있는 몇 개의 독립적인 memory pool이 있다. 각 pool은 많은 갯수의 page로 구성되었으며 몇 개는 쉽게 grow나 shrink할 수 있다. 응용프로그램은 wasted RAM의 양을 최소화 하는 범위내에서 메모리를 할당하기 위해 이 pool을 사용한다.

Stack

가장 평범하게 사용되는 data storage mechanism은 stack에 data를 선언하는 것이다. stack은 1KB에서 시작해 58KB까지 메모리를 추가하게 된다. syste은 stack을 줄일 수 있으나 모든 resource가 거의 다 사용되는 경우에만 비로서 수행하게 된다. short-lived data를 위해서는 stack이 적당하나. large amount of memory를 stack에 할당하는 것은 피하는 것이 좋다.(58KB이상의 stack allocation은 access violation을 발생한다)

Static Data

static data나 global data에 대한 선언은 data를 R/W section에 저장한다. 이 section은 grow와 shrink를 하지 않는다.application's data section 은 Win32 DumoBin을 사용해 결정할 수 있다.

Virtual Memory

VirtualAlloc은 Windows CE에서 가상메모리를 지원하는 기본적인 tool이 된다. Virtualalloc을 integral number of memory page를 직절할 당하는 데도 사용할 수 있다. VirtualFree를 사용해 메모리를 free하는 경우 즉시 global virtual memory pool에 return된다. 모든 메모리 pool은 VirtaulAlloc에 근거를 두고 있다. VirtualAlloc은 단지 page만을 할당할 수 있으므로 작은 메모리 object를 할당하는 용도를 목적으로 하지 않는다. 큰 메모리 할당을 목적으로 한다면 VirtualAlloc을 사용하는 것이 가장 효율적인 방법이다. 이런 방식의 장점은 low-memory condition이 발생한 경우 메모리가 쉽게 return된다는 것이다.

Default Heap

각 process는 heap을 가지고 있으며 LocalAlloc과 LocalFree는 이에 대해 동작한다. Note that memory for the new heap is reserved but not actually committed until needed. 메모리를 할당하거나 해제하기 위해 HeapAlloc이나 HeapFree를 사용한다. 이 함수는 LocalAlloc이나 LocalFree와 근본적으로는 같으며 차이점은 HeapDestroy로 이 Heap을 해제한 후 global virtual memory pool에 복귀시킨다는 점이 다르다. 많은 수의 작은 메모리를 임시로 할당하는데 separate heap을 사용하는 것은 매우 좋은 방법이다. 메모리를 즉시 global pool에 복귀할 수 있다는 점에서. heap은 대략 500바이트의 overhead가 필요하다. 적어도 5KB의 메모리를 할당한다면 separate heap을 할당하는 것은 좋은 메모리 사용전략이 된다.

Selecting a Memory Allocation Method

다음의 criterion은 메모리 allocation method를 결정하는 데 도움이 된다.

1) 하나의 큰 메모리 allocation의 경우, VirtualAlloc을 사용한다. 2) 동일한 lifetime을 지니는 작은 데이터 item의 경우 separate heap을 사용한다. 3) 응용프로그램과 동일한 life time을 지니는 경우 static section에 저장한다. 4)함수범위내에 존재하는 경우 stack을 사용한다. 4) random overlapping lifetime을 지니는 항목의 경우, default heap을 사용한다.

Monitoring An Application's RAM Usage

현재 어느정도의 메모리를 사용하고 있는지를 알 수 있는 두 개의 도구가 있다. Map File과 Remote Memory Viewer이다.

Map File

Map File은 static section의 data를 분석하는 데 효율적이다. 각 section의 길이가 파일의 처음에 제공된다. R/W section은 두 개의 subsection으로 구성된다. .data는 초기화된 global data로 구성되며 .bss는 초기화 되지 않은 데이터로 구성된다. 또한 read-only section .rdata역시 볼 수 있다( Map File은 static data에 대한 정보를 제공한다. static data는 3가지 section으로 구분된다)

Analyzing Memory Usage with Remote Memory Viewer

일단 응용프로그램이 컴파일되고 장치로 load되면 Remote Memory Viewer는 메모리 상황을 살펴볼 수 있는 매우 유용한 도구이다. 이 프로그램은 desktop PC에서 장치의 메모리 상활을 확인할 수 있도록 해준다.

Handling Low memory Situations

Low memory situation은 다음과 같은 현상으로 응용프로그램에 알린다. 1. VirtualAlloc함수가 실패, 2. LocalAlloc or HeapAlloc함수가 heap을 grow하려고 시도하나. 실패한다. 3.stack이 grow하려고 하나 실패한다.

System Low Memory Handler

system은 항상 사용가능한 메모리를 check하고 limited memory상황이 발생하지 않도록 모니터한다. 응용프로그램이 메모리를 요구할 때 시스템은 할당하는 메모리를 제한하므로써 request를 filtering하게 된다. 이는 한 프로그램이 모든 메모리를 사용하는 것을 금지한다.

The Limited-Memory State

system은 항상 메모리 사용량을 모니터한다. 그러다, 사용가능한 메모리가 Hibernation threshold이하로 떨어지면, limited-memory체제로 들어간다. 시스템은 비동기적으로 WM_HIBERNATE message를 모든 active application에 보내기 시작하고 이 메시지는 모든 응용프로그램에게 메모리가 부족해지고 있음을 알려주게 된다. 두 개의 추가적인 threshold가 있다. low, critical . 아래의 table은 memory threshold와 maximum allowable memory allocation for the three levels of limited-memory conditions

Hibernation Threshold : system 이 limited-memory state에 들어가는 시점이 된다. WM_HIBERNATE message가 발생한다. when the system memory falls below

Low Memory Threshold : system이 low memory state에 있을 때 system이 반드시 유지해야 하는 최소한의 사용가능한 메모리.

Maximum Low Memory Allocation : system이 low memory state에 있는 경우 VirtualAlloc으로 최대한 할당될 수 있는 메모리의 양

Critical Memory Threshold : system이 critical memory state에 있을 때 시스템이 반드시 유지해야 하는 최소한의 사용가능한 메모리

Maximum Cirtical memory Allocation : system이 critical state에 있을 때 VirtualAlloc으로 할당될 수 있는 최대한의 메모리.

(무슨 소린지?)

기본적으로 시스템이 반응해야 하는 4개의 시나리오가 있다.

Request Less than the Low-memory Maximum

응용프로그램이 VirtualAlloc을 사용해 maximum allowable memory보다 적은 메모리 할당을 요구하는 경우. 비록 이런 경우의 결과 시스템의 메모리가 low-memory threshold이하로 떨어지게 될 가능성이 있는 경우 System Out of Memory Dialog Box가 Display된다. 사용자는 프로그램을 종료하거나 Program Memory의 양을 증가시킨다.

Request Greater than the Low-memory Maximum

application이 low-memory state에서 최대한 허용가능한 메모리 보다도 많은 양을 할당하고자 하는 경우. 그 결과로 시스템 메모리가 low-memory threshold이하로 떨어지면 VirtualAlloc은 실패한다. System Out of Memory Dialog Box는 Display되지 않는다. 동일한 제약이 LocalAlloc에 적용되는 것은 아니다.이는 시스템 Heap의 현재 상황에 영향을 받는다.

Requesr Less Than The Critical-Memory Maximum

application이 cirtical-memory state에서 최대 할당가능한 메모리보자 적은 메모리를 VirtualAlloc을 사용해 할당하고자 하는 경우. 그 결과 시스템 메모리가 critical memory threshold이하로 떨어질 가능성이 있으면 System Out Of Memory Dialog Box가 display된다. 사용자는 응용 프로그램을 종료하거나 Program Memory를 늘리게 된다.

Request Greater than the Critical-Memory Maximum

critical-memory maximum보다 더 많은 메모리의 할당을 요구하는 경우, 그 결과 시스템 메모리가 cirtical memory threshld이하로 떨어지면 그 요구는 실패하게 된다. 시스템의 heap의 상태에 따라, LocalAlloc의 성공여부가 결정된다.

System Out Of Memory Dialog Box

위에서 언급한 바와 같이 OS는 system out of memory dialog box를 몇몇 상황에서 display한다. 이 dialog box는 system modal로 시스템의 모든 부분을 정지시킨다.(socket connnection may hang up, other threads stop running). 이 dialog box는 사용자에게 장치가 low memory 상황임을 알리고 어떻게 처리할 것인지를 요청하게 된다. dialog box가 사라진후 어떤 선택된 응용프로그램이 마치 Close Button이 눌린 것 처럼 close된다.

Application Hibernation

system은 WM_HIBERNATE 메시지를 응용프로그램이 메모리를 해제 하기 위한 기본적인 방편으로 사용한다. 시스템에서 메모리가 필요한면 WM_HIBERNATE를 모든 혹은 일부 응용프로그램에 전달한다. 이는 오랜동안 동작하지 않는 프로그램에 우선적으로 보내며 보이지 않는 Window에는 보내지 않는다. Hibernation은 매우 중요하며 잘 동작하는 Windows CE 프로그램은 WM_HIBERNATE에 동작하게 해야 한다. application이 foreground로 실행될 때에는 시스템은 WM_ACTIVATE를 발생한다. 만일 application이 hibernating을 하고 memory를 release했어도 시스템은 이를 복구하지 않는다. 따라서 application은 WM_ACTIVATE에 대한 handler를 가지고 있어서 이 리소스를 복구해야 한다.

Handling WM_HIBERNATE

application은 WM_HIBERNATE 메시지를 받으면 다음과 같은 동작을 취하게 된다.

1. VirtualAlloc에 의해 할당된 임의의 큰 메모리 블록을 해제한다. 2. 가능한 GWES Object를 해제한다. 3.heap의 state를 저장하고 entire heap을 해제한다. 사용가능한 메모리가 줄어들수록 시스템은 WM_HIBERNATE을 increasing rate로 발생한다. 만일 시스템이 VirtualAllo이 실패하는 상황이 발생하면 stack을 줄임으로써 메모리 페이지를 해제한다. 이 stack shrink는 시스템이 맨마지막에 취한는 조치다. 이는 자칫 stack fault를 발생시킬 수 있다.stack shrink가 불가능하면 VirtualAlloc은 실패하고 그 결과가 리턴된다.

Tips for efficient Memory Utilization

Allocating Memory

16KB이상의 메모리 할당을 시도하는 것은 System Out of Memory Dialog박스나 경고없이 실패할 가능성을 항상가지고 있으므로 이에 대한 대처를 해야한다. 일단 시스템이 low-memory체계에 들어가면 8KB이상 메모리를 할당하는 것은 항상 실패할 가능성을 포함하고 있다. 또한 shutdown code에서 많은양의 메모리를 할당하지 않아야한다. 작은 메모리를 할당하는 것은 거의 실패하지 않는다. 사용자는 System out of memory dialog box을 보게 되거나 low-memory상황에 적절한 대처를 할 수 있는 기회를 지니게 된다. (8KB이상의 메모리를 할당하는 것은 피하는 것이 좋다)

Managing Data

큰 데이터를 다룰 때에도 대부분의 계산은 순서적이며 따라서 한순간에는 하나 둘 또는 세 개의 데이터만을 처리하게 된다. 예를 들어 모든 데이터를 한꺼번에 loading하는 것은 메모리의 낭비를 초래한다. 만일 대규모의 데이터를 처리해야한다면 단지 특덩한 연산과 관련된 데이터만을 load한다.버전 1.01에서는 Read-only 메모리 페이지는 시스템 자원이 부족하면 언제고 page out될 수 있다.

Using Temporary Files

가장 좋은 해결책은 Temporary File을 생성하지 않는 것이다.

Storing Data and Resource Files

Text형태나 압축되지 않은 형태로 저장된 bitmap은 메모리 사용이 매우 비효율적이다. 비록 압축을 풀고 하는 것에 시간이 걸리나 메모리를 줄일 수 있다는 점에서 가치이쓴ㄴ일이다. desktop에서 HPC로 파일이 전송될 때 어느 정도의 압축이 발생한다.

Using Graphics

graphic environment가 비록 매우 어필하는 특성이기는 하나 많은 메모리 자원을 요구한다. 따라서 가능한 graphic환경을 최소화 하기 위한 노력을 해야한다.

Providing User Feedback

비록 시스템이 low-memory condition을 처리하기 위한 기능을 가지고 있다고 해도, 모든 프로그램에 대한 이상적인 경우는 될 수 없다. 응용프로그램은 시스템이 아닌 자신의 메모리 관리 기능을 포함하는 것이 효과적일 수 있다. 가령 큰 데이터를 다운로드 받는다고 할 때 미리 시스템에 남아있는 메모리를 확인해서 다운로드의 여부를 확인할 수 있다.

Using Backup Files

Using PC-side Applications

Using Widows CE Nofitifations

Windows CE는 notification을 사용자와 응용프로그램간의 통신으로 사용한다. noification은 시스템이 어떤 사건이 발생했음을 알려주는 signal이다.

Object Store

Object store란 Windows CE가 응용프로그램에 대해 지원하는 persistent storage를 일컫는다. 예를 들어 HPC는 사용가능한 메모리에 대해 OS대한 예약된 영역이 있고 나머지 부분은 application, application run-time data, user data로 분리해서 사용된다. 이 data는 file, registry, Windows CE database에 저장될 수 있다.

Windows CE는 Object Store를 액세스할 수 있는 3개의 주요한 그룹을 가지고 있다. 1. System Registry API : Windows CE의 registry는 Windows95/NT와 매우 유사하다. Windows CE는 registry의 key와 value를 조작하기 위해 standard regristry 관련 API를 사용한다. 2.File system API : Windows CE의 Filesystem api는 Win32 Filesystem API의 subset으로 구성되었다. 이들 함수는 directory와 file을 생성하도록 하며 data를 읽거나 쓰게한다. 3.Database system API : Windows CE Database API는 Windows CE database를 생성하고 관리할 수 있도록한다. 각 database는 임의 개수의 record로 구성된다. 각 record는 one or more propertie로 구성된다.

About Object Identifiers

Object Store내의 모든 Object들은(파일, 디럭토리, 데이터베이스, 데이터베이스 레코드) 유일한 object identifier와 연관되어 있다. application은 어떤 object 에 대한 handle이라도 Object identifier를 이용해 구할 수 있다. Object store내의 object에 대한 정보를 얻기 위해서는 Winodws CE Application은 CeOidGeInfo란 함수를 호출해 원하는 object에 대한 identifier를 넘겨준다. structure에 존재하는 data는 retrive하는 object에 의존적이다. 예를 들어 object가 database record이면 CEOIDINFO 구조체의 wObjType항목은 OBJECT_RECORD를 포함하고 있으며 이는 data가 CERECORDINFO로 구성되어 있음을 의미한다. type을 알고 있으면 application은 object odentifier나 object name을 사용해 적절한 API를 호출하고 그 object에 대해 operation을 한다. Windows CE는 다음과 같은 object type과 access function을 지원한다. Windows CE는 성공적으로 object를 생성하면 object identifier를 리턴한다. 다음의 간단한 예제는 Object store내의 어떤 object라도 얻기 위해 object identifier를 사용하는 방법을 보여준다.



User Interface Service

Keyboard Input

Windows CE는 Keyboard input를 Windows 95나 Windows NT와 동일한 방식으로 처리한다. window는 keyboard input을 keystroke message형태로 받아들이며 window와 연관된 message loop는 이를 character message로 변환해야 한다. Windoes CE는 Window 95나 Windows NT가 지원하는 많은 함수를 지원한다. 그러나 desktop에서 지원하는 것과 같은 많은 key는 지원하디 않는다. INPUT구조체는 Windows NT와 동일하다. KEBDEV Structure는 지원하지 않는다. (keyboard input은 Window 95나 Windows NT에서 지원하는 것과 같은 방식으로 지원하게 된다. keyborad input이 keystroke message로 변환되어 전달된다. Windows CE에서는 Windows 95/NT가 지원하는 모든 key와 구조체를 지원하지 못한다)

Keyboard Input Functions

Windows CE는 몇 개의 Window95/NT에서와는 약간 다르게 동작하는 몇 개의 standard keyboard input함수를 지니고 있다. 또한 새로운 입력관련 함수를 지원한다. EnableHardwareKeyboard함수를 keyboard를 enable diable하기 위해 사용한다. keyboard가 disable된 경우 사용자는 keyboard가 입력됨이 않되며, 이 함수가 enabled state로 변환한 경우 menu bar, tabs, buttons and static control이 다시 그려지도록 한다. 그래서, keyboard accelerator나 관련된 정보를 display하는 방식을 변경할 수 있다.( keyboard input를 enable, diable할 수 있으며 enable되는 경우 menu bar, tab, button, static control을 다시 그리므로 enable시키면서 이와 관련된 정보를 다른 형태로 표현할 수 있다)

Windows CE에서는 GetAsynState()함수를 지원하며 이는 left right virtual key constant를 지원한다. 따라서 left right key가 눌려졌는지 검사할 수 있다. VK_LCONTROL, VK_RCONTROL, VK_LMENU, VK_RMENU, VK_LSHIFT, VK_RSHIFT가 그것이다. Windows CE에서는 VK_CONTROL, VK_LCONTROL, VK_RCONTROL, VK_MENU, VK_LMENU, VK_RMENU, VK_SHIFT, VK_LSHIFT, VK_RSHIFT의 down state를 확인하기 위해서는 GetKeyState( )함수만을 사용할 수 있다. toggle state체크 가능.

Windows CE에서는 keybd_event함수에 대해 KEYEVENT_SILENT를 추가했다. 이를 사용하면 clicking sound 없이 keystroke를 simulation할 수 있다. keybd_event를 이용하면 오랜동안 입력이 없으면 power down mode로 동작하는 기능을 금지할 수 있다. Windows CE는 KEYEVENTF_EXTENDEDKEY를 지원하지 않는다.

MapVirtualKey함수는 uMapType Parameter로 2만을 지원한다. 이는 virtual key code를 unshifted character valuefh 변환한다.

Windows CE에서는 RegisterHotkey( )함수를 위한 새로운 flag를 지원한다. MOD_FLAG, WM_HOTKEY Message가 key up과 key down event에서 window에 보내진다. WM_HOTKEY가 keyup event에 보내질 때 이는 MOD_KEYUP flag를 가지게 된다. (?) Windows95/NT와는 달리 Windows CE에서는 across thread에 대한 hotkey를 정의할 수 있다.

SendInput과 UnregisterHotKey는 Windows95/NT와 동일한 기능을 한다.

Keyboard Input Message

Windows CE는 Windos95/NT와 동일하게 대부분의 keyboard input meddage를 지원하다. 단 예외가 하나 있다. Windows CE는 scan code와 extended key flag를 지원하지 않는다. 따라서 다음의 메시지의 16-24의 값을 지원하지 않는다. 비록 이 메시지들은 동일하다. WM_CHAR, WM_DEADCHAR, WM_HOTKEY, WM_KEYDOWN, WM_KEYFIRST, WM_KEYLAST, WM_KEYUP, WM_SYSCHAR, WM_SYSDEADCHAR, WM_SYSKEYDOWN, WM_SYSKEYUP( scand code와 extended key flag를 Windows CE에서는 지원하지 않는다)

Windows CE Design Guides for Keyboard Interaction

Windows CE H/W는 가능한 desktop PC와 동일한 keyboard layout을 사용하려하마 크기의 제약으로 인해 Windows CE H/W가 모든 standard key를 지원하도록 요구되어지지는 않는다. 따라서 대부분의 Windows CE H/W는 다음과 같은 key사 없다. Delete, Insert, Num Lock, Pause, Print scrn, Scroll lock, Function Key Shift+Backspace를 delete로 사용한다.

Stylus Input(Skip)

Windows CE Shell Services

shell은 Windows CE OS의 user interface이다. Windows CE Shell은 Windows 95 shell이 기반을 두고 있으며 많은 familiar feature를 가지고 있다.(desktop window, recycle bin, taskbar and drag drop)같은 기능을 가지고 있다. Windows CE는 portable OS로 많으 H/W에서 동작하게 된다. Windows CE Shell은 Windows 95 shell과 동일하게 file을 관리하고 desktop에 shortcut을 만들 수 있다. Windows CE는 또한 유일한 기능을 지원하는데 Notification API와 Hibernation기능을 들 수 있다. clipboard는 Windows 95/NT와 동일하게 동작한다.

Windows CE Shell Functions

Windows CE Shell은 Windows95/NT가 지원하는 기능의 일부를 지원한다. Windows CE Shell은 다음과 같은 4개의 기능을 지원하는 데 이는 Windows95/NT에서는 지원하지 않는 기능이다. 1.파일에 대한 shortcut을 만든다. 2. 존재한는 shortcut의 path를 얻는다. 3.파일로부터 device independent bitmap을 load한다. 4.사용자에게 low-memory condition을 알려주는 dialog box를 실행한다.(Windows CE의 shell은 기본적으로는 Windows 95/NT와 다를 것이 없다.단지 Windows CE가 mobile환경에 이식될 수 있으므로 notification API를 지원하고 low-memory situation을 위해 hibernation기능을 포함하고 있다)

SHGetFileInfo( )의 uFlag에 SHGFI_ICON을 설정하면 icon의 handle이 SHFILEINFO에 저장된다. Windows CE는 process가 종료해도 자동으로 icon object를 제거하지 않는다.따라서 Windows CE Application작성시에는 DestroyIcon( )이란 함수를 호츨해서 icon object를 제거해야 한다. 다음에 나오는 함수는 Windows CE와 Windows 95/NT가 동일하다.(?)

??

The Windowing Environment

windowing environment는 application의 사용자 인터페이스를 생성하고 관리하는 방법을 제공한다. Windows CE에서는 windows95/NT에서와 같이 screen자체를 사용하지 않고 window를 기본적인 output device로 사용한다. Windows CE의 Windowing system은 Windows 95/NT와 매우 유사하다. 그러나 Windows CE는 다른 OS에 비해 더 다양한 platform에서 동작할 수 있다. 대부분의 Windows CE platform이 portable로 제작되었으므로 display screen이 작고 desktop OS의 많은 windowing featire가 적용되지 않는다.그러나, 비록 target device가 display screen을 포함하고 있지 않더라고 window를 생성해야 한다(보이지 않더라도) 왜냐하면 message를 받기 위해서는 window가 필요하다.

(Windows CE의 Windowing기능은 Windows95/NT와 유사하다)

Window Management

Window은 screen상의 직사각형 영역으로 application display가 출력되고 사용자입력을 받아들이는 부분이다. 비록 많은 window의 생성이 가능하나 사용자의 입력을 받아들이는 부분은 항상 하나밖에 없다. Windows CE내의 모든 window는 Window Class에 속한다. window class is a set of attributes that Windows CE used as a template to create a iwindow. Windows CE에서의 window management가 desktop OS의 방식과는 다르다는 것을 발견할 수 있다. Windows CE는 MDI와 DDE를 지원하지 않는다. Windows CE는 window properties를 지원하지 않는다. window와 instance-specific information을 연결하기 위해서는 cbWndExtra field를 사용해서 그 window에 대한 추가의 byte를 등록한다. Windows CE는 window class내의 unaligned access를 허용하지 않는다. 또한 GWL_USERDATA값을 지원하지 않는다. 필요한 바이트를 할당하고 SetWindowLing( )과 GetWindowLong()을 사용한다.

Windows CE 장치의 screen은 일반적으로 작으며 장치마다 다르다. 따라서 절대 죄표로 지정하지 않는 것이 좋다. windows CE에서는 window의 size를 window생성시에 기술해 주며 Windows CE는 maximize & minimize를 지원하지 않는다. 그러나, 사용자는 window를 back of Z order로 보낼 수도 복귀시킬 수도 있다.

Windows CE는 SW_MINIMIZW, SW_RESTORE, SW_SHOWMAXIMIZED, SW_SHOWMINIMIZED, SW_SHOWNOACTIVATE를 WinMain의 nCmdShow파라메타 값으로 지원하지 않는다. Windows CE에서는 만일 visible top-level window가 WS_OVERLAPPED style을 가지고 있으면 taskbar에 button이 생긴다. taskbar에 button이 있는 window에 대해서만 WM_HIBERNATE 메시지를 받을 수 있다.

Window Style

Windows CE는 Windows 95/NT와 매우 유사한 기능을 제공한다. windows CE에서는 모든 window가 WS_CLIPCHILDREN과 WS_CLIPSIBLINGS sytle을 가지고 있다. Windows CE는 두 개의 확장된 style을 가지고 있다. WS_EX_NOACTIVE : 이 style을 가지고 생성된 window는 active될 수 없다. child window이 이 style을 가지고 있는 경우 이 child window로 이동한 경우에도 top-level window는 active되지 않는다. 이 style의 window는 stylus input을 받아들일 수 있으나 focus는 반아들이지 못한다. WS_EX_NOANIMATION : 이 style을 가지고 생성된 window는 animated exploding and imploding rectangle을 보여줄 수 없으며 taskbar에 button을 만들지 못한다.( ? )

다음에 기술하는 style은 windows 95/NT와 동일하게 windows CE에서도 동작한다.

WS_CHILD : child window를 생성하며 WS_POPUP style과 동시에 사용될 수 없다. WS_DISABLED : 사용자의 입력을 받아 들이수 없는 window를 생성한다. WS_GROUP : control group의 첫 번째 control을 기술한다. group은 첫 번째 control과 이후에 정의된 control로 구성된다. WS_GROUP이 기술되기 전까지의 모든 control. group매의 첫 번째 control은 WS_TABSTOP 속성을 지닐 수 있어 사용자는 group to group move가 가능하다. 사용자는 group내의 control간의 focus변경을 direction key를 이용해 할 수 있다. WS_POPUP : popup style의 window를 생성한다. WS_TABSTOP : TAB key를 사용자가 눌렀을 때 input focus를 받을 수 있도록 한다. WS_VISIBLE : 생성시 보이는 window. WS_EX_NOACTIVATE : activated 될 수 없는 window를 생성한다. WS_EX_TOPMOST : 모든 non-topmost window위에 존재하는 window를 생성하고 그들위에 존재한다. 비록 window가 deactivated되었어도, SetWindowPos( )를 이용해 이 style를 설정하게 된다.

Window functions

Windows CE는 outside of the command bar에 menu bar를 지원하지 않는다. 따라서, AdjustWindowRectEx( )의 bMenu를 FALSE로 셩정해야 한다. CreateWindow( ), CreateWindowEx( )의 hMenu를 항상 NULL로 설정한다. 만일 hMenu를 child-window의 identifier로 사용하지 않을 거라면, Windows CE 1.0에서는 owned window를 지원하지 않는다. MDI를 지원하지 않는다. Window style에 제약이 있다. DestrioyWindow( )는 WM_DESTROY를 발생하며 WM_NCDESTRIY는 지원하지 않는다. Windows CE는 EnumThreadWindows( )를 지원하지 않는다. 그러나, EnumWindows( )와 GetWindowsThreadProcessId( )를 이용해 구현할 수 있다. Windows CE는 window class내에서의 unaligned access를 지원하지 않는다. 따라서, GetClassLong( )과 SetClassLong( )의 nIndex파라메타값이 4BYTE의 배수가 되어야 한다. GetClassLong( )은 GCE_ATOM, GCL_CBCLDEXTRA, GCL_CBWNDEXTRA, GCL_HBRBACKGROUND, GCL_HCURSOR, GCL_HICONSM, GCL_HMODULE, GCL_MENUNAME, GCL_WNDPROC는 지원하지 않는다. 만일 Windows CE가 Iconcurs를 사용한다면( 적절한 target application에서의 mouse cursor지원)GCL_HCURSOR값을 사용할 수 있다.

command bar는 client area의 일부가된다. 따라서 이는 GetClientRect( )에 포함된다.

desktop에서 mouse에 적용되는 것과 같이 Windows CE의 stylus에도 동일하게 GetDoubleClickTime( )이 적용된다. Windows CE는 GetScrollPos( )와 GetScrollRange( )를 지원하지 않는다. GetScrolInfo( )를 scroll bar의 현재 위치를 얻기 위해 사용한다.

Windows CE 2.0과 그이후에 버전에서는 GetSysColor( )의 nIndex 파라메타로 새로운 2개의 값과 lpaElements를 SetSysColor( )를 위해 지원한다.

Windows CE는 GetSystemMetrix의 모든 nIndex값을 지원하지 않는다. GetUpdataRgn( )의 bErase를 무시하고 window의 background를 지우지 않으며 아무런 drawing도 하지 않는다.

GetWindowLong( )과 SetWindowLong( )함수는 GWL_HINSTANCE나 GWL_HWNDPARENT를 지원하지 않는다. Windows CE에서는 바이트 align이 되어야 하므로 4의 배수가 되어야 한다. Windows CE에서는 유효한 window handle을 InvalidateRect( )와 ValidateRect( )에 전달해야 한다. Windows95/NT에서는 NULL이 설정되면 모든 window를 다시 그리나 Windows CE에서는 이를 지원하지 않는다. Windows CE에서는 MoveWindow( )의 bRepaint값을 무시하고 이를 TRUE로 간주한다. RegisterClass( )함수의 경우, WNDCLASS의 lpszMenuName을 지원하지 않으며 이를 NULL로 설정한다. 만일 Windows CE장치가 mouse를 지원하지 않는 다면 HCursor을 NULL로 설정한다. 새 window class를 증록할 때에는 Unicode로 해야한다. ScrollWindowEx( )함수에 SW_SCROLLCHILDREN을 설정할 수 없다. 왜냐하면 한번에 한방향으로만 window을 scroll할 수 있기 때문이다. SetWindowPos( )함수에 SWP_FRAMECHANGED flag를 설정하는 경우 Windows CE는 모든 non-client를 다시그린다. 이는 client의 size를 바꿀 수도 있다.