Symbol and Intermec Scanner APIs in Windows Mobile 6.5

This article explores how hardware-level barcode scanning engines from manufacturers such as Symbol (later Motorola Solutions and Zebra) and Intermec were integrated into Windows Mobile 6.5. Because Microsoft did not provide a standardized, universal barcode scanning framework within the native Windows Mobile operating system, hardware vendors implemented proprietary Software Development Kits (SDKs) and APIs to interface directly with their scan engines. Below is a breakdown of the specific software architecture, key API components, and programming models used to control these scanning engines in enterprise deployments.

The Lack of a Unified OS Standard

Windows Mobile 6.5, built on the Windows CE 5.2 kernel, did not feature a built-in barcode scanning subsystem. Enterprise hardware relied on two integration methods:

  1. Keyboard Wedge / Data Parsing: A background driver captured scan events and injected decoded ASCII characters into the active input field via standard keystroke events (WM_KEYDOWN/WM_CHAR). While simple, this approach offered zero programmatic control over the scanner hardware.
  2. Vendor-Specific APIs: Hardware manufacturers developed C/C++ dynamic-link libraries (DLLs) and managed wrappers for the .NET Compact Framework (C# and VB.NET). These APIs provided granular control over the scanning subsystem, including symbology activation, scan triggers, illumination, and raw data handling.

Symbol (Motorola Solutions) Scanning Architecture

Symbol Technologies developed dedicated scan engines (such as the SE955 1D laser engine and SE4500 2D imager) and integrated them into the OS through the Enterprise Mobility Developer Kit (EMDK) for Windows Mobile/CE.

Key Assemblies and Namespaces

For managed .NET Compact Framework applications, Symbol provided:

  • Assembly: Symbol.Barcode.dll (Legacy) and Symbol.Barcode2.dll (Modern EMDK).
  • Namespace: Symbol.Barcode and Symbol.Barcode2.

For native C/C++ developers:

  • Header Files: ScanCAPI.h
  • Static/Import Libraries: Direct links to native scan drivers exposed through system DLLs like ScanAPI32.dll.

Core API Capabilities

  • Scanner Initialization: Applications used the Barcode2.Reader class (managed) or SCAN_Open (native) to establish a handle to the physical engine.
  • Asynchronous Event Notification: The API decoupled scanning from the UI thread by using event listeners (Reader.ReadNotify and AttachReadNotify). When a user pulled the physical trigger or software initiated a scan, an asynchronous event returned a ReaderData object containing the barcode type, timestamp, and decoded byte buffer.
  • Symbology Configuration: Developers adjusted decoders programmatically via the Reader.Decoders collection. Specific barcode types (e.g., Code 39, Code 128, DataMatrix, QR Code) could be enabled, disabled, or constrained by length.
  • Hardware Trigger Control: The API allowed programmatic firing of the laser/imager through Reader.Actions.ToggleSoftTrigger() without requiring physical trigger engagement.

Intermec Data Collection Architecture

Intermec built industrial devices using scan engines such as the EV15 (1D linear) and EA30 (high-performance 2D imager). To interface with Windows Mobile 6.5, Intermec supplied the Intermec Developer Library (IDL), specifically the Data Collection Resource Kit.

Key Assemblies and Namespaces

For .NET Compact Framework:

  • Assembly: Intermec.DataCollection.CF35.dll (targeting .NET CF 3.5) or Intermec.DataCollection.CF20.dll.
  • Namespace: Intermec.DataCollection.

For native development:

  • Headers and Libraries: itcscan.h and associated native runtime libraries providing the ITCScan API.

Core API Capabilities

  • The BarcodeReader Class: The primary integration entry point was the Intermec.DataCollection.BarcodeReader class. Instantiating this object bound the application directly to the active internal scanning engine.
  • Event-Driven Data Retrieval: Intermec implemented standard .NET event patterns using the BarcodeRead event. The associated BarcodeReadEventArgs exposed properties such as strDataBuffer (the decoded string), Symbology, and Time.
  • Scanner Control and Direct Commands: Intermec scanners utilized internal configuration commands (often referred to as device settings or Virtual Wedge parameters). The API allowed developers to execute SetDecoderParam() and GetDecoderParam() to modify scanning behaviors, such as minimum/maximum character limits, check-digit verification, and preamble/postamble insertion.
  • Software Triggers: Similar to Symbol, Intermec provided explicit control over the scan engine via methods like BarcodeReader.ScannerEnable and BarcodeReader.ScannerOn(bool).

Comparison of Integration Workflows

Both vendors followed a similar lifecycle pattern to manage scanner power states and prevent resource deadlocks within the constrained memory model of Windows Mobile 6.5:

  1. Allocation: Open the scanner instance during form initialization or on application startup.
  2. Buffer Configuration: Allocate memory buffers to hold scanned data payloads.
  3. Event Hooking: Register callbacks for barcode read events and scanner state change events (e.g., scanner enabled, disabled, or hardware error).
  4. Symbology Filtering: Explicitly disable unused symbologies to optimize the engine's decoding speed and reduce misread rates.
  5. Deallocation: Release engine handles and unregister event listeners when the application loses focus (Deactivate or LostFocus events) to allow other applications or the default OS wedge to access the scanner.