Intermec Scan to Exit

We had another very curious incident, this time on an Intermec terminal. Each time the terminal scanned a barcode our application would immediately exit.  No warning, no exception, nothing but an immediate exit.  And it wasn’t even a complicated application, just a simple prototype.

What made this even more curious was that it didn’t happen on all of our Intermec terminals and hadn’t occurred in the past with our other customers.  A few more details will make the problem a little clearer.  First of all we are developing in .NET CF 2 with VS.NET 2005 and our SNAP application framework.  The Intermec 760B terminal is running Pocket PC 2003 (OS 4.51 Premium with PSM 3.93.1 for 32MB Flash) and the Intermec 2.4 IDL.Intermec 700 Series Terminals

So it was a matter of rolling up our sleeves and getting down in to the bowels of the source code.  Initially we suspected that there was an exception in the scanner dll causing the application to abort.  We tried the usual tasks such as walking through the code (difficult since scanning is event driven), and catching exceptions on invocation instead of where they are caught, all to no avail.  Finally, it was a matter of controlling the scanning to catch the error, where we found a Windows Message conflict, essentially programmatically triggering the scanner to control the execution in the debugger.

Apparently Intermec has implemented their scanner code using messages and happened to assign the same Window Message ID (WM_USER+1 =  0x401) that we were using for exiting a sequence of forms (in this case out of the application).  And that’s the end of the application.

So what does that mean.  The first thing one could argue is that a system object like this should not expose the window messages to the application, or at least not use one that is quite so common. And I’d think you’d have a pretty good argument there. 

So the simple solution is that rather than using WM_USER as our Message ID base, we could use a value that is unique within the system.  The easy way to do this is to register the window message with the OS and request a unique id.  Simply use the method:

[DllImport("CoreDll.dll", SetLastError = true, CharSet = CharSet.Unicode)]
static extern uint RegisterWindowMessage(string lpString);

static uint WM_MY_MSG = // use RegisterWindowMessage to ensure unique

Of course this isn’t 100% perfect since you can still have people using the same string to register their message.  To take it the next step you can create a GUID, but I think that’s getting a bit much.  Just use a reasonable unique name and everything should be fine. 


Symbol's New WT4070/WT4090

Recently I’ve been doing quite a bit of work with Symbol’s new wearable terminal, the WT4070 and the WT4090, the long awaited upgrade to Symbol’s original DOS wearable terminal the WSS1060. For those unfamiliar with these terminals, these are wearable terminals typically used by warehouse and distribution center workers such as UPS, FedEx, etc. The WT4070 is the currently shipping version that support 802.11 b/g, and the WT4090 will support 802.11 a/b/g. It is actually the same unit with software changes to handle some regulatory hurdles with the radio.

For the last few months, I’ve been working on migrating the SVTP terminal emulator I wrote at Symbol, from the old DOS terminal to Windows CE (SVTPCE) for one of our larger customers. Symbol does ship the WT4090 with a license for another terminal emulator, but our customer preferred having a version that was drop in compatible with their existing terminals, which used the original SVTP, and could be customized to meet their exact requirements.

ARD_SVTPCESince I’ve been working with this new terminal, I thought I’d give a short review of the new WT4090 terminal and some tricks for working with this terminal.

Overall the WT4090 is a great terminal, and is a long awaited addition to the Symbol product line. It’s lightweight at only 12.6 oz. and has a very nice display and keyboard layout. The WT4090 will be available in two keyboard layouts, a “2-tap” keyboard that functions like the legacy WSS-1060 did, and a “3-tap” keyboard that operates more like a cell phone keyboard.

However, the biggest feature is that you now have a full Windows CE 5.0 operating system strapped to your wrist or belt which opens up a huge number of possible applications. Initially I see this product as a technology refresh for the current WSS1060 users who will mostly use it for warehouse and distribution centers, but down the road this could easily be used for many other types of field force applications where it would be helpful to not need to carry the terminal around. And with the belt option and voice capabilities the options expand even more.

The WT4090 also comes with two scanner options, the RS-309 Scanner and the RS-409. The RS-309 scanner is very large and bulky for a wearable scanner and I wouldn’t recommend it, but the RS-409 is a very nice device that compares favorably to the older RS-1 and SRS-1. Also, the scanner can be connected on either side of the terminal to allow for either left or right-handed users.

Display (not Touchscreen)WT400 w/ RS-309
The display is a nice 320 x 240 landscape pixel addressable QVGA. It is sufficiently bright for working indoors, but would be difficult to use in an outdoor environment. Overall a pretty nice display.

One of the first things that I noticed was, like the MC1000, the WT4090 does not have a touch screen!!! When asked, Symbol told me that this was a design decision to help improve the terminal’s ruggedness in the wearable environment. Since the terminal is meant to be worn on the wrist or belt, they felt that having a touch screen would reduce the ruggedness of the device and receive stray mouse events.

