Douglas Boling
February 2007
역자 : EddyKim(김은권) June 2007
- Draft : June. 25. 2007
Summary
This article covers how the new version of Windows Embedded CE handles memory, how it is architected, and what impacts these changes will have on applications.
이 문서는 새로운 버전의 Windows Embedded CE가 어떻게 메모리를 다루고 구조화되었는지, 그리고 어플리케이션에 있어서의 이러한 변화들의 영향력은 무엇인지에 관하여 다룬다.
Introduction
Over the last 10 years, Windows Embedded CE has grown from a fresh-faced newcomer to a grizzled veteran of the embedded operating system world. During this time, Microsoft has improved almost everything about Windows CE but the way it manages memory. Sure, Windows CE is and has always been a modern, preemptively multitasking operating system with virtual memory support, but there were some severe limits for memory and code intensive systems such as set-top boxes and the Windows Mobile® platforms.
Specifically, the limits are the 32 concurrent process limit and the 32 MB application virtual space limit. Neither of these limits were a problem in the early days of Windows CE, nor are they a problem on many embedded systems built today. The problems occur on systems that are intensively media driven, therefore running Windows Media® player, systems needing large amounts of system and application code, such as Windows Mobile, and on systems that tend to create systems with large numbers of small processes, such as some process control systems.
Windows Embedded CE 6.0 blows away the “two 32’s,” due to a completely rewritten kernel and new operating system architecture. The new kernel allows up to 32 thousand processes running at any one time. I suspect this new 32K process “limit” should not be a problem for at least a few years. In addition, virtual memory space for a given application has been improved from 32 MB of virtual address space per process to 2 GB of address space per process.
지난 10년 동안, Windows Embedded CE는 임베디드 오퍼레이팅 시스템의 세계에서 fresh-faced newcomer에서 히끗한 베테랑(grizzled veteran)으로 성장해왔다.
그 시간동안 마이크로 소프트는 메모리를 관리하는 것을 제외한 거의 모든 부분에 있어서 향상시켰다. 확실히 Windows CE는 최신화, 가상 메모리 지원의 선점형 멀티테스킹 OS화 되어왔다. 그러나 셋탑박스 와 Windows Mobile 플랫폼과 같은 코드 집약적인 시스템과 메모리에 있어서 약간의 심각한 제한들이 있다.
특히, 32개의 프로세스 제한과 32MB의 어플리케이션 가상공간 제한이다.
이러한 제한들은 이전의 WindowsCE는 문제가 아니었고 오늘날의 많은 임베디드 시스템에서도 문제가 되지 않는다. 문제는 집중적인 미디어 구동의 시스템(Windows Media Player), 많은 시스템과 어플리케이션 코드들을 필요로 하는 시스템(Wnidows Mobile), 시스템들을 제어하는 프로세스와 같은 많은 수의 작은 프로세스를 구성하려는 경향이 있는 시스템들에서 나타난다.
Windows Embedded CE 6.0은 완전히 새로 작성된 커널 및 새로운 오퍼레이팅 시스템 구조이기 때문에 두개의 32제한(two 32's : 역자주 - 32개의 동시적 프로세스, 32MB 제한)을 날려버렸다. 새로운 커널은 32000개의 프로세스를 동시에 돌리 수 있도록 한다. 나는 적어도 몇년동안은 이러한 새로운 32K 프로세스 제한이 문제가 되지 않는다고 생각한다(?). 추가적으로 어플리케이션의 가상 메모리 공간은 프로세스당 32MB 가상공간에서 프로세스당 2GB로 향상되었다.
The Memory Architecture
To fully understand the improvements in the new kernel, a review of the architecture used in Windows CE 5.0 is helpful. Figure 1 shows the Windows CE 5.0 unified virtual address space. As with both Windows® XP and Windows Embedded CE 6.0, the top 2 GBs of the address space is reserved by the system. The lower half of the address space is divided into a number of regions. The majority of this area, almost half of the space, is defined as the Large Memory Area. This area is used to allocate large blocks of memory space typically used for memory-mapped files.
새로운 커널의 개선을 충분히 이해하기 위해서, Windows CE 5.0에서 사용된 아키텍쳐를 컴토해보는것이 도움이 된다. 그림1은 단일화된 WindowsCE 5.0의 단일화된 가상 주소 공간을 보여준다. WindowsXP와 Windows Embedded CE 6.0에서는 주소 공간의 상위(top) 2GB는 시스템에 의해 예약되어 있으며, 하위 절반은 다수의 영역으로 나누어져 있다.
이 공간의 거의 절반은 Large Memory Area로서 정의되어 있고 전형적으로 memory-mapped files를 위해 사용되어지는 메모리 공간의 large blocks으로 할당되어 있다.
.gif)
Figure1
Below the Large Memory Area is the set of 31 “process slots” that contain the virtual address images for the processes that are currently running. Below the process slots, at the extreme low end of the memory space is a 64-MB area. This 64-MB area, more precisely the lowest 32 MB of the area, is the replicated process slot for the process that contains the currently running thread.
Large Memory Area의 아랫부분은 동시에 수행된는 프로세스들에 대한 가상 주소 이미지들을 포함하는 31개로 구성되는 슬롯의 집합(Process slots)이다.
메모리 공간의 최하위 64MB는 현재 실행되고 있는 스레드를 포함한 반복된 프로세스 슬롯이다.
It is this “slot architecture” that imposes both the 32 process and 32-MB virtual memory limit. Because there are a limited number of slots (31) there are a limited number of concurrent processes. (In marketing math, 31 process slots turns into 32 processes when you add in the kernel process, which is located in the upper 2 GBs of the address space.)
이러한 슬롯 아키텍쳐는 32 프로세스와 32MB 가상 메모리 제한을 내포하고 있다.
왜냐하면 31개의 제한된 슬롯수가 있으므로, 동시 실행 프로세스의 수가 제한된다.
( 마케팅 계산법에 있어서, 31개의 프로세스 슬롯은 커널 프로세스에 추가할때 32개의 프로세스로 계산되며, 주소 공간의 상위 2GB에 위치한다. - 번역이 미비 )
An expanded look at the lowest 64 MB of the earlier Windows CE process space is shown in Figure 2. The lower 32 MB of the process space is the replicated space from the process slot of the process where the currently running thread is executing. The upper 32 MB of this space used to load the code and read only memory for ROM-based dynamic-link libraries (DLLs). This upper 32 MB, known as “slot 1,” is shared across all running applications.
그림2는 이전의 Windows CE 프로세스 공간의 하위 64MB의 확장을 보여준다.
프로세스 공간의 하위 32MB는 프로세스의 프로세스 슬롯에 복사된 공간이며 여기서 현재 돌고(running)있는 스레드가 실행된다.
이 공간의 상위 32MB는 코드를 로드하거나 ROM-based DLL에 대하여 read-only memory로 사용된다. 이 32MB는 "slot 1"으로 알려져 있으며 모든 실행중인 어플리케이션들이 공유한다.
.gif)
Figure2
The 32 MB virtual space limit comes from the size of each individual process slot. Because of the single, unified address space, making the virtual space per process larger would result in fewer total slots and thus fewer concurrent processes. As it is, the compromise of 32 processes and 32 MB per process works, or at least worked, pretty well.
32MB 가상 공간의 제한은 각 개별적인 프로세스 슬롯의 사이즈에 기인한다.
단일화된 주소 공간때문에 프로세스당 가상 공간을 크게 만들면 더 적은 슬롯 수로 되고 적은 수의 동시 실행 프로세스들이 된다. 이로 인해, 32 프로세스들과 프로세스당 32MB의 타협은 적어도 잘 동작했고 잘 동작한다.
The Application Vitural Address Space
The memory architecture of Windows Embedded CE 6.0 is shown in Figure 3. With the new design, each running process gets its own copy of the entire lower 2 GBs of the address space. While this 2 GB space seems at the surface the same layout as Windows XP, the use of the application address space is different.
그림3은 Windows Embedded CE 6.0의 메모리 구조를 보여준다.
새로운 디자인으로 각 실행중인 프로세스는 주소 공간의 하위 총 2GB의 복사본을 획득한다.
이 2GB는 Windows XP와 동일한 레이아웃처럼 보이지만 어플이케이션 주소공간의 사용은 다르다.
.gif)
Figure3
Figure 4 shows the layout of the virtual memory space of a given Windows Embedded CE 6.0 process. Like the earlier Windows CE architecture, an application’s virtual memory space is divided in two. The lower 1 GB is space where the application code is loaded and where the application can allocate memory. This is where all memory allocations will be placed as well as the location for the stacks for all threads in the application.
그림4는 주어진 Windows Embedded CE 6.0 프로세스의 가상 메모리 공간의 레이아웃을 보여준다. 이전의 Windows CE 구조와 같이, 어플리케이션의 가상 메모리 공간은 둘로 나뉘어진다.
하위 1GB의 공간에서 어플리케이션 코드가 로드되고 어플리케이션을 메모리를 할당할수 있다. 여기서 어플리케이션에서 모든 스레드들에 대한 스택 위치처럼 모든 메모리 할당이 된다.
.gif)
Figure4
Just above this region is a 512-MB region where the system will load the code and read only data for the DLLs that are loaded by the various applications currently running. Like earlier versions of Windows CE, a given DLL loaded by an application is loaded at the specific address for one process is loaded at the same address for all processes that load that DLL. DLLs in this region are loaded from the bottom up in the region (starting at 0x4000 0000) instead of top down, as was the case for earlier versions of Windows CE.
Just above the DLL space, starting at address 0x6000 0000, is a 256 MB region used to allocate RAM-backed memory-mapped files. RAM-backed memory-mapped files, also known as memory-mapped objects are memory-mapped files that do not have an actual file backing the data in the object. Memory-mapped objects are typically used for interprocess communication. To facilitate backward compatibility, if a named memory-mapped object is allocated in more than one process, it is mapped at the same base address for all processes that map the object. If a process opens an actual file for memory-mapped access, the buffer for that memory-mapped file is allocated in the lower 1 GB of the application’s address space.
이 영역의 바로 위가 512MB영역이며 여기서 시스템이 코드를 로드하고 현재 실행중인 다양한 어플리케이션에 의해 로드되는 DLL들에 대하여 데이타만을 읽는다.
이전의 Windows CE와 마찬가지로, a given DLL loaded by an application is loaded at the specific address for one process is loaded at the same address for all processes that load that DLL. 이 영역에서의 DLL들은 0x4000 0000번지를 시작으로하는 영역에 밑에서부터 로드된다.
0x6000 0000 번지를 시작으로 DLL 공간 바로위 부분은 RAM-backed memory-mapped file들을 할당하기 위해 사용되어진다. memory-mapped object로 알려진 RAM-backed memory-mapped file들은 object에 있어서 데이타를 backing하는 실질적인 파일을 가지고 있지않다.
Memory-mapped object들은 전형적으로 interprocess communication에 사용된다.
이전 호환을 용이하게 하기 위해, 만약 이름지어진 memory-mapped object가 하나의 프로세스보다 많이 할당된다면, 그 object를 맵하고 있는 모든 프로세스들에 대하여 동일한 base address에 맵되며, memory-mapped file에 대한 버퍼는 어플리케이션 주소 영역의 하위 1GB에 할당된다.
At virtual address 0x7000 0000 is a 255-MB region that is used for communication between the operating system and the application. This region is read only to the application but can be read and written to by the operating system. Finally, there is a 1 MB guard region at 0x7FE0 0000 that not accessible by the application or operating system.
To summarize, the application has 1 GB of its address space for its code and for all memory and stack allocations, and another GB that is available for dedicated purposes. While only half of the virtual memory space is available for memory allocations, it is much better than the earlier 32-MB region in Windows CE 5.0 that was available for the same purpose. In addition, because Windows Embedded CE 6.0 retains the current limit of 512 MB of physical RAM, I suspect a system will run out of physical RAM before an application runs out of virtual memory space.
가상주소 0x7000 0000의 255MB영역은 OS와 어플리케이션과의 통신에 사용되어지며, 이 영역은 어플리케이션에 읽혀지지만 OS는 읽고/쓰기 가능하다. 결국 0x7FE0 0000에 1MB 가드영역이 있으며 어플리케이션이나 OS는 접근 불가능하다.
요약하자면, 어플리케이션은 1GB의 코드와 메모리 그리고 스택할당을 위한 자체 주소 영역을 가지며 다른 GB는 전용 목적으로 사용 가능하다.
가상 메모리 주소의 절반이 메모리 할당에 가능한 반면에(할지라도), 이는 동일한 기능의 목적으로 가능한 이전의 Windows CE 5.0에서의 32MB보다 낫다.
추가적으로, Windows Embedded CE 6.0은 여전히 물리 RAM의 512MB의 현재 제한을 유지하기 때문에, 나는 어플리케이션이 가상 메모리 영역밖에서 실행되기 이전에 물리 RAM밖에서 동작할거라 의심한다.(너무 직역이군)
The Kernel Virtual Address Space
The memory map for kernel address space in Windows Embedded CE 6.0 is shown in Figure 5.
그림5는 Windows Embedded CE 6.0에서의 커널 주소 영역의 메모리 맵을 보여준다.
.gif)
Figure5
As with earlier versions of Windows CE, the first two regions of the kernel address space are the cached and uncached windows in the physical address space. It is through these windows that the operating system and the drivers access the RAM and memory-mapped peripherals.
At address 0xC000 0000 there is a 128-MB region where the ROM-based DLLs loaded by the kernel are mapped. The 128-MB region just above this at 0xC800 0000 is used by the file system to map the RAM-based object store.
The region starting at 0xD000 0000 is the kernel’s virtual machine space. This region is where the kernel mode side of the operating system executes. The kernel, all operating system extensions such as FileSys and GWE, as well as all kernel mode device drivers, are loaded in this region. The size of this region depends on the CPU. For SH4 CPUs, the region is 256 MB but for all other CPUs the size is 512 MB. Finally, the region at 0xF000 0000 is used by the kernel for CPU-specific purposes.
This new memory map is a big clue that this is not your father’s Windows CE. For an even clearer example of the vast changes to the operating system, let’s turn to how the Windows Embedded CE 6.0 is architected.
이전의 Windows CE버전과 마찬가지로, 물리 주소 영역에 있어서 캐쉬 & 언캐쉬 윈도우라는 커널 주소 영역의 두 영역이 존재한다. 이러한 윈도우를 통해 OS와 드라이버들은 램과 메모리맵된 주변회로(?)를 접근한다.
주소 0xC000 0000부터 128MB 영역에 커널에 의해 로드되는 ROM-based DLL들이 맵된다.
주소 0xC800 0000부터 128MB 영역은 RAM-based object store를 맵하기 위해 파일시스템에 의해 사용되어 진다.
주소 0xD000 0000부터 시작하는 영역은 커널의 가상 머신 공간이며, OS의 커널 모드로 실행된다. 그리고 커널( FileSys, GWE, 그리고 모든 커널 모드 디바이스 드라이버들과 같은 모든 OS의 확장)이 이 영역에 로드된다. 또한 이영역의 사이즈는 CPU별로 종속적이다.
예로, SH4 CPU에서는 250MB이지만 다른 모든 CPU에서는 512MB이다.
결론적으로 0xF000 0000의 이 영역은 각 CPU별 목적에 따라 커널에 의해 사용되어진다.
이런 새로운 메모리 맵은 이전의 Windows CE가 아니라는 커다른 단서가 된다.
OS에 있어서의 커다란 변환들의 명맥한 예에 대해, Windows Embedded CE 6.0의 구조가 어떻게 되었는지 알아보자.
The Operating System Architecture
As with the memory discussion, to fully appreciate the changes in the Windows Embedded CE 6.0 kernel, we need to hearken back to Windows CE 5.0 to see how it was put together. From its inception, Windows CE had been designed around a series of user mode processes called Process Server Libraries (PSLs). While the kernel, Nk.exe operated in kernel mode, the other parts of the operating system such as the file system, the device manager, and the graphics subsystem were each separate, user mode executables named FileSys.EXE, Device.EXE, and GWES.EXE, respectively.
메모리 논의에 있어서, Windows Embedded CE 6.0 커널의 변화를 충분히 인식하기 위해서는 우리는 이 모든것이들이 어떻게 구성되었는지 보기 위해 다시 Windows CE 5.0에 귀를 귀울일 필요가 있다.
These separate processes made the operating system robust, because the major subsystems were protected from one another, but at the expense of performance. A single function call to the operating system caused at least one and possibly two process switches. In addition these processes were subjected to the same 32-MB process limit that Windows CE imposed on all processes.
이러한 분리된 프로세스들은 OS를 견고하게 만든다. 왜냐하면, 퍼포먼스에서 댓가를 치르지만 주요 서스시스템들은 다른것들에 의해 보호되기 때문이다.
OS로 단일 함수 호출은 적어도 한번 그리고 혹은 두번 프로세스 스위칭을 야기한다.
더불어 이러한 프로세스들은 모든 프로세스들에서 Windows CE가 내포하고 있는 동일한 32MB 프로세스 제한에 지배를 받는다.
The new Windows Embedded CE 6.0 kernel does away with separate processes and brings all the subsystems into the kernel’s virtual machine. This change improves the performance of the operating system because communication between the subsystems is now a simple, intra-process call. Figure 6 shows a diagram of the new operating system architecture.
새로운 Windows Embedded CE 6.0 커널은 분리된 프로세스들을 날려버렸고, 모든 서브시스템들을 커널의 가상 머신에 넣었다.
이런 변화는 서브시스템들간의 통신(intra-process call)이 간단해졌기 때문에 OS의 성능을 향상시킨다.
그림6은 새로운 OS구조의 다이어그램을 보여준다.
.gif)
Figure6
Notice that the earlier subsystems (FileSys, Device, and GWES) are now DLLs. In addition, the kernel code that used to be in Nk.exe is now in Kernel.dll. The new Nk.exe contains only the OEM abstraction layer code and a very thin compatibility layer. This separation will improve maintainability because the kernel can now be updated independently from the OEM code.
눈여겨 볼것은 이전의 서스시스템들(FileSys, Device 그리고 GWES)은 현재 DLL들이 되었다는 것이다. 더욱이 Nk.exe로 사용되어 졌던 커널 코드는 Kernel.dll이 되었고, 새로운 Nk.exe은 단지 OEM abstraction layer(OAL)코드와 매우 엷은 호환 레이어를 포함하고 있다.
이런 분리는 커널이 OEM 코드에 의해 독립적으로 업데이트되기 때문에 유지보수를 향상시킬 것이다.
Now that the device manager is in the kernel VM, most of the device drivers also migrate there too. As with previous versions of Windows CE, the device manager will load device drivers both on boot and on demand but now, instead of running in user mode, most device drivers will operate in kernel mode.
현재 디바이스 메니저(Device Manager)는 커널 가상머신안에 있으며, 또한 대부분의 디바이스 드라이버들은 커널 가상 머신쪽으로 바꾸어졌다.
이전의 Windows CE 버전에서와 마찬가지로 디바이스 메니저는 부트때 그리고 요구시 디바이스 드라이버들은 로드한지만 사용자 모드(User Mode)에서 동작하기 보다는 대부분의 디바이스 드라이버들은 커널 모드(Kernel Mode)에서 동작한다.
While running the drivers in the kernel VM might imply that a big porting job is looming for OEMs moving to version 6.0, the porting should be quite simple. The key to the simple porting task is a new DLL named k.Coredll.dll. This DLL mimics Coredll.dll, which still resides in user mode, to provide the same API to kernel mode code as is presented to user mode applications. When a kernel mode DLL calls an API such as VirutalAlloc, k.CoreDll simply reflects the call to Kernel.dll for processing. Because this call is all within the same VM, the time to call the VirtualAlloc code is significantly less than if a driver had called it in Windows CE 5.0 or before.
커널 가상머신에서 드라이버가 동작한다는 것은 OEM들이 버전 6.0으로 바꾸는데 있어서 커다란 포팅 작업들이 불안 혹은 중요하게 됨을 내포하고 있지만 포팅은 아주 간단하다.
간단한 포팅 작업에 있어서의 주요 키는 k.Coredll.dll이라는 새로운 DLL이다.
이 DLL은 Coredll.dll을 본뜬것이며 사용자 모드의 어플리케이션에서 동일한 API가 보여지는 것처럼 커널 모드 코드에 동일한 API를 제공하기 위해 여전히 사용자 모드에 상주하고 있다.
커널 모드 DLL이 VirtualAlloc와 같은 API을 호출했을 때 CoreDll은 간단히 처리를 위한 Kernel.dll에 호출을 반영(전달)한다. 이러한 모든 호출은 동일한 가상머신에 존재하기 때문에, VirtualAlloc코드를 호출하는 시간은 Windows CE 5.0 혹은 이전 버전에 있어서 드라이버가 호출되는 것보다 월등히 작다.
Coredll.dll is not the only DLL to get this “k.” treatment. Any DLL that needs to be loaded in both kernel and user mode will be actually loaded in both. Because Windows CE 6.0 retains the need to keep a single instance of a DLL at a fixed address, the kernel copy of the DLL will have its name mangled by prefixing a k. to the DLL name.
Coredll.dll은 오직 이런한 "k."처리를 같는 유일한 DLL은 아니다. 커널모드와 사용자 모드에 로드될 필요가 있는 DLL은 실질적으로 양쪽에 로드될 것이다.
Windows CE 6.0은 고정 주소에서 DLL의 단일 인스턴스를 유지하기 위한 요구를 유지(고수)하기 때문에, DLL의 커널 복사는 DLL 이름에 접두사 "k."붙인 이름을 가질것이다.
There are some drivers that, on some systems, should not be in the kernel VM, for example, a third-party driver that was installed on a device after it shipped. For these types of drivers, Windows Embedded CE 6.0 provides a user-mode device driver manager that will load the driver in user mode. User-mode driver will be somewhat slower when communicating with calling applications but their isolation will improve security.
어떤 시스템에서 어떤 드라이버들(예, shipping된 이후 설치되었던 서드파티 드라이버)은 커널 가상 머신에 있을 필요는 없다.
이러한 종류의 드라이버에 대해서, Windows Embedded CE 6.0은 사용자 모드에서 드라이버를 로드하는 사용자 모드 디바이스 드라이버 메니저를 제공한다. 사용자 모드 드라이버는 호출하는 어플리케이션과의 통신때 다소 느릴 것이지만, 그들의 고립(?)은 보안성을 향상시킨다.
Services are supported in Windows CE 6.0 almost identically to the way they have been supported in previous versions of the operating system. Like before, services under Windows CE 6.0 will operate in user mode and will be loaded by the services manager. Their design does not change and, except for a minor registry, change services written for Windows CE 5.0 will run unmodified in Windows CE 6.0.
Windows CE 6.0 에서 제공되는 서비스들은 이전 버전의 OS에서 제공되어져 왔던 방법과 거의 유사하다. 이전 버전과 마찬가지로, Windows CE 6.0에서의 서비스들은 사용자 모드에서 동작하고 서비스 메니저에 의해 로드될 것이다.
이러한 디자인은 바뀌지 않았으며, 중요하지 않은 레지스트리를 제외하고는 Windows CE 6.0에서 수정없이 Windows CE 5.0이 돌아가기 위해 씌어진 서비스들은 바뀌었다.(? 무슨말이야)
Programming Impacts of the New Design
While the new architecture looks interesting, most programmers reading this article may be wondering, “What does this mean for my applications?” Fortunately, the operating system changes noticeable by applications are going minor, and mostly, for the good.
새로은 구조는 흥미롭게 보이겠지만, 이 글을 읽고 있는 대부분의 프로그래머들은 의아해 할것이다. "내 어플리케이션에 있어서 이 새로운 구조가 어떤 의미를 가지는가 ?"
다행이도 어플리케이션에 있어서의 눈에띠는 OS변화는 사소(minor)하며 대부분 좋다.
First, let’s look at the old problems that are now gone. Windows CE, specifically Windows Mobile, systems have been plagued for years with the problem of too many DLLs taking too much of a processes virtual memory space. The small application VM space, along with some rules that Windows CE used for loading DLLs causes fits for some systems. With the new, 2 GB address space, the “DLL crunch” problem is a thing of the past.
먼저 지금은 없어졌지만 이전의 문제점들에 대해 살펴보자. Windows CE시스템, 특별히 Windows Mobile은 많은 DLL들이 많은 프로세스 가상주소공간을 가지는 문제로 수년 동안 괴롭혀졌다. DLL들을 로딩하는 약간의 규칙과 더불어 작은 어플리케이션 VM 공간은 어떤 시스템에서는 적절하다.
Another effect of the larger memory space, the problem of running out of virtual memory space when reserving large numbers of virtual memory blocks is now gone. In fact, system programmers who used to be obsessed with the small VM space are now going to see applications that run out of physical RAM before they run out of VM space. It’s not that Windows Embedded CE 6.0 uses that much more RAM than earlier versions, rather than with the VM barrier removed, lazy programmers will simply allocate memory to fill up the available space.
A standard feature of Windows CE since 2.12 has been the “trusted module” method of security. In this scheme, modules (EXEs and DLLs) are checked during the load process. The OEM code can then decide to have the system load the module in either “trusted” or “untrusted” mode. If the module runs in “trusted mode,” it can call any API in the system. Code in modules that are “untrusted” cannot call a small set of system critical API and cannot set any thread to a priority higher than eighth from the lowest priority. In addition, the OEM can even tell the system not to load a module.
Windows CE 5.0 and before also has a special mode where the system runs all code in kernel mode, instead of running the kernel in kernel mode and the remainder of the system in user mode. The advantage of running in “all kernel mode” is performance with the tradeoff being security, because the kernel code and memory space is accessible to all applications.
Windows Embedded CE 6.0 does away with both “all kernel mode” and the trusted model of security. All kernel mode is not necessary because most of the performance gains of “all kernel mode” are gained by the new kernel architecture. The trust model goes away in anticipation of the porting the desktop’s Access Control List (ACL) security to a future version of Windows CE. For Windows Embedded CE 6.0, there is no trusted model, nor is there ACL security.
Interprocess Communication
Windows Embedded CE 6.0 provides the same interprocess communication tools as in previous versions of Windows CE. These tools include RAM-backed memory-mapped files, point-to-point message queues, and the old classics such as the WM_COPYDATA message.
Windows Embedded CE 6.0은 이전 버전의 Windows CE에서 제공하는 것과 마찬가지로 동일한 상호프로세스 통신을 제공한다. 이러한 기능은 RAM-backed memory-mapped file, point-topoint message queue 그리고 WM_COPYDATA 메시지와 같은 옛 클래식(?)들을 포함한다.
What is not available in Windows Embedded CE 6.0 are the “slot based” communication tricks. There are some applications that use the MapCallerToProcess and SetProcPermissions APIs to be able to read and write memory across process boundaries. These two APIs, along with a few other functions that depend on the slot model, are no longer relevant. While they are exported from Coredll.dll for compatibility, the have no effect in Windows Embedded CE 6.0. A workaround for applications that use SetProcPermissions is to use ReadProcessMemory and WriteProcessMemory, which are supported in CE 6.0.
Windows Embedded CE 6.0에서 가능하지 않는것은 "slot based" 통신 트릭들이다.
여기에는 프로세스 경계를 가로질서 메모리를 읽고 쓸수 있게 하는 MapCallerToProcess와 SetProcPermissions 과 같은 API들을 사용하는 어플리케이션들이 있으며, slot model에 종속적은 다른 소수의 함수들고 함께 이 두 API들은 이제는 더이상 적절하지 않으며 호환성을 위해 Coredll.dll로부터 엑스포트되었지만 Windows Embedded CE 6.0에서는 무의미하다.
SetProcPermissions를 사용하는 어플리케이션의 작업은 CE 6.0에서 제공되는 ReadProcessMemory 와 WriteProcessMemory를 사용하는 것이다.
Another change in Windows Embedded CE 6.0 is that applications can no longer copy handles from one process to another. CE 6.0 uses separate handle tables for each process, so handle values are independent for each process. To work around this issue, applications should use the DuplicateHandle API to clone a handle for use in another process.
Windows Embedded CE 6.0에서의 다른 변화는 어플리케이션이 하나의 프로세스에서 다른 프로세스로 핸들을 더이상 복사 할 수 없다. CE 6.0은 각 프로세스에 대하여 분리된 핸들 테이블을 사용하기 때문에 핸들 값은 각 프로세스에 대하여 독립적이다. 이러한 이슈에 대한 작업은 어플리케이션들은 다른 프로세스에서 사용되기 위해서는 핸들을 복제하기 위한 DuplicateHandle API를 사용해야 한다.
In general, well written Windows CE applications (well written meaning they do not use slot-based tricks) will run unmodified in Windows Embedded CE 6.0. To ensure that your application will run, you can use a compatibility testing tool that will be delivered in the Windows Embedded CE 6.0 Platform Builder.
일반적으로 잘 작성된(slot-based trick을 사용하지 않는) Windows CE 어플리케이션들은 Windows Embedded CE 6.0에서 수정없이 동작할 것이다. 당신의 어플리케이션이 동작할 것을 확인하기 위해, Windows Embedded CE 6.0 Platform Builder안에 제공되는 호환성 테스트 툴을 사용할 수 있다.
Conclusion
Windows Embedded CE 6.0 is a huge advance for Windows CE. The removal of the classic kernel limits is going to reduce the demands for consultants who have made a living helping companies work around these issues. This new memory model brings Windows CE much closer to the desktop model without the size or cost of Windows XP. Expect to see a whole new class of powerful devices driven by this new, better version of Windows CE.
Windows Embedded CE 6.0은 Windows CE에 있어서 커다란 진보다. 전형적인 커널 제한 제거는 이런한 이슈의 작업을 하는 컨설턴트들에 대한 요구를 감소시킬 것이다.
새로운 메모리 모델은 Windows CE를 Windows XP의 가격이나 사이를를 제외한 데스크 탑 모델에 좀더 가깝게 한다. 새롭고 진보된 버전이 Windows CE에 의해 동작하는 총재적인 새로운 종류의 강력한 디바이스들을 볼 수 있음을 예상할 수 있다.
This article is excerpted from
http://msdn2.microsoft.com/en-us/library/bb331824.aspx