Update 14. sept 2010: fixed source code and template files, please use the new files only

Create windows ce cab files which install a complete directory structure onto a device. I created
this small tool, as I needed an easy to use tool to create a pseudo installation cab.

The DLL will unzip a archiv file with all dirs onto a device. To build a new cab use the directory
structure you will find below cabdir.

Create your own install

First cleanup all files below cabdir\source. Then place all files into this directory as they should be
unpacked onto the device. For example for an application called barcodegame, I created the following
structure below source:

source
	+---Program Files
	¦   +---barcodegame
	¦       +---de
	¦       +---en
	+---Temp
	+---windows
		+---Start Menu
			+---Programs

Then let cabbuild.bat create a new archive with all files and then a cab with this packed file. For example
change to the cabdir (cd cabdir) and then launch

Buildcab.bat "BarcodeGame3"

The batch file will patch an inf file needed for cabwiz and zip all files below source. The batch will also
patch the file SetupDll_zip2.ini.tmpl which is used to specify the install location and the zip filename:

;SetupDll_zip2.ini
;directory values have to end with a \

[unzip]
basedir=\
reboot=0
zipfile=!APPNAME!.zip

The unzip directory could also be controlled by the registry but the ini file is looked up first.

If you like to control the unzip by the registry, you have to change the template file “cabtemplate.inf” and use these
settings:

"HKLM\Software\SetupDll_ZIP2"
	registry entries (all REG_SZ):
	unzipbasedir: "\"
	zipfilename: "install.zip"
	doreboot:"0"|"1"

Currently the batch and everything is adjusted to work with the ini template file “SetupDll_zip2.ini.tmpl”.

Dependencies

• The ini and inf template files are patched using the GNU tool sed.
• The zip file is created with 7za
• The cab is created with the MS SDK tool cabwiz.
• The setupdll is written with the help of iniutil.cpp/h and unzip.cpp/h

Coding techiques

• Windows native API.
• CreateWindow from DLL.
• Read ini files on Windows CE.
• Unzip file on Windwos Mobile.
• Update window from thread.

Advantages and Disadvantages

• No national windows support. No shellfolders
• Very easy to use

Download (source and ready to use): DOWNLOAD:SetupDll_Zip - (Hits: 489, size: 2.4 MB)

Updated 14. sept 2010:
DOWNLOAD:SetupDll_Zip 14.sept 2010, evc4 source and DLL - (Hits: 113, size: 172.19 kB)
DOWNLOAD:SetupDll_Zip, CAB dir with templates and sample files - You can use this without source code to build CAB files which use the unzip DLL (incl.). (Hits: 120, size: 3.24 MB)

Bookmark It

How I installed a FTDI serial to USB adapter within ITC CN50 running Windows Mobile 6.1.

Although the USB to Serial adapters with FTDI chips can be installed with drivers from FTDI, these will not work out of the box with WM6.1.

Initial Test with CN50

First I copied the Armv4 driver files ftdi_ser.dll and FTDIPORT.INF to \Windows on the device.

Inserted a Micro USB/B to USB A host connector (Digikey H11576-ND)

Inserted the USB2SER adapter “US232R-10 – Premium USB – RS232 Serial Converter Cable”

The device prompts for the driver name and I typed “ftdi_ser.dll” although it should not do so, as I copied the files previously. See also

Then I started to try to communicate using COM10 (verified with registry). But there was no communication possible. The VCP test application did not list any port to open, so I entered COM10: (or SER0 for patched driver) but without success.

I also tested without success using a Loopback adapter as described here http://www.airborn.com.au/serial/rs232.html:

Using the VCP PC drivers for WinXP the serial adapter worked fine, so the hardwware is not faulty.

I also tested on CN3 (WM6.1) at the dock connector without the micro-USB cable. But this did also not work.

Finally I tested on a WinCE5 device (CK61) and this worked OK. So I compared the registry of WinCE5 and WM6.1 after driver install and adapter connection. I found the following (red) keys are missing on the WM6.1 device and so I added them manually:

