최근 임베디드 기술 시장의 움직임이 분주하다. 그 중심에 있는 윈도우 CE가 세상에 모습을 드러낸 지 10년 만에 임베디드 OS의 주인 자리를 노리고 있다. 「임베디드 하면 리눅스」라는 통념을 깨고 임베디드의 중심축이 되어 가고 있는 윈도우 CE는 과연 어떤 장점이 숨어 있는 것일까? 이번 4부에서는 보다 빠른 제품 개발을 위해 필수 운영체제로 자리매김하고 있는 윈도우 CE의 특징과 윈도우 CE에서 제공하는 라이브러리를 활용해 짧은 시간에 안정적으로 개발할 수 있는 방법들에 대해 알아본다.

임베디드와 윈도우 CE
임베디드라는 단어는 수년 전만 하더라도 일부 엔지니어들 사이에서나 입에 오르던 용어였다. MICOM을 기반으로 발전하기 시작한 임베디드 시스템은 기존 아날로그 방식의 기기들이 디지털 방식으로 변화하면서 본격적으로 발전하기 시작했다. 최근의 임베디드 제품들은 개인용 컴퓨터 환경에 버금가는 기능과 성능을 지원하며 더욱 빠른 성장세를 이어가고 있다.


임베디드 제품의 진화는 곧 복잡한 기능을 지원하는 소프트웨어가 필요하다는 뜻이다. 결국 개발사에게 큰 부담이 될 수밖에 없었다. 제품에 꼭 필요한 몇 가지 기능만 수행하는 애플리케이션을 직접 만들어서 이식하던 방식으로는 개발 기간이 너무 길어질 것이기 때문이다. 이런 문제를 해결하기 위해 찾은 방법이 바로 윈도우 CE.

임베디드 시장에서 언제나 찬밥 신세에 불과하던 윈도우 CE로 눈을 돌리게 된 것이다.

윈도우 CE의 발전 계기
필자가 처음 윈도우 CE를 접한 것은 2000년. 당시만 해도 여러 임베디드 시장에서는「비싼 돈 주고 윈도우 CE를 사용하는 것은 미친 짓」으로 여겨질 정도였다. 당시만 해도 대부분 리눅스를 사용하고 있었던 탓이다.

대부분의 개발자들이 리눅스의 공개된 소스코드를 사용해서 공짜로 원하는 기능을 만드는 것이 대세였기에, 윈도우 CE는 그야말로 찬밥 신세였던 것이다.

설움의 시절을 보내던 윈도우 CE에게 회생의 기회가 온 것은PDA가 관심을 끌던 2000년 무렵이었다. 당시 팜, 리눅스, 심비안과 함께 경쟁하던 윈도우 CE와 포켓 PC는 기존 데스크톱 환경과 유사한 덕에 좋은 위치를 선점할 수 있었다.

포켓 PC는 윈도우 CE의 핵심기능을 이용하여 PDA 시장을 겨냥한 MS의 모바일 운영체제였다. 그 뒤 모바일 기기의 하드웨어 발전에 따라 지능형 휴대단말기 스마트 폰용 운영체제가 나오게 되었다. 현재는 「윈도우 모바일」그룹으로 「포켓 PC 2005」와「스마트 폰 2005」등으로 발전한 상태다.

모바일, PDA 시장에 있어서 윈도우 CE는 풍부한 네트워크솔루션을 기반으로 유/무선통신, 인터넷 서비스 및 멀티미디어지원과 강력한 그래픽 사용자 환경에서 강세가 뚜렷하다.

또한 다양한 응용프로그램과 호환성 그리고 사용자 응용프로그램 개발도구 제공 등을 통해서도 확인할 수 있다. 이외에 수많은 사용자에게 익숙해진 데스크톱 윈도우의 사용자 환경(UI)을 이어간 쉘(Shell)도 큰 역할을 했다.


윈도우 CE의 PDA 시장에서의 성공은 임베디드 시장에서 윈도우 CE의 성장 가능성을 보여주고 있다. 이를 계기로 여러 가지 디지털 응용 제품들이 속속들이 개발되고 있다. 그 사례로 요즘은 등기우편 및 물건을 집까지 배달해주는 우편배달원 아저씨들의 한쪽 손에서 윈도우 CE가 탑재된 단말기를 쉽게 볼 수 있다.

더 나아가 군사작전 중 암호화된 디지털 정보를 열악한 환경속에서 통신하여, 신속하고 성공적인 작전을 수행할 수 있도록 하는 군사용 단말기에도 사용되고 있다.



