Symbol MK1200 - Access the Windows CE Desktop

When Motorola introduced the MK500 and MK4000 we developed the StepOne PCK Emulator.  This allowed customers to extend their investment in the software they had developed for the PCK9100 and MK1100/MK1200/MK2000 series of kiosks.

We even went so far as to support the existing configuration files on the MK series of devices that is located in the \Application\symbolpck directory (display.def and PCK2000.CFG).  Normally this is a simple case of connecting the device with ActiveSync and pulling the files across, but it’s an old device and needs a special serial cable to connect.

It also has a compact flash card, so that is often the easier route.  But, then the problem is breaking out of the application to the Windows CE Desktop so you can actually get to the files.  Fortunately there is a way to break out, by preventing the launch of the kiosk application described in the Symbol MK1200 Product Reference Guide page 6-3.

To prevent launching an application on power-up:

1. Perform a cold boot: press and hold buttons B and C on the MK1200 until the display goes blank (typically 15 seconds), then release the buttons.
2. To prevent the MK1200 from entering an application, simultaneously press and hold buttons A and D just after the blue Performing System Initialization (Phase 1) screen appears, and before the message changes to Phase2. Release the buttons.
3. When the Enter Password prompt appears, press buttons DDBAC and touch OK, or simultaneously press the A and B buttons for Enter. The MK1200 enters Protected Mode and the Windows® CE desktop appears.

To prevent the applications from starting in the first place, look for the file \Application\mkconfig.reg.  It contains the automatic start up configuration (Startup Applications on Symbol terminals) as well as many other configuration settings.  Either edit it, or move it out of the way.
Now you can access the configuration files, copy them to a compact flash card and transfer them to the computer and use them with the StepOne PCK Emulator.

.NET CF Remote Performance Monitoring

The first step for learning about .NET CF Remote Performance Monitoring is Steven Pratschner’s excellent post, Analyzing Device Application Performance with the .Net Compact Framework Remote Performance Monitor, which provide straight forward walk through of using RPM.

Install .NET Compact Framework 2.0 SP 2 on the Workstation.

Download and install .NET Compact Framework 2.0 Service Pack 2 Redistributable to get the Remote Performance Monitor and a bunch of other useful tools and updates.

Prepare the device for Performance Monitoring

Install the components from the workstation to the device and configure the device to enable Performance Monitoring.

1. Install .NET CF 2 SP2 on the device.
   Copy the .NET CF 2 SP2 CAB file to the device.  The file can be found at C:\Program Files\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE\wce500\armv4i (change your OS version and processor if needed). Then choose NETCFv2.wce5.armv4i.cab for CE or NETCFv2.wm.armv4i.cab for the WM version.  Copy the CAB file to the device with ActiveSync and run to install.
2. Install Device Side Files
   There are two device files netcfrtl.dll and netcflaunch.exe that need to be copied to the \Windows directory on the device. They can also be found in the directory above.
3. Configure the registry to enable performance monitoring on the Device
   Set the registry to allow Performance Monitoring on the device.  This is detailed in David Klines post on Enabling Performance Counters.
   [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\PerfMonitor]
   “Counters”=dword:00000001

To verify that everything is configured correctly fun the program \Windows\netcflaunch.exe.  If you get the following display, everything is working.

Now to better understand all of the various settings and attributes, take a look at David Kline’s detailed walk through of RPM, Monitoring Application Performance on the .NET Compact Framework.

agent.exe and ISUSPM.exe are taking over my machine

Today I was doing some coding and getting intermittent performance.  When I looked there was a program called agent.exe that was hogging all my resources.  When I killed it, it was using 50-75% of CPU and 600M of memory.   When I killed it, it auto-started and continues to suck memory, but not as bad on memory.

I started up the latest version of Sysinternals Process Monitor and It turns out that the agent.exe program and ISUSPM.exe program are actually the Macromedia Software Manager Agent.  According to a couple of the process sites like BleepingComputer and File Net