However, I find that the lack of a touchscreen on a Windows operating system is difficult to work with. After a while I was able to navigate fairly well with the keyboard, but there are some functions that I was never able to access. Also, its hard to get past the habit of trying to push the buttons on the screen when looking at a windows environment. In a production environment this is probably ok since the end users will not need to navigate the Windows CE Shell, but as a developer or administrator it can be quite painful.

There are two ways to get around this “problem”. First, Symbol has provided USB keyboard and mouse drivers for their terminal which you can use to connect directly to the WT4090 (through the cradle). However, it requires an odd cable, a Mini USB A to USB A Female connector, which is apparently commercially available but not at any of the normal electronics stores (Radio Shack, CompUSA, Best Buy, …).

The second option, is to run the Microsoft ActiveSync Remote Display program to connect to the device over a regular ActiveSync connection. This is the choice I took, since it didn’t require finding special cables, and as a developer I needed to use the USB connection to debug the application. See my article on ActiveSync Remote Display for CE 5.0.

One more consideration when developing applications for the WT4090 is the memory configuration. The device has 128MB of RAM, and another 64 MB of flash available in the /platform and /application directories that Symbol uses for installing applications.

The WT4090 does not provide any slots for an external memory card. In general this is not a problem since the terminal is targeted for a warehouse environment which is continuously connected, but will prevent this terminal from being used in other field force applications.

New Bluetooth Stack
This terminal uses the StoneStreet OneBlueTooth Stack which Symbol is now also using on the MC9094. While in theory switching between the various BlueTooth implementations shouldn’t be a problem, it is when they implement different programming APIs. So for us this means migrating our BlueTooth implementation from using the Microsoft Socket interface to the API provided by Symbol on devzone.

Also note that Symbol is not providing the BTExplorer GUI on this terminal so all BlueTooth access must be done using the software APIs.

Software Development
Development for this terminal is essentially the same as any of the other Symbol handheld terminals. Since it is a Windows CE 5.0 device it is best to do your development in Visual Studio 2005 to be able to deploy your applications.

Symbol provides the folowing set of SMDKs for wearable development (available in devzone):

Around the Burgh: Sunset Hills Farm Alpacas

This weekend we went up near Butler, PA and stopped at Sunset Hills Alpaca Farm and learned more about Alpacas than we ever expected. I’d heard about Alpacas before but really only knew that they were related to llamas and were used for wool. But there’s a whole world of Alpacas and several farms right in the Pittsburgh area.When we arrived we hadn’t realized that this was a family farm and wasn’t really intended to be a public curiosity, but everyone we met at the farm was very friendly and encouraged us to look around and see the Alpacas.When we went out to the pasture to see them, they were very curious in seeing us as well. We had heard that Alpacas are known to spit, which is not just saliva but actually the regurgitated stomach contents and rather foul. However, these Alpacas were very friendly and curious about us..

We also learned a little bit about Alpacas. For instance, Aplacas come from the Andes in Peru and there isn’t such a thing as a wild Alpaca, they were bred down from vicuñas in South America. And, despite their cute fuzzy heads, they don’t like to have their heads pet, but don’t mind being pet on their neck and backs.

The Drive By:
After we were there for a while Lara came out leading Zephyrus their most prized Alpaca. He has won over 10 color champions, and is valued at over a million dollars!!! It’s hard to imagine a farm animal being worth that much!! But he’s sired several other champions and has a virtually perfect pelt and demeanor.

Apparently the way breeding can occur with alpacas is something they refer to as a “Drive By”, essentially a female aplaca is brought to the farm, they are brought to a clean area, and then they are bred. The other curious part about this, is that since alpacas aren’t very big, they don’t need a large trailer and can show up in a mini-van, like this one.

Almost as soon as the female alpaca got out of her mini-van, they were ready to go, and breeding was soon in process. Since alpacas are dribble ejaculators the whole process can take anywhere from five minutes to over an hour, with the male “orgling” (an odd groaning sound) to put the female in the mood. Or at least for a while since after ten or fifteen minutes the female was getting pretty bored and layed down until Zephyrus was done. The other interesting part is that female alpacas are induced ovulators, which means that they don’t really have to worry about the timing, she will ovulate in response to the attempt to breed.

And if all goes well, in another 11 months they’ll have another baby alpaca to continue on the Zehphrus family, like the ones that were recently born this year that were in the barn.

So if you get a chance, be sure to visit an alpaca farm and see these amazing animals.

More information:

Startup Applications on Symbol terminals

There are two ways to cause an application to run during the Symbol startup of the terminal, either using the Symbol Startup Program Registry Keys or as a Startup Application in the Symbol Startup Folder. You should pick only ONE of these choices.