윈도우 CE는 비싸다?
흔히 윈도우 CE를 멀리하는 이유 중 하나로 비싼 가격을 꼽는데 사실은 그렇지가 않다. 윈도우 CE가 지원하는 모든 기능들은 다른 임베디드 운영체제에 비하여 저렴한 런타임 라이센스 가격으로 사용할 수 있다. 리눅스와 비교해 보자. 리눅스 운영체제가 무료이기는 하지만, 각종 디바이스와 드라이버, 미들웨어 등 주요 솔루션은 유료이다.

이것저것 따지다보면 윈도우 CE를 쓰는 편이 저렴하다는 이야기다. 윈도우 CE가 각광을 받고 있는 더 중요한 이유는 리눅스가 기기간의 연결성과 응용프로그램의 호환성 문제를 명쾌하게 해결하기 어렵다는 데 있다.

윈도우 CE는 운영체제에 포함된 컴포넌트에 따라 코어, 프로페셔널, 프로페셔널 플러스의 세 가지 런타임 라이선스 모델로 구성된다. 이미 대중화된 CNS(Car Navigation System)는 처음 포켓 PC 기반으로 출시되어 많은 자동차 운전자들의 주목을 받았다.

CNS 시장의 성장이 가시화 되고, 보다 저렴한 가격과 다양한 기능을 갖춘 네비게이션이 필요해지면서 윈도우 CE가 그 자리를 이어 받아 코어 라이선스가 적용된 다기능의 CNS가 출시되기 시작하였다.

윈도우 CE 기반의 CNS는 이미 포켓 PC에서 검증된 네비게이션 솔루션들을 문제없이 운영할 수 있다는 것이 큰 매력이다. 또 멀티미디어와 차계부 등의 다양한 응용프로그램이 개발되면서 CNS 시장의 대중화를 더욱 가속화시켰다.


기존에는 거의 100% 리눅스 기반이었던 DMB(Digital Multimedia Broadcasting)와 PMP(Portable Media Player)도 최근에는 윈도우 CE를 운영체제로 사용하고 있는 추세이다.

물론 저렴한 가격도 한몫했다. 윈도우 CE의 주요기능이 포함되어 있는 윈도우 CE 코어 라이선스 모델의 가격이 3 달러라는 점은 뿌리치기 어려운 유혹이다.

윈도우 CE의 또 다른 강점은 멀티미디어 기능과 유/무선 네트워크를 기반으로 하는 풍부한 인터넷 서비스이다. 데스크톱 윈도우 운영체제의 인터넷 익스플로러 주요 기능을 포함한 윈도우CE용 인터넷 익스플로러와 멀티미디어 기능이 IPSTB(IPTV)시장도 선도하고 있다.



윈도우 소스코드는 비공개라서 사용하기 어렵다?
MS 운영체제의 소스코드는 공개되지 않는다는 인식은 대부분의 개발자들이 가지고 있는 생각이다. 하지만 MS는 특별 운영프로그램에 의해서 소스코드들을 공개하고 있다.

윈도우 CE 운영체제의 커널, 주요 시스템 소프트웨어의 소스코드와 응용프로그램 개발을 위한 참조용 소스코드 및 디바이스드라이버 소스코드 등 약 200만 라인 이상의 소스코드가 플랫폼빌더 안에 포함되어 윈도우 CE 개발자들에게 제공된다.

이 외에도 프리미엄 쉐어드(Premium Shared) 소스코드 프로그램에 의해서 더 많은 공개 소스코드를 받아 볼 수 있다. 개발자 또는 OEM 업체는 이들 공개 소스코드의 수정 및 재배포도 할 수 있다.

플랫폼 빌더와 윈도우 CE 개발 프로세스윈도우 CE의 개발은 플랫폼 빌더(Platform Builder)에서부터 시작된다. 플랫폼 빌더는 400개 이상의 컴포넌트를 포함하고 있다. 이들 컴포넌트를 이용하여 다양한 임베디드 환경에 맞게 윈도우 CE를 개발할 수 있다.