You can actually run the Software Manager directly from the Start->All Programs->Software Updates, it’s the water drop icon.  In running that, it turns out that it was the Intermec IDL Device Resources Kit, that installed the agent to let me know about their updates.

Regardless, I’m not interested in random programs sucking down resources on my computer.  Although, it seems reasonable to do the updates on demand.

To find the startup program its a lot easier to run the System Configuration Utility, msconfig.exe from Start->Run and disable it on the Startup tab.

You can test it this way, but to permanently remove the program from the system startup you need to delete the actual registry key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\ISUSPM

Now I can run System Updates if I feel like, but it won’t run when I don’t want it.  Now things are running back where they should be.

.NET CF RPM - Who is Using My Controls

The primary use for Remote Performance Monitor is to find memory leaks and other kinds of objects that are growing a causing system problems. It is also very good for finding who is using a particular resource.

However another question is, which forms are actually using a particular control. In this case, we have a ClockControl that displays the current time on the form. The clock control is then updated on a regularly to display the current time. In theory, we should only need one clock ever displayed in our application, but by using RPM we see that there are actually three.  This is easily found by looking in the left panel of the GC Heap View.

But who is actually using the Clock Control? That is also easy to determine by looking at the right hand panel and finding the SNAP.UI.Controls.ClockControl object.  By expanding the object tree we can see the three separate memory objects and in the first line of each one is the form that is using the clock control.  In this case it’s PCKE.Forms.BrowserForm, SNAP.UI.Forms.MessageBox, and SNAP.UI.FormsKeyboardForm.

Also, we can see that each one of those is referenced by a SNAP.Util.UpdateTimer, which means each one is set up to receive Updates, even though they are not being displayed.  Now, we can start looking more closely to determine if the code should be updated.

Resizing ContentMenus on .NET CF

When developing applications for the mobile environment, we are very conscious about what it takes to make it a pleasant usable experience for our customers.  This means an interface that is navigable with your fingers rather than the stylus (that is always missing).  Things like big buttons that are easy to press with your fingers, a keyboard that is usable, NOT the horrible one that comes with Windows Mobile, and so on.

Typically this is just a case of making a set of design decisions that work well for us, writing a little code and moving on.  But that’s not the case with the ContextMenu which does not provide any method in .NET CF to set the font at all.

A while back Daniel Moth described a method where you can set the registry to affect the way the menu is drawn.

Menus (MainMenu, ContextMenu and MenuItem) are resized according to their Font. However, they do not expose a Font property, so you are stuck with whatever the default Font is for the platform. You can change that through the registry:

HKLM\Menu\BarFnt

, DWORD “Ht” for height , DWORD “Wt” for boldness: 700 or 400

HKLM\Menu\PopFnt

same as above, but this applies to menu items rather than the menu bar

The actual registry keys are

• HKEY_LOCAL_MACHINE\SYSTEM\GWE\Menu\BarFnt used for menu bar fonts.
• HKEY_LOCAL_MACHINE\SYSTEM\GWE\Menu\PopFnt used for popup menu fonts.

For instance to increase the height of the menu to something a little larger just set the height to 1200

[HKEY_LOCAL_MACHINE\System\GWE\Menu\PopFnt]
“Ht”=dword:000004b0

The default content menu:		The adjusted content menu:

The official page System Font Registry Settings describes these fonts and a few others.  The font definitions are based on the LOGFONT method of defining a font.

Another important point is that these fonts are loaded when Windows System starts up so after you set the value in the registry the system needs to be warm booted.

Overall I really can’t support this UI design.   It seems reasonable that OS forms would use a standard font size, but when I can control virtually every other font in my application, I should also be able to control this font.  On the desktop it is possible with OwnerDraw can get around this or you could use the OpenNet CF PopupMenuControl, but this really should be part of the base system.

PCI - No Wireless, No Excuse