Symbol Startup Program Registry Keys

Symbol has created a set of registry keys that can be used to create a controlled launch of programs during the boot sequence. By setting these parameters, and using the Microsoft wceload command, it is easy to orchestrate the applications that are run during startup.


Where ProgN can be set to any value between 1 and 20. However, be careful since some of the values are reserved for Symbol applications, and may be used by other applications.

Reserved Values:

  • Prog4 Symbol .NET Class Libraries
  • Prog5 Symbol AirBeam Abboot.exe
  • Prog7 Symbol AirBeam Abstart.exe
  • Prog10 Symbol Printer Drivers

Another nice part of the Symbol Registry is the options that can be set for each of the programs. This allows you to have real control over applicationstartup.

Registry Options:

  • Name Application file name with full path spec (string)
  • Command Application command line parameters (string)
  • Continue Block or not block, 1 = do not wait for program to finish
  • ColdBootOnly Run on cold boot, 1 = run on cold only (dword)

While these commands can be used for launching any program, they can also be easily used to install CAB files as well with the Microsoft application. By using Microsoft’s wceload utility you can easily install CAB files from the command line with several helpful options. See the wceload page for details on the command line option.

An Example:


; Load .NET CF 2
“Command”=”/delete 1 /noaskdest /noui windowsNETCF2.CAB”

“Command”=”/delete 1 /noaskdest /noui windowsSVTPCE.CAB”

; Run SVTPCE – Example, uncomment to use.
; Per Symbol the “preferred” method is to use the ApplicationStartup
; directory, but you can’t control the order
“Name”=”Program FilesSVTPCE_FDXSVTPCE”

Symbol Startup Folder

The other main choice is using the Symbol Startup Folder. In this method, you simply create a “.run” file which provides the options for running an application, and installing the file in the “ApplicationStartup” directory. Symbol says this is the preferred method.

A “.run” is a text file with two lines. The first line is the complete name of the executable file (with full path information), and the second line is an optional command line argument to be passed to that executable file. For instance, if the run file contains the command:

Program FilesSVTPCESVTPCE.exe

It will launch the SVTPCE application. However since the execution order is unspecified, if the program needs to be installed first, you will either need to load the CAB files with Registry parameters, or create an application to load the CAB files and run the application.

Pros and Cons of These Methods

Each of these methods for controlling application startup have their pros and cons, and this must be carefully considered when setting up a configuration.

Registry Method: The key advantage of the Registry Startup method is the absolute control that can be had with the startup of the applications. This allows specifying if the applications only runs at cold boot, whether the application is run synchronously or asynchronously, and the exact sequence of the programs. All of which provide a huge amount of control for the user.

Despite all of these advantages, there is also a downside to the Registry Startup method. Since there are a small set of registry values allocated these must be managed very carefully. This is fine if you are integrating a custom system, but can be very dangerous with a product that must be able to interoperate with other programs.

Application Startup Method: This option provides the simplest method for starting applications, but what you gain in simplicity, you lose in control. Unlike the Registry method there are no guarantees on the sequence of the applications that are launched. Likewise, you aren’t able to control how and when the applications are launched. Any such control must be provided in a custom program for your application.

Although you lose control in the launch sequence, it is the simplest method for applications that don’t require special treatment. Also, it is the best method for products that must be able to launch in any environment.

Other references:

ActiveSync Remote Display for CE 5.0

Microsoft’s ActiveSync Remote Display program, which comes as a separate download with the Windows Mobile Developer Power Tools, has always been a nice tool for viewing and demoing applications. 

However, I’ve been recently working on a project on the Symbol WT4070 which does not have a touch screen and only a limited keyboard.  While its possible to access pretty much everything through the keyboard, it’s not easy.

That’s where the ActiveSync Remote Display program makes a huge difference, but unfortunately it does not natively recognize CE 5.0 devices.  However, if you copy the remote client “cerdisp2.exe” on to the terminal, everything starts working again, and you have a nice remote desktop to work from.

So here are the steps:

  1. Download the ActiveSync Remote Display program (EmuASConfig.msi) from the Windows Mobile Developer Power Tools site and install.
  2. Navigate the installation directory (C:Program FilesWindows Mobile Developer Power ToysActiveSync_Remote_Displaydevices).  This directory contains files for all of the platforms that ARD recognizes.  Find the device that best matches your terminal, for most devices this will be “wce400armv4”.
  3. Create an ActiveSync connection to your terminal.
  4. Copy the program “cerdisp2.exe” to the “Windows” directory of your terminal.
  5. Launch ActiveSync Remote Display from the Start Menu.  Note: The message “ The OS or CPU of this device is unknown to this application” will be displayed.  This can be safely ignored.

And then use it like a normal window application as in my SVTPCE application.