플랫폼 빌더는 GUI 기반의 통합개발 환경으로 윈도우 CE 운영체제의 디자인, 디버깅, 테스트 플랫폼 빌더와 윈도우 CE 개발 프로세스윈도우 CE의 개발은 플랫폼 빌더(Platform Builder)에서부터 시작된다. 플랫폼 빌더는 400개 이상의 컴포넌트를 포함하고 있다. 이들 컴포넌트를 이용하여 다양한 임베디드 환경에 맞게 윈도우 CE를 개발할 수 있다. 플랫폼 빌더는 GUI 기반의 통합개발 환경으로 윈도우 CE 운영체제의 디자인, 디버깅, 테스트 디버깅을 가능하게 한다.

또한 개발 참조보드(Development Reference Board)나 타깃하드웨어가 없어도 운영체제의 디자인과 응용프로그램을 개발하거나 디버깅 할 수 있는 디바이스 에뮬레이터도 제공한다.

이와 같이 플랫폼 빌더가 제공하는 여러 개발도구와 기능들은 병렬방식 개발을 가능하게 하므로 다른 임베디드 운영체제의 직렬방식개발에 비해 높은 개발 생산성을 유지할 수 있다. 직렬방식 개발이란, 하드웨어 보드의 개발과 운영체제 및 관련 소프트웨어 포팅 등의 작업을 순차적으로 진행하는 방식을 말한다.


플랫폼 빌더를 사용하는 윈도우 CE는 운영체제의 디자인 및 응용프로그램의 개발을 하드웨어 개발과 동시에 진행할 수 있는 병렬방식 개발을 지원하므로 개발시간을 단축할 수 있다. 플랫폼빌더의 디바이스 에뮬레이터를 이용하여 운영체제의 디자인과 테스트를 선행할 수 있다. 또 응용소프트웨어의 테스트 및 디버깅도 가능하다.



윈도우 CE 운영체제의 생성 과정과 응용프로그램, 샘플코드활용
플랫폼 빌더에는 약 400개 이상의 컴포넌트가 있다. 이들 컴포넌트들을 선택적으로 구성하여 운영체제의 환경을 설정할 수 있다. 운영체제의 환경 설정이란 개발될 제품에 맞춰 윈도우 CE운영체제가 지원해야 하는 기능들을 최적화하여 구성하는 것을 말한다. 이렇게 해야 하는 이유는 윈도우 CE의 활용 범위가 광범위하기 때문이다.

플랫폼 빌더를 이용하여 원하는 윈도우 CE 운영체제의 환경설정이 완료되면 빌드(Build)를 수행하여 윈도우 CE 운영체제의 OS 이미지를 생성하게 된다. 여기서 우리가 이해하고 넘어가야 하는 것은 선택된 많은 수의 컴포넌트들에 대한 소스코드를 모두 컴파일 하지 않는다는 것이다.

실제로 윈도우 CE의 모든 소스코드들은 300만 라인이 훨씬 넘는 어셈블리어와 C/C++ 코드로 구성되어 있기 때문에, 이들 코드를 모두 컴파일 한다면 윈도우 CE 운영체제 OS 이미지를 생성하는 시간이 굉장히 오래 걸린다. 이는 곧 개발 생산성을 떨어뜨리는 원인으로 연결된다.

● 윈도우 CE 운영체제의 생성과정
그래서 플랫폼 빌더는 주요 컴포넌트들에 대한 소스코드를 미리 컴파일한 라이브러리(.lib)들을 가지고 있다. 윈도우 CE 운영체제를 빌드 할 때 이들 라이브러리를 환경 설정에 맞게 링크하여 주요 컴포넌트들을 생성하게 된다. 이러한 이유로 윈도우 CE운영체제의 생성과정은 크게 4단계로 구성된다. <그림 6>은 빌드과정을 보여주고 있다.



- 1 단계 : Sysgen
첫 번째 단계를「SYSGEN」이라고 부르며 SystemGeneration을 뜻한다. 이 단계에서는 플랫폼 빌더가 가지고 있는 컴포넌트들 중 선택된 환경 설정에 따라 유효 컴포넌트들을 분리하여 주는 필터링 과정을 수행한다. 라이브러리들의 링크를통해서 실제로 윈도우 CE 운영체제에서 사용될 주요 컴포넌트들을 생성하는 단계이다.

또한 디바이스 드라이버나, 응용프로그램의 소스코드를 컴파일 할 때 사용되는 기타 라이브러리와 헤더 파일들을 분리한다.

이 단계에서 분리된 라이브러리와 헤더 파일들은 응용프로그램전용 개발 도구인 임베디드 비주얼 C/C++개발 도구에 포함될SDK(Software Development Kit)를 생성하는 데 사용된다.

