|
Windows CE 5
|
Windows Embedded CE
6.0
|
|
Boot Sequence
|
- kernel was
hard-coded to launch filesys.exe as the second process.
- starting order of system processes and applications was
controlled by registry settings underHKEY_LOCAL_MACHINE\Init.
|
- most of the system
processes have been converted to DLLs that load inside the kernel process,
the system uses a mechanism that supports both DLLs and executables.
- You cannot specify
command-line parameters for executables.
This is unchanged
from previous versions of Windows Embedded CE.
-
Application-loading sequences are specified under the HKEY_LOCAL_MACHINE\Init
registry key.
- You can specify
the load order of system DLLs, executables, and applications under
theHKEY_LOCAL_MACHINE\Init registry key. - The OS launches executables listed
under this key and loads DLLs under this key into the kernel.
You can specify
which DLL entry point to call when the application starts.
- The startup sequence is similar to the service startup
sequence in Services.exe and the registry enumerator.
|
|
Virtual Memory Layout
|
1. there was a limit
of 32 processes, and a 32 MB limit on virtual memory (VM) for each process.
2. all of the
processes shared the same 4 GB address space.
3. the current
application executed in slot zero
|
1. the kernel
process resides in the upper 2 GB of the 4-GB (32-bit) virtual memory space,
and the bottom 2 GB is unique for each process.
2. limit of about
32,000 processes, due to the number of handles that can be created. The
practical limit on the number of processes is bounded by the amount of
physical memory.
3. slot zero, and
all other process slots, are effectively 2 GB each.
4. Because virtual
memory access is translated into hardware access through the memory
management unit (MMU), virtual memory code is CPU-dependent. ARM and x86 CPUs
use hardware page tables, so the content of virtual memory is accessed
directly by the hardware.
|
|
Handle Tables
|
1. a handle to an
event, a thread, a process, a mutex, and so on, could be passed to a
different process and be usable by that process.
- If two
handles were opened to the same object, the handle value, which is the 32-bit
identifier that an application holds onto, was the same for both handles.
In Windows CE 5.0,
generated handle values could elevate user privileges.
- There was one
global list of handles that was shared by all processes. Handle objects are
locked before they are used, and unlocked after they are used. The locking
mechanism is a reference counter, which is incremented before the handle is
used and decremented after the handle is used.
- Handle
objects are destroyed only when their reference counter equals zero, so
handle objects in use are never destroyed.
- a handle object
could be destroyed while it was still in use, for example, in the middle of a
call to an API.
8.the reuse count
was only 3 bits, so a handle could easily be reused. Therefore, stale handles
could be a problem.
-returned the same
handle value for duplicated handles, or a named handle of the same name.
|
1. each process has
its own individual handle table.
- If two handles to
the same object are opened, they have different values, even within the same
process.
- A handle value in
one process cannot be used to access that object in another process. This
includes the kernel.
- The kernel
process, including the kernel-mode servers running under it, has its own
handle table, and cannot use a handle that was opened by a different process.
- If you try
to pass a handle from one process to another, that handle value may already
be used by the other process to refer to a different object. If that other
process tried to use the handle value, it would access a different object.
This improves security because handle guessing is eliminated.
- Handles are looked
up in the handle table, which the user cannot access. This prevents users
from generating handle values.
- Similar to Windows
desktop-based operating systems, every newly created handle, including newly
duplicated handles, has a unique value.
8. Handles cannot
easily be reused because there is a 16-bit reuse count. Therefore, about
64,000 operations to create and close handles would be required to exhaust
the reuse count.
Tradeoffs of the
Handle Tables
Handles are only valid within the process that created
them. Handles cannot be passed between processes. Existing code that passes
handles from process to process must be changed to useDuplicateHandle to create a new handle that the other process can use.
If necessary, use OpenProcessto access the other process.
|
|
Mapping Pointers and Sharing Memory
between Processes
|
- When a function
gets called, the kernel performed a 1-byte access check on pointer parameters
and marshaled the pointer by mapping it.
- The OS address space was arranged so that
the 32-MB virtual-memory address space for every process was accessible at
all times.
- Therefore,
mapping required only modifying the pointer to point to the right memory
space of the target process.
- The server process
was responsible for calling a function such as MapCallerPtr to verify that
the caller process had sufficient privileges to access the entire buffer, and
the server process was responsible for access-checking and marshaling any
embedded pointers.
- both the access
check and marshaling were covered by calling MapCallerPtr.
- The server was also responsible for performing a secure
copy, if necessary.
|
- when an
application calls a function, the kernel performs the full access check on
buffer parameters, taking responsibility for that protection away from the
server processes.
- This is made
possible by giving the kernel more information about parameter sizes. The
kernel still marshals pointer parameters, and servers must still marshal
embedded pointers. Servers must still perform a secure copy, if necessary.
The following list shows what has changed:
- The kernel has
taken over full access checking of pointer parameters.
- The function
servers must call to marshal parameters.
- Options available
for servers to perform a secure copy.
- marshaling must be handled if the server needs to
access a buffer asynchronously.
|
|
Loading DLLs in Kernel Mode or User Mode
|
- One DLL cannot
simultaneously load into both kernel mode and user mode.
- When you run an executable file or a DLL, the code must
be able to run at its specified address. For example, jumps within the code
or references to global variables must be modified to refer to the hard-coded
addresses. Because kernel DLLs load above 0x80000000 and user DLLs load below
0x80000000, it is impossible for a single copy of the DLL to be able to run
in both locations at once.
|
- In Windows
Embedded CE 6.0, the OS bypasses this limitation by having two versions of
some DLLs; one version to load in kernel mode and one version to load in user
mode.
- The kernel has a
new naming standard for DLLs that load in both kernel mode and user mode. The
kernel-mode DLL has a k. at the beginning of the name. user-mode version of
coredll is coredll.dll whereas the kernel-mode version is k.coredll.dll.
- The kernel
automatically translates kernel-mode accesses to user-mode DLLs into the
proper kernel-mode version for this version. For example, if a DLL is linked
to the user-mode coredll.dll, as almost all DLLs in the build system are,
when that DLL is loaded into the kernel process, the DLL is importing from
the kernel-mode k.coredll.dll, instead. There is no load error in this case
because the imports are seamlessly redirected to the kernel DLL. Similarly,
if code in the kernel process calls LoadLibrary on coredll.dll, it actually loads a reference to
k.coredll.dll. Therefore, if it calls GetProcAddress and calls a function, it calls the proper kernel-mode
function.
- if you implement
DLLs, you do not need to change all coredll.dll references to k.coredll.dll
references.
- In fact, that
would destroy portability of your code to user mode. In the future, you may
want to run your code in user mode, instead of inside the kernel.
OEMs may need to specify where their DLLs load with .bib
file flags. The Z flag specifies Windows CE 5.0 and prior versions. Z cannot
be combined with the compression flag C, whereas there are no such
|
|
Process Switching
|
File system.exe, GWES.exe, and Device.exe are process
hence process switch required.
|
File system.exe,
GWES.exe, and Device.exe have become libraries which are loaded into the
kernel. Now that they are libraries, there is no process switch between them.
- Services.exe is still a user-mode process.
|
|
Paging Pool
|
- the paging pool
was a fixed-size portion of memory reserved for executable code and
read-only, memory-mapped files.
- If the amount of
code loaded into memory at any time was smaller than the pool, the pool did
not shrink to match.
- if the amount of
coded loaded at any time was larger than the pool, only the most recently
used pages were held in memory, up to the size of the pool. - The pool did
not grow to hold more code, so executable code discarded.
- OEMs controlled
the size of the paging pool with an OEM adaptation layer (OAL) variable, cbNKPagingPoolSize.
- the page pool
maintained a physically contiguous range of pages and kept an array of
information to track each page in the pool.
- Pages were kept in a global first-in, first-out (FIFO)
list, and in a list per module for quick discarding of a module on unload.
|
- The pool can
temporarily exceed its reserved size.
- Rather than
setting a single size for the pool, an OEM can now choose a target size for
the pool, plus a maximum size.
- There is always
enough memory reserved for the pool to grow to reach its target.
- Above that, if
memory is available the pool continues to grow, up to the maximum limit.
- The pool never
exceeds the maximum.
- As soon as the
pool exceeds the target, the kernel wakes up a trimming thread that walks
through modules and discards pages.
- The trimming
thread runs at low priority normally, so that paging operations do not
disturb other system activity.
- If the pool
approaches its maximum limit, the trimming thread runs at higher priority
temporarily to ensure that pool memory is released.
- There are now two
pools.
- One pool, the
loader pool, holds executable code and read-only, memory-mapped files as
did the Windows CE 5.0 paging pool.
- A second
pool, the file pool, holds data pages from memory-mapped files and
from the new CE 6.0 file system cache manager.
- The file pool is
different from the loader pool in that its pages may also be read/write, so
they may need to be written back to disk before being discarded.
- Therefore, the
file pool can be configured separately from the loader pool to maximize
system performance.
- Because file
writes are relatively slow operations, the file pool trimming thread runs at
lower priority than the loader pool trimming thread.
- the OAL variable cbNKPagingPoolSize
is deprecated.
- Instead, to
configure paging pool parameters, OEMs can implement a new IOCTL in their
OAL: IOCTL_HAL_GET_POOL_PARAMETERS.
- If the OAL does
not implement this IOCTL, the kernel chooses suitable default settings.
- The kernel also
exposes information about the current state of the paging pool to
applications through the new kernel IOCTL IOCTL_KLIB_GET_POOL_STATE.
- Applications can call this IOCTL to query current
memory usage and other state information about the paging pools.
|
|
Kernel Mode
|
1. SetKMode and ALLKMODE exist.
|
1. modules (DLLs)
are loaded in the kernel process, a user process, or both.
2. any thread
owned by a module loaded in the kernel process is said to run in kernel mode.
3. any thread owned
by a module loaded in a user process is said to run in user mode.
4. For threads to migrate to different processes, but in
general, this happens only for a short duration when the threads are in
process server library (PSL) servers.
|
|
Kernel Servers
|
- a process server
library (PSL) is a process that implements a set of APIs for applications to
call.
- a kernel-mode
server is a DLL that loads into the kernel process and implements a set of
APIs for applications to call. Kernel.dll, filesys.dll, device.dll, gwes.dll,
and most of device drivers are kernel-mode servers.
- The kernel-mode
servers are supported by a kernel-only version of coredll named kcoredll.dll.
Any code that loads into the kernel, but was linked to coredll.dll, is
automatically redirected to use k.coredll.dll, instead.
Simplified and improved security for API calls.
|
- a user-mode server
is a process that registers an API set.
- Services.exe is a
user-mode server that loads some drivers that in previous version of Windows
Embedded CE were loaded by filesys, device, and gwes.
- Improved performance for most API calls.
|
