Thin Client Hardware Requirements (Windows CE 5.0)

Send Feedback

The minimal hardware requirements and recommendations that Windows Thin Client must have are provided in the following subsections.

RAM and ROM Requirements

ROM and RAM requirements for Windows Thin Client depend on several significant factors, such as CPU selection, software selection, and performance considerations.

The following table shows the RAM and ROM requirements.

Requirement Description
RAM The Windows Thin Client system software and the Microsoft RDP client together require at least 6 MB of RAM. This requirement does not reflect the amount of RAM that is required for the video frame buffer or the OEM-supplied software. This memory requirement supports a Windows Thin Client that is running one or two RDP sessions.
Note   Each RDP session requires approximately 4.5 MB of RAM.
You can change the amount of memory each RDP session uses by adjusting the value of BitmapCacheSize in the registry. For more information, see RDP Registry Settings.
Nonvolatile memory The Windows Thin Client requires sufficient nonvolatile memory, such as flash memory or nonvolatile RAM, to store the universally unique identifier (UUID) and the registry entries that contain the Windows Thin Client OS design settings. The UUID requires 128 bytes of memory. The amount of memory that is required to store the OS design settings depends on the device, the software that is installed, and the number of Windows Thin Client connections that are defined. A typical Windows Thin Client device that has the RDP client installed and that has five connections defined requires approximately 20 KB of storage.

Microsoft recommends that you provide sufficient nonvolatile memory for the registry to grow to at least 50 KB in size.

ROM If the Windows Thin Client is booted from ROM, it requires a minimum of 4 MB of ROM.

The default thin client design template includes Windows .NET Compact Framework which takes our image to size to more than 4MB.

Additionally, the ROM must be sufficient to support software that you add to the Thin Client.

Generally, flash memory is used for ROM. This permits the upgrade of Windows Thin Client software without requiring hardware replacement.

In situations in which multiple RDP sessions are required, RAM becomes increasingly critical to the operation of the terminal. If a user attempts to start a session and there is insufficient RAM, then the Windows Thin Client Shell sends a message that the client process cannot be started. In designing your Windows Thin Client device, consider the needs of your customers when you establish RAM size for your Windows Thin Client.

Input/Output Devices Requirements

Input/output (I/O) devices allow data exchange between the terminal and a user.

Microsoft recommends that you also include the following I/O technologies and peripherals in the Windows Thin Client:

  • A keyboard
  • A pointing device
  • Network connectivity hardware.

Although the use of mass-storage devices, such as ATA PC Cards, is permitted for the Windows Thin Client design, rotating mass-storage devices is not recommended because of reliability concerns.

The Windows Thin Client does not support audio-input hardware, IrDA, or video capture.

Display Hardware Requirements

The following table shows display hardware requirements for Windows Thin Client devices.

Requirement Description
The display hardware must support 8 bits per pixel (BPP). Windows CE supports pixel depths from 1 BPP to 32 BPP. Windows Thin Client supports 8 BPP, 16 BPP, and 24 BPP.
The display hardware must support resolution of 640 x 480 pixels at 8 BPP. The Windows Thin Client software supports desktop resolutions that run at 640 x 480, 800 x 600, 1024 x 768, 1280 x 1024, and 1600 x 1200 pixels.
The CRT display hardware must provide contrast control. The display device must include contrast control hardware.
Note   An LCD display may only have backlight control.
Color display must have brightness control. The display device must include brightness control.

System performance is highly dependent on graphic performance. For best video performance, you should use an accelerated video graphics adapter and hardware-accelerated graphics. For more information, see Working with Graphics Devices.

Keyboard Hardware Requirements

The hardware that performs keyboard scans can be simple and can require CPU control from the low-level hardware-dependent portion of the driver.

The following table shows the requirements for the keyboard device and subsystem:

Requirement Description
The subsystem must support all functionality that is required in a Windows environment. The following list shows the minimal support:
  • Delivery of scan codes. The keyboard driver must support MapVirtualKey because RDP on Windows CE does not support sending virtual key codes directly to the server. Instead the client reads the virtual key codes from the message queue and converts these virtual key codes to scan codes using MapVirtualKey.
  • Roll-over
  • Separate LEFT SHIFT, RIGHT SHIFT, ALT, CTRL, and Windows keys
  • Function keys from F1 to F12
Hardware must meet the minimum Windows CE and Windows Thin Client requirements. The following list shows the minimum hardware requirements:
  • Interrupt on key press
  • Interrupt on key release
  • Keyboard roll-over support
  • Keystroke debounce support
  • Keyboard buffer

For more information about specific keyboard drivers, see Keyboard Drivers.