- 2 단계 : Build
두 번째 단계를「BUILD」라고 부르는데 디바이스 드라이버(BSP) 또는 작성된 응용프로그램 소스코드들을 컴파일 한다.

- 3 단계 : Buildrel
세 번째 단계를 「BUILDREL」이라고 부르며 Building theRelease Directory라는 의미다. 첫 번째와 두 번째 단계에서 생성된 컴포넌트들(커널, 디바이스 드라이버, 응용프로그램 등)과 윈도우 CE 운영체제 OS 이미지를 생성하기 위한 설정 파일들을 모두 릴리즈 디렉토리라고 부르는 폴더로 복사하여 준다. 릴리즈 디렉토리는 플랫폼 빌더로 윈도우 CE 개발을 시작할 때 명시한 이름의 프로젝트 폴더이다.

- 4 단계 : Make Image
네 번째 단계를 「MAKE IMAGE」라고 부르며, 릴리즈 디렉토리에 있는 컴포넌트들과 설정 파일들을 이용해서 윈도우 CE 운영체제 OS 이미지 파일인 「NK.BIN」을 생성하는 단계이다.

누구에게나 친근한 Hello World 해부하기윈도우 CE를 개발하다 보면 때때로 플랫폼 빌더의 소스코드를 수정할 경우가 발생하고 또는 샘플소스 코드를 이용하여 목표하는 응용프로그램을 개발해야 하는 때도 있다. 응용프로그램 개발 방법에 있어서, 플랫폼 빌더에서 개발되는 응용프로그램은 오직 Win32 API만을 이용할 수 있다.

하지만 임베디드 비쥬얼C/C++ 윈도우 CE 응용프로그램 전용 개발도구는 Win32 API와 MFC, ATL 등을 이용한 응용프로그램의 개발을 가능하게 한다. 비쥬얼 스튜디오 2003 또는 2005는 윈도우 CE용 비주얼 베이직 .NET(이하 VB.NET)과 C#의 응용프로그램 개발을 가능하게 한다.

응용프로그램의 목적에 따라 Win32 API 기반 또는 MFC,ATL 그리고 VB.NET, C# 등으로 구분하여 개발할 수 있지만,플랫폼 빌더가 포함하고 있는 윈도우 CE의 주요 컴포넌트들과샘플 소스코드들은 전부 Win32 API 기반으로 되어 있다.

이는 소프트웨어의 성능을 향상시키고 시스템 제약사항을 최소화하기 위해서다. 결국 플랫폼 빌더의 샘플 소스코드를 이용한 응용프로그램 개발은 Win32 API를 기반으로 하는 것이 효율적이다. MS의 응용프로그램 개발 도구들은 GUI 기반의 소프트웨어 소스코드의 시작이 되는 Hello World를 제공하고 있다. 물론 윈도우 CE의 경우도 Hello World를 제공한다.

<리스트 1> 윈도우 CE Win32 API 기반의 Hello World 소스코드

// Forward declarations of functions included in this code module: ATOM MyRegisterClass(HINSTANCE hInstance); BOOL InitInstance(HINSTANCE, int); LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { // TODO: Place code here. MSG msg; HACCEL hAccelTable; // Initialize global strings LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING); LoadString(hInstance, IDC_helloWorld, szWindowClass, MAX_LOADSTRING); MyRegisterClass(hInstance);