With the recent PCI standards, not deploying a corporate Wireless LAN in your stores, doesn’t allow you to ignore Wireless LAN security. In a recent PCI Data Security Standard (DSS), Information Supplement: PCI DSS Wireless Guidline, the Wireless Special Interest Group has specifically reviewed the PCI requirements as they relate to wireless LANs and state that wireless scanning to detect rogue APs is required.

PCI DSS Requirement
11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.

Considering how easy and cheaply it is possible for an employee or intruder to purchase an Access Point or WLAN access card and install it on the corporate  network, this makes perfect sense.

With the prevalence of laptop computers and consumer mobile devices add a wireless LAN, is typically not a matter of malicious intent, but convenience for the store employees to access either corporate resources or the public Internet more easily.  It may even be making the store associates more efficient in performing their jobs, by keeping the store manager on the floor, or educating the sales associates on the features of their merchandise and their competitor’s promotions.

Unfortunately, the access point that was innocently added to the network can become an open door for an unwanted intruder.  Without the proper security configuration including modifying default keys and passwords, enabling 802.11 security,  which is unlikely with a rogue AP, this is an open invitation for a hacker to access the corporate  network.

And even worse, is the scenario where the rogue device was deliberately added to the network as part of an attack of the network.  In this case, the wireless devices could be physically obscured and configured to avoid detection.

So what is a retailer to do.  The low tech solution is to perform a quarterly audit with a wireless analyzer at every store, and other location that credit card information touches.  While this may be possible for a small operation, the logistics and costs soon make it impractical.

The only practical solution is to automate the process with a wireless Intrusion Detection/Prevention System (IDS/IPS) such as Motorola’s AirDefense products.  These products are installed within the corporate environment to continually monitor and detect intrusions within the store environment and report them for processing to the IT organization.

Additional Resources:

• PCI DSS
• PCI DSS Wireless Guidline
• Wikipedia: Payment Card Industry Data Security Standard
• Motorola AirDefense

Pittsburgh, G20 and Eric Schmidt

This year the G20 has come to Pittsburgh which has come as an unexpected surprise to those of us who live in Pittsburgh.  I spent the morning at the Pittsburgh Technology Council Pre-G20 event featuring Eric Schmidt, CEO of Google.

It was an interesting forum split in to two sessions In the first session for council members, Andre Russo had a “fireside chat” with Eric Schmidt about Pittsburgh’s history of innovation and how today’s entrepreneurs are continuing this legacy.

Session 1: Fireside Chat with Audrey Russo

When outsiders think of Pittsburgh, they still think of us as an industrial city. They think of Andrew Carnegie’s Steel mills and George Westinghouse’s air brakes. The Pittsburghers of years gone by that drove America’s industrial revolution. The Heinz History Center has a great video about this, 250 Years of Pittsburgh Innovation.

What they often miss, is that the legacy of innovation, entrepreneurship, and work ethic is still alive in Pittsburgh today. However, today’s version is one of information technology, robotics, life science, advanced manufacturing, health care, green technology and a myriad of other innovations that will continue to transform the world.

This legacy of innovation, and Pittsburgh long history as an inventor of computer science itself,  is what led Google to establish a Pittsburgh office in 1996 on Carnegie Mellon’s campus.  Now with over 100 employees in the local office Google is continuing to expand it’s presences with the recent acquisition of Recaptcha to this week, and to continue to invest in the region.

It was also interesting to hear his opinion on the Pittsburgh Technology Council which he said was the best in the country. It is nice to here what others have to see about what we often take for granted.

Part 2: Technology, Innovation, and The Global Economy

In the second session, Eric Schmidt gave a presentation on the democratization of information and the ability for computers to process it, and the overall impact on the global economy.

It is this irrevocable change in access to information on a global scale that is transforming the way the world works. Information is no longer narrowly controlled by the media and governments, but the people themselves. We now have access to everyone’s views, not just the official version. Issues are now really shades of gray since all viewpoints are now accessible giving us an increasing transparent view of the world.