REGEDIT4

;[HKEY_LOCAL_MACHINE\Drivers\Active\48]
;"FullName"="SER0"
;"Hnd"=dword:005A1A80
;"Key"="Drivers\\USB\\ClientDrivers\\FTDI_DEVICE"
;"Name"="SER0:"

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\FTDI_DEVICE\FTE06D03]
"ConfigData"=hex(3):01,04,3f,3f,10,27,88,13,c4,09,e2,04,71,02,38,41,9c,80,4e,c0,34,00,1a,00,0d,00,06,40,03,80,00,00,d0,80
"DeviceContext"=dword:00000000
"InitialIndex"=dword:00000000
"LatencyTimer"=dword:00000010

[HKEY_LOCAL_MACHINE\Drivers\USB\ClientDrivers\FTDI_DEVICE]
"ConfigData"=hex(3):01,04,3f,3f,10,27,88,13,c4,09,e2,04,71,02,38,41,9c,80,4e,c0,34,00,1a,00,0d,00,06,40,03,80,00,00,d0,80
"DeviceArrayIndex"=dword:00000000
"Dll"="ftdi_ser.dll"
"Index"=dword:00000000
"InitialIndex"=dword:00000000
"LatencyTimer"=dword:00000010
"Prefix"="SER"
"Version"="1.1.0.2"

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\1027_24577\Default\Default\FTDI_DEVICE]
"DLL"="ftdi_ser.dll"

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\1027_24592\Default\Default\FTDI_DEVICE]
"DLL"="ftdi_ser.dll"

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\1027_24593\Default\Default\FTDI_DEVICE]
"DLL"="ftdi_ser.dll"

[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\Default\255\FTDI_DEVICE]
"DLL"="ftdi_ser.dll"

Using this registry changes and after reinserting the adapter, I was able to communicate using the patched driver, where all COM was replaced with SER. Maybe the original driver will work too, it uses COM10 as port, where the patched driver uses SER0.

VCP test tool

Although the VCP Test application is not the best in regards of error checking (you can enter whatever you want for port and it always makes you think it was able to open the port), I include it here only for completeness.

Original VCP test tool: http://www.ftdichip.com/Projects/CodeExamples/VC++/VCPTest_vcpp.zip

Patched Driver: DOWNLOAD:FTDI (CE ARM) patched driver - Replaced all COM by SER (Hits: 1005, size: 30.77 KB)

Same driver as cab with COM instead of SER: DOWNLOAD:FTDI driver install cab using the standard COM prefix and not SER - (Hits: 257, size: 64.01 kB)

Here is the source code of the modded VCP test tool: DOWNLOAD:Modded VCP test tool - (Hits: 560, size: 105.86 KB)

Additional links

Link to Installation guides: http://www.ftdichip.com/Documents/InstallGuides.htm

The CE installation guide: http://www.ftdichip.com/Documents/InstallGuides/Windows_CE_Installation_Guide.pdf

Update 23. march 2011: Anyone looking for a two port solution? Try the drivers provided by Handera (SD50).

Bookmark It

iHook3

This application provides the user with key shortcuts to applications. All keystrokes or hot keys are transparent, this means, they are not lost and will reach the application just running in foreground. iHook2 can be started by placing a link to the exe in \Windows\Startup, by a batch file or some other AutoStart feature of the device OS.

iHook3 Version 1.3

This versions uses the registry to read the assigned keys and applications. Additionally the app is now safe and will only load once. The only argument supported is “-writereg” to write a default registry (see below).

Sample registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Intermec\iHook2]
"arg4"="iRun2.exe"
"exe4"="\\windows\\iKill2.exe"
"key4"=hex:\
      1b
"arg3"=""
"exe3"="explorer.exe"
"key3"=hex:\
      71
"arg2"=""
"exe2"="\\windows\\iSIP2.exe"
"key2"=hex:\
      74