<리스트 2> 윈도우 CE Win32 API 기반의 HelloWorld 소스코드, 윈도우 프로시저

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { PAINTSTRUCT ps; HDC hdc; TCHAR szHello[MAX_LOADSTRING]; LoadString(hInst, IDS_HELLO, szHello, MAX_LOADSTRING); switch (message) { case WM_PAINT: hdc = BeginPaint(hWnd, &ps); // TODO: Add any drawing code here... RECT rt; GetClientRect(hWnd, &rt); DrawText(hdc, szHello, _tcslen(szHello), &rt, DT_CENTER); EndPaint(hWnd, &ps); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hWnd, message, wParam, lParam); } return 0; }

<리스트 1>은 윈도우 CE용 Win32 API 기반의 Hello World 소스코드를 보여 준다. 이미 데스크톱 윈도우 응용프로그램을 개발한 경험이 있는 독자라면 위의 코드가 눈에 많이 익을 것이다.

Win32 API 기반 소스코드의 시작인 WinMain()과 윈도우 클래스(Window Class) 설정인 MyRegisterClass(), 콜백 윈도우프로시저인 WndProc() 및 메시지와 메시지 처리 방법 등 데스크톱 윈도우 응용프로그램과 동일하다.

멀티미디어 샘플 소스 활용하기
다른 임베디드 운영체제의 응용프로그램을 개발하기 위해서는 새로운 개발환경과 개발논리, 주요 API들에 대한 공부와 사전경험이 필요하다. 이와 반면에 윈도우 CE용의 데스크톱 윈도우 응용프로그램 소스코드의 호환성 및 이식성은 기존 데스크톱 윈도우 응용프로그램 개발자의 부담을 덜어준다.

또 기업에게는 임베디드 시장에 빨리 진입할 수 있도록 다양한 솔루션을 제공한다.

플랫폼 빌더에 있는 수많은 샘플 소스코드 중 어떠한 경우는 윈도우 데스크톱 소스코드를 거의 그대로 가지고 온 것을 보게 된다. 그 중에 최근 관심의 대상이 되는 임베디드 멀티미디어 기능을 살펴보면 윈도우 CE는 MS의 다이렉트 쇼(Direct Show)구조를 사용하고 있다.

윈도우 CE는 MS 윈도우 미디어 9 기술 기반의 윈도우 CE용 멀티미디어 플레이어를 제공한다. 관련 소스코드와 응용프로그램에서 참조할 수 있는 샘플 플레이어 소스코드도 제공한다.

이 윈도우 CE용 샘플 미디어 플레이어는 MS의 데스크톱 윈도우 다이렉트쇼 SDK에 포함되어 있는 샘플 플레이어 코드와 거의 동일하다. 이외에 개발자의 코덱과 필더를 테스트 할 수 있는 윈도우 CE용 그래프 에디터가 제공된다.

<리스트 3> 윈도우 CE의 샘플 미디어 플레이어 소스코드

HRESULT PlayMovieInWindow(LPTSTR szFile) { WCHAR wFile[MAX_PATH]; HRESULT hr; RETAILMSG(1, (TEXT(“Playing media %s...\r\n”), szFile)); // Clear open dialog remnants before the slow-running RenderFile() UpdateWindow(ghApp); #ifndef UNICODE MultiByteToWideChar(CP_ACP, 0, szFile, -1, wFile, MAX_PATH); #else if (_tcslen(szFile) < MAX_PATH) lstrcpy(wFile, szFile); else return E_FAIL; #endif // Get the interface for DirectShow」s GraphBuilder JIF(CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER, IID_IGraphBuilder, (void **)&pGB)); if(SUCCEEDED(hr)) { // Have the graph construct its the appropriate graph automatically JIF(pGB->RenderFile(wFile, NULL)); // QueryInterface for DirectShow interfaces JIF(pGB->QueryInterface(IID_IMediaControl, (void **)&pMC)); JIF(pGB->QueryInterface(IID_IMediaEventEx, (void **)&pME)); JIF(pGB->QueryInterface(IID_IMediaSeeking, (void **)&pMS)); // Query for video interfaces, which may not be relevant for audio files JIF(pGB->QueryInterface(IID_IVideoWindow, (void **)&pVW)); JIF(pGB->QueryInterface(IID_IBasicVideo, (void **)&pBV)); // Query for audio interfaces, which may not be relevant for video-only files JIF(pGB->QueryInterface(IID_IBasicAudio, (void **)&pBA)); // Is this an audio-only file (no video component)? CheckVisibility(); if (!g_bAudioOnly) { JIF(pVW->put_Owner((OAHWND)ghApp)); JIF(pVW->put_WindowStyle(WS_CHILD | WS_CLIPSIBLINGS | WS_CLIPCHILDREN)); } // Have the graph signal event via window callbacks for performance JIF(pME->SetNotifyWindow((OAHWND)ghApp, WM_GRAPHNOTIFY, 0)); if (g_bAudioOnly) { JIF(InitAudioWindow()); } else { JIF(InitVideoWindow()); } // Let」s get ready to rumble! ShowWindow(ghApp, SW_SHOWNORMAL); UpdateWindow(ghApp); SetForegroundWindow(ghApp); SetFocus(ghApp); UpdateMainTitle(); // Run the graph to play the media file JIF(pMC->Run()); g_psCurrent=psRUNNING; SetFocus(ghApp); } return hr; }

윈도우 CE 제약사항
윈도우 CE를 처음 접한 개발자와 사용자들은 대부분 윈도우CE의 사용자 환경이 데스크톱(윈도우 98, 2000) 환경과 유사하기에 기능이나 성능 그리고 데스크톱용 애플리케이션과의 완벽한 호환성도 기대하게 마련이다.

하지만 윈도우 CE는 MS의 새로운 커널을 사용하며, 모바일 임베디드 환경에서 RISC(Reduced Instruction Set Computer) CPU 환경을 지원한다.

RISC CPU의 빠른 발전으로 데스크톱 플랫폼(x86) 수준의 성능을 따라가지만 아직까지 데스크톱 플랫폼을 뛰어넘는 RISC 모바일 CPU는 없는 실정이다.

하드웨어 지원의 영향도 있지만, 서로 다른 하드웨어 플랫폼간의 호환성과 연결성의 지원으로 인하여 나타난 성능의 열세는 윈도우 CE가 안고 있는 커다란 제약사항이다. 여기서 말한 성능의 열세란 데스크톱 윈도우 운영체제와 비교하였을 경우를 말한다.

예로 데스크톱 윈도우 운영체제가 소프트웨어 멀티미디어 코덱을 무리 없이 지원하지만, 윈도우 CE에서는 하드웨어 지원 멀티미디어 코덱을 사용해야 하는 등의 사례를 들 수 있다.

물론 윈도우 CE에서도 소프트웨어 코덱을 무리없이 지원할 수 있지만, 이 경우 MS의 다이렉트 쇼(Direct Show) 구조를 포기해야 하는 것으로 나타났다.

<그림 7>은 윈도우 XP와 윈도우 CE의 차이점을 보여준다. 윈도우 XP 임베디드는 윈도우 XP Pro의 임베디드 버전이다. XPPro와 같은 바이너리를 사용하기 때문에 윈도우 XP Pro와 완벽한 호환성을 제공한다.


윈도우 CE의 차기 버전 윈도우 CE 6.02006년 하반기에는 윈도우 CE 역사에 큰 획을 그을 코드네임「야마자키」로 불리는 윈도우 CE 6.0이 출시될 계획이다.

윈도우CE 6.0은 그 동안 윈도우 CE가 가지고 있던 메모리 구조의 취약점을 대폭 개선하였다. 최신의 비쥬얼 스튜디오 닷넷 2005(Visual Studio .NET 2005) 개발 도구와의 통합으로 개발 생산성을 향상 시켰다.

윈도우 CE 5.0까지 응용프로그램당 32MB 메모리 사용이라는 제한과 32개의 시스템 프로세스 및 응용프로그램 운영이라는 제한도 대폭 개선되었다. 6.0은 응용프로그램당 2GB의 메모리를 사용하고 32,000개의 시스템 프로세스 및 응용프로그램을 운영할 수 있다.

또한 커널의 부하를 최소화하기 위한 윈도우 CE 고유의 마이크로-커널 구조를 그대로 이어가면서 커널과 시스템 프로세스간의 호출 이동 시간을 대폭 개선한 통합커널 구조가 사용된다.

임베디드 운영체제의 선택
임베디드 운영체제의 선택은 개발할 제품에서 필요한 기술과비용 그리고 시장 동향에 의해 좌우된다. 하드웨어의 빠른 변화는 소프트웨어 발전의 가능성과 다양한 기회를 제공 하지만, 현실적으로 소프트웨어는 하드웨어만큼 빨리 발전하지 못한다.

이유는 사용자의 눈높이가 높아진 만큼 화려한 환경과 서비스를 계속 요구하고, 이로 인해 소프트웨어의 복잡성이 날로 증가하는 탓이다.




그렇기 때문에 임베디드 운영체제(소프트웨어)는 검증된 기술로 다양한 서비스를 문제없이 제공해야 하고 이들 기술을 사용해서 제품과 개발의 비용이 상승해서는 안 된다.

윈도우 CE가 이러한 조건을 모두 충족할 수는 없지만, 10년이라는 윈도우 CE의 역사는 이러한 조건을 이미 충족시킬 정도로 검증을 받았다. 더불어 윈도우 CE가 가지고 있는 기기간의 상호연결성 및 호환성은 이미 임베디드 시장에서 중요한 요소로 자리잡았다.

이 글이 독자들에게 임베디드 분야에서의 윈도우 CE에 대해 바르게 이해할 수 있도록 하는 계기가 되었길 바란다. @


* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.