Small companies, like StepOne Systems,  are now able to be a micro-multinational, 10 person companies with a global customer base. Not only does the Internet allow access to these customers through email, web sites, and file transfer, but the entire sales, marketing, distribution, and data center requirements can be done on the Internet.  The only true capital expense a company needs to be a global player is some laptops for the employees and a link to the Internet.

It is this disruptive technology that is breaking down barriers and creating a global marketplace.  Increasingly providing more information to empower the consumer and making the world more interconnected.

Review of the Motorola MK500 - Motorola’s Low Cost Micro Kiosk

The MK500 is Motorola’s new low cost Micro-Kiosk based on the same hardware platform as the very popular MC3000 and WT4000 terminals. By using the same core platform, Motorola has not only made it more efficient for their development, but also makes it easier for the software developers, It uses the same development APIs, the SMDK (now the EMDK), touch screen support, and the 320×240 screen size is the standard landscape mode for Windows Mobile. This makes it a simple task to develop (or migrate) handheld applications for the MK500.

In our initial development efforts with the MK500, we have migrated a couple of our snapRETAIl applications, ItemLookup and ItemLocator, both of which ported easily. We did have to make a couple of changes to support the MK500, but both were fairly straightforward. Since the MK500’s three buttons are different than the Windows Mobile terminals, this is a simple case of updating the keyboard event handlers to support the appropriate events

Also since the MK500 doesn’t have hardware scanner trigger, we chose to use the continuous scanning mode of the terminal. This keeps the scanner USB Connector:continuously active on any page that requires scanner input and allows the user to simply scan an item by placing it under the kiosk’s scanner.

Some things I liked:

• Small Form Factor: I think that the MK500 has a great form factor and with the right price I see a lot of applications for this terminal. With it’s small size it can easily be mounted on the edge of a shelf or virtually any other retail fixture. This creates the opportunity to develop customer facing applications right at the point of decision.
• MSIE: The MK500 supports a full MSIE web browser (based on IE6) which makes it possible to develop full-featured web applications.
• Motorola Pocket Browser: The MK500 also natively support the Motorola Pocket Browser. While this seems to be a minor decision, it is really important. As a software developer, I can now develop thin client applications without deploying any software to the device. It would be a good idea to do this for all of the Motorola devices.
• Standard 320 x 240 display: By using a standard landscape QVGA, we can use the same code that we use for the standard landscape Windows Mobile layout.
• Standard SMDK/EMDK: The MK500 support the standard SMDK as the terminals which means I can make an application that deploys to either platform.
• Real Speaker: Having a real speaker is a good decision, this could easily support audio and video applications.

Some things I didn’t like:

• No battery backup: Yes, I realize that this is a wired kiosk and I really shouldn’t expect it to have a battery, but if for some reason I need to unplug it for any reason, it instantly loses everything (radio configuration, object store file system, etc.). Obviously a battery is overkill, but using a super cap, like the handhelds use for battery changes would be nice.
• microUSB Connector: Another very picky issue. The location of the microUSB connector is very tight to the back of the plastics, which is too tight for my universal USB adaptor, but works fine for a standard cable.

Overall this is a great small kiosk which I see as way more than just a price checker.

More Information:

• Motorola MK500 Page
• Motorola MK500 Handout
• Motorola PocketBrowser
• StepOne snapRETAIL Applications

Foolish Enterprise Mobile Technology Purchasing

One of the most frustrating things I see in the enterprise mobile technology space is the deliberate under specing of hardware to save a few nickles. Clearly it is a good idea to be careful with capital spending, but when you are eliminating the possibility of future functionality you are just being foolish.

I’ve seen this in many forms, such as rolling out a thousand batch devices to the field because the current application doesn’t require wireless LAN.  The company saves $50,000 on a one million dollar plus capital spend, everyone congratulates themselves on how they saved a little bit of money and they forever eliminate the possibility of rolling out a wireless application.