"arg1"="-toggle"
"exe1"="\\windows\\LockTaskBar.exe"
"key1"=hex:\
      73
"arg0"=""
"exe0"="\\windows\\iRotateCN2.exe"
"key0"=hex:\
      72

New in version iHook3 (version 2.0)
recognizes CK60
adds Notification icon in taskbar

New in iHook3 (version 3.1)
recognizes CN3
supports consuming/forwarding switch for hot-keys. Use “ForwardKey” registry binary value 0 to disable forwarding hot-keys, 1 to enable forwarding hotkeys.
This new option is usefull if you have a phone device and hook the number keys. In this case disable forwarding with 0, otherwise the phone app will come in front for the number keys.

REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Intermec\iHook3]
"arg0"=""
"exe0"="\\Windows\\iRotate.exe"
"key0"=hex:\
      26
"ForwardKey"=hex:\
      00

The main functionality is in here:
#pragma data_seg(".HOOKDATA")									//	Shared data (memory) among all instances.
	HHOOK g_hInstalledLLKBDhook = NULL;						// Handle to low-level keyboard hook
	//HWND hWnd	= NULL;											// If in a DLL, handle to app window receiving WM_USER+n message
#pragma data_seg()

#pragma comment(linker, "/SECTION:.HOOKDATA,RWS")		//linker directive

// The command below tells the OS that this EXE has an export function so we can use the global hook without a DLL
__declspec(dllexport) LRESULT CALLBACK g_LLKeyboardHookCallback(
   int nCode,      // The hook code
   WPARAM wParam,  // The window message (WM_KEYUP, WM_KEYDOWN, etc.)
   LPARAM lParam   // A pointer to a struct with information about the pressed key
)
{
	/*	typedef struct {
	    DWORD vkCode;
	    DWORD scanCode;
	    DWORD flags;
	    DWORD time;
	    ULONG_PTR dwExtraInfo;
	} KBDLLHOOKSTRUCT, *PKBDLLHOOKSTRUCT;*/

	// Get out of hooks ASAP; no modal dialogs or CPU-intensive processes!
	// UI code really should be elsewhere, but this is just a test/prototype app
	// In my limited testing, HC_ACTION is the only value nCode is ever set to in CE
	static int iActOn = HC_ACTION;
	PROCESS_INFORMATION pi;
	int i;
	bool processed_key=false;
	if (nCode == iActOn)
	{
		PKBDLLHOOKSTRUCT pkbhData = (PKBDLLHOOKSTRUCT)lParam;
		if ( (wParam == WM_KEYUP) && (processed_key==false) )
		{
			for (i=0; i<=lastKey; i++)
			{
				if (pkbhData->vkCode == kMap[i].keyCode)
				{

Below is the download of the source code as done with embedded visual c 4.
DOWNLOAD:iHook3 Embedded Visual C++ 4 source code -  (Hits: 340, size: 90.75 KB)

Bookmark It

Do you think windows mobile is the right choice for a commercial used handheld?

Having windows mobile OS on a barcode scanner data retrieval system has a lots of disadvantages. There may be unwanted popups and it is hard to lock the user in the application. Windows CE is shrinked down, but no one will miss outlook and other PIM of windows mobile on a data retrieval system.

When I am talking about industrial/commercial used handhelds, I am talking about such devices.

Windows Mobile offers a rich set of functions, but from a support and developing view, it is harder to lock down the user in the application they have to use to enter data. There is an strange function key mapping and every time a popup may appear, where the user can get out of the main app back to the OS.

Windows CE is much easier to support and it is easier to lock down the user. It also has a smaller footprint and the application has more memory: no outlook and other mostly unused apps in the background. For browser type applications, the browser is more compatible to desktop browser than the Mobile Internet Explorer.

What do you think?

Some companies for ruggedized handhelds offer both OS types for there devices, some not.

Please vote at right sidebar.

Bookmark It