Pointing Device Requirements

Typically, the pointing device for Windows Thin Client is a mouse or a touch screen. The following table shows the requirements for the pointing device.

Requirement Description
The device must emulate mouse movement and button events. The device must correctly emulate mouse-movement events. Mouse-movement events must be separate and independent of button events.
The device must support minimum coordinate resolution. The device must provide coordinates to a minimum of pixel resolution.
The device must support minimum sampling rates. The device must provide a minimum of 100 samples per second at regular intervals.
The device must support minimum bits per sample. The device must provide resolution with enough bits per sample to resolve coordinates accurately.
The device must provide per-sample interrupts. The device must provide per-sample interrupts.
Pointing device filtering and calibration must be supported for devices that require these capabilities. Touch screens and glide pads require filtering to remove erroneous samples that are caused by noise. Touch screens require a method to calibrate them properly to their displays. This calibration can be done with either hardware or software.

I/O Port Requirements

Although parallel, serial, and USB ports are not required, they are recommended. RDP supports serial and parallel port redirection. A server application can therefore interact with the client's serial port to connect to devices, such as a bar code scanner.

The following table shows the serial port requirements for a Windows Thin Client device.

Requirement Description
The port must meet minimum RS-232-C hardware requirements, if RS-232 is present. In general, the serial port hardware must support the standard technologies that are found in the universal asynchronous receiver/transmitter port of a computer.
The port must meet minimum speed requirements. The port must support speeds of up to, and including, 115.2 kilobytes per second (KBps).
The port must meet framing requirements. The port must support all of the combinations of parity and stop bits. Also, it must support word lengths of at least seven and eight data bits.
The port must meet flow-control requirements. The following list shows the support requirements of hardware flow control:
  • Request To Send (RTS). Required.
  • Clear To Send (CTS). Required.
  • Data Terminal Ready (DTR). Optional.
  • Data Set Ready (DSR). Optional.

The port must support software flow control, including the capability to support a clean stop in the current buffer transmission.

The serial port must also support a maximum skid of 16 bytes. This is the maximum number of bytes that continue to be sent after the receiver requests a flow control off command.

The port must support a break in hardware. When the serial port hardware receives a break command, it must stop transmission cleanly at a framed byte boundary. Notice that the break command is differentiated from the sending of a continuous stream of logic 0 bytes, because the 0 bytes is framed.
The port should use a standard DB-9 connection. For ease of use and convenience, serial ports should use the standard DB-9 connector.
The port must support minimum signal-line requirements. The following list shows the requirements for each signal:
  • Ground (GND) signal. Required. Electrical ground.
  • Transmit Data (TXD) signal. Required. This data output signal must provide RS-232-C signals at +/– 12V.
  • Receive Data (RXD) signal. Required. This data input signal must handle RS-232-C signals at +/– 12V.
  • Ready To Send (RTS) signal. Required. This software-controlled output signal is used for hardware flow control, and must provide RS-232-C signals at +/– 12V.
  • Clear To Send (CTS) signal. Required. This input signal must generate an interrupt on every +/– 12V edge. The interrupt must be enabled only when the serial port is powered.
  • Data Carrier Detected (DCD) signal. Required. This input signal must generate an interrupt on every +/– 12V edge. The interrupt must wake up the device from suspend mode and be enabled at all times, including times that the serial port is in suspend mode.
  • Data Terminal Ready (DTR) signal. Required. Software-controlled output; must provide RS-232-C signals at +/ – 12V.
  • Data Set Ready (DSR) signal. Optional. This input signal generates an interrupt on either edge of +/– 12V. This interrupt must be active only during stand-by and full-power modes.
  • Ring Indicator (RI) signal. Optional. Input that generates an interrupt on a transition from +12V to –12V. This interrupt must be active only during stand-by and full-power modes.

For more information about I/O ports, see Programming Serial Connections and Parallel Port Architecture.

Audio Hardware Requirements

Although Audio output hardware is not required for Windows Thin Client devices, it is recommended. RDP supports audio playback redirection. This allows a server application to playback at the server or client audio output hardware.

If audio is supported, the Windows Thin Client must support the playback of 8-bit, monophonic ("Mono"), and pulse-coded modulation-formatted audio files. The following list shows the audio output requirements for Windows Thin Client:

  • The Windows Thin Client device must have a single channel, 8-bit D/A converter.
  • The Windows Thin Client device must have a 22.05 KHz sampling rate.

Note   For better results, upgrade to 16 bits per sample and 44.1 KHz sample rate.

For information about audio playback options, see Windows Media Technologies.

See Also

Developing a Windows Thin Client

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.