Or the other example that always drives me insane is specing out the minimum memory footprint because who would ever want to run something other than a terminal emulator on these devices.  They are after all real computers, with real capabilities.  Maybe someday we could run a real application on these terminals.

And perhaps the worst is purchasing a device that already has an obsolete version of the operating system loaded when it is purchased, particularly as a new device.  Oh we can get a “great” deal on this CE 4.1 device, that won’t run my .NET CF2 apps, has an obsolete web browser, dll crunch and will be an overall disaster to deal with.

The real problem I see is that purchasing still take the short-sighted perspective that the mobile infrastructure will only be needed for the current project.  In the past, that may have been reasonable since developing, deploying, maintaining a single application on a DOS hand held was about all it could handle.

Now the mobile devices should really be considered hand held computers that can be used for any number of tasks.  Today it could be a simple terminal emulator that runs the application, but next year it’s a set of mobile applications to handle inventory, gift registry, mobile communications, web applications and more.

In the consumer world, devices come and go as the seasons, or the two year service contract.  Which is fine when your talking about a $200 dollar investment.  But in the corporate world, the cost is in the millions of dollars every time you upgrade the device.  Obviously this makes it a much different decision and leads company to change the handheld every ten years or more.  Go out to your local retailer and see how many are still stuck in the past using DOS terminals from the 90s.

So if your making a mobile device purchase for you company please consider the future.  Always spend the extra couple of dollars now to maximize the capabilites of the device in the future.  By spending a little bit now, the useful life of the device will be extended for several more years in to the future, and new applications, with real ROI, all without a huge capital cost.

The Web as a Mobile Enterprise Application Platform

In many ways the web seems like it should be the ideal development platform for mobile enterprise applications. It’s a thin client platform with a rich UI experience. There are standard development tools and with AJAX the screen refreshes can make the applications feel like a thick client environment.

And it can definitely work, as we proved back in 2000 when we developed the Sears mobile retail application. This was developed on the Symbol SPT1840 (Palm OS) with a custom, very primitive, web client. On the server side they were originally running Java 1.1 servlets on an OS/2 box (later Windows NT).

So mobile web applications are technically feasible and have a desirable thin client architecture.  Then why isn’t it the industry standard. The answer becomes more apparent as we look at some of the obstacles.

Latency - The first big obstacle was the screen refresh problem. Any time we wanted to change application state required a round trip to the server and a screen refresh. With AJAX this is better, but it does makes development more difficult.

Device Features - One of the main reason that we people use mobile devices is for all of the cool features such as barcode scanning, magnetic stripe readers, cameras, video, messaging, etc.   Not to mention a pretty powerful CPU, persistent storage, and the other features of a portable computer. With web apps, you are generally limited to the functionality of your browser. To some extent you can get around this with ActiveX controls and third party browser extensions such as Motorola’s PocketBrowser, but this is all custom.

Bells and Whistles -Audio is a critical component of Enterprise applications. For some reason Microsoft all but eliminated sound from the mobile web. Without audio cues, alerting users of errors is less effective. Again we can use third party tools for this such as PocketBrowser, but…

Web Standards Support - Here’s another big frustration area that drives developers crazy. It’s only natural that the Microsoft developers made some trade offs when they implemented the mobile browsers, but clearly they weren’t targeting it as an application platform from their choices. Take the single window limitation, i.e. no popup window for displaying error messages or alerts. Or not supporting absolute position.  While these types of limits don’t prevent development, it just makes things more difficult.

Despite these challenges, web applications will become increasingly popular because of the standards based thin client advantage.  And over time, as functionality improves, it will become an increasingly common platform.

However at this point, I still see the web as a limited platform for Enterprise Mobile Applications.  We have found that it works well for smaller applications such as price checkers, or even Gift Registry.  But as the applications increase in scale and functionality, the web environment just isn’t ready for the demands of the enterprise.