DCConnect Client User's Guide (formerly 752x Emulator for DOS)

DCConnect Client User's Guide
-----------------------------
This document describe the use of the IBM DCConnect Client product, including
hardware and software requirements, all configuration options available for
this product as well as other required products such as the operating system
and the TCP/IP stack, and including detailed instructions about how to run
this product on each of the support models of hardware.

Prior to March 2000, this product was known as the 752x Emulator for DOS.

The name was changed to remove the confusion that has existed because of the
term 'emulator' and because the product now runs on Windows 95/98/Me/NT/2000/XP/7/Server
as well as Windows CE.

For much of this document, this product will be referred to as the 'Client'.
However, in order for existing installations not to have to change, the .INI
file from which configuration parameters are read will continue to be called
EMULATOR.INI. For the same reason, we'll continue to use EM.BAT as the name
of the batch file used to start the executable and we'll continue to use
ETSPB.EXE and ETSPT.EXE as the executable names.

Table of Contents
-----------------
Notices
Trademarks
Overview

Using the DCConnect Client with non-IBM Data Collection Terminals
Hardware Requirements
Software Requirements

Installation Instructions for the DCConnect Client
Installing the DCConnect Client on Windows 95/98/Me/NT/2000/XP/7/Server
Product Files
Installation Hints for the FTP Software TCP/IP Stack
Authentication Key and Serial Number Entries in the .INI file

Common Command Line Parameters for the Client
Starting the Serial-Attached Flavor of the Client
Starting the TCP/IP-Attached Flavor of the Client

Menus
Main Menu
Diagnostics Menu
Menu Short Cut Keys

Configuration using EMULATOR.INI and MASTER.INI
Keyword: ABORT_ONKEY_ON_RS232_INPUT
Keyword: ABORT_READ_ON_RS232_INPUT
Keyword: ADDRESS
Keyword: ALL_SCAN_DATA_UPPER_CASE
Keyword: ALLOW_LOWER_CASE
Keyword: AUTO_SCROLL_ROW
Keyword: BAUD_RATE
Keyword: COLOR_ATTRIBUTES
Keyword: COM_PORT
Keyword: COMPILE_ONLY
Keyword: DATE_SEPARATOR
Keyword: DEVICE
Keyword: DONT_CHANGE_SCREEN_SIZE
Keyword: ENABLE_MENU_SHORTCUTS
Keyword: FILE_PAGING
Keyword: FULL_SCREEN
Keyword: HIDE_MENU_BAR
Keyword: IDLE_DELAY_MIN_AND_MAX
Keyword: IGNORE_ARROW_KEYS
Keyword: IGNORE_KEY
Keyword: IGNORE_UNDERLINE
Keyword: KEY_CLICK
Keyword: KEYPAD_FONT_SIZE
Keyword: KEYPAD_KEY
Keyword: KEYPAD_NUM_KEYS
Keyword: KEYPAD_NUM_KEY_COLS
Keyword: KEYPAD_NUM_KEY_ROWS
Keyword: KEYPAD_POSITION
Keyword: LOCK_IN_MEMORY
Keyword: LOG_COMPILE_WARNINGS
Keyword: MAPPED_KEY
Keyword: MAX_TRANSACTIONS
Keyword: MENU_ITEM
Keyword: MENU_KEY
Keyword: MENU_PASSWORD
Keyword: MODEM_DIAL_CHAR
Keyword: MODEM_DIAL_STRING
Keyword: MODEM_RETRIES
Keyword: MODEM_SETUP_STRING
Keyword: MSG_BUFFER_FULL
Keyword: MSG_WAITING_FOR_FILES
Keyword: NUM_COLUMNS / NUM_COLS
Keyword: NUM_PF_STRINGS
Keyword: NUM_ROWS
Keyword: NUM_TOUCH_STRINGS
Keyword: PF_AUTO_ENTER
Keyword: PF_MAPPING
Keyword: POWER_OFF_TIMER
Keyword: RESEND_TIMER
Keyword: ROW_PIXEL_SPACING
Keyword: SCAN_LOOK_FOR_AIM_CODE
Keyword: SCAN_SENTINEL_CHARS
Keyword: SCAN_STRIP_COUNT_FRONT
Keyword: SCRIPT_NAME
Keyword: SELECT_FONT
Keyword: SHOW_IDLE_TIME
Keyword: STATUS_ROW
Keyword: TCPIP_ENCRYPT
Keyword: TCPIP_HOST
Keyword: TCPIP_PORT
Keyword: TERM_NAME
Keyword: TERM_SUB_MODEL
Keyword: TIME_SEPARATOR
Keyword: TIMEZONE_ADJUST
Keyword: TOGGLE_BACKLIGHT_CHAR
Keyword: TSR_INTERRUPT
Keyword: TXTN_BUFFER_WARNING_COUNT
Keyword: TXTN_BUFFER_WARNING_TIMER
Keyword: USE_ROOT_FOR_DOWNLOAD_FILES/A>
Keyword: USE_RS232_FOR_SCANNER
Keyword: USE_TSR_FOR_KEYBOARD
Keyword: USE_TSR_FOR_RS232
Keyword: USE_TSR_FOR_SCANNER
Keyword: UV_POOL_SIZE
Keyword: VOLUME

Keyboard Usage
Android Keypad

Custom Idle Screen

Communications Protocol, Internal File Formats and Other Technical Information

CFR Headers, Libraries and Samples
Compiling and Linking a CFR
Using the Environment Variable CFRTOOLS and Others When Building CFRs
Using IBM C/2 Version 1.10 to Build CFRs for DOS-based Terminals
Using Borland Turbo C++ 3.0 for DOS to Build CFRs for DOS-based Terminals
Using Microsoft Visual C++ Version 6.0 to Build CFRs for Windows 95/98/Me/NT/2000/XP/7/Server
Using Microsoft eMbedded Visual Toolkits to Build CFRs for Windows CE Devices

Latest Fixes and Enhancements

Using the DCConnect Client on ...
Intelligent Instrumentation LanPoint/FactoryPoint/TimePoint Terminals
Intelligent Instrumentation LanPoint Pro Terminals
Intermec 6400 Terminals
Intermec 6540 (or MaxiLAN DX) Terminals
Intermec Trakker Antares Line of Terminals
Intermec Janus 2010/2020/2050 Terminals
LXE MX1, MX2, VX1 Terminals
PSC/Percon Falcon 345 Terminals
Selected Symbol Spectrum 24 Terminals
Teklogix 7035 Terminals
Telxon PTC960SL/X, PTC860IM and PTC870IM Terminals
Windows 95/98/Me/NT/2000/XP/7/Server
Windows CE Devices

Notices
-------
References in this document to IBM products, programs, or services do not
imply that IBM intends to make these available in all countries in which
IBM operates. Any reference to an IBM product, program or service is not
intended to state or imply that only IBM's product, program, or service
may be used. Any functionally equivalent product, program, or service that
does not infringe any of IBM's intellectual property rights may be used
instead of the IBM product, program or service. Evaluation and verification
of operation in conjunction with other products, except those expressly
designated by IBM, is the user's responsibility.

IBM may have patents or pending patent applications covering subject matter
in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to
the IBM Director of Commercial Relations, IBM Corporation, Purchase, NY
10577.

Trademarks and Service Marks
----------------------------
The following terms are trademarks of the IBM Corporation in the United
States or other countries or both:

IBM

Other company, product, and service names may be trademarks or service
marks of others.

Overview
--------
The DCConnect Client allows a DOS or Windows device such as a PC to appear to
be a Client Data Collection Terminal to the DCConnect Server. The Client
software makes the device on which it is running function in much the same
way that an IBM 7524 Data Collection terminal functions, accepting the download
of the same transaction program files used for real 7524s and responding to
commands and requests from the DCConnect Server, just as a 7524 does.

With this product, customers who already have transaction programs written
for the 7524 can use them on device supported by the DCConnect Client -
including selected devices from Intermec, Symbol, Telxon as well as devices
running Windows NT/95/98 and Windows CE. The Client can even run in a
DOS full-screen session of OS/2.

When configuring the DCConnect Server, any device that is running the DCConnect
Client should be set up using the 7524 terminal type. This is because the Client
makes a device work just like a 7524 terminal; DCConnect does not know the
difference.

The DCConnect Client product includes modules for several different methods of
attachment to a data collection system such as DCConnect:

- Attachment via the serial port. If using this method the device running the
Client would be configured as a 7524 terminal attached to a serial line
or ARTIC line in the DCConnect configuration.

- Attachment via any TCP/IP adapter supported by IBM DOS TCP/IP Support
Version 2.11. If using this method the device running the Client would
be configured as a 7524 terminal attached to a TCP/IP 75XX line.

- Attachment via any TCP/IP adapter supported by FTP Software's PC/TCP
Network Kernel for DOS/Windows version 3.2 or later. If using this method
the device running the Client would be configured as a 7524 terminal
attached to a TCP/IP 75XX line.

- Attachment via any TCP/IP adapter supported by Novell's LAN Workplace for
DOS. If using this method the device running the Client would be
configured as a 7524 terminal attached to a TCP/IP 75XX line.

- Attachment via any TCP/IP adapter supported by the native networking
support of Windows 95/98/Me/NT/2000/XP/7/Server and Windows CE.

- For Antares terminals, attaching using the TCP/IP Connectivity Software (not
UDP plus).

The product provides a different executable for each of these attachment
methods.

Using the Client with non-IBM Data Collection Terminals
-------------------------------------------------------
In addition to being able to run on a standard DOS-based PC and in the Windows
NT/95/98 environments, the Client has been written to support many different
third party data collection terminals. At this time, the following terminals
are supported:
Max
Data Collection Terminal Screen Style & Connectivity
------------------------ ------ --------------------
- Group Mobile MA1000 (Windows CE) *** #SVGA Tablet PC, RF

- HandHeld Products 7400 (Windows CE) *** #QVGA Portable RF - flashlight style

- Intelligent Instrumentation LanPoint 2x40 Stationary Ethernet or serial
- Intelligent Instrumentation FactoryPoint 2x40 Stationary Ethernet or serial
- Intelligent Instrumentation TimePoint 2x40 Stationary Ethernet or serial
- Intelligent Instrumentation LanPoint Pro 4x40 Stationary Ethernet or serial, RF optional

- Intelligent Instrumentation LanPoint CE #Half VGA Stationary/Vehicle Mount Ethernet/serial/RF

- Intermec 6400 *15x20 Portable RF/batch serial - flashlight

- Intermec 6540 4x40 Wired ethernet or serial, RF optional
- Intermec MaxiLAN DX 200S/200H (former name of Intermec 6540)

- Intermec Janus 2010 16x20 Portable RF/batch serial - flashlight
- Intermec Janus 2020 16x20 Portable RF/batch serial - gun style
- Intermec Janus 2050 20x40 Vehicle mount RF

- Intermec Trakker Antares 2410 16x20 Small portable batch serial - flashlight
- Intermec Trakker Antares 2415 16x20 Small portable RF - flashlight
- Intermec Trakker Antares 2420 16x20 Large portable batch serial - flashlight
- Intermec Trakker Antares 2425 16x20 Large portable RF - flashlight
- Intermec Trakker Antares 2435 +16x20 Large portable RF - flashlight
- Intermec Trakker Antares 2455 25x40 Vehicle mount RF
- Intermec Trakker Antares 2460 2x16 Stationary serial
- Intermec Trakker Antares 2461 2x16 Stationary Ethernet
- Intermec Trakker Antares 2480 4x40 Stationary Ethernet or serial
- Intermec Trakker Antares 2481 24x40 Stationary Ethernet or serial
- Intermec Trakker Antares 2485 4x40 Stationary RF
- Intermec Trakker Antares 2486 24x40 Stationary RF

- Intermec 600 (Windows CE) #QVGA Palm style: wired ethernet, serial (needs dock to talk)
- Intermec 7xx (Windows CE, Pocket PC) #QVGA Palm style: wired ethernet, serial, RF (needs dock unless RF)
- Intermec 5020 (Windows CE) #QVGA Portable RF - flashlight
- Intermec 6651 (Windows CE, Handheld PC) #VGA Pen tablet: serial or RF
- Intermec CK3 (Windows Mobile) *** #QVGA Portable RF - flashlight
- Intermec CK30 (Windows CE) #160x160p Portable RF - flashlight (p = pixels)
- Intermec CK31 (Windows CE) #QVGA Portable RF - flashlight
- Intermec CK61 (Win CE, Win Mobile) *** #QVGA Portable RF - flashlight/gun
- Intermec CN30 (Win CE, Win Mobile) *** #QVGA Portable RF - flashlight/gun
- Intermec CV30 (Win CE, Win Mobile) *** #VGA Fixed mount RF
- Intermec CV60 (Windows CE) #SVGA Vehicle mount RF

- LXE/Honeywell MX1 *** 16x20 Portable RF - flashlight style
- LXE/Honeywell MX2 *** (Equivalent to PSC/Percon Falcon 345)
- LXE/Honeywell MX3Plus (Win CE) *** #1/2 VGA Mini Vehicle mount RF
- LXE/Honeywell MX5 (Win CE) *** #QVGA Portable RF - flashlight/gun
- LXE/Honeywell MX7 Tecton (WinCE/Mob) *** #QVGA Portable RF - flashlight/gun
- LXE/Honeywell VX1 *** 20x40 Vehicle mount RF
- LXE/Honeywell VX7 (Win CE) *** #SVGA Vehicle mount RF

- PSC/Percon Falcon 345 *** 16x20 Portable RF - gun style

- Symbol FMT1020 (Equivalent to Intelligent Instrumentation LanPoint)
- Symbol FMT1040 (Equivalent to Intelligent Instrumentation FactoryPoint)
- Symbol FMT1060 (Equivalent to Intelligent Instrumentation TimePoint)
- Symbol FMT3000 (Equivalent to Intelligent Instrumentation LanPoint Pro)

- Symbol WSS1040/1060 8x20 Wearable RF
- Symbol PDT3140 8x20 Portable RF - flashlight style
- Symbol LRT3840 8x20 Portable RF - gun style
- Symbol VRC3940 8x20 Vehicle mount RF
- Symbol PDT6840 16x20 Portable RF - flashlight style
- Symbol VRC6940 8x20 Vehicle mount RF

- Symbol MC30xx (Win CE) *** #QVGA Portable RF - flashlight/gun style
- Symbol WT4070/90 (Win CE 5.0) *** #QVGA Wearable RF
- Symbol VC509x (Win CE 5.0) *** #SVGA Vehicle mount RF (Half SVGA also available)
- Symbol MC709x (Win CE, Win Mobile) *** #QVGA Palm style, RF
- Symbol VRC7946 (Win CE 5.0) *** #Half VGA Vehicle mount RF
- Symbol PDT81xx (Win CE, Pocket PC) #QVGA Portable RF - flashlight style
- Symbol PPT88xx (Win CE) *** #QVGA Palm style, RF
- Symbol MC906x (Win CE, Win Mobile) #QVGA Portable RF - flashlight style
- Symbol MC909x (Win CE, Win Mobile) *** #QVGA Portable RF - flashlight style
- Symbol MC91xx (Win CE, Win Mobile) *** #VGA/QVGA Portable RF - flashlight style

- Teklogix 7035 *** ##18x20 Portable RF - gun style

- Telxon 960SL/960X 16x21 Portable RF - gun style
- Telxon 860IM 8x40 Vehicle mount RF
- Telxon 870IM 20x40 Vehicle mount RF

- IBM 2483 = Telxon 960X (no longer logoed by IBM)
- IBM 2493 = Telxon 960SL (no longer logoed by IBM)
- IBM 2484 = Telxon 860IM (no longer logoed by IBM)

* Although the Intermec 6400 actually has 16 rows, the bottom row is used for
displaying annunciators and these overwrite any text that the DCConnect
Client might write to that row.

+ The Intermec Antares 243x models default to a font which accommodates 16 rows
by 20 columns. However the font can be changed to allow up to 21 rows by
31 columns. (The Client would only use 20 of those rows).

# For all Windows CE devices you can choose any dimension up to 20 rows and
up to 40 columns. The operating system will pick a font that best matches
the specified dimensions. Of course if you pick a large number of rows
and columns and the physical screen is very small, it may be hard to read
the characters. If a p follows the dimensions (e.g. 160x160p for the
Intermec CK30) then the measurement is in pixels.

## The Teklogix 7035 has a number of different fonts to choose from ranging
from 10x20 to 18x32. 16x20 which is used on many other devices is not
available on the 7035. The closest is 18x20.

*** Devices marked with 3 asterisks are ones that one or more customers are
successfully running the DCConnect Client on and/or IBM has successfully
tested; however, our documentation contains limited or no information
about how to load and configure them.

Specific sections which describe configuration requirements and hints for
each of these supported terminals will follow the sections that apply to
all terminals.

Note: IBM also supports the legacy Norand/Intermec RF terminals in the 1100,
1700 and 5900 series. These were formerly logoed by IBM as the IBM 7524
series of terminals. However, these terminals do not run the Client
directly. They can be ordered from Norand/Intermec with a special
Extended Terminal Services (ETS) flash load that provides similar
function to what the DCConnect Client provides. Please see our
website for more information about the supported models:

http://www.ibm.com/software/data/dcconnect

From there, choose 'Product Downloads' and then '7524 ETS Flash Loads
and CFR Samples, Programming Tools'.

Hardware Requirements
---------------------
If attaching via the serial port, at least one serial port that appears to
the operating system as a COMx device. For example, this may be a native
PC RS-232 port or an add-on RS422/485 adapter.

If attaching using a TCP/IP adapter consult your DOS TCP/IP product
documentation (IBM or FTP Software) or the Windows Networking documentation
for the supported hardware.

If a non-IBM Data Collection terminal is being used, there may be other
device-specific hardware requirements - such as a PCMCIA memory card.

Please refer to the following sections for more information relevant to each
supported terminal:

Hardware and Software Requirements for 6400 Terminals
Hardware and Software Requirements for 6540 Terminals
Hardware and Software Requirements for Antares Terminals
Hardware and Software Requirements for Janus Terminals
Hardware and Software Requirements for LanPoint/FactoryPoint/TimePoint Terminals
Hardware and Software Requirements for LanPoint Pro Terminals
Hardware and Software Requirements for Spectrum 24 Terminals
Hardware and Software Requirements for Telxon Terminals
Hardware and Software Requirements for Windows 95/98/Me/NT/2000/XP/7/Server Terminals
Hardware and Software Requirements for Windows CE Devices

Software Requirements
---------------------
One of the following:
- IBM DOS version 5.0 or later.
- Windows NT 4.0 or later
- Windows 95
- Windows 98
- Windows CE 2.0 or later

If attaching via the serial port, no additional software support is needed

If attaching using a TCP/IP adapter, one of the following TCP/IP support
products (stacks) is required (unless otherwise noted in the specific device
descriptions below):

- IBM DOS TCP/IP Support version 2.11 (no longer orderable)
- FTP Software/ PC/TCP Network Kernel for DOS
NetManage At this writing, FTP Software's product number was K-210-41
which is version 4.1 of the product. Note: FTP Software is
now a subsidiary of NetManage.
- Novell LAN Workplace for DOS
- Antares For Antares terminals, you must order the TCP/IP Connectivity
Software option.
- Windows For Windows NT/95/98/CE the networking support provided by
the operating system is all that is required

Separate Client executables are provided for each attachment method.

If a non-IBM Data Collection terminal is being used, there may be other
device-specific software requirements. Or the required TCP/IP stack may
already be provided by the hardware manufacturer.

Please refer to the following sections for more information relevant to each
supported terminal:

Installation Instructions for the DCConnect Client
--------------------------------------------------
With release 2.00 of the DCConnect Client, an installation procedure has been
set up to install the DCConnect Client files to a Windows NT/2000/XP/7/Server system.
If the DCConnect Server is already installed on that system, the files will
be installed to the DCCLIENT subdirectory under the directory in which the
DCConnect Server was installed. For example, if the DCConnect Server was
installed into the C:\DCCONN directory, then the DCConnect Client files will
be installed to the C:\DCCONN\DCCLIENT directory.

If the DCConnect Server is not installed, the installation of the Client will
prompt you for the directory into which the files should be installed.

Note: Unlike previous versions of the DCConnect Client CD/diskettes, the files
that are part of the DCConnect Client are compressed on the version 2.0
(and later) CD. Therefore you must run the installation in order to get
access to the product files.

Once the files are installed, the ones that you will need to use will depend
on which device(s) the DCConnect Client will run on. Please see the
references at the end of the previous section to get detailed instructions
about how each device is to be set up and which DCConnect Client product
files will be required. Some devices require special utility programs and
additional configuration may be required.

Installing the DCConnect Client on Windows 95/98/Me/NT/2000/XP/7/Server
-----------------------------------------------------------------------
The installation of version 2.00 (and later) of the DCConnect Client also
gives you the option to set up a Windows version of Client as a terminal that
can be part of the DCConnect Server configuration. You can use this option to
install the Windows version of the Client on one or more PCs. If you choose
this option, you will be prompted for the 'Server IP' and the 'Client Port'.

For the 'Server IP', enter the IP address of the DCConnect Server. If the
DCConnect Server is running on the same machine as the Client, you can use
the loopback address 127.0.0.1. By default the DCConnect Server uses port
number 7500 to communicate with terminals. If your DCConnect Server is
configured to use a different TCP/IP Port Number (page 1 of the Options tab
of the Node Settings notebook), then add a comma after the IP address
immediately followed by the TCP/IP Port Number that the DCConnect Server is
using.

For the 'Client Port' number specify the TCP/IP Port number that the DCConnect
Client will use to communicate with the DCConnect Server. The Port Number
for the Client must be different from the Server Port number if both are
running on the same machine. Also, if you will be running more than one
copy of the Client on the same machine, each must have a unique port number.
After you decide which port number to use for the Client, make sure the
DCConnect Server configuration for this terminal specifies that same port
number. This is done on page 1 of the General tab in the Terminal Settings
notebook. After the IP address, add a comma and then the port number value.

Once the Windows version of the Client is installed, a shortcut will be
created, which can be accessed from the Start button as follows: Start ->
Programs -> IBM Data Collection -> DC Connect Client (local). If the font
that is used to show the Client is not appropriate, it can be changed
using the Font tab of the Properties notebook for this window (click mouse
button two once on the upper left corner).

Product Files
-------------
The DCConnect Client is made up of many different 'flavors' of executable
files so that it can be run on a variety of different devices. Some of
those devices also require additional configuration files or supporting
tools for loading, configuring or running the Client.

All flavors of executables require the license file to be installed on the
device.

Also installed part of the product are the files necessary for building CFRs for use
by the device running this product. For more information about these
files, refer to the section CFR Headers and Libraries.

The DCConnect Client product files that are installed to the \DCCONN\DCCLIENT
directory are:

ETSCHECK.LIC - License file; it must be in the current directory
in order for the Client to run on any device. For
Windows CE devices it must be in the directory
specified by the 'path' value for the registry key:

HKEY_LOCAL_MACHINE\Software\IBM\DCConnect Client

LOGFILE.LOG - Empty transaction logfile. Needed when building
Windows CE .CAB files - along with LOGFILE.NDX.

LOGFILE.NDX - Empty transaction index file. Needed when building
Windows CE .CAB files - along with LOGFILE.LOG.

DOS-based Device-Specific files
-------------------------------
6400\6400BC.CFG - Input file for 6400 Bar code configuration
6400\6400BC.EXE - Bar code Configuration program for 6400 terminals
6400\6400_TSR.EXE - TSR needed for the Client to control the scanner.
6400\6400DISP.EXE - Tool to configure the 6400 display.

ANTARES\ETSPB.EXE - DOS flavor of serial Client that runs only on the
Intermec Antares line of terminals.
ANTARES\ETSPT.EXE - DOS, TCP/IP-attached flavor of the Client that
runs only on the Intermec Antares line of terminals.
ANTARES\FLASHLDR.BIN - File needed by LOADER.EXE to load terminals
ANTARES\LISTFILE.DOS - Used with DOWNLOAD.BAT to load DOS files to Antares
ANTARES\LOADER.EXE - DOS-based file load utility from Intermec
ANTARES\LOAD1.BAT - Batch file for loading a single file to the terminal
ANTARES\LOAD2.BAT - Batch file for loading two files to the terminal
ANTARES\SETUPANT.EXE - Utility program for changing Antares configuration
ANTARES\T24FCOPY.EXE - Windows-based file load utility provided by Intermec.
It can be used to upload or download files to Antares
terminals.
ANTARES\T24FCOPY.HLP - Help file for T24FCOPY.EXE
ANTARES\USER.BAT - Called by AUTOEXEC.BAT to start Client automatically

ANTARES\SAMPLE\DOWNLOAD.BAT - Sample download batch file to use with LOADER.EXE
ANTARES\SAMPLE\EM.BAT - Sample EM.BAT for Antares
ANTARES\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Antares
ANTARES\SAMPLE\S.BAT - Easier-to-type sample batch file for calling SETUPANT.EXE
ANTARES\SAMPLE\SETUPANT.INI - Sample input file for SETUPANT.EXE
ANTARES\SAMPLE\UPGRADE.BAT - Alternate UPGRADE.BAT used when loading Intermec flash
to Antares terminals.

FALCON\FALC_TSR.EXE - TSR needed by the Client in order to distinguish between
keyboard and scanner input on the PSC/Percon Falcon and its
twin the LXE MX2.

LANPTPRO\PREPOST.EXE - Utility for configuring the bar code pre/postamble on the
Intelligent Instrumentation LanPoint Pro (aka Symbol FMT3000).

SPEC24\CFG3000.EXE - Configuration utility for Symbol Spectrum 24 terminals. It
modifies INIT.EXE.
SPEC24\ETSPT.EXE - DOS, TCP/IP-attached flavor of Client used by the
Symbol Spectrum 24 terminals. It uses Novell's LAN
Workplace for DOS. The terminals are shipped by
Symbol with the Novell software installed.
SPEC24\FLSHBLD.ZIP - Zip file containing the set of files used when flashing
the Symbol Spectrum 24 terminal.
SPEC24\S24_TSR.EXE - Required for use of the scanner and Serial port on Symbol
Spectrum 24 terminals

TELXON\HHB.EXE - Flavor of Telxon's HandHeld Bridge that runs on the PC
TELXON\HHB.TXT - Documentation for Telxon's HHB.EXE
TELXON\HHBR.EXE - Flavor of Telxon's HandHeld Bridge that runs on the terminal
TELXON\HHBR.TXT - Documentation for Telxon's HHBR.EXE
TELXON\TELXONBC.EXE - Bar code Configuration program for Telxon terminals
TELXON\TELXONBC.CFG - Input file for Telxon Bar code configuration
TELXON\T870_TSR.EXE - TELX_TSR.EXE for use on PTC870; it is required for
any scanner use on this terminal
TELXON\TELX_TSR.EXE - Optional TSR for Telxon 960SL/X, 860IM; provides
RS-232 support and enhanced scanner support
TELXON\WANDTSR.EXE - TSR required for scanner support on Telxon 960SL/X, 860IM

Two DOS Flavors of the Client that Communicate to DCConnect Serially
--------------------------------------------------------------------
SERIAL\ETSPB.EXE - Serial-attached flavor of the Client for use on
DOS devices.

SERIAL\NLS\ETSPB.EXE - DOS flavor of serial Client built with different
video routines that use whatever code page is
set in DOS for displaying characters. Does not
work on all devices (but does work on Janus 2050).

Various DOS flavors of the Client for different TCP/IP stacks
-------------------------------------------------------------
TCP_FTP\ETSPT.EXE - DOS, TCP/IP-attached flavor of the Client requiring
FTP Software's PC/TCP Network Kernel for DOS.

TCP_FTP\NLS\ETSPT.EXE - DOS flavor of TCP/IP Client for FTP stack built
with different video routines that use whatever
code page is set in DOS for displaying characters.
Does not work on all devices (but does on Janus 2050).

TCP_IBM\ETSPT.EXE - DOS, TCP/IP-attached flavor of the Client requiring
IBM DOS TCP/IP Support. Also runs in a full screen
DOS session of OS/2.

TCP_NOV\ETSPT.EXE - DOS, TCP/IP-attached flavor of Client requiring
Novell's LAN Workplace for DOS.

TCP_VSL\ETSPT.EXE - DOS, TCP/IP-attached flavor of Client that requires
the Virtual Socket Library from JSB Software.

Client Files for Use on 32/64-bit Windows Platforms (95/98/Me/NT/2000/XP/7/Server)
----------------------------------------------------------------------------------
WIN32\ETSPT.EXE - Windows flavor of Client. Uses networking support that
is provided by the operating system. This is the stub
executable that is run to start the Client; the majority
of the program is in WIN32\ETSPT.DLL.

WIN32\ETSPT.DLL - Windows flavor of Client functionality; requires
WIN32\ETSPT.EXE to start it.

WIN32\ETSSCRPT.DLL - Windows flavor of Client DLL for support of text script
file processing.

WIN32\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for the 32-bit Windows flavor of
the Client.

NMWIN32.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Windows platforms.
Also used with the various Windows makefiles that
are part of the CFR packages.

Client Files for Use on Windows CE Devices
------------------------------------------
MAKECAB.BAT - Used to build Windows CE .CAB files from .INF files
DCCLIENT.INF - Sample .INF file used to create DCConnect Client .CAB
files for the various flavors of Windows CE devices.

CECONFIG.VB - Microsoft eMbedded Visual Basic executable for the IBM
CE Config Tool. This tool uses an .INI file to set up
registry values, create files, and perform file and
directory operations for the purpose of automating
the configuring a Windows CE device. Provides the
ability to prompt the user for certain values, including
the ability to provide a list of valid choices, while
automating the setting of any values that would not
change.
CECONFIG.INI - Sample .INI file used by the IBM CE Config Tool.
Includes sample commands for setting registry keys
and creating a file.
GETREG.VB - Microsoft eMbedded Visual Basic executable for the
Get Registry tool.

ETSUSER.C - Sample source for building Windows CE DLL needed
on some devices to run the Client in 'full-screen'
mode. Also can be used to add customer menu items
to the Client's pull-down menus.
ETSUSER.DEF - Sample module definition file to go with ETSUSER.C
ETSUSER.VCN - Microsoft eMbedded Visual Toolkit Version 3.0 make file
used to build various flavors of ETSUSER.DLL from the
source files ETSUSER.C and ETSUSER.DEF.
ETSUSER.VCP - Microsoft eMbedded Visual Toolkit Version 3.0 project file
used to build various flavors of ETSUSER.DLL from the
source files ETSUSER.C and ETSUSER.DEF.
ETSUSER.VCW - Make file generated by Microsoft eMbedded Visual Toolkit
Version 3.0; used to build various flavors of ETSUSER.DLL
from the source files ETSUSER.C and ETSUSER.DEF.

NMCK30.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Intermec CK30.
Also used with the various Windows CE makefiles that
are part of the CFR packages.
NMCV60.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Intermec CV60.
Also used with the various Windows CE makefiles that
are part of the CFR packages.
NMI5020.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Intermec 5020 (running
Windows CE 3.0 or later). Also used with the various
Windows CE makefiles that are part of the CFR packages.
NMI600.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Intermec 600.
Also used with the various Windows CE makefiles that
are part of the CFR packages.
NMI6651.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Intermec 6651.
Also used with the various Windows CE makefiles that
are part of the CFR packages.
NMI700.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Intermec 700.
Also used with the various Windows CE makefiles that
are part of the CFR packages.
NMS90XX.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Symbol 90xx terminals.
Also used with the various Windows CE makefiles that
are part of the CFR packages. Can also be used for
91xx terminals.
NMLPTCE.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the Intelligent
Instrumentation LanPoint CE. Also used with the
various Windows CE makefiles that are part of the
CFR packages.
NMX86EM.BAT - Batch file to use with the makefile ETSUSER.VCN in
order to build ETSUSER.DLL for the MS Pocket PC
Emulation environment. Also used with the
various Windows CE makefiles that are part of the
CFR packages.

Windows CE Device with ARM Processor - but not Pocket PC API Available
----------------------------------------------------------------------
ARMNOPPC\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for use
on devices with an Intel StrongARM processor or
compatible and with Windows CE 3.0 or compatible
later version but which are not Pocket PC devices. Uses
networking support that is provided by the operating
system. This is the stub executable that is run to
start the Client; the majority of the program is in
ARMNOPPC\ETSPT.DLL.
ARMNOPPC\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for use
on devices with an Intel StrongARM processor or
compatible and with Windows CE 3.0 or compatible later
version but which are not Pocket PC devices; requires
ARMNOPPC\ETSPT.EXE to start it. This flavor of
ETSPT.DLL is similar to the IMEC700\ETSPT.DLL
except that it does not require the Pocket PC library
AGYSHELL.DLL.
ARMNOPPC\ETSSCRPT.DLL - Intel StrongARM Client DLL containing text file processing.

Interemc CK30 (XScale processor, Windows CE)
--------------------------------------------
CK30\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for the
Intermec CK30 terminal. Uses networking support that is
provided by the operating system. This is the stub
executable that is run to start the Client; the
majority of the program is in CK30\ETSPT.DLL.
CK30\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Intermec CK30 terminal; requires CK30\ETSPT.EXE
to start it.
CK30\ETSSCRPT.DLL - Intermec CK30 Client DLL containing text file processing.
CK30\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Intermec CK30
CK30\SAMPLE\CK30.CAB - Sample cabinet file for installing the Client onto
the Intermec CK30. Built using MAKECAB.BAT and
CK30\SAMPLE\CK30.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI, ETSCHECK.LIC, and ETSSCRPT.DLL.
CK30\SAMPLE\CK30.INF - Sample .INF file used with MAKECAB.BAT for creating
CK30.CAB.

Interemc CV60 (Intel P-III processor, Windows CE / Windows XP Embedded)
------------------------------------------------------------------------
CV60\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for the
Intermec CV60 terminal. Uses networking support that is
provided by the operating system. This is the stub
executable that is run to start the Client; the
majority of the program is in CV60\ETSPT.DLL.
CV60\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Intermec CV60 terminal; requires CV60\ETSPT.EXE
to start it.
CV60\ETSSCRPT.DLL - Intermec CV60 Client DLL containing text file processing.
CV60\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Intermec CV60
CV60\SAMPLE\CV60.CAB - Sample cabinet file for installing the Client onto
the Intermec CV60. Built using MAKECAB.BAT and
CV60\SAMPLE\CV60.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI, ETSCHECK.LIC, and ETSSCRPT.DLL.
CV60\SAMPLE\CV60.INF - Sample .INF file used with MAKECAB.BAT for creating
CV60.CAB.

Interemc 5020 (Hitachi SH3 processor, running Windows CE 3.0 or later)
----------------------------------------------------------------------
IMEC5020\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for
the Intermec 5020 terminal (running Windows CE 3.0).
Uses networking support that is provided by the
operating system. This is the stub executable that
is run to start the Client; the majority of the program
is in IMEC5020\ETSPT.DLL.
IMEC5020\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Intermec 5020 terminal (running Windows CE 3.0);
requires IMEC5020\ETSPT.EXE to start it.
IMEC5020\ETSSCRPT.DLL - Intermec 5020 Client DLL containing text file processing.
IMEC5020\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Intermec 5020
IMEC5020\SAMPLE\IMEC5020.CAB - Sample cabinet file for installing the Client onto
the Intermec 5020 (running Windows CE 3.0). Built
using MAKECAB.BAT and IMEC5020\SAMPLE\IMEC5020.INF.
Installs ETSPT.EXE, ETSPT.DLL, LUCON.TTF, LOGFILE.NDX,
LOGFILE.LOG, EMULATOR.INI, ETSCHECK.LIC and ETSSCRPT.DLL.
IMEC5020\SAMPLE\IMEC5020.INF - Sample .INF file used with MAKECAB.BAT for creating
IMEC5020.CAB.

Intermec 600 (AMD 486 processor, Windows CE 2.12)
-------------------------------------------------
Note: script text file processing is not supported on the Intermec 600 terminal
due to there being no support for C++ exception handling on this platform.

IMEC600\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for
the Intermec 600 terminal. Uses networking support
that is provided by the operating system. This is the
stub executable that is run to start the Client; the
majority of the program is in IMEC600\ETSPT.DLL.
IMEC600\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Intermec 600 terminal; requires IMEC600\ETSPT.EXE
to start it.
IMEC600\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Intermec 600
IMEC600\SAMPLE\IMEC600.CAB - Sample cabinet file for installing the Client onto
the Intermec 600. Built using MAKECAB.BAT and
IMEC600\SAMPLE\IMEC600.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI and ETSCHECK.LIC.
IMEC600\SAMPLE\IMEC600.INF - Sample .INF file used with MAKECAB.BAT for creating
IMEC600.CAB.

Interemc 6651 (Toshiba MIPS processor, running Windows CE 3.0 or later)
-----------------------------------------------------------------------
IMEC6651\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for
the Intermec 6651 terminal. Uses networking support
that is provided by the operating system. This is the
stub executable that is run to start the Client; the
majority of the program is in IMEC6651\ETSPT.DLL.
IMEC6651\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Intermec 6651 terminal; requires IMEC6651\ETSPT.EXE
to start it.
IMEC6651\ETSSCRPT.DLL - Intermec 6651 Client DLL containing text file processing.
IMEC6651\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Intermec 6651
IMEC6651\SAMPLE\IMEC6651.CAB - Sample cabinet file for installing the Client onto
the Intermec 6651. Built using MAKECAB.BAT and
IMEC6651\SAMPLE\IMEC6651.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI, ETSCHECK.LIC and ETSSCRPT.DLL.
IMEC6651\SAMPLE\IMEC6651.INF - Sample .INF file used with MAKECAB.BAT for creating
IMEC6651.CAB.

Intermec 700 (Intel ARM processor or compatible, running Windows CE or later)
-----------------------------------------------------------------------------
Note: Intermec 700's that have Pocket PC 4.x or later can use the DCConnect
Client build fles found in SYM90XX - which provides full support for text file
processing. Intermec 700's with Pocket PC 3.x must use the files in IMEC700
which do not support text based processing due to the lack of exception handling
in Pocket PC 3.x.

IMEC700\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for
the Intermec 700 terminal with Pocket PC 3.x.
Uses networking support that is provided by the
operating system. This is the stub executable that
is run to start the Client; the majority of the
program is in IMEC700\ETSPT.DLL.
IMEC700\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Intermec 700 terminal with Pocket PC 3.x;
requires \IMEC700\ETSPT.EXE to start it.
IMEC700\ETSUSER.DLL - Sample ETSUSER.DLL built for the Intermec 700 using
ETSUSER.C and the other source files above.
IMEC700\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Intermec 700
IMEC700\SAMPLE\IMEC700.CAB - Sample cabinet file for installing the Client onto
the Intermec 700. Built using MAKECAB.BAT and
IMEC700\SAMPLE\IMEC700.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI, ETSCHECK.LIC and ETSUSER.DLL.
IMEC700\SAMPLE\IMEC700.INF - Sample .INF file used with MAKECAB.BAT for creating
IMEC700.CAB.

LanPoint CE (AMD 486 processor, Windows CE 3.0)
-----------------------------------------------
Note: Note: script text file processing is not supported on the LanPoint CE terminal
due to there being no support for C++ exception handling on this platform.

LANPTCE\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for the
Intelligent Instrumentation LanPoint CE terminal.
Uses networking support that is provided by the
operating system. This is the stub executable that is
run to start the Client; the majority of the program is
in LANPTCE\ETSPT.DLL.
LANPTCE\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the LanPoint CE terminal; requires LANPTCE\ETSPT.EXE
to start it.
LANPTCE\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for LanPoint CE
LANPTCE\SAMPLE\LANPTCE.CAB - Sample cabinet file for installing the Client onto
the LanPoint CE. Built using MAKECAB.BAT and
LANPTCE\SAMPLE\LANPTCE.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI and ETSCHECK.LIC.
LANPTCE\SAMPLE\LANPTCE.INF - Sample .INF file used with MAKECAB.BAT for creating
LANPTCE.CAB.

Symbol 81xx (compatible with Intermec 700)
------------------------------------------
SYM81XX\SAMPLE\CECONFIG.INI - Sample CECONFIG.INI for Symbol 81xx
SYM81XX\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Symbol 81xx
SYM81XX\SAMPLE\SYM81XX.CAB - Sample cabinet file for installing the Client onto
the Symbol 81xx. Built using MAKECAB.BAT and
SYM81XX\SAMPLE\SYM81XX.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI and ETSCHECK.LIC.
SYM81XX\SAMPLE\SYM81XX.INF - Sample .INF file used with MAKECAB.BAT for creating
SYM81XX.CAB.

Symbol 90xx (Intel ARM processor or compatible, running Windows CE or later)
----------------------------------------------------------------------------
SYM90XX\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for the
Symbol MC90xx terminal. Uses networking support that is
provided by the operating system. This is the stub
executable that is run to start the Client; the
majority of the program is in SYM90XX\ETSPT.DLL.
SYM90XX\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Symbol MC90xx terminal; requires SYM90XX\ETSPT.EXE
to start it.
SYM90XX\ETSSCRPT.DLL - Symbol MC90xx Client DLL containing text file processing.
SYM90XX\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for Symbol MC90xx
SYM90XX\SAMPLE\SYM90XX.CAB - Sample cabinet file for installing the Client onto
the Symbol MC90xx. Built using MAKECAB.BAT and
SYM90XX\SAMPLE\SYM90XX.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI, ETSCHECK.LIC, and ETSSCRPT.DLL.
SYM90XX\SAMPLE\SYM90XX.INF - Sample .INF file used with MAKECAB.BAT for creating
SYM90XX.CAB.

Symbol 91xx (Intel ARM processor or compatible, running Windows CE or later)
----------------------------------------------------------------------------
This flavor of the Client handles the VGA resolution of the Symbol 91xx and other
compatible devices.

SYM91XX\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for
the Symbol MC91xx terminal. Uses networking support
that is provided by the operating system. This is the
stub executable that is run to start the Client; the
majority of the program is in SYM91XX\ETSPT.DLL.
SYM91XX\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Symbol MC91xx terminal; requires \SYM91XX\ETSPT.EXE
to start it.
SYM91XX\ETSSCRPT.DLL - Symbol MC91xx Client DLL containing text file processing.

Pocket PC Emulator (Debug Build)
--------------------------------
X86EMDBG\ETSPT.EXE - Windows CE TCP/IP Sockets flavor of Client for the
Microsoft Pocket PC Emulation Environment.
Uses networking support that is provided by the
operating system. This is the stub executable that is
run to start the Client; the majority of the program is
in X86EMDBG\ETSPT.DLL.
X86EMDBG\ETSPT.DLL - Windows CE TCP/IP Sockets flavor of Client DLL for
the Pocket PC Emulator; requires X86EMDBG\ETSPT.EXE
to start it.
X86EMDBG\ETSSCRPT.DLL - Pocket PC Emulator Client DLL containing text file processing.
X86EMDBG\SAMPLE\EMULATOR.INI - Sample EMULATOR.INI for the Pocket PC Emulator
X86EMDBG\SAMPLE\X86EMDBG.CAB - Sample cabinet file for installing the Client onto
the Pocket PC Emulator. Built using MAKECAB.BAT and
X86EMDBG\SAMPLE\X86EMDBG.INF. Installs ETSPT.EXE,
ETSPT.DLL, LUCON.TTF, LOGFILE.NDX, LOGFILE.LOG,
EMULATOR.INI, ETSCHECK.LIC, and ETSSCRPT.DLL.
X86EMDBG\SAMPLE\X86EMDBG.INF - Sample .INF file used with MAKECAB.BAT for creating
X86EMDBG.CAB.

Files Used for Building CFRs to Run with the Client (DOS, 32-bit Windows, Windows CE)
-------------------------------------------------------------------------------------
CFRTOOLS\CFRAPI24.H - Header file required for compiling all CFRs
CFRTOOLS\CFRWIN32.H - Header file required for compiling Win32 and CE CFR DLLs

CFRTOOLS\BORLAND\CFRAPI24.LIB - Library file required for linking when building CFRs
with Borland Turbo C++ 3.0 for DOS
CFRTOOLS\IBMC2\CFRAPI24.LIB - Library file required for linking when building CFRs
with IBM C/2 1.10

CFRTOOLS\CK30\CFRAPICE.LIB - Library file required for linking CFR built for
Intermec CK30 terminals
CFRTOOLS\CV60\CFRAPICE.LIB - Library file required for linking CFR built for
Intermec CV60 terminals
CFRTOOLS\IMEC600\CFRAPICE.LIB - Library file required for linking CFR built for
Intermec 600 terminals
CFRTOOLS\IMEC700\CFRAPICE.LIB - Library file required for linking CFR built for
Intermec 700 terminals
CFRTOOLS\IMEC5020\CFRAPICE.LIB - Library file required for linking CFR built for
Intermec 5020 terminals (running Windows CE 3.0)
CFRTOOLS\IMEC6651\CFRAPICE.LIB - Library file required for linking CFR built for
Intermec 6651 terminals
CFRTOOLS\LANPTCE\CFRAPICE.LIB - Library file required for linking CFR built for
Intelligent Instrumentation LanPoint CE terminals
CFRTOOLS\SYM90XX\CFRAPICE.LIB - Library file required for linking CFR built for
Symbol MC90xx terminals. Can also be used for
MC91xx cfrs.
CFRTOOLS\X86EMDBG\CFRAPICE.LIB - Library file required for linking CFR built for
MS Pocket PC Emulation Environment

CFRTOOLS\WIN32\CFRAPI32.LIB - Library file required for linking 32-bit Windows CFRs

CFRTOOLS\CFRUTL24.RME - README file describing the files in the CFR utility
library package in more detail.
CFRTOOLS\CFRUTL24.HTM - More detailed documentation about each utility
routine.

CFRTOOLS\CFRUTL24.H - Include file use in building the CFR utility library -
and needed when building a CFR that uses the routines
in this library.
CFRTOOLS\*.C - Source files used to build the utility library. See
CFRTOOLS\CFRUTL24.RME for a description of each.

CFRTOOLS\CFRUTL24.MAK - Used for building the flavor of CFR utility library
for either the Borland Turbo C++ 3.0 for DOS compiler
or the IBM C/2 1.10 compiler.

CFRTOOLS\CFRUTL32.DSP - Project file used with MS Visual Studio for
building / working with the 32-bit Windows flavor
of the CFR utility library.
CFRTOOLS\CFRUTL32.DSW - Workspace file used with MS Visual Studio for
building / working with the 32-bit Windows flavor
of the CFR utility library.
CFRTOOLS\CFRUTL32.MAK - Generated by MS Visual Studio for building the
32-bit Windows flavor of the CFR utility library
CFRTOOLS\NMWIN32.BAT - Batch file used to build the 32-bit Windows flavor
of the CFR utility library. Uses CFRTOOLS\CFRUTL32.MAK.

CFRTOOLS\CFRULT40.VCN - MS Embedded Visual C++ Version 4.0 makefile, generated by
the build environment when loaded from cfrutl40.vcw.
Used by several of the build batch files below that build
the various CE flavors of the utility library, cfrutlce.lib,
for devices that run Windows CE 4.x and later (in
subdirectories CK30, CV60, SYM90XX...)
CFRTOOLS\CFRULT40.VCP - MS Embedded Visual C++ Version 4.0 project file used for
building some of the various flavors of cfrutlce.lib.
See cfrutl40.vcn file above for more details.
CFRTOOLS\CFRULT40.VCW - MS Embedded Visual C++ Version 4.0 workspace file used for
building some of the various flavors of cfrutlce.lib.
See cfrutl40.vcn file above for more details.

CFRTOOLS\CFRULTCE.VCN - MS Embedded Visual C++ Version 3.0 makefile, generated by the
build environment when loaded from cfrutlce.vcw. Used by
several of the build batch files below that build the various
CE flavors of the utility library, cfrutlce.lib, for devices
that run Windows CE 3.x and earlier (in subdirectories
IMEC600, IMEC700, ...)
CFRTOOLS\CFRULTCE.VCP - MS Embedded Visual C++ Version 3.0 project file used for
building many of the various flavors of cfrutlce.lib.
See cfrutlce.vcn file above for more details.
CFRTOOLS\CFRULTCE.VCW - MS Embedded Visual C++ Version 3.0 workspace file used for
building many of the various flavors of cfrutlce.lib.
See cfrutlce.vcn file above for more details.

CFRTOOLS\NMCK30.BAT - Batch file for building Intermec CK30 flavor of
cfrutlce.lib. Uses CFRTOOLS\CFUTL40.VCN.
CFRTOOLS\NMCV60.BAT - Batch file for building Intermec CV60 flavor of
cfrutlce.lib. Uses CFRTOOLS\CFUTL40.VCN.
CFRTOOLS\NMI600.BAT - Batch file for building Intermec 600 flavor of
cfrutlce.lib. Uses CFRTOOLS\CFUTLCE.VCN.
CFRTOOLS\NMI700.BAT - Batch file for building Intermec 700 flavor of
cfrutlce.lib. Uses CFRTOOLS\CFUTLCE.VCN.
CFRTOOLS\NMI5020.BAT - Batch file for building Intermec 5020 (running Windows
CE 3.0) flavor of cfrutlce.lib. Uses
CFRTOOLS\CFUTLCE.VCN.
CFRTOOLS\NMI6651.BAT - Batch file for building Intermec 6651 flavor of
cfrutlce.lib. Uses CFRTOOLS\CFUTLCE.VCN.
CFRTOOLS\NMLPTCE.BAT - Batch file for building Intelligent Instrumentation
LanPoint CE flavor of cfrutlce.lib. Uses
CFRTOOLS\CFUTLCE.VCN.
CFRTOOLS\NMS90XX.BAT - Batch file for building Symbol MC90xx flavor of
cfrutlce.lib. Uses CFRTOOLS\CFUTL40.VCN. Can also
be used for MC91xx CFRs.
CFRTOOLS\NMX86EM.BAT - Batch file for building the MS Pocket PC Emulator
flavor of cfrutlce.lib. Uses CFRTOOLS\CFRUTLCE.VCN.

CFRTOOLS\BORLAND\CFRUTL24.LIB - Utility library file used when linking CFRs built with
Borland Turbo C++ 3.0 for DOS
CFRTOOLS\IBMC2\CFRUTL24.LIB - Utility library file used when linking CFRs built with
IBM C/2 1.10

CFRTOOLS\CK30\CFRUTLCE.LIB - The utility library for use on Intermec CK30 terminals
CFRTOOLS\CV60\CFRUTLCE.LIB - The utility library for use on Intermec CV60 terminals
CFRTOOLS\IMEC600\CFRUTLCE.LIB - Utility library file used when linking CFRs built for
Intermec 600 terminals
CFRTOOLS\IMEC700\CFRUTLCE.LIB - Utility library file used when linking CFRs built for
Intermec 700 terminals
CFRTOOLS\IMEC5020\CFRUTLCE.LIB - Utility library file used when linking CFRs built for
Intermec 5020 terminals (running Windows CE 3.0)
CFRTOOLS\IMEC6651\CFRUTLCE.LIB - Utility library file used when linking CFRs built for
Intermec 6651 terminals
CFRTOOLS\LANPTCE\CFRUTLCE.LIB - Utility library file used when linking CFRs built for
Intelligent Instrumentation LanPoint CE terminals
CFRTOOLS\SYM90XX\CFRUTLCE.LIB - The utility library for use on Symbol MC90XX terminals.
Can also be used for MX91xx terminals.
CFRTOOLS\X86EMDBG\CFRUTLCE.LIB - Utility library file used when linking CFRs built for
the MS Pocket PC Emulator.

CFRTOOLS\WIN32\CFRUTL32.LIB - Utility library file used when linking CFRS built for
32-bit Windows.

CFRTOOLS\CFRSMP24.ZIP - Sample CFR package. Source, make and library
files included for DOS, 32-bit Windows and
Windows CE devices

CFRTOOLS\CFRPAN24.ZIP - Input panel driver CFR package. Source, make and
library files included for DOS, 32-bit Windows
and Windows CE devices

CFRTOOLS\CFRUTL24.ZIP - Package of useful utility routines to include in
CFRs. Source, make and library files included
for DOS, 32-bit Windows and Windows CE devices

Note: This package is no longer included as a .ZIP file
in the product. Instead its contents are included,
already expanded, into the CFRTOOLS directory
(e.g. cfrutl24.h, ibmc2\cfrutl24.lib, ...) See
CFRTOOLS\CFRUTL24.RME for a complete list of files.

The CD installation also adds the following files to the \DCCONN\HELP directory:

DCCLIENT.HTM - This file
7524ETS.HTM - Technical Reference for DCConnect Client - includes information about
CFR APIs, internal file formats and the communications protocol.
E9GWROOT.HTM - Part of Technical Reference
E9GWTOC.HTM - Part of Technical Reference

The CD itself contains a \MANUALS subdirectory that includes the DCConnect Client
documentation along with documentation for most of the other IBM Data Collection
products. To bring up an index of these manuals, just point your browser to:

file:///d:\manuals\index.htm

where d: is the letter for your CD drive, and you will see the list of manuals
provided.

Installation Hints for the FTP Software TCP/IP Stack
----------------------------------------------------
In many cases, you will need to install files from the FTP Software product,
PCTCP Network Kernel for DOS.

Note: FTP Software is now a subsidiary of NetManage.

While some files can simply be copied from the diskettes, others are on the
diskettes in a packed format and must be expanded. From a DOS session in
either OS/2 or Windows/NT you can run a program called EXPAND.EXE which can
expand the compressed files on to your harddrive. The program takes two
parameters, the source file name and the target file name. For example:

expand a:\odipkt.co_ odipkt.com

Listed below are files that you may need from the PCTCP product and how to get
them. The location of these files is based on version 4.1 of the PCTCP product.

ethdrv.exe --> Using diskette 2: copy a:\ethdrv.exe

dis_pkt.gup --> Using diskette 3: expand a:\dis_pkt.gu_ dis_pkt.gup
odipkt.com --> Using diskette 3: expand a:\odipkt.co_ odipkt.com
netbind.com --> Using diskette 3: expand a:\netbind.co_ netbind.com
protman.dos --> Using diskette 3: expand a:\protman.do_ protman.dos
protman.exe --> Using diskette 3: expand a:\protman.ex_ protman.exe

Authentication Key and Serial Number Entries in the .INI file
-------------------------------------------------------------
The original versions of the PCTCP product required that each device on the
network running the software must use the unique serial-number and
authentication key that are specified for each unique license. These
parameters are defined in the .INI file (PCTCP.INI, LPTCP.INI, ...) for
the network parameters in the section [pctcp kernel]. For example:

[pctcp kernel]
serial-number = aaaa-bbbb-cccc ; Fill in the unique serial #
authentication-key = xxxx-yyyy-zzzz ; Fill in the unique key
interface = ifcust 0

Using these original versions, a message about duplicate licenses would be
displayed if two devices were using the same serial-number and key.

More current versions of the network drivers that are provided by the terminal
manufacturers - and possibly by FTP Software themselves - no longer require
these entries in the .INI file.

However, it is still necessary to purchase a license of the PCTCP product for
each device - just as it is necessary to purchase a license of the DCConnect
Client for each device that will be running it.

Note: many times the terminal manufacturer will resell the drivers from FTP
Software and provide an option to have them preinstalled on the terminal. In
these cases, you would not have to purchase a separate license directly from
FTP Software; the license for each device is obtained from the terminal
manufacturer instead.

Common Command Line Parameters for the Client
---------------------------------------------
There are a few command line parameters that can be used whether you are
running the serial-attached or one of the TCP/IP-attached flavors of the
Client.

Note: As of version 1.40H, with the exception of the -M and -F parameters all
command line parameters can now be defined in the EMULATOR.INI file. For
more details, see Configuration using EMULATOR.INI

Attach-specific command line parameters are covered in the following two
sections. The format of the common parameters (used with etspb) is:

etspb [-DDevice] [-Ffilename] [-M] [-Sscriptname] [-O=option]

where:

'-DDevice' indicates the type of device the Client is running on.
The Client must behave different ways for the various
supported devices. Choices for 'Device' are:

LANPOINT - for the Intelligent Instrumentation LanPoint
FACTORYPOINT - for the Intelligent Instrumentation FactoryPoint
TIMEPOINT - for the Intelligent Instrumentation TimePoint
LANPOINTPRO - for the Intelligent Instrumentation LanPoint Pro

INTERMEC6400 - for the Intermec/Norand 6400
INTERMEC6540 - for the Intermec 6540 (MaxiLAN replacement)
INTERMEC5020 - for the Intermec Windows CE 5020
MAXILAN - for the Intermec MaxiLAN DX

ANTARES16x20 - for any Intermec Antares with 16x20 display
ANTARES20x40 - for any Intermec Antares with 20x40 display
ANTARES12x40 - for any Intermec Antares with 12x40 display
ANTARES4x40 - for any Intermec Antares with 4x40 display
ANTARES2x16 - for any Intermec Antares with 2x16 display

JANUS - for the Janus 2010 or 2020
JANUS2010 - for the Janus 2010 or 2020
JANUS2020 - for the Janus 2010 or 2020
JANUS2050 - for the Janus 2050

FMT10X0 - for the Symbol FMT1020, FMT1040 or FMT1060
FMT3000 - for the Symbol FMT3000

LRT3840 - for the Symbol LRT3840
VRC3940 - for the Symbol VRC3940 or VRC6940
PDT3140 - for the Symbol PDT3140
WSS1040 - for the Symbol WSS1040 or WSS1060
PDT6840 - for the Symbol PDT6840

PTC960 - for the Telxon 960SL or 960X
PTC860 - for the Telxon 860IM
PTC870 - for the Telxon 870IM

One of the above names should immediately follow the -D
on the command line.

If you don't see the device you are using listed above,
you may not need to use the -D parameter - although
you may still want to set up some parameters in
EMULATOR.INI to change some default parameters such
as NUM_ROWS and NUM_COLS.

If the Client is running on a PC, this parameter is not
needed.

'-Ffilename' indicates the name of a configuration file from which to
read parameters. Use the up-to-8-character name you
previously used when saving the configuration from the
Client menus. The actual file name has the extension
.SER or .TCP added to the end of whatever name was picked
from the menus.

The very first time you run the Client, you would not
use this parameter - unless you used a configuration file
from another system.

Note 1: Now that all parameters can be defined in EMULATOR.INI,
the -F parameter and the corresponding configuration
file can be replaced by the addition of the appropriate
keywords to EMULATOR.INI. For more details, please see
Configuration using EMULATOR.INI.

Note 2: If this option is to be used and a specific device is
specified using the -D parameter, you must set the STATUS
ROW option in the menus as appropriate for the device the
Client will be running on before saving the configuration
to file.

Normally, the -d parameter sets the status row
appropriately. But using a configuration file with the -f
parameter will override the device's default assigned
value. And if the menu default value (row 20) is not
visible on the device, the device will appear as if it is
not working.

Another way to resolve this problem is to eliminate the
use of the -F command line parameter and the
corresponding configuration file and instead to add
to the EMULATOR.INI file any parameters that were
previously set using the menus.

'-M' This parameter tells the Client to start in the menus and not
try to start up communications. Because the communications are
not being started, the Client can be run from the PC with the
EMULATOR.INI file (and license file) in the same directory. You
can then verify that the configuration file is set up properly
by using the VIEW SETTINGS option in the menus.

This option is not valid for Antares terminals because the
Antares flavor of the program can only run inside the Antares
terminal.

Note: Prior to version 1.40H this option allowed you to go
into the menus and make configuration changes and then
save them to file - without actually running the Client
However, starting with version 1.40H, the configuration
screens have been removed from the menus and all
configuration is done via EMULATOR.INI (although for
backwards compatability the -f option can still be used
to read a previously created configuration file.

Once in the menus, the VIEW SETTINGS option can be selected
to verify that all configuration parameters have been set up
as expected. After you have reviewed the settings and then
go to exit the menus, the program will end without trying
to start communications with the DCConnect Server.

This option is useful when trying to verify a configuration
for a device like the Intermec 6540 or Intelligent Instrumentation
LanPoint/FactoryPoint/Timepoint terminals which only have a
few rows. The menus sometimes use up more rows then the device
might have available. In these situations, it is better to run
the Client on a PC with the -M option to verify the configuration
for the device.

If you would normally use the -D parameter when running the
Client on a particular device, then when you use the -M
parameter you should also use the -D parameter. For example,
to view the configuration for an Intermec 6540 terminal
enter the following when running from a PC:

etspt -m -dINTERMEC6540

Using the -M option, the DOS flavors of the Client can run on
a true DOS machine or in a full-screen DOS session of OS/2,
Windows/NT or Windows/95. Note that the DOS flavor of the
Client cannot run in a windowed DOS session on any of these
other operating systems.

-Sscriptname specifies that the Client should load transaction programs
and the rest of its configuration from the specified script
text file. See the EMULATOR.INI keyword equivalent to this,
SCRIPT_NAME for more information about script files.

The command line setting will override the .INI file setting
if both are present.

-O=option used to enable one or more options. If more than one option
needs to be enabled, use this command line option multiple times.
Possible choices for "=option" are:

=Compile_Only Use this option in conjunction with -S to tell
the Client only to compile the script file; don't actually run
it. For more details see Keyword: COMPILE_ONLY.

=DONT_USE_IMBED_PATHS Use this option to tell the Client to
ignore any paths found in IMBED commandsin downloaded script files.
Instead the Client should look for the specified script file in the
same directory that it looks for EMULATOR.INI.

=LOG_COMPILE_WARNINGS Use this option to tell the Client, when
compiling a text script, to log to ETSPT.MSG any warning messages
that occur. By default, warnings are not logged because there can
be hundreds of them and logging them can affect performance
during the download process.

Starting the Serial-Attached Flavor of the Client
-------------------------------------------------
In order to run the serial-attached flavor of the Client, issue the
following command on the command line:

etspb [-Ffilename] [-DDevice] [-M] [-Sscriptname] [-O=option] [-Cc] [-Aa] [-Bbbbb]

where: -Ffilename is described 'Common Command Line Parameters for the
Client' above.

-DDevice is described 'Common Command Line Parameters for the
Client' above.

-M is described 'Common Command Line Parameters for the
Client' above.

-Sscriptname is described 'Common Command Line Parameters for the
Client' above.

-O=option is described 'Common Command Line Parameters for the
Client' above.

-Cc indicates which COM port to use. Valid choices are 1 to 4.
If this parameter is not specified, COM1 is used.

-Aa indicates which terminal address to use. Valid choices are
A to Y and 0 to 6. If this parameter is not specified,
the value * is used - indicating an address has not been
configured.

-Bbbbb indicates which baud rate to use. Valid choices are 300,
1200, 2400, 4800, 9600, 19200, or 38400. If this parameter
is not specified, a baud rate of 19200 is used.

Typically you would specify the configuration file name without specifing any
other parameters. However, if both are specified, the command line parameters
would override any parameters that are part of the specified configuration.

When entering parameters, upper or lower case can be used. Do not include
the square brackets shown above; those brackets indicate the parameters which
are optional.

As an example, to run the Client on an Intermec 6540 terminal using address F
on COM2 using baud rate 19200, the following would be entered on the command
line:

etspb -dINTERMEC6540 -c2 -aF

Starting the TCP/IP-Attached Flavor of the Client
-------------------------------------------------
Regardless of which TCP/IP product support is being used, to run the TCP/IP-
attached flavors of the Client, issue the following command on the command
line:

etspt [-Ffilename] [-DDevice] [-M] [-Sscriptname] [-O=option] [-Nname] [-Ppppp] [-Ha.b.c.d,pppp]

where: -Ffilename is described 'Common Command Line Parameters for the
Client' above.

-DDevice is described 'Common Command Line Parameters for the
Client' above.

-M is described 'Common Command Line Parameters for the
Client' above.

-Sscriptname is described 'Common Command Line Parameters for the
Client' above.

-O=option is described 'Common Command Line Parameters for the
Client' above.

-Nname specifies the terminal name that this Client represents.
It is equivalent to the TERM_NAME parameter in EMULATOR.INI.
The command line setting will override the .INI file setting if
both are present.

For more details, see Keyword: TERM_NAME

-Ppppp indicates the IP port number to use for the Client.
The range is 2000 to 9999. If this parameter is not
specified, 7500 is used for the IP port number.

The -P parameter is the command line equivalent to the
TCPIP_PORT parameter in EMULATOR.INI. The command
line setting will override the .INI file setting if
both are present.

This parameter is ignored on Antares terminals because
the Network Port is set in the Antares menus - or
using the SETUPANT.EXE utility. For more information
about the Antares menus and the SETUPANT.EXE utility, see
Using the Antares Menus and the SETUPANT.EXE Utility.

-Ha.b.c.d,pppp indicates the IP address and IP port number of the
DCConnect Server. If this parameter is specified,
you must use a valid IP address followed by a comma and
the IP port number. Do NOT put spaces anywhere in the
parameter. If you omit the comma and port number, the
default port number, 7500, is assumed for the host.

The -H parameter is the command line equivalent to the
TCPIP_HOST parameter in EMULATOR.INI. The command
line setting will override the .INI file setting if
both are present.

Starting with version 2.10 of the Client, you also have
the option to specify the hostname of the DCConnect
Server instead of its IP address. (Except for Symbol
Spectrum 24 terminals such as the PDT6840, VRC6940 and
WSS1040). For example, if the Windows flavor of the
Client is running on the same PC as the Server, the
DCConnect server and port could be specified as:

-hlocalhost,7500

Also, start with version 2.10 of the Client, a colon
can be used instead of the comma:

-hlocalhost:7500

Note: Depending on the network setup, it may be necessary
to give the fully qualified network name (hostname@domain).
For example:

-hdcserver@ibm.com,7500

This parameter is ignored on Antares terminals because
the Controler IP Address is set in the Antares menus -
or using the SETUPANT.EXE utility. For more information
about the Antares menus and the SETUPANT.EXE utility, see
Using the Antares Menus and the SETUPANT.EXE Utility.

Using this parameter, causes an 'I-am-here' message
to be sent to the DCConnect Server as soon as the
the Client is started - which should result in the
start of the download in a matter of seconds.

If this parameter is not specified, the Client waits
for the DCConnect Server to issue a slow poll to the
to the Client's IP address and port number before it
communicates at all. Typically the data collection
server will issue the slow poll once a minute unless
its configuration has increased that value.

The previous two paragraphs are true for all but the
Antares terminal. Because the Antares terminal uses
stream sockets, it is the one that will continually
make attempts to communicate with the DCConnect
Server - every 90 seconds until it is successful.

When entering parameters, upper or lower case can be used. Do not include
the square brackets shown above; those brackets indicate the parameters which
are optional.

As an example, to run the Client on an Intelligent Instrumentation FactoryPoint
terminal using port number 7501 when communicating with the DCConnect Server
whose IP address is 3.1.65.99 and whose IP port number is 7500, the following
would be entered on the command line:

etspt -dFACTORYPOINT -p7501 -h3.1.65.99,7500

Menus
-----
Note: As of version 1.40H, all configuration screens have been removed from
the menus. Instead all parameters can now be configured by adding
parameters to the EMULATOR.INI file. For more information, please see
Configuration using EMULATOR.INI.

The menus now only provide options for diagnostics and for viewing the
version of the Client and its current configuration.

At any time, the Client menus can be brought up by pressing the Home key, the
equal sign or question mark key.

Note: If the device being used has less than 8 rows, it is probably better
to try and view the configuration from a PC rather than on the device
itself. Refer to the description of the -M parameter in the section
Common Command Line Parameters for the Client.

While the menus are displayed, communications with the data collection server
continue to go on. So you could, for example, enter the menus while a
download to the Client is in progress and the download would go on
uninterrupted.

The menu layout is shown below, starting with the Main Menu.

........................
. .
. MAIN (FTP TCP): 7500 .
. -------------------- .
. 1) VERSION INFO .
. 2) TXTN COUNT .
. 3) DIAGNOSTICS .
. 4) VIEW SETTINGS .
. 5) CLOSE MENUS .
. 6) MOVE KEYPAD .
. .
. X or 0 = EXIT .
........................
.
........................ . ........................
. . . . .
. VERSION INFO . (1). . TXTN COUNT .
. ------------ ...... . ---------- .
. DCCONN ClIENT V2.10 . . . TO SEND: 1 .
. Jun 3 2004 19:20 . .(2) . SPACE FOR: 351 .
. MADE W/ADK 4.42 . ...... .
. FREE MEM: 223000 . . . .
. . . . .
. . . . ENTER/ESC = END .
........................ . ........................
.
........................ . .......................
. . . . .
. DIAGNOSTICS . (3). . SETTINGS 1 OF 9 .
. ----------- ...... . --------------- .
. 1) TRACE LOG . . . DEVICE .
. 2) DUMP MEMORY . .(4) . JANUS .
. 3) VIEW USER VAR . ...... TCPIP_HOST .
. 4) START STEPPING . . 99.99.99.17,7500 .
. 5) TURN ON CMD LOG . . TCPIP_PORT .
. 6) RETURN . . 7500 .
. . . .
. . . UP/DN=SCROLL Q=QUIT .
........................ .......................
.
. .......................
. . .
. . TRACE LOG .
.(1) . --------- .
...... 1) TO SCREEN .
. . 2) TO RS-232 .
. . 3) TO SCREEN/232 .
. . 4) RETURN .
. . .
. .......................
.
. .......................
. . .
. . MEMORY DUMP .
.(2) . ----------- .
...... MAKE CHOICES .
. . THEN HIT ENTER: .
. . .
. . 1) DUMP PARMS/PGMS .
. . 2) TO SCREEN .
. . .
. . BKSPACE/ESC = QUIT .
. .......................
.
. .......................
. . VIEW USER VAR .
. . ------------- .
.(3) . UV Pool Max-Min-Now .
...... 10000-10000-10000 .
. .
. Global UV0-99: .
. BLANK=NEXT W/DATA .
. .
. .
. ENT=NEXT ESC=QUIT .
.......................

Note: For the Windows CE flavors of the Client, access to the menus shown above
is provided via a traditional Windows action/command bar at the top of
DCConnect Client window. The action bar menus are used to select one of
the above menus, but once selected, the selected information is displayed
in the main window over the idle screen or transaction program that is
running. Once you end the menu option (by pressing Esc), the idle screen
or transaction program is redisplayed. While one menu option is active,
no other menu option can be selected.

Main Menu
---------
The title of the Main Menu includes the flavor of the Client that is running,
such as "FTP TCP", "Batch", ... and the currently configured address/port
number that is configured.

The options available on the Main Menu are:

1) Show the Version Info about the Client. Included is the version number,
the date and time it was built, the version of the Norand Application
Development Kit (ADK) that was used to build it and the amount of free
memory that is currently available in the terminal. When the option to show
this menu is selected, you'll temporarily see a "CHECKING MEMORY..." screen
which shows the free memory total as it is counted up.

2) Show the current statistics about the quantity of transactions stored
in the terminal, awaiting transmission to the data collection server and
the number of bytes that are currently being used out of the total
capacity.

If many transactions are buffered and are actively being sent to the
data collection server, this screen will be updated 5 times a second
to show the current statistics.

3) The Diagnostics Menu includes options for viewing the trace log, dumping
the contents of files, viewing user variables and starting/stopping
stepping of transaction programs. These options are explained below in the
Diagnostics Menu section.

4) Use the VIEW SETTINGS option to scroll a list of all parameters that can
be configured using EMULATOR.INI. The title of the screen indicates how
many screens of parameters are available for viewing. For each parameter,
the keyword is on one line and its value is shown on the next line,
indented by two spaces.

Use the up and down arrows to move from page to page. The Enter key is
also equivalent to the down arrow. Use the Q key or Esc key to return to
the main menu.

5) Use the CLOSE MENUS option to leave the menus; the Client remains running
when this option is selected. The Enter or Esc key can also be used to close
the menus.

6) The MOVE KEYPAD option is available only if the KEYPAD_xxxx options are being
used in EMULATOR.INI to define an on-screen keypad. Choosing this option
will switch the keypad to the opposite side of the screen from where it is
now. For example, if on the right, choosing this option will move it to the
left. The keypad remains in the new location until this option is selected
again - or until the Client is restarted. Whenever the Client starts, the
keypad position reverts to the location specified by the KEYPAD_POSITION
keyword in EMULATOR.INI.

X or 0) Press the X or 0 key to end the Client program. You will be asked to
confirm your choice to exit by pressing the Enter key.

Diagnostics Menu
----------------
The options available on the Diagnostics Menu are:

1) TRACE LOG: Dump the contents of the communications trace log to the screen
or to the RS-232 port. The communications trace log stores up to 80 bytes
of last 128 messages that were sent to/from the Client from/to the DCConnect
Server.

Note: To make more memory available for downloaded files, the Antares
flavors of the Client only store 40 bytes of the last 20
messages.

For the serial-attached flavor of the Client, the RS-232 port is not
a valid place to dump the trace log because that port is used to attach
to the data collection server.

The Trace Log screen provides options 1-3 to start the dump to the
screen, to the RS-232 port or both. The dump is started when one of
those three options is started.

If the dump is to go to the screen, only the last 20 or so messages are
displayed. The complete dump is only sent when the target is the RS-232
port.

If the target is RS-232 the data is written to the port using a baud rate
of 19200, no parity, 8 data bits and 1 stop bit.

For a complete description of the communications protocol used by the
Client, refer to the:

7524 Extended Terminal Services / DCConnect Client Technical Reference.

2) DUMP MEMORY: Dump the contents of a particular file in memory to the screen
or to the RS-232 port.

If FILE_PAGING is currently in effect, then before the MEMORY DUMP
screen is shown, other screens will be shown indicating which
transaction programs and validation files are currently loaded into
memory and how much space they consume. As of 3.0.8m the sizes of all
transaction programs will be shown; those that are actually in memory
will have an asterisk before the key ID.

The screen entitled PROGRAMS (*IN MEM) will list all transaction programs.
For each program, its programs number (1-121), name and its size will
be shown. An asterisk will precede them name if it is in memory. In the
following example, programs F1 and F2 are loaded into memory:

PROGRAMS (*IN MEM)

1 *F1: 101 bytes
2 *F2: 20 bytes
3 F3: 482 bytes
4 F4: 550 bytes
5 F5: 476 bytes
6 F6: 513 bytes
7 F7: 524 bytes
8 F8: 498 bytes
9 F9: 96 bytes
...

ENTER=NEXT ESC=QUIT

Up to 10 programs will be listed on the screen at a time. If more than
that are in memory, the last line will show '...' and additional screens
with the same title will be used to view the other programs. Press
ENTER to move to the next screen or press ESC to leave this menu
option and return to the main menu.

After all screens for transaction programs are shown, screens for
validation files will be shown. The screen entitled PAGED FILES IN MEM
will list all validation files that are in memory, ordered from most
recently used to least recently used. For each validaiton file, its
name and its size will be shown. For example:

D2R_SAMP.VAL = 84 bytes

This list will not include validation files that are LOCKED_IN_MEMORY.
If no other validation files are loaded in memory, NONE will be shown.
Up to 10 validation files will be listed on the screen at a time. If
more than that are in memory, the last line will show '...' and
additional screens with the same title will be used to view the other
validation files. ENTER and ESC work the same on this screen as they
do on the PROGRAMS IN MEM screen. After all validation file screens
are shown, the MEMORY DUMP screen will be shown.

From the MEMORY DUMP screen, the following files are available to
be dumped to screen or RS-232:

PARMS/PGMS - Contains configuration parameters (record 0) and
all transaction programs (record 1-121). Each
record is separated by a record separator
character <1E>.
FAST CLOCK - Contains fast clocking configuration
MESSAGES - Contains the text for prompts and messages used
in transaction programs and some other system uses
such as the idle screen.
ALIAS STRINGS - Contains the initial values of alias strings for
PF keys and touch points
CFR - The fixed up CFR executable - if a CFR is in use
VAL MAPPING - Maps single character validation file identifiers 2-7,
A-Z, a-z to their full 8.3 filename counterparts
All validation files - Of course, only validation files loaded to the
terminal can be viewed. The list will show the
validation file ID (2-7, A-Z, a-z) followed by
a colon and the full 8.3 filename.

Note: If FILE_PAGING is in effect, when file 0 is being shown, the
contents of those programs which are not currently in memory will
be shown simply as !! followed by a record separator. In addition
any validation file that is selected for dumping will
automatically be loaded into memory if it is not already in memory.

For the serial-attached flavor of the Client, the RS-232 port is not
a valid place to dump the trace log because that port is used to attach
to the DCConnect Server.

The Memory Dump screen provides option 1 to change which file is to be
dumped. It defaults to PARMS/PGMS. As you press the 1 key, the file value
cycles through the list of files shown above. Some validation files (2-7)
will be listed between FAST CLOCK and MESSAGES while the rest (a-z, A-Z)
will be listed after VAL MAPPING. Once the end of the list is reached,
pressing 1 again will go back to the beginning of the list.

Option 2 lets you change the target of the dump: to screen, to the RS-232
port or both.

If the target is RS-232 the data is written to the port using a baud rate
of 19200, no parity, 8 data bits and 1 stop bit.

When you have set options 1 and 2, press the Enter key to begin the memory
dump. If the memory dump is going to the screen, you will be shown the
data one screen at a time. At the bottom of the screen will be an indicator
of where you are in the file and what the total size is. For example, if
the file is 2000 bytes long and the first screen can show the first 450
bytes, the bottom of the first screen of the dump will show (450 OF 2000).

While the memory dump is being displayed, the backspace or Esc key can be
used to stop showing the rest of the file. Any other key will cause the
next screen in the dump to be displayed.

Any character in the file that has an ASCII value less than 32 or greater
than 127 will be displayed in the format < xx > where xx is the hex value of
the character.

For a complete description of the contents of the Client's files, refer to
the:

7524 Extended Terminal Services / DCConnect Client Technical Reference.

3) VIEW USER VAR: Used to view the contents of any of the parameters, global
or local user variables or the return code variable (gRc / uvRC) used in
a transaction program in the terminal. To start the screen will be set up to show
global user variables. At this prompt just type in the user variable number (0 - 99)
and press the Enter key. The length of the user variable will be given along with
the data that is in the user variable.

Any character in the user variable data that has an ASCII value less than 32
or greater than 127 will be displayed in the format < xx > where xx is the hex
value of the character.

If the entry field is blank when you press Enter, the next non-empty user
variable will be displayed.

If you had entered a user variable number and pressed enter, in addition to
showing the length and contents of the specified user variable, the value
in the input field is automatically incremented by 1 so that if you wanted
to view the next user variable, all you'd have to do is press Enter.

If the entry field is blank, repeatedly pressing the Enter key will move
from one non-empty user variable to the next - until the last one is shown.
If the last non-empty user variable is being displayed and Enter is pressed
the following message will be displayed:

OTHERS ARE EMPTY!

Pressing Enter one more time (with the entry field still blank) will go
back to the beginning and show the first non-blank user variable.

To leave this screen at any time, press the Esc key.

Starting with version 2.00f of the Client which is the version in which
the use of a user variable pool was implemented, the top of this screen
will give some statistics about the user variable pool:

Max: The size of the pool (will be either 10000 or whatever
UV_POOL_SIZE is defined to be)
Min: The smallest amount of free space that there ever was
up to this point (gives an indication as to how much
is actually needed).
Now: The current amount of free space in the pool

The 'Min' value can be used to determine whether or not the size of the
user variable pool can be reduced - should additional space be required
for downloading files. If after running all of your transaction programs
using maximum length data inputs you find that the Min value is large enough
you could reduce the size of the pool.

Starting with version 2.10 of the Client, if you bring up this screen while
a transaction program is in progress you can also view the contents of
any local variables or parameters that are currently available. The
following letters are used to switch between the different types of
variables:

G = Choose a global variable to view
L = Choose a local variable to view
P = Choose a parameter to view (not added until 2.10b)

And in version 3.0.8i the return code user variable can also be selected:

R = Choose to view the return code variable (aka uvRC or gRC)

The screen will show the valid range of local variables/parameters that
are currently available. For example, if there are 2 local variables
and 3 parameters currently available, the screen will initially give
the following choices:

Global 0-99,L,P,R:

If you press L, the prompt becomes:

Local 1-2, P,G,R:

If you press P, the prompt becomes:

Parm 1-3, L,G,R:

If you press R, the prompt becomes:

uvRC,L,P,G: 1

Regardless of what type of variable/parameter is currently being viewed,
pressing enter with the field blank will show the first non-blank variable/
parameter.

Also starting with version 3.0.8i of the Client, the user variable / parameter
name will be shown on the same line as the UV / Parameter number and length
for the variable/parameter that is currently being shown - if the client has
loaded the programs from text files instead of being downloaded from a .PGM
file.

4) The START/STOP STEPPING option is used to turn on or off the ability to step
through transaction programs one command at a time. When you first press
the 4 key to START STEPPING, you will get a confirmation pop-up telling you
that stepping is now active and that the following keys can be used while
in stepping mode:

Enter = Next step
Esc = Cancel stepping
1-9,0 = Skip 1-10 steps
S = Skip current subroutine. Only valid when stopped at a GOSUB or
ONSUB command. All commands are processed in that subroutine
as well as any subroutine(s) that it calls. Stepping pauses at
the command following the subroutine call.
R = Return from the current subroutine. Only valid when in a
subroutine. Commands are processed up to and including the
RETURN command. Stepping pauses where the subroutine returns.
B = Leave the current (if or else) block. Stepping resumes after
the end block command (}) that ends the current block. Any
other blocks that are entered will be exited on the way to
the target end of the block.

You must press any key to clear the confirmation screen in the menus.
The wording for option 4 will now be STOP STEPPING - although most of
the time you would probably just stop stepping by pressing the Esc key.

When stepping is active, the bottom of the screen will be used to show, in
reverse video, the next command to be performed. First is the 3 digit step
number, then the name known in DCTPB or DCConnect is given (e.g. APND, SHOW,
CCFR) followed by the actual raw program command in parenthesis. For example:

001:SET/APNDSTR(;7CU60011)

Note 1: If the current sceen dimensions are at a size with less than 40 columns
use the arrow keys to move the screen so that you can see more of the command
at the bottom of the screen.

Note 2: If the transaction programs were loaded directly from script files
rather than being downloaded from .PGM file(s), then after the command name,
the parameters for the command will be more readable variable / parameter /
label names. For example:

001:SETSTR(lRowNumber, "7")

While the command is displayed at the bottom of the screen, you can press
Esc to cancel stepping or you can press Enter or one of the other valid
keys to execute that displayed command and move to the next command.

Note: Pressing Esc just ends stepping; it does not end the transaction
program. The program runs along normally after stepping is ended.

When Enter is pressed, the screen is restored to its prior contents and then
the command is performed. After that command is performed, there is a
brief delay before the next command will be displayed on the bottom of the screen.
When more than one command is skipped at a time, each command is shown very
briefly as it is performed.

If one of the commands to be skipped is one that prompts for input, such as a READ
command or a CCFR command that waits for keyboard or scanner input, then
while that command is being performed (i.e. while the input field is being
displayed) you will not see the reverse video display of a command at the
bottom of the screen. Only after Enter is pressed or a scann is performed for
that READ or CCFR commad and the field is accepted will the next command be
displayed at the bottom of the screen.

While stepping through a program, you can use the menus to do things such
as viewing the contents of user variables.

As was mentioned, you can end the stepping by pressing Esc when a command
is being shown in reverse video at the bottom of the screen, or you can
go into the menus and choose option 4) STOP STEPPING from the DIAGNOSTICS
MENU.

5) The TURN ON/OFF CMD LOG option is used to turn on or off the logging of
transaction program commands to a file called COMMANDS.LOG. This file is
created in the same folder where LOGFILE.LOG is created.

The content of this file is similar to the info shown on the bottom of
the screen when STEPPING mode is in effect, except that it is preceded
by a timestamp and the data is not truncated. For example:

01:34:37.630: 001:APNDSTR(;7CU60011)
01:34:37.640: 002:APNDSTR(;7CU70012)
01:34:37.650: 003:APNDSTR(;7CU80013)
01:34:37.660: 004:APNDSTR(;7CU90014)
01:34:37.670: 005:APNDSTR(;7CUA0015)
01:34:37.680: 006:GOTO/SUB(:GS05100501C003500)

The timestamp is followed by the 3 digit step number, then the command name
known in DCTPB or DCConnect is given (e.g. APND, SHOW, CCFR) followed by the
actual raw program command in parentheses.

Note: When text based compiling is in effect, the output will no longer just
be the raw binary command that would be found in a .PGM; rather it will show
the parameter / user variable / label names and look similar to the command
that was compiled from the .COD file. For example:

02:04:53.898: 158:SET RowCount,inRowCount
02:04:53.898: 159:IF (RowCount#==0)
02:04:53.898: 160:SET RowCount,gLastHelpRows
02:04:53.898: 161:GOSUB ADDL1:ShowHelp(Help,RowCount)
02:04:53.898: 163:LOCALS 4
02:04:53.898: 164:SET gLastHelpRows,RowCount

After this option is selected to turn on the logging, all transaction programs
that are executed are written to this file until this option is turned off
or until the transaction program completes. Be sure to turn off this option
or end the program before trying to access the COMMANDS.LOG file.

This option is not available for DOS versions of the DCConnect Client.

Menu Short Cut Keys
-------------------
There are two short cut keys available to quickly take you two a couple of the
diagnostic menu functions if ENABLE_MENU_SHORTCUTS=Y is specified in EMULATOR.INI:

- The '@' will bring up the Start Stepping menu. Just press Enter once from that
screen and you'll be back at the program with stepping mode in effect.

Note: If stepping mode is already in effect, pressing the @ key will appear to do
nothing.

- The '#' will bring up the View User Var screen directly. When done, press Enter
to return to the transaction program.

Configuration using EMULATOR.INI and MASTER.INI
----------------------------------------------
In version 1.20F of the Client, a new way was added for configuring the
Client using a text file called EMULATOR.INI. In that version, only certain
new parameters were configured using this text file. However, starting with
version 1.40H all parameters that used to be set from the command line or from
the menus can now be set by simply adding keywords to the EMULATOR.INI file.

If used, this file must be in the current directory when the Client is started.
The format of each line in the file is very simple:

KEYWORD = value

Comments are denoted by a slash (/). All lines that start with a slash are
ignored.

Spaces surrounding the KEYWORD, equal sign and value are optional.

The equal sign and value must be on the same line as the KEYWORD.

Blank lines are allowed any where in the file.

In version 3.0.8j, with the implementation of text-based downloads from the
DCConnect Server, the client also now looks for MASTER.INI - which the server
will send to the terminal along with the text files. The purpose of MASTER.INI
is to provide a mechanism for the server to assign to the client the values
for the SCRIPT_NAME and TERM_SUB_MODEL parameters. When a text file download
completes, the Client rereads EMULATOR.INI and MASTER.INI; settings in
MASTER.INI will override any matching settings in EMULATOR.INI.

Listed below are the valid keywords that can be used in either EMULATOR.INI or
MASTER.INI.

Note: The .INI files can include the section indicator [CONFIG] at the beginning
but it is not required for operation of the DCConnect Client itself; the Client
will just ignore it. This section indicator is used by the InstallShield-based
installation to allow it to update parameters in EMULATOR.INI during the
installation based on prompts that the user answers.

Keyword: ABORT_ONKEY_ON_RS232_INPUT
-----------------------------------
This keyword tells the Client to immediate cancel a waiting ONKEY command
if data is received on the RS-232 port. This can be useful when a data
collection device is used both to collect data from people and to collect
data from a serial device that periodically sends out data.

When this keyword is in effect and an ONKEY command is waiting for user
input, the receipt of data on the serial port will cause the ONKEY command
to abort, ending the transaction program. When the Client returns to the
idle prompt, if it finds that an RS-232 initiated transaction is defined,
that RS-232 transaction will be started so that the serial input can be
processed right away.

The keyword is specified as follows:

ABORT_ONKEY_ON_RS232_INPUT = Y

This keyword is likely to be used in conjunction with the the related
keyword, ABORT_READ_ON_RS232_INPUT, which applies to the READ command. For
more information please see Keyword: ABORT_READ_ON_RS232_INPUT.

Keyword: ABORT_READ_ON_RS232_INPUT
----------------------------------
This keyword tells the Client to immediate cancel a waiting READ command
if data is received on the RS-232 port. This can be useful when a data
collection device is used both to collect data from people and to collect
data from a serial device that periodically sends out data.

When this keyword is in effect and a READ command is waiting for user
input, the receipt of data on the serial port will cause the READ command
to abort, ending the transaction program. When the Client returns to the
idle prompt, if it finds that an RS-232 initiated transaction is defined,
that RS-232 transaction will be started so that the serial input can be
processed right away.

The keyword is specified as follows:

ABORT_READ_ON_RS232_INPUT = Y

This keyword is likely to be used in conjunction with the the related
keyword, ABORT_ONKEY_ON_RS232_INPUT, which applies to the ONKEY command. For
more information please see Keyword: ABORT_ONKEY_ON_RS232_INPUT.

Keyword: ADDRESS
----------------
This keyword is valid only for the serial flavors of the Client. It is used
to specify the terminal address - in the same way that the -A command line
parameter does. The keyword is specified as follows:

ADDRESS = A

The valid choices for address are the letters A through Y and the numbers 0
through 6.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the address value from that file will override the
ADDRESS parameter in EMULATOR.INI. Furthermore, if the command line parameter
-A is specified, it will override both the configuration file and the
ADDRESS parameter. Therefore the ADDRESS parameter will take effect only if
the -F and -A command line parameters are not used.

If no address is specified in the .INI file, the command line or a
configuration file, it will be set to '*' indicating that no address is
configured.

Keyword: ALL_SCAN_DATA_UPPER_CASE
---------------------------------
This keyword specifies that all scan data be converted to upper case. By
default the case of scan data is not changed. The keyword is specified as
follows:

ALL_SCAN_DATA_UPPER_CASE = Y

This keyword only takes effect if either the SCAN_SENTINEL_CHARS keyword or
USE_RS232_FOR_SCANNER keyword is used because without either of these in effect,
the Client has no way to distinguish keyboard data from scanner data. If all
scanner data simply looks like keyboard data to the Client then all scanner
and keyboard data is converted to upper case unless the ALLOW_LOWER_CASE keyword
is specifed.

Keyword: ALLOW_LOWER_CASE
-------------------------
This keyword specifies that lower case keyboard input should not be converted
to upper case. By default (without this keyword) all keyboard input is
converted to upper case. And if the SCAN_SENTINEL_CHARS keyword is not used,
all scanner input is treated the same as keyboard input. The keyword is
specified as follows:

ALLOW_LOWER_CASE = Y

If the SCAN_SENTINEL_CHARS keyword is being used, then this keyword has no
effect on scanner input. In this case, by default the case of scanner input
is not changed; however, the ALL_SCAN_DATA_UPPER_CASE keyword can be used to
override that default.

Keyword: AUTO_SCROLL_ROW
------------------------
This keyword, which is valid only for Android devices, is used to force the
current screen content to be positioned so that the current cursor position
always shows at a particular row. This is useful for those devices that have
no keyboard and the soft-keyboard Android or manufacturer provided keyboard takes
up a large portion of the screen. You would typically specify row 1, 2 or 3
since the soft-keyboard is usually displayed flush with the bottom of the
physical screen.

When this keyword is in effect, the auto-scrolling behavior only occurs when
the Client detects that the soft-keyboard is visible.

The keyword is specified as follows:

AUTO_SCROLL_ROW = 2

where the row can range from 1-20.

Note: that the Android / manufacturer provided soft-keyboard is different from
the keypad that can be defined in the EMULATOR.INI. That keypad is positioned
next to the screen content and therefore does not overlap it.

Keyword: BAUD_RATE
------------------
This keyword is valid only for the serial flavors of the Client. It is used
to specify the baud rate - in the same way that the -B command line parameter
does. The keyword is specified as follows:

BAUD_RATE = 19200

The valid choices for baud rate are 300, 1200, 2400, 4800, 9600, 19200 and
38400.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the baud rate value from that file will override the
BAUD_RATE parameter in EMULATOR.INI. Furthermore, if the command line
parameter -B is specified, it will override both the configuration file and the
BAUD_RATE parameter. Therefore the BAUD_RATE parameter will take effect only
if the the -F and -B command line parameters are not used.

If no baud rate is specified in the .INI file, the command line or a
configuration file, the baud rate defaults to 19200.

Keyword: COLOR_ATTRIBUTES
-------------------------
This keyword, which is valid only for 32-bit Windows flavors of the Client,
specifies that attributes be shown using the following color scheme:

- The REVERSE attribute shows up as white on blue.
- The BLINKING attribute shows up as white on red.
- The UNDERLINE attribute shows up as blue on black.
- Where combinations of these attributes are used, BLINKING supercedes
REVERSE which supercedes UNDERLINE. For example, if both the
REVERSE and BLINKING attributes were selected, the blinking
attribute would be used; so you'd get white on red.

The keyword is specified as follows:

COLOR_ATTRIBUTES = Y

If this keyword is not used the following scheme is used:

- The REVERSE attribute shows up as black on white.
- The BLINKING attribute shows up as bright red on black
- The UNDERLINE attribute shows up as bright white on black
- Where combinations of these attributes are used, the same rules of
precedence apply as described above for color.

Whether color is used or not, the normal display of characters (i.e.
with any attributes) is black on white.

Keyword: COMPILE_ONLY
---------------------
This keyword is used in conjunction with the SCRIPT_NAME parameter or -S
command line option to tell the Client that it should only compile the script
file; it should not attempt to load and run the transaction programs. When
this option is in effect, after the compile completes, a popup is shown
indicating whether or not the compile found any errors. If errors or warnings
are found, they are written to a file called ETSPT.MSG in the same directory
where the Client looks for EMULATOR.INI or MASTER.INI.

The keyword is specified as follows:

COMPILE_ONLY = Y

This keyword is equivalent to the command line option:

-O=Compile_Only

If neither is specified, after compilation of the script files completes, the
programs are loaded and the client attempts to establish communications with the
server.

Keyword: COM_PORT
-----------------
This keyword is valid only for the serial flavors of the Client. It is used
to specify the COM port on which the terminal is communicating to the data
colleciton server - in the same way that the -C command line parameter
does. The keyword is specified as follows:

COM_PORT = 1

The valid choices for COM port are 1 through 8.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the COM port value from that file will override the
COM_PORT parameter in EMULATOR.INI. Furthermore, if the command line
parameter -C is specified, it will override both the configuration file and the
COM_PORT parameter. Therefore the COM_PORT parameter will take effect only
if the the -F and -C command line parameters are not used.

If no COM port is specified in the .INI file, the command line or a
configuration file, the COM port defaults to COM1.

Keyword: DATE_SEPARATOR
-----------------------
This keyword can be used to change the date separator character
when used in conjunction with Keyword: SHOW_IDLE_TIME.

By default the date separator is the slash (/). It can be changed to the
dash (-) or period (.)

The keyword is specified as follows:

DATE_SEPARATOR = -

The only valid choices are the slash (/), dash (-) or the period (.)

Keyword: DEVICE
---------------
This keyword specifies which device the Client will be running on - in the
same way that the -D command line parameter does. The keyword is specified
as follows:

DEVICE = PTC960

The valid choices for device are the same as for the -D parameter. Please
refer to the description of the -D parameter in the earlier section
Common Command Line Parameters for the Client.

If both the command line parameter -D and this DEVICE keyword are used, the
command line parameter takes effect.

Keyword: DONT_CHANGE_SCREEN_SIZE
--------------------------------
This keyword tells the Client not to change the screen size when starting
up or showing the menus. For many devices supported by the Client, the
Client already knows not to change the screen size. Among these are the
MAXILAN, PTC960 and FMT10X0. But if the -D command line parameter or
DEVICE keyword is not being used and you find that the Client changes the
screen size inappropriately, use the following keyword in EMULAOTR.INI
to tell the Client to leave the screen size as is:

DONT_CHANGE_SCREEN_SIZE = Y

The Client normally changes the screen size for devices that have larger
screens in order to maximize the use of those screens. For example, the
JANUS2050 defaults to an 80 column screen. Because the Client only uses
up to 40 columns, it switches to 40 column mode so that the entire width
of the screen is used.

However, the command used by the Client to change the screen size does not
work properly on all devices. In these cases it may be necessary to
use the DOS 'MODE' command or a terminal specific utility to set the screen
size appropriately before the Client is started. At the same time, the
DONT_CHANGE_SCREEN_SIZE keyword must be used to let the Client know that
the screen size is already set as it should be.

Keyword: ENABLE_MENU_SHORTCUTS
------------------------------
This keyword tells the Client to allow the @ key to be a short cut key to
jump immediately to the Start Stepping page in the menus and to allow
the # key to jump immediately to the View User Vars page in the menus.
Use the following in EMULATOR.INI to enable these shortcuts:

ENABLE_MENU_SHORTCUTS=Y

Note: In version 3.0.8i of the Client, the @ and # were first made available
as menu short cuts and the default behavior of the Client was that these
short cut keys were always enabled. In version 3.0.8o the default behavior
was changed to disable these menu short cut keys - and only enable them if
this keyword was used.

Keyword: FILE_PAGING
--------------------
This keyword is used to specify that some of the files that are downloaded
to the Client be paged in and out of memory as necessary rather than all
being loaded into memory at once.

When file paging is in effect, the Client requires less available memory to
run transaction programs. Not all downloaded files are paged; only
transaction programs and validation files are paged. The paged files are
stored on the terminal's disk drive (or equivalent) during a download. Then
as transaction programs are run and local validation files are required,
they are loaded from the files on disk. If there is not enough memory to
load a particular file, some that are already in memory will be unloaded
and an attempt to load will be made again.

To enable file paging, add the following keyword to EMULATOR.INI:

FILE_PAGING = Y

If you specify 'Y' then the paged files are written to the current directory,
which is the same directory in which the Client looks for EMULATOR.INI. You
can specify a different directory for the paged files by substituting the
directory path for the 'Y'. For example, to have paged files written to the
directory D:\PAGEFILE, put the following keyword to EMULATOR.INI:

FILE_PAGING = D:\PAGEFILE

The name used for paged validation files is exactly the same name that they
are downloaded as (e.g. BADGES.VAL, GRPTXNS.VAL, ...). All transaction
programs are stored in a single page file called FILE0.DAT.

IMPORTANT NOTE: If FILE_PAGING is in effect and a CFR is in use that
calls the API DataFile(), then any validation file referenced by the
DataFile() API cannot be paged. This is done with the LOCK_IN_MEMORY keyword.
For more information, please see Keyword: LOCK_IN_MEMORY.

The LOCK_IN_MEMORY keyword can also be used to lock
in memory frequently used transaction programs so that they are not constantly
swapped in and out of memory.

Keyword: FULL_SCREEN
--------------------
This keyword, which is valid only for Windows CE devices, is used to tell
the Client to run in "full-screen" mode.

Note 1: Originally this function was valid only on Pocket PC / Windows Mobile devices
because the Client used a special Pocket PC API to hide the various buttons and
tool bar. However, as of version 2.10, this option can be used on any Windows
CE device because the buttons and task bar are now identified by their
system name in order to hide them.

Note 2: As Windows CE / Mobile has evolved, the effectiveness of this option
has diminished with regard to what is actually accessible outside of the Client.
Rather than trying to keep up with these evolving changes we now rely on the
device manufacturers to provide "lock-down" tools.

Note 3: For many Symbol / Motorola / Zebra devices which have Windows CE and
not Pocket PC / Windows Mobile installed, Symbol provides an application called
AppCenter which can be used to 'lock down' (aka run in 'full screen' mode) any
application, including the DCConnect Client. It is recommended that AppCenter
be used where available as it is tailored for specific Symbol devices. As of
November 2006, this was freely available from Symbol's Developer Zone web
site: devzone.symbol.com.

Note 4: Similarly for many Intermec / Honeywell devices, Intermec offers an
application called iLaunch which, like AppCenter, helps to restrict the user's
access to a limited set of applications.

In "full-screen" mode, the terminal user is locked out from accessing
any other application while the Client is running. The following things
are done to accomplish this:

- The Start button is hidden
- The Taskbar is hidden
- The Software Input Panel button (aka pop-up keyboard) is hidden on Pocket
PC Devices. And since the Software Input Panel is hidden, the Client adds
an A-Z button to its command bar. The A-Z button allows the user to toggle
whether or not the software keyboard is showing.
- Also, on the Intermec 700 terminal, the orange-shifted keys A1 through A4
are disabled while the Client is running. These are normally set up to
start certain applications such as Notes and Calendar.

The disabling of these keys is actually done during the loading of a
special DLL called ETSUSER.DLL that the Client will try to load when the
FULL_SCREEN keyword is in effect. In ETSUSER.DLL, the function
_DllMainCRTStartup is called when the DLL is loaded. The default
version of this .DLL that is built for the Intermec 700 has code
in this function to clear certain registry values in order to
disable the A1-A4 keys. The same function is called when the Client
shuts down which allows the restoration of the registry settings for
these keys - thus reenabling them to start applications.

The source for ETSUSER.DLL: ETSUSER.C and ETSUSER.DEF along with
make files, is available where the DCConnect Client is installed
(e.g. C:\DCCONN\DCCLIENT). This gives customers the ability to
change what is done to the terminal during startup and shutdown of
the Client - in case other things need to be disabled/enabled.

Note: ETSUSER.DLL is the same .DLL used by the Client to find functions
defined by the MENU_ITEM keyword. For more details, please see
Keyword: MENU_ITEM.

The keyword to put the Client in full-screen mode is specified as follows:

FULL_SCREEN = Y

When in full screen mode, you will probably also want to password
protect the menus so that the terminal users must know the proper
password in order to be able to shut down the Client. Enabling a
menu password is done using the MENU_PASSWORD keyword which is
described in Keyword: MENU_PASSWORD.

Keyword: HIDE_MENU_BAR
----------------------
This keyword, which is valid only for Windows CE devices, is used to tell
the Client to not show the Menu Bar that has the File, Diagnostic and About
pull-down menus. This frees up more space in the Client window - which is
especially useful for Windows CE devices such as the Intermec CK30 where
screen real estate is at a premium.

The keyword to tell the Client to hide the menu bar is specified as follows:

HIDE_MENU_BAR = Y

When the menu bar is hidden, the Client menus can be brought up using the
same methods that are available on the DOS and Windows flavors of the Client:
using the Home, question mark or equal keys. The MENU_KEY keyword can also
be used in EMULATOR.INI to override these keys with a different one. For
more details please see Keyword: MENU_KEY.

Keyword: IDLE_DELAY_MIN_AND_MAX
-------------------------------
This keyword, which is not valid for DOS platforms, allows for the tuning of the
DCConnect Client idle delay cycles to influence its performance and the affect
that has on battery life. The idle delay is used in the cooperative multi-tasking
scheme that the client uses when switching between the various threads of
execution. Two different values are provided.

The 'max' value is used for situations where the client is waiting for input and
therefore should maximize its idle delay and use less processing power. For
example, while waiting for a transaction program to be started or waiting for
keyboard / scan input.

The 'min' value is used for all other situations in order to maximize performance,
such as when downloading files from the server or processing a sequence of commands
in a transaction program.

The format of this command is:

IDLE_DELAY_MIN_AND_MAX = nnn, xxx

where both 'nnn' and 'xxx' are values from 0 to 100 representing a unit of time,
which is in milliseconds for all currently supported platforms: Windows, Windows CE
and Android devices. If this keyword is not provided, the default values are:

IDLE_DELAY_MIN_AND_MAX = 0, 1

A value of 0 indicates the thread will only wait as long as other threads have
work to do; if no other threads have work to do, the thread that was in control
will immediately resume its processing.

Keyword: IGNORE_ARROW_KEYS
--------------------------
This keyword can be used to disable the ability to use the arrow keys to scroll
the Client screen. By default the arrow keys can be used to change what part
of the 20x40 virtual Client screen is currently visible in the terminal's
viewport (the physical screen). For example, with a 16x20 viewport like the
Antares 2425 has, the initial view is of rows 1-16 and columns 1-20 of the
virtual 20x40 Client screen. Pressing the right arrow moves the
viewport over half a screen so that rows 1-16 and columns 11-30 are visible.

Sometimes it is not desirable for the terminal user to be able to move the
screen - particularly if there will never be any data to viewed that is
outside the physical viewport. In these cases you may want to disable the
arrow keys so that users don't accidently scroll the screen to the point
where it is blank - which can lead them to mistakenly think something is
wrong with the terminal.

To disable the arrow keys, add the following keyword to EMULATOR.INI:

IGNORE_ARROW_KEYS = Y

In order to use this keyword, you must have version 1.40S or later of the
DCConnect Client.

Note: Even if the Client is ignoring the arrow keys, the actual terminal
hardware might have a way to scroll the physical screen that can't be
disabled by the Client - although there might be a way to disable this
way of scrolling by changing the terminal's hardware configuration. For
For example, the Janus 2020 uses the Function key in conjunction with the
arrow keys as a way to scroll the viewport. Whether these are enabled is
specified in the Janus configuration file JANUS.INI - which is set up
using the IC.EXE utility. On this terminal, the use of IGNORE_ARROW_KEYS
(or lack thereof) only dictates what happens when the arrow keys are
pressed without the Function key being pressed first.

The handling of the arrow keys by the Client can also be turned on and
off using the CFR API KbdHandleArrowKeys. Using a CFR to do this would
only be necessary if handling of the arrow keys should be disabled
temporarily rather than all of the time. For information about this and
and other CFR APIs, please refer to the:

7524 Extended Terminal Services / DCConnect Client Technical Reference.

Keyword: IGNORE_KEY
-------------------
This keyword, which is not valid for DOS platforms, can be used to tell the
DCConnect Client to ignore one or more keys, informing the operating system
that the application will not act on it.

The format of this command is:

IGNORE_KEY = nnn

where 'nnn' is the decimal ASCII value for the key code to be ignored (1-255).
For example, to ignore the [ key (ASCII 91) use the following statement:

IGNORE_KEY = 91

The key code to ignore can also be an extended ASCII code. To specify that a
code is actually an extended code, precede the ASCII decimal value with
an x (upper or lower case). So to ignore the F1 key (extended ASCII 59):

IGNORE_KEY = x59

Keyword: IGNORE_UNDERLINE
-------------------------
This keyword should be used when characters that are supposed to use
the underline attribute do not show up properly. This can happen when
a device does not support the underline attribute. The LXE MX2 (same
as the PSC/Percon Falcon 345) is one such device.

In order to tell the Client not to use the underline attribute anywhere,
add the following keyword to EMULATOR.INI:

IGNORE_UNDERLINE = Y

The Client tries to use the underline attribute for the menu titles and
it's possible that the transaction programs that are loaded to the device
will be using underlining for certain text. For some devices, the
underlined titles and text will be shown properly with the underlines,
for other devices the titles and text will be shown in a slightly modified
intensity.

However for other devices the menu titles and underlined text will not show
up at all. For these devices, the IGNORE_UNDERLINE keyword must be used.

Keyword: KEY_CLICK
------------------
This keyword can be used to turn on the keyboard key click sound on most terminals.
The keyword is specified as follows:

KEY_CLICK = Y

If the keyword is not used, the Client default keyboard setting is no key click
sound.

This keyword is not valid for Antares terminals.

Note: On some devices, there are hardware settings that can turn on/off a
key click outside of the control of the Client. The Antares terminals have
a hardware setting to control the key click.

Keyword: KEYPAD_FONT_SIZE
-------------------------
This keyword can be used to override the default sizing of the text on keypad labels for
Android devices. By default, the keypad label text is automatically resized to maximize
its size relative to the button size; so this keyword should not typically be needed.

There are 4 font sizes that can be specified, based on the number of characters in the
label. Keypad labels should be no more than 4 characters for readability. The first
font size specified is for 1 character labels, the second is for 2 characters labels, ...

The font size can be a number from 1-512 indicating a relative size but it does not
represent any specific pixel size; so it will likely require trial and error to determine
the ideal size. A larger number is a larger font.

The keyword is specified like the following example:

KEYPAD_FONT_SIZE = 32, 16, 10, 8

which will set the font size for 1 character labels to 32, the font size for 2 character
labels to 16, the font size for 3 character labels to 10 and the font size for 4 character
labels to 8.

Keyword: KEYPAD_KEY
-------------------
This keyword, which is valid only for Android devices, is one of several
parameters used to define an on-screen keypad. Please see Android Keypad
for an overall discussion.

The KEYPAD_KEY keyword is used for each key in the keypad to define its label and
the ASCII code or extended ASCII code that should be generated when that key is
pressed..

The format of this command is

KEYPAD_KEY label, nnn

The first parameter is the label that will appear on the key; this can be more than
one character if desired (e.g. Esc or Ent). Note that a blank is not allowed for the
label; so if a space is intended to be generated use something like Sp or Spc for the
label.

The second parameter, 'nnn' is the decimal ASCII value for the key code to be generated
when the key is pressed (1-255). For example, to generate a zero chararacter (ASCII 48)
use the following statement:

KEYPAD_KEY = 0, 48

The key code can also be an extended ASCII code. To specify that a code is actually an
extended code, precede the ASCII decimal value with an x (upper or lower case). So to
generate a left arrow key (extended ASCII 75), use the following statement:

KEYPAD_KEY = <, x75

Here is a sample set of 12 keys defined for the numbers 0-9 and the left and right
arrow keys:

KEYPAD_KEY = 1, 49
KEYPAD_KEY = 2, 50
KEYPAD_KEY = 3, 51
KEYPAD_KEY = 4, 52
KEYPAD_KEY = 5, 53
KEYPAD_KEY = 6, 54
KEYPAD_KEY = 7, 55
KEYPAD_KEY = 8, 56
KEYPAD_KEY = 9, 57
KEYPAD_KEY = 0, 48
KEYPAD_KEY = <, x75
KEYPAD_KEY = >, x77

Keyword: KEYPAD_NUM_KEYS
------------------------
This keyword, which is valid only for Android devices, is one of several
parameters used to define an on-screen keypad. Please see Android Keypad
for an overall discussion.

The KEYPAD_NUM_KEYS keyword specifies how many keys will be defined for the keypad - which means
it should match the number of KEYPAD_KEY definitions.

Note that typically the KEYPAD_NUM_KEY_COLS multiplied by KEYPAD_NUM_KEY_ROWS will equal the
KEYPAD_NUM_KEYS but it does not have to. For example, a 2 by 6 grid of keys could be set up to
have the 10 numeric keys and the enter key for a total of 11.

The keyword is specified as follows:

KEYPAD_NUM_KEYS = 12

Where the number can be from 1 to 100 but must match the number of KEYPAD_KEY definitions that
are in the .INI file.

Keyword: KEYPAD_NUM_KEY_COLS
----------------------------
This keyword, which is valid only for Android devices, is one of several
parameters used to define an on-screen keypad. Please see Android Keypad
for an overall discussion.

The KEYPAD_NUM_KEY_COLS keyword along with the KEYPAD_NUM_KEY_ROWS keyword specifies the layout of
the grid of keys for the keypad. Each row in the keypad will have KEYPAD_NUM_KEY_COLS keys - with
the possible exception of the last row - in the case where the total number of keys is not equal to
the number of rows multiplied by the number of columns. The width of each key is maximized, dividing
the total keypad size (defined by the KEYPAD_POSITION keyword) by the KEYPAD_NUM_KEY_COLS.

The keyword is specified as follows:

KEYPAD_NUM_KEY_COLS = 2

Where the number can be from 1 to 100.

Keyword: KEYPAD_NUM_KEY_ROWS
----------------------------
This keyword, which is valid only for Android devices, is one of several
parameters used to define an on-screen keypad. Please see Android Keypad
for an overall discussion.

The KEYPAD_NUM_KEY_ROWS keyword along with the KEYPAD_NUM_KEY_COLS keyword specifies the layout of
the grid of keys for the keypad. Each column in the keypad will have KEYPAD_NUM_KEY_ROWS keys - with
the possible exception of the last column - in the case where the total number of keys is not equal to
the number of rows multiplied by the number of columns. The height of each key is maximized, dividing
the total keypad size (defined by the KEYPAD_POSITION keyword) by the KEYPAD_NUM_KEY_ROWS.

The keyword is specified as follows:

KEYPAD_NUM_KEY_ROWS = 6

Where the number can be from 1 to 100.

Keyword: KEYPAD_POSITION
------------------------
This keyword, which is valid only for Android devices, is one of several
parameters used to define an on-screen keypad. Please see Android Keypad
for an overall discussion.

The KEYPAD_POSITION keyword specifies from which edge of the screen the keyboard will
extend and what percent of the screen it will take up, starting at that edge. All defined
keys will be arranged within this area in the grid configuration specified by the other keypad
parameters.

The keyword is specified as follows:

KEYPAD_POSITION = RIGHT, 20

This specifies that the keypad should take up the right 20 percent of the screen.

The first parameter can be one of RIGHT, LEFT, TOP or BOTTOM. Only the first letter
is needed and it is case insensitive.

The second parameter can be from 1 to 100 percent, although you actually would never
want it to take up the entire screen.

While the KEYPAD_POSITION keyword defines the location of the keypad when the Client
is started, that position can be switched to the opposite side of the screen by
using the MOVE KEYPAD option on the main menu (option 6). Each time that option is
selected it keeps switching from one side to the other. But regardless of the use
of this option, the value in the .INI file will be the one that takes effect when
the Client is started.

Keyword: LOCK_IN_MEMORY
-----------------------
This keyword is used in conjunction with FILE_PAGING to specify certain
validation files and / or transaction program IDs that should not be paged;
they should instead remain in memory at all times.

Note: support for locking transaction programs was added with version 3.0.8m.

Locking validation files
------------------------
If FILE_PAGING is in effect and a CFR is in use that calls the API DataFile(),
then any validation file referenced by the DataFile() API cannot be paged.
DataFile() returns a pointer to the start of the validation file in memory.
Once that pointer is given to the CFR, the file cannot be moved or else use of
the pointer by the CFR would not work properly. Any paged file may be
unloaded from memory and reloaded at a different location than when it
was previously loaded. Therefore validation files referenced by the
DataFile() CFR API cannot be paged.

To lock in memory the validation files EMPLGRP.VAL and GRPTXNS.VAL, add
the following keyword to EMULATOR.INI:

LOCK_IN_MEMORY = EMPLGRP.VAL, GRPTXNS.VAL

Validation file names must be specified by at least one space and/or
comma. The LOCK_IN_MEMORY keyword can be used multiple times if there
is a long list of validation files that must be locked.

Locking transaction programs
----------------------------
When FILE_PAGING is in effect, the Client tries to load into memory all the
transaction programs that are referenced (those that are started by a key press
and those that are branched to by a GOTO / GOSUB command) as it references them.
But if a new program must be loaded and there is no more memory available, the
Client will begin to unload programs (and validation files) until there is
enough memory available to load the latest referenced program. But if there
are programs that are used frequently (e.g. common subroutines stored in ADDL1,
ADDL2, ...) and frequent unloading/loading is being done, performance can be
improved by locking those programs in memory. There must be enough memory available
to fit not only these locked programs but also the largest non-locked program.
To see the sizes of transaction programs and to see which ones are currently loaded
in memory, use the DUMP MEMORY option on the Diagnostics menu.

To lock one or more programs in memory use the LOCK_IN_MEMORY keyword and then list the
numeric value (1-121) of the program key or the program name (e.g. F1, PF1, ADDL1, ...).
For example, to lock programs ADDL1 and ADDL2:

LOCK_IN_MEMORY = ADDL1, ADDL2

Possible choices for program name are the same as are used for key names in the
AKA, CALL, GOSUB, GOTO, KEY and SUB commands:

F1 - F28, (1-28)
BADGINIT, (29)
FASTCLK, (30)
PF1 - PF12, (31-42)
SPF1 - SPF12, (43-54)
RS232, RS232_2, (55,56)
DI0 - DI7, (57-64)
RES2 - RES9, (65-72)
TCH1 - TCH40, (73-112)
ADDL1 - ADDL8, (113-120)
TODCLK (121)

Mixing of validation file names and transaction program IDs in a single
LOCK_IN_MEMORY command is allowed.

This keyword is only valid if FILE_PAGING is being used. For more
information, please see Keyword: FILE_PAGING.

Keyword: LOG_COMPILE_WARNINGS
-----------------------------
Use this keyword to tell the Client, when compiling a text script, to log to
ETSPT.MSG any warning messages that occur. By default, warnings are not logged
because there can be hundreds of them and logging them can affect performance
during the download process.

The format of this command is:

LOG_COMPILE_WARNINGS = Y

Keyword: MAPPED_KEY
-------------------
This keyword is used to convert one incoming key code to another key code.
This can be useful to get around the default behavior of the keys on some
devices, especially when the device's keyboard can be remapped in the
hardware or in the operating system.

One such device is the Intermec CV30. On this device the default behavior
of keys F1 - F10 do not generate the expected key codes as seen by the
DCConnect Client. In addition, Windows Mobile 5.0 intercepts some keystrokes
to perform actions like bringing up the task list (F1) or Calendar (F2).

But the CV30 can be remapped (via the registry) to generate alternate key
codes for the F1 - F10 keys. And combining this with the appropriate key
mapping statements in EMULATOR.INI can allow the F1 - F10 keys to function
as expected.

The format of this command is:

MAPPED_KEY = abc, xyz

where 'abc' is the decimal ASCII value for the source key code (1-255) and
'xyz' is the decimal ASCII value for the target key code. For example
to map the 'A' key (ASCII 65) to the 'B' key (ASCII 66) - not that you'd
ever want to do that - use the following mapping statement:

MAPPED_KEY = 65, 66

Either the source key code or the target key code or both can be extended
ASCII codes. To specify that a code is actually an extended code, precede
the ASCII decimal value with an x (upper or lower case). So to map the
'A' key (ASCII 65) to be the F1 key (extended ASCII 59):

MAPPED_KEY = 65, x59

The normal ASCII codes can be found in many places on the internet but
finding the extended ASCII codes as well as not as common. The following
link has tables that cover both:

http://brebru.com/asciicodes.html

Keyword: MAX_TRANSACTIONS
-------------------------
As of version 2.10c of the DCConnect Client, when support of transactions
with data up to 750 bytes was implemented, this keyword is no longer
relevant. For support of the longer transactions, the logfile format was
changed so that it now stores variable length records instead of fixed
length records.

As a result, the capacity of the logfile is now specified as a number of
bytes rather than a number of transactions. Furthermore, the size of the
logfile can now be changed using the DCConnect User Interface; on the second
page of the General tab of the Terminal Settings notebook, the Buffer Size
box lets you specify the size of the logfile from 1K - 64K bytes. After
the size is changed there and saved, the terminal must be redownloaded in
order for the Client to use the new size.

Also as of version 2.10c, the Client no longer stores all transactions both
in memory and on the disk; all transactions are stored on disk but the
Client will only store in memory, the oldest transaction that has not yet
been sent successfully to the server.

The MAX_TRANSACTIONS keyword now only comes into play when the Client starts
up and finds that there is no valid transaction logfile. If MAX_TRANSACTIONS
is defined, the Client will use that value and multiply it by 131 (the old
fixed record size) in order to come up with the default size of the logfile.
If the MAX_TRANSACTIONS keyword is not defined and the logfile does not
exist, the Client will create a logfile using 1000 bytes as its size.

The rest of the discussion in this section, applies only to versions 2.10b
and earlier of the Client.

This keyword defines how many transactions can be buffered in the terminal
at one time. The value for MAX_TRANSACTIONS can be from 10-500. For example:

MAX_TRANSACTIONS = 10

If this keyword is not included in EMULATOR.INI, the default number of
transactions is 367.

If an existing logfile contains transactions that have not been sent to the
host PC and the Client is started using a MAX_TRANSACTIONS value that is
different from the capacity of the existing logfile, the old capacity will
be used for that run of the Client. A different capacity will only be
used if the existing logfile contains no transactions when the Client is
started.

Note: The actual number of transactions available is one less than the number
that is the capacity of the logfile because there is always at least
one unused record in the logfile - indicating where the last record
is. Therefore if MAX_TRANSACTIONS is set to 10, there will really only
be space for 9 transactions plus one space for the unused record.

Keyword: MENU_ITEM
------------------
This keyword, which is valid only for Windows CE, can be used to add items to the
menus. The new menus items are tied to specific functions that the user must create
in a C language DLL called ETSUSER.DLL. The keyword is defined as follows:

MENU_ITEM = Menu Text, FunctionName [, password]

where 'Menu Text' is the menu text to be included on the menu and 'FunctionName'
is the name of the function, found in ETSUSER.DLL that will be called when
the menu item is selected. The password parameter is optional. All parameters
can be up to 50 characters each - although screen size might enforce a lower actual
limit for the Menu Text. The first two parameters cannot contain commas because the
Client looks for the comma to delimit the parameters. All leading and trailing
spaces are not included. Imbedded spaces are allowed in the Menu Text but are not
allowed in the FunctionName (since it is a C function name).

The optional third parameter, password, is used to specify a special password that
must be entered by the terminal user before the function associated with this
MENU_ITEM is run. Even if the third parameter is omitted, if a MENU_PASSWORD is
defined elsewhere in EMULATOR.INI, then the terminal user must enter that password
before this MENU_ITEM is run. However, if you set the third parameter for a
particular MENU_ITEM to be NONE (upper or lower case), then the terminal user will
not be required to enter any password for this MENU_ITEM, even if a MENU_PASSWORD
is defined.

More than one MENU_ITEM can be defined at a time.

Without any menu items defined, there are 3 top level menu items defined: File,
Diagnostics and About. If any MENU_ITEM is defined, a 4th top level menu, called
'User', is added between the Diagnostics and About menu. The 'Menu Text' parameter
from each MENU_ITEM definition is listed on the 'User' submenu - in the order that
they are defined in EMULATOR.INI.

The ETSUSER.DLL that must be created by the user, must include an exported function
for each of the 'FunctionName's. The prototype for all must be the same:

int FunctionName(HWND hwnd);

The window handle that is passed in is for the DCConnect Client main client window.
Below is a simple sample that illustrates two of these functions being defined:

#include

int Test1(HWND hwnd)
{
MessageBox(hwnd,
TEXT("You have successfully called menu function 1!"),
TEXT("Menu Function 1"),
MB_OK | MB_ICONINFORMATION);
return(0);
}

int Test2(HWND hwnd)
{
MessageBox(hwnd,
TEXT("You have successfully called menu function 2!"),
TEXT("Menu Function 2"),
MB_OK | MB_ICONINFORMATION);
return(0);
}

The following EMULATOR.INI entries can be used with the above functions:

MENU_ITEM = Test First, Test1, PW1
MENU_ITEM = Test Second, Test2

Note: For the first MENU_ITEM, the user must enter PW1 before the function is run.
But for second MENU_ITEM, the user will only have to enter a password if
MENU_PASSWORD is also defined in EMULATOR.INI.

When using the Microsoft eMbedded Visual Toolkit development environment, you must
use a module definition file (.DEF) in order to have the function names exported
without any name decoration (addition of _ and @nn characters to the function name
when stored in the DLL). The following is how ETSUSER.DEF would look for the
above functions:

LIBRARY ETSUSER

EXPORTS
Test1
Test2

The default project settings were sufficient for creating a working .DLL for the
functions above.

If necessary, initialization and cleanup code can be created by including the
function:

BOOL WINAPI _DllMainCRTStartup( HANDLE hInst, ULONG ul_reason_for_call, LPVOID lpReserved);

in the .DLL. When ETSUSER.DLL is first loaded by the DCConnect Client (when parsing
EMULATOR.INI), the above function will be called by the system with the parameter
ul_reason_for_call set to DLL_PROCESS_ATTACH. And when the DCConnect Client is about
to shut down, the above function is called by the system with the paramter
ul_reason_for_call set to DLL_PROCESS_DETACH. This is the function that can be
used to include operations that must be performed in order to completely put
the terminal in and out of 'full_screen' mode. For more information about putting
the terminal in this mode, please see Keyword: FULL_SCREEN.

Keyword: MENU_KEY
-----------------
This keyword can be used to override the default keys used to get bring up the
Client menus. By default, pressing ?, = or the home key will bring up the Client
menus. However, you can use the MENU_KEY keyword to specify the decimal ASCII
value of another key to bring up the menus. If this is done, then the ?, = and
home key no longer bring up the menus. (You could actually define the MENU_KEY
to be 61 for the equal key or to be 63 for the question mark key or X71 for the
home key and only that key would bring up the menus).

The keyword is specified as follows:

MENU_KEY = 37

In this example, the decimal ASCII value of 37 is specified, indicating that
the percent sign (%) will be the only key that brings up the menus.

If an extended key such as Home, End, F1 or Insert should be the menu key then
specify X followed by the decimal value of the high order byte for the extended
key code. For example, to specify the Home key as the menu key:

MENU_KEY = X71

Do not put a space between the X and the the decimal number. The X can be upper
or lower case.

Other common extended keys are:

F1 = X59
F2 = X60
... = ...
F9 = X67
F10 = X68
Home = X71
Page Up = X73
End = X79
Page Down = X81
Insert = X82
Delete = X83
F11 = X133
F12 = X134

Keyword: MENU_PASSWORD
----------------------
This keyword can be used to define a password that must be entered before most
menu options are allowed to be performed. The menu options that are not guarded
by the password are VERSION INFO and TXTN COUNT.

The keyword is specified as follows:

MENU_PASSWORD = abc

where 'abc' is the unencrypted password (at this time no encryption is done). The
password can be up to 7 characters in length.

Password entry is case-insenstive. Therefore, if the password is defined as shown
above, any of the following would be considered a match: ABC, abc, Abc, AbC, ...
(No, '...' does not match!).

Keyword: MODEM_DIAL_CHAR
------------------------
This keyword is valid only for the serial flavors of the Client. It is one
of 4 keyword (MODEM_????) used to configure the Client so that it can
make a dial-up connection to the DCConnect Server.

The MODEM_DIAL_CHAR keyword specifies which key on the terminal is to be
used to initiate the dial-up process. When dial-up access has been configured,
the terminal is not normally using the serial port to communicate with the
DCConnect Server - which actually allows the serial port to be used to
talk to a printer or other serial device.

When it is time to upload transactions to the DCConnect Server, the terminal
must be attached to the modem and then the configured MODEM_DIAL_CHAR should
be pressed to start the dial-up process. At this point, the Client will jump
into the menus to the TXTN COUNT screen to show how many transactions are
available for upload. The terminal will then use the configured
MODEM_DIAL_STRING and MODEM_SETUP_STRING's to instruct the modem to dial-up
dial-up the DCConnect Server and then upload transactions. In addition, if
a download is queued for this terminal, it will be initiated.

When the upload and download process has completed, the Enter key can be
pressed to take the terminal out of the dial-up mode. This will cause the
Client to issue a hang-up command to the modem. Then the terminal can
be disconnected from the modem.

The keyword is specified as follows:

MODEM_DIAL_CHAR = 123

The value is the decimal value for the character. In the example above, 123 is
the left curly bracket. Pick a character that would not be part of normal
data entry (not a number, letter, period, space). It is is even better if
a shift key is required to generate the character; this reduces the chance that
it would be pressed accidentally. To make it easier for the terminal user
to remember, you might want to pick a character that is generated by one of
the shift keys and the 'D' key - ('D' for dial-up). For example:

- On a Janus or Antares 2415/2425 terminal use the left curly bracket { whose
value is 123. This is generated by pressing (Function) then 'D'

- On a 6400 terminal use the right curly bracket } whose value is 125. This is
generated by pressing (Gold shift) then 'D'

- On a Symbol LRT3840 use the forward slash / whose value is 47. This is
generated by pressing (Func) then 'D'.

- On a Telxon 960SL terminal use the bar character | whose value is 124. This
is generated by pressing (Func) then 'D'.

The MODEM_DIAL_STRING along with the MODEM_DIAL_CHAR must be configured in
order for the Client to get into dial-up mode and be able to dial the proper
phone number.

Keyword: MODEM_DIAL_STRING
--------------------------
This keyword is valid only for the serial flavors of the Client. It is one
of 4 keywords (MODEM_????) used to configure the Client so that it can
make a dial-up connection to the DCConnect Server.

The MODEM_DIAL_STRING keyword specifies the phone number for the modem to
dial. The keyword is specified as follows:

MODEM_DIAL_STRING = 9,1-123-456-7890

Up to 40 characters can be specified starting with the first non-blank
character after the equal sign going to the end of the line. Any trailing
blanks are ignored.

The MODEM_DIAL_STRING along with the MODEM_DIAL_CHAR must be configured in
order for the Client to get into dial-up mode and be able to dial the proper
phone number.

Keyword: MODEM_RETRIES
----------------------
This keyword is valid only for the serial flavors of the Client. It is one
of 4 keyword (MODEM_????) used to configure the Client so that it can
make a dial-up connection to the DCConnect Server.

The MODEM_RETRIES keyword specifies the number times the Client will try to
establish a dial up connection - if repeated attempts to send commands to the
modem receive a 'BUSY' response. The keyword is specified as follows:

MODEM_RETRIES = 3

Valid values are 0 to 5. This keyword is not required. If not provided,
the default is 1 retry.

Keyword: MODEM_SETUP_STRING
---------------------------
This keyword is valid only for the serial flavors of the Client. It is one
of 4 keywords (MODEM_????) used to configure the Client so that it can
make a dial-up connection to the DCConnect Server.

The MODEM_SETUP_STRING keyword is used to override the default strings that
are sent to the modem to initialize it. By default, the following two
strings are sent:

M1X4&R1&H0&I0
&D0

Either one or both can be changed by using the MODEM_SETUP_STRING keyword.
The keyword is specified as follows:

MODEM_SETUP_STRING = 1, M1X4&R1&H0&I0

The number before the comma specifies which string is being replaced. The
string starts with the first non-blank character after the comma and goes to
the end of the line. Each string can be up to 40 characters in length.
Trailing blanks are removed from the end of the line.

If the default setup strings are correct for your modem, this keyword does
not need to be specified.

If both strings should be replaced, the keyword should be included in
EMULATOR.INI twice - using a different string number for each definition.

Keyword: MSG_BUFFER_FULL
------------------------
This keyword specifies the text of the message to show on the terminal when
the transaction buffer is full. In the past, this text could be changed in
the menus and then saved to a configuration file for use with the -F command
line parameter.

The keyword is specified as follows:

MSG_BUFFER_FULL = No more room for transactions

The text can be up to 40 characters starting with the first non-blank
character following the equal sign. However, when this message is displayed
it is followed by the number of transactions that are buffered. So you should
allow for that value to be added to the end.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the message text from that file will override the
MSG_BUFFER_FULL parameter in EMULATOR.INI.

If the text for this message is not changed using a configuration file or this
keyword, the default text is: "Buffer full: ".

Keyword: MSG_WAITING_FOR_FILES
------------------------------
This keyword specifies the text of the message to show on the terminal when
it is first rebooted and has not yet been downloaded. In the past, this text
could be changed in the menus and then saved to a configuration file for use
with the -F command line parameter.

The keyword is specified as follows:

MSG_WAITING_FOR_FILES = Waiting for files . . .

The text can be up to 40 characters starting with the first non-blank
character following the equal sign.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the message text from that file will override the
MSG_WAITING_FOR_FILES parameter in EMULATOR.INI.

If the text for this message is not changed using a configuration file or this
keyword, the default text is: "Waiting for files".

Keyword: NUM_COLUMNS / NUM_COLS
-------------------------------
This keyword specifies the number of columns available on the the screen or
"viewport" of the device that is running the Client. This value is used
in determining where to put text when it should be right justified (such as
date/time on the status line) or centered (for menu titles). It is also used
to determine how scrolling should work. The keyword is specified as follows:

NUM_COLS = 25

Valid values are 1 through 40.

Use of the -D command line parameter of DEVICE keyword sets appropriate values
for screen row and column based on the device selected. For example, selecting
MAXILAN for the device will result in rows being set to 4 and columns being
set to 40. But if you have an 8 line MaxiLAN terminal, you will need to
use the NUM_ROWS=8 keyword in EMULATOR.INI.

In the past, you could also override the default row and column values using
the DISPLAY menu and then save them to a configuration file for use with the
-F command line parameter.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the number of columns from that file will override the
NUM_COLS parameter in EMULATOR.INI.

If the number of columns is not changed using a configuration file or this
keyword, the default value is based on the device setting in use or is set to
40 if no device is specified on the command line or in the .INI file.

Keyword: NUM_PF_STRINGS
-----------------------
This keyword defines how many PF Key Strings the Client will allocate space
for. The value for NUM_PF_STRINGS can be from 0 to 24. For example:

NUM_PF_STRINGS = 0

PF Strings in in the range 13-24 are considered the Shifted PF Strings 1-12.

If this keyword is not included in the EMULATOR.INI file, the Client
allocates space for the maximum: 24 PF Strings (@ 128 bytes each).

Note: Even if this value is set to 0, PF Keys can still be used to assign
transaction programs to and they can be used in ONKEY/ONSUB commands.

Keyword: NUM_ROWS
-----------------
This keyword specifies the number of rows available on the the screen or
"viewport" of the device that is running the Client. This value is used
in determining how much text to show on the screen when dumping trace data or
file information and in determining where the bottom of the screen is if the
status row is configured to be shown on the bottom of the screen. It is also
used to determine how scrolling should work. The keyword is specified as
follows:

NUM_ROWS = 8

Valid values are 1 through 20.

In the past, you could also override the default row and column values using
the DISPLAY menu and then save them to a configuration file for use with the
-F command line parameter.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the number of rows from that file will override the
NUM_ROWS parameter in EMULATOR.INI.

If the number of rows is not changed using a configuration file or this
keyword, the default value is based on the device setting in use or is set to
25 if no device is specified on the command line or in the .INI file.

Keyword: NUM_TOUCH_STRINGS
--------------------------
This keyword defines how many Touch Point (or Touch Region) Strings the Client
will allocate space for. The value for NUM_TOUCH_STRINGS can be from 0 to 40.
For example:

NUM_TOUCH_STRINGS = 0

If this keyword is not included in the EMULATOR.INI file, the Client
allocates space for the maximum: 40 Touch Strings (@ 128 bytes each).

Note: Neither 7524 terminals nor supported 3rd-party terminals actually have
Touch screens that the Client interfaces with. These touch point strings are
a carry over of a feature from IBM 7527 model 2 terminals which allowed
transaction programs to be started by pressing a Touch Region on the screen
and allowed input fields to be filled in with predefined strings for each
region on the screen. The Client does not support the ability to detect a
region being pressed but it does allow storage of the predefined data for
the strings that were associated with each region.

Keyword: PF_AUTO_ENTER
----------------------
This keyword is used to tell the Client to assume an Enter key has been
pressed after any PF Key is pressed for a READ command for which PF Key
input is allowed. The user, therefore, does not have to press Enter to
complete the field.

To turn on this feature, use the following keyword in the .INI file:

PF_AUTO_ENTER = Y

When this keyword is in effect, the Client assumes the pressing of the
Enter key for any active PF Key, even when the PF Key String associated
with the pressed key is 0 length.

If the READ command specifies a fixed length field and the content of the
PF Key String does not fill the field, the field will be padded out to
the fixed length when PF_AUTO_ENTER is in effect.

If you plan to use PF Key Strings for input during READ commands, be
sure the NUM_PF_STRINGS keyword specifies a value equal to or larger
than the highest PF key that will be used - or eliminate the keyword
altogether in order to activate all PF Keys.

Keyword: PF_MAPPING
-------------------
This keyword does the same thing as the PF_MAPPING option that is available
in the menus. To set PF mapping on, use the following keyword in the .INI
file:

PF_MAPPING = Y

When PF_MAPPING is on, the number keys 1-9 and 0 can perform the same
functions as PF1 through PF10 both when starting a transaction program and in
a transaction program ONKEY/ONSUB commands.

Keyword: POWER_OFF_TIMER
------------------------
This keyword is used to conserve terminal battery power consumption. The
keyword can be set to a value of from 1 to 120. This value indicates the
number of minutes the terminal should stay powered on without keyboard or
scanner activity. When there isn't any activity, the terminal will power
off and can be turned back on by pressing either the scanner trigger or
terminal power on/off button.

As an example, if you wish the terminal to power off after three minutes of
inactivity the keyword would be specified as follows:

POWER_OFF_TIMER = 3

If this keyword is not used, the default is the terminal will require manual
power off.

Note: This keyword is only valid on Symbol Spectrum24 terminals (1.40X),
Intermec 6400 terminals (1.41D), and the terminals that use
falc_tsr.exe (2.00E) which are the LXE MX2 and PSC/Percon Falcon
terminals.

Keyword: ROW_PIXEL_SPACING
--------------------------
This keyword, which is valid only for Android devices, is used to specify the
number of pixels that should be used between rows of text. This allows for more
fine tuning of the screen layout for different device hardware. If not specified,
this value is set to 6 by default. The Client takes this value into account,
along with the NUM_ROWS and NUM_COLS settings, when it determines the best font
size to use in order to fill the screen with the largest possible characters.

The range of allowable values is 0 to 100. This keyword is specified as follows:

ROW_PIXEL_SPACING = 7

Keyword: RESEND_TIMER
---------------------
This keyword specifies how long the Client waits before it resends a
transaction. When a transaction is sent to the data collection server, an
acknowledgement is expected back within some amount of time to indicate that
the server received the transaction. If a response is not received before
the time expires, the Client will automatically resend the transaction.

The resend timer for an RS-232 attachment is used differently from how it is
used for a TCP/IP attachment. It is used only when the Client has been
told it must receive the CMD K release command before transactions are removed
from the Client (the 16-bit DCC/2 runtime configured terminals this way;
the DCC/2 32-bit runtime and DCConnect do not). If configured this way, when
the Client has many transactions buffered, it will send them in order to the
server in response in response to successive polls.

The Client may send many transactions to the server without receiving the
CMD K release command. However, if the resend timer expires, the Client
will assume the server did not receive any of the outstanding transactions
and will reset its internal pointers so that the very first transaction in
the buffer will be sent to the server again on the next poll.

This keyword is specified as follows:

RESEND_TIMER = 10

Valid values are 1 through 255 seconds or use 0 to prevent transactions from
being resent.

In the past, you could change the resend timer using the menus and then save
the value to a configuration file for use with the -F command line parameter.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the timer value from that file will override the
RESEND_TIMER parameter in EMULATOR.INI.

If the number of rows is not changed using a configuration file or this
keyword, the default value is 25 seconds for the serial flavors of the
Client or 5 seconds for the TCP/IP flavors. (Prior to version 2.30d the
default for TCP/IP was 60 seconds).

Keyword: SCAN_LOOK_FOR_AIM_CODE
-------------------------------
This keyword should be used to tell the Client to look for the 3 character
AIM Symbology code in scanned data.

If the first 3 characters of the scanned data are determined to be an AIM Symbology
code (first of three character sequence is ], the ending square bracket),
then the identifier sequence will be parsed to determine the bar code type -
which is a value that is returned in the first byte of the scan data buffer
for the SenRead CFR API. The 3 character AIM code is then stripped from the
start of the scan data.

But if the AIM code it is not found, then nothing is stripped from the front of the scan data.

The keyword is specified as follows:

SCAN_LOOK_FOR_AIM_CODE = Y

This keyword is ignored for Antares terminals. For all others, this keyword
will only take effect if the SCAN_SENTINEL_CHARS keywords is also in effect.

Although SCAN_STRIP_COUNT_FRONT also handles the AIM Symbology code (if the strip
length is at least 3 and the first character is ]), it differs because that keyword
will always strip the specified number of characters from the front of the scan data
regardless of whether the AIM code is found.

Only one of SCAN_LOOK_FOR_AIM_CODE or SCAN_STRIP_COUNT_FRONT should be used. If both are
used, SCAN_STRIP_COUNT_FRONT will take precedence (if its value is > 0).

Below is a list of the AIM Symbology Identifier values that are handled, along with
the value from CFRAPI24.H that will be returned in SenRead for each. Note that there is
always a 3rd 'modifier' byte that follows the 2 byte values shown below:

]A CODE_39
]B TELEPEN_CODE
]C CODE_128
]D CODE_ONE
]d DATAMATRIX
]E UPC_A // This covers all UPC and EAN variations
]e RSS_CODE
]F CODABAR
]G CODE_93
]H CODE_11
]I I_25_CODE
]K CODE_16K
]L PDF417
]M MSI_CODE
]N ANKER_CODE
]O CODABLOCK
]P PLESSEY
]Q QR_CODE
]R S_25_CODE // 2 bar
]S S_25_CODE // 3 bar
]T CODE_49
]U MAXICODE
]z AZTEC_CODE

Keyword: SCAN_SENTINEL_CHARS
----------------------------
This keyword should be used if it is necessary to distinguish between keyboard
and scanner input or if it is necessary to better enforce the lengths of bar
codes that are allowed to be scanned. Without this keyword, the Client is
unable to tell what input came from the scanner and what was keyed in.

The keyword is specified as follows:

SCAN_SENTINEL_CHARS = 91,93

The two values are the decimal values for the start (preamble) and
ending (postamble) characters that have been configured for the
scanner input. In the example above, 91 is the left square
bracket and 93 is the right square bracket.

Note1: some of the terminals that are supported by the Client do not have the
capability to configure preamble and postamble characters. For these terminals
the SCAN_SENTINEL_CHARS keyword will not work and is therefore unsupported.

In order for this to work the terminal must be configured to have
preamble/postamble characters prepended/appended to all barcodes/magnetic
stripes that are scanned.

Any non-digit character can be used between the start and end values.

Both values must be included and they cannot be the same - otherwise the
keyword is ignored.

You should choose values for the sentinel characters that are not used by
the terminal operator - or that can't even be generated. Of course the
values specified here must match those configured as the preamble and
postamble characters using the terminal manufacturer's configuration utility.

IMPORTANT: When using this keyword, it is no longer necessary - and is in fact
incorrect - to use a carriage return as a postamble character. It
should not be used as the preamble either since this is a key that
could potentially be used by the terminal operator.

When this keyword is used, the transaction program READ (:R) command will
only accept keyboard input if the the alphanumeric or numeric keyboard device
is selected. In the past, if the sensor devices were selected, keyboard input
was also accepted; that's because in the past there was no way to distinguish
between keyboard and scanner input.

Likewise, if the READ command will only accept scanner input if the alphanumeric
or numeric device is selected for the command's parameters.

Another advantage to using this keyword is that the lengths of badges scanned
can be enforced. For fixed length reads, the badges accepted will be those
of the specified fixed length. For variable length reads, no badges will be
accepted if they exceed the maximum length.

Since the actual scan is handled by the the terminal's hardware or an
attached scanner, the terminal's scanner-related hardware will always generate
a good beep for all barcodes it can scan - even if they are not of a length
that is considered to be valid by the Client. The Client will ignore (and
discard) any barcodes that it considers to be of an invalid length; the READ
command will continue to wait for valid input.

The operation of the CFR APIs are also changed when the this keyword
is used. Without this keyword, all keyboard and scanned input had to
be read through the KbdReadAscii() API. With this keyword in effect, only
keyboard input comes in through KbdReadAscii(); you must use SenRead() to
get scanned input. Thus CFRs are now able to differentiate between keyboard
and scanned input and disallow one or the other if desired.

Keyword: SCAN_STRIP_COUNT_FRONT
-------------------------------
This keyword should be used if it is necessary to strip characters, such as
the 3 AIM Symbology Identifier characters, from the front of every bar code
that is scanned.

The keyword is specified as follows:

SCAN_STRIP_COUNT_FRONT = 3

This keyword is ignored for Antares terminals. For all others, this keyword
will only take effect if the SCAN_SENTINEL_CHARS keywords is also in effect.

The length specified can be from 1-128. If the length specified is greater
than or equal to the length of the bar code that was scanned (including imbedded
characters such as the AIM Symbology Identifier characters), then that scan
will be ignored.

Stripping of leading characters for all scanned bar codes can be useful in
the situation where a terminal is configured to include the AIM Symbology
Identifier for another application that is being run on the device and at
the same time the DCConnect Client is running on the device, thus requiring these
extra characters to be ignored.

If the stripped characters are determined to be AIM Symbology Identifier
characters (first of three character sequence is ], the ending square bracket),
then the identifier sequence will be parsed to determine the bar code type -
which is a value that is returned in the first byte of the scan data buffer
for the SenRead CFR API.

For a list of the AIM Symbology Identifier values that are handled, see the
end of SCAN_LOOK_FOR_AIM_CODE.

Keyword: SCRIPT_NAME
--------------------
This keyword is used to specify that the Client should load transaction programs and
and the rest of its configuration from the specified script text file. This feature

was completed for version 3.0.9 of the DCConnect Client and DCConnect Server. It
eliminates the need to compile transaction programs into a .PGM file using the
Data Collection Transaction Program Builder (DCTPB). Instead the Client can now
process those text (e.g. .COD) files directly. In fact the text file processing
handles not only the transaction programs but everything else that can be downloaded
to a terminal running the Client:

- CFR
- System Messages
- Validation files
- Configuration parameters found in the Terminal Settings noteboook such as BUFFERING_MODE

Because a majority of the text file content is made up of the transaction programs and
the DCTPB manual has been used to document transaction program commands, that manual has
been updated to describe the additional commands that constitute a full text file download -
rather than adding all of that reference material to this document.

With the ability to read text files directly, the Client now has the following benefits:

- After a download of text files (and optional CFR, validation files, ...) from the Server
to the Client is received, all of those files are stored locally. That way when the
Client is stopped and restarted it can load those files immediately without having to
wait to have them downloaded from the server.

There is a new version command that can be added to one of the text files which the
server and client can use to determine if they both have the same set of files and
can therefore avoid the download process.

The client also has a mechanism to determine if it has a partial or complete download
from the server. If the client is stopped in the middle of a download, the next time
it is restarted, it will detect that the local files are not a complete download and
it will therefore request a new download from the server.

- Because the text files are read directly by the client, it knows the variable and
parameter names and can display more meaningful trace information when running in
stepping mode, writing to the command log or display the contents of variables/parameters
on the VIEW USER VAR screen.

- Support added for multiple languages (via the new Start_Language, End_Language, Set_Language commands)
for MESSAGE prompts as well as System Messages.

- When used in conjunction with the specifing of a (sub) model for the terminal and the
CFR_FILE command's capability to be repeated for different models, the same set of text files
can be used with different models of terminals. This also means all terminals running
the same set of programs can be in the same DCConnect function group even when different
CFRs have to be used for different models. In the past, if a different CFR was needed
for different terminals, they had to be in different function groups even if everything
else was the same.

- Because the Client now processes the Key command directly, no longer is it necessary
to set up the associations between keys and bindings that used to have to be done in
the Terminal Settings notebook.

Although the SCRIPT_NAME can be put into EMULATOR.INI or its equivalent -S can be
specified on the command line, the normal use for SCRIPT_NAME parameter is for the
server to put it into MASTER.INI and then download that MASTER.INI, the specified
script file, the CFR and any others to the Client. When the download completes, the
Client reads MASTER.INI and then loads the script file specified by the SCRIPT_NAME
parameter - along with all of its references.

The keyword is specified as follows:

SCRIPT_NAME = SCRIPTS.TXT

Keyword: SELECT_FONT
--------------------
This keyword, which is valid only on Windows CE devices, is used to specify a
particular font to be used for the display. While not enforced, it is highly
recommended that a fixed-pitch font such as Courier be specified. If this keyword
is not used, the Client asks the operating system for a list of available fixed-pitch
fonts and it uses the first one in the list.

If the specified font name is not found, then the Client acts as if the keyword were
not specified, using the first fixed-pitch font from the list provided by the operating
system.

The keyword is specified as follows:

SELECT_FONT = Lucida Console

Capitalization of the font name is not important. However, if the font name contains
spaces, be sure to use the correct number of spaces. In the example above, there must
be exactly one space between "Lucida" and "Console".

In addition to specifying the keyword in the EMULATOR.INI file, it may be necessary
to copy the appropriate font file to the terminal's \Windows\Fonts directory. For
example, the font file for "Lucida Console" is LUCON.TTF. Using Active Sync this file
can be transferred directly from a Windows NT/2000 PC's \winnt\fonts directory to the
terminal's \Windows\Fonts directory. A better method to transfer the font file to the
terminal would be to include it in the DCConnect Client .CAB file. Please see,
Building a .CAB File to Install the Client on a Windows CE Device.

You can verify that the Client is using the font you specified by using the View
Settings option in the Client menus and going to the second page of settings. You
should see the setting for SELECTED FONT. Even if the SELECT_FONT keyword is not used,
the default font name in use will be shown. For more information about the View Settings
menu option please see Menus.

There is another way to use the SELECT_FONT keyword when you are not sure what fonts
are available. Instead of specifying a font name, you can specify a number indicating
which font from the list of available fonts should be used. For example, specifying:

SELECT_FONT = 1

tells the Client to use the first font in the list of available fixed-pitch fonts (which
is what it does by default if this keyword is not used). If you specified:

SELECT_FONT = 3

the Client would use the 3rd font in the list of available fixed-pitch fonts.

If there are fewer fonts in the list than the number specified, the last font in the
list will be used.

In all cases, you can go to the VIEW SETTINGS menu of the DCConnect Client to find
out the name of the font being used. Once you have settled on an appropriate font, use
the name instead of the number in EMULATOR.INI.

Note: On a Windows NT/2000 PC you can view what a particular font looks like by using
Windows Explorer to explore the \winnt\fonts directory (or any other containing .TTF files)
and then double clicking on the appropriate font file. You can determine whether a
font is non-proportional or not by comparing the sizes of the lines that show the
lower and upper case letters. If the sizes of these lines is the same, the font
is non-proportional.

Keyword: SHOW_IDLE_TIME
-----------------------
This keyword is used to specify that the date and/or time be displayed on the
terminal during idle times. There are a couple of ways for specifying the
parameters for this keyword. The simplest is:

SHOW_IDLE_TIME = Y

If a simple Y is specified, this means the idle time should be shown using the
date and time formats specified in the parameters that are downloaded to the
terminal from the host software (e.g. DCConnect). Using this method, the
following things can be changed about the prompt:

- What's shown: date and time, just date, just time
- Date format: YYMMDD, MMDDYY, DDMMYY, JJJYY, YYJJJ
- Date separator: / - or .
- Time format: 12 or 24 hour
- Time separator: . or :

Prior to fix pack E for version 1.40 of DCConnect, the 7524 Terminal
Settings notebook did not include a page that allowed these options to
be changed - although the 7527 Terminal Settings notebook did have a
page for these options. If you are running fix pack E or a later
version of DCConnect, it is probably best to simply set SHOW_IDLE_TIME
to Y and then configure the format using the terminal settings notebook;
this allows you to quickly change the format in one place rather than
having to change the EMULATOR.INI file in all terminals.

Alternatively, the parameters for specifying the date and time format can be
specified along with the SHOW_IDLE_TIME keyword. In this case, the parameters
that are downloaded from the host software are ignored.

The choices for date format are:

YYMMDD MMDDYY DDMMYY JJJYY YYJJJ

the choices for time format are:

12 24

Following the equal sign you can specify one of the date formats and/or one of
the time formats. If both the date and time are to be shown, at least one
space or comma must separate the date format and the time format. Here are
some examples:

To show just the date using MMDDYY format, add the following line to
EMULATOR.INI:

SHOW_IDLE_TIME = MMDDYY

To show the date using YYMMDD and the time using 24 hour format, add the
following line to EMULATOR.INI:

SHOW_IDLE_TIME = YYMMDD, 24

To show just the time in 24 hour format, add the following line to EMULATOR.INI:

SHOW_IDLE_TIME = 24

The default date separator is the slash (/). To change the date separator, add
a line to EMULATOR.INI using the Keyword: DATE_SEPARATOR.

The default time separator is the colon (:). To change the time separator, add
a line to EMULATOR.INI using the Keyword: TIME_SEPARATOR.

The date and/or time are shown in the desired format, right-justified on
the same line that the idle prompt (e.g. Press a key) is displayed.
One space is left open to the right of the date/time so that the
cursor does not move to the next line after showing the date/time.

If this keyword is not included in EMULATOR.INI, the date and time are not
displayed.

Keyword: STATUS_ROW
-------------------
This keyword allows you to specify which row status messages such as 'Waiting
for files', 'Out of service', 'Waiting for host response', ... should be
displayed. The keyword is specified as follows:

STATUS_ROW = 8

Valid choices are 1-20, TOP or BOTTOM. TOP is the same as 1. BOTTOM means to
use the bottom of the physical screen/view port - as defined by the DEVICE or
NUM_ROWS parameter.

In the past, you could change the status row using the menus and then save
the value to a configuration file for use with the -F command line parameter.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.SER) then the status row from that file will override the
STATUS_ROW parameter in EMULATOR.INI.

If the status row is not changed using a configuration file or this
keyword, the default setting is BOTTOM.

Keyword: TCPIP_ENCRYPT
----------------------
This keyword, new in version 3.2.1, is valid only for TCP/IP flavors of the Client
that are built for Windows, Windows Mobile and Android platforms. It is used to
specify that encryption should be used by the Client to send transactions and user
variable data to the server and that the server should encrypt all user variable data
and any validation file data that it sends to the Client.

This option takes effect only if the DCConnect Server is also at version 3.2.1 or later.

The keyword is specified as follows:

TCPIP_ENCRYPT = Y

If this keyword is not specified, encryption is not used.

Keyword: TCPIP_HOST
-------------------
This keyword is not valid for the serial flavors of the Client. It is used
to specify the IP address and port number for the host data collection server
(e.g. DCConnect) - in the same way the the -H command line parameter is used.
Using this parameter causes and 'I-am-here' message to be sent to the data
collection server as soon as the Client is started - which should result in
the start of the download in a matter of seconds.

This keyword is ignored on Antares terminals because the Controler IP Address
is set in the Antares menus - or using the SETUPANT.EXE utility. For more
information about the Antares menus and the SETUPANT.EXE utility, please see
Using the Antares Menus and the SETUPANT.EXE Utility.

If the Client is not given the IP address and port number of the server,
the Client waits for the server to issue a poll to the Client's IP
address and port number before it communicates at all. Typically, the
data collection server will issue this poll once a minute unless its
configuration has changed that value.

This keyword is specified as follows:

TCPIP_HOST = 99.99.99.101, 7500

The port number value (7500 shown here) can be omitted - along with the
preceding comma. If no port number is specified, it is assumed to be 7500.

Be sure not to put any spaces around the periods in the IP address.

Starting with version 2.10 of the Client, you also have the option to
specify the hostname of the DCConnect Server instead of its IP address.
(Except for Symbol Spectrum 24 terminals such as the PDT6840, VRC6940
and WSS1040). For example, if the Windows flavor of the Client is
running on the same PC as the Server, the DCConnect server and port
could be specified as:

TCPIP_HOST = localhost, 7500

Also, starting with version 2.10 of the Client, a colon can be used
instead of the comma:

TCPIP_HOST = localhost:7500

Note: Depending on the network setup, it may be necessary to give the
fully qualified network name (hostname@domain). For example:

TCPIP_HOST = dcserver@ibm.com, 7500

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.TCP) then the value for the host from that file will override the
TCPIP_HOST parameter in EMULATOR.INI. Furthermore, if the command line
parameter -H is specified, it will override both the configuration file and the
TCPIP_HOST parameter. Therefore the TCPIP_HOST parameter will take effect only
if the the -F and -H command line parameters are not used.

Note: while there was never a place in the menus to set the host IP address
and port number, if the -H parameter was used on the command line and then
later the configuration was saved, the values specified in the -H parameter
were in fact saved to the configuration file.

Keyword: TCPIP_PORT
-------------------
This keyword is not valid for the serial flavors of the Client. It is used
to specify the IP port number that the Client will use - in the same way that
the -P command line parameter does. The keyword is specified as follows:

TCPIP_PORT = 7501

The valid choices for port number are 2000 through 9999. If a value other
than 7500 used, be sure the data collection server (e.g. DCConnect) includes
both IP address and this port number for this terminal's address in the
server configuration.

This keyword is ignored on Antares terminals because the Network Port is
set in the Antares menus - or using the SETUPANT.EXE utility. For more
information about the Antares menus and the SETUPANT.EXE utility, please see
Using the Antares Menus and the SETUPANT.EXE Utility.

If the the -F command line parameter is used to load a configuration file
(e.g. ETSCFG.TCP) then the port value from that file will override the
TCPIP_PORT parameter in EMULATOR.INI. Furthermore, if the command line
parameter -P is specified, it will override both the configuration file and the
TCPIP_PORT parameter. Therefore the TCPIP_PORT parameter will take effect only
if the -F and -P command line parameters are not used.

If no port number is specified in the .INI file, the command line or a
configuration file, the default value 7500 will be used.

Keyword: TERM_NAME
-----------------------
This keyword, which is equivalent to the -N command line option, is used to
specify the terminal name that this Client represents. It must be a name that
exists in the DCConnect Server configuration and the name is case-sensitive.

This keyword is only valid for TCP/IP flavors of the client because it allows
a client to connect to the server in the situation that the machine on which
the client is running has neither a fixed IP address nor a consistent hostname.
(This is typically the case when the client machine must first connect to a
VPN before it can contact the DCConnect Server machine). This process is known
as "terminal name resolution".

When using the TERM_NAME keyword or -N command line option it is important
that the TCPIP_HOST keyword (or its -H command line equivalent) also be
used to specify the correct address of the DCConnect Server so that
communications can be properly initiated between client and server.

Note that if terminal name resolution will be used for this terminal, then in
the DCConnect configuration for this terminal, the address should be set to
255.0.0.0 or <resolve-by-name> (optionally followed by the port number if that
is not 7500).

The keyword is specified as follows:

TERM_NAME = Warehouse1

Keyword: TERM_SUB_MODEL
-----------------------
This keyword can be used to give more information about the type of the terminal
that this Client is running on. One of the main uses of this is

The keyword is specified as follows:

TERM_SUB_MODEL = Win32

Other choices for sub model, which are defined in TRMMODEL.INI, found in the Data
directory of the DCConnect Server installation, include:

Intermec_600
Intermec_700
Intermec_5020
Intermec_6651
Intermec_CK30
Intermec_CV60
LanPoint_CE
Symbol_81xx
Symbol_90xx
Symbol_91xx
X86EMDebug

The primary use of this command is to choose the correct CFR_FILE command, when there
are multiple such commands in the scripts, each specifying a different CFR executable
for different terminal models.

Keyword: TIME_SEPARATOR
-----------------------
This keyword can be used to change the time separator character when
used in conjunction with Keyword: SHOW_IDLE_TIME.

By default the time separator is the colon (:). It can be changed to the
period (.)

The keyword is specified as follows:

TIME_SEPARATOR = .

The only valid choices are the colon (:) or the period (.)

Keyword: TIMEZONE_ADJUST
------------------------
Support for this keyword was added specifically for use when the DCConnect
Client is running in a Citrix environment and the Citrix clients are in
different timezones from the Citrix server. This support was added because
the Citrix client was not able to properly change to a timezone different
from the server and because Citrix was configured to prevent the DCConnect
Client from adjusting the actual operating system time. This keyword tells
the DCConnect Client to pretend that the time is one or more hours earlier
or later than it actually is being reported by the operating system.

The DCConnect Client adjusts the time in the following situations:

- If the SHOW_IDLE_TIME keyword is in effect, the time shown is the
adjusted time.
- The timestamp included in all transactions and validation requests is the
adjusted time.
- The time is adjusted before being returned by the CFR APIs RtcGetAsciiDate,
RtcGetAsciiTime, RtcGetDate and RtcGetTime.
- Events such as changing in and out of fast clocking intervals and any
scheduled alarms are based on the adjusted time.
- The time returned by command 7 (used by the DCConnect API
DcxQueryTermDateTime) is the adjusted time

The keyword takes a positive or negative value in the range -23 to 23,
excluding 0. This value indicates the number of hours the terminal's
time should be ahead of (positive) or behind (negative) the time on
the DCConnect Server. For example, if the DCConnect Server is in the
eastern time zone and the terminal is running on a system that is
one hour behind in the central time zone, then the following statement
should be included in EMULATOR.INI

TIMEZONE_ADJUST = -1

This keyword should not be used if the version of the DCConnect Server that
is in use includes support for time zones and the system on which the
DCConnect Client is running allows the Client to adjust the time.

Keyword: TOGGLE_BACKLIGHT_CHAR
------------------------------
This keyword is used to allow integrated use of the backlight on a Janus
terminal. (This option is not supported on any other terminal at this time).
For many terminals, such as the Antares, the keyboard has a backlight key that
is used to control the backlight; so the Client does not need to do it.

The keyword is specified as follows:

TOGGLE_BACKLIGHT_CHAR = 126, 30

The first parameter is the decimal value of the character that is used to
toggle the backlight state. In the example above, 126 is the tilde
character (~). You should pick a character that is not used for any other
purpose.

The second parameter is the backlight timeout in seconds. This is an
optional parameter. By default, the Janus uses a 10 second timeout. This
parameter may range from 1 to 60 seconds.

If the TOGGLE_BACKLIGHT_CHAR parameter is not included in EMULATOR.INI, then
the Client does not control the backlight on the Janus terminal in any way.

If it is included, the Client initializes the timeout but leaves the
backlight off - until the toggle character is pressed.

If the backlight state is off and the toggle character is pressed, the
backlight will turn on and remain on for the timeout period. Until the toggle
character is pressed again, the backlight will automatically be reactivated
when a key is pressed or whenever data is scanned (since scan data goes to the
keyboard).

If the backlight state is on and the toggle character is pressed, the backlight
will be turned off. In this state, key presses and scans will not turn the
backlight on; the toggle key must be pressed again to turn on the backlight.

Note: the Janus automatically provides a multi-character key sequence for
toggling the backlight. However, if this sequence is used, the Client will
not know about it and the description of the behavior above may no longer be
accurate.

If backlight usage is needed for the Janus, it is recommended that the
TOGGLE_BACKLIGHT_CHAR parameter be used since it provides a simpler key
sequence to toggle the backlight and it allows ordinary keystrokes to
automatically turn the backlight on after it times out - if the backlight state
is on.

Keyword: TSR_INTERRUPT
----------------------
This keyword can be used in conjunction with one of the USE_TSR_??? keywords
to tell the Client what interrupt to use to talk to the TSR (Terminate-and-
Stay-Resident interrupt handler). By default, interrupt 0x6a is used for all
devices except the Symbol 3xxx and 6xxx devices; they use interrupt 0x08.

You may find that using the default interrupt causes problems - even causing
the terminal to lock up. In this case, use the TSR_INTERRUPT keyword to tell
the Client to use a different interrupt. In addition, you will need to tell
the appropriate TSR executable to use the same interrupt by passing the
interrupt as the first parameter when the TSR executable is started.

For example, on the LXE MX2 and PSC/Percon Falcon, use of interrupt 0x6a
does not work. However, interrupt 0x63 does work. Therefore, if the EMULATOR.INI
for these terminals includes the following two statements:

USE_TSR_FOR_KEYBOARD = Y
USE_TSR_FOR_SCANNER = Y

then it must also include:

TSR_INTERRUPT = 0x63

In addition when starting falc_tsr.exe you must tell it to use interrupt 0x63
as well:

falc_tsr 0x63

This keyword was added in version 2.00D of the Client (December 2002). At that
time all of the following TSR executables were also changed to allow the default
TSR interrupt to be overridden by specifying the alternate interrupt on the
command line:

6400_tsr.exe - For Intermec 6400 terminals
falc_tsr.exe - For LXE MX2 and PSC / Percon Falcon terminals
s24_tsr.exe - For Symbol 3xxx and 6xxx terminals
t870_tsr.exe - For Telxon 870 IM terminals
telx_tsr.exe - For Telxon 960 IM and 860 IM terminals

The interrupt can be specified as either a decimal value in the range 0 to 255
or as a hex value in the range 0x00 to 0xff. If specifying in hex, the '0x' must
be part of the value - as is shown in the examples above.

Keyword: TXTN_BUFFER_WARNING_COUNT
----------------------------------
This diagnostic keyword can be used to force the Client to show the TXTN COUNT
menu whenever a new transaction is created that causes the current number of
transactions in the transaction buffer to exceed a certain value.

This can be useful in alerting the terminal user that communications with the
Server have been lost for an extended amount of time. The terminal user can
then notify a system administrator to look into the problem.

This keyword is similar to the TXTN_BUFFER_WARNING_TIMER keyword below. However,
it is more appropriate to use TXTN_BUFFER_WARNING_COUNT when transactions are
being generated quickly and it is important to find out quickly when transactions
are not being sent to the Server.

The keyword is specified as follows:

TXTN_BUFFER_WARNING_COUNT = 25

where the value can be any number greater than 0. If this keyword does not
exist or the value is set to 0, this feature is disabled.

The default behavior is for the warning also to be given for every transaction
that is generated after the count is reached.

If you want the warning to occur only when the warning count is reached, and
not for all transactions that exceed the warning count, then add a comma and
the keyword ONCE_ONLY after the value. For example:

TXTN_BUFFER_WARNING_COUNT = 25, ONCE_ONLY

If you want this warning to occur repeatedly, at an interval specified by the
count, then instead of the ONCE_ONLY keyword, you can specify REPEAT. For
example, to have the Client give a warning when the transaction buffer reaches
10, 20, 30, 40, ... transactions, put the following in EMULATOR.INI:

TXTN_BUFFER_WARNING_COUNT = 10, REPEAT

Another aspect of the TXTN_BUFFER_WARNING_COUNT being set is that a special
error transaction is generated so that it can be sent to the Server the next time
communications with the Server are reestablished. This allows an application to
capture the fact that the terminal's transaction buffer did hit the configured
warning count - albeit the error transaction is not sent until communications
are reestablished and the buffered transactions start flowing to the Server.

This error transaction is generated only once for each time that the transaction
buffer contains more than one transaction. The error transaction is generated
at the time that the first warning is shown. A second error transaction is not
generated until the transaction buffer is completely emptied out and then later
begins to fill up again, exceeding the warning level.

Both the TXTN_BUFFER_WARNING_COUNT and TXTN_BUFFER_WARNING_TIMER can be used at
the same time.

Keyword: TXTN_BUFFER_WARNING_TIMER
----------------------------------
This diagnostic keyword can be used to force the Client to show the TXTN COUNT
menu whenever a certain number of minutes has gone by during which the
transaction buffer contains more than 1 transaction.

This keyword is similar to the TXTN_BUFFER_WARNING_COUNT keyword above. However,
it is more appropriate to use TXTN_BUFFER_WARNING_TIMER when transactions are
being generated infrequently - and it could therefore take a while for the
transaction count to grow.

The keyword is specified as follows:

TXTN_BUFFER_WARNING_TIMER = 10

where the value can be any number greater than 0 indicating the number of minutes
that should elapse before an error is given.. If this keyword does not
exist or the value is set to 0, this feature is disabled.

As is the case with TXTN_BUFFER_WARNING_COUNT, another aspect of the
TXTN_BUFFER_WARNING_TIMER being set is that a special error transaction is generated
so that it can be sent to the Server the next time communications with the Server
are reestablished. This allows an application to capture the fact that the
terminal's transaction buffer did contain transactions for the configured warning
timer period - albeit the error transaction is not sent until communications are
reestablished and the buffered transactions start flowing to the Server.

Both the TXTN_BUFFER_WARNING_TIMER and TXTN_BUFFER_WARNING_COUNT can be used at
the same time.

Keyword: USE_ROOT_FOR_DOWNLOAD_FILES
------------------------------------
This keyword tells the Client to write downloaded files to the root directory.
This is intended for for devices (typically Windows Mobile devices) that use a
flash drive for persistence - which in some cases have been found to have
performance problems over time.

If you find that on a certain device the download process from the DCConnect
Server gets all the way to the end, pauses for a bit, and then starts all over
from the beginning, and this continues to cycle, you can try this keyword to see
if resolves the problem. This problem has been seen to occur with the CFR file
(e.g. DCC07500.DLL) after it is downloaded from the server and then the client is
trying to load it. If you are monitoring the download from a line trace or from
the Data Monitor, this delay is seen to occur when the "set time" command is sent.

The keyword is specified as follows:

USE_ROOT_FOR_DOWNLOAD_FILES = Y

Keyword: USE_RS232_FOR_SCANNER
------------------------------
This keyword can be used to tell the Client to look for scanner input from
the RS232 serial port. When active, the Client will turn on the serial port
any time that scanner input is accepted (for CCFR calls it is always on).

The scanner must be configured to add a single terminating character
after the bar code data. Typically this would be a single carriage return
character (decimal value of 13). The Client will buffer characters that
are read from the serial port and when it sees the terminating character, it
will place all preceding characters into the scanner buffer so that commands
like READ, FB, KB or the CFR call scanRead() can get the bar code data.

The serial port baud rate, parity, data bits and stop bits are configured
based on the RS-232 parameters that are downloaded to the terminal (DCConnect
Terminal Settings notebook -> Devices tab -> RS232 page).

Enter the keyword as follows:

USE_RS232_FOR_SCANNER = Y

to specify that a carriage return is the terminating character. To specify
a different terminating character, replace the Y with the decimal number for
the ascii value of that character. For example, to specify a line feed which
has an ascii value of 10 decimal:

USE_RS232_FOR_SCANNER = 10

When this keyword is in effect, the serial port is turned on when scanner
input is allowed and is turned off afterwards. However, you may find that
in some situations, the overhead of turning the serial port on and off has
too much of a performance impact. If this is the case, you can add a
second parameter, ALWAYSON, to tell the Client to keep the serial port on
all the time (after a download completes):

USE_RS232_FOR_SCANNER = Y, ALWAYSON

The USE_RS232_FOR_SCANNER keyword is valid for all terminals that support
the serial port.

Keyword: USE_TSR_FOR_KEYBOARD
-----------------------------
This keyword was implemented in order for the Client to be able to
differentiate between keyboard and scanner input on the PSC/Percon Falcon
(same as LXE MX2) terminals. On these devices both USE_TSR_FOR_KEYBOARD
and USE_TSR_FOR_SCANNER must be set to yes in order for the Client
to be able to be able to tell scanner input from keyboard input.

A TSR (Terminate-and-Stay-Resident interrupt handler), included with
the DCConnect Client product files, interfaces with the device hardware
using device-specific calls to get the keyboard and scanner input.
Without the TSR, all scanner data goes to the keyboard buffer and the
Client is not able to distinguish it from true keyboard input.

The keyword is specified as follows:

USE_TSR_FOR_KEYBOARD = Y

If the USE_TSR_FOR_KEYBOARD keyword is being used, then you must be sure to
to start the appropriate TSR before the Client is started (falc_tsr.exe for
the Percon Falcon / LXE MX2). Failure to do so will result in the inability
to use the keyboard or scanner while the Client is running.

Keyword: USE_TSR_FOR_RS232
--------------------------
This keyword can be used for those DOS-based devices, such as those from Telxon,
for which we provide a TSR (Terminate-and-Stay-Resident interrupt handler) to
handle RS-232 functions. Without the TSR, the Client does not work with
the serial port of these terminals, because the standard RS-232 functions
used by the Client do not work with the non-standard RS-232 functions of
the affected terminals. The keyword is specified as follows:

USE_TSR_FOR_RS232 = Y

If the USE_TSR_FOR_RS232 keyword is being used, then you must be sure to
to start the appropriate TSR before the Client is started.

For more information on using the serial port on terminals that require a
TSR see:

Serial Port Use on Symbol Spectrum 24 Terminals
Serial Port Use on the Telxon Terminal

This keyword is not valid for Antares terminals.

Keyword: USE_TSR_FOR_SCANNER
----------------------------
This keyword can be used for those DOS-based devices, such as those from Telxon,
for which we provide a TSR (Terminate-and-Stay-Resident interrupt handler) to
handle scanning functions. For the Telxon PTC870IM and Symbol Spectrum 24
terminals, this TSR is required in order to use the scanner at all.

For the other Telxon terminals, the TSR provides better scanning capabilities
such as the ability to distinguish between scanner and keyboard input. Without
the TSR, scanner input comes through the keyboard and because the Telxon
terminals do not provide the ability to configure preamble and postamble
characters, there is no way for the Client to tell the difference between
keyboard and scanner input. The keyword is specified as follows:

USE_TSR_FOR_SCANNER = Y

If the USE_TSR_FOR_SCANNER keyword is being used, then you must be sure to
to start the appropriate TSR (Telxon - TELX_TSR.EXE or T870_TSR.EXE, Symbol
Spectrum 24 - S24_TSR.EXE) before the Client is started.

The capabilities provided by the USE_TSR_FOR_SCANNER keyword are the same as
those provided by the keyword SCAN_SENTINEL_CHARS that is available for
terminals that support preamble and postamble characters. Please see
the last 5 paragraphs of Keyword: SCAN_SENTINEL_CHARS for
an explanation of these capabilities.

This keyword is not valid for Antares terminals.

Keyword: UV_POOL_SIZE
---------------------
This keyword is new with version 2.00f of the Client and it defines how much
memory is allocated for storing the contents of user variables. In the 2.00f
version, the Client no longer allocates 128 bytes for each of the 100 user
variables. Instead a pool of memory is allocated which is shared by all user
variables and local variables that contain data. If all user variables are
empty, then no space in the pool is in use - although it remains allocated.

The pool can be set to any value from 1000 to 99999 bytes. The following
example sets the user variable pool size to 5000 bytes:

UV_POOL_SIZE = 5000

If this keyword is not specified, 10000 bytes are allocated for the user
variable pool.

Although the maximum allowed for this parameter is 99999 the practical
maximum is likely to be much less, depending on the available RAM in the
device. Memory allocated for the user variable pool competes with
memory allocated for downloaded files. Therefore if the user variable
pool is too large, all files to be downloaded may not fit.

The Client keeps track of a couple of statistics about the user variable
pool which can be viewed on the VIEW USER VAR diagonstic screen in the
menus. In addition to the maximum, you can view the current amount of
free space in the user variable pool and you can view the smallest amount
that was free during the entire operation of the terminal - since last
reboot. This last value helps you to determine how much of the pool is
actually used and consequently let you know that the pool could be reduced
in size if this value is large enough.

If the user variable pool is too small, then at some point while running
your transaction programs, you'll get the message "User variable pool is
out of space." showing for a few seconds on the terminal screen and the
transaction program will be aborted with the additional message: "9812:
Download error - not enough memory available".

The user variable pool is also used to store the 'stack' that keeps
track of all levels of subroutines that have been entered as well as
all levels of nested if and else statement and blocks that have
been entered. Each level of if or block that is added to the stack
only takes up 8 bytes. Each level of subroutine that is added to the
stack takes up 17 bytes plus 8 bytes for every local variable and plus
4 bytes for every parameter.

Keyword: VOLUME
---------------
This keyword is currently only used on Windows CE devices where sound
is produced by generating .wav files. The volume parameter is used
during the generation of the .wav files to determine how loud the resulting
sound will be. It is also referred to as the 'amplitude' for .wav file.

The range of values for volume are 1-127 and if this keyword is not
used, the default volume is 16. Note: that the actual volume can vary
from device type to device type - and is also affecting by the sound/volume
settings in the device configuration.

If you find that the volume of the generated sounds is too soft or too loud,
then you can try different values for the Volume keyword. Note that the
.wav file(s) that are generated to produce sounds for different frequency
and duration combinations are generated in the same folder in which the
emulator.ini file is or the transaction log files are created.

The DCConnect Client does not delete or recreate the .wav files if they
already exist on startup. (This allows you to replace them with files
of your choosing if you wish to do so.) But this also means that you
must delete these files, if they exist, whenever you change the VOLUME
parameter in EMULATOR.INI so that the .wav file(s) can be regenerated
using the new volume value the next time the DCConnect Client is started.

The keyword is specified as follows:

VOLUME = 32

Keyboard Usage
--------------
When using the Client, the keyboard of the device has restricted
usage - similar to that of a 7524 terminal. The Client has two basic
states in which the function of the keys may differ:

- Idle mode is when a transaction program is not in progress.
- Transaction mode is when a transaction program is in progress.

When in the menus, the keys function in the same way as when in transaction
mode.

When in idle mode the following keys are active:

A-Z = Used to start the transaction programs bound to F1 through F26
, or < = Used to start the transaction program bound to F27
. or > = Used to start the transaction program bound to F28
F1-F12 = Used to start the transaction programs bound to PF1 through PF12
Home = or ? = Bring up the configuration menus.
Arrow keys = Used to scroll the view of the virtual screen if the display
size is set to anything smaller than 20x40. The arrows move
the 'view port' relative to the virtual screen. For example,
pressing the up arrow will move you closer to row 1 if row 1
is not already displayed.

When in the menus or in a transaction program the following keys are active:

Arrow keys = Used to scroll the view of the virtual screen - just as in idle mode.
Backspace = Delete data in an input field
In some places in the menus it is used to cancel an operation
Tab/Backtab = Used to move between options in the menus. Use in transaction
programs to move from field to field when doing field
navigation (NAV, INAV, ...)
Enter = Used to complete an input field or accept the information on
a menu screen.
Esc = Cancel a transaction program
End = Used in field navigation to accept the data in all input fields.
Insert = Used to fill in an input field with spaces when in a transaction
program
Delete = Used to clear an input field when in a transaction program.
F1-F12 = Function as PF1-PF12 in transactions in the following cases:
- In an ONKEY command to conditionally pass control based on a
key pressed.
- Can also be used to fill alias string text into an input field
if alias string text has been assigned to th PF Keys and if the
input field was produced by a READ command which has the PF
Keys selected as an input device.
Home = or ? = Bring up the configuration menus (if not already in them)
Space # $ %
& * + . /
0-9, A-Z = These are the valid characters that can be typed into an
entry field (the same set that 7524 terminals has available).
In certain menu options where it might be desirable to
enter other characters into a field, a method is provided by
which the ASCII value of the desired character can be entered.
PgDn,PgUp = Are available to the CFR in a transaction and can be used on
the View Settings screen.

Note: While many of the 3rd party terminals have all of the PC keys defined
that are needed by the Client, some such as the Intelligent Instrumentation
TimePoint have a more limited keyboard and thus may not be able to make
full use of the Client functions.

Android Keypad
--------------
Certain Android devices, such as the Zebra WT6000 and TC8000 and the Honeywell D75e and
CT50, have no physical keyboard and instead rely on using an on-screen Android or
manufacturer-provided keyboard for manual data entry. But in some cases, that on-screen
keyboard takes up a large percentage of the screen and/or the keys are relatively small,
making it harder to type.

For the WT6000, the default Android keyboard takes up the bottom half of the screen
and even that can be difficult to type on reliably because of the size of the keys.
Zebra provides an "Enterprise" keyboard which increases the key size but that in
turn means the keyboard takes up a greater portion of the screen - 75% or more.

Because of this and the fact that the content, size and position of the Android and manufacturer-
provided keyboards cannot be customized, the DCConnect Client provides a way to create a custom
keypad containing commonly used keys (typically 0-9, Enter, backspace, ...) that can be positioned
off to one side of the screen and sized as needed in order to give the desired balance
between key size and size of the screen content. This minimizes the need to bring
up the larger Android or manufacturer-provided keyboard.

Note: Some devices such as the WT6000 provide a couple of programmable buttons that could be set
up to function as Enter, backspace or other needed keys. If programmable buttons are available, it
is recommended that they be taken advantage of so as to minimize the number of keys that must be
included on the keypad.

The customizable keypad will be placed next to the screen content for the transaction programs; it
will not overlap that. Devices usually have one dimension longer than the other; so it is usually
best to define the keypad so that it is located where it takes more of the larger dimension than
the shorter dimension. For example, if the width is wider than the height, the keypad should be set
up on the left or right of the screen. But if the height is longer than the width, the keypad should
be set up on the top or bottom of the screen.

The keypad is defined by adding a series of KEYPAD_xxxx parameters to EMULATOR.INI:

- KEYPAD_POSITION defines which edge of the screen it will be on: right, left,
top or bottom and it defines what percent of the screen it should take up, extending
from the defined edge.
- KEYPAD_NUM_KEY_ROWS and KEYPAD_NUM_KEY_COLS define the number of rows and columns
the keypad should have. A 5 row x 2 column arrangement of keys works well for the numeric keys on the WT6000 (assuming the
Enter and Backspace keys are set up as 2 of the 3 programmable keys).
- KEYPAD_NUM_KEYS defines the number of keys that should be created - in case the grid of keys should
not be filled out. For example, the grid could be 5 x 2 but only 9 keys will be defined.
- For each key, KEYPAD_KEY defines the label text and the ASCII or extended ASCII code that
should be generated when the key is pressed.

Note: Make sure KEYPAD_NUM_KEYS is set to the actual number of KEYPAD_KEY statements. Here is one example used to
define the 10 numeric keys for a Zebra WT6000 with a keypad taking up the right 20% of the screen:

KEYPAD_POSITION = RIGHT, 20

KEYPAD_NUM_KEY_ROWS = 5
KEYPAD_NUM_KEY_COLS = 2

KEYPAD_NUM_KEYS = 10
KEYPAD_KEY = 1, 49
KEYPAD_KEY = 2, 50
KEYPAD_KEY = 3, 51
KEYPAD_KEY = 4, 52
KEYPAD_KEY = 5, 53
KEYPAD_KEY = 6, 54
KEYPAD_KEY = 7, 55
KEYPAD_KEY = 8, 56
KEYPAD_KEY = 9, 57
KEYPAD_KEY = 0, 48

And here is a sample used to put a 6x2 keypad at the bottom of a Honeywell CT50, including the 10 numeric keys plus the
Enter and Backspace keys. It takes up the bottom 20% of the screen:

KEYPAD_POSITION = BOTTOM, 20

KEYPAD_NUM_KEY_ROWS = 2
KEYPAD_NUM_KEY_COLS = 6

KEYPAD_NUM_KEYS = 12
KEYPAD_KEY = 1, 49
KEYPAD_KEY = 2, 50
KEYPAD_KEY = 3, 51
KEYPAD_KEY = 4, 52
KEYPAD_KEY = 5, 53
KEYPAD_KEY = Ent, 13

KEYPAD_KEY = 6, 54
KEYPAD_KEY = 7, 55
KEYPAD_KEY = 8, 56
KEYPAD_KEY = 9, 57
KEYPAD_KEY = 0, 48
KEYPAD_KEY = BkSp, 08

There is another keyword, AUTO_SCROLL_ROW that can be used to make sure
the current cursor position is visible when the Android / manufacturer-provided soft-keyboard
is being shown and it is obscuring a large portion of the screen content. If using a keypad defined
with the KEYPAD_xxxx parameters, the AUTO_SCROLL_ROW parameter would only be needed if all keys
that the user might need to use cannot fit on the keypad; in this case the soft-keyboard will be
needed to enter those other keys and that in turn may require auto-scrolling to be in effect if the
soft-keyboard obscures too much of the screen content.

Custom Idle Screen
------------------
Normally after the DCConnect Client is downloaded with the transaction programs and
related files, the idle screen is shown based on the Idle Menu configuration that
is configured on page 2 of the Associations tab in the Terminal Settings notebook
in the DCConnect User Interface.

However with version 2.10D and later of the DCConnect Client, there is a way to
have a transaction program called rather than showing this idle menu. This gives
the flexibility to draw a custom idle menu - one that can have dynamic information
being updated and also can give you better control of the keys that may be pressed.

To tell the Client that a transaction program should be run instead of showing the
idle menu, change the first line of the Idle Menu to include the following:

$$IdleProgram = nnn

where 'nnn' is the number of the transaction program to be started - from 1 through
121. Spaces around the equal sign are optional.

This program would be responsible for drawing the idle screen instead - just as you
might do if you were using tiered menus. Use the ONKEY or ONSUB command to wait on
user input and then branch to other transaction programs based on the key pressed.

Since you have the responsibility for drawing the idle screen, you can update
information that might change after other transaction programs are run. For example,
you could show the name of who is currently logged on.

Using the custom idle screen also solves the problem that arises when you have bound
transaction programs to keys F1-F26 (A-Z) but you don't want the user to be able
to start those programs by pressing the A - Z keys directly. Instead you want to control
access to those programs through a series of tiered menus where the user must pick an
option from 1-9 or another selected range of keys. The ONKEY / ONSUB commands will
handle that restriction.

Communications Protocol, Internal File Formats and Other Technical Information
------------------------------------------------------------------------
This document does not describe the protocols, file formats or other technical
information about the interfaces to the DCConnect Client. Because the
source code that is used to build the Client is the same as is used to
build the 7524 Extended Terminal Services flash modules, you can consult the:

7524 Extended Terminal Services / DCConnect Client Technical Reference

for technical information about the DCConnect Client.

CFR Headers, Libraries and Samples
----------------------------------
The programming tools (libraries, header files, and samples) required to
create CFRs for use with the DCConnect Client are included in the
CFRTOOLS directory where the Client is installed. You'll notice that the names of many
the files in this directory refer to the 7524 terminal. This is because DOS
flavors of the DCConnect Client and the 7524 terminal share the same source
code and thus can use the same CFRs. Windows flavors of the Client can use
the same CFR source code as well; however that source must be compiled as a
Windows DLL in order to be called by the Client after download.

For detailed information about creating CFRs, refer to the:

7524 Extended Terminal Services / DCConnect Client Technical Reference.

This reference also describes all of the APIs available.

In the CFRTOOLS directory where the Client is installed there are serveral zip files containing
CFR related tools and samples:

1) CFRUTL24.ZIP (formerly called CFR24LIB.ZIP)
------------
Note: This package is no longer included as a .ZIP file in the product. Instead its
contents are included, already expanded, into the CFRTOOLS directory
(e.g. cfrutl24.h, ibmc2\cfrutl24.lib, ...) See CFRTOOLS\CFRUTL24.RME for
a complete list of files.

This package contains a set of useful CFR functions that can be called by
your CFRs. The package includes the source, make files and libraries for
all flavors of the DCConnect Client - including Windows flavors. Refer
to CFRUTL24.RME and CFRUTL24.TXT for more details about this package. Both
of these files are included in CFRUTL24.ZIP.

2) CFRSMP24.ZIP (formerly part of CFR24.ZIP)
------------
This package contains a complete sample CFR, including useful routines
that can be used in your transaction program. The package includes the
source, make files and CFR executables for all flavors of the DCConnect
Client - including Windows flavors. Refer to CFRSMP24.RME and CFRSMP24.TXT
for more details about this package. Both of these files are included in
CFRSMP24.ZIP.

3) CFRPAN24.ZIP (formerly part of CFR24.ZIP)
------------
This package contains the Input panel CFR, which is a CFR that provides
routines for making a more sophisticated user interface on the terminal -
including pop-ups, pre-filled field, ... The package includes the source,
make files and CFR executables for all flavors of the DCConnect Client -
including Windows flavors. Refer to CFRPAN24.RME and CFRPAN24.TXT for
more details about this package. Both of these files are included in
CFRPAN24.ZIP.

For more information about building CFRs for use on 32-bit Windows systems
see the following section about "Compiling and Linking a CFR" as well as
Building CFRs for Windows 95/98/Me/NT/2000/XP/7/Server based Terminals.

For more information about building CFRs for use on Windows CE terminals
see the following section about "Compiling and Linking a CFR" as well as
Building CFRs for Windows CE Devices.

Compiling and Linking a CFR
---------------------------
The CFR writer need only write a function with a "main(function, *paramlist)"
entry point, compile with the appropriate "include" files, and link with the
apporopriate provided CFR API library (and any other libraries required) to
create a CFR program file. Compiling and linking a mode 1 or mode 2 CFR is
accomplished in the same manner.

Note: A mode 2 CFR is one that takes control of the terminal, never returning
after it is called with function 0 (terminal being put into service)
or function 2 (terminal was just powered on - 7526/7527/7524 only). A
mode 1 CFR does return from function 0 and function 2 and it is called
by a transaction program using the CCFR (;M) command. See the 7524
Extended Terminal Services / DCConnect Client Technical Reference for
more information.

There is a CFR API library provided with the DCConnect Client product for
each of the supported 'C' compilers. The Custom Function Routine libraries
contain:

o (DOS only) a special startup module to link with the CFR which provides
for parameter passing, CFR initialization, and returning control to the
Client. The CFR startup module substitutes for the normal compiler start
up module that is linked with "C" language code. For this reason, you
must arrange for the Client CFR API library to be linked first before
any other standard "C" library file which may include a suitable object
module for resolving the link.

o Object modules to link with the CFR so that it can make calls to the
DCConnect Client application program interface (API). Examples of this
API include KbdReadAscii, VioWrtCharStr and IdleManager.

When writing a CFR, the source will need to "include" the file, CFRAPI24.H, which
contains DCConnect Client API function prototypes, defined constants, and return
code defines. Also provided is CFRWIN32.H which is required when building 32-bit
Windows and Windows CE CFR DLLs. However, because CFRWIN32.H is automatically
included by CFRAPI24.H when compiling for a Windows or Windows CE platform, your
CFR source need only include CFRAPI24.H.

If you will be working with different data collection terminals that use
different operating systems (DOS, Windows CE, Windows NT/2000/XP/7/Server, ...) you will
probably need to build more than one 'flavor' of the same CFR. The sample
packages (CFRSMP24.ZIP and CFRPAN24.ZIP), described above, are good
examples of building many flavors of CFR executables (.EXE and .DLL) from
the same source. While the source is in one directory, the resulting objects
and CFR .EXE / .DLL files for each flavor are created in subdirectories with
names like IBMC2, BORLAND, WIN32, IMEC700, LANPTCE, ...

This structure is also used for the CFR API header files and libraries:

CFRAPI24.H
CFRWIN32.H
IBMC2\CFRAPI24.LIB
BORLAND\CFRAPI24.LIB
WIN32\CFRAPI32.LIB
IMEC700\CFRAPICE.LIB
LANPTCE\CFRAPICE.LIB
...

and it is used for the contents of the utility library package (CFRUTL24.ZIP)
which is included in the CFRTOOLS directory, already expanded, where the DCConnect
Client files are installed:

CFRUTL24.H
GETREC24.C
...
IBMC2\CFRUTL24.LIB
BORLAND\CFRUTL24.LIB
WIN32\CFRUTL32.LIB
IMEC700\CFRUTLCE.LIB
LANPTCE\CFRUTLCE.LIB
...

Using the Environment Variable CFRTOOLS and Others When Building CFRs
---------------------------------------------------------------------
If API and utility header files and libraries are expanded into the same
directory (e.g. C:\CFRTOOLS) and the environment variable:

CFRTOOLS

is set to point to that directory. Use the System settings from the Control
Panel to set this environment variable (it should probably go into the
System section - instead of User - so that it is accessible to all users).

Then the make files, batch and compiler project files used to build the
various flavors of a CFR can use this environment variable to locate
the header and library files. In fact, if you inspect the batch files,
make files and project files in the CFRSMP24.EXE and CFRPAN24.EXE
packages, you'll see the use of the CFRTOOLS enviroment variable.

There are a couple of other environment variables that the Windows and/or
Windows CE batch files, make files and project files use:

- WCEROOT - Set to the root directory where the Microsoft eMbedded Visual
Toolkit is installed. For example: G:\MSEmbedded30. If this
toolkit is installed, this environment variable should already
be set properly. If it is not defined, then you can define
it using the System icon in the Control Panel folder.

This variable is used in several of the provided batch files
(e.g. nmi700.bat) in order to locate compiler batch files
(e.g. evc\wce300\bin\wcearm.bat) that set up the appropriate
compiler enviroment for the different flavors of Windows CE.

- WCE40ROOT - Set to the root directory where the Microsoft eMbedded Visual
C++ 4.0 toolkit is installed. For example: G:\MSEmbedded40.
This environment variable is not set up automatically. In
fact emBedded Visual C++ 4.0 continues to use WCEROOT just
like it did in version 3.0. But if you have both versions
installed, set WCEROOT to point to the root directory for
3.0 and set WCE40ROOT to point to the root directory for
4.0.

This variable is used in several of the provided batch files
(e.g. nmck30.bat, nms90xx.bat) in order to locate compiler batch
files (e.g. evc\wce300\bin\wcearm.bat) that set up the appropriate
compiler enviroment for the different flavors of Windows CE.

- OSVERSION - Specifies which version of Windows CE (e.g. WCE300) is to be
assumed when compiling a particular flavor of an application.
This value is set within the provided batch files
(e.g. nmi700.bat) and is used by the compiler batch files
(e.g. evc\wce300\bin\wcearm.bat).

You should not need to change this value or set it up in the
System settings for Windows.

- PLATFORM - Specifies which platform (e.g. ms pocket pc) is to be assumed
when compiling a particular flavor of an application. This
variable is set and used just like OSVERSION, described above.

You should not need to change this value or set it up in the
System settings for Windows.

- MSVC32DIR - Used only when building Windows 95/98/Me/NT/2000/XP/7/Server CFRs; it
is not needed when building Windows CE CFRs. MSVC32DIR is
referenced in NMWIN2.BAT in order to locate the Microsoft
Visual C++ Compiler environment batch file, VCVARS32.BAT.

If the path to VCVARS32.BAT is already set up in your
PATH statement, then you could change the 3 batch files to
simply call:

call vcvars32

instead of:

call %MSVC32DIR%\bin\vcvars32

and then you would not have to set up MSVC32DIR.

But if vcvars32.bat is not in the path, then, like CFRTOOLS, you
must set up MSVC32DIR yourself (using the System settings in
the Control Panel). MSVC32DIR should point to the parent
directory of the \BIN and \INCLUDE subdirectories of the path
into which the Microsoft Visual C++ Compiler was installed.

Refer to the following sections for information about how to use the various
supported compilers when building CFRs:

o Using IBM C/2 Version 1.10 to Build CFRs for DOS-based Terminals
o Using Borland Turbo C++ 3.0 for DOS to Build CFRs for DOS-based Terminals
o Using Microsoft Visual C++ Version 6.0 to Build CFRs for Windows 95/98/Me/NT/2000/XP/7/Server
o Using Microsoft eMbedded Visual Toolkits to Build CFRs for Windows CE Devices

Using IBM C/2 Version 1.10 to Build CFRs for DOS-based Terminals
----------------------------------------------------------------
The following command line options are recommended when running the compiler:

cl -c -nologo -Fl -ALw -FPa -Zpe -W3 -Ox -G1s -l[path]cfr.h mycfr.c

-c suppress automatic linking

-nologo suppress logo and copyright in output stream

-Fl create object file

-ALw large model, separate stack segment, does not load DS
at each module entry point

-FPa use alternate math library

-Zpe pack structures, enables C language extensions

-W3 use warning level 3 for warning/error messages

-Ox maximum optimization

-G1s 186 instruction set, no stack checking (to make
compatible with more levels)

-l[path]cfr.h location of include file, path optional

mycfr.c CFR source file

The following command line options are recommended when running the linker:

link mycfr1+mycfr2, mycfr.exe, mycfr.map, cfrapi24.lib llibcar.lib /DO /NOD /NOI;

mycfr1+mycfr2 list of object modules

mycfr.exe output executable file name

mycfr.map output map file name

cfrapi24.lib Client CFR API library, required - supplies CFR start up
code as a minimum, plus modules for CFR APIs to interface with Client.
Be sure to use the IBM C/2 flavor of this library.

llibcar.lib Large model, combined, alternate math library for REAL
MODE of the microprocessor (do not use PROTECT MODE
libraries)

/NOI don't ignore upper and lower case

/DO arrange segments in DOS fashion

/NOD no default library usage; link only with libraries
specified on link command line

Note: You should link with a REAL MODE "C" library, not with a PROTECTED MODE
library. Also you must ensure that you are linking with the IBM C/2 flavor of
the CFRAPI24.LIB file (it's in the CFRTOOLS\IBMC2 directory where the Client
is installed) and that it is in the current directory or in the path specified
in the SET LIB= statement of your environment. It is also important to compile
and link specifying the alternate math library instead of the emulation or 8087
math libararies.

Using Borland Turbo C++ 3.0 for DOS to Build CFRs for DOS-based Terminals
-------------------------------------------------------------------------
The following command line options are recommended when running the compiler:

tcc -c -ml mycfr.c

-c suppress automatic linking

-ml Compile using large memory model

mycfr.c CFR source file

The following command line options are recommended when running the linker:

tlink mycfr1 mycfr2, mycfr.exe, mycfr.map, cfrapi24.lib cl.lib

mycfr1 mycfr2 list of object modules

mycfr.exe output executable file name

mycfr.map output map file name

cfrapi24.lib Client CFR API library, required - supplies CFR start up
code as a minimum, plus modules for CFR APIs to interface with Client
Be sure to use the Borland flavor of this library.

cl.lib Large model standard real mode library

Note: Be sure to link with the Borland Turbo C++ flavor of the CFRAPI24.LIB
library (it's in the CFRTOOLS\BORLAND directory where the Client is installed).
Also be sure it is the first library in the link list to ensure that the correct
CFR linkage and parameter passing routines are executed during CFR calls.

Using Microsoft Visual C++ Version 6.0 to Build CFRs for Windows 95/98/Me/NT/2000/XP/7/Server
---------------------------------------------------------------------------------------------
While running the DCConnect Client under Windows 95/98/Me/NT/2000/XP/7/Server, CFRs
are required to be built as Windows DLLs. CFRs built as 16-bit DOS
executables CAN NOT BE DOWNLOADED to a Client when it is running under
one of the Windows 32-bit operating systems. Also CFRs built for Windows
CE will not run on Windows 95/98/Me/NT/2000/XP/7/Server.

When building a CFR DLL for use with the DCConnect Client running
on Windows 95/98/Me/NT/2000/XP/7/Server, the only required tool is the standard
Microsoft Visual C++ 6.0 product. For information about using the
Microsoft Visual C++ tool for building DLL CFRs for this Client refer to
Building CFRs for Windows 95/98/Me/NT/2000/XP/7/Server based Terminals.

Using Microsoft eMbedded Visual Toolkits to Build CFRs for Windows CE Devices
-----------------------------------------------------------------------------
While running the DCConnect Client on a Windows CE device, CFRs are required
to be built as Windows CE DLLs. CFRs built as 16-bit DOS executables CAN NOT BE
DOWNLOADED to a Client when it is running on a Windows CE device.

Even CFRs built to run on Windows 95/98/Me/NT/2000/XP/7/Server cannot run on a
Windows CE device.

Furthermore, each different model of Windows CE device that is used may require
the use of a different flavor CFR DLL to be built. This is because Windows CE
runs on a number of different processors (e.g. X86, Strong ARM, MIPS, SH3, ...)
and there are even several different versions of Windows CE in use by different
devices. Here are some examples:

- The Intermec 600 terminal has an X86 processor and runs Windows CE 2.12
- The Intelligent Instrumentation LanPoint CE terminal also has an X86 processor
but it runs Windows CE 3.0.
- The Intermec 700 terminal has a Strong ARM processor and runs Windows CE 3.0
- The Intermec CK30 terminal has an Intel XScale processor and runs Windows CE .NET

In order for two Windows CE devices to be able to use the same CFR DLL, they
both have to have the same processor and they both have to be running the
same version of Windows CE.

Although it has not been the case to this point, some day there might even be
an issue regarding what 'environment' a particular device contains.
Different 'environments' include "Pocket PC", "Pocket PC 2002", "Handheld/PC",
"Palm-size PC", ... A Windows CE 'environment' specifies not only a
particular version of Windows CE but also certain screen dimensions and a
certain set of preloaded applications. Fortunately, when building a CFR
today, these other issues do not come into play; only the processor type
and Windows CE version matter.

The Microsoft eMbedded Visual Toolkits provide a build environment that allows
you to have a single source file and generate from it all of the different
flavors of an application based on different Windows CE versions and
different processors.

Note: The same source can also be used to build your DOS and 32-bit Windows
flavors of the CFR.

Depending on the version of Windows CE that is running on the device you will
need one or both of the two versions of the toolkit. Version 3.0 of the
Microsoft eMbedded Visual Toolkit is used for building CFRs for devices that
run Windows CE 3.x and earlier (e.g. Intermec 700, Symbol PDT81xx,
Intelligent Instrumentation LanPoint CE). However, for devices running
Windows CE .NET (4.x), version 4.0 of the Microsoft eMbedded C++
compiler is needed. The Intermec CK30, Intermec CV60 and Symbol MC90xx
terminals are in this category.

Depending on what devices you will be using, you will have to install one
or more device-specific Software Development Kits (SDKs) after installing the
appropriate MS eMbedded Visual Toolkit(s).

During the installation of the MS eMbedded Visual Toolkit 3.0 you have the option
to install several SDKs, including:

- MS Windows Platform SDK for Pocket PC
- Windows CE Platform SDK (H/PC Pro)
- Windows CE Platform SDK (Palm-size PC)

Installing these will be all that is needed to support:

- Intermec 700
- Intermec 6651
- Symbol PDT 81xx
- MS Pocket PC Emulation Environment

all of which use the Pocket PC environment. (The 'Emulation Environment'
listed above allows you to simulate a Windows CE device on the same PC
that the MS eMbedded Visual Toolkit is installed.)

The following devices have their own toolkit that must be installed
separately after the MS eMbedded Visual Toolkit(s) are installed:

- Intermec 5020 (if running Windows CE 2.11)
- Intermec 600
- Intelligent Instrumentation LanPoint CE
- Intermec CK30
- Intermec CV60

Note: Some devices such as the Symbol PDT81xx and Symbol MC9000 have
toolkits (SDKs) but the installation of these SDKs is not necessary
for building CFRs for those devices.

Once all the necessary toolkits are installed you can start to set up
a workspace and projects for building the various flavors of the
Windows CE CFR DLLs that will be needed. For information about using the
MS eMbedded Visual Toolkit for building Windows CE DLL CFRs for the Client
refer to Building CFRs for Windows CE Devices.

Latest Fixes and Enhancements
-----------------------------
For a listing of the latest fixes and enhancements that have been added to the
Client, see the README file that is included in the product or in the latest
fix pack.

The latest fix pack and its readme are available from the ERPBridge/Data
Collection website:

http://www.ibm.com/software/data/dcconnect

Follow the 'Product Downloads' link and then 'DCConnect Client'.

Using the DCConnect Client on Intelligent Instrumentation LanPoint/FactoryPoint/TimePoint Terminals
---------------------------------------------------------------------------------------------------
This section describes what additional configuration must be done when using
the DCConnect Client on one of the following Intelligent Instrumentation terminals:
LanPoint, FactoryPoint or TimePoint. Instructions for using the Intelligent
Instrumentation LanPoint Pro terminal are below in Using the DCConnect
Client with the Intelligent Instrumentation LanPoint Pro Terminal.

Note: The Intelligent Instrumentation LanPoint, FactoryPoint and TimePoint
terminals are equivalent to the following set of terminals from Symbol:
FMT1020, FMT1040 and FMT1060 terminals respectively. Previous versions of this
documentation primarily used the Symbol names of these terminals. However,
Symbol no longer resells the Intelligent Instrumentation terminals. So the
documentation has been changed to use the Intelligent Instrumentation names.

While the LanPoint, FactoryPoint and TimePoint terminals look very different
they all in fact have the same architecture and even the same screen
dimensions. Because of this they are all treated the same by the DCConnect
Client. This documentation will refer to these terminals collectively as
the xxxPoint terminals for simplicity.

For more detailed information about using LanPoint/FactoryPoint/Timepoint terminals
please refer to the following sections:

- Hardware and Software Requirements for LanPoint/FactoryPoint/TimePoint Terminals
- Drive Arrangement on LanPoint/FactoryPoint/TimePoint Terminals
- Transferring Files to a LanPoint/FactoryPoint/TimePoint Terminal
- LanPoint/FactoryPoint/TimePoint CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
- LanPoint/FactoryPoint/TimePoint Bar Code Configuration
- Using the BIOS Setup Program on a LanPoint/FactoryPoint/TimePoint
- Serial Port Use on a LanPoint/FactoryPoint/TimePoint Terminal
- Digital I/O Use on a LanPoint/FactoryPoint/TimePoint Terminal
- Starting the Client on a LanPoint/FactoryPoint/TimePoint Terminal
- Setting Up a LanPoint/FactoryPoint/TimePoint Terminal from Scratch

Hardware and Software Requirements for LanPoint/FactoryPoint/TimePoint Terminals
--------------------------------------------------------------------------------
In order to use the xxxPoint terminals, you must also get either the 1MB or 2MB
PCMCIA SRAM card. This not only includes DOS and some network and other
manufacturer-provided drivers but it also provides non-volatile storage for
transactions that are generated by the Client.

If not attaching the terminal to the DCConnect PC via the serial port, the
'PC/TCP Network Kernel for DOS' from FTP Software is required and it must be
purchased from FTP Software separately.

Drive Arrangement on LanPoint/FactoryPoint/TimePoint Terminals
--------------------------------------------------------------
The xxxPoint terminals have a single A: drive which is the PCMCIA SRAM card.
All files must be copied to this card.

Transferring Files to an LanPoint/FactoryPoint/TimePoint Terminal
-----------------------------------------------------------------
The xxxPoint terminals can be booted from a PCMCIA SRAM card that is preloaded
with DOS and low-level network drivers. Files can be copied to this SRAM card
from any PC or laptop that has support for PCMCIA SRAM cards. The xxxPoint
terminal must be configured to boot from the local drive. See the next
section for more details.

The SRAM card is referred to as drive A: in the xxxPoint terminals.

LanPoint/FactoryPoint/TimePoint CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
----------------------------------------------------------------------------------
In the discussion that follows, references are made to various files that
come from the diskettes for FTP Software's product, PC/TCP Network Kernel for
DOS. For information about where to find these files and how to copy them,
refer to Installation Hints for the FTP Software TCP/IP Stack.

Following is the CONFIG.SYS file that was used during our testing:

*1 device=a:\dos\lphimem.sys
*2 device=a:\protman.sys /i:a:\
*3 device=a:\dis_pkt.gup
*4 device=a:\lp_ndis.sys
dos=high,umb
files=20
buffers=5
stacks=9,256
lastdrive=f

A few notes about the above:

1) LPHIMEM.SYS is the extended memory manager specific to these terminals
2) PROTMAN.SYS is one of 3 network drivers. This driver is provided by
Intelligent Instrumentation in the directory A:\TCPIP\NDIS of the
Network diskette. The /i parameter gives the drive on which to find
PROTOCOL.INI, the network configuration file. Our PROTOCOL.INI
contained the following:

; this is for LANpoint, none of these items should be changed

[LP_NIF]
DRIVERNAME = LPND$$$$
MAXTRANSMITS = 10
IOADDRESS = 0x300
INTERRUPT = 5
RAMSIZE(K) = 32
IOWORDSIZE = 8

;****************;
; Protocol ;
;****************;

[PKTDRV]
DRIVERNAME=PKTDRV$
BINDINGS=LP_NIF
INTVEC=0x66

3) DIS_PKT.GUP is the second network driver, a packet driver. It comes from
diskette 3 of FTP Software's PC/TCP product.

4) LP_NDIS.SYS is the third network driver, the NDIS driver for these
terminals. This driver comes from Intelligent Instrumentation in the
directory A:\TCPIP\NDIS of the Network diskette.

Following is the AUTOEXEC.BAT file that was used during our testing:

@echo off
*1 netbind
*2 set pctcp=a:\lptcp.ini
path=a:\;a:\dos;
prompt $p$g
*3 ethdrv
*4 lpmode com2:96,n,8,1
*5 doskey

REM Set up user-defined key 1 to be the Home key
*6 echo S1D\e0\47>com2
echo S1U\e0\c7>com2

REM Set up user-defined key 2 to be the Esc key
echo S2D\01>com2
echo S2U\81>com2

REM Turn off keyboard click
echo SKC0>com2

*7 REM Uncomment the following two lines to specify the 'preamble' and
REM 'postamble' characters with which to enclose all bar code input. In
REM this example, the preamble is the '[' character and ']' is the postamble.
REM echo SPP[>COM2
REM echo SPS]>COM2

REM --- or ---

REM Uncomment the following to add carriage return to all bar code input
REM echo SEP1>com2

*8 REM Uncomment the following two lines to set up user-defined key 3 to be
REM an X key (necessary only on the TimePoint/FMT 1060).
REM echo S3D\2d>com2
REM echo S3U\ad>com2

REM Start the Client
*9 call em

A few notes about the above:

1) NETBIND.EXE establishes a connection with the network. This program is
provided by Intelligent Instrumentation in the directory A:\TCPIP\NDIS
of the Network diskette.

2) The environment variable 'pctcp' tells ETHDRV.EXE what configuration
file to use for network parameters.

3) ETHDRV.EXE is the high-level ethernet driver. It is part of FTP Software's
PCTCP product. ETHDRV.EXE uses the setting of the environment variable
PCTCP to determine what .INI file to use. LPTCP.INI must be customized
for each terminal on the network. All should be the same except for the
IP address. Below are selected sections of the LPTCP.INI that we used
during testing:

[pctcp general]
host-name = lanpoint ; Unique for each terminal
domain = bocaraton.ibm.com ; Change this for your site
... ; Other items aren't covered here

[pctcp kernel]
interface = ifcust 0
... ; Other items aren't covered here

[pctcp addresses]
domain-name-server = 99.99.99.1 ; Change this for your site

[pctcp ifcust 0]
ip-address = 99.99.99.7 ; Unique for each terminal
subnet-mask = 255.255.240.0 ; Change this for your site

For information about the possible need for entries for authentication-key and
serial-number, see Authentication Key and Serial Number Entries in the .INI file.

4) LPMODE defines the parameters for the internal COM2 port. The xxxPoint
terminals use this port to issue commands for controlling the bar code
processor, digital I/O, auxillary port and other hardware control
commands. Refer to the terminal manuals for more information.

5) DOSKEY is run to make it easier to retrieve commands through the use of the
arrow keys.

6) Several commands are sent via COM2 to define two of the user defined keys,
and to turn off the keyboard click.

NOTE it is VERY IMPORTANT that no space exist before the >COM2 and after
the characters for the command being issued.

7) These commented out lines are for defining preamble/postamble
(prefix/suffix) characters to be added to all scanned bar codes. If
the SCAN_SENTINEL_CHARS keyword is to be used in the EMULATOR.INI, then
the SPP and SPS commands must be used to set up characters to match those
that are defined with the SCAN_SENTINEL_CHARS keyword. Otherwise, the
SEP1 command should be used to force the carriage return character to be
added to all scanned bar codes.

8) The TimePoint/FMT 1060 has a limited keyboard and does not have the ?
key which is one way to get into the menus. The other way to get into
the menus is using the Home key which is defined as User Defined Key 1 in the
AUTOEXEC.BAT above. In order to end the Client, the X key must be
pressed from the Main Menu. Therefore a another User Defined Key should
be set up in the AUTOEXEC.BAT. The example shows how to set up user-
defined key 3 to be X.

9) The call to EM.BAT is the one that automatically starts the Client.

LanPoint/FactoryPoint/TimePoint Bar Code Configuration
------------------------------------------------------
When using any of the xxxPoint terminals, configuration of the bar codes is
done using commands sent to COM2. This is described in the terminal manuals.
Each bar code symbology can be enabled or disabled using these commands. By
default, all bar codes types are active. If desired, additional echo commands
could be added to AUTOEXEC.BAT to disable bar code types that should not be
active.

The preamble and postamble characters for all bar codes must also be set up
using commands to COM2. See the discussion of the AUTOEXEC.BAT above for
examples of how this is done.

Using the BIOS Setup Program on an LanPoint/FactoryPoint/TimePoint
------------------------------------------------------------------
When an xxxPoint is first powered on, you have a few seconds to press the
Enter key to activate the BIOS Setup program. During our testing, we used the
BIOS Setup program to configure the following options:

*1 - Memory Option: A (640K Conv, 256K Ext)
*2 - PCMCIA Slot: Enabled
*3 - Full Screen Display: CGA
*4 - Display Tracking: Enable
*5 - Display Tracker Mode: 2x40 CF
- Display Slowdown: Disable
- Remove CGA Snow: Disable
- Cursor Source: BIOS
- Shift State Tracking: On
- Cursor: On
- Cursor Style: Line
- Enter Setup: Enable
*6 - BOOT ROM Type: TCP/IP
- TCP/IP BOOT Option: BOOTP
- TCP/IP BOOT Protocol: Ethernet_II
*7 - BOOT Priority: Local

A few notes about the above settings:

1) Memory option B is used for 736K Conventional/128K Extended. If you
are running out of memory for the files being downloaded, it be useful
to switch to memory option B. We have not tested that so we don't know
if there are problems running that way.

2) The PCMCIA slot must be enabled to use the SRAM card.

3) We attached a CGA display during testing but that probably isn't
necessary in a customer environment. (Besides you may have trouble finding
a CGA display!)

4) Display Tracking must be enabled to show the most appropriate portion
of the virtual screen on the 2x40 display.

5) The Display Tracker Mode must be 2x40 CF (Cursor Following) in order to
show the last two most recently changed lines from the virtual screen.

6) The BOOT ROM type must be TCP/IP in order to communicate properly on the
ethernet. Likewise the TCP/IP Boot Option must be BOOTP and the TCP/IP
boot protocol must be Ethernet_II

7) Boot Priority must be LOCAL in order for the terminal to boot from the
SRAM card.

Serial Port Use on the LanPoint/FactoryPoint/TimePoint Terminal
---------------------------------------------------------------
The serial port on the xxxPoint terminals can be used by the Client to
communicate with devices such as a serial printer or scale.

The serial flavor of the Client can also be used if the terminal is to
communicate to the data collection server via the serial port instead of
over ethernet.

Digital I/O Use on the LanPoint/FactoryPoint/TimePoint Terminal
---------------------------------------------------------------
While the xxxPoint terminals have digital I/O ports, the DCConnect Client
does not currently support access to those ports from transaction programs
or CFRs.

Starting the Client on a LanPoint/FactoryPoint/TimePoint Terminal
-----------------------------------------------------------------
Since the xxxPoint has only a single drive, the Client and the file
ETSCHECK.LIC should be copied to that drive along with any configuration
file(s). If desired, all of these files could be copied to a subdirectory
instead - but they must all be in the same directory.

Regardless of the model of xxxPoint terminal that is being used, any one the
following 'device' command line parameter must be used when starting the Client:

-dLANPOINT
-dFACTORYPOINT
-dTIMEPOINT
-dFMT10x0

For more details about this and other command line parameters, see the earlier
section called Common Command Line Parameters for the Client.

Setting Up a LanPoint/FactoryPoint/TimePoint Terminal from Scratch
------------------------------------------------------------------
This section describes suggested steps to take an out-of-the-box xxxPoint
terminal and set it up so that the Client can run on it. The instructions
below assume the use of an SRAM card. Our BIOS level was 3.01.

The SRAM card as received from Intelligent Instrumentation contains the
following files:

A:\1.BAT A:\VLM\AUTO.VLM A:\VLM\REDIR.VLM
A:\2.BAT A:\VLM\BIND.VLM A:\VLM\RSA.VLM
A:\AUTOEXEC.BAT A:\VLM\CONN.VLM A:\VLM\SECURITY.VLM
A:\CONFIG.SYS A:\VLM\FIO.VLM A:\VLM\TRAN.VLM
A:\VLM.BAT A:\VLM\GENERAL.VLM A:\VLM\VLM.EXE
A:\VLM\IPXNCP.VLM
A:\DOS\DOSKEY.COM A:\VLM\IPXODI.COM A:\DEMO\ACONTROL.DAT
A:\DOS\LPHIMEM.SYS A:\VLM\LPNICE.COM A:\DEMO\TIMEDEMO.EXE
A:\DOS\LPMODE.COM A:\VLM\LSL.COM A:\DEMO\TIMELOG.DAT
A:\DOS\TED.COM A:\VLM\NDS.VLM
A:\VLM\NET.CFG
A:\ODI\IPXODI.COM A:\VLM\NETX.EXE
A:\ODI\LPNICE.COM A:\VLM\NETX.VLM
A:\ODI\LSL.COM A:\VLM\NWP.VLM
A:\ODI\NET.CFG A:\VLM\PNW.VLM
A:\ODI\NETX.EXE A:\VLM\PRINT.VLM

1) Before doing anything, copy the original contents of the SRAM card to
a safe place. For example, if the backup directory will be called
c:\lanptorg and the SRAM card is drive F:

c:
md \lanptorg
xcopy f:\*.* c:\lanptorg /s

2) As shipped the SRAM card does not leave enough space for the additional
files that must be copied on for the Client. So to make more space,
the following files can be deleted from the SRAM card:

1.BAT
2.BAT
VLM.BAT
DOS\TED.COM
all files in the ODI directory
all files in the VLM directory
all files in the DEMO directory

The empty directories can then be removed.

3) Now create a special directory on your PC for building the set of files
that will end up on the SRAM card. This will allow you to quickly
recreate the card should anything happen to its contents.

Start by copying all files from the SRAM card to this directory. For
example:

c:
md \lanptsrm
xcopy f:\*.* c:\lanptsrm /s

The above example assumes the PC sees the SRAM card as drive F: and the
directory for the set of SRAM card files will be c:\lanptsrm

4) The default AUTOEXEC.BAT contains the following:

path=a:\;a:\dos;a:\demo;a:\odi
prompt $p$g
lpmode com2:96,n,8,1

Change it to look like the one shown in the sample above in the section
LanPoint/FactoryPoint/TimePoint CONFIG.SYS, AUTOEXEC.BAT and Network Configuration.

If the serial flavor of the Client is to be used instead of the TCP/IP
flavor, then do not include the following lines:

netbind
set pctcp=a:\lptcp.ini
ethdrv

Also be sure to set up the preamble and postamble characters based on
whether or not the SCAN_SENTINEL_CHARS command will be used in EMULATOR.INI.

5) The default CONFIG.SYS contains the following:

device=a:\dos\lphimem.sys
dos=high,umb
files=20
buffers=5
rem lastdrive=z

Change it to look like the one shown in the sample above in the section
LanPoint/FactoryPoint/TimePoint CONFIG.SYS, AUTOEXEC.BAT and Network Configuration.

If the serial flavor of the Client is to be used instead of the TCP/IP
flavor, then do not include the following lines:

device=a:\protman.sys /i:a:\
device=a:\dis_pkt.gup
device=a:\lp_ndis.sys

6) If you are running the serial flavor of the Client skip this and the
next 2 steps. Otherwise copy the following files from the "Network
Drivers and Utilities" companion diskette (from Intelligent Instrumentation):

a:\tcpip\ndis\protocol.ini
a:\tcpip\ndis\lp_ndis.sys
a:\tcpip\ndis\lptcp.ini
a:\tcpip\ndis\netbind.exe
a:\tcpip\ndis\protman.sys

7) We did not have to change the PROTOCOL.INI from its default values (shown
above).

However, several changes are needed in the default LPTCP.INI.
Change it to look like the sample shown above in the section
LanPoint/FactoryPoint/TimePoint CONFIG.SYS, AUTOEXEC.BAT and Network Configuration.

8) The following files come from diskettes for FTP Software's PCTCP Network
Kernel for DOS:

ethdrv.exe
dis_pkt.gup

For more information about how to copy these files from the PCTCP product
diskettes to the directory for SRAM card files, refer the the section
Installation Hints for the FTP Software TCP/IP Stack.

9) Now copy the following files from where the Client is installed to the
directory for the SRAM card files:

ETSCHECK.LIC

If using the serial flavor of the Client:

SERIAL\ETSPB.EXE

If using the Client along with the FTP Software TCP/IP stack:

TCP_FTP\ETSPT.EXE

10) Now determine if you need to create an EMULATOR.INI file. For more about
what parameters can be set up in this file, refer to the section above
Configuration using EMULATOR.INI.

If you decide you need this file, create it in the directory for the SRAM
card files.

11) The last Client specific file to create is EM.BAT. Remember that in
step 4 above AUTOEXEC.BAT was changed to call EM.BAT at the end. This
file will have different contents depending on what flavor of the
Client you are running and what device you are using.

For all flavors, you should start with the following two lines:

a:
cd \

to make sure the Client is running from the right drive and directory.

If you are running the serial flavor of the Client, then add a line
to EM.BAT that is similar to:

etspb -aB -b19200 -dLANPOINT

Change the -a (address) and -b (baud rate) parameters as appropriate for
your configuration. You could also use -dFACTORYPOINT, -dTIMEPOINT or
-dFMT10x0 instead of -dLANPOINT.

If you are running the TCP/IP flavor of the Client, then instead add
a line to EM.BAT that is similar to:

etspt -dLANPOINT -h1.2.3.4,7500

Change the -h (host PC) parameters as appropriate for your configuration.
You could also use -dFACTORYPOINT, -dTIMEPOINT or -dFMT10x0 instead
of -dLANPOINT.

For more details about command line parameters, see the earlier section
called Common Command Line Parameters for the Client.

After the call to the Client add a call to clear the screen:

cls

This is sometimes needed to restore the display to its original state
after you exit the Client.

12) These are all of the files that can be set up from the PC. So at this time
you can copy all of the files from your directory for SRAM card files to
the actual SRAM card.

Once all files are copied, put the SRAM card into the xxxPoint terminal and
get ready to start it up.

13) When you start up the terminal for the first time, press Enter to get into
the BIOS setup and make sure the parameters are set up as described above in
Using the BIOS Setup Program on a LanPoint/FactoryPoint/TimePoint.

Once that is done and saved, let the terminal come up and make sure
everything starts up properly.

Using the DCConnect Client on Intelligent Instrumentation LanPoint Pro Terminals
--------------------------------------------------------------------------------
This section describes what additional configuration must be done when using
the DCConnect Client on the Intelligent Instrumentation LanPoint Pro terminal.
Instructions for using the Client on the Intelligent Instrumentation LanPoint,
Factory Point and Time Point terminals can be found above in
Using the DCConnect Client with the Intelligent Instrumentation
LanPoint/FactoryPoint/TimePoint Terminals.

Note: The Intelligent Instrumentation LanPoint Pro terminal is equivalent to
the FMT3000 terminal from Symbol. Previous versions of this documentation
primarily used the Symbol names of this terminal. However, Symbol no longer
resells the Intelligent Instrumentation terminals. So the documentation has
been changed to use the Intelligent Instrumentation names.

For more detailed information about using LanPoint Pro terminals please refer to the
following sections:

- Hardware and Software Requirements for LanPoint Pro Terminals
- Drive Arrangement on LanPoint Pro Terminals
- Transferring Files to a LanPoint Pro Terminal
- LanPoint Pro CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
- LanPoint Pro Bar Code Configuration
- Serial Port Use on the LanPoint Pro Terminal
- Parallel Port and Digital I/O Use on the LanPoint Pro Terminal
- Starting the Client on a LanPoint Pro Terminal
- Setting Up a LanPoint Pro Terminal from Scratch

Hardware and Software Requirements for LanPoint Pro Terminals
-------------------------------------------------------------
In order to use the LanPoint Pro terminals, you must get the 2MB PCMCIA SRAM card.
This not only includes DOS and some network and other manufacturer-provided
drivers but it also provides non-volatile storage for transactions that are
generated by the Client.

If not attaching the terminal to the DCConnect PC via the serial port, the
'PC/TCP Network Kernel for DOS' from FTP Software is required and it must be
purchased from FTP Software separately. One license of this software is
required per terminal - as is the case with the DCConnect Client.

One of the options for the LanPoint Pro terminal is a VGA card that goes into
the PC/104 expansion slot. The use of this card changes the way the terminal
handles video interrupts - which is different from the way the Client
expects the interrupts to be used. Therefore, the VGA card cannot be
installed when the Client is being used on the terminal.

Drive Arrangement on LanPoint Pro Terminals
-------------------------------------------
The LanPoint Pro terminals have a single A: drive which is the PCMCIA SRAM card.
All files must be copied to this card.

Transferring Files to a LanPoint Pro Terminal
---------------------------------------------
The LanPoint Pro terminals can be booted from a PCMCIA SRAM card that is preloaded
with DOS and low-level network drivers. Files can be copied to this SRAM card
from any PC or laptop that has support for PCMCIA SRAM cards.

The SRAM card is referred to as drive A: in the LanPoint Pro terminals.

LanPoint Pro CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
---------------------------------------------------------------
In the discussion that follows, references are made to various files that
come from the diskettes for FTP Software's product, PC/TCP Network Kernel for
DOS. For information about where to find these files and how to copy them,
refer to Installation Hints for the FTP Software TCP/IP Stack.

Following is the CONFIG.SYS file that was used during our testing:

device=keybufs.sys
buffers=40,0
files=40
dos=high,umb
fcbs=4,0
lastdrive=f

*1 device=a:\net\protman.dos /i:a:\net
*2 device=a:\net\smc9000.dos
*3 device=a:\net\dis_pkt.gup

A few notes about the above:

1) PROTMAN.DOS is one of 3 network drivers. This driver is on diskette 3 of
FTP Software's PC/TCP product. The /i parameter gives the path in which
to find PROTOCOL.INI, one of the network configuration files. Our
PROTOCOL.INI contained the following, none of which should need to be
changed:

[network.setup]
version=0x3110
netcard=smc9000,1,SMC9000,1
transport=ms$nwlink,MS$NWLINK
transport=ms$ndishlp,MS$NDISHLP
lana0=smc9000,1,ms$nwlink
lana1=smc9000,1,ms$ndishlp

[MS$NWLINK]
FRAME=ETHERNET_802.2
DriverName=nwlink$
BINDINGS=SMC9000

[protman]
DriverName=PROTMAN$
PRIORITY=MS$NDISHLP

[SMC9000]
DriverName=SMC9X$
Interrupt=0x0A
IOBase=0x300

[MS$NDISHLP]
DriverName=ndishlp$
BINDINGS=SMC9000

[pktdrv]
drivername=pktdrv$
bindings=smc9000
intvec=0x60

2) SMC9000.DOS is the second of the network drivers. This one comes from the
A:\NDIS directory of the LanPoint Pro Utilities diskette. This driver needs
the configuration file SYSTEM.INI in the A:\NET directory. Here are the
contents of the SYSTEM.INI file used in our testing:

[network]
directhost=yes
filesharing=no
printsharing=no
autologon=yes
computername=LANPOINTPRO
lanroot=A:\NET
username=LANPOINTPRO
workgroup=WORKGROUP
reconnect=yes
dospophotkey=N
lmlogon=0
logondomain=WORKGROUP
preferredredir=basic
autostart=full
maxconnections=8
maxnwsess=8

[network drivers]
netcard=smc9000.dos
transport=ndishlp.sys
devdir=A:\NET
LoadRMDrivers=yes

[Password Lists]
*Shares=A:\NET\Share001.PWL

The contents of this file should not have to be changed.

3) DIS_PKT.GUP is the last of the network drivers, a packet driver. It comes
from diskette 3 of FTP Software's PC/TCP product.

There is another driver PROTMAN.EXE which is not explicitly started in either
CONFIG.SYS or AUTOEXEC.BAT but it is started by one of the other drivers. It
therefore must also be present in the A:\NET directory in the terminal. This
driver is on diskette 3 of FTP Software's PC/TCP product.

Following is the AUTOEXEC.BAT file that was used during our testing:

*1 LDRIVER
*2 LPPINIT
*3 DISTRACK w=40

PATH a:\;a:\dos;a:\net

doskey
PROMPT $p$g

*4 PMADJUST
*5 set pctcp=a:\net\lptcp.ini
*6 a:\net\netbind
*7 a:\net\ethdrv

REM Start the Client
*8 call em

A few notes about the above:

1) LDRIVER.COM is a TSR that provides access to the various peripherals of the
hardware, including bar code configuration, digital I/O and speaker. It is
found in the root directory of the LanPoint Pro Utilities diskette. It also
comes on the 2MB SRAM card.

2) LPPINIT.COM activates some BIOS extensions for the terminal. It is also
found in the root directory of the LanPoint Pro Utilities diskette and on
the 2MB SRAM card.

3) DISTRACK.COM is a TSR program that configures how the LCD display is to
be used. The w=40 parameter above indicates the width of the screen should be
treated as 4 rows of 40 columns wide (instead of 2 rows of wrapping 80
columns). This program is also found in the root directory of the LanPoint Pro
Utilities diskette and on the 2MB SRAM card.

4) PMADJUST.COM puts the terminal in Power Management mode to help increase
the life of the battery - if one is being used. This program is also
found in the root directory of the LanPoint Pro Utilities diskette and on the
2MB SRAM card.

5) The environment variable 'pctcp' tells ETHDRV.EXE what configuration
file to use for network parameters.

6) NETBIND.COM establishes a connection with the network. This program can
be found on diskette 3 of FTP Software's PC/TCP product.

7) ETHDRV.EXE is the high-level ethernet driver. It can be found on
diskette 2 of FTP Software's PC/TCP product. ETHDRV.EXE uses the setting
of the environment variable PCTCP to determine what .INI file to use.
LPTCP.INI must be customized for each terminal on the network. All should
be the same except for the IP address. Here is the LPTCP.INI that we used
during testing:

[pctcp kernel]
interface = ifcust 0

[pctcp ifcust 0]
ip-address = 99.99.99.31
subnet-mask = 255.255.240.0
router = 99.99.99.101

For information about the possible need for entries for authentication-key and
serial-number, see Authentication Key and Serial Number Entries in the .INI file.

8) The call to EM.BAT is the one that automatically starts the Client.

LanPoint Pro Bar Code Configuration
-----------------------------------
By default, the LanPoint Pro is configured to handle any of the bar code
symbologies that it supports. To make sure the ones that you will need are
supported, consult the documentation that comes with the terminal.

Also by default, bar code input is routed through the keyboard and a carriage
return character is automatically appended to the end. Therefore nothing
special is needed for the Client to be able to read bar code input in most
situations.

However, if the terminal must be able distinguish between bar code and keyboard
input or if better enforcement of bar code lengths is required, then special
preamble and postamble characters will have to be configured and the keyword
SCAN_SENTINEL_CHARS will have to be included in EMULATOR.INI. For more about
this keyword, see Keyword: SCAN_SENTINEL_CHARS.

In order to change the default preamble and postamble characters in the
LanPoint Pro terminal, you must use the utility PREPOST.EXE which can be found
in the LANPTPRO directory where the Client is installed. This utility takes
two parameters: the decimal value of the preamble character and the decimal
value of the postamble character. These should match the same values used in
the EMULATOR.INI for the SCAN_SENTINEL_CHARS keyword (without the comma).
For example:

prepost 91 93

A line similar to this should be included in EM.BAT if the SCAN_SENTINEL_CHARS
keyword is used in EMULATOR.INI.

Serial Port Use on the LanPoint Pro Terminal
--------------------------------------------
The serial port on the LanPoint Pro terminals can be used by the Client to
communicate with devices such as a serial printer or scale.

The serial flavor of the Client can also be used if the terminal is to
communicate to the data collection server via the serial port instead of
over ethernet.

Parallel Port and Digital I/O Use on the LanPoint Pro Terminal
--------------------------------------------------------------
While the LanPoint Pro terminals have a digital I/O port and the capability
to add a parallel port, the Client does not currently support access to the
parallel port or Digital I/O from transaction programs or CFRs.

Starting the Client on a LanPoint Pro Terminal
----------------------------------------------
Since the LanPoint Pro has only a single drive, the Client and the file
ETSCHECK.LIC should be copied to that drive along with any configuration
file(s). If desired, all of these files could be copied to a subdirectory
instead - but they must all be in the same directory.

The following 'device' command line parameter must be used when starting the
Client on a LanPoint Pro terminal:

-dLANPOINTPRO

Note: You can also use the Symbol name for this terminal:

-dFMT3000

For more details about this and other command line parameters, see the earlier
section called Common Command Line Parameters for the Client.

Setting Up a LanPoint Pro Terminal from Scratch
-----------------------------------------------
This section describes suggested steps to take an out-of-the-box LanPoint Pro
terminal and set it up so that the Client can run on it. The instructions
below assume the use of an SRAM card. Our BIOS level was 3.01.

The 2MB SRAM card as received from Intelligent Instrumentation contains
the following files:

A:\AUTOEXEC.BAT A:\CARDSOFT\INTELLAN.CLB A:\MOUSE\MOUSE.EXE
A:\CONFIG.SYS A:\CARDSOFT\LINKSYS.CLB A:\MOUSE\MOUSE.LAN
A:\CUSTOM.EXE A:\CARDSOFT\LINKSYS2.CLB
A:\CUSTOM.INI A:\CARDSOFT\MCFORMAT.EXE A:\NDIS\NET.CFG
A:\DISTRACK.COM A:\CARDSOFT\MTAA.CLB A:\NDIS\OEMSETUP.INF
A:\DRVSPACE.BIN A:\CARDSOFT\MTAA.EXE A:\NDIS\PROTOCOL.INI
A:\KEYBUFS.SYS A:\CARDSOFT\MTAB.CLB A:\NDIS\SMC9000.DOS
A:\LDRIVER.COM A:\CARDSOFT\MTAB.EXE A:\NDIS\SMC9000.NIF
A:\LPPINIT.COM A:\CARDSOFT\MTDDRV.CLB A:\NDIS\SMC9000.OS2
A:\PAUSE.SYS A:\CARDSOFT\MTDDRV.EXE
A:\PMADJUST.COM A:\CARDSOFT\MTI1.CLB A:\NWCLIENT\IPXODI.COM
A:\CARDSOFT\MTI1.EXE A:\NWCLIENT\LOGIN.BAT
A:\CARDSOFT\ADAPTER.CLB A:\CARDSOFT\MTI2P.CLB A:\NWCLIENT\LSL.COM
A:\CARDSOFT\ADAPTER.EXE A:\CARDSOFT\MTI2P.EXE A:\NWCLIENT\NET.CFG
A:\CARDSOFT\ATADRV.CLB A:\CARDSOFT\MTSRAM.EXE A:\NWCLIENT\NETX.EXE
A:\CARDSOFT\ATADRV.EXE A:\CARDSOFT\PROXIM.CLB A:\NWCLIENT\SMC9000.COM
A:\CARDSOFT\ATAINIT.CLB A:\CARDSOFT\SOCKETEA.CLB A:\NWCLIENT\SMC9000.INS
A:\CARDSOFT\ATAINIT.EXE A:\CARDSOFT\SS365SL.EXE
A:\CARDSOFT\CARD_BAP.CLB A:\CARDSOFT\SSCIRRUS.EXE A:\PACKET\DIS_PKT9.DOS
A:\CARDSOFT\CARD_BAP.EXE A:\CARDSOFT\SSDETECT.EXE A:\PACKET\ODIPKT.COM
A:\CARDSOFT\CARDID.CLB A:\CARDSOFT\SUNDISK5.CLB A:\PACKET\SMC91C92.COM
A:\CARDSOFT\CARDID.EXE A:\CARDSOFT\SYSEDIT.EXE
A:\CARDSOFT\CARDID.INI A:\CARDSOFT\TDKLAN2.CLB A:\UTILS\ADDRESS.EXE
A:\CARDSOFT\CARDINFO.CLB A:\CARDSOFT\VCB.EXE A:\UTILS\BACKLGHT.EXE
A:\CARDSOFT\CARDINFO.EXE A:\CARDSOFT\WD.CLB A:\UTILS\BATTERY.EXE
A:\CARDSOFT\CBDAS.CLB A:\CARDSOFT\XIRCOM.CLB A:\UTILS\BCODE.EXE
A:\CARDSOFT\CS.EXE A:\UTILS\CUSTOM.INI
A:\CARDSOFT\CS_APM.EXE A:\DOS\DEBUG.EXE A:\UTILS\DIGIN.EXE
A:\CARDSOFT\CSALLOC.EXE A:\DOS\DOSKEY.COM A:\UTILS\DIGOUT.EXE
A:\CARDSOFT\CSALLOC.INI A:\DOS\EDIT.COM A:\UTILS\DIR4.BAT
A:\CARDSOFT\CSDETECT.EXE A:\DOS\EDIT.HLP A:\UTILS\ETHERNET.EXE
A:\CARDSOFT\DISK.ID A:\DOS\EMM386.EXE A:\UTILS\GOODREAD.EXE
A:\CARDSOFT\DLINK.CLB A:\DOS\FORMAT.COM A:\UTILS\README.TXT
A:\CARDSOFT\ENDBOOTR.EXE A:\DOS\HIMEM.SYS A:\UTILS\TYPE4.EXE
A:\CARDSOFT\FTL.CLB A:\DOS\MEM.EXE A:\UTILS\VOLUME.EXE
A:\CARDSOFT\FTL.EXE A:\DOS\MORE.COM A:\UTILS\WEDGE.EXE
A:\CARDSOFT\GENATA.CLB A:\DOS\PRINT.EXE
A:\CARDSOFT\GENMODEM.CLB A:\DOS\QBASIC.EXE
A:\CARDSOFT\IBM3270.CLB A:\DOS\QBASIC.PIF
A:\CARDSOFT\IBMLAN.CLB A:\DOS\SYS.COM
A:\CARDSOFT\IBMTOK.CLB A:\DOS\XCOPY.EXE

1) Before doing anything, copy the original contents of the SRAM card to
a safe place. For example, if the backup directory will be called
c:\lanptorg and the SRAM card is drive F:

c:
md \lanptorg
xcopy f:\*.* c:\lanptorg /s

2) As shipped the 2MB SRAM card does not leave enough space for the additional
files that must be copied on for the Client. So to make more space,
the following files can be deleted from the SRAM card:

DOS\QBASIC.EXE
all files in the MOUSE directory
all files in the NDIS directory
all files in the NWCLIENT directory
all files in the PACKET directory
all files in the CARDSOFT directory

The empty directories can then be removed.

3) Now create a special directory on your PC for building the set of files
that will end up on the SRAM card. This will allow you to quickly
recreate the card should anything happen to its contents.

Start by copying all files from the SRAM card to this directory. For
example:

c:
md \lanptsrm
xcopy f:\*.* c:\lanptsrm /s

The above example assumes the PC sees the SRAM card as drive F: and the
directory for the set of SRAM card files will be c:\lanptsrm

For the remaining steps, perform all file changes and copies into this
building directory (c:\lanptsrm in this example).

4) The default AUTOEXEC.BAT includes all the calls to terminal drivers
that are needed - and none need to be removed. The only change to the
existing statements that is needed is to add 'w=40' parameter to the call
to DISTRACK.

Other calls are needed for network drivers and for starting the Client.

If the TCP/IP flavor of the Client will be used (instead of the
serial flavor), add the following lines at the end for the network
drivers.

set pctcp=a:\net\lptcp.ini
a:\net\netbind
a:\net\ethdrv

Then regardless of which Client is being used, add the following line
so that the Client batch file is started automatically whenever the
terminal is rebooted:

call em

For more information about the calls in AUTOEXEC.BAT, refer to the section
LanPoint Pro CONFIG.SYS, AUTOEXEC.BAT and Network Configuration.

5) The default CONFIG.SYS includes all the basic statements that are needed -
and none need to be removed. There are several calls to CARDSOFT drivers
that are commented out - and should remain that way. All that must be
added are the calls needed for network drivers - and that is only if
the TCP/IP flavor of the Client is to be used. In that case, add the
following statements at the end of the file:

device=a:\net\protman.dos /i:a:\net
device=a:\net\smc9000.dos
device=a:\net\dis_pkt.gup

For more information about the statements in CONFIG.SYS, refer to the section
LanPoint Pro CONFIG.SYS, AUTOEXEC.BAT and Network Configuration.

6) If you are running the serial flavor of the Client skip this and the
next 2 steps. Otherwise, first create a directory called NET under the
building directory. For example:

md c:\lanptsrm\net

Then copy the following file to that NET subdirectory from the 'LANpoint
Pro Utility Disk' (from Intelligent Instrumentation):

a:\ndis\smc9000.dos

7) You will need to create a PROTOCOL.INI and SYSTEM.INI that match the ones
described previously and you will need to create a LPTCP.INI that is
similar to the one described previously. All of these files should be
created in the NET subdirectory.

For more information about the contents of these files, refer to
LanPoint Pro CONFIG.SYS, AUTOEXEC.BAT and Network Configuration.

8) The following files come from diskettes for FTP Software's PCTCP Network
Kernel for DOS:

protman.dos
protman.exe
dis_pkt.gup
netbind.com
ethdrv.exe

These should all be copied/expanded into the NET subdirectory that was
created in step 6.

Note: Although PROTMAN.EXE is not explicitly called in either CONFIG.SYS
or AUTOEXEC.BAT it is called indirectly by one of the other drivers.

For more information about how to copy these files from the PCTCP product
diskettes to the directory for SRAM card files, refer the the section
Installation Hints for the FTP Software TCP/IP Stack.

9) Now copy the following files from where the Client is installed to the
top level directory for the SRAM card files:

ETSCHECK.LIC

If using the serial flavor of the Client:

SERIAL\ETSPB.EXE

If using the Client along with the FTP Software TCP/IP stack:

TCP_FTP\ETSPT.EXE

10) Now determine if you need to create an EMULATOR.INI file. For more about
what parameters can be set up in this file, refer to the section above
Configuration using EMULATOR.INI.

If you decide you need this file, create it in the topmost directory for
the SRAM card files (e.g. c:\lanptsrm).

For all flavors, you should start with the following two lines:

a:
cd \

to make sure the Client is running from the right drive and directory.

If you need to configure preamble and postamble characters for barcodes
you should have already added the SCAN_SENTINEL_CHARS keyword to
EMULATOR.INI and you should add a line similar to the following to EM.BAT:

prepost 91 93

Be sure to use the same values for parameters that you used for the
SCAN_SENTINEL_CHARS keyword. Also be sure to copy PREPOST.EXE from the
LANPTPRO directory where the Client is installed into the directory
for SRAM files.

Next add the following line to force the 4x40 display to show only the
upper left hand corner of the larger VGA screen:

distrack r=0 c=0

If you are running the serial flavor of the Client, then add a line
to EM.BAT that is similar to:

etspb -aB -b19200 -dLANPTPRO

Change the -a (address) and -b (baud rate) parameters as appropriate for
your configuration. You can also use -dFMT3000 instead of -dLANPTPRO.

If you are running the TCP/IP flavor of the Client, then instead add
a line to EM.BAT that is similar to:

etspt -dLANPTPRO -h1.2.3.4,7500

Change the -h (host PC) parameters as appropriate for your configuration.
You can also use -dFMT3000 instead of -dLANPTPRO.

For more details about command line parameters, see the earlier section
called Common Command Line Parameters for the Client.

After the call to the Client add the following two calls to clear the
screen and reset the LCD display mode:

cls
distrack w=40

12) These are all of the files that can be set up from the PC. So at this time
you can copy all of the files from your directory for SRAM card files to
the actual SRAM card.

Once all files are copied, make sure the terminal is powered off, put the
SRAM card into the terminal and then power it on. Let the terminal come
up and make sure everything starts up properly.

Using the DCConnect Client on Intermec 6400 Terminals
-----------------------------------------------------
This section describes what additional configuration must be done when using
the Client on an Intermec 6400 RF (or batch) terminal.

It is important to note that although the 6400 terminal has 16 rows, the bottom
row is used to display annunciators for battery status, keyboard shift states
and other information. These annunciators overwrite most of any text that
might be written to row 16 by the DCConnect Client. Therefore, the Client
considers the 6400 terminal to have only 15 rows available.

For more detailed information about using 6400 terminals please refer to the
following sections:

- Hardware and Software Requirements for 6400 Terminals
- Drive Arrangement on 6400 Terminals
- Transferring Files to a 6400 Terminal
- 6400 CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
- 6400 Bar Code Configuration
- Configuring the 6400 Display and Viewport
- Serial Port Use on the 6400 Terminal
- Starting the Client on the 6400 Terminal
- Setting Up a 6400 Terminal from Scratch

Hardware and Software Requirements for 6400 Terminals
-----------------------------------------------------
When ordering the 6400 terminal for use with the DCConnect Client, the
following minimum configuration is needed:

- 4MB RAM / 2MB flash is sufficient for the needs of the Client
- DOS/PC keyboard overlay is required - whether 41 key or 51 key
- Choose the scanner you need
- Choose the radio that you need (or none for batch)
- If using the serial flavor of the Client, then the 'Batch' Connectivity
Software load is all that is needed. Otherwise choose the type of
'FTP/IP Client Software' that is appropriate for the radio that you selected.

If you selected one of the 'FTP/IP Client Software' loads, then this includes
the required license of FTP Software's PC/TCP Network Kernel for DOS along with
the necessary radio drivers. Therefore you do not have to order anything from
FTP Software separately.

If the DCConnect Client will need to be able to distinguish between keyboard
input and scanner input, then you will need to purchase one copy of:

215-760-001 DOS Developer Diskettes

because this includes the driver 64SCN7A.EXE that is needed in order for the
Client to be able to read scanner input directly. Only one copy is necessary
regardless of how many 6400 terminals you are using.

But if you just want all scanner input to be routed through the keyboard in
'wedge' mode, this driver is not needed.

In order to load the 6400 terminal, it must be serially attached to a DOS
PC because the DOS utility INTERLNK.EXE is required. This utility is not part
of nor will it run under Windows 95/98/NT or OS/2.

The serial connection from the PC to the terminal requires the 6400 be put
into one of the choices for docking station or the use of the following:

705-368-001 Communications Adapter, Serial

The latter requires a standard null-modem cable as well. Check with Intermec
for part numbers on the docking stations and for the cable requirements of
the docking station (probably a null-modem cable too).

Drive Arrangement on 6400 Terminals
-----------------------------------
The 6400 terminal has the following drives:

A: This is a read-only drive that is not used by the Client. It is used
strictly for the radio card.

C: This is the readable/writable non-volatile flash drive. The minimum
available 2MB flash memory is sufficient for the needs of the Client.
Of that 2MB, 256K is used for BIOS and DOS files.

This is the drive where all 6400 programs and drivers reside and it is the
drive where all Client files will reside and run from.

D: This a RAM drive that is typically only used as a temporary repository
for files when the terminal is reflashed. It is not used by the
Client.

Transferring Files to a 6400 Terminal
-------------------------------------
Transferring files to a 6400 terminal can be done one of two ways:

1) Using the serial port attached via a null-modem cable to a DOS PC. The
terminal must be in a docking station or have a serial adapter in place.
The null-modem cable attaches to the docking station/serial adapter on
the terminal side.

With the proper cabling and hardware in place, the DOS programs INTERLNK.EXE
and INTERSVR.EXE are used to map drives on the terminal to extra drive
letters on the PC. Once this mapping is set up, files can be copied
between the terminal and the PC.

The flash load for the terminal includes a file, 6400.BAT, which is used
to run INTERSVR.EXE on the terminal. So by simply entering:

6400

on the terminal command line, the INTERSVR program is started and waits
for a connection from the PC. The DOS PC must have a statement similar to
the following in CONFIG.SYS:

device=c:\dos\interlnk.exe /drives:3

in order for the PC to hook up with the 6400 terminal during reboot of
the PC. Even after reboot, INTERLNK can be run from the command line
whenever you want to see the status of the connection - and to find out
which drive letter on the PC is mapped to the 6400 C: drive.

For more information on INTERLNK/INTERSVR programs, consult the DOS User's
Guide. For more information on the 6400.BAT command file, see the 6400
Programmer's Reference Guide.

It is recommended that when copying files, the XCOPY command be used along
with its /V parameter to verify that the file copy was successful.

2) Once the 6400 is communicating on the TCP/IP network, the program FTP.EXE
can be run from the 6400 terminal to transfer files to/from an FTP server
on the network.

In order to reflash the terminal, which should not be necessary in most cases,
the null-modem cable setup to a DOS PC, described above in #1, is required.
Please see the 6400 Programmer's Reference Guide for instructions on how to
reflash the 6400 terminal.

CONFIG.SYS, AUTOEXEC.BAT and Network Configuration for 6400 Terminals
---------------------------------------------------------------------
The following CONFIG.SYS file was used during our testing. It is unchanged
from the one provided in the default DOS flash load for the terminal:

break=on
buffers=30
files=128
lastdrive=f
stacks=9,256
device=c:\himem.sys
dos=high
device=c:\elanump.sys /X=c000,d000,d400,e400,e800,ec00
dos=umb
device=c:\norirda.sys -t:6400
devicehigh=c:\elanapm.exe /L0
devicehigh=c:\nordospm.exe
devicehigh=c:\clock.exe
devicehigh=c:\64apmoem.exe
shell=c:\command.com c:\ /e:512 /p

Following is the AUTOEXEC.BAT file that was used during our testing with
an RF terminal (2.4ghz Open Air - FCC):

@Echo Off
elancfg /V1 /T2 /D24 /L1 /H1
*1 set runem=0
*2 delay "Press 0 for C>" /500
if not errorlevel 1 goto PC
set runem=1
*3 set PCTCP=C:\PCTCP.INI
*4 641223 -T0
*5 64scn7a
cdsvc1a
*6 lsl
prox_apm p
rl2pcm
delay "" /500 /k
owlattch
odipkt.com
ethdrv.exe
for %%i in (dhcpfile snmpfile) do if exist %%i.bat call %%i
:PC
misctsr -A -K -L -T -P1
dosgas
Echo PEN*KEY 6400 FLASH
Bios
*7 if "%runem%" == "1" call em.bat

A few notes about the file above:

1) The 'runem' flag is used to determine whether or not EM.BAT should be run
at the end to start the DCConnect Client automatically. By default this
is no - in case the user presses 0 in the next step to stop all the drivers
from loading.
2) The default load from Intermec included this and the following statement to
allow the user to press 0 to stop all the scanner, radio and network
drivers from loading.
3) The PCTCP environment variable indicates the name of the .INI file that
contains the terminal's network configuration. The contents of this file
will be described below.
4) 641223.EXE is the scanner driver. It has several command line parameters
which are described in the 6400 Programmer's Reference Guide. In the
statement above, the driver is being started so that its scanner API can
be used to read scanner input directly. This is the default if no
parameters are provided. The -t0 parameter used above indicates a
tethered scanner will not be attached to the terminal, just the internal
scanner. This parameter is required, if the serial port is to be used
to attach to a serial device.

In order to run the scanner in 'wedge' mode where all scanner input is
routed through the keyboard, the following parameters should be added:

-e -w -c

This is in fact the way the configuration is set up in the default DOS
load from the factory. The -e means don't enable the API interface and
instead turn the scanner on permanently. -w means to enable wedge mode
so that scanner input goes through the keyboard. And -c means to append
a carriage return / line feed to each bar code that is scanned.

Whether or not -t0 (disable tethered scanner) or -i0 (disable internal
scanner) should be added depends on which scanner you will be using.

To allow the Client to control the scanner properly, it is best not to run
in wedge mode (use no flags or just -t0 or -i0). This allows the Client
to keep the scanner off except when needed and it allows the Client to
distinguish between keyboard and scanner input.

Another parameter, -An where n is a # of half second intervals, must be used
for internal long range scanners to configure how duration of the aiming
beam. By default the aiming beam is disabled.
5) 64SCN7A.EXE is the scanner driver that must be in place in order for the
Client to be able to turn the scanner on and off and to be able to read
scanner input directly. This driver is not part of the default load. It
is found on the 6400 DOS Developer Diskettes. It is recommended that this
driver be used with the Client. If it is used, the previous driver, 641223
must not have any parameters - except perhaps -i0 or -t0.
6) LSL.COM is the first of several radio and network drivers that are loaded.
Other radio drivers are PROX_APM.COM, RL2PCM.COM and OWLATTCH.COM. The
network drivers are ODIPKT.COM and ETHDRV.EXE. These are all part of the
default terminal load of a 6400 RF terminal with a 2.4GHZ radio.
7) The last statement was added to automatically start the Client - if the
'runem' flag is set (See #1 above).

The radio configuration is defined in the file NET.CFG. The following is the
NET.CFG used in our testing:

Link Driver RL2PCM
*1 DOMAIN 11
INT 15
PORT 270
MEM #1 C000
STATION_TYPE 0
FRAME ethernet_II
PROTOCOL NNL 875B ethernet_II
SOCKET A
INITIALIZE_365 N
ROAM_CONFIG 1
MAC_OPTIMIZE 1
PEER_TO_PEER N
INACTIVITY_SEC 5
INACTIVITY_MIN 0
PM_DELAY 1
READ_PORT_OFF

*2 CHANNEL 1
SUBCHANNEL 1

A few notes about the file above:

1) We changed the DOMAIN value to match our access point.
2) We added CHANNEL and SUBCHANNEL to match our access point as well.

The TCP/IP parameters for the network are set up in PCTCP.INI. Here are the
contents of the file we used in our testing:

[pctcp ifcust 0]
*1 ip-address = 99.99.99.81
*2 subnet-mask = 255.255.240.0
*3 router = 99.99.99.101
interface-type = PKTDRV
frame-type = DIX-Ethernet
asynch-send = yes
odi-pkts = 8

[pctcp kernel]
interface = ifcust 0
kernel-does-dns = no
mtu-discovery = yes
multicast = no
pktdrv-loopback = yes
router-discovery = no
window = 4380
disable-timeout = yes
arp-timeout = 1500
do-slow-start = yes
icmp-echo-broadcast = yes

[pctcp general]
etc-dir = c:\
name-resolution = dns
time-zone-name = CST
time-zone-offset = 360
host-name =
domain =

[pctcp time]
time-zone-subsection = us-cst
dst-begins = 93
dst-ends = 304

[pctcp time us-cst]
time-zone-name = CST
time-zone-full-name = US/Central Standard Time
time-zone-offset = 6:00
dst-rule = US Federal
dst-name = CDT
dst-offset = 5:00
dst-begin-day = M4.1.0
dst-end-day = M10.5.0
dst-begin-time = 2:00
dst-end-time = 2:00

[pctcp dhcp]
cache-lease = no

[pctcp pctcpnet]
use-advanced = yes

[pctcp socks]
use-socks = no
socks-server =

[pctcp tn]
screen-saver = yes

; if you wish to use an alternative keyboard mapping, specify it here
[pctcp 3270]
;3270-keymap = c:\abcd.kyb

[pctcp vt]
;vt220-keymap = c:\abcd.kyb

Most of this is unchanged from the default, except for the following:

1) The terminal's IP address must be set. Each terminal must have a unique
value and it must match the address that is configured for this terminal in
DCConnect.
2) The subnet mask must be set to what is valid for your network.
3) The router must be set to what is valid for your network.
4) The default PCTCP.INI also included the following two lines:

[pctcp addresses]
domain-name-server = x.x.x.x

We removed these because the Client does not require a name server.

6400 Bar Code Configuration
---------------------------
When using 6400 terminals, configuration of the bar codes is not done using
the information that might be downloaded from the DCConnect Server. Instead,
a special utility, 6400BC.EXE, is provided as part of the DCConnect Client
so that all capabilities of the 6400 internal scanning functions can be taken
advantage of.

Note: The only way to configure bar code symbologies for a tethered scanner, is
to scan special bar codes from the scanner's manual; a tethered scanner
can not be configured programmatically. For more information about
using tethered scanners, see the 6400 Programmer's Reference Guide.

The 6400BC utility reads a configuration file, 6400BC.CFG, to determine which
bar codes symbologies should be active. Each symbology may also have certain
parameters configured for it. The 6400BC.CFG file contains comments which
explain exactly how to make changes to it.

Both 6400BC.CFG and 6400BC.EXE are provided in the 6400 directory where the
the Client is installed.

In the default DOS load of a 6400 terminal, the scanner is configured to be
in wedge mode (parameters -e -w and -c are used with 641223), which means all
scanner input is routed through the keyboard. It also means the scanner is
active at all times.

The DCConnect Client will work just fine in this mode, but it will not be able
to distinguish between keyboard and scanner input and it will not be able to
turn off the scanner when it is not needed.

However, if the 6400 scanner driver (641223.EXE) is configured to run in API
mode (parameters -e -w and -c are not used) instead of wedge mode and the
additional 6400 scanner driver (64SCN7A.EXE) is loaded, then the Client is able
to turn the internal scanner on only when scanner input is allowed in a
transaction program or CFR and the Client is able to distinguish between
scanner and keyboard input - preventing one or the other as needed.

Note: The 6400 does not allow a tethered scanner to be turned on and off; if
a tethered scanner is being used (-t1 parameter added to 641223) then it
is always on. But even so, the ability to distinguish between keyboard
and scanner input is still available when using a tethered scanner - as
long as 641223.EXE is running in API mode.

For more information about setting up 641223.EXE and 64SCN7A.EXE in
AUTOEXEC.BAT, which is how our test configuration was set up, please refer to
the discussion of the AUTOEXEC.BAT used in our testing above.

It is recommended that the API mode be used rather than wedge mode in order
to allow the Client to fully control the scanner. If API mode is used then
you will need to get the 64SCN7A.EXE driver from the 6400 DOS Developer
Diskettes. In addition, you will need the following driver:

6400_TSR.EXE

from 6400 directory where the Client is installed. In order for the Client
to use the 6400_TSR, the TSR must be started before the Client is started (in
EM.BAT) and the following keyword must be part of EMULATOR.INI:

USE_TSR_FOR_SCANNER = Y

For more information see Keyword: USE_TSR_FOR_SCANNER.

IMPORTANT NOTE: The 6400 terminal does not provide a way to programmatically
configure preamble/postamble (aka prefix/suffix) characters
for bar codes that are read. The only way to do this is by
scanning special bar codes from the scanner User's Guide. But
that requires those bar codes to be scanned by every terminal -
which means each terminal's scanner must be configured
separately, by hand. If you do choose to use this method then
the SCAN_SENTINEL_CHARS keyword would be used in EMULATOR.INI
instead of USE_TSR_FOR_SCANNER. And if USE_TSR_FOR_SCANNER
is not being used, you would lose the ability to turn the
scanner off during periods when scanned input is not allowed.

But with the use of 64SCN7A.EXE and 6400_TSR.EXE along with
running 641223.EXE in API mode, the Client is able to
accomplish the same function that SCAN_SENTINEL_CHARS provides.

Configuring the 6400 Display and Viewport
-----------------------------------------
The physical screen of the 6400 terminal (viewport) is 15 rows by 20 columns
(if you do not include the annunciator row). That viewport can be moved around
the virtual 25 by 80 screen of DOS by using the blue shift key along with the
arrow keys. By default the viewport is positioned at the bottom left of the
virtual 25 by 80 screen. And by default pressing the blue shift key and one of
the arrow keys moves the viewport one row or one column in the direction of the
arrow pressed.

The DCConnect Client uses the upper 20 rows and the leftmost 40 columns of the
virtual 25 by 80 screen. So while the Client is running, the virtual screen
can be considered to have shrunk to 20 by 40 - which is still larger than the
viewport. In order to view the DCConnect Client screens properly, the viewport
must be repositioned to be at the top left of DOS's virtual 25 by 80 screen.

In order to reposition the viewport without having to use the blue shift key
and arrow keys, a utility called 6400DISP.EXE is provided in the 6400
directory where the Client is installed. This utility takes one of two
parameters: TOP or BOTTOM to indicate whether the viewport should be position
in the top left or bottom left corner. So before the Client is started, the
following command should be run:

6400disp top

and after the Client ends the following command should be run:

6400disp bottom

Repositioning at the bottom when returning to DOS will properly position the
viewport so that the DOS command prompt is at the bottom of the screen.

While the Client is running, the blue shift keys and arrow keys can still be
used to move the viewport around. However, because for each press of the
arrow key (preceded by the blue shift) the viewport moves only one position, it
is a very tedious process to move the viewport more than a couple of rows or
columns. Fortunately, the Client handles movement around its own virtual
screen by simply pressing one of the arrow keys without the blue shift key.
In this case, the screen moves by one half of the width or one half of the
height of the screen in the direction of the arrow pressed. In this case, the
6400 viewport remains in its same position; its just that the Client is
showing a different part of its virtual 20 by 40 screen.

The exception to this is when the menus are up, the Client does not act on the
arrow keys. But if you need to scroll while in the menus, you can still use
the blue shift key and the arrow keys to move the viewport around, one row or
column at a time.

The 6400 terminal not only supports the default 16 x 20 screen size but also
supports a number of other screen sizes. The number of rows can be any of
5, 8, 10 or 16 and the number of columns can be any of 10, 13, 16, 20, 26
or 32. If you want to change the terminal's screen size before running the
Client, you can use the 6400DISP utility with the first parameter being 'size',
the second parameter being the number of rows and the third parameter being
the number of columns. For example, to set the screen size to 16 rows x 26
columns, enter the following on the terminal (after 6400DISP.EXE has been
loaded to it):

6400disp size 16 26

If you will be changing the screen size, it is probably best to add this
command to AUTOEXEC.BAT.

Serial Port Use on the 6400 Terminal
------------------------------------
The serial port on the 6400 terminal can be used not only for transferring
files and images to the terminal, but it can be used by the Client to
communicate with devices such as a serial printer.

The serial flavor of the Client can also be used if the terminal is to
communicate to the data collection server via the serial port instead of
RF over ethernet.

Starting the Client on the 6400 Terminal
----------------------------------------
The executable for the Client and the file ETSCHECK.LIC should be copied to
the C: drive of the 6400 along with any configuration file(s).

The following 'device' command line parameter must be used when starting the
Client on a 6400 terminal:

-dINTERMEC6400

For more details about this and other command line parameters, see the earlier
section called Common Command Line Parameters for the Client.

Setting Up a 6400 Terminal from Scratch
---------------------------------------
This section describes suggested steps to take an out-of-the-box 6400 terminal
and set it up so that the Client can run on it. The instructions below are
based on a 6400 terminal that was loaded with version 1.12 of the FTP/IP
Client Software for a 2.4ghz radio and had version 1.25 BIOS.

Note: The PC operations in these instructions must be performed from a PC that
has a FAT harddrive, CD ROM drive, RS-232 serial port and must be
running DOS. The INTERLNK.EXE utility that must be run on the PC is
not part of and will not run under Windows 95/98/NT or OS/2.

The 6400 terminal initially contains the following files on drive C:

C:\6400.BAT C:\CONFIG.BAK C:\INET.EXE C:\PROTOCOL
C:\641223.EXE C:\CONFIG.SYS C:\INTERSVR.EXE C:\PROX_APM.COM
C:\64APMOEM.EXE C:\CONTEXT.CNF C:\IRDAPDRV.EXE C:\PROXSTAT.EXE
C:\64IPPR10.NAM C:\DELAY.EXE C:\LSL.COM C:\RAMDFMT.EXE
C:\64SCN7B.EXE C:\DHCP.EXE C:\MISCTSR.EXE C:\RL2PCM.COM
C:\ANSI.SYS C:\DHCPHLPR.EXE C:\MMBFLAG.COM C:\RPC
C:\AUTOEXEC.BAK C:\DOSGAS.EXE C:\MODE.COM C:\SERVICES
C:\AUTOEXEC.BAT C:\ELANAPM.EXE C:\NET.CFG C:\SETCLOCK.EXE
C:\BIOS.EXE C:\ELANCFG.EXE C:\NORDOSPM.EXE C:\SNMPD.EXE
C:\BOOTP.EXE C:\ELANUMP.SYS C:\NORIRDA.SYS C:\TFTP.EXE
C:\CDSVC1A.EXE C:\ENTITY.CNF C:\ODIPKT.COM C:\TIMEZONE.INI
C:\CHGPARMS.EXE C:\ETHDRV.EXE C:\OWLATTCH.COM C:\TRAPCOMM.CNF
C:\CLOCK.EXE C:\FTP.EXE C:\PCTCP.INI
C:\COMMAND.COM C:\HIMEM.SYS C:\PING.EXE
C:\COMMUNIT.CNF C:\HOSTS C:\PRDRV.SYS

1) The first step is to copy from the terminal to the PC, the files that
already exist but which need to be modified. For these files and for
those that must be added, create an empty subdirectory on your DOS PC.
These instructions will use C:\6400LOAD:

md c:\6400load

Then transfer from the 6400 terminal to this directory the following files:

AUTOEXEC.BAT
NET.CFG
PCTCP.INI

For instructions about how to transfer files from the 6400 to the PC, see
Transferring Files to a 6400 Terminal.

You will change each of these files in the following steps.

2) Make the changes to AUTOEXEC.BAT that are described above.

Be sure to set the parameters for the call to 641223 based on whether or not
a tethered scanner is being used and whether or not the scanner will be
running in wedge mode. To summarize:

- If running in wedge mode, use the following line:

641223 -e -w -c

- If you must be able to distinguish between keyboard and scanner data
(which requires the use of 64SCN7A and 6400_TSR) then use the
following two lines:

641223
64SCN7A

- In either case, if a tethered scanner will not be used, add -T0 to
the call to 641223. Or if the interal scanner will not be used, add
-I0 to the call to 641223.

- If you want to change the default screen size of 16 x 20 to something
else, add a line to AUTOEXEC.BAT to call '6400disp' with the appropriate
parameters. This line should be added right before the call to EM.BAT
at the end. For more information about changing the screen size please
see Configuring the 6400 Display and Viewport.

If you will be using the 6400 terminal in batch mode (thus not using the
radio) you should add the following line before the call to 'lsl':

goto pc

This will skip the loading of the radio and network drivers. After having
made this change, skip the next two steps below because they deal with
change radio/network configuration files.

3) Make the changes to NET.CFG that are described above.

Be sure the DOMAIN matches that of your access points and if necessary set
the CHANNEL and SUBCHANNEL values. Contact your RF network administrator
if you are not sure how these parameters should be set.

4) Make the changes to PCTCP.INI that are described above.

You must set a unique 'ip-address' for each terminal. The 'subnet-mask'
and 'router' will be common across all terminals.

If you have more than one terminal in your network, you will have to
remember to change the 'ip-address' in PCTCP.INI before loading each
terminal. To make this easier, you could create a batch file (and we
recommend you do) that takes as a parameter the ip-address and
generates the PCTCP.INI file for you and then copies all the files to the
6400 terminal, provided the cabling is set up and 6400.BAT has been
run on the terminal. The following steps can accomplish all this:

a) First we have to take the PCTCP.INI that you just set up with the
ip-address, subnet-mask and router and split it up into parts.

Create a file called PCTCP.1ST and copy into it all lines from PCTCP.INI
starting at the beginning of the file and going up to but NOT including
the line with ip-address.

(This may only be one line).

b) Create another file called PCTCP.2ND and copy into it all lines from
PCTCP.INI starting with the line after the one with ip-address and going
to the end of the file.

c) Create a batch file called LOAD6400.BAT in the directory C:\6400LOAD
that contains the following:

@echo off
if "%2" == "" goto needparm
copy pctcp.1st pctcp.ini
echo ip-address = %2 >> pctcp.ini
copy pctcp.ini+pctcp.2nd pctcp.ini

echo .
echo . Be sure the 6400 is attached to the PC with a null-modem cable.
echo .
echo . Then run 6400 from the C: drive of the 6400.
echo .
echo . After you have done that, press Enter to begin the transfers.
pause >nul

xcopy *.* %1\ /v

echo All files have been transferred. Please reboot the terminal.
goto end

:needparm
cls
echo .
echo . You must enter the drive letter that maps to the terminal's
echo . C: drive and you must enter terminal's IP address. For example:
echo .
echo . load6400 e: 99.99.99.7
echo .

:end

d) Do not run this batch file now because there are still more files to be
created and copied into the C:\6400LOAD directory. Later when you do
run this batch file, you will provided two parameters. The first is the
drive letter on the PC that is mapped to the 6400's C: drive. If you
don't know what that is, run INTERLNK on the PC after the terminal is
serially attached to the PC and you have started 6400.BAT on the
terminal. The second parameter to LOAD6400.BAT is the terminal's IP
address - which will be inserted into PCTCP.INI before the terminal is
loaded.

5) Now copy the following files from the where the Client is installed to the
C:\6400LOAD on your PC:

ETSCHECK.LIC

If using the serial flavor of the Client:

SERIAL\ETSPB.EXE

If using the RF / TCP/IP flavor of the Client:

TCP_FTP\ETSPT.EXE

In all cases, copy:

6400\6400DISP.EXE

6) In order to configure code symbologies for the scanner, the following files
are needed from the 6400 directory where the Client is installed. Copy
these into the C:\6400LOAD directory:

6400BC.EXE
6400BC.CFG

Make changes to 6400BC.CFG as necessary. The file contains comments
which explain how to change the file. For more general information, refer
to 6400 Bar Code Configuration.

7) If you must be able to distinguish between keyboard and scanner data then
be sure you set up the calls to 641223 and 64SCN7A when setting up
AUTOEXEC.BAT above and copy the following file from 6400 DOS Developer's
Kit. The file may be in one of the self-extracting zip files on that
diskette. We had version 1.05 of the diskette and we found the file
in the self-extracting zip file 64TK105D.EXE.

64SCN7A.EXE

In addition copy the following file from where Client is installed:

6400\6400_TSR.EXE

(Both of these files should be copied to C:\6400LOAD on the PC).

8) Now determine if you need to create an EMULATOR.INI file. For more about
what parameters can be set up in this file, refer to the section above
Configuration using EMULATOR.INI.

If you decide you need this file, create it in the C:\6400LOAD directory.

If you decided to use 6400_TSR in the previous step, you must add the
following keyword to EMULATOR.INI:

USE_TSR_FOR_SCANNER = Y

9) The last Client specific file to create is EM.BAT. Remember that in
step 2 above AUTOEXEC.BAT was changed to call EM.BAT at the end. This
file will have different contents depending on what flavor of the
Client you are running and depending on how the scanner is being used.

For all flavors, you should start with the following three lines:

c:
cd \
6400bc

so that the Client can be started regardless of what the current
directory and drive are and so that the scanner can be configured with
the proper bar code symbologies.

Only if you copied 6400_TSR.EXE from Client directories should
you add the following line:

6400_tsr

For all flavors, add the following line to position the terminal's
viewport in the top left corner:

6400disp top

If you are running the serial flavor of the Client, then add a line
to EM.BAT that is similar to:

etspb -aB -b19200 -dINTERMEC6400

Change the -a (address) and -b (baud rate) parameters as appropriate for
your configuration.

If you are running the TCP/IP flavor of the Client, then instead add
a line to EM.BAT that is similar to:

etspt -dINTERMEC6400 -h1.2.3.4,7500

Change the -h (host PC) parameter to use the IP address of the DCConnect
Server.

For more details about command line parameters, see the earlier section
called Common Command Line Parameters for the Client.

After the call to the Client add the following line to reposition the
terminal's viewport back in the bottom left corner:

6400disp bottom

10) If you are not using the serial flavor of the Client, skip this step.

If you have more than one serial attached terminal in your network you must
make sure that the -a parameter for the call to ETSPB (in EM.BAT) is unique
for every terminal in the network. To make this easier, you could create
a batch file (and we recommend you do) that takes as a parameter the
terminal address letter and generates the EM.BAT file for you and then
loads all files to the 6400 terminal, provided the cabling is set up and
6400.BAT has been run on the terminal. The following steps can accomplish
all this:

a) First we have to take the EM.BAT that you just set up and split it up
into parts.

Create a file called EM.1ST and copy into it all lines from EM.BAT
starting at the beginning of the file and going up to but NOT including
the line that has the call to 'etspb'.

b) Create another file called EM.2ND and copy into it all lines from
EM.BAT starting with the line after the one with the call to 'etspb' and
going to the end of the file.

c) Create a batch file called LOAD6400.BAT in the directory C:\6400LOAD
that contains the following (be sure to use the baud rate that is
appropriate for your network):

@echo off
if "%2" == "" goto needparm
copy em.1st em.bat
echo etspb -a%2 -b19200 -dINTERMEC6400 >> em.bat
copy em.bat+em.2nd em.bat

xcopy *.* %1\ /v

echo All files have been transferred. Please reboot the terminal.
goto end

:needparm
cls
echo .
echo . You must enter the drive letter that maps to the terminal's
echo . C: drive and you must enter terminal's address (A-Y, 0-6).
echo . For example:
echo .
echo . load6400 e: B
echo .

:end

d) In the next step, you will run this batch file and provide two parameters.
The first is the drive letter on the PC that is mapped to the 6400's C:
drive. If you don't know what that is, run INTERLNK on the PC after the
terminal is serially attached to the PC and you have started 6400.BAT on
the terminal. The second parameter to LOAD6400.BAT is the terminal's
address (A-Y, 0-6) which will be inserted into EM.BAT before the
terminal is loaded.

11) All files should now be set up properly in the C:\6400LOAD directory.

In order to load the terminal, you must first connect it serially to the
PC, using a docking station or communications adapter and a null-modem
cable. Then run 6400.BAT from the terminal.

On the DOS PC, be sure you have booted with the INTERLNK statement in
CONFIG.SYS and make sure the current directory is C:\6400LOAD.

If you created LOAD6400.BAT in either step 4 or step 10 above, you can
load the terminal now by running LOAD6400.BAT and specifying the
parameters described above in those steps.

If you have not set up LOAD6400.BAT, all files from C:\6400LOAD can be
transferred to the terminal's C: drive using one of the methods described
above in Transferring Files to a 6400 Terminal.

Using the DCConnect Client on Intermec 6540 (or MaxiLAN DX) Terminals
---------------------------------------------------------------------
This section describes what additional configuration must be done when using
the Client on an Intermec 6540. The 6540 is the new improved follow-on to
the Intermec/UBI MaxiLAN DX terminal. For the most part, the way both of these
terminals are used by the Client is the same. The rest of this document
will discuss things in terms of the 6540 while noting, where necessary,
whenever the instructions would be different for the MaxiLAN DX terminal.

Since you can only get new 6540 terminals and cannot get new MaxiLAN terminals
anymore, any discussion about new terminals and their default configurations
apply specifically to the 6540 terminals.

For more detailed information about using 6540 terminals please refer to the
following sections:

- Hardware and Software Requirements for 6540 Terminals
- Drive Arrangement on 6540 Terminals
- Transferring Files to a 6540 Terminal
- 6540 CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
- 6540 Bar Code Configuration
- Serial Port Use on the 6540 Terminal
- Parallel Port and Digital I/O Use on the 6540 Terminal
- Starting the Client on a 6540 Terminal
- Setting Up a 6540 Terminal from Scratch

Hardware and Software Requirements for 6540 Terminals
-----------------------------------------------------
For TCP/IP-attached, 6540 terminals, no additional hardware is required.
The required FTP Software TCP/IP stack can be purchased as a 6540 option
from Intermec, or it can be obtained from FTP Software directly. If purchased
from Intermec, the terminal is shipped with the necessary drivers installed.

If 6540 terminals are to be attached serially in an RS-485 network, then
an ISA RS-485 adapter must be installed in the terminal as COM1 or COM2.
Contact Intermec for information about supported RS-485 adapters. We
actually tested with an OPTO-422 adapter; however, the one we used is no
longer available. No additional software is required for serially-attached
6540 terminals.

Drive Arrangement on 6540 Terminals
-----------------------------------
The drive arrangement for 6540 / MaxiLAN DX terminals is different based on
the model. Here is a summary of the models supported by the Client:

For the 6540 model DFB (MaxiLAN DX 100):

A: drive is a ROM disk; the contents of this drive cannot be changed.

B: drive is a 512K flash disk that can provide permanent non-volatile
storage (does not require battery backup). This drive can be
write-protected if needed.

For the 6540 model DSB (MaxiLAN DX 200S):

A: Same as for model DFB (MaxiLAN DX 100)

B: Same as for model DFB (MaxiLAN DX 100)

C: drive is an SRAM disk ranging from 512K to 1.5MB depending on the
feature that is ordered. It works just like an ordinary hard disk,
with the exception that permanent data storage requires a battery
backup (which is provided with the terminal).

For the 6540 model DHB (MaxiLAN DX 200H):

C: drive is the only drive and it is a conventional PC harddrive. It
comes in sizes of 1GB or more. Because it is a conventional PC
drive, it is non-volatile storage.

The Client must run on a writable drive so that transactions that are
generated can be preserved through shutdown of the Client and power down of
the terminal. It is also preferred that the writable drive be non-volatile so
that its contents are preserved even if all battery power is lost.

Therefore for models DFB and DSB (100 and 200S) drive B: is the preferred
target drive. For model DFB (100) you have no other choice. For model
DSB (200S) drive C: could be used; the only drawback is the very small
possibility of losing its contents should the backup battery be completely
drained when the unit is powered off.

On the model DHB (200H) the only available drive (C:) is writable and
non-volatile so it satisfies the desired criteria.

For simplicity, all examples in this documentation will use drive B: since
we expect the models DFB and DSB will be more commonly used than model DHB.

But if drive C: is the drive you will be using you should substitute C: for
most uses of B: in the examples. One exception to this is that references
to B:USER.BAT and B:USERCONF.SYS cannot be changed to the C: drive.

IMPORTANT NOTE: While the model DFB (100) is supported, be aware that drive B:
is 512K bytes. Whether you are running the serial or TCP/IP
flavor of the Client, all files required by the Client
should fit into this space. In some cases you may need to
remove some preloaded files that aren't needed by the
Client. Files that are not required by the Client are
listed here with their approximate sizes in bytes:

TN.EXE 267K
RLOGINVT.EXE 98K
TFTP.EXE 24K
PING.EXE 23K

All of the above are in the B:\PCTCP directory of terminals
that are preloaded with FTP Software's network drivers.

Transferring Files to a 6540 Terminal
-------------------------------------
The 6540 Getting Stated Guide describes how to transfer files between a PC
and the 6540. In short, it involves the use of a null modem cable to
attach one of the 6540 serial ports to a PC serial port and the use of two
serial transfer programs - one that runs on the PC that talks to one that
runs on the 6540.

The 6540 provides two utilities for transferring files:

1) TRANSFER.EXE - This utility allows the transfer of individual files
between the PC and the 6540. It can be used on 6540 and MaxiLAN DX
terminals. The terminal ships with this utility already installed.

The PC version of TRANSFER.EXE is found on the 6540 Utility diskette in
the A:\ROM-DOS directory. This runs not only in a true DOS system but also
in a DOS window of OS/2 or Windows/NT.

The TRANSFER.EXE runs on the terminal and communicates with the TRANSFER.EXE
program that runs on the PC. We usually start the receiving side first, but
it should work either way. The syntax of the command is slightly different
depending on which end of transfer the PC or 6540 is on. If sending a file
from the PC to the terminal, then on the terminal enter:

TRANSFER /COM1 /R /B38400 filename

and on the PC enter:

TRANSFER /COM1 /S /B38400 filename

If sending from the terminal to the PC, then switch the commands.

The 'filename' parameter for the sender is the name of the existing file in
the current directory. The 'filename' parameter for the receiver is the
name of the file that will be created in the current directory of the
receivers machine.

If you have many files to transfer it is recommended that you create
a zip file using a compression utility such as PKZIP and then transfer
the zip file and an uncompress utility (e.g. PKUNZIP) to the terminal.
Or use a self-extracting executable so that PKUNZIP.EXE does not need to
be transferred.

WARNING: The TRANSFER utility will sometimes append extra characters to a
file during the transfer. It seems to pad out the file size so
that it is a multiple of 128 bytes of data. In some cases, the
extra characters may cause a problem for the program that uses the
file. For example, we have experienced the PCTCP.INI file being
corrupted to the point where the ethernet drivers did not start.
We found two ways to get around this problem:

a) We transferred the file in a zipped file and then unzipped it
on the 6540. If you can create a self-extracting zip that would
be better.

b) If we added a bunch of lines of comments at the end of the
file, the padding did not seem to cause a problem for the
ethernet drivers any more. It seems if the comments bring the
file size to something greater than 1024 bytes then the ethernet
drivers do not have a problem. In order to accomplish this we
added 10 lines of comments to the file! But this is simpler
than zipping and unzipping the file.

2) REMSERV.EXE / REMDISK.EXE - These utilities are different from the TRANSFER
utility because they allow the PC to see one of the 6540 drives as an
extra drive on the PC. Once they are set up this way, all copy operations
can be performed on the PC. Files are copied to or from the 6540 drive as
if that drive were simply another PC drive.

IMPORTANT NOTES: 1) REMDISK will not run in a DOS window of OS/2 or
Windows/NT. So unless you have a DOS PC or DOS
bootable diskettes, you will probably need to use the
TRANSFER utility instead.

2) These utilities can only be used if the 6540 BIOS is
version 3.0 or newer.

3) These were not provided with and cannot be used with
MaxiLAN terminals.

REMSERV.EXE runs on the 6540 and it is pre-installed on the terminal when
the terminal ships. When you run the utility, you specify which drive
you want to give access to from the PC. For example:

REMSERV B:

REMDISK.EXE runs on a DOS PC and it can also be found on the 6540 Utility
diskette in the A:\ROM-DOS directory. You simply type REMDISK at the DOS
prompt. If it starts up and is able to communicate with REMSERV on the
terminal, then it will stay loaded in memory and return to the DOS prompt.
It will also tell you which drive it has mapped to the 6540 drive. It will
be a new drive letter, one that was not accessible prior to running REMDISK.

Once REMDISK has set everything up, you can then copy files to and from the
mapped drive as if it was a PC drive.

Note that REMSERV should be started on the terminal before REMDISK is run
from the PC.

If files are to be transferred to the B: drive, you must make sure that
write-protection for that drive is removed before starting the transfer. The
6540 Getting Started Guide describes how to use the SSDRIVE.EXE utility to add
and remove write-protection from the drive. To remove write-protection from
the drive, issue the following command from the 6540:

SSDRIVE B: -U

To write-protect the drive:

SSDRIVE B: -W

The SSDRIVE utility can also be used on the SRAM C: drive.

6540 CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
-------------------------------------------------------
The 6540 comes with DOS on a chip for models DFB and DSB or on the harddrive
for the model DHB.

The location and contents of the CONFIG.SYS and AUTOEXEC.BAT are different
depending on the model:

- For models DFB and DSB (MaxiLAN 100 and 200S):

- AUTOEXEC.BAT is on the read-only drive A: and it always has the following
contents:

REM AUTOEXEC.BAT VER 3.03
PATH A:\;B:\;C:\;
PROMPT $P$G
B:USER.BAT

Notice that at the end, USER.BAT is called from B: drive. Since A: drive
can't be changed, any statement that would normally go into AUTOEXEC.BAT
must be put into USER.BAT on the B: drive; thus USER.BAT is really an
extension of AUTOEXEC.BAT.
- USER.BAT will not exist (or will have nothing special in it) if network
drivers are not preinstalled on the 6540. However, if the FTP Software
drivers are preinstalled, USER.BAT will probably have the following
statements:

SET PATH=B:\PCTCP;%PATH%
*1 b:\pctcp\epktisa.com 0x60 0x300
*2 SET PCTCP=b:\pctcp\pctcp.ini
*3 b:\pctcp\ethdrv

A few notes about the above:

1) EPKTISA.COM is the low-level 6540 packet-driver. It can also be found in
the A:\PCKTDRVR directory of the 6540 Network Drivers diskette. The
0x60 and 0x300 parameters for the first line respectively specify the
interrupt to use and I/O address to use.

2) The PCTCP environment variable is set to point to the PCTCP.INI file
to be used for the ethernet configuration. PCTCP.INI is where you will
specify the terminal network parameters such as its IP address. This
file is discussed later in this section.

3) ETHDRV.EXE is the higher-level ethernet driver that comes from FTP
Software. If network drivers were not preinstalled in the 6540, this
file must be obtained from FTP Software PC/TCP Network Kernel for DOS
product. Refer to Installation Hints for the FTP Software TCP/IP Stack.

If there are any other statements that need to be added that would
normally go into AUTOEXEC.BAT, they should be added to the end of USER.BAT.
For example, you'll probably want to add the following statements to
ensure the B: drive is unlocked, make it the current directory and then
call the Client batch file:

SSDRIVE B: -U
B:
CALL EM.BAT

A discussion of the contents of EM.BAT can be found in the section
Setting Up a 6540 Terminal from Scratch.

- CONFIG.SYS is also on the read-only drive A: and it always has the
following contents:

REM CONFIG.SYS VER 3.03
DEVICE = SSDRV.SYS /F
DEVICE = SSDRV.SYS /S
NEWFILE = B:\USERCONF.SYS

Notice that at the end, B:\USERCONF.SYS is 'called' from the B: drive.
In the same way that USER.BAT is an extension of AUTOEXEC.BAT, USERCONF.SYS
is an extension of CONFIG.SYS. Any statement that would normally go into
CONFIG.SYS must be put into USERCONF.SYS on the B: drive because the A:
drive is read-only.

The SSDRV.SYS device statements are needed for the SRAM drives B: and C:

- USERCONF.SYS will always have the following statement so that DOS can
work properly:

SHELL=B:\COMMAND.COM /P

No other statements are needed for network support or for use of the
Client.

- For model DHB (MaxiLAN 200S):

- Because this model has just a C: drive and that is a standard harddrive,
AUTOEXEC.BAT is used in the normal way; there is no USER.BAT or a need
for one. At a minimum, AUTOEXEC.BAT will have the following:

SET PATH=c:\;c:\dos;

If network drivers are pre-installed, the path statement will be changed
to:

SET PATH=c:\;c:\dos;c:\PCTCP;

and the following statements for network drivers are added:

*1 c:\pctcp\epktisa.com 0x60 0x300
*2 SET PCTCP=c:\pctcp\pctcp.ini
*3 c:\pctcp\ethdrv

For more information about what these statements do, please see the
discussion of USER.BAT above.

- No default CONFIG.SYS is provided for the model DHB; nor is any needed -
even if network drivers are installed. If you need to add any statements,
you can create a CONFIG.SYS on drive C: and it will be used as it is on a
regular DOS PC. There is no need for USERCONF.SYS either.

The discussion above focused on the 6540s CONFIG.SYS, AUTOEXEC.BAT, USER.BAT
and USERCONF.SYS files. Should you have a MaxiLAN DX terminal instead of a
6540 terminal, you might find the following differences, among others:

1) All models of the MaxiLAN DX terminals included a call to LTDSPLY in
AUTOEXEC.BAT or USER.BAT for support of the LCD display. For all models of
the 6540, the BIOS loads this driver.

2) The set of network drivers that are used may be different. These may
include the following which go into CONFIG.SYS or USERCONF.SYS

PROTMAN.DOS
ENDS2ISA.DOS
DIS_PKT.GUP

and the following which go into AUTOEXEC.BAT or USER.BAT:

NETBIND.COM
ETHDRV.EXE

and PCTCP.BAT may be set up to call the above. Please refer to the
MaxiLAN documentation for more specific information about how to install
these drivers.

Whether you are using a 6540 or MaxiLAN terminal, if the terminal will be
on the ethernet, you'll need to set up the PCTCP.INI file. This file is
in the \PCTCP directory on either the B: or C: drive.

This file should be the same for all terminals in your network except for the
IP address. Below are selected sections of the PCTCP.INI that we used during
our testing, with notes to the right about what needs to be changed:

[pctcp ifcust 0]
ip-address = 99.99.99.7 ; Unique for each terminal
subnet-mask = 255.255.240.0 ; Change this for your site
interface-type = PKTDRV ; Required
frame-type = DIX-Ethernet ; Required

[pctcp general]
etc-dir = c:\pctcp\etc
router = 99.99.99.1 ; Change this for your site
name-resolution = dns
time-zone-name = EST
time-zone-offset = 300

[pctcp kernel]
interface = ifcust 0

; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption
; Add these ten lines to the end of the file to thwart the corruption

For information about the possible need for entries for authentication-key and
serial-number, see Authentication Key and Serial Number Entries in the .INI file.

WARNING: Refer to the section above, Transferring Files to a 6540 Terminal
for a warning about the possibility of file corruption when this
file is transferred to the terminal. In our testing we found that
if ten long lines are added to the end of the file, then the transfer
process does not corrupt any important parts of the file.

6540 Bar Code Configuration
---------------------------
When using the 6540 terminal, configuration of the bar codes is not done using
the information that might be downloaded from a data collection server
(e.g. DCConnect). Instead, Intermec provides two different ways to do it.

Regardless of which method is used, the following kinds of bar code parameters
can be configured:

- Active bar code symbologies and optional parameters for each.
- Tone of speaker when bar code is read.
- Speaker volume and tone combinations.
- Preamble and postamble for bar codes. If using the SCAN_SENTINEL_CHARS
keyword in EMULATOR.INI (see above), you need to
define both a preamble and postamble. If not using that keyword, it is
suggested that single carriage return character be configured as the
postamble so that the Enter key does not have to be pressed after a bar
code is scanned.

However, as you'll read below, if the MAXCONF2 utility is used, you'll need
a preamble and postamble in all cases.

Here are the two methods for configuring the 6540 bar codes:

1) A utility called MAXCONF2.EXE can be run on a PC to generate a bar code
configuration file that can be downloaded to all of your 6540 terminals.
The utility includes an option to transmit the bar code configuration file
to the terminal. This utility will run in a DOS window of OS/2 or of
Windows/NT.

Once the bar code configuration file and a second utility, called
MAXILOAD.EXE, are transferred to the terminal, the MAXILOAD utility
can be run to configure the 6540 terminal bar codes from the configuration
file.

Both MAXCONF2.EXE and MAXILOAD.EXE can be found on the Utility diskette in
the A:\CONFIG diretory.

The use of these utilities is described in the 6540 Getting Started Guide.

2) The terminal's bar code configuration can also be set up directly from the
6540 Getting Started Guide by scanning various bar codes in Appendix D.
That appendix describes the order in which the bar codes should be scanned.

The advantage to method 1 is that you can set up the configuration once on
your PC and save it to file and then distribute that file to all terminals.
Unfortunately there is an anomaly that results with the use of the MAXCONF2
utility that requires some scanner slight-of-hand to work around.

It seems that when configuring the terminal using MAXCONF2 you are forced
to choose a 'bar code ID' character that will be prepended to every scanned bar
code. This character is unique based on the symbology. You have a choice of a
character from 'A' through 'O' for each symbology that will be active.
Whenever a bar code is scanned, the first character received is the bar code ID
character. Following that is the preamble string, if any, then the data that
was scanned followed by the postamble string, if any.

The extra bar code ID character poses a problem for the Client because this
looks like keyboard input to the Client - even when SCAN_SENTINEL_CHARS are
being used. To get around this problem you can configure the preamble to
start with a Backspace character. This causes the Client to see the bar
code ID character followed immediately by a backspace - the net effect of which
is that nothing was typed.

So when using MAXCONF2 you will need to configure the preamble as follows,
depending on whether or not SCAN_SENTINEL_CHARS are being used:

- If SCAN_SENTINEL_CHARS are not being used, you will need to configure a
preamble that consists of just the Backspace character.

- Otherwise, the preamble string must consist of two characters; the first is
the Backspace character and the second is whatever you need. See the section
above about Keyword: SCAN_SENTINEL_CHARS for more info.

Note: When defining the preamble character using the MAXCONF2 utility, the
Backspace character can be selected by pressing the Down arrow to
highlight the 'Control codes chart' option and then pressing Enter.
Press the down arrow to highlight the first option in the second row (BS)
and press the Enter key.

Using the Backspace in the preamble to erase the bar code ID character works
well with the standard transaction program READ command - even with numeric-
only input. If you are using CFRs, the extra bar code ID character and
backspace character may cause problems depending on how the code is written.
The CFR must take the following into account:

- Anywhere the CFR has a call to SenRead() to get scanned input, there will
also need to be a call to KbdReadAscii() to flush out the extraneous bar
code ID character and the backspace character. If this is not done, those
characters will remain in the keyboard buffer and will probably show up
as input for other fields or could even start a transaction program
unexpectedly (e.g. the 'A' character might start the program bound to F1).

- If the CFR is already calling KbdReadAscii() and SenRead() in the same loop
there probably won't be anything more to do if backspaces are being
processed. However, if certain keyboard characters have special meaning
such as 'E' to end, 'N' for next, ... (which might be the case when only
numeric input is being looked for) then when you run the MAXCONF2 utility,
you have to be sure to pick a bar code ID character that is not one of those
with special meaning.

If you want to avoid the challenges that MAXCONF2 presents, you can just use
the bar codes in the 6540 Getting Started Guide to configure the terminal.
The problem with the leading bar code identifier does not exist when using the
bar codes in the Guide, but you will have to configure every terminal by hand.

Serial Port Use on the 6540 Terminal
------------------------------------
The serial port on the 6540 terminal can be used not only for transferring
files to the terminal, but it can be used by the Client to communicate with
devices such as a serial printer or a scale.

The serial flavor of the Client can also be used if the terminal is to
communicate to the data collection server via the serial port instead of over
the ethernet. If one of the built-in RS-232 ports is to be used, then
nothing more needs to be done.

Intermec does not support the addition of an RS-485 adapter to the 6540
terminal even though this used to be an option with the MaxiLAN DX terminal.

Parallel Port and Digital I/O Use on the 6540 Terminal
------------------------------------------------------
While the 6540 terminal has a parallel port and the capability to add
a Digital I/O adapter, the Client does not currently support access to the
parallel port or Digital I/O from transaction programs or CFRs.

Starting the Client on a 6540 Terminal
--------------------------------------
The drive on which the Client should run depends on the model of the 6540
being used. The Client requires writable, non-volatile storage so that
its transaction logfile can be properly written to and be properly preserved
through any loss of power. Drive A: is never a choice because it is a
ROM (read-only-memory) Disk.

For model DFB, drive B: must be used.

For model DSB, either drive B: or C: could be used; however, drive B: is
non-volatile storage and drive C: requires a backup battery for preserve
its contents. Therefore, it is probably preferable to use drive B: for
non-volatile storage of transactions.

For model DHB, there is only a drive C: and it is a standard hard drive thus
it provides non-volatile storage.

After you have determined which drive should be used, the Client and the
file ETSCHECK.LIC should be copied to that drive along with any configuration
file(s). If desired, all of these files could be copied to a subdirectory
instead - but they must all be in the same directory.

If using the Intermec 6540 then the following 'device' command line parameter
must be used when starting the Client:

-dINTERMEC6540

However, if you are using a MAXILAN DX terminal, the the following command
line parameter should be used instead:

-dMAXILAN

For more details about this and other command line parameters, see the earlier
section called Common Command Line Parameters for the Client.

Setting Up a 6540 Terminal from Scratch
---------------------------------------
This section describes suggested steps to take an out-of-the-box 6540 terminal
and set it up so that the Client can run on it. These instructions were
developed from a 6540 that we tested with. Since you can't get a new MaxiLAN
we have no way of knowing how an out-of-the-box MaxiLAN might look and chances
are you won't need to know either.

The instructions below are for either a model DFB or DSB 6540 and they set up
all files on the B: drive. If you have a model DHB, references to the B: drive
would be changed to C: and the out-of-the-box configuration would have more
files - most of them associated with DOS.

The 6540 models DFB and DSB always contain the following files on drive A:

AUTOEXEC.BAT CONFIG.SYS COMMAND.COM REMSERV.EXE SSDRV.SYS SSDRIVE.EXE

Since drive A: is read-only, none of these files can be changed.

The 6540 models DFB and DSB always contain the following files on drive B:

USER.BAT USERCONF.SYS

If you ordered 'PC/TCP Network Kernel for DOS from FTP Software' as a feature
of the 6540 terminal then drive B: would have a directory called B:\PCTCP
containing the following additional files:

EPKTISA.COM PCTCP.INI ETHDRV.EXE PING.EXE TFTP.EXE TN.EXE RLOGINVT.EXE

On model DSB, RLOGINVT.EXE is found on drive C: instead.

Although using REMSERV.EXE / REMDISK.EXE is an easier way to copy files to and
from the terminal they require a true DOS environment on the PC side. The
TRANSFER.EXE utility is harder to use but it will work in a DOS window of OS/2
or Windows/NT - which is where we assume most people will be trying to set
up their terminals from. So the instructions below will only use the
TRANSFER.EXE utility for getting files to and from the terminal. Batch files
will be set up on both sides to make this a mostly automated process.

1) To start, create a directory on your PC for collecting all the files that
will be transferred to the B: drive of the 6540. This example will use
C:\6540LOAD.

Copy into that directory, the TRANSFER.EXE utility from the A:\CONFIG
directory of the 6540 Utility diskette.

2) Transfer from the 6540 to the C:\6540LOAD directory, the USER.BAT batch
file on drive B:

If you have the drivers from FTP Software preinstalled, then transfer
the PCTCP.INI file from B:\PCTCP to C:\6540LOAD.

For help on using the TRANSFER.EXE utility, see the section above called
Transferring Files to a 6540 Terminal.

3) If you are using the TCP/IP flavor of the Client and you purchased the
PC/TCP Network Kernel for DOS directly from FTP Software then you will need
to copy the necessary drivers to C:\6540LOAD:

a) Copy ETHDRV.EXE from the PC/TCP diskettes. For information about where
to find this, see Installation Hints for the FTP Software TCP/IP Stack.

b) Copy EPKTISA.COM from the A:\PCKTDRVR directory of the 6540 Network
Drivers diskette.

c) You'll also need to create PCTCP.INI like the one described in the
network configuration section above.

4) Make the following changes to USER.BAT:

a) If you are using the TCP/IP flavor of the Client and you purchased
the PC/TCP Network Kernel for DOS directly from FTP Software then you
will need to add the following statements:

B:\PCTCP\EPKTISA.COM 0X60 0X300
SET PCTCP=B:\PCTCP\PCTCP.INI
B:\PCTCP\ETHDRV

If PC/TCP was preinstalled, you should already have these statements.

b) Add the following statement to ensure that drive B: can be written to:

SSDRIVE B: -U

c) Add the following statement to automatically start up the Client
whenever the terminal is rebooted:

CALL EM

5) If using the TCP/IP flavor of the Client, set up the PCTCP.INI file like
the one described in the network configuration section above.

The only parameters you should have to change are the 'subnet-mask',
'router', and 'ip_address'. The first two of these will probably be the
same for all terminals. The 'ip_address' will be unique for each terminal.

Later on we'll be setting up batch files for loading the 6540 with all the
necessary files. To automate things as much as possible, we'll set up that
batch file to generate PCTCP.INI based on a command line parameter that
specifies the IP address and two files that are the parts of PCTCP.INI
that come before and after the 'ip-address' statement.

From the PCTCP.INI file that you have created, copy the first line to a
file called PCTCP.1ST in the C:\6540LOAD directory. It should look like
this:

[pctcp ifcust 0]

Copy the rest of the file, after the line for 'ip_address' to a separate
file called PCTCP.2ND. It should look like this:

subnet-mask = 255.255.240.0 ; Change this for your site
interface-type = PKTDRV ; Required
frame-type = DIX-Ethernet ; Required

[pctcp general]
etc-dir = b:\pctcp
router = 99.99.99.1 ; Change this for your site
name-resolution = dns
time-zone-name = EST
time-zone-offset = 300

[pctcp kernel]
interface = ifcust 0

Later on when the batch file is set up, these two parts of the file will
be combined with a line generated from the batch file echo command for the
'ip_address' parameter. The end result will be a complete PCTCP.INI file
that is unique for the terminal you are loading.

6) If you will be configuring the barcodes for the 6540 using a configuration
file generated from MAXCONF2, then you must do the following things:

a) Copy the following files from the A:\CONFIG directory of the 6540
Utility diskette to the C:\6540LOAD directory on the PC:

MAXILOAD.EXE
MAXCONF2.EXE
CONF2.DOC

The first one will be loaded to the terminal later; the others are
needed to run MAXCONF2 on the PC.

b) Run the MAXCONF2.EXE utility to configure your barcodes, preamble,
postamble, ... Save the configuration using the name BARCODES (the
utility will automatically add an extension of .CFG when it saves the
file).

For more information about how to use the MAXCONF2 utility and, in
particular, how the preamble and postamble strings must be set up,
see 6540 Bar Code Configuration.

c) Create a file called BARCODES.IN in the C:\6540LOAD directory on your
PC that contains the following lines:

1
BARCODES

This will be used as input to the MAXILOAD utility when it runs on the
6540 so that user intervention is not required. The first line
causes option 1 to be selected for configuring the terminal. The
second line gives the name of the bar code configuration file without
the .CFG extension.

7) Now copy the following files from where the Client is installed to the
C:\6540LOAD directory on your PC:

ETSCHECK.LIC

If using the serial flavor of the Client:

SERIAL\ETSPB.EXE

If using the TCP/IP flavor of the Client:

TCP_FTP\ETSPT.EXE

8) Now determine if you need to create an EMULATOR.INI file. For more about
what parameters can be set up in this file, refer to the section above
Configuration using EMULATOR.INI.

If you are using an 8 line terminal then you will need to add the parameter

NUM_ROWS = 8

to override the default value of 4 which is assumed for the 6540 device.

If you decide you need this file, create it in the C:\6540LOAD directory
on your PC.

9) The last Client specific file to create is EM.BAT. Remember that in
step 4 above USER.BAT was changed to call EM.BAT at the end. This
file will have different contents depending on what flavor of the
Client you are running and what device you are using.

For all flavors, you should start with the following two lines:

b:
cd \

to make sure the Client is running from the right drive and directory.

If you will be configuring the barcodes for the 6540 using a configuration
file generated from MAXCONF2, then add the following line:

maxiload < barcodes.in

If you are running the serial flavor of the Client, then add a line
to EM.BAT that is similar to:

etspb -aB -b19200 -dINTERMEC6540

Change the -a (address), -b (baud rate) and -d (device) parameters as
appropriate for your configuration.

If you are running the TCP/IP flavor of the Client, then instead add
a line to EM.BAT that is similar to:

etspt -dINTERMEC6540 -h1.2.3.4,7500

Change the -d (device) and -h (host PC) parameters as appropriate for your
configuration.

For more details about command line parameters, see the earlier section
called Common Command Line Parameters for the Client.

After the call to the Client add a call to clear the screen:

cls

This is sometimes needed to restore the display to its original state
after you exit the Client.

10) All files that are required are now set up, except for the batch files
that do the actual transfer. The batch file that runs on the terminal
will also ensure that unnecessary files are deleted to make room for
all files that will be transferred.

The batch file that runs on the terminal will be called 6540RECV.BAT and
the the one that runs on the PC will be called 6540SEND.BAT.

Shown below is a sample 6540RECV.BAT that would be used to receive the
files needed for a 6540 preloaded with network drivers. There are lots
of variations based on what files your installation needs:

REM Change to B: drive and remove write-protection
b:
ssdrive b: -u

REM Change to network directory, remove extra files and transfer
REM in the PCTCP.INI file
cd \pctcp
if exist tn.exe del tn.exe
if exist rloginvt.exe del rloginvt.exe
if exist tftp.exe del tftp.exe
transfer /r /com1 /b38400 pctcp.ini

REM Go back to the root directory and transfer the rest of the files
cd \
transfer /r /com1 /b38400 user.bat
transfer /r /com1 /b38400 etscheck.lic
transfer /r /com1 /b38400 etspt.exe
transfer /r /com1 /b38400 emulator.ini
transfer /r /com1 /b38400 etscfg.tcp
transfer /r /com1 /b38400 em.bat
transfer /r /com1 /b38400 maxiload.exe
transfer /r /com1 /b38400 barcodes.in
transfer /r /com1 /b38400 barcodes.cfg

echo All done. Please reboot the terminal.

Working in conjunction with the receive batch file above is the
6540SEND.BAT that runs on the PC. To remove some of the redundancy for
the commands that are used in transferring a file, we created a small
batch file XFER.BAT that is called by 6540SEND.BAT for most transfers:

transfer /s /com1 /b38400 %1
REM The following line puts the cursor back in column 1 on the next line
echo T

The contents of 6540SEND.BAT are as follows:

@echo off
if "%1" == "" goto needparm
copy pctcp.1st pctcp.ini
echo ip-address = %1 >> pctcp.ini
copy pctcp.ini+pctcp.2nd pctcp.ini

echo .
echo . Be sure the 6540 is attached to the PC with a null-modem cable.
echo .
echo . Then run 6540RECV from the B: drive of the 6540.
echo .
echo . After you have done that, press Enter to begin the transfers.
pause >nul

call xfer pctcp.ini
call xfer user.bat
call xfer etscheck.lic
call xfer etspt.exe
call xfer emulator.ini
call xfer etscfg.tcp
call xfer em.bat
call xfer maxiload.exe
call xfer barcodes.in
call xfer barcodes.cfg

echo All files have been transferred. Please reboot the terminal.
goto end

:needparm
cls
echo .
echo . You must enter the terminal's IP address. For example:
echo .
echo . 6540send 99.99.99.7
echo .

:end

As was mentioned your configuration may require some additional files to
be transferred or perhaps fewer files. If that is the case, then be sure
to add/delete the transfer statement for that file from both batch files
and make sure the order of transfers is the same in both files.

11) Now that the batch files are set up, you have to get the 6540RECV.BAT file
into the 6540 using the TRANSFER.EXE utility. You may need to remove
write-protection for B: drive before transferring the file if this is the
first time using the terminal. If that is the case enter the following
command on the 6540:

ssdrive b: -u

Now you can transfer the batch file. Make the root directory of the B:
drive the current directory on the 6540 and enter the following command:

transfer /r /com1 6540recv.bat

And on the PC enter the following command from the C:\6540LOAD directory:

transfer /s /com1 6540recv.bat

12) Once 6540RECV.BAT is in the terminal you can run 6540SEND on from the
C:\6540LOAD directory on the PC and it will tell you when to run
6540RECV on the terminal. When that process completes, reboot the
terminal and make sure it works as expected.

Once 6540RECV.BAT is in the terminal, you should not have to reload it
unless you change the set of files that are needed in the terminal (which
of course requires a corresponding change in 6540SEND.BAT). If the set
of files has changed, then you must repeat step 11 to update that file
in the terminal and then do step 12 again.

But if you are just updating configuration files that are already in the
terminal or if you have a new version of the Client, then you just have
to update those files in the C:\6540LOAD directory and run 6540SEND to
have them updated in the terminal.

Using the DCConnect Client on Intermec's Trakker Antares Line of Terminals
--------------------------------------------------------------------------
This section describes what additional configuration must be done when using
the Client with one of the Intermec Trakker Antares terminals. There are
several different models of Antares, in all shapes and sizes, but they all have
the same architecture; so the way the Client works with one is the way it
works with all of them. A list of many Antares models is given above in,
Using the DCConnect Client with non-IBM Data Collection Terminals.

For the remainder of this document, the term 'Antares' will be used to refer
to all of the different models collectively.

For more detailed information about using Antares terminals please refer to the
following sections:

- Hardware and Software Requirements for Antares Terminals
- Drive Arrangement on Antares Terminals
- Using the Antares Menus and the SETUPANT.EXE Utility
- Transferring Files to an Antares Terminal
- Loading DOS files to an Antares Terminal
- Loading Intermec flash to an Antares Terminal
- Antares CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
- Antares Bar Code Configuration
- Serial Port Use on the Antares Terminal
- Digital I/O Use on the Antares Terminal
- Starting the Client on an Antares Terminal
- Setting Up an Antares Terminal from Scratch

Hardware and Software Requirements for Antares Terminals
--------------------------------------------------------
Here is a summary of the points made in this section:

- Adding more than the 2MB of base RAM is not necessary nor will it help
- Antares have less RAM available than most terminals. But using the FILE_PAGING
option in EMULATOR.INI can alleviate space issues
- Antares terminal is loaded serially, so appropriate dock/adapter/cables needed
- Terminal must be loaded with DOS, use special options when ordering to
specify DOS
- Must specify TCP/IP connectivity option - not UDP Plus
- Intermec DCS 300 Controller is not needed nor will it help
- DCConnect must be at fix pack C for version 1.40 or later

The basic configuration for the various Antares models is sufficient for
the Client to be able to run on the terminal. Therefore a terminal with
2MB flash and no SRAM drive will work. The Antares terminal has less RAM
available for the downloading of files and storage of transaction programs
than most of the other devices have. There are about 89,000 bytes of RAM space
available once the Client (as of version 1.41I) is started - which should be
sufficient for most configurations.

Note 1: 89,000 bytes is available if MAX_TRANSACTIONS is set to 10 and
NUM_PF_STRINGS and NUM_TOUCH_STRINGS are both set to 0 using EMULATOR.INI.

Note 2: As new features are added to the Client, the size of the executable will
increase which in turn reduces the amount of RAM available for files that
need to be downloaded from the DCConnect Server.

As of version 1.40T of the DCConnect Client, a new feature has been added to
allow the Antares to handle downloads that are larger than the RAM space
available. This is done by loading files to disk and then paging them in
and out of memory as required by the operations being performed by the
terminal user. This new feature can be activated using the FILE_PAGING keyword
in EMULATOR.INI For more information, please see Keyword: FILE_PAGING.

In order to load the Client files on to the Antares terminal, a serial
connection is required from the terminal to a PC. Therefore, depending on
the terminal type, you may need a special serial cable, serial adapter or
docking station in order to make the connection. Here's what you need by
terminal model using part numbers from the 1999 price guide (check with
Intermec for any additional options that these selections might require such
as power supply or power cords):

- 241x: 6 foot 16pin-9pin RS232 cable (069589) or 6 inch serial adapter (069591)
or Communications dock (TD2410A)
- 242x: Serial adapter (064021) or Communications dock (TD2400A)
- 2455: Null modem cable (066847)
- 246x: Already includes a standard 9pin male RS232 connector
- 248x: Already includes a standard 9pin male RS232 connector

In order for the Client to run on the Antares terminal, the terminal must be
loaded with the DOS program files. Antares versions 6.12 up to but not
including version 6.20 included the necessary DOS files. However, starting
with version 6.20, Intermec stopped automatically including the DOS files
with their flash load to limit the royalties they had to pay.

To ensure that the terminals include the DOS files when they are shipped by
Intermec, certain options have to be specified for the order category that is
called 'Configuration Software and Keyboard Overlay' or 'Keypad & Software
Options'. The following table gives the appropriate option to specify for
several Antares terminal models:

Antares Model Option to Order
------------- ---------------
2415 02
2425 11
2455 B
248x J

If terminals are received without the DOS files, you will need to contact
Intermec Support in order get those DOS files so that you can load them.

It is also possible for a terminal that was shipped to Intermec for service
to be reflashed by Intermec without including the DOS files. If this
happens and you do not have the DOS files somewhere else, you will have to
contact Intermec Support to get the files. As a last resort, if another
terminal you have has the DOS files, it is possible to upload those files
to a PC using the T24FCOPY utility that is included with the DCConnect Client.
For information about using this utility, please see the second half of
Transferring Files to an Antares Terminal.

If you ever have to load the terminal with DOS files, the best way to do
this is to incorporate them into the loading of the DCConnect Client
files. For information about how to do this, please see
Loading DOS files to an Antares Terminal.

On Ethernet and RF Antares terminals, the architecture includes specialized
drivers for handling TCP/IP communications. As a result, it is not necessary
(nor would it work) to install another TCP/IP stack on the terminal. The
TCP/IP flavor of the Client uses a TCP/IP stream socket to communicate
with the data collection server (such as DCConnect); it does not use UDP Plus.
Therefore you will not be using an Intermec DCS 300 controller for Antares
terminals that are communicating with the DCConnect Server.

Since TCP/IP will be used instead of UDP Plus, when ordering an Ethernet-
attached or RF Antares terminal, be sure to specify TCP/IP for the
Connectivity Software option. Do not specify UDP Plus.

Because a stream socket is used by the Antares terminals, DCConnect had to be
enhanced to support TCP/IP stream sockets. All other terminals supported by
DCConnect prior to the Antares used UDP sockets. The enhancement to support
stream sockets was done in Fix Pack C for the DCConnect 1.4.0 CDs. Therefore
that fix pack (or later) is required in order to use Antares terminals attached
via TCP/IP to DCConnect.

If you intend to use Antares terminals attached serially to the DCConnect
Server, there are some performance considerations to be aware of regarding the
ability of the terminal to respond to polls from the DCConnect Server. For
more information, please see Serial Port Use on the Antares Terminal.

Drive Arrangement on Antares Terminals
--------------------------------------
The primary drive available for use on an Antares terminal is drive C: It is
a non-volatile, writable drive and it is 750K in size. After DOS and other
system files are loaded, about 500K is free for the Client and its files -
which is more than adequate. The total size of the physical drive is actually
2MB, but 1.25MB is used by the Antares for other purposes.

There is a read-only A: drive which contains a couple of files, including
AUTOEXEC.BAT and CONFIG.SYS. But there is no need to change these files
in order to run the Client.

There is also a read-only B: drive containing DOS utilities. This B: drive is
actually implemented as a single file on the C: drive - called DRIVEB.IMG.
There is no need to change anything on this drive either.

The Antares terminal allows a RAM disk to be created out of the available RAM.
This is not necessary, and is in fact discouraged because it would take away
from the RAM that the Client needs for the files and transactions that it
will be storing.

Using the Antares Menus and the SETUPANT.EXE Utility
----------------------------------------------------
This section describes how terminal parameters can be set using the Antares
menus - as well as how they can be set using the SETUPANT.EXE program. Please
read the entire section for both methods. You should find that using the
SETUPANT.EXE program is the preferred method - especially if you have many
terminals to configure.

The Antares menus are used for changing various configuration parameters,
including parameters for the following features:

Feature Path Through the Menus Starting at the MAIN MENU
------- ------------------------------------------------
Serial Port CONFIGURATION -> COMMUNICATIONS -> SERIAL PORT [COM1]
Basic TCP/IP Setup CONFIGURATION -> COMMUNICATIONS -> PRIMARY NETWORK
Advanced TCP/IP Setup CONFIGURATION -> COMMUNICATIONS -> ADVANCED NETWORK
Radio CONFIGURATION -> COMMUNICATIONS -> RADIO
Bar Code Symbologies CONFIGURATION -> SYMBOLOGIES
Beeper volume CONFIGURATION -> TERMINAL -> BEEPER
Backlight timeout CONFIGURATION -> TERMINAL -> DISPLAY
Scanner setup CONFIGURATION -> TERMINAL -> SCANNER

There is also a DIAGNOSTIC MENU off the MAIN MENU from which you can test the
hardware.

There is a SYSTEM MENU off the MAIN MENU from which the option to UPGRADE
FIRMWARE can be used to reflash the terminal, if that becomes necessary. This
same option can be used to reboot the terminal - just go through all the prompts
as if you were going to flash the terminal and when the LOADER WAITING screen
shows, press Esc and then select the option to Boot the System.

Here are a few tips about navigating the Antares menus:

1) To get into the Antares menu, press and release the following 5 keys
in order:

Function - Left Enter - 2 - 4 - 8

Notes: On 2435 terminals the Left Enter key is the key on the bottom
left (left of the 0).

On other terminals that do not have left and right Enter keys,
just press the Enter key instead.

On some terminals the Left Enter key has also been referred to
as the 'Left Kidney' key due to its shape!

2) Use the up and down arrow keys to change between menu options.

3) Press Enter to go into a different menu or configuration screen

4) When the current setting for a particular option is highlighted, if it is
an entry field, just type in the new value, otherwise use the left and
right arrow keys to scroll through the value settings for that option.

On some Antares models, in order to get the equivalent of the left and right
arrow keys, you must press the Function key followed by another key.

5) To leave the current screen and keep any changes you made, scroll down to
the OK button and press Enter.

6) To cancel the changes that you made on a particular screen, press the Esc
key (or you can scroll down to the Cancel button and press Enter).

7) Pressing Esc on any screen that just has a menu takes you back up to the
next highest menu.

8) Pressing Esc from the MAIN MENU exits the menus. However, if you had made
any changes while in the menus you will get the following prompts:

a) "Save new configuration (in RAM)?" Select Yes if you want to keep those
changes. Then press Esc again to exit the menus. You'll get the next
prompt:

b) "Store configuration changes in flash memory? ... " Again select Yes
so that the changes remain in effect when rebooting. This will take
a second or two and you'll get a third prompt:

c) "Exiting TRAKKER Antares 2400 Menu System". Just press Enter and you'll
be completely out of the menus.

IMPORTANT NOTE: Although the Antares menus can be entered at any time,
including when the Client is running, IT IS STRONGLY
RECOMMENDED THAT YOU EXIT THE CLIENT BEFORE ENTERING
THE ANTARES MENUS, PARTICULARLY IF YOU WANT TO CHANGE
ANY ANTARES CONFIGURATION OPTIONS. On more than one
occasion we have seen the situation where the changing
of an Antares configuration option while the Client
was running caused the terminal to lockup the next
time it was rebooted. In fact the terminal had to
be reflashed with the Intermec Antares falsh to
recover.

Most of the configuration changes that can be made through the Antares menus
can also be made by scanning bar codes out of the Antares manual. For more
information about this capability and for additional information about the
menus, consult the Antares manual.

Another way to make configuration changes in the menus is to use a custom
written program that uses the Antares PSK API im_command() with the appropriate
configuration string. The configuration string is in fact the same as can be
scanned from the Antares manual. The Client program itself uses this method
to configure the terminal for any serial communications that must be done.

Most of the following parameters need to be set in order for the DCConnect
Client to work properly and communicate with the DCConnect Server:

Terminal IP Address
Subnet mask
Host IP Address
Network Port
Default router
Radio parameters for 802.11 radio or radio parameters for Open Air radio
Enabling the RF or Ethernet
Font Size
Beeper volume
Serial port protocol, baud rate and flow control for use with T24FCOPY utility
Preamble / postamble for bar code scanning
Changes to the default bar code symbologies

In order to ease the configuration of these parameters, we have provided a
small utility program called SETUPANT.EXE which reads a file containing
configuration strings - just like the ones that can be scanned in from the
Antares manual - and configures the terminal using the im_command() API. This
program has one required parameter, the file name to be read. That file must
exist in the current directory.

Following that can be additional configuration commands that will be issued
before all the commands in the file are issued. These extra parameters are
useful for setting values that will be different for each terminal, such as the
Terminal IP Address. The configuration file will not include parameters that
are different for every teminal.

To reduce the typing required on the terminal and to eliminate the need for
the typer to remember the command syntax for setting the IP address, we have
created a batch file called S.BAT that calls SETUPANT.EXE and issues a set IP
address command using the configuration file and IP address passed in on the
command line. S.BAT contains the following:

@ECHO OFF
C:
IF "%1" == "" GOTO SERIAL
SETUPANT SETUPANT.INI $+ND%1
GOTO END

:SERIAL
SETUPANT SETUPANT.INI

:END
COPY HIDEUSER.BAT USER.BAT
CALL USER.BAT

The %1 is replaced with the IP address. For example, to configure the
terminal using the configuration file SETUPANT.INI and to set its IP address to
99.99.99.31, enter the following command at the DOS prompt of the Antares
terminal:

S 99.99.99.31

Because S.BAT first changes to the C: drive before running SETUPANT, the
above command can be entered when the current drive is A: - which is the case
when the terminal is first booted.

As you probably noted, the above batch file can also be used with serial-
attached terminals that do not require the TCP/IP address to be set.

The configuration file should have the following format:

- At most one configuration string per line
- The entire configuration string must be on one line with no imbedded spaces
- Every line containing a command must start with $+ which is what the
Antares terminal expects at the start of the command.
- Space characters before the $+ are allowed
- Blank lines are allowed
- Any line whose first non-space character is not $ is assumed to be a comment
and will be skipped.

The installation of the Client product files includes SETUPANT.EXE
in the directory ANTARES and it includes samples for S.BAT and
SETUPANT.INI in the directory ANTARES\SAMPLE.

These three files should be included in the DOWNLOAD.BAT file that you will set
up for downloading all files to the terminal. After each terminal is loaded
for the first time you will need run S.BAT with the appropriate parameters
one time. Once it has been run, the configuration changes are saved in
the terminal's flash RAM and will be preserved through a reboot. S.BAT
should therefore not have to be run again unless the terminal configuration
in SETUPANT.INI is changed and redownloaded.

When the terminal is eventually set up with all of its files, A:AUTOEXEC.BAT
will call C:USER.BAT which in turn will call C:EM.BAT which automatically starts
the DCConnect Client. This sequence presents a problem if we want to run
S.BAT right after the terminal is loaded. This problem was solved by the
last two lines in S.BAT:

COPY HIDEUSER.BAT USER.BAT
CALL USER.BAT

With these statements in place, USER.BAT should be downloaded as HIDEUSER.BAT
instead. Then when DOWNLOAD.BAT is run and the download completes and
AUTOEXEC.BAT runs, it will not find USER.BAT. The person setting up the
terminal will then run S.BAT as described above to do the terminal
configuration. After SETUPANT.EXE runs, HIDEUSER.BAT will be copied to
USER.BAT and then it will be called. Thus the Client will automatically be
started after the configuration is complete and USER.BAT will be properly set
up for the next time the terminal has to be rebooted.

Further instructions for setting these files up will be covered later in
Setting Up an Antares Terminal from Scratch.

Transferring Files to an Antares Terminal
-----------------------------------------
This section discusses how to load the Antares terminal with the necessary
DCConnect Client files and assorted configuration files that are required. It
assumes the terminal is already loaded with the proper flash and DOS files.

If the proper flash files are not already on the terminal, follow the
instructions above for obtaining the proper flash. The instructions are in
Hardware and Software Requirements for Antares Terminals.

If the terminal is not already loaded with DOS files, please see
Loading DOS files to an Antares Terminal.

Intermec provides a couple of utilities for loading files to the Antares
terminals. Both require that the terminal be attached to a PC using the
appropriate serial cable described in the hardware requirements section above.

The preferred method for loading multiple files uses a utility called
LOADER.EXE. This is a DOS program that can also run in a DOS window on
Windows NT/2000 or OS/2. It is provided where the Client is installed,
in the ANTARES subdirectory. In that same directory are two other files
that are used with the LOADER program:

FLASHLDR.BIN
SAMPLE\DOWNLOAD.BAT

The first is used internally by the LOADER program; it must exist in the
current directory when LOADER is run. The second is a sample batch file for
calling the loader to load several files in a row. This batch file contains
the following:

loader %1 %2 etscheck.lic /pwait /x

goto skipdos
loader %1 %2 /flistfile.dos /update /pwait /x /s

:skipdos
loader %1 %2 etspt.exe /pwait /x /s
loader %1 %2 emulator.ini /pwait /x /s
loader %1 %2 setupant.exe /pwait /x /s
loader %1 %2 setupant.ini /pwait /x /s
loader %1 %2 s.bat /pwait /x /s
copy user.bat hideuser.bat
loader %1 %2 hideuser.bat /pwait /x /s
loader %1 %2 em.bat /pboot /x /s /ados.bin
@REM Clear screen because loader leaves cursor on same line as last command
cls

Some important notes about the parameters being used for each call to loader:

- %1 and %2 are placeholders for optional parameters that might be specified
when DOWNLOAD.BAT is run from the command line. These optional parameters
are described below.

- Next is the name of the file being loaded. The file name can include a path
indicating where on the PC the file is located. However, whether or not the
name includes a path, it will always be loaded to the root directory of
drive C: on the terminal. The Antares terminal does not support
subdirectories.

- The /p parameter tells the terminal what to do after the file is loaded.
For all but the last file, the parameter is /pwait which tells the terminal
to wait because more files will be loaded. For the last file, the parameter
is /pboot which tells the terminal to reboot after the file is loaded.

- The /x parameter, used with every call to loader tells the LOADER program
itself to automatically exit when the load is complete - rather than wait
for the user to press a key. This is necessary in order to automate the
loading of all files.

- The /s parameter, used on all but the first call to loader, tells the
terminal that the FLASHLDR.BIN file is already loaded and started in the
terminal (due to a prior run of loader which specified /pwait) and therefore
it should not be reloaded. If /s is omitted, as is the case for the first
call to loader, then loader will first send FLASHLDR.BIN to the terminal
and start it before loading the specified file.

- The /a parameter is used in conjunction with the /pboot parameter. It tells
the terminal which application to run after the terminal boots. We always
want to run DOS - which is why /ados.bin is specified.

- This batch file ships with the 'goto skipdos' statement set up to skip the
loading of DOS files. If you need to load the DOS files as well and you
have those files, simply comment out (precede it with REM) or delete the
'goto skipdos' command.

Before the DOWNLOAD.BAT file can be run, the terminal must be put into its
loading mode. This can be done using the following path through the Antares
menus:

MAIN -> SYSTEM -> UPGRADE FIRMWARE

For instructions about navigating the menus, making and saving changes, see
Using the Antares Menus and the SETUPANT.EXE Utility.

Respond OK to the first confirmation prompt. Respond Yes to the second
confirmation prompt. The terminal will then reboot and show a screen
that says 'LOADER WAITING'.

If the terminal is attached properly to the PC with the appropriate serial
cable. DOWNLOAD.BAT can now be run from the PC to load all the files. By
default, the loader program talks to COM1 and runs at a baud rate of 38400.
The port to use can be changed by using one of the following parameters when
running DOWNLOAD.BAT:

/com2 /com3 /com4

The baud rate to use can be changed by using one of the following parameters
when running DOWNLOAD.BAT:

/b9600 /b19200 /b57600 /b115200

For example, to download to COM2 using a baud rate of 115200, enter:

download /com2 /b115200

or to download to COM1 (the default) using a baud rate of 57600, enter

download /b57600

With a good cable, you should be able to run at a baud rate of 115200 - even
in a DOS window of Windows NT/2000. But if you get communications errors,
try reducing the baud rate.

Once DOWNLOAD.BAT is started, all files should load automatically and at the
end the terminal will reboot and start DOS. If none of the DCConnect
Client files were on the terminal before the load, the terminal will boot
to an A: prompt. This is when you would run S.BAT as is described towards the
end of Using the Antares Menus and the SETUPANT.EXE Utility.

Loading One or Two Files at a Time (LOAD1.BAT and LOAD2.BAT)
------------------------------------------------------------
After the terminal has been downloaded, you may eventually need to update
one or two files, perhaps due to a change needed in the configuration or
an update to the DCConnect Client program. Rather than redownloading all
files to all affected terminals, you could use the batch files LOAD1.BAT or
LOAD2.BAT to download the specific one or two files that need to be updated.

LOAD1.BAT and LOAD2.BAT are included where the Client is installed, in
in the ANTARES directory. As you might expect, LOAD1.BAT takes a single
parameter - the name of the file to be loaded and LOAD2.BAT takes two
parameters - the names of two files that are to be loaded. Before running
either of these batch files, the terminal must be put into loader mode -
just as is required when running DOWNLOAD.BAT or loading Intermec Antares
flash.

As is the case with DOWNLOAD.BAT, communcations with the terminal
defaults to using COM1 and a baud rate of 38400. If you need to override
this uses the same /com? and /b? parameters described above for DOWNLOAD.BAT -
but use them AFTER the file name(s) that are listed. For example to
reload just ETSPT.EXE and use COM2, run:

load1 etspt.exe /com2

or to load both etspt.exe and emulator.ini to COM2 running at a baud
rate of 19200, run:

load2 etspt.exe emulator.ini /com2 /b19200

If you get communications errors during the download, trying reducing
the baud rate.

Uploading or Downloading Files Using T24FCOPY.EXE
-------------------------------------------------
Intermec provides a second graphical utility, which runs on Windows 95/98/NT/2000,
for downloading/uploading individual files to/from the terminal. It is
called T24FCOPY.EXE - or more genericly, the FileCopy utility.

FileCopy does not require that the terminal be in loader mode - in fact the
terminal should not be in loader mode to use the utility. Instead, you must
set the communications parameters in the terminal for the terminal's COM1
port to match those used by the FileCopy utility. The instructions below
describe the use of this utility:

1) Be sure the Antares terminal is attached to the PC using the appropriate
serial cable described in the hardware requirements section above.

2) Be sure the terminal's serial port is configured for the correct protocol
and communications parameters:

Protocol = Polling Mode D
Baud Rate = 38400
Flow Control = XON/XOFF Rep and Cntrl

These communications parameters are set in the Antares menus using
the following menu hierarchy:

MAIN -> CONFIGURATION MENU -> COMMUNICATIONS MENU -> SERIAL PORT [COM1]

If you use the utility SETUPANT.EXE which is provided with the Client files,
these parameters can be set up without having to go into the menus. For
information about the using the menus and about the SETUPANT.EXE utility,
see Using the Antares Menus and the SETUPANT.EXE Utility.

3) On the PC side, you'll need the T24FCOPY utility - which can be found where
the Client files are installed, in the ANTARES subdirectory. Copy both
T24FCOPY.EXE and T24FCOPY.HLP. This program runs under Windows NT/95/98/2000.

4) When this utility is started, you are presented with a 3 page notebook, the
first of which specifies the source and target files. The second page is
the 'COM Port Setup' and should only need to be set up once with the
following values:

a) PC COM Port = COM1 (or whichever port on your PC is being used)
b) TRAKKER COM Port = COM1
c) Communication Protocol = Polling Mode D
d) File Transfer Protocol = YModem
e) Baud Rate = 38400

The third page, 'Serial Communication Setup' does not have any parameters to
be set because Polling Mode D is the protocol in use.

5) Once the communication parameters are set up, it's time to select the
source file and target file. The source file can be anywhere on your PC.
The target file must be specified to go into the root directory of the C:
drive on the Antares terminal. In fact, the Antares terminal does not
support subdirectories.

6) When the source and target file names have been specified, make sure none
of the check boxes on the right hand side are checked (particularly the one
to 'Convert .EXE') and then press the Download button. If communications
to the terminal are set up properly and the cable is attached, a second
window comes up which shows a status bar for the progress of the copy.

7) Each file must be copied separately in this manner. The drop down lists
for the source and target file names list recently used names.

While the FileCopy utility could actually be used while the Client is
running, it is recommended that the terminal be at a DOS prompt whenever a
file is downloaded/uploaded to/from it using this utility.

Loading DOS files to an Antares Terminal
----------------------------------------
When shipped from the factory, Intermec should have included the DOS files
in the terminal load, provided the terminal was ordered with the proper
options. For information about the options to use, please see
Hardware and Software Requirements for Antares Terminals.

It's also possible for a terminal that was loaded with DOS to be shipped
to Intermec for service and then to be reflashed by Intermec without the
DOS files.

In these situations you will of course need to get the DOS files if you do
not already have them. You must contact Intermec support to get them because
Intermec must pay royalties for every copy used. There are four files required:

DRIVEA.BIN
ROM-DOS.IMG
DOS.BIN
DRIVEB.IMG

A fifth file, LISTFILE.DOS, is needed in order to load the files to the
terminal but it is not loaded to the terminal itself. LISTFILE.DOS is
provided with the DCConnect Client in the ANTARES directory.

Once you have them, the best way to load the DOS files to the terminal is
to incorporate them into the loading of the DCConnect Client files.
In the section Transferring Files to an Antares Terminal
above, there is a discussion about how to use DOWNLOAD.BAT to load the
DCConnect Client files to Antares terminals. You'll notice that the
default DOWNLOAD.BAT (SAMPLE\DOWNLOAD.BAT) contains a 'goto skipdos'
statement which prevents the loading of DOS by default.

So once the DOS files are copied to the same directory as DOWNLOAD.BAT and
LISTFILE.DOS, all you have to do is comment out or remove the 'goto skipdos'
line in DOWNLOAD.BAT and the loading of DOS files will be set up to occur
when all the DCConnect Client files are loaded to the terminal.

Note: The use of LISTFILE.DOS is required in order to properly load the DOS
files to the terminal because DRIVEA.BIN is loaded to a special place
on the terminal which can only be accomplished using a list file.

Loading Intermec Flash to an Antares Terminal
---------------------------------------------
While the Antares terminal should be shipped with the appropriate flash
level there may be situations where terminals will need to be upgraded to
a newer version of Antares flash.

Flash images are typically distributed by Intermec Support or are downloadable
from Intermec's website as a single self-extracting executable file.

That self-extracting executable should be copied to its own folder/directory
and then it should be run to expand itself. The self-extracting executable
expands to several files including INSTALL.BAT and another self-extracting
executable. Simply run INSTALL.BAT and it will expand all the necessary
files into a directory with a name similar to:

C:\TKV70198

where the 70198 indicates a version number such as 7.01.98.

This directory will contain around 100 files, including UPGRADE.BAT which is
what you will run in order to load the terminal once it is put into loader
mode. Putting the terminal into loader mode is done using the following
path through the Antares menus:

MAIN -> SYSTEM -> UPGRADE FIRMWARE

For instructions about navigating the menus, making and saving changes, see
Using the Antares Menus and the SETUPANT.EXE Utility.

Respond OK to the first confirmation prompt. Respond Yes to the second
confirmation prompt. The terminal will then reboot and show a screen
that says 'LOADER WAITING'.

You are now ready to run UPGRADE.BAT. However, how you run UPGRADE.BAT
depends on what level of flash you are loading. Versions of Intermec
flash up to at least 7.01.00 included an UPGRADE.BAT that required a
program called CHOICE.COM that was used to prompt the user for 4
different options:

1) Which COM port to use (COM1 - COM4)
2) What baud rate to use (9600, 19200, 38400, 57600, 115200)
3) What software stack to use (UDP plus, TCP or BATCH)
4) What communications hardware to use (Proxim OpenAir radio, 802.11, Ethernet)

For some reason CHOICE.COM was not included as part of the flash load - but
it can be downloaded from Intermec's website. There were older versions of
CHOICE.COM that did not work on Windows NT/2000 but the latest one from
Intermec's website should work.

Intermec is supposed to be shipping newer versions of their flash with a
new version of UPGRADE.BAT that does not require CHOICE.COM. Instead the 4
parameters are passed on the command line when UPGRADE.BAT is run. This
version of UPGRADE.BAT is also provided with the Client product files,
in ANTARES\SAMPLE directory.

Only if you have a version of flash that requires the use of CHOICE.COM,
should you copy the UPGRADE.BAT from the product files' ANTARES\SAMPLE
directory to the flash directory.

When you run UPGRADE.BAT specify the four parameters from the
following choices (upper or lower case):

1) com1 com2 com3 com4 << You'll usually use COM1
2) 9600 19200 38400 57600 115200 << 38400 should work most of the time
3) udp tcp batch wtp << Use tcp unless batch terminal
4) prx 802 eth << Pick radio type or 'eth' if hard-wired ethernet

For example to load an Antares that has an 802.11 radio using COM1 run:

upgrade com1 38400 tcp 802

If you get communications errors, try reducing the baud rate.

If you have to rety the load process, be sure to turn off the terminal and
back on again so that it properly restarts the load process.

The flash load usually takes 5-6 minutes at a baud rate of 38400. When
the flash load completes, the terminal will reboot automatically and
will end up on a screen that shows a date and time at the top.

You will now be ready to load the DCConnect Client files and, if necessary, the
DOS files to the terminal. For instructions about how to do this please see
Transferring Files to an Antares Terminal.

Antares CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
----------------------------------------------------------
Unlike most of the other devices supported by the Client, there is nothing
in the CONFIG.SYS and AUTOEXEC.BAT files for the Antares terminals that needs
to be changed in order to support the Client. In fact, these files are on
the read-only A: drive and cannot be changed.

The AUTOEXEC.BAT on drive A: does make a call to C:\USER.BAT at the very end,
if that file exists. This allows an application to be started automatically
whenever DOS is rebooted. In order to start the DCConnect Client
automatically, you should create a USER.BAT that will be downloaded to drive C:
and it should contain the following simple line:

call em

This calls EM.BAT which is the standard method that is used throughout this
document for starting the DCConnect Client - regardless of the device it is
running on. The content of EM.BAT is discussed later in the section,
Setting Up an Antares Terminal from Scratch.

Network and radio configuration for Antares terminals is done through the
Antares menus or using the SETUPANT.EXE utility provided with the Client.
This is also how other parameters such as those for active bar code
symbologies, preamble, postamble, scanner, display, beeper volume, ...
are set up.

The recommended method for configuration all of these parameters is
through the use of SETUPANT.EXE and its configuration file. This method
allows you to automate the configuration of all of your terminals.
For instructions about using the menus and about using this utility, see
Using the Antares Menus and the SETUPANT.EXE Utility.

If the Antares terminal will be communicating with the data collection server
using TCP/IP, then from the following menu:

MAIN -> CONFIGURATION -> COMMUNICATIONS -> PRIMARY NETWORK

you will need to set the following parameters:

1) 'Activate' the radio / ethernet port
2) Set the 'Host IP Addr' to the IP address of the DCConnect Server
3) Set the 'Terminal IP Address' to the appropriate value for the terminal -
which should match the value configured for this terminal in the DCConnect
Server.

In addition, from the following menu:

MAIN -> CONFIGURATION -> COMMUNICATIONS -> ADVANCED NETWORK

you will need to set the following parameters:

1) 'Network port' must match the 'TCP/IP Port' value configured for the
DCConnect Server. This value is typically 7500. Note that Antares
terminals must use the same port number as the host application (DCConnect
Server) to which they are communicating otherwise a connection cannot be
made. (This is different from most of the other terminals supported by
the Client which can have port numbers different from the DCConnect
Server).
2) 'Subnet mask' must be set to what is appropriate for your network
3) 'Default router' must be set to what is appropriate for your network

If the Antares device you are using has a Proxim OpenAir radio in it then
from the following menu:

MAIN -> CONFIGURATION -> COMMUNICATIONS -> RADIO

you will need to set the following parameters at a minimum:

1) 'Domain' must be set to match the domain value configured in the access
points through which the terminals will be communicating.
2) The 'Security ID' must also be set to match the access points'
configuration. You won't be able to see the current value of the security
ID when on the Radio screen. Just set it to what it should be. If it
should be blank, use the backspace key to clear out the field.

But if the Antares device you are using has an 802.11 radio in it then
from the same radio menu you will instead have to set the following
options at a minimum, making sure that they match the settings in the
access points:

1) AP Density
2) Medium Reservation
3) Reservation Threshold
4) Network Name

Other parameters may need to be tweaked based on the network setup. Consult
the Antares manual for more information about all of the parameters in these
menus.

IMPORTANT NOTE: When using SETUPANT.INI to configure terminals be sure that
you only include parameters that are appropriate for the
model of Antares terminal that will be processing it. For
example, if the terminal is ethernet attached (and therefore
does not have a radio) make sure no radio configuration
parameters are included. We have seen cases where setting
inappropriate parameters have caused intermittent problems
on the network - eventually causing terminals to lock up
after a couple of days.

Antares Bar Code Configuration
------------------------------
By default, Antares terminals have the following bar code symbologies active:

Code 39
Code 128
UPC / EAN

Using the Antares menus, options for these symbologies can be changed and any
of the following additional symbologies can be activated:

Codabar
Code 11
Code 49
Code 93
Code 16K
2of5 / I 2of5
MSI
Plessey

Changes to the bar code Symbology configuration can be made using the following
wpath in the Antares menus:

MAIN -> CONFIGURATION -> SYMBOLOGIES

Instead of using the menus, the utility SETUPANT.EXE, which is provided with
the Client, can be used to configure changes to the symbologies. Using
this utility allows you to automate the configuration of all terminals.
For instructions about using the menus and the SETUPANT.EXE utility, see
Using the Antares Menus and the SETUPANT.EXE Utility.

The Antares terminal supports the use of preamble and postamble characters.
Therefore it is recommended that the terminal be configured to use them along
with the keyword SCAN_SENTINEL_CHARS in EMULATOR.INI. This will provide
better enforcement of scan lengths by the Client and it will allow the
Client to be able to distinguish between keyboard and scanned data.

For more information about the SCAN_SENTINEL_CHARS keyword and its benefits,
please see, Keyword: SCAN_SENTINEL_CHARS.

To configure the preamble and postamble characters in the Antares terminal,
you can use the following path through the Antares menus:

MAIN -> CONFIGURATION -> TERMINAL -> PREAMBLE / POSTAMBLE

However, it is recommended that you instead use the SETUPANT.EXE utility to
configure the preamble and postamble along with all the rest of the terminal
parameters. For instructions about using the menus and the SETUPANT.EXE utility,
see Using the Antares Menus and the SETUPANT.EXE Utility.

Serial Port Use on the Antares Terminal
---------------------------------------
The COM1 serial port on the Antares terminals can be used by the Client to
communicate with devices such as a serial printer or scale.

The serial flavor of the Client can also be used if the terminal is to
communicate to the data collection server via the serial port instead of
over ethernet or radio.

In all cases, it is not necessary to configure the serial port using the
Antares menus. Instead the Client will configure the serial port based on
the command line / EMULATOR.INI parameters (for the serial flavor of
the Client) or based on the downloaded serial port configuration (when the
serial port is used to talk to another device such as a printer or scale).

A word of caution regarding the use of the Client to communicate with
DCConnect via the serial port on the Antares terminal: because the 'hard drive'
of the Antares is a flash drive operations to update it are relatively slow -
which can interfere with the terminal's responsiveness to DCConnect polls.

In order to ensure data integrity for transactions that are generated, all
transactions are written to a log file on the flash drive. The file must be
closed and reopened in order to ensure the data is on the disk. The close and
reopen process can take a second or more. During this time, the terminal is
only writing to the flash; reading of the serial port is basically suspended.
So there are often times when the terminal will not respond to one or more
polls. And if the write operation takes long enough, the terminal might miss
several polls in a row - causing DCConnect to briefly put the terminal into
the 'Not responding' state. After the next 'slow poll rate' interval (which
by default is one minute) DCConnect will try to talk to the terminal again -
which will usually result in the terminal being put back into service.

To help reduce the chance that the terminal will miss enough polls to be put
into the not responding state, the Poll Timeout for the appropriate serial
line(s) should be increased from the default of 0.5 seconds to 1.0 or even
1.5 seconds - in the DCConnect configuration. The benefit to this is that
terminals will be less likely to be put into the 'Not responding' state.
The downside is that DCConnect will spend more time trying to talk to any
terminals that are configured but which are not communicating. If all
terminals on the line are communicating, then the longer timeout should not
be a problem.

Note: The delays in writing transactions to the flash drive also exist
when running the TCP/IP flavor of the Client. However, they don't present
the same communications problem because when communicating over TCP/IP the
terminal is not continuously being polled. Therefore there is no need for the
terminal to quickly respond to a poll.

Digital I/O Use on the Antares Terminal
---------------------------------------
While some of the models of Antares terminals have digital I/O ports, the
DCConnect Client does not currently support access to those ports from
transaction programs or CFRs.

Starting the Client on an Antares Terminal
------------------------------------------
Since the Antares terminals have only one writable drive (C:) and subdirectories
are not supported, the Client, the file ETSCHECK.LIC and any configuration files
should be copied to that drive along with any configuration file(s).

Depending on which model of Antares terminal is being used, a different 'device'
command line parameter must be used. You also have the option to use the
DEVICE= keyword in EMULATOR.INI instead of using the -d command line option.

The only differences between the valid Antares device parameters is the
screen size:

For Antares models 2410, 2415, 2420, 2425 and 2435 use the following device
parameter:

-dANTARES16x20

For Antares models 2455, 2481 and 2486 use one of the following two parameters,
depending on which Font Type is being used on the terminal (8x8 or 8x16):

-dANTARES20x40
-dANTARES12x40

Use a Font Type of 8x8 with ANTARES20x40 and use a Font Type of 8x16 with
the device keyword ANTARES12x40. The Font Type is changed in the Antares menus
using the following path:

MAIN -> CONFIGURATION -> TERMINAL -> DISPLAY

The Font Type setting can also be configured using the SETUPANT.EXE utility.
For instructions about using the menus and about using the SETUPANT.EXE utility,
see Using the Antares Menus and the SETUPANT.EXE Utility.

For Antares models 2460 and 2461 use the following device parameter:

-dANTARES2x16

For Antares modes 2480 and 2485 use the following device parameter:

-dANTARES4x40

The model 2435 allows for more combinations of row-column dimensions than the
set of valid ANTARESrrXcc device parameters include. If the Antares will
be configured to use a different row-column combination, you can pick any
ANTARES device parameter and then override the row and/or column setting by
adding one or both of the following keywords to EMULATOR.INI:

NUM_ROWS
NUM_COLS

For more details about these EMULATOR.INI parameters please see
Configuration using EMULATOR.INI.

For more details about this and other command line parameters, see the earlier
section called Common Command Line Parameters for the Client.

Setting Up an Antares Terminal from Scratch
-------------------------------------------
This section describes suggested steps to take an out-of-the-box Antares
terminal and set it up so that the Client can run on it. These instructions
assume the terminal is already preloaded with DOS files. If that is not the
cases, please read about what files are needed and where to get them in the
section Loading DOS files to an Antares Terminal.

An Antares with DOS files already loaded will have the following files on the
A: drive:

ANTIFS.EXE AUTOEXEC.BAT COMMAND.COM CONFIG.SYS

and the following files on the C: drive (the first two aren't DOS-specific):

APPTSK.BIN EM9560.BIN ROM-DOS.IMG DOS.BIN DRIVEB.IMG

The instructions below for loading the terminal will use the LOADER utility and
corresponding DOWNLOAD.BAT file instead of the T24FCOPY utility because the
former method is more automated - and it is assumed a more automated process is
preferred when many terminals need to be set up.

1) To start, create a new, empty directory on your PC for collecting all the
files that will be transferred to the Antares terminal. This example
will use C:\ANT_LOAD.

If you have more than one model of Antares terminal you may need to
set up separate directories for each model. The differences that are
important are:

a) Difference in screen size because a different DEVICE = parameter is
needed in EMULATOR.INI, depending on the screen size:

ANTARES16x20
ANTARES20x40
ANTARES12x40
ANTARES2x16
ANTARES4x40

If the screen size used by a particular device is not represented
in the list above you can override the row and/or column values
using the NUM_ROWS and/or NUM_COLS keywords in EMULATOR.INI.

b) Differences in the way the terminal communicates to DCConnect:

- Using an RF radio
- Directly attached via Ethernet
- Directly attached using a serial port

This difference matters for a couple of reasons:

1) The first two ways require the use of ETSPT.EXE and the last
requires the use of ETSPB.EXE (which affects what goes into EM.BAT).
2) The contents of SETUPANT.INI will be different for each:

- If using RF, radio parameters must be set (e.g domain or network name)
and TCP/IP network parameters such as router, host IP
address and subnet mask must be set.
- If attached directly via Ethernet, radio parameters are not needed.
But the TCP/IP network parameters are.
- If attached using the serial port, no radio or network parameters
are needed.

If you do not want to create separate directories for each set of download
files, you could keep all the files in the same directory and create
separate EMULATOR.INI files with different names based on the screen size
to be used. For example:

EM16x20.INI (includes DEVICE=ANTARES16x20)
EM20x40.INI (includes DEVICE=ANTARES20x40)
EM12x40.INI (includes DEVICE=ANTARES12x40)
EM2x16.INI (includes DEVICE=ANTARES2x16)
EM4x40.INI (includes DEVICE=ANTARES4x40)
EM20x21.INI (includes DEVICE=ANTARES16x20 and NUM_ROWS=20 and NUM_COLS=21)

and create separate SETUPANT.INI files with different names based on the
method of attachment:

SETUPANT.PRX (includes Proxim OpenAir radio and network parameters)
SETUPANT.802 (includes Lucent 802.11 radio and network parameters)
SETUPANT.ETH (includes network parameters but no radio parameters)
SETUPANT.SER (includes no radio parameters or network parameters)

If you will devices communicating to the DCConnect Client both serially and
over TCP/IP you could create two different flavors of EM.BAT to cover both:

EM.SER (calls etspb.exe)
EM.TCP (calls etspt.exe)

(Most likely you'll only ever have TCP/IP connected terminals and would
only have an EM.BAT that calls etspt.exe).

All the rest of the files to be downloaded would be the same. To make
the loading of the different models of terminals easy, you should set
up batch files that copy the appropriate flavors of EMULATOR.INI,
SETUPANT.INI and EM.BAT and then call DOWNLOAD.BAT. For example, if
you have 2425 terminals with 802.11 radios, you could set up
LOAD2425.BAT that does the following:

copy em16x20.ini emulator.ini
copy setupant.802 setupant.ini
copy em.tcp em.bat
call download.bat %1 %2

and if you had 2480 terminals (ethernet attached) with 4x40 displays
you could set up LOAD2480.BAT that does the following:

copy em4x40.ini emulator.ini
copy setupant.eth setupant.ini
copy em.tcp em.bat
call download.bat %1 %2

and if you had 2410 terminals to be used as batch terminals you could
set up LOAD2410.BAT that does the following:

copy em16x20.ini emulator.ini
copy setupant.ser setupant.ini
copy em.ser em.bat
call download.bat %1 %2

In all 3 of the above examples, DOWNLOAD.BAT is the same because it
uses the EMULATOR.INI, SETUPANT.INI and EM.BAT that are set up when
it is called. The %1 and %2 that follow the call to DOWNLOAD.BAT
are for passing the optional /com? or /bbaudrate parameter to
download.bat.

Using all of these different names may be a bit confusing to set up in
the first place but it will make things simpler when it comes time to
actually load all of the terminals.

In order to simplify the remaining instructions, it will be assumed that
only one model of Antares is being used and thus only one flavor of
EM.BAT and SETUPANT.INI will be created in the steps below.

These instructions also assume you are doing this for the first time
and as a result none of the files already exist on your PC.

2) Copy into that directory the following loader-related files and terminal
configuration utility files from the directory where the Client is
installed:

ANTARES\LOADER.EXE
ANTARES\FLASHLDR.BIN
ANTARES\SETUPANT.EXE

ANTARES\SAMPLE\DOWNLOAD.BAT
ANTARES\SAMPLE\SETUPANT.INI
ANTARES\SAMPLE\EMULATOR.INI
ANTARES\SAMPLE\S.BAT

ANTARES\USER.BAT

all files from the ANTARES\SAMPLE directory are samples that you may
have to customize. They are put into the ANTARES\SAMPLE directory
so that the entire ANTARES directory and it subdirectories can be
copied from future CDs and fix packs without overwriting the customized
.BAT and .INI files.

3) Now copy the license file from the root directory where the DCConnect
Client is installed:

ETSCHECK.LIC

4) If the terminal will be communicating with the DCConnect Server over the
serial port, copy the following executable from the directory where
the Client is installed:

ANTARES\ETSPB.EXE

Otherwise the terminal will be communicating directly over Ethernet or
using a radio. In this case copy the following executable:

ANTARES\ETSPT.EXE

5) Now all the product files have been copied. Some of them have to
be customized, starting with SETUPANT.INI. This file contains commands
that are issued to the Antares terminal to configure certain parameters.
For more information about the format of this file and how it is used, see
Using the Antares Menus and the SETUPANT.EXE Utility.

Start your favorite text editor and make the following changes to
SETUPANT.INI.

Note: Do not change the order of the commands that are already in the
file. Certain commands must be done in a particular order or they
will not work.

a) If using the serial flavor of the Client, comment out the commands
that relate to TCP/IP and radio configuration. This can be done by
placing // in front of each line that contains a command that
starts with $+. For example, if the file contains the following two
lines:

// Subnet mask
$+NS255.255.240.0

Then to comment out this command for setting the subnet mask would
result in the following difference:

// Subnet mask
// $+NS255.255.240.0

The commands that should be commented out are for the following
parameters:

Subnet Mask
Default router
Host IP Address
Network Port
Lucent 802.11: AP Density
Lucent 802.11: Medium Reservation
Lucent 802.11: Reservation Threshold
Lucent 802.11: Network Name
Lucent 802.11: Power Management
Lucent 802.11: Receive All Multicasts
Proxim Open Air: Radio Domain value
Activate RF / Ethernet network communications
Proxim Open Air: Radio security ID

b) If the Antares terminal will be communicating using Ethernet or a radio,
set the proper values for the following parameters:

Subnet Mask << Choose the value that is proper for your network
Default router << Choose the value that is proper for your network
Host IP Address << Enter the DCConnect Server IP address here
Network Port << Enter the TCP/IP Port Number used by the
DCConnect Server. It defaults to 7500, but
can be changed using the System -> Options
notebook and going to page 1 of the Options
tab.

(No need to change the 'Activate RF / Ethernet network communications'
parameter because it is already properly set.)

c) If you are using an Antares terminal that is attached via Ethernet and
does not have a radio, then comment out the following parameters:

Lucent 802.11: AP Density
Lucent 802.11: Medium Reservation
Lucent 802.11: Reservation Threshold
Lucent 802.11: Network Name
Lucent 802.11: Power Management
Lucent 802.11: Receive All Multicasts
Proxim Open Air: Radio Domain value
Proxim Open Air: Radio security ID

But if the Antares terminal has a Lucent 802.11 radio or Proxim OpenAir
radio, be sure to set the appropriate raido specific parameters to match
the settings of the access points. Also be sure to comment out the
parameters for the radio that is not appropriate.

d) In most cases, the font size to use will be 8x8 in order maximize
the number of rows and columns available on the screen. But if that
is not the case for your terminals, change the font size setting as
needed. Make a note of what dimensions the font size results in so
that the DEVICE, NUM_ROWS and NUM_COLS parameters can be properly
set later in EMULATOR.INI.

e) Set the beeper volume as needed, using the values explained in the
SETUPANT.INI file.

f) You should not change the values for the serial port Protocol, Baud Rate
or Flow Control. The default settings for these parameters in the .INI
file are set up so that the file copy utility T24FCOPY.EXE could be used
if necessary.

If the DCConnect Client needs to use the serial port - whether it is the
serial flavor of the Client or the TCP/IP flavor talking to a serial
device - the Client will reconfigure the port based on parameters that
are provided to it in EMULATOR.INI or via download. When the Client
exits, it restores the serial port parameters to what they were before it
changed them.

g) The Preamble and Postamble characters default to \x01 and \x02
respectively. It is recommended that these settings not be changed in
order to make the best use of the scanner. But be sure to add the
SCAN_SENTINEL_CHARS keyword to EMULATOR.INI when it is set up in the
steps below.

h) If any changes are needed to other parameters in the Antares configuration,
such as parameters for bar code symbologies, extra commands can be added
to the end of the file. Refer to the Antares 24xx User's Guide for
information about the syntax of any additional commands.

6) Now it is time to customize EMULATOR.INI with whatever parameters are
needed. For information about what parameters can be set in this file,
see Configuration using EMULATOR.INI.

First set the DEVICE parameter to match the screen dimensions of the
terminal. For example:

DEVICE = ANTARES16x20

If none are appropriate for the number of rows and columns
that will be visible, then pick any of the ANTARESrrXcc values for
DEVICE and then override the row and/or column values using commands
similar to the following:

NUM_ROWS = 16
NUM_COLS = 20

It is recommended that the following statements also be included to
maximize the amount of space that is available in the terminal for files
that will be downloaded:

NUM_PF_STRINGS = 0
NUM_TOUCH_STRINGS = 0
MAX_TRANSACTIONS = 10

Of course, if more than 10 (actually 9) transactions have to be buffered
at a time, adjust the value for MAX_TRANSACTIONS accordingly. The
maximum value is 500. However, if you find you cannot download all of
your transaction programs and the rest of the terminal configuration
from DCConnect, you may have to reduce this number.

Remember if you left the Preamble and Postamble configuration commands
uncommented in the SETUPANT.INI file in the previous step, then be sure
the following statement is included in EMULATOR.INI:

SCAN_SENTINEL_CHARS = 1, 2

Many customers like to be able to use the larger numeric keys to start
transaction programs or select menu options - instead of making the
user press keys F1 through F10. If you need this capability, make
sure the following is included:

PF_MAPPING = Y

Because the Antares terminal has less available RAM than most
other terminals supported by the DCConnect Client, it will
likely be necessary to enable the FILE_PAGING feature in
which is done by adding:

FILE_PAGING = Y

to EMULATOR.INI. If enabled you might also need to use the
keyword LOCK_IN_MEMORY to list validation files that should
not be paged. For more information about these keywords please
see Keyword: FILE_PAGING
and Keyword: LOCK_IN_MEMORY.

For serial-attached terminals, be sure to add parameters for BAUD_RATE
and COM_PORT if the default values are not correct. An ADDRESS parameter
is also needed; however, it is different for every terminal so it can't
be included in the base EMULATOR.INI that will be loaded to every terminal.
But you can do something similar to the following in order to add the
ADDRESS parameter to the file at the time the terminal is downloaded:

a) Create EMULATOR.SER instead of EMULATOR.INI and include all necessary
keywords except for ADDRESS =

b) Change the appropriate LOAD24xx.BAT so that the first parameter is
the address character to use (A-Y, 0-6). Then in the LOAD24xx.BAT
DOWNLOAD.BAT before the step to load EMULATOR.INI to the terminal,
add the following two lines:

COPY EMULATOR.SER EMULATOR.INI
ECHO ADDRESS = %1 >> EMULATOR.INI

This will add an ADDRESS command to EMULATOR.INI based on the
parameter passed to LOAD24xx.BAT. (If you make this change, be sure
to change all prior occurrences of %2 to be %3 instead and change all
prior occurrences of %1 to be %2 instead).

Alternatively, S.BAT could be changed to do a similar set of steps when it
is run down in the terminal. In this case, EMULATOR.SER would be loaded
to the terminal instead of EMULATOR.INI.

7) The last terminal-resident file to set up is EM.BAT. The sample that is
provided with the Client (ANTARES\SAMPLE\EM.BAT) includes the following:

c:
cd\
etspt

You should not have to change this unless the terminal is communicating
with DCConnect over the serial port. In this case, replace the last
line with:

etspb

These examples do not use any command line parameters when starting the
Client because they are all set up in EMULATOR.INI per the instructions
above.

When running on Antares terminals, the command line parameters -p and -h
and their equivalents in EMULATOR.INI, TCPIP_PORT and TCPIP_HOST, are
not needed because these are set up as part of the Antares configuration
via SETUPANT.INI.

8) All files that are required are now set up, with one possible exception -
the DOWNLOAD.BAT file that will be used to load the terminal. A default
flavor of this file is provided with the Client
(as ANTARES\SAMPLE\DOWNLOAD.BAT) - and should already have been copied
to C:\ANT_LOAD in step 2 above. For a complete description of the
contents of this file and information about LOADER.EXE please see
Transferring Files to an Antares Terminal.

For TCP/IP you should not have to change this file.

But for serial attached terminals you will need to change the
reference to 'etspt.exe' (part of the 3rd loader command) to be
'etspb.exe'.

Assuming that you will be creating a LOAD24xx.BAT file as is described
above in steps 1b and 6b there should not be any other changes needed.

9) Now that DOWNLOAD.BAT is set up and we previously set up LOAD24xx.BAT
file(s), the LOAD24xx.BAT files can be run to load terminals - once
they have been put into 'loader' mode. For more details, please see
Transferring Files to an Antares Terminal.

Remember that for serial flavors, the terminal address character must be
provided as a parameter when you run the LOAD24xx.BAT or when running
S.BAT on the terminal.

10) After the download completes for each terminal, the terminal should
reboot automatically and run DOS, ending up at an A: prompt. At this
point S.BAT must be run on the terminal so that the terminal is
configured based on the commands in SETUPANT.INI. Remember for
Ethernet-attached or RF terminals, you must specify the terminal's
IP address as the command line parameter when running S.BAT. For example:

S 99.99.99.61

When the configuration completes, the Client should automatically be
started.

Using the DCConnect Client on Intermec Janus 2010/2020/2050 Terminals
---------------------------------------------------------------------
This section describes what additional configuration must be done when using
the DCConnect Client on one of the Intermec Janus terminals.

For more detailed information about using Janus terminals please refer to the
following sections:

- Hardware and Software Requirements for Janus Terminals
- Drive Arrangement on Janus Terminals
- Transferring Files to a Janus Terminal
- Janus CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
- Janus Bar Code Configuration
- Configuring the Janus Display and Viewport
- Serial Port Use on the Janus Terminal
- Starting the Client on the Janus Terminal
- Setting Up a Janus Terminal from Scratch

Hardware and Software Requirements for Janus Terminals
------------------------------------------------------
While not absolutely required, it is strongly recommended that a PCMCIA SRAM/
ATA/FLASH memory card be used in the Janus terminal. The memory card serves as
non-volatile storage for transactions that are generated by the Client.
Without it, transactions could be lost if all battery power in the terminal is
lost or if the terminal is cold-booted.

Use of a memory card also makes it much easier to update files on the Janus
terminal. Files can be copied to the card from a laptop or PC with a PCMCIA
drive. Flashing of the Janus read-only drives can also be done from the
memory card if it is loaded with the necessary flash utilities and drive
images.

The ATA memory card is the most cost-effective and appropriate kind of the
three types of memory cards and this kind of card does not require a battery
either. (SRAM cards require a battery and thus still have the potential to
lose data if the battery were to lose its charge). We used a 10MB ATA flash
card from SanDisk (formerly SunDisk) during our testing of Janus 2020
terminals. Please check with Intermec for recommended cards. Note that the
Janus 2010 terminal has a type I PCMCIA slot while the 2020 and 2050 models
have a type II PCMCIA slot.

Towards the end of 1998, Intermec talked of including both the FTP Software
drivers with the Janus terminal. If this becomes reality, then the TCP/IP
drivers from FTP Software do not need to be purchased separately. But if
these drivers are not included by Intermec, then they will have to be purchased
separately from FTP Software.

Intermec does provide the Novell TCP/IP drivers with the Janus terminal. A
flavor of the Client is provided that uses the Novell TCP/IP stack. If
this flavor is used, then TCP/IP drivers do not have to be purchased
separately. Another advantage of using the Novell drivers is that they
consume almost 60K less of RAM - which means more RAM is available for the
DCConnect Client to use.

In order to load the Janus terminal, it must be serially attached to a DOS
PC because the DOS utility INTERSVR.EXE is required for some of the steps of
the configuration process (all of the steps if a memory card is not being used).
This utility is not part of Windows 95/98/NT or OS/2. However we have found
that INTERSVR.EXE will run under Windows 95, if you have it to copy there.

If you will be using a memory card, you will need some PC or laptop that has
an appropriate PCMCIA card slot and drivers for the operating system on that
PC / laptop that support the memory card. Check with the manufacturer of the
memory card for the necessary drivers for your operating system.

Drive Arrangement on Janus Terminals
------------------------------------
The Janus terminal defaults to having a C: D: and E: drive. However an
F: or G: can be added by installing a PCMCIA SRAM/ATA/FLASH memory card
On a Janus 2010/2020, the memory card will be drive F: if it is put into the
type I PC card drive or it will be drive G: if it is put into the type II PC
card drive. On the Janus 2050, the memory card is always drive G:

Most of the discussion of Janus terminals in this document assumes a memory
card will be used.

Drives C: and D: are read-only in the terminal. Special utilities, provided
with the Janus terminal, are used to build and load the images for drives C:
and D:.

Drive E: is a RAM drive. If no memory card is installed, then drive E:
is the only drive that can be written to during normal terminal use. With no
other writable drive available, the Client must be run with drive E: as
the current drive because the Client stores transactions on 'disk' in the
drive and directory which is current when the Client is started.

However drive E: is not a non-volatile drive; its contents can be lost if
all battery power in the terminal runs out or if the terminal is cold-booted.

Because of the possiblity that transactions might be lost on a RAM drive, it
is recommended that a memory card be used to provide non-volatile storage.
With an ATA memory card installed, a drive F: or G: will now be available
and the Client should be started when this drive is the current drive so
that transactions can be saved to non-volatile storage.

Use of a memory card has other benefits:

- It is easier to put updated versions of the Client and the various
terminal configuration files on a memory card than it is to serially
attach the terminal and reload an entire drive. You will still have to load
each terminal at least once serially after you've set up the C: and D:
drives so that they run the changeable programs from the memory card.
However, after each terminal's initial loading via the serial port, all
future updates to the terminal could be done via the memory card.

- The reflashing of C: and D: drives can actually be done by copying the
appropriate files to the memory card, inserting the memory card into the
terminal and running the appropriate flashing software from the card.

Consult the Janus documentation for more information about the use of PCMCIA
memory cards and ways to flash the read-only C: and D: drives.

Transferring Files to a Janus Terminal
--------------------------------------
The Janus User's Guide describes how to transfer files between a PC
and the Janus terminal. Use of INTERLNK.EXE and INTERSVR.EXE is described in
Chapter 6 in the section "Running Interlnk to Transfer Files. Files can be
transferred using a serial cable between the PC and the Janus docking station
or over the network once the base communication files have been set up. If a
PCMCIA memory card is installed, files can be copied directly to that card when
it is inserted into a PC's PCMCIA slot (provided the proper PCMCIA memory card
drivers are installed).

The Janus User's Guide describes a couple of different ways of reflashing the
C: and D: drives. But the best method is not really described in the book,
although it does require the use of a utility called LOADER.EXE that is
provided by Intermec on its utility diskettes / CD. Before running LOADER
you must use another Intermec utility called MAKEDISK.EXE to create the
image file from a set of files in a directory on the PC.

For example, if the current directory is C:\ and all files that should be part
of the drive C: image are located in C:\JANUS_C then run the following on the
PC at the DOS command line:

makedisk /s=c:\janus_c /o=drivec.img

(you may need to specify a path for the location of MAKEDISK.EXE if it is not
in the current directory). This call will create a file called DRIVEC.IMG.

In order to create an image for the terminal's D: drive from files that are
located in C:\JANUS_D, run the following:

makedisk /s=c:\janus_d /d=d /o=drived.img

Note: the use of the /d=d parameter. Without it, makedisk assumes the image
will be for the C: drive of the Janus terminal.

Once the image files have been created, the LOADER.EXE utility can be run to
flash the terminal with these images. But the terminal must first be put into
a mode where it is prepared to be loaded. This is done as follows:

1) Turn the terminal off
2) Next you must press the following 3 keys together: F3 and 2 and left
arrow (don't confuse this with the backspace key). Start by pressing and
holding F3. While still holding F3, press and hold 2. While still holding
F3 and 2, press the Left arrow key and then release all 3 keys.
3) Now press and release the 2 key by itself.
4) Turn on the terminal; you should now see the BOOT LOADER menu.
5) On the BOOT LOADER menu use the arrow keys to highlight 'Load' and then
press Enter. The terminal is now ready to be loaded from the PC - provided
that is in a docking station or has an optical link adapter that is
attached serially to the PC.

Once the terminal is in loading mode and serial connection is set up to the
PC, the loader utility can be run to flash the C: and D: drives (this example
uses the names we used above when running makedisk):

loader /user=drivec.img /app=drived.img

If only C: drive is being flashed, leave off the /app=drived.img. Loader takes
other parameters for specify the COM port to use:

/com1
/com2
/com3
/com4

and for specifying the baud rate:

/b38400

By default COM1 is used and 57600 is used for the baud rate.

Note: Both MAKEDISK and LOADER will run in a DOS session of Windows/NT.
However, we have found that it was difficult to have LOADER complete
the flash process before ending with too many communications errors.
So we were forced for run LOADER on a PC that was booted from DOS.

If transferring files serially or flashing the terminal, a serial cable is
required and the one required is different depending on the terminal and
the docking station being used:

- For Janus 2010 or Janus 2020 terminal:

- If using a JD2010 Communications Dock you must connect the dock to the
host computer with a 3-wire (2, 3 and 7) cable in order for communications
to work properly. A standard null-modem cable will not work. From the
Janus 2010 User's Guide, the Intermec part numbers for the appropriate
cable are:

047569 for a 3-wire, 9-pin, null modem with DB9 PC connector
052477 for a 3-wire, 9-pin, null modem with DB25 PC connector

- If using a JL2010 Optical Link Adapter, a standard null-modem cable must
be used. From the Janus 2010 User's Guide, the Intermec part numbers
for the appropriate cable are:

059167 for a 5-wire, 9 pin, null modem with DB9 PC connector
048693 for a 7-wire, 25 pin, null modem with DB25 PC connector

- For Janus 2050 terminals:

- A special Janus 2050 null modem adapter cable is required. The Janus 2050
User's Guide lists the part number for this cable as: 063092.

The file JANUS.INI contains the hardware specific configuration information
such as barcodes in use, pre/postambles for bar codes, display size and
viewport configuration. This file can be updated by the IC.EXE utility which
is the Intermec configuration program that runs only on the Janus terminal.
You could also update this program with any text editor by using the
appropriate commands and parameters which are documented in the Janus User's
Guide.

For the best flexibility, the JANUS.INI file should be located on the
memory card drive - a non-volatile, writable drive. That way it can easily
be updated without having to reflash one of the terminal's read-only drives.

In version 4.06 of the Janus drive images, the JANUS.INI file does not
exist. However, using the save option of the IC.EXE utility on the terminal,
a default JANUS.INI file can be generated on a writable drive - preferably the
memory card drive. Once on the memory card, it can be easily transferred to a
PC for replication on other Janus terminals in the network.

If a memory card is not being used, then the JANUS.INI file must be saved to
the drive E:, the RAM drive. Then it can be transferred to the PC using the
INTERSVR.EXE / INTERLNK.EXE utilities as described in the Janus User's Guide.

CONFIG.SYS, AUTOEXEC.BAT and Network Configuration for Janus Terminals
----------------------------------------------------------------------
The following CONFIG.SYS file was used during our testing. It is unchanged
from the one provided in version 4.06 of the Intermec-supplied drive C: image:

REM *
REM * FILENAME: CONFIG.SYS
REM *
REM * PROD ID: J2020
REM *
REM * VERSION: 4.06b
REM *
REM * SETUP BOOT MENU ITEMS
[MENU]
MENUITEM=SRAM, SRAM PCCARD
MENUITEM=ATA, ATA PCCARD
MENUITEM=FLASH, FLASH PCCARD
MENUITEM=IO, I/O PCCARD
MENUITEM=NO, NO PCCARD
MENUCOLOR=15,0
*1 MENUDEFAULT=SRAM, 20

[COMMON]
REM * COMMON TO ALL CONFIGURATIONS

REM * SET ENVIRONMENT SIZE
SHELL=COMMAND.COM /E:2000 /P

DEVICE=D:\HIMEM.SYS /TESTMEM:OFF
DOS=HIGH

REM * LOAD APM POWER MANAGEMENT
DEVICE=D:\POWER.EXE /LOW

REM * LOAD DRIVE E: RAMDISK
*2 DEVICE=D:\SRAMDISK.SYS 256 512 /E

REM * REQUIRED TO RESUME PCCARD CONTROLLER
INSTALL=D:\CARD_SR.EXE

[SRAM]
REM * MEMORY CARDS
DEVICE=D:\CS.EXE /POLL:1
DEVICE=D:\CSALLOC.EXE D:\CSALLOC.INI
DEVICE=MTSRAM.EXE
DEVICE=MTDDRV.EXE

[ATA]
REM * ATA CARDS
DEVICE=D:\CS.EXE /POLL:1
DEVICE=D:\CSALLOC.EXE D:\CSALLOC.INI
DEVICE=D:\ATADRV.EXE /S:2
DEVICE=MTDDRV.EXE
DEVICE=D:\CARDID.EXE

[FLASH]
REM * FLASH CARDS
DEVICE=D:\CS.EXE /POLL:1
DEVICE=D:\CSALLOC.EXE D:\CSALLOC.INI
DEVICE=D:\MTI1.EXE
DEVICE=D:\MTI2P.EXE
DEVICE=MTDDRV.EXE
DEVICE=D:\FTL.EXE

[IO]
REM * I/O AND MEMORY CARDS
DEVICE=D:\CS.EXE /POLL:1
DEVICE=D:\CSALLOC.EXE D:\CSALLOC.INI
DEVICE=MTSRAM.EXE
DEVICE=MTDDRV.EXE
DEVICE=D:\CARDID.EXE

[NO]
REM * NO PCCARD CARDS

[COMMON]
REM * AUTO LOADER HOOK IF ACTIVE
*3 DEVICE=D:\INTERLNK.EXE /DRIVES:5 /NOPRINTER /COM:1 /AUTO

BUFFERS=10

REM * FOR INTERMEC IRL SUPPORT.
FILES=50

STACKS=9,256

REM * Needed for JRTE support.

LASTDRIVE = Z

A few notes about the above:

1) The MENUDEFAULT line should be changed based on the kind of memory card
that will be installed or if no memory card will be installed.
2) SRAMDISK.SYS is the driver to set up the drive E: RAM disk. If the size
of drive E: must be changed, change the parameters for this driver. Note
that the RAM drisk is created in extended memory (/E) so changing the size
will not affect available conventional memory in the terminal.
3) INTERLNK.EXE must be included in order to be able to copy files from the
terminal's drive C: or drive D: to a PC running INTERSVR.EXE under DOS.
Alternatively, the contents of drive C: or D: could be copied to the
memory card drive. This driver will unload itself if a connection is not
established with an INTERSVR program.
4) There are no network drivers in CONFIG.SYS

Following is the AUTOEXEC.BAT file that was used during our testing:

@ECHO OFF
CLS
:*
:* FILENAME: AUTOEXEC.BAT
:*
:* PRODUCT: J2020
:*
:* VERSION: 4.06b
:*
:* ------------- ! AUTO-INTERROGATING DRIVE C: INSTALLATION ! -------------
:*
:* INTERMEC AUTOMATIC DRIVE C: INSTALLER HOOK; (DO NOT REMOVE!)
:*
ECHO OFF
CLS
IF NOT EXIST AUTOINST.BAT GOTO T2
CALL AUTOINST
GOTO T3
:T2
*1 IF EXIST D:\AUTOINST.BAT CALL D:\AUTOINST
:T3
:*
:* ------------- AUTO-INTERROGATING DRIVE C: INSTALLATION ENDS -------------
SET PROMPT=$P$G
*2 PATH=C:\;D:\;E:\;F:\

REM * REQUIRED FOR MORE.COM TO WORK ON ROM DRIVES
SET TEMP=E:\

REM * USED BY READER SERVICES
SET IM_ERRPATH=E:\

REM * REQUIRED TO RESUME IF NO APM_4M
D:\IPM_4M.EXE

REM * LOAD FOR PCMCIA CARD DETECT ON RESUME
REM D:\APM_4M.EXE

REM * LOAD BARCODE READER FUNCTIONALITY
IF EXIST D:\LOADUMA.EXE D:\LOADUMA

REM * REQUIRED FOR COMPLETE DISPLAY FUNCTION
D:\IM_DISP.EXE

REM * SET READER CONFIG
*3 D:\IC /L F:\JANUS.INI

REM * CONFIGURE BARCODE WEDGE (DEFAULT DISABLE)
REM * 0= DISABLE WITH EXKBD
REM * 1= ENABLE WITH EXKBD
REM * 2= ENABLE WITHOUT EXKBD
REM * 3= DISABLE WITHOUT EXKBD
REM * 4= DISPLAY STATUS
D:\KWC.COM 0

REM * LOADS ONLY IF RF BACK INSTALLED
REM RFPH 4

*4 CALL F:\NET.BAT

REM * IF FTA EXISTS CALL TO DETERMINE IF HOST TRANSFER
REM * NOTE: THE RAMDRIVE E: IS USED SO FILES CAN BE
REM * ACCESSED WITHOUT SPECIFYING THE FULL PATH.
IF NOT EXIST C:\FTA.EXE GOTO DOS_PROMPT
E:
FTA.EXE CHECKHOST; EXIT

REM * START POSSIBLE HOST SET IM_APPLICATION
REM * TO EXECUTE A DOWNLOADED APPLICATION
%IM_APPLICATION%

:DOS_PROMPT
REM * END AT C: DOS PROMPT
C:
CLS
*5 CALL F:\EM.BAT

A few notes about the above:

1) AUTOINST figures out which drives are available.
2) Change the path as necessary for your installation. The statement above
was changed to add the root directory of the memory card drive.
3) IC.EXE is an Intermec-provided utility for configuring many things about
the Janus terminal. When called with the /L parameter, it simply loads the
configuration from the specified configuration file (JANUS.INI). The
statement above was changed to indicate the JANUS.INI is on the memory card
drive so it is easier to update and so that it resides on a non-volatile
drive (on a Janus 2050, this would be drive g: instead.)
4) NET.BAT was added to start the necessary drivers for radio communication
over the ethernet. NET.BAT contains the following for running the
necessary network drivers from memory card drive (in this case F:),
including those required to run FTP Software's TCP/IP stack:

F:
MINIPM.EXE
LSL.COM
RL2OEM.COM
IF NOT ERRORLEVEL 1 GOTO CARD_OK
ECHO *
ECHO * ERROR LOADING
ECHO * RL2OEM.COM
ECHO *
PAUSE

:CARD_OK
ODIPKT
ETHDRV

If the Novell TCP/IP stack is to be used instead, a simple change to
NET.BAT is needed; the calls to ODIPKT and ETHDRV should be replaced
by a single call to TCPIP.EXE.

Note: Newer versions of Janus terminals have a newer version of the 2.4ghz
radio which requires the use of RL2UISA.COM instead of RL2OEM.COM

5) EM.BAT is a batch file that is set up to start the Client automatically.

The network configuration is defined in one or two files depending on whether
the FTP Software or Novell TCP/IP stack is to be used:

NET.CFG
PCTCP.INI

NET.CFG is used in both cases. It contains the configuration for the LSL
driver - in the section labeled LINK SUPPORT. It also contains the
configuration of the domain, channel, subchannel and other parameters used by
the RL2OEM driver - in the section labeled LINK DRIVER RL2OEM. During
our testing, we used a Norand 6710 access point.

If using the Novell TCP/IP stack, then the TCP/IP parameters for the
IP address, subnet mask and router are configured in the section labeled
PROTOCOL TCPIP in NET.CFG.

The NET.CFG shown below is the one we used:

LINK SUPPORT
BUFFERS 8 1500
MEMPOOL 4096
MAX STACKS 8

LINK DRIVER RL2OEM
INT 7
PORT 270
DOMAIN 0 ;Matches LAN ID in 6710 access point
STATION_TYPE 0
FRAME ETHERNET_II
RADIO_MODE 0
ROAM_CONFIG 0
INACTIVITY_MIN 0
INACTIVITY_SEC 5
PEER_TO_PEER N
SNIFF_TIME 255
CHANNEL 1 ;Matches channel in 6710 access point
SUBCHANNEL 1 ;Matches subchannel in 6710 access point

PROTOCOL TCPIP ;This section is only used with the Novell stack
IP_ROUTER 99.99.99.101
IP_NETMASK 255.255.240.0
IP_ADDRESS 99.99.99.150

Note: If your Janus terminal has a newer 2.4ghz radio in it that requires the
use of the driver RL2UISA.COM instead of RL2OEM.COM, then change the
section in NET.CFG that is called LINK DRIVER RL2OEM should be changed
to LINK DRIVER RL2UISA instead.

If using the FTP Software TCP/IP stack, the IP address subnet mask and
router are instead configured in the PCTCP.INI file. This file is not used
when using the Novell TCP/IP stack.

There are lots of parameters in this file, but we only changed a few of them
in our testing. Since we aren't familiar with the meaning of all of them, the
entire file we used is included below. Comments are on the right hand side
for parameters that we changed and for other useful information.

The PCTCP.INI shown below is the one we used:

[pctcp general]
time-zone=EST
time-zone-offset=300
etc-dir=f:\
host-name=intermc ; This should be unique per terminal
domain=bellevue or you might be able to remove it

[pctcp kernel]
keep-alive=60000
mtu-discovery=yes
multicast=no
pktdrv-loopback=yes
router-discovery=no
kernel-does-dns=yes
interface = ifcust JR2020G ; This points to the section below
host-table = hosts that contains the interface in use

[pctcp ifcust JR2020G]
ip-address = 99.99.99.150 ; Must be unique for each terminal
subnet-mask = 255.255.240.0 ; Change this for your site
router = 99.99.99.101 ; Change this for your site
interface-type=PKTDRV ; Must use this interface type
frame-type = ethernet_II ; Must use this frame type

[pctcp netbios]
adapter-number=0
cache-elements=10
loadhigh=yes
names=16
ncbs=20
sessions=10

[pctcp addresses]

[pctcp bootp]

[pctcp time]
dst-begins=97
dst-ends=305

[pctcp screen]
video-card=VESA

[pctcp idprint printer]
when = timeout

[pctcp idrive]
umask=775
use-emm=yes

[pctcp vmail]
ask-overwrite=no
indent-reply=" "
new-mbox=yes
post=yes
print-nonprintable=no

[pctcp pcmail]
max-sync-descs=0
msglimit=0
net-time-out=5
repository-port=158

[pctcp pop2]
max-sync-descs=0
net-time-out=5
pop2-port=109

[pctcp pop3]
bboard=no
default-mbox=default
max-sync-descs=0
net-time-out=5
pop3-port=110
rpop=no
xmit=no

[pctcp nntp]
join-max-msgs=0
max-sync-descs=0
net-time-out=5
nntp-port=119

[pctcp tn]
back-arrow-key=del
ftpsrv=off
status=on

[pctcp 3270]
bell=on
ftp-sfe-attr=0x09,0x04,0x05,0x02,0x03,0x0E,0x0F
ftp-sfe-rv-attr=0x10,0x40,0x50,0x20,0x30,0x60,0x70
light-pen=off
model-3/4=4
mouse=off
yale=on

[pctcp vt]
8-bit=off
allow-vt220-8-bit=on
answerback=FTP
bell=on
def-em-mode=vt220
wrap-line=off

[pctcp vpctcp]
MinimumCopySpace=12
HiTSRFenceSegment=A000h

[pctcp sessions]
telnet=c:\session.ini
ftp=c:\session.ini
ctlapp=C:\CTLAPP.INI

[pctcp ctlapp]
default-placement=1 5 35 275 200
toolbar=small
show-status-bar=yes

[pctcp ping]
host=JR2020G
status-bar=yes
icon-bar=yes
ping-on-startup=no
savesettings=yes
icmp-data-length=56
trace-show-host=yes
time-interval=1
mode=trace

[pctcp wmsg]
default-placement=1 5 35 275 200

For information about the possible need for entries for authentication-key and
serial-number, see Authentication Key and Serial Number Entries in the .INI file.

The PCTCP.INI file needs to be in the current directory or in a directory
referenced by the environment variable PCTCP, which is set in the NET.BAT
file above.

Janus Bar Code Configuration
----------------------------
When using one of the Janus terminals, configuration of the bar codes is
done using a utility that is provided with the Janus terminal. This utility
is called IC.EXE and it is provided by Intermec. The utility must be run
on the Janus terminal. Refer to the Janus User's Guide for more information
about using the IC utility. In brief, you must use the 'Sym' pull-down
menu to select bar code symbologies that are to be active.

In addition to selecting the bar code symbologies, preamble and postamble
characters should be configured using the IC utility. If using the
SCAN_SENTINEL_CHARS keyword in EMULATOR.INI (see above), you need to
define both a preamble and postamble. If not using that keyword, it is
suggested that the carriage return (\r) sequence be configured as the
postamble so that the Enter key does not have to be pressed after a bar
code is scanned.

Use the 'Op' pull-down menu of the IC utility followed by the 'Amble' option
and then fill in the PREAMBLE and POSTAMBLE values as needed.

After all parameters are defined, go to the File pull-down and use the
'Save As' option to save the file to the memory card drive so that it can
be transferred to the PC for replication to other terminals in the network.

Configuring the Janus Display and Viewport
------------------------------------------
By default the Janus display is set up as 25x80 and the Viewport is set up
to scroll automatically with the cursor. When running the Client in this
configuration, this automatic scrolling leads to rather unpleasant movement
of the screen. It is suggested that the IC utility be used to change the
Viewport Movement to be Manual.

In early versions of the Janus firmware, the manual mode of the viewport did
not work properly. For these versions, it may be necessary to change the
Display dimensions to be 16x20 in order to prevent it from moving or from
being moved at all.

Serial Port Use on the Janus Terminal
-------------------------------------
The serial port on the Janus terminal can be used not only for transferring
files and images to the terminal, but it can be used by the Client to
communicate with devices such as a serial printer.

The serial flavor of the Client can also be used if the terminal is to
communicate to the data collection server via the serial port instead of
RF over ethernet.

Starting the Client on the Janus Terminal
-----------------------------------------
If the Client will be run from the memory drive as suggested, then the
Client and the file ETSCHECK.LIC should be copied to that drive along
with any configuration file(s).

Depending on which model of Janus terminal is being used, a different 'device'
command line parameter must be used:

For the Janus 2010 or 2020 terminals, any one of the following parameters
may be used:

-dJANUS
-dJANUS2010
-dJANUS2020

For the Janus 2050 terminal, the following parameter must be used:

-dJANUS2050

For more details about this and other command line parameters, see the earlier
section called Common Command Line Parameters for the Client.

Setting Up a Janus Terminal from Scratch
----------------------------------------
This section describes suggested steps to take an out-of-the-box Janus
terminal and set it up so that the Client can run on it. The instructions
below are based on a Janus that was loaded with version 4.06 of the Intermec
drive images.

Note 1: These instructions also assume the use of a memory card. At the
end of each step, will be a section with the heading:

>>> NO MEMORY CARD <<<
----------------------

That describes what to do differently if a memory card is not being
used in the terminal.

Note 2: The PC operations in these instructions must be performed from a PC
that has a FAT harddrive, CD ROM drive, RS-232 serial port and must be
running DOS. And if a memory card is to be used in the Janus terminal,
drivers for that memory card must be installed on the PC. The
INTERSVR.EXE utility that must be run on the PC is not part of
Windows 95/98/NT or OS/2. We have found that INTERSVR.EXE will run
under Windows 95, if you have it to copy there.

The Janus terminal initially contains the following files:

C:\AUTOEXEC.BAT D:\CHKDSK.EXE D:\INTERSVR.EXE D:\NLSFUNC.EXE
C:\AUTOINST.BAT D:\CHOICE.COM D:\IPM_4M.EXE D:\PHIMEC.EXE
C:\CARDINFO.EXE D:\COUNTRY.SYS D:\IRL.BAT D:\PHPCSTD.EXE
C:\COMMAND.COM D:\CS.EXE D:\IRL001.DAT D:\POWER.EXE
C:\CONFIG.SYS D:\CSALLOC.EXE D:\IRLDESK.EXE D:\PUTDISK.EXE
C:\JANUS.MRF D:\CSALLOC.INI D:\JANUS.CLB D:\RFPH.EXE
C:\MCFORMAT.EXE D:\DEBUG.EXE D:\KEYB.COM D:\RSERUMA.EXE
C:\MTDDRV.EXE D:\DECSCAN.EXE D:\KEYBOARD.SYS D:\RWTSR.EXE
C:\MTSRAM.EXE D:\DISPLAY.SYS D:\KWC.COM D:\SCANNER.INI
D:\DOSKEY.COM D:\LABEL.EXE D:\SETVER.EXE
D:\ANSI.SYS D:\EDLIN.EXE D:\LCD.CPI D:\SILENT24.EXE
D:\APM_4M.EXE D:\FC.EXE D:\LOADFIX.COM D:\SORT.EXE
D:\ATADRV.EXE D:\FORMAT.COM D:\LOADUMA.EXE D:\SRAMDISK.SYS
D:\ATAINIT.EXE D:\FTL.EXE D:\LOADUMA.INI D:\SUBST.EXE
D:\ATTRIB.EXE D:\HIMEM.SYS D:\MEM.EXE D:\UNDELETE.EXE
D:\CARD_SR.EXE D:\IC.EXE D:\MODE.COM D:\UNLOAD.EXE
D:\CARDID.EXE D:\IC001.DAT D:\MORE.COM D:\XCOPY.EXE
D:\CARDID.INI D:\IM_DISP.EXE D:\MTI1.EXE
D:\CFGUMA.EXE D:\INTERLNK.EXE D:\MTI2P.EXE

1) The first step is to get the files for drive C: on to your PC so that
they can be changed and added to and a new image created. The easiest
way to do this is to install a memory card in the Janus and copy all files
on drive C: to the memory card drive. We will not be changing anything
on drive D: so this will not have to be reflashed.

Create a directory on your PC that will contain only the Janus drive C:
files. In the steps below we'll call this directory C:\JANUS_C.

Also create a directory on your PC that will contain the files that will
be copied to the memory card. In the steps below we'll call this
directory C:\JANUS_F because that is the memory card drive on a Janus 2010.
(On 2020 and 2050 terminals, the memory card drive can be drive G: instead).

Copy all files from the terminal's C:\ drive to the C:\JANUS_C directory
on the PC. For instructions about how to do this, refer to the section
above: Transferring Files to a Janus Terminal.

>>> NO MEMORY CARD <<<
----------------------
If no memory card is being used, changes to the terminal's drive D: will
also be needed because all required files will not fit on drive C: So
instead of creating a C:\JANUS_F directory on the PC, create C:\JANUS_D
for the files on drive D: Then copy all the files from the terminal's D:\
drive, including all subdirectories, to the C:\JANUS_D directory on the PC.

There is not enough space on drive D: of the terminal to include all of
the original files in addition to the files that will be added in the
steps below. So to make space, the file IRLDESK.EXE should be deleted
from C:\JANUS_D after all files are transferred from the terminal (this
program is not needed when running the DCConnect Client on the terminal).
This file is almost 350K all by itself - which is much larger than the
combined size of all other files that will be added.

2) One additional file needs to be created on the terminal and transferred to
the PC. This file is JANUS.INI and it contains Janus specific
configuration parameters such as display and bar code settings. From any
Janus terminal run the IC utility and make changes to the configuration as
needed. Then save the file to the terminal's RAM drive, drive E: as
JANUS.INI.

For more information about how and what to configure using IC.EXE,
refer to the Janus User's Guide. More specific hints related to the use
of the Client are in the sections above Janus Bar Code Configuration
and Configuring the Janus Display and Viewport.

Using the same method that was described in the previous step, transfer
E:\JANUS.INI on the terminal to C:\JANUS_F.

>>> NO MEMORY CARD <<<
----------------------
Transfer E:\JANUS.INI to C:\JANUS_C on the PC instead.

3) Make the following changes to AUTOEXEC.BAT:

a) Change the path statement to include the memory card drive. For example:

PATH=C:\;D:\;E:\;F:\

b) Change the call to IC to get the JANUS.INI file from the memory card
drive. For example:

D:\IC /L F:\JANUS.INI

c) If you will be running a TCP/IP flavor of the Client, add a call to
NET.BAT from the memory card drive after the call to KWC.COM. For
example:

D:\KWC.COM 0
CALL F:\NET.BAT

d) If you want the Client to start up automatically from AUTOEXEC.BAT
then add the following two lines at the end:

CALL F:\EM.BAT

>>> NO MEMORY CARD <<<
----------------------
Step a is not needed.
Step b is not needed; JANUS.INI will be on C: drive.
In step c, NET.BAT should be on drive D:
In step d, EM.BAT should be on drive C:

4) The only change that is needed in the CONFIG.SYS file is the default
setting for the memory card. The default is 'sram'. This is indicated
near the top of the CONFIG.SYS file by the line:

MENUDEFAULT=SRAM, 20

If you will be using an ATA memory card instead, change the line to read:

MENUDEFAULT=ATA, 20

If you will not be using any memory card, change the line to read:

MENUDEFAULT=NO, 20

You may also want to change the default menu display time of 20 seconds to
something less.

>>> NO MEMORY CARD <<<
----------------------
Be sure to use 'NO' for the MENUDEFAULT setting.

5) All files for drive C: are now set up in the C:\JANUS_C directory. You
should now create the C: drive image with the original files from drive C:
and the AUTOEXEC.BAT / CONFIG.SYS that weres modified in the previous steps.
After the image is created, the Janus terminal should be reflashed either
via the serial port or using the memory card.

For information about creating images and flashing the Janus terminal, see
Transferring Files to a Janus Terminal.

If you are using a memory card, this should be the last time that you will
have to flash the C: drive because all other changes would be made on the
memory card drive.

>>> NO MEMORY CARD <<<
----------------------
Do not create the drive C: image yet. Since no memory card is being used,
other steps below will be adding other files for drive C: Creating images
for drive C: and D: will be one of the last steps when no memory card is
involved.

6) The rest of the steps involve what is to be set up on the memory card drive.
You should set up a separate directory on your PC for all the files that
will be copied to the memory card drive. In this example, we'll use:

C:\JANUS_F

because the memory card will be drive F: in the terminal (for 2010). For
2020 and 2050, the memory card will be drive G:.

>>> NO MEMORY CARD <<<
----------------------
Don't do this, you should already have a separate directory for file that
will be on drive D:.

7) First we'll set up NET.BAT, the batch file that is called to start up
the necessary network drivers. If you are running the serial flavor of
the Client then this and the next three steps can be skipped.

Set up the NET.BAT as described above under the section above called,
Janus CONFIG.SYS, AUTOEXEC.BAT and Network Configuration.

>>> NO MEMORY CARD <<<
----------------------
NET.BAT will be created in the root of drive D: And the first line of
NET.BAT should be changed to set the current drive to be D: rather than F:

8) Copy the following drivers from the Janus Network Driver's disk to
C:\JANUS_F on the PC:

MINIPM.EXE
LSL.COM
RL2OEM.COM

>>> NO MEMORY CARD <<<
----------------------
Copy these to C:\JANUS_D instead.

9) If you are using the FTP Software TCP/IP stack, the necessary drivers from
FTP Software are supposed to be provided on one of the companion diskettes
for the Janus terminal. We were unable to find out from Intermec which one
it was. Copy the following files from the appropriate diskette to
C:\JANUS_F on the PC:

ODIPKT.COM
ETHDRV.EXE

But if you are using the Novell TCP/IP stack, the following file should
be copied from the appropriate companion diskette to C:\JANUS_F on the PC:

TCPIP.EXE

>>> NO MEMORY CARD <<<
----------------------
Copy these files to C:\JANUS_D instead.

10) Now set up the network configuration files as decribed above in the section
Janus CONFIG.SYS, AUTOEXEC.BAT and Network Configuration.

NET.CFG must be set up regardless of the TCP/IP stack is to be used.

PCTCP.INI must be set up only if the FTP Software TCP/IP stack is to be
used.

These files should be set up C:\JANUS_F on the PC.

>>> NO MEMORY CARD <<<
----------------------
Set up these files in C:\JANUS_D instead.

11) Now copy the following files from the directory where the Client is
installed to C:\JANUS_F on the PC:

ETSCHECK.LIC

If using the serial flavor of the Client:

SERIAL\ETSPB.EXE

If using the Client along with the FTP Software TCP/IP stack:

TCP_FTP\ETSPT.EXE

If using the Client along with the Novell TCP/IP stack:

TCP_NOV\ETSPT.EXE

>>> NO MEMORY CARD <<<
----------------------
Set up these files in C:\JANUS_C instead (note that we switched from D to C).

12) Now determine if you need to create an EMULATOR.INI file. For more about
what parameters can be set up in this file, refer to the section above
Configuration using EMULATOR.INI.

If you decide you need this file, create it in C:\JANUS_F on the PC.

>>> NO MEMORY CARD <<<
----------------------
Create EMULATOR.INI in C:\JANUS_C instead.

13) The last Client specific file to create is EM.BAT and it should be
created in C:\JANUS_F on the PC. Remember that in step 3 above
AUTOEXEC.BAT was changed to call EM.BAT at the end. This file will have
different contents depending on what flavor of the Client you are running
and what device you are using.

For all flavors, you should start with the following two lines:

f:
cd \

so that the Client can be started regardless of what the current
directory and drive are. If drive G: is your memory card drive, then
be sure to change f: to g: instead.

If you are running the serial flavor of the Client, then add a line
to EM.BAT that is similar to:

etspb -aB -b19200 -dJANUS2050

Change the -a (address), -b (baud rate) and -d (device) parameters as
appropriate for your configuration.

If you are running the TCP/IP flavor of the Client, then instead add
a line to EM.BAT that is similar to:

etspt -dJANUS2050 -h1.2.3.4,7500

Change the -d (device) and -h (host PC) parameters as appropriate for
your configuration.

For more details about command line parameters, see the earlier section
called Common Command Line Parameters for the Client.

After the call to the Client add a call to clear the screen:

cls

This is sometimes needed to restore the display to its original state
after you exit the Client.

>>> NO MEMORY CARD <<<
----------------------
Create this file in C:\JANUS_C instead. In addition, because the Client
must run on a writable drive, the RAM drive (E:) must be the current
drive before the Client is started. The Client expects ETSCHECK.LIC and
the optional EMULATOR.INI file to be in the current directory. So these
must be copied from drive C: to drive E: before the Client is started. So
replace the first two lines in the file described above (f: and cd \) with
the following:

e:
cd \
copy c:\etscheck.lic
copy c:\emulator.ini

If not using EMULATOR.INI, do not add the last line.

14) These are all of the files that can be set up from the PC. So at this time
you can copy all of the files from your directory for memory card files to
the actual memory card. Then put the memory card into the Janus terminal
and reboot it.

Make sure everything starts up properly.

>>> NO MEMORY CARD <<<
----------------------
Now we are ready to create the C: and D: drive images and then flash the
Janus terminal with those new images.

For information about creating images and flashing the Janus terminal, see
Transferring Files to a Janus Terminal.

15) The drive C: image and directory of files for the memory card should now be
setup up properly as the basis for replicating your configuration across
all Janus terminals in the network.

For serial terminals, the only difference between terminals should be
the address parameter set in EM.BAT.

For TCP/IP terminals, the only difference between terminals should be
the IP address configured in either NET.CFG (if using the Novell TCP/IP
stack) or in PCTCP.INI (if using the FTP Software stack).

>>> NO MEMORY CARD <<<
----------------------
Unfortunately, when a memory card is not being used different images are
needed for each terminal. For serial terminals, the EM.BAT (or
EMULATOR.INI) will have to be different for every terminal; therefore
the drive C: image will have to be different for every terminal. For
TCP/IP terminals, NET.CFG or PCTCP.INI will have to be different for every
terminal; therefore the drive D: image will have to be different for every
terminal.

The only way to get around this is to have the files that are different
reside on drive E:, the RAM drive so that they can be changed without
reflashing. And to facilitate the changing of those files, a separate
batch file (e.g. SETUP.BAT) would be run on the terminal to set up the
parameter that is different and insert into the file. This would be done
once after the terminal is flashed with the new C: and D: drive images.

Files on drive E: are preserved through a Cntrl-Alt-Del reboot. But they
are lost if the terminal loses all battery power or if a cold boot is
performed. So if drive E: is erased, SETUP.BAT would have to be run again
to set the address. Below are suggested steps for creating SETUP.BAT
along with what other changes would be needed for other files that are
part of the C: and D: drive images.

For serial terminals you could do the following:

a) Instead of specifying the terminal address in EM.BAT when ETSPB is
called, the terminal address can be read from EMULATOR.INI that is
read when ETSPB starts. So first remove the -a parameter from the
call to ETSPB in EM.BAT.
b) Also remove the line to copy EMULATOR.INI from C: to E: drive; this
file will be set up using a SETUP.BAT file that is run once.
c) In the set of files for drive C: create EMULATOR.INI with all parameters
except for ADDRESS. That will be added via a batch file.
d) Create a batch file for C: drive called SETUP.BAT that takes as a
parameter, the terminal address character (A-Y, 0-6). This batch file
would then copy EMULATOR.INI from C: to E: and append to it a line that
specifies the address parameter. The contents of SETUP.BAT would be:

@echo off
if "%1" == "" goto needaddr

copy c:\emulator.ini e:\
echo ADDRESS=%1 >> e:\emulator.ini
goto end

:needaddr
echo Enter address as parameter

:end

e) You might also want to change EM.BAT to look for the existence of
EMULATOR.INI on drive E:. If it is not found, the batch file could
prompt the user to run setup. To accomplish this, add the following
line to EM.BAT before the call to ETSPB.EXE:

if not exist e:\emulator.ini goto needsetup

and add the following lines to the end of EM.BAT:

goto end
:needsetup
echo Run SETUP to set address
:end

For TCP/IP terminals you could do the following:

a) The terminal IP address is the parameter that is different for every
terminal and it is found in either PCTCP.INI (if using FTP Software
TCP/IP stack) or in NET.CFG (if using Novell TCP/IP stack). Whichever
file is being used, will have to be split into 3 parts:

1) Part 1 includes all lines of PCTCP.INI / NET.CFG up to but not
including the line that specifies the IP address:

ip-address = 1.2.3.4 (PCTCP.INI)

IP_ADDRESS 1.2.3.4 (NET.CFG)

The part 1 files should be called PCTCP.1ST / NET.1ST and it should
be created in C:\JANUS_D on the PC.

2) Part 2 is the ip-address / IP_ADDRESS line itself. It is not part
of any files. Instead it will be generated using an ECHO command in
the SETUP.BAT file that will be created below.

3) Part 3 includes all lines of PCTCP.INI / NET.CFG after the line
that specifies the IP address. These lines should be put into
a file called PCTCP.2ND / NET.2ND. This files should also be
created in C:\JANUS_D on the PC.

b) NET.BAT should be changed in the following ways:

1) The first two steps should be to make drive e: the current drive and
to look for the existence of PCTCP.INI / NET.CFG. For the FTP stack
use the following two lines:

e:
if not exist e:\pctcp.ini goto needsetup

for the Novell stack, use the following two lines:

e:
if not exist e:\net.cfg goto needsetup

2) Then add the following lines to the end of NET.BAT to prompt the
user to run setup when net.cfg is missing.

goto end
:needsetup
echo Run SETUP to set IP address
setup >nul
:end

The call to setup is a little trick to cause stop any further
processing of NET.BAT and AUTOEXEC.BAT. The user will be left
at a DOS prompt and will be able to run SETUP - this time
specifying an IP address.

3) Before all calls to network drivers (MINIPM.COM, LSL.COM, RL2OEM.COM /
RL2UISA.COM, ODIPKT.COM, ETHDRV.EXE and TCPIP.EXE) be sure to
specify the path in which these drivers will reside on the terminal -
which is the root of drive D: For example, change the call to
LSL.COM to be:

D:\LSL.COM

d) Create a batch file for C: drive called SETUP.BAT that takes as a
parameter, the IP address for the terminal. This batch file will create
PCTCP.INI / NET.CFG on drive E: using the parts from drive D: and the
IP address parameter passed in on the command line. Use the following if
running the FTP Software stack:

@echo off
if "%1" == "" goto needaddr

copy d:\pctcp.1st e:\pctcp.ini
echo ip-address = %1 >> e:\pctcp.ini
copy e:\pctcp.ini + d:\pctcp.2nd e:\pctcp.ini
goto end

:needaddr
echo Enter IP address as parameter

:end

Use the following if running the Novell stack:

@echo off
if "%1" == "" goto needaddr

copy d:\net.1st e:\net.cfg
echo IP_ADDRESS %1 >> e:\net.cfg
copy e:\net.cfg + d:\net.2nd e:\net.cfg
goto end

:needaddr
echo Enter IP address as parameter

:end

Using the DCConnect Client on LXE MX1, MX2 and VX1 Terminals
------------------------------------------------------------
This sections gives a few notes about using the DCConnect Client on one of the following
terminals from LXE: MX1, MX2 and VX1. While these terminals are currently in use at
one or more customers, we have not yet had the opportunity to do the in depth investigation
needed to fully document all aspects of configuring these terminals. Please consult
the manufacturer's documentation for any information required.

- The MX1, MX2 and VX1 all require the flavor of the DCConnect Client that uses the
FTP Software TCP/IP stack and the alternate video drivers. This is found in the
\TCP_FTP\NLS directory where the Client files are installed.

- Before the Client is started on the device, you should make sure that the screen
dimensions are set properly by issuing the DOS 'mode' command. On the MX1 and MX2
terminals, run the command:

mode 80

on the VX1 terminal, run the command:

mode 40

while this seems backwards, the MX1 and MX2 need to be set to 80 column mode so that the
characters are small enough to fit 20 across on the screen. This may in fact already be
the default font. On the VX1, the screen must be set to 40 characters across because the
Client does not support more than 40 columns; setting to 40 character mode maximizes the
use of the display. Setting the mode also ensures that the screen is cleared and
positioned at the top of the terminal display - which is where the Client needs it to be.

In our testing, we set up EM.BAT to set the mode as described and then call the DOS
command CLS after the Client runs. This is done in order to properly position the
screen after the Client ends. If CLS is not done, the DOS prompt could be off the
screen.

Here is the EM.BAT we used on the MX1/MX2 terminal:

mode 80
etspt
cls

and here is the EM.BAT we used on the VX1 terminal:

mode 40
etspt
cls

- Below is the content of the EMULATOR.INI we used on the MX1/MX2 terminals:

NUM_PF_STRINGS = 0
NUM_TOUCH_STRINGS = 0

MAX_TRANSACTIONS = 10

PF_MAPPING = Y

NUM_ROWS = 16
NUM_COLS = 20

TCPIP_HOST = 102.102.102.101
DONT_CHANGE_SCREEN_SIZE = Y
IGNORE_UNDERLINE = Y

An explanation of each parameter follows:

- NUM_PF_STRINGS = 0 and NUM_TOUCH_STRINGS = 0 are used to
maximize the memory available in the terminal for
downloaded files.

- MAX_TRANSACTIONS = 10 sets the transaction buffer
size to its minimum - to maximize the memory
available for transactions. Change this if the
terminal needs to buffer more transactions.

- PF_MAPPING = Y allows the terminal's numeric keys to
be used as the PF1 through PF10 keys.

- NUM_ROWS = 16 and NUM_COLS = 20 tell the Client
the dimensions of the terminal's physical screen.

- TCPIP_HOST = 102.102.102.101 tells the Client the
IP address of the DCConnect Server. Change this
to make it correct for your DCConnect Server.

- DONT_CHANGE_SCREEN_SIZE = Y is required in order
to tell the Client to leave the screen size as it
is. On many devices the Client tries to switch the
screen size to 40 column mode but this does not work
correctly on the LXE devices.

- IGNORE_UNDERLINE = Y is required in order to tell
the Client to ignore the underline attribute
wherever it may be used. Characters using this
attribute are shown normally instead. The LXE
terminals do not support the underline character;
if the attribute was used, the character would
not be visible.

The EMULATOR.INI for the VX1 terminal is the same
except for NUM_ROWS and NUM_COLS parameters which
are set as follows:

NUM_ROWS = 20
NUM_COLS = 40

because of the larger display on the VX1.

For more information about the EMULATOR.INI parameters, see
Configuration using EMULATOR.INI.

- If the termina'ls auto-suspend timer is not working when the
Client is running, the POWER_OFF_TIMER keyword can be added
to EMULATOR.INI to solve this problem. For more information
please see Keyword: POWER_OFF_TIMER.

- The serial port of the LXE MX1, MX2 and VX1 can be used by the Client to
communicate with devices such as a serial printer.

- The MX2 is actually the exact same terminal as the PSC/Percon
Falcon 345 terminal - which is also covered in this documentation.
For some more information about configuring that terminal please see
Using the DCConnect Client on PSC/Percon Falcon 345 Terminals.

Note: The 'falc_tsr' discussed in the above referenced section can
be used on the LXE MX2 terminal as well.

- By default all scanner input is routed through the keyboard and
a carriage return is automatically appended to the scanner input. In
this mode, the Client does not know which input data came from the
scanner and what was keyed in.

If there is a requirement for the LXE terminal to be able to distinguish
between keyboard and scanner input (e.g. in order to require scanner
input for a particular field) then falc_tsr.exe must be started prior
to starting the Client, it must use the parameter 0x63 and the following
three parameters must be added to EMULATOR.INI:

USE_TSR_FOR_SCANNER = Y
USE_TSR_FOR_KEYBOARD = Y
TSR_INTERRUPT = 0x63

The use of the TSR falc_tsr.exe and these three keywords is covered in
Using the DCConnect Client on PSC/Percon Falcon 345 Terminals.

Using the DCConnect Client on PSC/Percon Falcon 345 Terminals
-------------------------------------------------------------
This sections gives a few notes about using the DCConnect Client on the Percon Falcon
345 terminal. This terminal is also sold by LXE as the MX2 model terminal (which is
also covered in this documentation).

While the Percon Falcon 345 terminal is currently in use at one or more customers,
we have not yet had the opportunity to do the in depth investigation needed to fully
document all aspects of configuring these terminals. Please consult the
manufacturer's documentation for any information required.

- The Percon Falxcon 345 requires the flavor of the DCConnect Client that uses the
FTP Software TCP/IP stack and the alternate video drivers. This is found in the
\TCP_FTP\NLS directory where the Client files are installed.

- Before the Client is started on the device, you should make sure that the screen
is positioned at the top because this is where the Client displays its data. This
is done by issuing the DOS 'cls' command.

Note: The Percon Falcon 345 usually defaults to 80 column mode which is what the
Client requires in order to be able to view 20 columns of data. If this
is not the default setting, then use the DOS command:

mode 80

to set the screen properly. This command also positions the screen at
the top; so it is not necessary to issue the cls command after the mode
command.

In our testing, we set up EM.BAT to call the cls command as described and then call
same cls command after the Client runs. This is done in order to properly position the
screen after the Client ends. If cls is not done, the DOS prompt could be off the
screen.

Here is the EM.BAT we used on the Falcon terminal:

cls
falc_tsr 0x63
etspt
cls

The call to 'falc_tsr' is discussed below.

- In order to have the ability to distinguish between keyboard and scanner input,
the Client requires that a special TSR be running. This TSR, falc_tsr.exe, is
found in the \FALCON directory where the Client files are installed. It must
be called before the Client is start - as is the case in the EM.BAT that is
described in the previous bullet.

The interrupt 0x63 is specified as a parameter because the default interrupt 0x6a
that the Client uses to talk to the TSR does not work properly on the Falcon
terminal.

The Falcon does not provide a way to set up both preamble and postamble
characters for scanned bar codes. Therefore the SCAN_SENTINEL_CHARS keyword
cannot be used in EMULATOR.INI.

Instead, use the keywords:

USE_TSR_FOR_KEYBOARD = Y
USE_TSR_FOR_SCANNER = Y
TSR_INTERRUPT = 0x63

and make sure 'falc_tsr.exe' is running before the Client is started. The use
of TSR_INTERRUPT above tells the Client to use 0x63 for the interrupt to talk
to the TSR instead of the default of 0x6a. For more info about this keyword,
see Keyword: TSR_INTERRUPT.

- Below is the content of the EMULATOR.INI we used on the Falcon terminals:

NUM_PF_STRINGS = 0
NUM_TOUCH_STRINGS = 0

MAX_TRANSACTIONS = 10

PF_MAPPING = Y

NUM_ROWS = 16
NUM_COLS = 20

TCPIP_HOST = 102.102.102.101
DONT_CHANGE_SCREEN_SIZE = Y
IGNORE_UNDERLINE = Y

USE_TSR_FOR_SCANNER = Y
USE_TSR_FOR_KEYBOARD = Y
TSR_INTERRUPT = 0x63

An explanation of each parameter follows:

- NUM_PF_STRINGS = 0 and NUM_TOUCH_STRINGS = 0 are used to
maximize the memory available in the terminal for
downloaded files.

- MAX_TRANSACTIONS = 10 sets the transaction buffer
size to its minimum - to maximize the memory
available for transactions. Change this if the
terminal needs to buffer more transactions.

- PF_MAPPING = Y allows the terminal's numeric keys to
be used as the PF1 through PF10 keys.

- NUM_ROWS = 16 and NUM_COLS = 20 tell the Client
the dimensions of the terminal's physical screen.

- TCPIP_HOST = 102.102.102.101 tells the Client the
IP address of the DCConnect Server. Change this
to make it correct for your DCConnect Server.

- IGNORE_UNDERLINE = Y is required in order to tell
the Client to ignore the underline attribute
wherever it may be used. Characters using this
attribute are shown normally instead. The Falcon 345
terminal does not support the underline character;
if the attribute was used, the character would
not be visible.

- USE_TSR_FOR_SCANNER = Y and USE_TSR_FOR_KEYBOARD = Y
allow the Client to distinguish between keyboard and
scanner input. These are discussed in the previous
section as well.

- TSR_INTERRUPT = 0x63 tells the Client which interrupt
to use when talking to the TSR. This is discussed in
the previous Falcon section above.

For more information about the EMULATOR.INI parameters, see
Configuration using EMULATOR.INI.

- If the terminal's auto-suspend timer is not working when the
Client is running, the POWER_OFF_TIMER keyword can be added
to EMULATOR.INI to solve this problem. For more information
please see Keyword: POWER_OFF_TIMER.

- The manufacturer of the Falcon terminal provides with the
terminal, the Falcon Configuration Utility, which should be
installed on your PC in order to load files to and configure
the Falcon terminal. Please consult the documentation provided
with the terminal for information about how to use this utility.

Here are some notes about the use of that utility:

- We ran it on our Windows 2000 test machine.

- When installing the utility, be sure to specify the
appropriate radio for the terminals that you have.

- When it is started several buttons are provided, including
ones to:

- Custom - Set up a custom installation and configuration
- Comm Settings - Change the serial port settings that the
utility uses to communicate with the terminal.
- Transfer Files - Transfer a set of files to or from the terminal

- When you press the Custom option, you are asked to choose a
configuration file (*.cfg). Default configuration files are
provided based on the radio type(s) that you specified during
installation. Be sure to pick the .cfg file name for that
radio that includes 'tcp' in the name. For example:

- ar_tcpip.cfg is for TCP/IP communications with an Aeronet radio
- cs_tcpip.cfg is for TCP/IP communications with a Cisco radio
- lu_tcpip.cfg is for TCP/IP communications with a Lucent radio

Once you pick the .cfg file you will be prompted for the Program
Settings file (*.prs). We started with default.prs. This file
contains settings for active bar code symbologies as well as other
things.

Once you pick the .prs file, you will be presented a new set of
buttons:

- File Configuration - Lets you add to the set of files to be
loaded to the terminal and gives you the
opportunity to change the contents of
them (e.g. net.cfg).
- Program Settings - Lets you change which barcode symbologies
are active and change their settings. Also
lets you define miscellaneous parameters
including scanning parameters such as
whether Symbology Identifiers are included
in the bar code data.
- Comm Settings - Change the serial port settings that the
utility uses to communicate with the terminal.
- Download - Download the entire file configuration and
program settings to a terminal.

- If you choose the File Configuration option, you'll see a list of
files that are to be loaded to the terminal. Initially these
include all the network and radio related files. You will need
to configure net.cfg and socket.cfg and you will need to add DCConnect
Client related files.

To change the contents of net.cfg, highlight in the list (the one for 32x)
and click the Edit button. This will bring up another window that lets you
specify the source and target. You won't be changing either of these but
we'll use the Browse button and a little trick to allow you to edit the
file:

- Click the Browse button. This will bring up the 'Open' dialog
- In the box at the bottom labelled 'Files of type' change the
selection to 'All(*.*)'. You should now see net.cfg in the list
above.
- Use the right mouse button and choose the 'Open' option (not Select).
If your Windows system is configured to bring up an editor for .cfg
files, then net.cfg will be opened in that editor. If no application
is currently set up to handle .cfg files, choose Notepad to be that
application.
- You can now make the appropriate changes to this file and save it.
Consult your network administrator for appropriate values. In our
testing with a terminal with a Cisco radio, we set values in the
'Link Driver cscodi' and 'Link Driver CISLEAP' sections.
- After saving your changes, exit the editor.
- Press Cancel on the Open dialog
- Press Cancel on the Edit File Properties dialog

Follow the same sequence to modify socket.cfg. You should only have
to change two lines in this file. Consult your network administrator
for the appropriate value:

- Around line 4: IP address 99.99.99.34/24

Fill in the IP address your terminal should have.
Leave the /24 if your subnet mask is 255.255.255.0
Change it to the appropriate value (indicating
number of bits) if your subnet mask is different.

- Around line 17: route add default if0 99.99.99.101

Fill in the IP address of your router/gateway.

Do not change the 'IP address' statement around line 20. This is
used simply to display what the IP address is this file is processed
during a boot up of the terminal.

To add files to the list, do the following:

- Click the Add button. This brings up the 'File Selection' dialog.
- Fill in the path where the file can be found on the PC. You can
use the Browse button to locate the file.
- Fill in the path where the file should go on the terminal. In
our testing we put all DCConnect Client files in the root of
drive c: Be sure you specify the path and filename in this
second field.
- One file that you will add will be the 'Main Application'. This
the application that will be called by AUTOEXEC.BAT after the
boot process completes.

We typically use EM.BAT as the the main application; it adjusts
the screen appropriately, starts the TSR and then starts the
Client.

When adding the file that is to be the Main Application, be sure
to check the check box that is to the right of the 'Main Application:'
label and under the 'Falcon 32x/33x/34x' heading.

- When you have fill in all parameters, click OK.

Repeat this process for all files. In our testing we add the following
files:

- em.bat
- emulator.ini
- etspt.exe
- etscheck.lic
- falc_tsr.exe

and em.bat was set up to be the main application.

After all files have been added, click the Next button on the
'File Configuration' screen. The next screen lets you set some
memory options, connectivity options and select which DOS files
are loaded. The defaults will probably be sufficient.

However, if you will be using the 'mode' command, be sure to
check the 'DOS Files ...' check box and then click the 'More'
button so that you can highlight 'Mode.com' for downloading.

Clicking Next again on the File Configuration screen takes
you to the last screen where you can browse/modify AUTOEXEC.BAT
CONFIG.SYS or a user text file. You should not have to change
anything here.

Before clicking 'Done' use the Save button to save your
configuration. If you have not already done so, choose an
alternate name for the .CFG file - one that is appropriate
for your location. For example, we saved our configuration as:

IBMFalcon345.cfg

In the future you will use this new name when selecting a
configuration file to work with.

After the configuration is saved, click the Done button.
This will take you back to the 'Custom Configuration'
screen.

- If you choose the Program Settings option, the 'Program
Settings' screen is shown. The first few pages let you
enable/disable and set options for various bar code
symbologies. Change these as needed.

After the bar code options are some scanner options. By
default the 'Symbology Identifiers' are probably not checked.
If you need to identify the bar code symbology (using the
CFR API SenRead) then be sure to check this box. The
Auto-Terminator character should always be set to 'Carriage
Return' in order for the falc_tsr.exe to properly read
bar codes.

On the last page, there are other options for keyboard and
sound. Change them as needed.

Before clicking 'Done' use the Save button to save your
program settings. If you have not already done so, choose an
alternate name for the .PRS file - one that is appropriate
for your location. For example, we saved our configuration as:

IBMFalcon345.prs

In the future you will use this new name when selecting a
Program Settings file to work with.

After the program settings are saved, click the Done button.
This will take you back to the 'Custom Configuration'
screen.

- The default serial port settings for downloading to the terminal
are COM1 and a baud rate of 38400. If you need to change either
of these, select the Comm Settings button and make the changes.

- Once you have changed the configuration and program settings and
set the serial port settings, you are ready to download the
terminal. Press the Download button to start this process.

When the Download button is pressed, the Falcon Configuration
utility will process the specified files and will then present
a screen where you can verify the serial port parameters and
the set of files that will be loaded.

The 'Program Settings' that you set up earlier are transferred
in a file called 'bparams.ini'. Any modifications you made to
CONFIG.SYS and AUTOEXEC.BAT will be transferred as CONFIG.INS
and AUTOEXEC.INS respectively.

Before pressing OK on this screen, make sure you have attached
the serial cable between the terminal and the PC. Then from
the DOS prompt on the terminal, enter 'ld' to tell the terminal
to look for a download. Now press the 'Download' button on
the PC.

The download can take quite a few minutes. When it completes,
reboot the terminal. Verify that the terminal can be pinged
from the PC that is running the DCConnect Server and verify
that the DCConnect Client starts up properly on the terminal.

If you cannot ping the terminal, recheck the values in net.cfg
and socket.cfg. You can also reboot the terminal and try to
look for error messages that are given when the radio and
network drivers start up.

- If you need to update a file or two on the terminal, such as
EMULATOR.INI or ETSPT.EXE you can use the 'Transfer Files' from
the top level screen of the Falcon Configuration Utility to do this.

When you click the 'Transfer Files' button, the 'File Transfer'
screen is shown. Here you can build a list of files to be
transferred. Clicking the Add button allows you to add a file
to the list - after specifying the source and target of that
file.

When all the files have been added to the list, click the Send
button. You'll be presented the same screen that you get when
clicking the 'Download' button from the Custom Configuration
screen. Verify the serial port parameters and the list of
files. Make sure the serial cable is connected and start
'ld' from the terminal's DOS prompt. Then click the OK button
to start the transfer.

If you want to save this list of files, choose the Save option
and enter a name for the list. This list can be used the
next time you select 'Transfer Files' from the main screen by
selecting the 'Browse...' button after the 'File Transfer'
screen is shown.

Note that from the 'File Transfer' screen you can also upload
files from the terminal to the PC by using the Receive button
instead of the Send button.

- Once you've used the Falcon Configuration Utility to update one
terminal, you can use it again for each of your terminals. However,
you will have to change the contents of socket.cfg and perhaps
net.cfg for each terminal in order to change the IP address and
any other parameter that is unique for each terminal. This can
be a tedious process if a lot of terminals must be loaded.

One way to speed up this process is to make use of the files that
are generated by the Falcon Configuration Utility and set up a
batch file that builds socket.cfg and net.cfg from command line
parameters. We'll run through an example with socket.cfg to
illustrate. The configuration utility generated a socket.cfg
that looks similar to:

# Socket.cfg sets the options for Data Light socketp.exe
# The section xxx.xxx.xxx.xxx is for this machines IP
# /24=number of bits for class c
IP address 10.19.133.201/24

# Interface sets the physical interfaces
# pdr=packet driver
# if0=interface_card
# dix=frame type
# 1500=MTU
# 10=Buffers
# 0x69=ioaddr
Interface pdr if0 dix 1500 10 0x69

# When using a gateway (IP router) to the rest of the world,
# replace "XXX.XXX.XXX.XXX" with your gateway ip.
route add default if0 10.19.133.1

# Redisplay IP information
IP address

# options, refer to documentation to change
ip ttl 15
tcp mss 1460
tcp window 2920

Assuming all terminals will be using the same router/gateway, then
the only part of this file that has to be changed for each terminal
is the 4th line where the IP address is specified. We will split
this file into socket.1 and socket.2 which will be the parts that
come before and after the line that is different for each terminal.
Therefore socket.1 will contain:

# Socket.cfg sets the options for Data Light socketp.exe
# The section xxx.xxx.xxx.xxx is for this machines IP
# /24=number of bits for class c

and socket.2 will contain:

# Interface sets the physical interfaces
# pdr=packet driver
# if0=interface_card
# dix=frame type
# 1500=MTU
# 10=Buffers
# 0x69=ioaddr
Interface pdr if0 dix 1500 10 0x69

# When using a gateway (IP router) to the rest of the world,
# replace "XXX.XXX.XXX.XXX" with your gateway ip.
route add default if0 10.19.133.1

# Redisplay IP information
IP address

# options, refer to documentation to change
ip ttl 15
tcp mss 1460
tcp window 2920

A batch file is then created which takes as a parameter the
terminal's IP address. This batch file builds a socket.cfg
from the two parts, inserting the statement for the IP
address in the middle. We used the following LOADFALC.BAT
(located in the 'temp' directory where the Falcon Utility
is installed) to build both socket.cfg and net.cfg. In
our case, each terminal had a unique user name and password
in the 'Link Driver CISLEAP' section:

@echo off
if "%3" == "" goto needparms

echo Creating and copying socket.cfg . . .
type socket.1 > socket.cfg
echo IP address %1/24>> socket.cfg
type socket.2 >> socket.cfg

copy socket.cfg C:\Falcon\rf\network\socket.cfg

echo Creating and copying net.cfg . . .
type net.1 > net.cfg
echo user "%2">> net.cfg
echo password "%3">> net.cfg
type net.2 >> net.cfg
copy net.cfg C:\Falcon\32x\rf\NET.CFG

echo Calling download.bat . . .
call download.bat

goto end
:needparms
echo .
echo . You must provide the following parameters:
echo .
echo . - IP address to use for this terminal
echo . - LEAP User Name
echo . - LEAP Password
echo .
echo . For example (password not accurate):
echo .
echo . %0 10.19.133.201 TERMB665 xxxxxxx
echo .

:end

After socket.cfg and net.cfg are generated, they are
copied to the location where the Falcon Configuration
utility expects them to be.

After the files are generated and copied, download.bat
is called to perform the download process. DOWNLOAD.BAT
works in conjunction with RESPONSE.BAT and FILELIST.RSP
(all located in the 'temp' subdirectory) to load the
files that you set up initially with the Falcon
Configuration Utility. FILELIST.RSP contains the list
of files that will be loaded.

Be sure that the serial cable is attached and 'ld'
has been started on the terminal before running LOADFALC.BAT.

Note the use of 'type' above for appending the parts of
socket.cfg and net.cfg together. 'type' is used instead
of, for example:

copy net.cfg+net.2 net.cfg

because the latter method can result in end-of-file
characters in the middle of the file.

- The serial port of the PSC/Percon Falcon 345 can be used by the
Client to communicate with devices such as a serial printer.

Using the DCConnect Client on Selected Symbol Spectrum 24 Terminals
-------------------------------------------------------------------
This section describes what additional configuration must be done when using
the DCConnect Client on one of the following Symbol Spectrum 24 terminals:

PDT3140
LRT3840
VRC3940
WSS1040
WSS1060
PDT6840
VRC6940

All of these terminals have the same basic architecture and therefore all can
use the same configuration.

For more detailed information about using the above Spectrum 24 terminals please
refer to the following sections:

- Hardware and Software Requirements for Spectrum 24 Terminals
- Drive Arrangement on Spectrum 24 Terminals
- Transferring Files to a Symbol Spectrum 24 Terminal
- Spectrum 24 CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
- Rebooting the Spectrum 24 Terminal
- Spectrum 24 Bar Code Configuration
- Alternate method for building an INIT.EXE initialization program
- Serial Port Use on Symbol Spectrum 24 Terminals
- Starting the Client on the Symbol Spectrum 24 Terminal
- Setting Up a Spectrum 24 Terminal from Scratch

Hardware and Software Requirements for Spectrum 24 Terminals
------------------------------------------------------------
The supported Spectrum 24 terminals, require no additional hardware.
The terminals are shipped with the Novell Software TCP/IP stack, drivers and
terminal configuration tools already installed. Any additional software that is
needed to load and run the Client on Spectrum 24 terminals is provided by the
DCConnect Client product.

As of version 1.40T of the DCConnect Client, there is now a requirement that
the Symbol terminal be loaded with version 4.02.07 of the Lan Workplace (LWP)
flash load from Symbol. That flash load includes newer flash drivers that
can handle both old and newer flash chips in the Symbol terminals. The older
flash load does not work with the newer flash chips.

Note: The level of DCConnect Client files that works with the 4.02.07 Symbol
flash also works with the newer Symbol flash version 5.00.??.

As of September 2003, the 4.02.07 version of LWP was available from Symbol using the
following link:

Download Spectrum24� Series 3000 Flash Disk Architecture

Download the file LWP4_02_07.ZIP and the associated installation documentation.

Note: Support for allowing a hostname for the TCPIP_HOST keyword and for the -h
command line parameter is not provided for the Symbol Spectrum 24 terminals.
This is because including this support makes the executable too large to
run properly in the terminal.

Drive Arrangement on Spectrum 24 Terminals
------------------------------------------
The Spectrum 24 terminal can have a A:, B:, D: and E: drive. Drives A:, B:
and E: are read-only NVM(Non-Volatile Memory) drives. Special utilities,
provided with the DCConnect Client product, are used to build and load the
images for drive B:

Drive E: is the drive onto which the DCConnect Client files are copied during
the flash process. This process temporarily makes drive E: writable before
doing so. But after the flash process completes, drive E: is made read-only
again.

Drive D: is a RAM drive. The Client must have drive D: as the current
drive so that transactions can be written to 'disk'. It is recommended that
the RAM drive be set at a minimum size of 20K. The RAM disk size is defined
by INIT.EXE which is one of drivers that is included during the flash
build.

The RAM disk size can be changed using two different methods. The
easiest method is to bring up the init.bat file in an editor. There is only
a one line entry in the file, "ramchg xx". Where xx equals the size of the
ram disk in Kbytes. This file is already included in the flash image (see
MAKEHEX.BAT that is part of the self-extracting zip file SPEC24\FLSHBLD.EXE).

Once the flash is downloaded to the terminal at the next boot the RAM disk will be resized
to the new value. The second method is to create a new INIT.EXE driver. Please see
Alternate method for building an INIT.EXE initialization program.

Transferring Files to a Symbol Spectrum 24 Terminal
---------------------------------------------------
Files are transferred by connecting a cable between the Symbol docking station
and the PC COM port. The required cable should be provided with the docking
station. The files to be loaded to the terminal must first be converted into a
HEX image. This step is accomplished by running the MAKEHEX tool passing as
a parameter the type of Spectrum 24 terminal for which you wish to build the HEX
image. The MAKEHEX tool uses a response file (GENRSP.RSP) to determine what files
should be included in the HEX image. Once the files are in a HEX image format they
are downloaded using the LOADTERM tool.

The following response file was used during testing to build the NVM
HEX file that was then downloaded to the terminal:

First response file - genrsp.rsp
--------------------------------

nullsys.hex
/s command.com
/c apphex.sys
/a apphex.bat
/r init.exe
/r intb50c.exe
!
/u err3000.sys
/u pkunzjr.com
/u flashdsk.sys
/u flshctl.exe
/u flshfmt.exe
/u getnum.exe
/u chk_id.exe
/u ident.txt
/u _l.bat
!
/u _files.zip

/l 62995-01

/h /256 /320 em.hex

Note: The file _files.zip includes the following files:

init.bat ; Sets the size of D: drive ram disk.
etscheck.lic ; DCConnect Client license file
scan3000.exe ; Symbol Scanner file
s24_tsr.exe ; DCConnect Client scanner/serial port driver
scanparm.exe ; Symbol Scanner configuration tool
scanparm.ini ; Symbol Scanner configuration file
etspt.exe ; DCConnect Client - Novell flavor for Spectrum 24
emulator.ini ; DCConnect Client ini file
em.bat ; DCConnect Client startup file (created from one of
; the other .BAT files - PDT6840.BAT, LRT3840.BAT, ...)
; when MAKEHEX.BAT runs
flshprep.bat ; Used to allow the Client files to be updated after flashing

The last file in the list above, flshprep.bat, must be used in order to reload the
DCConnect Client hex file (generated by makehex.bat) to the terminal. This should be
run before you use loadterm.bat to load the terminal with the updated hex file. However,
it can be run afterwards if you forgot to do it before; you'll just have to cold-boot the
terminal again after doing so.

FLSHPREP.BAT temporarily makes drive E: writable so that E:\EM\_EXIST and E:\EM\IDENT.TXT
can be deleted; then it makes drive E: read-only again. This is necessary because the
AUTOEXEC.BAT will update drive E: with the downloaded Client files only if
E:\EM\_EXIST does not exist.

Spectrum 24 CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
--------------------------------------------------------------
The default terminal CONFIG.SYS file was used during our testing:

When the NVM HEX file is created, one of the files that is included in the
image is APPHEX.BAT. This file will become the AUTOEXEC.BAT
once the image is loaded on the terminal.

Following is the APPHEX.BAT file that was used during our testing:

@echo off
path b:;a:;e:
e:
if exist \em\_exist goto chdir
flshctl /w /d
set _FLSH=on
md \em

:chdir
cd\em
chk_id b: e:
if errorlevel 1 goto chain
if "%_FLSH%" == "" flshctl /w /d
set _FLSH=on
cls
echo.
echo.
echo Loading application
echo y > d:y.rsp
echo Please wait...
echo Copying to flash...
if exist _exist del *.* < d:y.rsp > nul
echo exist>_exist
pkunzjr -o b:_files
echo @call e:\em\em.bat > run.bat
copy b:ident.txt > nul
if exist e:\swupd\em.txt copy b:ident.txt e:\em\em.txt > nul

echo Flash update
echo complete.

:chain
if "%_FLSH%" == "on" flshctl /ro
set APP=
set _FLSH=
cd\
d:
flshauto

The APPHEX.SYS that is part of the NVM HEX image becomes CONFIG.SYS
once the image is loaded on the terminal. We did not change this
file during our testing.

In order to set the terminal's radio parameters (e.g. ESS Id) and
TCP/IP parameters (e.g. Subnet Mask, Default Router, MU IP Address)
a special program on the terminal must be used. For older versions
of the Symbol LWP flash (4.02.07 and earlier) this program was called:

CFG24.COM

For newer versions of the Symbol LWP flash on terminals with
802.11 radios, this is called:

CFG11.COM

Make sure the current drive is drive D: when you run this program.

Note: In CFG11, the network parameters are found by selecting the
'Boot Mode' option from the main menu. Press Clear/Esc to
leave this sub-menu.

After the changes are made, choose the Exit option - which will save
them first. Then cold-boot the terminal as described in the section
Rebooting the Spectrum 24 Terminal.

If upon Exiting CFG24/CFG11 you get a "File I/O ERROR" message, it
is probably because there is no free space on drive D: The CFGxx
program writes the new configuration to a temporary file before
replacing the NET.CFG. The default configuration of the DCConnect
Client and the default size of the RAM drive D: are set up so that
there is very little space left over after the Client creates its
transaction logfiles. To get around this problem, you can delete
LOG*.* from the D: drive (they are recreated the next time the
Client starts up) and then rerun the CFGxx program.

You could also decrease the default number of transactions (100)
defined for the MAX_TRANSACTIONS parameter in EMULATOR.INI - which
of course means the hex image would have to be recreated and
reloaded.

Rebooting the Spectrum 24 Terminal
----------------------------------
To Cold-Boot the terminal:

35-key PDT3140 Press and hold the [SPACE], [UP-ARROW] and [FUNC] keys.
Press and release the [ON/OFF] key.
Release [SPACE], [UP-ARROW] and [SHIFT] keys.

46-key PDT3140
LRT3840
PDT6840 Press and hold the [A], [B] and [D] keys.
Press and release the [PWR] key.
Release the [A], [B] and [D] keys.

54-key VRC3940 Press and hold the [F1], [F4] and [ENTER] keys.
Press and release the [On/Off] key.
Release the [F1], [F4] and [ENTER] keys.

WWS1040
WWS1060 Press and hold the [RIGHT-ARROW] and [ENTER] keys.
Press and release the [PWR] key.
Release the [RIGHT-ARROW] and [ENTER] keys.

To boot the terminal into Command Mode:

35-key PDT3140 Press and hold the [BKSP] and [SHIFT] keys.
Press and release the [On/Off] key.
Release [BKSP] and [SHIFT] keys.

46-key PDT3140
LRT3840
PDT6840 Press and hold the [F] and [I] keys.
Press and release the [PWR] key.
Release the [F] and [I] keys.

54-key VRC3940 Press and hold the [A] and [D] keys.
Press and release the [On/Off] key.
Release the [A] and [D] keys.

WWS1040
WWS1060 Press and hold the [ENTER] and [FUNC] keys.
Press and release the [PWR] key.
Release the [ENTER] and [FUNC] keys.

Spectrum 24 Bar Code Configuration
----------------------------------
When the terminal boots, the SCAN3000.EXE driver is started on the terminal to decode
the different scanner symbologies. The SCAN3000 driver, as shipped by Symbol,
supports most of the standard symbologies and in most cases the default scanner
decode set is all that is required. SCAN3000 scanner decoders and characteristics
can be modified by running the SCANPARM.EXE tool on the terminal. Decoders can be
activated or deactivated if the decoder was previously included in the SCAN3000 driver.
You tell SCANPARM.EXE which settings should be changed by creating a SCANPARM.INI.

The Client product CD includes a sample SCANPARM.INI (and backup SCANPARM.SMP) in the
self-extracting zip file \SPEC24\FLSHBLD.EXE. This sample .INI lists all of the possible
parameters as of the 3.xx version of the Symbol LWP flash. This is the same set of
parameters for versions 4.02-07 and 5.00-38 of the LWP flash. However, there's no
guarantee Symbol won't add additional parameters in the future.

The default value for some of the parameters has changed between versions of LWP flash.
Therefore you should not use the complete sample SCANPARM.INI file. Create a small .INI
file that includes only the parameters you need to change along with the appropriate section
header (the words enclosed in square brackets such as [DECODERS] or [CHARACTERISTICS]). For
example, if you wanted to be able to scan DUN14 barcodes (which are really I2OF5 format but
different length) create a SCANPARM.INI containing only the following:

[DECODERS]
CODE_I25
State=enable
MIN= 12
MAX= 18
DEP= 6

Or if you just wanted to enable the spotting beam, then create a SCANPARM.INI file that
contains just the following:

[MISC]
SpottingBeam=enable

If you wanted to do both, then create a SCANPARM.INI that contains both sets of lines:

[DECODERS]
CODE_I25
State=enable
MIN= 12
MAX= 18
DEP= 6

[MISC]
SpottingBeam=enable

Once you have created SCANPARM.INI you will need to update the appropriate .BAT file(s)
so that SCANPARM.EXE is called to process the SCANPARM.INI file. The .BAT file(s) to
change are dependent on the terminal model(s) you are using and will be one or more of
the following (included in FLSHBLD.EXE):

LRT3840.BAT
PDT3140.BAT
PDT6840.BAT
VRC3940.BAT
WSS1040.BAT

At the start of all of these files you will find the following four lines:

if "%1" == "" goto restrt
scan3000
rem scanparm /c e:\em\scanparm.ini
:restrt

You'll notice that the call to 'scanparm' is currently commented out. Simply remove
the 'rem ' at the beginning of the 3rd line so that the four lines now look like:

if "%1" == "" goto restrt
scan3000
scanparm /c e:\em\scanparm.ini
:restrt

Do this for all of the appropriate .BAT files.

MAKEHEX.BAT already includes SCANPARM.INI so you do not have to change that .BAT file.

The /C parameter tells SCANPARM.EXE to automatically configure the scanner using the
parameters in the specified .INI file merged with the current scanner settings.

From the command line of the Symbol terminal you can run SCANPARM.EXE two other ways
that will allow you to see the scanner settings:

- Running SCANPARM.EXE without any parameters brings up menus that allow you to view
all of the current scanner settings - and change them if necessary.
- Running SCANPARM.EXE with a file name but without the /C parameter shows the same
menus but the values you see will reflect the merging of the values from the
specified file.

Note that when specifying a file name as a parameter to SCANPARM.EXE that file
must either exist in the current directory or you must provide the full path to the
file.

By running SCANPARM.EXE on the terminal, you can figure out what to put
into SCANPARM.INI.

1) First make sure that the D: drive is the current drive and then
run SCANPARM at the command line without any parameters.
2) From the main menu choose the Edit Menu option
3) Use the sub-menus to change whatever options need to be changed.
The keys work as follows:
- Accepts the settings on the current screen and moves to the next one
- Moves up to the next value for the current field
- Moves down to the next value for the current field
- Move to the next field on the screen
- Toggles the Enable/Disable value for bar codes
- Returns to the previous menu (keeping any changes)
4) When done, use Esc to get back to the main menu
5) From the main menu choose the option to 'Save to disk'. This will
generate SCANPARM.INI in the current directory (should be on drive D:).
6) You can also use the 'Update Scanner' option to have the changes take
effect immediately so that you can test them.
7) Choose the Exit option to exit to the DOS prompt.
8) You can now use the 'type' command to see the contents of the
SCANPARM.INI that was generated by SCANPARM.EXE:

type scanparm.ini

The file contents will scroll by the screen. You can use the CTL key followed
by the C key to stop the file output. It may take a few attempts to stop the
scrolling at the right point. Use the F3 key (Func - 3) to recall the 'type'
command that you entered initially. That way you don't have to keep typing it in.
9) Once you find the proper parameters, you can create your own SCANPARM.INI
with the same subset of parameters - but make sure you include the appropriate
heading enclosed in square brackets (e.g. [DECODERS] or [CHARACTERISTICS]) before
the parameters that you add.

Alternate method for building an INIT.EXE initialization program
----------------------------------------------------------------
Most of the default settings of the terminal are sufficient in order for the
DCConnect Client terminal to be able to run. However, there may be situations
where the default settings need to be changed.

Symbol provides a tool in their Application Developer's Toolkit (ADK), called
BLDINIT, that can be used to generate an executable file, INIT.EXE, that can
change some of the terminal's default settings. INIT.EXE can change display
settings, keyboard settings, COM port settings, and other miscellaneous settings.
The BLDINIT tool provides a menu that lets you change the value for any of
these settings. When you save the settings, the BLDINIT tool generates 'C'
language source files that require the availability of a Microsoft Visual C++
version 1.5 16-bit compiler to create the INIT.EXE initialization program.
However, Microsoft no longer markets this version of 'C' compiler.

If you do not have access to the Microsoft 'C' compiler or the ADK, there is
an alternative method for changing the values of a few settings. Included in
the FLSHBLD.EXE self-extracting zip file that is in the directory where the
Client is installed, under the SPEC24 directory, is a prebuilt flavor of
INIT.EXE that sets values for the following settings:

Size of the RAM drive
Backlight timeout delay value
Block Cursor on or off

Note: If only the size of the RAM size needs to be changed, then then you can
simply change the contents of the INIT.BAT file rather than setting up
a separate INIT.EXE file. INIT.BAT calls the program RAMCHG.EXE that is
part of the Symbol flash for the terminal. INIT.BAT is included in
the FLSHBLD.EXE self-extracting zip file.

All other configuration settings are defaulted to the values we used during our
testing. In addition to the INIT.EXE found in the .ZIP file, the Client
also includes the program CFG3000.EXE in the \SPEC24 directory. This program is
used to modify the values of the above listed settings directly in the INIT.EXE
file.

The CFG3000 configuration tool is started from a PC server command line.
The three different configuration options can be selected, changed and saved
by using the following keys:

F1 - Help
F9 - Keys Help
F2 - Change the RAM disk size
F3 - Change the backlight timeout value
F4 - Active or deactive the terminal block cursor
F5 - Save change and exit
ESC - Exit

At start up, if the CFG3000 tool locates a copy of the INIT.EXE file in the
current directory it will ask if you wish load its configuration as the
starting point or use the default values. Once you have made any changes to
the configuration you will be asked if the changes should be saved. You can
exit the tool without saving the changes at anytime by pressing the 'ESC'
key. If changes are saved, the updated copy of the INIT.EXE program can
found in the current directory.

Once the INIT.EXE has been created as you need it, it will automatically
be included as part of the hex files that you create because it is
already referenced in GENRSP.RSP. It is also automatically called when
the server boots up.

Serial Port Use on Symbol Spectrum 24 Terminals
-----------------------------------------------
As of version 1.40O of the Client, support for the serial port on Symbol
Spectrum 24 terminals is now possible. In order to use the serial port, the
program S24_TSR.EXE (provided with the Client) must be started before the
Client and the keyword USE_TSR_FOR_RS232 must be added to the EMULATOR.INI
file. For more information see Keyword: USE_TSR_FOR_RS232.

Prior to version 1.40O, the serial port was not supported on any Spectrum 24
terminals.

Starting the Client on the Symbol Spectrum 24 Terminal
------------------------------------------------------
S24_TSR.EXE must be started before the Client. This is a TSR (terminate
and stay resident) program that controls the turning on and off of the
terminal laser scanner.

Before starting the Client, the current drive must be the RAM drive.
This is necessary because the Client opens and writes to data files.
Because the Client must use the RAM drive as the current drive, the
ETSCHECK.LIC file must be copied to that RAM drive (drive D:) before
the Client can run successfully.

When starting the Client in a Spectrum 24 terminal you must use the terminal
device command line switch to indicate the model of terminal being used. For
example, if your terminal type is a LRT3840 the command line switch would be
-dLRT3840. For more details about this and other command line parameters, see
the earlier section called Common Command Line Parameters for the Client.

All of the requirements above are satisfied with the default set of files
provided in the self-extracting zip file, FLSHBLD.EXE, which can be found
on the in the SPEC24 directory where the Client is installed. This zip file
includes a series of files that define the startup sequence on the terminal.
Steps in this sequence include setting the size of the RAM drive, copying
needed files to the RAM drive D: and starting the DCConnect Client using
the command line switch required for the terminal type that is indicated
when the flash image is built. The following section explains how to
use the files in FLSHBLD.EXE to setup and configure the terminal.

If you end the DCConnect Client and go to a DOS prompt, the Client can be
restarted by doing a cold-boot of the terminal or by simply running EM.BAT
by entering the following at the DOS prompt:

If you have trouble starting the Client (it returns to the DOS prompt), make
sure that the terminal can be 'pinged' from the DCConnect Server. If not,
you may need to make changes to the radio parameters or TCP/IP parameters.

If the terminal can be 'pinged' make sure that the Client is being started
with drive D: being the current drive and that there is enough space on
drive D: to create LOGFILE.NDX and LOGFILE.LOG. LOGFILE.NDX is 12 bytes and
LOGFILE.LOG is 131 bytes for each transaction (defined by MAX_TRANSACTIONS).
So if MAX_TRANSACTIONS is 100, LOGFILE.LOG will be 13100 bytes. If there is
not enough to accommodate the logfiles, you will have to decrease the
MAX_TRANSACTIONS parameter in EMULATOR.INI, regenerate the HEX image and
reload the terminal.

Setting Up a Spectrum 24 Terminal from Scratch
----------------------------------------------
The following instructions assume the terminal has the standard factory
Novell flash installed. All new terminals received from Symbol have this flash
flash installed. If the terminal doesn't have the standard flash, you can
download the files needed to install the flash, free of charge, from the
Symbol web site.

1) Connect a cable between the Symbol docking station and the PC server's COM port.
The required cable should have been provided with the docking station. If you
didn't get the cable with the docking station, a null modem cable can be used,
but it will require a gender changer. Insert the terminal into the docking
station and make sure the terminal is powered off by pressing the [PWR] key.

2) Create a work directory on the PC server. Copy the file FLSHBLD.EXE from the
SPEC24 directory where the Client is installed into the new work directory.
Switch into the work directory on the PC server and type FLSHBLD on the
command, and press enter. This is a self-extracting pkzip file, it will expand
out into all the files that are required to load and configure the terminal.
You will need one additional file; copy the ETSCHECK.LIC file from the directory
where the DCConnect Client is installed into the PC server work directory.

3) Two of the files included in FLSHBLD.EXE define the size of both the D: RAM
drive and transaction log file. The default configuration is 20 Kbytes for the
size of the RAM disk which can accommodate a transaction log file that can
hold around 135 transactions at 131 bytes each (although by default
MAX_TRANSACTIONS is set to 100 so that there is some free space on the RAM disk).
Other files that must reside on the RAM disk are DCConnect Client files such as
EMULATOR.INI and ETSCHECK.LIC and terminal generated files such as NET.CFG and
_AP.BAT.

The transaction log is needed in order to store transactions during periods
when the terminal is out of range of the Access Point. Transactions can be
entered on the terminal and they will be written safely into the transaction
log file. The next time the terminal comes into range of the Access Point the
stored transactions are automatically sent to the DCConnect Server. Since the
RAM drive is a part of the RAM storage area the larger the RAM drive the less
memory that is available for transaction programs, validation files, and custom
function routines( CFRs). The default configuration frees up to 192 Kbytes RAM
memory.

Note: Because the transaction logfile is on a RAM drive, which is volatile
memory, it will be destroyed if the terminal is cold-started or a total
loss of battery power occurs.

If you need more free memory for your transaction programs and files, the size
of the D: RAM drive can be made smaller by modifying the parameter in the INIT.BAT
file. To make the change, just bring up the INIT.BAT file in any editor. There is
only a one line entry in the file, "ramchg xx". Where xx equals the size of the
RAM disk in Kbytes. As an example if you need to resize the RAM drive to 15 Kbytes,
you would change the parameter to "ramchg 15". Any time the RAM drive is made
smaller, the transaction log file size must also decrease. The size of the
Transaction log file is controlled by the MAX_TRANSACTIONS parameter in the
EMULATOR.INI file. This value is maximum number of transactions the file can store.
For more information about using this and other EMULATOR.INI file parameters,
please refer to Configuration using EMULATOR.INI.

Parameters that are recommended in EMULATOR.INI are:

NUM_PF_STRINGS = 0
NUM_TOUCH_STRINGS = 0
MAX_TRANSACTIONS = 100
USE_TSR_FOR_SCANNER = Y
USE_TSR_FOR_RS232 = Y
PF_MAPPING = Y
TCPIP_HOST = aaa.bbb.ccc.ddd

where 'aaa.bbb.ccc.ddd' is the IP address of the DCConnect Server.

4) If any of the default scanning symbologies and/or parameters need to be ,
changed, then create SCANPARM.INI and modify the appropriate .BAT files as
described in Spectrum 24 Bar Code Configuration.

To best way to determine what the current scanner settings are for the
Symbol LWP flash level that is loaded is to run SCANPARM from the terminal
DOS prompt and navigate through all of the menus.

5) On the PC server command line enter "MAKEHEX terminal type". Where "terminal
type" would be the type of Symbol terminal you are going to load the new flash
on. The available types are PDT3140, LRT3840, VRC3940, WSS1040 or PDT6840.
As an example, if you wish to build the HEX image file for a terminal type
PDT6840, you would enter the following command:

MAKEHEX PDT6840

If there are no errors with the HEX image build, you will receive a message
indicating that the build was successful. The file EM.HEX is created; in
addition EM.HEX is copied to xxxxx.HEX where 'xxxxx' matches the parameter
passed on the command line when MAKEHEX.BAT was run. This is usefull if you
have several models of Symbol terminals for which .HEX files must be created.

6) The next step is to enter the following command on the PC server command line:

LOADTERM PDT6840

The following messages will display:

Loading PDT6840.HEX . . .
Press [ENTER] when remote is ready. ESC to abort...

Don't press enter yet!

Note: You can run LOADTERM.BAT without any parameters; in this case the name
of the .HEX file to be loaded is assumed to be EM.HEX.

7) If this is not the first time that you are loading the DCConnect Client .HEX file
to this terminal, please run:

FLSHPREP

from the command line so that the previous version of the Client is removed from
drive E: For more information about this process and why it is necessary, see
Transferring Files to a Symbol Spectrum 24 Terminal.

8) The terminal must now be put into "Program Loader" mode to start the the process
of downloading the new HEX image. Some of the terminals in the Spectrum 24 family
have fewer keys than others. The keys that are used to set the terminal into
Program load mode and start a cold reboot are different depending on which model
you are loading. In the following steps you will find a number of different key
combinations that must be used to perform loading process. Be sure only to use
the key combination that pertains to the terminal model you are loading.

On the terminal do the following steps to put it in the mode for downloading:

a) Turn the terminal off by pressing the [PWR] or [On/Off] key.
b) Boot the terminal into Command Mode as described in the section
Rebooting the Spectrum 24 Terminal
c) The terminal will boot into command mode.
d) Press the down arrow until "Program Loader" displays.
e) Press [ENTER]. A erase EEPROM warning will display; press [ENTER].
f) Once the erase completes the Comm Parameters screen will display.
g) Using the down arrow select Baud = 38400 press [ENTER]..
h) Data Bits = 7 [ENTER].
i) Parity = odd [ENTER].
j) Flow Control = Xon/Xoff [ENTER].

The terminal will display "Start?". Press [ENTER] on the terminal.

9) Immediately press [ENTER] on the PC server. (the terminal side must be started
before the PC side). The HEX image download will now start. You should begin
to see status displayed on both the terminal and the server. A successful
reflash will display "Bytes Send 100% "on the server and "Status 0000" on the
terminal. The terminal must now be cold booted to complete the flash update and
configuration.

10) On the terminal do the following steps to cold boot the terminal:

a) Turn the terminal off by pressing the [PWR] key.
b) Cold-Boot the terminal as described in the section
Rebooting the Spectrum 24 Terminal
c) After the cold boot starts you will begin seeing a series messages about
inflating files. The terminal is actually updating flash with the files
that were just loaded to it. After the reflash step completes, the terminal
will display the message, "flash update complete". You don't have to do
anything yet
d) Next the terminal will display, "software update?". Just let this message
time out or answer no.
e) The terminal may display, "remove from cradle". If this message displays
remove the terminal from the cradle and it will continue to boot. On
some terminals a menu will display, one of the options will be "EM".
Select this option to continue until the Client logo screen displays or
it comes up with the following message:

Terminal cannot associate with AP you're out of range or not configured.
Ctrl-C to end or other key to retry.

If you receive this message, press the [CTL] key followed by the 'C' key.
A "Halt Batch Process(Y/N)" message with display. Enter 'Y' for yes and
the DOS command line will now display.

The reason this message displays is because either there is a NET_ID mismatch
or the access point is not powered on. The Net ID is used to allow multiple
wireless LANs to co-exist in a single environment by assigning different Net
IDs for each LAN. The terminal Net ID must match the one that is being used
in the wireless LAN that connects to the DCConnect Server. If you only have one
access point, it is most likely set to the default Net ID 101. If this is not
the case, you will have to refer to the access point documentation on how to
view and configure the access point's Net ID.
f) In the case where the Access Point is powered on and the NET_ID matches, the
Client logo screen will appear. Press the [=] key to display the main Client
menu. On most terminals this is generated by pressing the [FUNC] key and then
the [ENTER] key. If this combination doesn't work on the model you are loading,
refer to the Terminal documentation for the correct key combination to generate
an [=] key. When the main menu displays, select "Exit to DOS" by typing a [X]
and pressing [ENTER].
g) On the DOS command line type cfg24 or cfg11 and press enter. The Terminal Configurator
menu will display and items can be selected by moving up and down the list
using the up/down arrows. The options that need to be configured before the
terminal can successfully communicate with the DCConnect Server are
"Subnet Mask", "Default Router", "MU IP Address" and "ESS ID" (aka Net ID). The other
parameters can be left as default.

Note: If running CFG11, the ESS ID is on the first menu, but to get to the
other parameters you must first choose the 'Boot Mode' option. After you
set the network parameters, press Esc/Clear to return to the main menu.

Choose the Exit option to save the configuration and exit the program.
h) Once you have completed the Terminal Communication setup, follow the cold boot
instructions in steps a) and b) above to reboot the terminal. When the cold
boot completes, the Client will automatically start and should be able to
communicate with the DCConnect Server if the server is running.

Using the DCConnect Client on Teklogix 7035 Terminals
-----------------------------------------------------
This sections gives a few notes about using the DCConnect Client on the Teklogix
7035 terminal.

While the Teklogix 7035 terminal is currently in use at one or more customers,
we have not yet had the opportunity to do the in depth investigation needed to fully
document all aspects of configuring these terminals. Please consult the
manufacturer's documentation for any information required.

- The Teklogix 7035 requires the flavor of the DCConnect Client that uses the
FTP Software TCP/IP stack and the alternate video drivers. This is found in the
\TCP_FTP\NLS directory where the Client files are installed.

- Drives C: and D: are ROM drives that can only be modified using a
process that entails creating an image of the contents of that drive
and then putting the terminal in a special mode before transferring
image to it.

- Drive A: is the read-write drive on the Teklogix terminal. It is therefore the
drive that the Client must run in.

Here is the EM.BAT we used on the 7035 terminal:

@echo off
cls
a:
cd \
etspt
cls

- Below is the content of the EMULATOR.INI we used on the 7035 terminals:

NUM_PF_STRINGS = 0
NUM_TOUCH_STRINGS = 0

MAX_TRANSACTIONS = 10

PF_MAPPING = Y

NUM_ROWS = 18
NUM_COLS = 20

TCPIP_HOST = 102.102.102.101

DONT_CHANGE_SCREEN_SIZE = Y
IGNORE_UNDERLINE = Y

SCAN_SENTINEL_CHARS = 1,2

An explanation of each parameter follows:

- NUM_PF_STRINGS = 0 and NUM_TOUCH_STRINGS = 0 are used to
maximize the memory available in the terminal for
downloaded files.

- MAX_TRANSACTIONS = 10 sets the transaction buffer
size to its minimum - to maximize the memory
available for transactions. Change this if the
terminal needs to buffer more transactions.

- PF_MAPPING = Y allows the terminal's numeric keys to
be used as the PF1 through PF10 keys.

- NUM_ROWS = 18 and NUM_COLS = 20 tell the Client
the dimensions of the terminal's physical screen.

Note: The Teklogix 7035 terminal provides a utility
that allows you to change the font and other
configuration parameters. While many handheld
devices that we support use 16x20 for the
screen size, 18x20 is the closest to that size
that is available on the 7035.

- TCPIP_HOST = 102.102.102.101 tells the Client the
IP address of the DCConnect Server. Change this
to make it correct for your DCConnect Server.

- IGNORE_UNDERLINE = Y is required in order to tell
the Client to ignore the underline attribute
wherever it may be used. Characters using this
attribute are shown normally instead. The Teklogix
7035 does not support the underline character;
if the attribute was used, the character would
not be visible.

- SCAN_SENTINEL_CHARS = 1,2 tells the Client the
characters that will signal the beginning and ending
of a bar code so it can distinguish scanned data from
data that is keyed in even though both go into the
keyboard buffer. For more information about the
SCAN_SENTINEL_CHARS keyword and its benefits, please see
Keyword: SCAN_SENTINEL_CHARS.

Along with the use of this keyword, the terminal must
be configured to use the corresponding prefix and suffix
characters. This is done using a utility that is
already on the Teklogix 7035 terminal. Some notes
about the use of this utility are described in the
next bullet.

If you find that the DCConnect download to the terminal is
failing due to lack of space, you will probably also need to
use the FILE_PAGING and possibly the LOCK_IN_MEMORY keyword.

For more information about the EMULATOR.INI parameters, see
Configuration using EMULATOR.INI.

- The Teklogix 7035 includes a utility for configuring the
terminals font, prefix/suffix characters for bar codes and
other parameters.

Before this utility can be used, the menu drivers must be
running. If they are not started automatically by AUTOEXEC.BAT
then run the following from the command line to start them:

p2man -i

Once the menu drivers are running you can start the
configuration utility by running 'Start' from the DOS prompt.
Pressing 'A' for the Parameters option on the opening screen
takes you to a list of parameters that can be configured. But
first you are prompted for a password; the default is '123456'.
You'll also be prompted to change the password; if you just
press Enter when this prompt appears, the password will remain
the same.

Use the up and down arrow keys to move between menu choices.
Press F1 to enter one of the submenus. Press F2 to return
from a submenu to its parent menu.

Use the up and down arrow keys to move between different
parameters on a menu. For any parameter, the left and right
arrow keys are used to scroll through the choices available
for that parameter.

The parameters we changed during testing were:

- From the System menu - set the font to 18x20
- From the System menu, panning submenu - set Auto pan to N.

Note: When Auto-pan is turned off commands that are
executed at the DOS prompt, including those during
a reboot, will scroll off the bottom of the screen
because the terminal 'view port' remains at the
top of the virtual screen. You can manually
scroll the view port down to see the bottom of
the virtual screen (using Blue Shift and the
arrow keys). The Client will always write to the
screen assuming the view port is at the top of the
virtual screen.

- From the Scanner menu, Bar code submenu - For each bar code
type enter F1 to get to its sub-menu, scroll down to the
Size/Chars menu option and press F1 to go to this sub-menu.
Set the Prefix Char to 1 and the Suffix Char to 2. Use
F2 to return to the Bar code submenu and repeat this for
every active bar code symbology.

This must be done in conjunction with the use of the
keyword:

SCAN_SENTINEL_CHARS = 1,2

in EMULATOR.INI that is described above.

Once you have made all changes, use PF4 to Save them. Then you
can exit the utility. This is done by pressing F2 until you
are back at the main menu; then choose option 'C' to go to
the DOS prompt - but you must first enter the same password
you entered to get to the Parameters.

If you started the menu drivers manually, you can stop them
by entering the following command from the DOS prompt:

p2man -u

- In order to generate certain characters on the Teklogix 7035
keyboard, the blue or orange shift keys may be required. If
required these keys are pressed and then released before the
other desired key - rather than pressing and holding them.

The Orange shift key is 'sticky' - meaning that the keyboard switches
to 'Orange mode' once the Orange shift key is pressed and it remains
in 'Orange mode' no matter how many other keys are pressed - until
the Orange shift key is pressed again.

The Blue shift key on the other hand is not 'sticky' if you press it
once before pressing another key. Once the other key is pressed
the 'Blue mode' is ended. If you want the Blue shift key to be 'sticky',
press it twice before pressing the next key. You can tell that
you are in 'sticky' 'Blue mode' because the word BLUE is in
upper case in the lower right of the screen.

- If you need to reboot the Teklogix 7035 terminal, press and
hold the Blue Shift key and press and hold the red Enter key.
Keep holding these two keys for at least 6 seconds - at which
time the screen will clear the the reset will start.

- The Backspace key is labelled 'DEL' - one of the grey keys on the
left side of the keyboard.

- Files are loaded to the A: drive of the Teklogix 7035 terminal
using Ymodem-G file transfer protocol which is provided by telnet
programs such as Hyperterminal - which comes with Windows 95/98/NT/2000.

Using Hyperterminal, choose the appropriate serial port and use the
communications parameters: 57600 baudrate, No parity, 8 data bits,
1 stop bit and use 'Auto-detect' for the emulation type. Start the
connection if it does not start automatically.

Note: Teklogix provides a special '20075' serial cable with a button
on it to use when reflashing the C: or D: drives. Do not use
this cable when loading files to drive A: using Hyperterminal;
use the cable without the special button on it.

Make sure the serial cable is properly attached to the terminal and
the PC. Then use Transfer -> Send File to start the file transfer
process from the PC. Locate the proper file name and then specify:

Ymodem-G

as the protocol - but do not click 'Send' until the terminal is ready.

On the terminal, make sure A: is the current drive and then run the
following from the DOS prompt:

ymodem -y57600

The terminal will then wait for the PC to start transferring. You can
now press 'Send' on the PC side.

- To send files from the Teklogix terminal to the PC, use the receive
function of Hyperterminal, but choose the 'Ymodem' protocol instead
of 'Ymodem-G'.

On the terminal side, when you run ymodem you also need to use the -s
parameter followed by a space and the file name to upload. For example,
to upload PCTCP.INI from drive A:

ymodem -y57600 -s pctcp.ini

- Parameters related to the radio, such as Network Name and Access Point
Density are found in the file PACKET.INI on the A: drive. You can
upload and reload this file using a telnet program such as Hyperterminal -
as described above.

- Network parmeters such as IP address, subnet mask and gateway/router are
found in the file PCTCP.INI on the A: drive. You can upload and reload
this file using a telnet program such as Hyperterminal - as described above.

These parameters are located in the section similar to the following:

[pctcp ifcust 0]
ip-address = 102.102.102.103
subnet-mask = 255.255.255.0
router = 102.102.102.1
interface-type = PKTDRV
frame-type = DIX-Ethernet

- AUTOEXEC.BAT and CONFIG.SYS are located on drive C: of the terminal.
It is therfore necessary to recreate the image of the ROM drive C: in
order to update either of these files. Please consult the manufacturer's
documentation for instructions about how to do this.

Therefore, in order to change AUTOEXEC.BAT to call EM.BAT so that the
DCConnect Client starts automatically after a reboot, the drive C:
image must be recreated and reloaded.

- If you find there is not enough memory to download DCConnect files to
the terminal, you can try removing statements from CONFIG.SYS. You
should be able to run the DCConnect Client with only the following
statements in CONFIG.SYS:

DEVICE = A:\himem.sys
device=a:\emm386.exe noems novcpi X=D000-D1ff
dos=high, umb
SHELL=C:\COMMAND.COM /E:512 /P
LASTDRIVE=F
FILES=30

and only the following statements in AUTOEXEC.BAT:

SET PATH=C:\;D:\;A:\
power ADV
sysmon -i
p2man -i
scan -i -k#
a:
detect
dynaload d:\wvlancad.sys /b=340 /i=11 /m=d000
wvlan42 l
sysmon -p
a:
p2man -u
ethdrv

REM the following statement automatically starts the DCConnect Client
call em

You might also be able to use 'sysmon -u' instead of 'sysmon -p' to
unload the System Monitor instead of having it monitoring packets.

If after making these changes and recreating and reloading the C: drive
image, downloads to the terminal still fail, then try the FILE_PAGING
and LOCK_IN_MEMORY keywords mentioned above in the discussion of
EMULATOR.INI.

- The serial port of the Teklogix 7035 can be used by the Client to
communicate with devices such as a serial printer.

Using the DCConnect Client on Telxon PTC960SL/X, PTC860IM and PTC870IM Terminals
--------------------------------------------------------------------------------
This section describes what additional configuration must be done when using
the DCConnect Client on one of the following Telxon terminals: PTC960SL,
PTC960X, PTC860IM or PTC870IM. For the most part, these terminals are
configured the same way. But there are a few differences - because of
differences in screen size and because the PTC870IM has a different internal
architecture (pen-based). Unless otherwise noted, all instructions below
apply to all the supported models of Telxon terminals.

The screen sizes use by the Client for the Telxon terminals are as follows:

- 16x21 for the PTC960SL and PTC960X
- 8x40 for the PTC860IM
- 20x40 for the PTC870IM

For more detailed information about using Telxon terminals please refer to the
following sections:

- Hardware and Software Requirements for Telxon Terminals
- Drive Arrangement on Telxon Terminals
- Transferring Files to a Telxon Terminal
- Telxon CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
- Telxon Bar Code Configuration
- Serial Port Use on the Telxon Terminal
- Starting the Client on a Telxon Terminal
- Setting Up a Telxon Terminal from Scratch

Hardware and Software Requirements for Telxon Terminals
-------------------------------------------------------
As of version 1.40E of the Client, support for the serial port on Telxon
terminals is now possible. In order to use the serial port, the program
TELX_TSR.EXE/T870_TSR.EXE (provided with the Client) must be started before
the Client is started (whether using the serial flavor or TCP/IP flavor)
and the keyword USE_TSR_FOR_RS232 must be added to the EMULATOR.INI file. For
more information see Keyword: USE_TSR_FOR_RS232.

Telxon terminals must use the TCP/IP flavor of the Client that talks to
the FTP Software TCP/IP stack. However, you do not purchase the PC/TCP
product directly from FTP Software. Instead, when ordering your Telxon
terminals, you must specify that they be flashed with the AirBeam TCP/IP flash.
There are several iterations of this flash. The latest as of May, 2000
requires a 512K ARC drive (drive B:) because of drivers for 802.11 radios that
are now included. Its part number is:

IL990151

The prior version required only 256K for the ARC drive. It's part number is:

IL970215

This flash not only provides all the necessary Telxon specific radio drivers
but it also includes a licensed version of the FTP Software TCP/IP stack.

Furthermore it provides a mechanism that allows an out-of-the-box Telxon
terminal to be loaded from an FTP server (OS/2 and Windows/NT both work) after
entering a few parameters from the initial AirBeam flash screens on the
terminal. Setting up the FTP server will be explained later in the section
called Transferring Files to a Telxon Terminal.

Though not required, it is suggested you install the necessary components of
either Windows/NT or OS/2 4.0 that will provide FTP server capability.
Presumably your data collection server (e.g. DCConnect) will be installed on
one of these two operating systems and will already be set up with TCP/IP
support since that is required to communicate with Telxon terminals. If that
is the case then only a few more steps are required to set up FTP server
capability.

On OS/2 4.0 nothing more needs to be installed, but you will have to configure
a User ID and Password for FTP clients to use when logging in. This is done
using the Securty tab of the TCP/IP Configuration notebook.

On Windows/NT 4.0 you will need to install the Microsoft Peer Web Services in
order to get FTP server capability. This can be done using the Add button of
the Services tab of the Network Settings notebook in the Control Panel. Once
installed, use the Start -> Programs -> Microsoft Peer Web Services (common) ->
Internet Services Manager to set up access to a directory that will contain
files to be loaded to the Telxon terminal. You may want to set up another
Windows/NT user ID with limited access by using Start -> Programs ->
Administrative Tools (Common) -> User Manager. Use this new user ID and
password for the Telxon terminals when they log in as FTP clients. This
password is stored in one of the configuration files on each terminal - which
is why you probably don't want to use your normal Windows/NT user ID and
password.

The Telxon terminal must have a minimum of 1MB of RAM in order to have a RAM
drive large enough to store the Client and its related files and still have
enough memory to run the Client.

The B: drive must be large enough to hold the AirBeam flash referenced above.
For AirBeam version 1.23, 256KB is required.

Check with Telxon for any requirements that using the AirBeam flash may place
on the access points and other parts of the network.

Drive Arrangement on Telxon Terminals
-------------------------------------
The PTC960SL, PTC960X and PTC860IM terminals always have A: B: and C: drives.
Here are the characteristics of each:

A: is referred to by Telxon as the 'E-disk' or 'Electronic disk'. It is a
RAM drive - allocated out of the minimum 1MB RAM. This is the only
writable drive on these Telxon terminals. It is technically not
considered non-volatile memory - although the only way for it to lose
its contents is if the internal backup battery were to lose all of its
power (not likely) or if the terminal is cold-booted.

The A: drive does preserve its contents through a normal power off-on
sequence and through a Cntrl-Alt-Del reboot.

With 1MB of RAM, this drive is typically 512K.

B: is referred to by Telxon as the ARC drive. It is a flash ROM EPROM.
Its contents can only be changed through a flashing process; applications
running on the terminal cannot write to this drive.

This is where the AirBeam flash will be installed. This drive is
non-volatile so you will never have to worry about losing its contents.

C: This drive contains the DOS bootable image. This is non-volatile memory
that cannot be and should not ever need to be changed.

The PTC870IM terminal has a C: and D: drive with the following characteristics:

C: is equivalent to the B: drive described above; it is where the AirBeam
flash is installed. This is a 2MB drive - more than enough to hold the
AirBeam flash.

D: is equivalent to the A: drive above; it is where the Client files are
loaded and run from. With 2MB of RAM in the terminal (the minimum
available), 1MB of it is allocated for this D: drive. Which is plenty
for the Client and all of the files it needs.

The Client must run on a writable drive so that transactions that are
generated can be preserved through shutdown of the Client and power down of
the terminal. The Client must therefore run from the D: drive for the
PTC870IM, and from the A: drive for all other terminals.

Transferring Files to a Telxon Terminal
---------------------------------------
There are two methods for transferring files to a Telxon terminal. The
preferred method uses File Transfer Protocol (FTP) to an FTP server. An
alternative method uses a serial conneciton to the terminal and a serial
transfer program.

1) Using the AirBeam flash, terminals can be easily loaded automatically
from an FTP server. In addition, using version information, every time
a terminal is rebooted, that terminal will check the FTP server for updated
files and if any are found, they will automatically be downloaded to the
terminal.

In order to use this method, the Telxon access points must be installed
and functioning properly on the network and an FTP server must be installed
somewhere in the network. For hints about setting up the FTP server, refer
to Hardware and Software Requirements for Telxon Terminals.

On the FTP server you must first set up a directory that will be used for
transferring files to the terminals. This directory must be created under
the 'home' directory that FTP clients are put into when they initially log
in. In the examples in this document the home directory will be assumed
to be c:\ftp_home. Under this we'll create a directory called telxon. So
all files to be sent to the terminal will be in:

c:\ftp_home\telxon

and its subdirectories.

In this directory one or more 'packages' will need to be set up. A
package is a set of files that are to be downloaded to the terminal. All
PTC960SL and PTC960X terminals will probably use the same package. While
PTC860IM terminals and PTC870IM terminals will use their own separate
packages - because of the differences in screen size and architecture.
Multiple packages can share many of the same files.

Each package must have at least two special files that define the package
and how it will run after it is downloaded to the terminal:

package_name.PKG - This is the package file which contains a list of files
that should be downloaded to the terminal.

package_name.BAT - This is the batch file that will be started on the
terminal after all files are downloaded from the
server. It is also called whenever the terminal is
rebooted; it is the last call made from AUTOEXEC.BAT.

Note: it is important that this batch file name be
included in the list of files in the .PKG file.

The package_name portion of both file names is the same. We'll use three
package names in this example: ptc960, ptc860 and ptc870.

This example assumes PTC960, PTC860 and PTC870 terminals will be used. To
organize files, 4 subdirectories will be created:

c:\ftp_home\telxon\960
c:\ftp_home\telxon\860
c:\ftp_home\telxon\870
c:\ftp_home\telxon\common

Most files will go into c:\ftp_home\telxon\common. One difference is EM.BAT
which is used to call the Client specifying the device parameter. Since
the device parameter is different for the different terminals, this batch
file is different. Here are the contents of a sample package file for the
PTC960 terminals (ptc960.pkg)

config 1,200000,,,REPLACE
file \telxon\960\ptc960.bat, \ptc960.bat, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\960\em.bat, \em.bat, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\etspt.exe, \etspt.exe, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\etscheck.lic, \etscheck.lic, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\emulator.ini, \emulator.ini, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\etscfg.tcp, \etscfg.tcp, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\wandtsr.exe, \wandtsr.exe, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\telxonbc.exe, \telxonbc.exe, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\telxonbc.cfg, \telxonbc.cfg, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\telx_tsr.exe, \telx_tsr.exe, FILE_SYSTEM, ERASE_ON_DISCARD

A similar package file for PTC860 terminals (ptc860.pkg) would also be set
up. The only difference would be that references to 960 above would be
changed to 860.

The package file for the PTC870 terminals (ptc870.pkg) not only uses 870
whereever references to 960 are, but also uses a different flavor
of telx_tsr.exe (also provided with the Client) that is specific to the
pen-based architecture of the PTC870 terminal:

config 1,200000,,,REPLACE
file \telxon\870\ptc870.bat, \ptc870.bat, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\870\em.bat, \em.bat, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\etspt.exe, \etspt.exe, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\etscheck.lic, \etscheck.lic, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\emulator.ini, \emulator.ini, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\etscfg.tcp, \etscfg.tcp, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\wandtsr.exe, \wandtsr.exe, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\telxonbc.exe, \telxonbc.exe, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\telxonbc.cfg, \telxonbc.cfg, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\870\telx_tsr.exe, \telx_tsr.exe, FILE_SYSTEM, ERASE_ON_DISCARD

A few notes about package files:

a) All commands must start in column 1

b) You can add comment lines to the package file by putting a semicolon
in column 1. Everything else on the line is ignored.

c) The first line contains the 'config' statement which has several
parameters:

- The first is the version number (1 above). This value is used by each
terminal at boot up time to determine if it has the latest version of
the package. Each time you update the package - whether changing the
list of files or the contents of any file in the package - this version
number should be incremented so that terminals can determine that the
package has been updated.

If you change the package file list or change the contents of any file
in the package and you forget to change the version number, then when
terminals are rebooted, they will skip over the loading of the files.

- The second parameter is the load size (200000 above). It is used by
the load process to ensure there is sufficient space in the terminal
for the files.

- The third and fourth parameters are not used

- The fifth parameter specifies what should happen to an existing package
on the terminal when a new version is to be downloaded. REPLACE means
the old one should be discarded before the new one is loaded. FAILSAFE
specifies that the old version be saved prior to downloading the new
one. The FAILSAFE option requires more space on the terminal's
writable drive but it allows recovery to the old version if the
download of the new version fails for any reason. We did not use the
FAILSAFE parameter in our testing.

d) The rest of the lines in the package file specify all of the files that
must be downloaded to the terminal. Each of these lines contains the
following parameters:

- The first is the path to the file on the FTP server relative to the
FTP home directory (not the root directory of the drive). When the
Telxon terminal logs in as an FTP client it cannot access above the
FTP home directory; so from the perspective of the FTP client (which
is the Telxon terminal), the home directory is the root directory.

- The second parameter is the path and file name on writable drive of the
terminal where the downloaded file should go.

- The third parameter specifies the type of file. FILE_SYSTEM means
this is file should be stored on the terminal using the path and name
in the second parameter. There are several other options for this
parameter that are covered in the AirBeam documentation but which
aren't relevant to this discussion.

- The last parameter specifies what should happen to this file when
the entire package is discarded or purged. ERASE_ON_DISCARD
indicates that the file should be erased when the package is
discard or purged.

e) There are a lot of fancy things you can do with package files which
aren't required for the use of the Client. These are all explained in
the AirBeam documentation

As was mentioned, the .BAT file that matches the file name is called after
files are downloaded or the terminal is rebooted. We just want it to start
the Client, but this will be done by simply calling em.bat. So this
file will contain one line:

call em.bat

This is the case for ptc960.bat, ptc860.bat and ptc870.bat. Even though the
contents are the same, we must have separate files - one to correspond
to the name of each package that is set up.

Throughout this document we've consistently used EM.BAT as the batch file
to be used to start the Client - whether from a batch file or from the
command prompt. That is why things are set up this way for Telxon
terminals. As a result, if you were to exit the Client after it was
started automatically from a reboot, you could start it again by simply
entering EM on the terminal's command line.

Once the package files and batch files are set up and all files to be
downloaded are in place, Telxon terminals that are fresh out-of-the-box,
loaded with the AirBeam flash can be loaded up by entering a several
parameters from the initial AirBeam prompts. The prompts are the same for
all terminals. There is a slight difference between prompts for terminals
with 900mhz radios and those with 2.4ghz radios. Later versions of AirBeam
flash may also have additional options.

To move from one prompt to the next, press the Enter key or the N key.

To change the value for any prompt you must first press the C key. Then
you will be prompted for the new value.

To save the changes (except when changing a parameter), press the S key.
After a confirmation message is responded to, the configuration will be
saved and the rest of the terminal boot up will continue.

To exit the prompts (except when changing a parameter), press the E key.
If changes have been made, you'll be asked if they should be saved. Like
the save option, the terminal boot up will continue when the prompts end.
Note: if you do not configure the terminal to 'Skip Config' at boot up,
then whenever the terminal is rebooted, the configuration prompts will be
the first thing that comes up. If that is the case, just press E to exit
the prompts and to continue the boot up process.

Here are the prompts from Version 1.23 of the AirBeam flash and suggestions
for proper inputs:

a) Serial Mac: We never changed this
b) Radio ID: This must be unique for each terminal. We use
the unique portion of the IP address for the
terminal.

c1) Channel: 900mhz radio only; must match 0-based index
of channel selection in access point

c1) Frequency: 2.4ghz radio only: must match 1-based index
of frequency selection in access point
c2) Bit Rate: 2.4ghz radio only; must match 1-based index
of bit rate selection in access point

d) System ID: Must match value from the access point
e) Boot Method: Use 0 for FTP
f) FTP User: User ID set up on FTP server for FTP clients
g) FTP Password: Password set up on FTP server for FTP clients
h) FTP Account: We never changed this
i) TFTP: We never changed this
j) Server IP: IP address of FTP server
k) PTC IP: IP address to use for this terminal; must be
unique for each terminal in the network
l) Router IP: IP address of router in the network
m) Package Dir: Name of directory under the FTP 'home'
directory that contains the package file on
the FTP server (in our example above,
we used telxon). Do not specify the full
path to this directory, just the directory
name itself:

telxon

n) Package: Name of the package file (.PKG) whose contents
should be loaded to the terminal. Do not
specify the .PKG extension. In our example,
the name to enter is: ptc960, ptc860 or ptc870.
o) Subnet Mask: Enter the appropriate mask for your network
p) Skip Config: Use 0 if you want these prompts to come up
every time the terminal is rebooted. Enter 1
if you do not. Once the terminal is put into
production, this value should probably be set
to 1. If you leave this at 0, whenever the
terminal is rebooted, the prompts will come up
and you will need to press E to exit the prompts
and continue the boot process.

If you have set the Skip Config option to 1
you can get back into the configuration using
the following command from the DOS prompt:

vutil mincfg -r%radio%

In fact you might want to create a batch
file called, CONFIG.BAT, that is part of the
package to be downloaded and which contains
the command above. If you start the
configuration program this way, then once you
have made the changes to the configuration and
saved them, the terminal will need to be
rebooted by pressing Cntrl, Alt, Del in order.

q) Suppress sep: We never changed this
r) Ignore Package: We never changed this

When all parameters are set as needed, press the S key to save and enter Y
for the confirmation. The file will be saved and the boot process will
continue. If everything is set up properly, the terminal will hook up with
the FTP server, download the package file and its associated files and
then will run the package batch file that should be set up to start the
Client automatically. And if the DCConnect Server is running, a download
from DCConnect should start automatically as well.

2) As was mentioned, method 1 is the preferred method. But if you are unable
to get an FTP server running, you can use the terminal's serial port to load
it. You'll still need to answer the AirBeam flash prompts in order to set
up the terminal's radio parameters and network parameters; the only
parameters you don't have to worry about are those that are specific to
the FTP server (Boot method, FTP User, FTP Password, FTP Account, TFTP and
server IP). However, each time the terminal is rebooted, it will make an
attempt to connect to the FTP server - because that is what the AirBeam
flash was designed to do. If you leave the FTP server field blank, you'll
get an error on reboot and you'll be left at a DOS prompt. To start the
Client, you'll have to run EM.BAT from the DOS prompt manually.

Note: On all but the 870IM, you could probably work around this and automate
the start up of the Client by doing some trickery like creating a
file called ETHDRV.BAT on the A: drive which does most of what
AUTOEXEC.BAT on drive B: does from the ETHDRV call and on - but
skipping the stuff that does the loading (vutil LOAD -v). Because A:
is before B: in the path, the batch file ETHDRV.BAT on drive A: would
be called instead of ETHDRV.EXE on drive B:. The batch file should
then have an explicit call to B:\ETHDRV.EXE using the same parameters
from the AUTOEXEC.BAT file. Furthermore because ETHDRV.BAT is a batch
file and it is not called with a 'call' command, when ETHDRV.BAT
completes, control will not return to AUTOEXEC.BAT.

The serial transfer process involves the use of the special terminal serial
cable attached to the PC's serial port and a pair of programs collectively
known as Handheld Bridge. Telxon also has a cradle that can be attached
serially to the PC. One program runs in the terminal (HHBR.EXE) and one
runs on the PC (HHB.EXE). These two programs are freeware programs that we
provide with the Client in the TELXON directory. HHBR.TXT and HHB.TXT can
also be found in this directory; these give more details about the use of
the Handheld Bridge programs.

The PC flavor (HHB.EXE) will run in a DOS windows of both OS/2 and
Windows/NT.

When both sides are talking, the HHB program on the PC shows, in a File
Manager type format, the contents of the terminal's drive and the contents
of the PC's drive. Using the space bar to select one or more files on
either side, files can be be sent from one side to the other or erased.
For example, if there are five files to be sent from the PC to the
terminal you would do the following steps:

a) Use the tab key to move the cursor to the PC's list of files.
b) Use the arrow keys to move up and down the list and use the space bar
to 'tag' those files that should be sent to the other side.
c) When all desired files are tagged. Press the S key for the Send
operation and all files will be transmitted.
d) It's as simple as that! Use X to exit the program.

Warning: the Copy function is not used to copy files from one side to the
other as might be expected. Copy is used to copy to a file of
a different name on the same side.

The Telxon terminal does not come with the HHBR utility already installed
on it. You must copy it to the terminal using the utility RXR.EXE which
is preinstalled on the terminal. The RXR utility is used for transferring
one file at a time. To transfer HHBR.EXE to the terminal using the RXR
utility, do the following at the terminal:

a) At the command line enter: rxr
b) At the Connect Optics? prompt, Enter: N
c) Enter 0, to receive a file
d) Enter 0, to select a baud rate of 38400
e) Enter the file name: HHBR.EXE
f) The terminal will now wait for the PC to begin transmitting the file

On the PC side, from a directory that contains both HHBR.EXE and HHB.EXE,
enter the following command:

hhb /n /s3

The /n is a special flag that tells Handheld Bridge to transfer HHBR.EXE
to the terminal. The /s3 parameter says to use 38400 for the baud rate.

When the transfer completes, do the following from the terminal side:

a) Enter 2 to leave the RXR program
b) You may need to reboot the terminal if you get an error about COMMAND.COM
c) Enter the following at the DOS prompt to start the terminal side of
Handheld Bridge: hhbr

Both sides should now be communicating with each other, providing an
easier way to transfer other files to the terminal than using RXR to
transfer them one by one.

Telxon CONFIG.SYS, AUTOEXEC.BAT and Network Configuration
---------------------------------------------------------
The Telxon terminal installed with the AirBeam flash includes AUTOEXEC.BAT and
CONFIG.SYS in that flash image. Since that flash is installed on read-only
drive B: these files cannot be changed. Nor do they need to be. The default
AUTOEXEC.BAT is set up to call the configured package file's .BAT file
(e.g. ptc960.bat). In the instructions above, we suggested that the package
.BAT file just call EM.BAT.

Therefore the only start up file that needs to be set up is EM.BAT. This will
be described in Setting Up a Telxon Terminal from Scratch.

As for the network configuration, the files associated with this are set up
automatically whenever configuration changes are made from the AirBeam prompts
that are shown on start up. Therefore these files do not need to be set up on
the PC nor do they need to be transmitted from the PC to the terminal.

Telxon Bar Code Configuration
-----------------------------
When using Telxon terminals, configuration of the bar codes is not done using
the information that might be downloaded from the DCConnect Server. Instead,
a special utility, TELXONBC.EXE, is provided with the Client so that all
capabilities of the Telxon scanning functions can be taken advantage of.
This utility reads a configuration file, TELXONBC.CFG, to determine which bar
codes should be active. Each bar code can also have certain parameters
configured for it. The TELXONBC.CFG file contains comments which explain
exactly how to make changes to it.

Both TELXONBC.CFG and TELXONBC.EXE are provided in the TELXON directory
where the Client is installed.

When running TELXONBC.EXE on the PTC960SL, PTC960X and PTC860IM terminals, no
parameters are needed. But for the PTC870IM, you must specify the parameter
PTC870 so that the proper function is called internally to do the configuration.

For all but the PTC870IM terminals, another program found in the same
directory, WANDTSR.EXE, must be downloaded to the terminal and must be run
before the scanner can be used. We have AirBeam version 1.30 installed on
our PTC870IM and it automatically starts the necessary Telxon drivers for
allowing the scanner to be used.

However, for the PTC870IM terminal only, in order for the Client to talk to
the scanner, a special TSR program, T870_TSR.EXE, must be started before the
Client and the keyword USE_TSR_FOR_SCANNER must be included in EMULATOR.INI.
This TSR program is included in the TELXON directory where the Client is
installed.

Another flavor of this scanning TSR, TELX_TSR.EXE, is also included with the
Client (versoin 1.40E and later) for use on the other Telxon models in order
to provide the ability for the Client to read scanner input directly and
therefore be able to distinguish it from keyboard input. Better enforcement
of scanning lengths is also provided.

In order for the Client to use the TSR, the appropriate one must be loaded
onto the terminal, the TSR must be started before the Client is started
and the following keyword must be part of EMULATOR.INI:

USE_TSR_FOR_SCANNER = Y

For more information see Keyword: USE_TSR_FOR_SCANNER.

IMPORTANT NOTE: None of the Telxon terminals supported by the Client allow
the configuration of preamble and postamble characters.
Therefore the SCAN_SENTINEL_CHARS keyword cannot be used in
EMULATOR.INI when using Telxon terminals.

So without the scanning TSR provided by the Client, all
scanning input is routed through the keyboard and as a result,
the Client would be unable to distinguish between keyboard
and scanner input.

Serial Port Use on the Telxon Terminal
--------------------------------------
As of version 1.40E of the Client, support for the serial port on Telxon
terminals is now possible. In order to use the serial port, the program
TELX_TSR.EXE/T870_TSR.EXE (provided with the Client) must be started before
the Client (whether using the serial flavor or TCP/IP flavor) and the
keyword USE_TSR_FOR_RS232 must be added to the EMULATOR.INI file. For more
information see Keyword: USE_TSR_FOR_RS232.

Prior to version 1.40E, the serial port was not supported on any Telxon
terminal.

Starting the Client on a Telxon Terminal
----------------------------------------
Since the Client must run from a writable drive, then the Client and
the file ETSCHECK.LIC should be copied to the terminal's drive writable along
with any configuration file(s). For more information about how to load files on
the terminal, see Transferring Files to a Telxon Terminal.

Depending on which model of Telxon terminal is being used, a different 'device'
command line parameter must be used:

For the PTC960SL and PTC960X terminals, the following parameter must be used:

-dPTC960

For the PTC860IM terminal, the following parameter must be used:

-dPTC860

For the PTC870IM terminal, the following parameter must be used:

-dPTC870

For more details about this and other command line parameters, see the earlier
section called Common Command Line Parameters for the Client.

Setting Up a Telxon Terminal from Scratch
-----------------------------------------
This section describes suggested steps to take an out-of-the-box Telxon
terminal and set it up so that the Client can run on it. These instructions
were developed using version 1.23 of the AirBeam flash.

While it is possible to transmit files to the terminal serially using the
Handheld Bridge utilities, this section will only cover the use of an FTP
server - which is the intended use of the AirBeam flash.

These instructions assume an out-of-the-box terminal with the AirBeam flash
on drive B: and the writable RAM drive A: being completely empty. For the
PTC870IM, the AirBeam flash is on drive C: and the writable drive is the
D: drive; so for this terminal substitute D: for A: in the steps below:

1) If you have not already done so, create a directory for accumulating
the files that are to be part of the download package(s). This directory
must be under the FTP 'home' directory. This example will assume the FTP
'home' directory is 'c:\ftp_home' and the directory under that for the
Telxon package files will be called 'telxon'. So all files will end up
in c:\ftp_home\telxon and its subdirectories. For more information
about setting up the FTP server on Windows/NT or OS/2, refer to
Hardware and Software Requirements for Telxon terminals.

2) Create the following subdirectories under c:\ftp_home\telxon so that files
can be properly organized by their use:

c:\ftp_home\telxon\common - Files used on both types of terminals
c:\ftp_home\telxon\860 - Files unique to PTC860IM terminals
c:\ftp_home\telxon\870 - Files unique to PTC870IM terminals
c:\ftp_home\telxon\960 - Files unique to PTC960SL and PTC960X terminals

All files except for the .PKG files will be copied to one of these
subdirectories. Most will be in c:\ftp_home\telxon\common.

3) We'll need to set up the package file that specifies all the files to be
downloaded. The steps that follow will help you determine which files
are to be included. For each that is included, two things will have to
be done:

1) Copy the file into the appropriate subdirectory of c:\ftp_home\telxon
2) Add an entry to the appropriate package file(s)

If you have not already done so, please review the section above about
using the AirBeam flash and setting up package files. This was covered in
Transferring Files to a Telxon terminal.

4) The first line of the package file(s) will indicate the version and the
size. The size does not have to be accurate, it is just a guideline.
Create as many of the following package files as you will need - based on
which terminal models you will be using:

ptc960.pkg
ptc860.pkg
ptc870.pkg

These files should be created in the c:\ftp_home\telxon directory.

The first line of the package file(s) should be:

config 1,200000,,,REPLACE

Then add entries for the package batch file and the Client startup
batch file - both of which are unique based on the terminal type.

In ptc960.pkg add:

file \telxon\960\ptc960.bat, \ptc960.bat, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\960\em.bat, \em.bat, FILE_SYSTEM, ERASE_ON_DISCARD

In ptc860.pkg add:

file \telxon\860\ptc860.bat, \ptc860.bat, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\860\em.bat, \em.bat, FILE_SYSTEM, ERASE_ON_DISCARD

In ptc870.pkg add:

file \telxon\870\ptc870.bat, \ptc870.bat, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\870\em.bat, \em.bat, FILE_SYSTEM, ERASE_ON_DISCARD

We'll set up the contents of these files in a few more steps.

5) Now copy the following files to the c:\ftp_home\telxon\common directory
on your PC from the directory where the Client is installed:

ETSCHECK.LIC
TCP_FTP\ETSPT.EXE

and add the following entries to all the package files that you are using:

file \telxon\common\etscheck.lic, \etscheck.lic, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\etspt.exe, \etspt.exe, FILE_SYSTEM, ERASE_ON_DISCARD

6) Now determine if you need to create an EMULATOR.INI file. For more about
what parameters can be set up in this file, refer to the section above
Configuration using EMULATOR.INI.

If you decide you need this file, create it in the c:\ftp_home\telxon\common
directory and add the following entry to all package files:

file \telxon\common\emulator.ini, \emulator.ini, FILE_SYSTEM, ERASE_ON_DISCARD

7) The last Client specific file to create is EM.BAT. This is one of the
terminal type specific files; one copy is created for each type in the
appropriate subdirectory.

If you are going to be using PTC960SL or PTC960X terminals you must create
an EM.BAT in c:\ftp_home\telxon\960.

If you are going to be using PTC860IM terminals you must create an EM.BAT
in c:\ftp_home\telxon\860.

If you are going to be using PTC870IM terminals you must create an EM.BAT
in c:\ftp_home\telxon\870.

For PTC960SL, PTC960X and PTC860 IM, the only difference between the batch
files will be the -d (device) parameter.

For all but the PTC870IM's batch file, start with the following command
for starting Telxon's wand TSR:

wandtsr

All flavors of EM.BAT should include the following command next in order
to configure the bar codes:

telxonbc

However, for the 870IM, add the parameter 'PTC870':

telxonbc PTC870

The command:

telx_tsr

should be added next for any of the following situations:

a) If the scanner will be used at all on the 870IM terminal
b) If enhanced scanning functions are needed for the other terminal
models (differentiation between keyboard and scanner input, better
enforcement of scanning lengths)
c) RS-232 serial port support for any terminal

For more information, see Keyword: USE_TSR_FOR_SCANNER
and Keyword: USE_TSR_FOR_RS232.

Finally add a line similar to the following for starting the Client:

etspt -dPTC960 -h1.2.3.4,7500

Change the -d (device) and -h (host PC) parameters as appropriate for the
terminal type and your network configuration.

For more details about command line parameters, see the earlier section
called Common Command Line Parameters for the Client.

After the call to the Client add a call to clear the screen:

cls

This is sometimes needed to restore the display to its original state
after you exit the Client.

8) Now that em.bat has been created, we have to create the package batch
file(s) which is automatically called after the package download and
after terminal reboots. The package batch files will contain the single
command:

call em.bat

If you have PTC960SL or PTC960X terminals, create
c:\ftp_home\telxon\960\ptc960.bat and add the line above to it.

If you have PTC860IM terminals, create
c:\ftp_home\telxon\860\ptc860.bat and add the same line above to it.

If you have PTC870IM terminals, create
c:\ftp_home\telxon\870\ptc870.bat and add the same line above to it.

9) In order for the scanner to work the following files should be copied
from the \TELXON directory where the Client is installed to the
c:\ftp_home\telxon\common directory:

TELXONBC.EXE
TELXONBC.CFG

and the following entries should be added to the package file:

file \telxon\common\telxonbc.exe, \telxonbc.exe, FILE_SYSTEM, ERASE_ON_DISCARD
file \telxon\common\telxonbc.cfg, \telxonbc.cfg, FILE_SYSTEM, ERASE_ON_DISCARD

Make changes to telxonbc.cfg as necessary. The file contains comments
which explain how to change the file. For more general information, refer
to Telxon Bar Code Configuration.

For all but the PTC870IM, the following file should be copied from the
TELXON directory where the Client is installed to the c:\ftp_home\telxon\common
directory:

wandtsr.exe

and the following entry should be added to the package file:

file \telxon\common\wandtsr.exe, \wandtsr.exe, FILE_SYSTEM, ERASE_ON_DISCARD

10) If the command 'telx_tsr' was added to EM.BAT in step 7 above, for any
reason, then the TSR must be copied and added to the package as well.

For the 870IM terminal, copy the following file from the
TELXON directory where the Client is installed to the
c:\ftp_home\telxon\870 directory:

t870_tsr.exe

and add the following entry to the package file:

file \telxon\870\t870_tsr.exe, \telx_tsr.exe, FILE_SYSTEM, ERASE_ON_DISCARD

For all other terminal models, copy the following file from the
TELXON directory where the Client is installed to the
c:\ftp_home\telxon\common directory:

telx_tsr.exe

and add the following entry to the package file:

file \telxon\common\telx_tsr.exe, \telx_tsr.exe, FILE_SYSTEM, ERASE_ON_DISCARD

11) All files that are required are now set up ready for transfer to the
terminals - as long as the FTP server and access point(s) are configured
and running. You should be able to turn on your terminals, respond to
the prompts and have them be downloaded with all of the files that were
set up above.

For a description of the AirBeam prompts and suggested values, refer to
Transferring Files to a Telxon Terminal.

The only prompts that have unique responses for each terminal are the
Radio ID and PTC IP address. All of the rest of the prompts are the same
for all terminals - with one exception. The Package name for PTC960SL
and PTC960X terminals will be:

ptc960

The Package name for PTC860IM terminals will be:

ptc860

The Package name for PTC870IM terminals will be:

ptc870

When all parameters are entered, and the configuration is saved, the
boot process will complete and the entire package should be transferred
to the terminal and the Client should be started automatically. The
download process should take 10 to 20 seconds for the approximately 200K
of files. As files are being transferred you will see the terminal show
one dot for each file specified in the package file.

Using the DCConnect Client on Windows 95/98/Me/NT/2000/XP/7/Server
------------------------------------------------------------------
This section describes what additional configuration must be done when using
the DCConnect Client on Windows 95, 98, Millenium, NT, 2000, XP, Windows 7 or Window Server xxx.

For more detailed information please refer to the following sections:

- Hardware and Software Requirements for Windows 95/98/Me/NT/2000/XP/7/Server
- Bar Code Configuration for Windows 95/98/Me/NT/2000/XP/7/Server
- Serial Port Use for Windows 95/98/Me/NT/2000/XP/7/Server
- Starting the Client on Windows 95/98/Me/NT/2000/XP/7/Server
- Building CFRs for Windows 95/98/Me/NT/2000/XP/7/Server based Terminals
- Setting Up the Client on Windows 95/98/Me/NT/2000/XP/7/Server from Scratch

Hardware and Software Requirements for Windows 95/98/Me/NT/2000/XP/7/Server
---------------------------------------------------------------------------
The only hardware requirement is a correctly configurated NetWork adapter that
will support the TCP/IP protocol, (Ethernet, Token-Ring, ...) There are no
special software requirements other than one of the supported versions
of the Microsoft Windows operating systems: Windows 95/98/Me/NT/2000/XP/7/Server.

Note: The DCConnect Client for Windows will not run on Windows 3.1 because that
is a 16-bit operating system.

The generic 32-bit Windows flavor of the DCConnect Client does not run
on Windows CE. There are Windows CE specific flavors of the Client
for those Windows CE platforms that we support. For example, we have
specific flavors of the Client for use on the Intermec 600 terminal,
for the Intermec 5020 terminal, for the Intelligent Instrumentation
LanPoint CE and the Symbol PDT81xx.

Bar Code Configuration for Windows 95/98/Me/NT/2000/XP/7/Server
---------------------------------------------------------------
There is no special Bar Code device support built into the 32-bit Windows
flavor of the DCConnect Client. If you have a bar code 'wedge' device that
you can attach the keyboard port of the Windows PC, then bar codes could be
scanned and they would be fed to the DCConnect Client as a series of
keystrokes.

If a wedge device is used and it has the ability to configure preamble/postamble
characters to be appended around every bar code that is read, then the Client
would be able to distinguish keyboard input from scanner input by properly
defining the SCAN_SENTINEL_CHARS keyword in EMULATOR.INI.

For more information about the SCAN_SENTINEL_CHARS keyword and its benefits,
please see, Keyword: SCAN_SENTINEL_CHARS.

You also have the option to use a serial scanner as long as the serial
scanner is a decoded scanner and it can be configured to set up a terminating
(postamble) character. In order to use a serial scanner, you must use
the USE_RS232_FOR_SCANNER keyword in EMULATOR.INI. For more information
please see, Keyword: USE_RS232_FOR_SCANNER.

Serial Port Use for Windows 95/98/Me/NT/2000/XP/7/Server
--------------------------------------------------------
The COM1 serial port on Windows terminals/PCs can be used by the Client to
communicate with devices such as a serial printer or scale.

There is currently no officially available serial flavor of the Client
that can be used to communicate to the data collection server via the
serial port instead of over a TCP/IP socket.

The Client will configure the serial port based on the downloaded serial port
configuration (when the serial port is used to talk to another device such as a
printer or scale).

Starting the Client on Windows 95/98/Me/NT/2000/XP/7/Server
-----------------------------------------------------------
The Client executables (ETSPT.EXE and ETSPT.DLL in the WIN32 directory where
the Client is installed) and the file ETSCHECK.LIC should be copied into a
subdirectory along with any configuration file(s). All the Client, license,
and configuration files must be in the same directory when the Client is
started.

There isn't any required 'device' command line parameter that must be used when
starting the Windows flavor of the DCConnect Client. The Client will default
to a 25 row by 40 column window.

However, device switches for other terminal types may be used. This would
cause the window to be sized based on the default size of the specified
terminal type. In addition, the keywords NUM_ROWS and NUM_COLS can be used
in EMULATOR.INI to override the default dimensions of the window. Using
device switches for other terminals on the Windows flavor of the Client is an
excellent way of testing your screen displays for other terminals types during
transaction program and CFR development. You can do your development work and
demos without actually having the actually having the terminal for which are
developing programs.

Note: In order for the 32-bit Windows flavor of the Client to use a CFR, that
CFR must be compiled as a Windows DLL - which of course is different from
a DOS executable that many supported devices require.

More than one copy of the Client may be started on the same system unit as long
as each uses a different port number (-p command line parameter or TCPIP_PORT
keyword in EMULATOR.INI).

Note: If you will be running multiple instances of the DCConnect Client on the
same PC from the same directory, then you must use the -p command line
parameter to specify each instance's port number instead of use the
TCPIP_PORT keyword in EMULATOR.INI. Each instance has its own logfiles
and downloaded CFR file. When running from the same directory, these
files must have unique file names. If the -p parameter is used, the
Client generates logfile names and CFR names based on the port number -
thus allowing multiple instances to coexist without overwriting each
other's files. If TCPIP_PORT is used instead of -p, the Client does
not make the file names unique because the Client does not process
EMULATOR.INI until after it has established the logfile names it will
use.

The Windows flavor of the DCConnect Client can also run on the same PC as the
Windows/NT flavor of the DCConnect Server. Just be sure that the port number
that the Server uses is different from the Client. Since the DCConnect Server
defaults to using port 7500, you would typically use port 7501 for the Client.
If more than one instance of the Client is to run on that PC, each should have
a different port number (7502, 7503, ...) Be sure the port number is specified
when configuring these 'terminals' in DCConnect. You can also use the loopback
IP address (127.0.0.1) for Clients that run on the PC as the Server - but
you still have to use different port numbers.

For more details about command line parameters, see the earlier section called
Common Command Line Parameters for the Client.

Building CFRs for Windows 95/98/Me/NT/2000/XP/7/Server based Terminals
----------------------------------------------------------------------
For DOS-based terminals running the DCConnect Client and the original IBM 752x
terminals, CFRs were built as 16-bit .EXE files. However, when the Client is
running on Windows 95/98/Me/NT/2000/XP/7/Server, CFRs must be built as Windows
DLLs. In addition, if the building of your CFR requires linking any libraries
that weren't part of the C compiler, these libraries must also be rebuilt as
Windows libraries.

Note: Even Windows CE CFR DLLs and libraries that were built for the Client
running on Windows CE devices cannot be used on Windows 95/98/Me/NT/2000/XP/7/Server.

The CFR source files (.C and .H files) that were used when building DOS CFR
exectuables should not have to change when you want to create CFR DLLs for
Windows from that same source.

Because DOS-based devices, Windows devices and Windows CE devices all use
different CFR executables, when configuring terminals using the DCConnect
User Interface, you will have to separate terminals into different function
groups when they use different CFR executables - even if all of the rest of
the configuration (transaction programs, validation files, ...) are the same
(except of course the terminal address).

During our testing we built our test CFRs using the Microsoft Visual Studio
Visual C++ 6.0 compiler. We have included in the Client product files, both
the project and workspace files that we used in order to help you get
started building your own Windows CFR DLLs.

To compile a CFR using the project and workspace files provided, follow the
steps below:

1) The installation of version 2.00 and later of the DCConnect Client
should copy all of the CFR related product files to your PC and then
set up the environment variable CFRTOOLS to point to the CFRTOOLS
directory located where the files were installed
(e.g. C:\DCCONN\DCCLIENT\CFRTOOLS).

If this has already been set up then you can skip to step 5 below.
Otherwise continue with step 2 in order to copy the necessary
files and to set up the CFRTOOLS environment variable.

2) First create a directory into which the CFR files can be copied. If
you are using the PC that is running the DCConnect Server, then create
the directory:

DCCLIENT\CFRTOOLS

under the directory where DCConnect is installed (e.g. C:\DCCONN).

3) Copy all files from the CFRTOOLS directory where the Client is
installed to the directory you created (e.g. C:\DCCONN\DCCLIENT\CFRTOOLS).

4) Using the System icon in the Windows Control Panel folder, set up
the environment variable CFRTOOLS to point to the directory that
you created (e.g. C:\DCCONN\DCCLIENT\CFRTOOLS).

5) Of all the files that are installed to the %CFRTOOLS% directory, the
following files are required for building 32-bit Windows CFRs:

cfrapi24.h - CFR API include file.
cfrwin32.h - CFR include file needed for 32-bit Windows and Windows CE CFRs
win32\cfrapi32.lib - Win32 CFR API Library.

6) Before proceding, it is suggested that you create a separate build
directory for your own CFR source. This should be different from the
directory that the environment variable CFRTOOLS points to. This
example will use C:\MYCFRS for the build directory.

7) One of the files in the %CFRTOOLS% directory is CFRSMP24.ZIP which
is the sample CFR package. This package includes Microsoft Visual
Studio workspace and project files - as well as the source and makefiles
for the sample CFRs.

Copy CFRSMP24.ZIP from the %CFRTOOLS% directory to C:\MYCFRS.

8) Then unzip CFRSMP24.ZIP, being sure to specify that subdirectories from the
.ZIP file be created (if using pkunzip, specify the -d option). The
unzipped files will include the following files that are relevant for
building the 32-bit Windows flavor of the sample CFR:

cfrsmp24.c - True source for the CFR
cfrsmp32.c - Wrapper file for CFRSMP24.C that allows us to create
CFRSMP32.OBJ when using Microsoft Visual Studio.
cfrsmp32.mak - Makefile that can be used to build the CFR from the
command line (nmake -f cfrsmp32.mak) - after setting
the environment for compiling (vcvars32.bat).
nmwin32.bat - Batch file for setting compile environment and then
calling nmake of cfrsmp32.mak with the proper options.
cfrsmp32.dsw - Microsoft Visual Studio workspace file for this CFR
cfrsmp32.dsp - Microsoft Visual Studio project file for this CFR

9) The sample CFR also uses some of the utility routines found in the package
CFRUTL24.ZIP. (The contents of this package are already expanded in the
%CFRTOOLS% directory). The files associated with this library of utility
functions that are used when building 32-bit Windows CFRs are:

cfrutl24.h - Header file for utility functions
win32\cfrutl32.lib - Library of utility functions

10) Copy your CFR source (and any include files) into the build directory. The
project setttings are configured to expect the CFR source file to be
named "CFRSMP32.C" and the output CFR executable will be called CFRSMP32.DLL
and it will be generated in the WIN32 directory under the current
directory (e.g. C:\MYCFRS\WIN32).

11) Start the Microsoft Visual C++ Visual Studio tool.

12) Under the 'File' pull down menu, click on "Open Workspace".

13) Open your build directory (e.g. C:\MYCFRS) and click on "CFRSMP32.DSW".
This will load the sample CFR project configuration.

14) Under the 'Build' pull down menu, click on 'Set Active Configuration...'
and select the 'Release' configuration (not the 'Debug').

15) Again underr the 'Build' pull down menu, click on the "Build cfrsmp32.dll"
item. This will start the CFR DLL compile.

In most cases your 16-bit CFR source can be recompiled into a DLL without any
changes. You may get a number of warning messages during the build that should
not cause any problems during run time. The messages may be caused by mismatch
sizes of primitive types between the 16-bit and 32-bit systems. As an example,
'int' on 16-bit systems is two bytes in size while it is four bytes on 32-bit
systems. But you should inspect the cause of each message to make sure
nothing needs to be changed. If there is anything that needs to be changed be
sure to change in it such a way that it will still compile properly when
building the 16-bit DOS flavor of the CFR.

If you will be building more than one CFR, you should set up a separate project
for each under the same workspace. The following steps gives an example of how
to create a second CFR (called WIN32\TEST.DLL) that is identical to the
WIN32\CFRSMP32.DLL:

1) Copy CFRSMP32.DSP to TEST.DSP. Edit the file using Notepad - or any editor
that handles line lengths greater than 256 bytes.

- Change all uppercase occurrences of 'CFRSMP32' to 'TEST'
- Change all lowercase occurrences of 'cfrsmp32' to 'test'

Then save the file.
2) Copy CFRSMP24.C to TEST.C (the project file referenced CFRSMP32.C but that
was changed to TEST.C as a result of the actions in the previous step).
3) Start Visual Studio and select the CFRSMP32 workspace.
4) Then add the project in TEST.DSP to the workspace.
5) Be sure the build type is Release (and not Debug). You should be able to
run the build and create WIN32\TEST.DLL.

You can have the build copy the resulting DLL to the \DCCONN\CFR directory
so that any time the CFR is updated it is immediately available for download
by the DCConnect Server. This can be done by going into the project settings
(be sure to select the 'Release' configuration) and going to the 'Post-Build
step' tab and add a command similar to the following:

copy win32\test.dll c:\dcconn\cfr

Once you have set up your project in the Microsoft Visual Studio development
environment and have successfully compiled a CFR, you can create a make file
so that in the future you can compile CFR changes from the command line. The
sample CFR package includes the following files for this purpose:

cfrsmp32.mak
nmwin32.bat

The first file, cfrsmp32.mak, is actually generated by Visual Studio using
the 'Export Makefile...' from the Project pull-down menu. This option lets
you create a .MAK file for all projects that are part of the current
workspace. Once you have the .MAK file, you can use a batch file similar
to nmsmp32.bat to start the compile from the command line. NMWIN32.BAT
does the following:

@echo off
if "%1" == "" goto needparm
goto ok

:needparm
echo .
echo . Please specify the name of a project (*.mak) to compile. For
echo . example:
echo .
echo . %0 cfrsmp32
echo . %0 cfrpan32
echo . %0 cfrutl32
echo .
goto end

:ok
setlocal
set whichMake=%1
call %MSVC32DIR%\bin\vcvars32
nmake /f %whichMake%.mak "CFG=%whichMake% - Win32 Release" > outwin32
if '%2'=='' call notepad outwin32
endlocal
:end

A few notes about the above:

- The 'setlocal' and 'endlocal' commands are used for temporarily
changing the session environment for the compile steps.
- The batch file 'vcvars32.bat' sets up the PATH and other
environment variables so that the compile environment is set
as needed for the Microsoft Visual C++ compiler. The call
to vcvars32 above is referenced using the environment variable
MSVC32DIR. You can change this to the specific path where
the Microsoft Visual C++ compiler is installed on your
system (e.g. C:\Visual Studio\VC98). Or you can set up this
environment variable using the System icon in the Windows
Control Panel folder.
- The nmake statement redirects the messages from the compiler
to the file 'outwin32' so that you can examine this file after
the compile. The statement after nmake will call notepad to
allow you to view any messages written to outwin32.

Setting Up the Client on Windows 95/98/Me/NT/2000/XP/7/Server from Scratch
--------------------------------------------------------------------------
The setup for the Windows flavor of the DCConnect Client product involves only
a couple of steps. The only requirement while setting up a Windows based Client
terminal is that all the Client files must reside in the same directory.

Create a 'run' directory on any of the Windows PC's drives. Copy the following
files from the directory where the Client is installed to the 'run' directory:

WIN32\ETSPT.EXE
WIN32\ETSPT.DLL
ETSCHECK.LIC

At this point, you could start the Windows Client by just switching into the
run directory and typing "etspt" from the command line. There is no required
command line 'device' switch when running the Windows flavor of the Client.

However, if the Windows Client is running on the same PC as the DCConnect
Server, you will need to specify a TCP/IP port number that is different
from the TCP/IP port number that is being used by the DCConnect Server. For
more information about running the Client on the same PC as the DCConnect
Server and about running multiple copies on the same PC, please see
Starting the Client on a Windows Terminal.

The default behavior of the Windows Client can be changed by including an
emulator.ini file in the run directory. By adding keywords in this file,
you can change many of the Client default characteristics such as the screen
size, the position of the status row, and transaction log file size. The
following keywords are not supported under the TCP/IP Windows flavor of
the Client product:

ADDRESS
BAUD_RATE
COM_PORT
MENU_ITEM
SELECT_FONT
TOGGLE_BACKLIGHT_CHAR
USE_TSR_FOR_RS232
USE_TSR_FOR_SCANNER
USE_TSR_FOR_KEYBOARD

Keywords you might consider adding to EMULATOR.INI:

TCPIP_HOST - To specify the IP address of the DCConnect Server.
If the Win32 DCConnect Client is running on the
same machine as the DCConnect Server, you can use
the loopback IP address 127.0.0.1 for the Server
IP address.

TCPIP_PORT - To specify the port number that DCConnect Client
will use. If running on the same machine as the
DCConnect Server, you must use a different port
number from the Server (which defaults to 7500).

NUM_ROWS and
NUM_COLS - To set the default screen size to something
other than 20x40 - perhaps to simulate the
screen of a device that the transaction programs
will eventually run on.

PF_MAPPING - To have the number keys act like PF keys when
starting a transaction program or executing an
ONKEY/ONSUB command.

USE_RS232_FOR_SCANNER - If you have a decoded scanner attached to the
serial port.

A sample EMULATOR.INI for use with the 32-bit Windows flavor of the
Client can be found where the product is installed as WIN32\SAMPLE\EMULATOR.INI

For more information about keywords that can be used in EMULATOR.INI, see
Configuration using EMULATOR.INI.

Using the DCConnect Client on Windows CE Devices
------------------------------------------------
This section describes what additional configuration must be done when using
DCConnect Client on Windows CE based devices.

While this and the following sections will try to cover the similarities
between Windows CE Devices there are many ways in which Windows CE devices
are different. In fact, the DCConnect Client product has to include several
differently compiled 'flavors' of the DCConnect Client in order for each
to work on its intended Windows CE terminal.

Two key areas where terminals differ are with the processor they use and
the version of Windows CE that they support. Of the Windows CE devices
that we supported initially, the processor and Windows CE versions differ
considerably:

- Intelligent Instrumentation LanPoint CE - Windows CE 3.0, X86 processor (AMD)
- Intermec 600 - Windows CE 2.12, X86 processor (AMD)
- Intermec 700 - Windows CE 3.0, Strong ARM 1110 processor (Intel)
- Intermec 5020 - Windows CE 3.0, SH3 processor (Hitachi)
- Intermec 6651 - Windows CE 3.0, MIPS processor (Toshiba)
- Intermec CK30 - Windows CE .NET, XScale processor (Intel)
- Intermec_CV60 - Windows XP Embed, Intel P-III 800Mhz processor
- Symbol MC9000 - Windows CE .NET, ARM processor (Intel)

Note: Intermec 5020 terminals originally came with Windows CE 2.12 on them. However
since any Intermec 5020 can be upgraded to Windows CE 3.0, starting with
version 2.0 of the DCConnect Client, Intermec 5020 terminals with versions
of Windows CE earlier than 3.0 are not supported.

Because each of these 8 devices has a different processor / Windows CE version
combination, 8 different sets of DCConnect Client executables have to be built.

For other Windows CE devices that match any of the processor / Windows CE
version combinations above, the corresponding executables should run on
that device. For example, the:

- Symbol PDT 81xx (e.g. 8146) - Windows CE 3.0, Strong ARM 1110 processor (Intel)
- Handheld Products "Dolphin" 7400 - Windows CE 3.0, String ARM 1110 processor (Intel)

both have the same processor / Windows CE version combination as the Intermec 700
terminal. Therefore, the executables built for the Intermec 700 terminal
should run on the Symbol PDT 81xx and HHP 7400.

Note: The PDT81xx and HHP7400 each use different directory names for the
non-volatile storage on the device. Therefore you would still have
to create different .CAB files for loading the Client to the device
even though the executables are the same.

In some cases you also have to worry about whether the device is a Pocket PC
device or not. The Intermec 700 and Symbol PDT 81xx are Pocket PC devices with
the same processor (StrongARM) and Windows CE version (3.0). The exectuables
built for this processor/Windows CE version combination also makes use of a
Pocket PC library in order to implement the FULL_SCREEN option in EMULATOR.INI.
The required library (AYGSHELL.DLL) is not available on non-Pocket PC devices.

So for devices that have a StrongARM or compatible (e.g. XScale) processor and
Windows CE 3.0 or compatible later version (e.g. 4.0) but which are not Pocket
PC devices, the executables for the Intermec 700 will not work. Instead the Client
software includes executables for this processor/Windows CE version combination
which do not require the Pocket PC .DLL (and therefore do not support the
FULL_SCREEN option). These executables are available in the .\ARMNOPPC directory.
Two devices that need to use these executables are:

- Group Mobile MA1000 - Windows CE 3.0, StrongARM processor (Intel)
- Symbol PPT 88xx - Windows CE .NET, XScale processor (Intel)

There is also a Desktop Pocket PC Emulation environment that runs on the same
machine as the Microsoft eMbedded Visual Toolkit. When you start this, you get
a window on your Windows PC that looks like a Palm Device. We provide a
flavor of the DCConnect Client that runs in this Pocket PC emulation
environment. This instance of the DCConnect Client can be treated like a
terminal in the DCConnect Server - in much the same way that you can run the
Windows NT/2000 flavor of the DCConnect Client on the same PC as the DCConnect
Server.

The need for different executables for different Windows CE devices also
applies when building CFRs to run in Windows CE devices. See the section
about building CFRs listed below for more information.

For more detailed information about using the DCConnect Client on Windows CE
devices please refer to the following sections:

- Hardware and Software Requirements for Windows CE Devices
- Using Microsoft ActiveSync with Windows CE Devices
- Bar Code Configuration for Windows CE Devices
- Using Hostnames Instead of IP Addresses for Windows CE Devices
- IBM CE Configuration Tool
- Setting Registry Keys with the IBM CE Config Tool
- Creating Files with the IBM CE Config Tool
- Duplicate Answers in the IBM CE Config Tool
- File, Directory and Other Commands in the IBM CE Config Tool
- Preserving and Reusing the Answers in the IBM CE Config Tool
- How to Explore Registry Keys on a CE Device
- IBM Get Registry Tool
- Changing the Font Used By the Client on a Windows CE Device
- Serial Port Use on the Windows CE Devices
- Building a .CAB File to Install the Client on a Windows CE Device
- Reinstalling the DCConnect Client on a Windows CE Device
- Uninstalling the DCConnect Client on a Windows CE Device
- Starting the Client on a Windows CE Device
- Building CFRs for Windows CE Devices
- Building More Than One 'Flavor' of a Windows CE CFR
- Building Windows CE CFRs from the Command Line
- Adding Another Configuration to a Windows CE CFR Project
- Setting Up a Windows CE Device from Scratch

The sections above generally apply to all Windows CE devices. However, there
are some terminal-specific issues that are discussed in the sections listed below:

- Terminal-Specific Issues for the Intermec 600 Terminal
- Terminal-Specific Issues for the Intermec 700 Terminal
- Terminal-Specific Issues for the Intermec 5020 Terminal
- Terminal-Specific Issues for the Intelligent Instrumentation LanPoint CE Terminal
- Terminal-Specific Issues for the Symbol PDT 81xx Terminal
- Terminal-Specific Issues for Non-Pocket PC, StrongARM Compatible Devices
- Terminal-Specific Issues for the Intermec CK30 Terminal
- Terminal-Specific Issues for the Intermec CV60 Terminal
- Terminal-Specific Issues for the Symbol MC 90xx Terminal
- Terminal-Specific Issues for the Motorola (Symbol) MC 91xx Terminal

Hardware and Software Requirements for Windows CE Devices
---------------------------------------------------------
The DCConnect Client only needs about 1MB of diskspace and 1 or 2 MB of RAM
in order to run. Only if the Windows CE device will be running other
applications at the same time as the DCConnect Client should you need
extra memory or diskspace.

Consult the device manufacturer to find out how much free diskspace and
free RAM memory is available.

While not required, it is strongly recommended that the Windows CE
device be installed with non-volatile storage and that that storage
be the place where the DCConnect Client runs. With non-volatile
storage in place, all transactions generated by the Client are
safely stored so that they would survive a cold-boot or total
loss of battery power. Non-volatile storage is also generally used
to store the DCConnect Client .CAB file. In the event of a
cold-start or total loss of battery, the .CAB file would still
be on the terminal - thus allowing the Client to be reinstalled
without having to use a serial cable or other method to reload
the .CAB file.

All sample flies and instructions in this document assume the
existence of non-volatile storage on the Windows CE device.

Loading the Windows CE device will often require either a serial,
infrared, or network connection. Therefore the appropriate hardware (e.g.
dock, null-modem cable, ethernet cable, ...) will be required in order to
load the DCConnect Client on to the device. In addition, certain software
such as a web browser and/or Microsoft ActiveSync will probably be required
to load the device.

Consult the device manufaturer's documentation for instructions about what
hardware and software is needed to load the device.

If you need to download a CFR to the device, you will need to build
the CFR specifically for the device. In order to build CFRs for
any Windows CE device, you must install the Microsoft eMbedded Visual Toolkit
on your PC. As of September 2003, the 2002 version of the toolkit could be downloaded,
free of charge, from the Microsoft website:

eMbedded Visual Tools 3.0 - 2002 Edition

you can also order a CD for a nominal charge.

Some devices (e.g Intermec CK3x) require the Microsoft eMbedded Visual C++ 4.0 compiler. The following links were valid
as of September 2008 for getting this compiler and its fix pack:

Microsoft eMbedded Visual C++ 4.0 compiler

Microsoft eMbedded Visual C++ 4.0 SP4

The MS eMbedded Visual Toolkit also includes Software Development Kits (SDKs)
for MS Pocket PC devices, Handheld/PC devices and "Palm-size PC" devices.
However, certain devices (e.g. Intermec 5020, Intermec 600, LanPoint CE)
also have their own SDK that must be installed after the MS eMbedded Visual
Toolkit is installed. These SDKs should be available from the device
manufacturer - and are often included on CDs that come with device
'starter kits'.

The SDKs that are part of the Microsoft eMbedded Visual Toolkit also
include the tool used for building .CAB files (CABWIZ.EXE) - which is the
standard way of packing files for download to a Windows CE device.
Installation of a .CAB file not only installs files to the appropriate
location on the Windows CE device but it can also register .DLLs
with the operating system, set values in the registry and set up
shortcuts on the Start Menu and other folders.

So more than likely you will need to build the .CAB file and thus will
require need to download and install the Microsoft eMbedded Visual
Toolkit. Unfortunately, there does not appear to be any other way to
obtain the CABWIZ.EXE and associated files. For more information, please see
Building a .CAB File to Install the Client on a Windows CE Device.

The Microsoft eMbedded Visual Toolkit is also necessary if you
will be using the IBM CE Config Tool to configure your terminals.

So here is a summary of situations that require the installation
of the Microsoft eMbedded Visual Toolkit:

- If building a custom ETSUSER.DLL
- If using the IBM CE Config Tool
- If using the Cab Wizard to create a .CAB file
- If building a CFR for use on the Windows CE device
- If viewing or changing the registry on the Windows CE device

If there are any other utilities that are required, for example,
to route bar code input to the keyboard, these should be provided
by the device manufacturer and would probably already be included
in the default load of the device.

Windows CE devices include all the radio / network / TCP/IP drivers.
So unlike many DOS terminals, there is no need to install any
additional drivers.

Using Microsoft ActiveSync with Windows CE Devices
--------------------------------------------------
Microsoft's ActiveSync software is used to accomplish the
following things in conjunction with the use of the DCConnect
Client:

- Transfer the the .CAB file and supporting files to the
Windows CE device. There are sometimes other methods for
transferring files to the terminal (e.g. removable compact
flash card), but ActiveSync is often the easiest.
- If using the IBM CE Config Tool to update the Windows CE
registry, then the Remote Registry Editor, which is part of
the Microsoft eMbedded Visual Toolkit, is needed to explore
the registry to figure out all the keys and this tool works
best with an ActiveSync connection.
- If debugging a CFR or ETSUSER.DLL using the MS eMbedded
Visual C++.

ActiveSync can make a connection to the Windows CE device
a number of different ways:

- Serial port
- Infrared port
- USB Port
- Ethernet / RF connection

On some devices, such as the Intermec 700 and Symbol 81xx,
in order to establish an ActiveSync connection over
Ethernet / RF, the device must establish an ActiveSync
connection via the serial port or infrared before the
Ethernet / RF ActiveSync connection can be made.

During our testing, we used version 3.5 of ActiveSync.
As of June 2002, this version was available from
Microsoft's website:

http://www.microsoft.com

At the end of the installation of ActiveSync, ActiveSync
will want you to attach your Windows CE device so that
an initial connection can be made. This initial connection
is usually made via the serial port. For some devices,
you do not have to do anything special on the device, just
attach the cable and/or the dock and ActiveSync makes
the connection automatically. For other devices you
have to start a program on the device. Consult the
documentation for the device to find out what must be
done.

Note: In our experience with ActiveSync we have found very
inconsistent behavior regarding the ability to establish
the ActiveSync connection, particularly over ethernet
or RF. We've had to do things in a very precise order
to increase the chances of a successful connection.

When ActiveSync detects the device, it will ask whether
a partnership should be created. Respond 'yes' if you ever
want to use an ActiveSync connection over the ethernet
or RF. When establishing the partnership, you'll be
presented a window with a lot of check boxes associated
with different kinds of information that can be
synchronized. None of the checkboxes need to be
checked for the uses of ActiveSync that are associated
with the DCConnect Client. In fact you might have
trouble finalizing an ActiveSync connection if, for
example, the check box for Inbox, Tasks or Notes is
checked and you don't have Microsoft Outlook installed.

Once the partnership is established ActiveSync will
complete the connection and should end up showing that
the device is connected and synchronized. You can now
use ActiveSync to do the following things:

- Use the 'Explore' button to view the files on the
Windows CE device. Used in conjunction with Windows
Explorer on the host PC (running ActiveSync) you can
transfer files to and from the devices. For some
file types a conversion is done - and this conversion
is governed by settings that can be viewed/changed
via the Options button. For example, .mdb database
files are converted to .cdb Pocket Access Database
files.

Note: Before transferring .CAB files to a Windows CE
device, uses Windows Explorer to make sure the
read-only attribute for the file is set. If
not, the .CAB file is deleted from the device
after it is installed. The ActiveSync Explore
program does not allow you to change attributes
for files directly on the Windows CE device; nor
can it be done from the terminal itself.

If you are using the MAKECAB.BAT file provided
with the DCConnect Client to make your .CAB
files, then that .BAT file will make sure the
read-only attribute is set for any .CAB file
that is created successfully.

- Use the Remote Registry Editor from either Microsoft
eMbedded Visual Basic or Microsoft eMbedded Visual C++
to explore the registry on the Windows CE device.

It is best to use an ActiveSync connection over
ethernet or RF if you will be searching or exporting
the registry.

In order for the Remote Registry Editor to view the
registry of the device, you must first use the
'Configure Windows CE Platform Manager...' option on
the 'Connection' pull-down menu to specify how to
connect to the device. The Platform Manager provides
a 'Default Device' for each Platform. We've just
used the default device for the Pocket PC when
using ActiveSync with the Intermec 700 and the
Symbol 81xx. If you highlight the correct device and
then select the Properties button you will have a
choice of 'Transport Components'. You should be
able to use Microsoft ActiveSync. However, we
have had trouble using this option. We've been
successful using 'TCP/IP Transport for Windows CE'.
After highlighting this option, press the 'Configure'
button and make sure 'Fixed Port' is checked. The
default port number of 5000 worked for us. After
you click OK to accept these values, click the
'Advanced' tab and make sure 'Microsoft ActiveSync'
is selected. Click OK and then click Test to make
sure the transport programs on the device and the
PC can talk to each other.

If this still does not work, try using the 'Configure'
button again and uncheck the 'Fixed Port' checkbox.
Click OK and try the Test button again.

The Remote Registry Editor provides an 'Add Connection'
option from the 'Connection' pull-down menu then select
the device that you just configured and press OK. This
should start the connection and allow you to access
the device's registry.

- Use the the MS eMBedded Visual C++ debugger to debug
a CFR or ETSUSER.DLL. Just like the Remote Registry
Editor, the compiler provides the 'Configure Windows
CE Platform Manager..' option - this time on the
Tools pull-down menu. Set up your device as described
above for the Remote Registry Editor.

As was mentioned, using an ActiveSync connection over
ethernet or RF is much faster than serial or infrared.
However, to establish that connection requires a few
more steps. Here are some notes about ActiveSync
connections over ethernet or RF:

- On the device you must configure both the WINS and
DNS servers. If you don't actually have a WINS and/or
DNS server, then use the IP address of the PC that is
running ActiveSync.

- You must first have created a partnership over a serial
or infrared connection between the device and the PC
before ActiveSync can connect over ethernet or RF. Then
the serial or infrared connection must be disconnected
before you can establish the ethernet/RF connection. For
a serial connection either disconnect the serial cable or
remove the terminal from the dock. For an infrared
connection, move the terminal out of range of the infrared
port on the PC.

- Once you have established the partnership and then
disconnected, use the 'Connection Settings' option on
the File pull-down menu of ActiveSync to select which
ways ActiveSync is allowed to connect. The 'Allow
network (Ethernet)...' option must be checked. But
in some cases we found we also had to uncheck the
'Allow serial...' and 'Allow USB..' options in order
for it to work.

- After you press OK on the Connection Settings window
you should be able to start ActiveSync from the device
after making sure it is not connected via the serial
port or infrared port (and provided the device is active
on the network - i.e. it can be pinged from the
PC that is running ActiveSync). Be patient because
it can sometimes take up to a minute before the
connection is made. The PC side and possibly the
terminal side will show that a connection has been
made and that the device has been synchronized.

- We have seen situations where the connection is made
but synchronization fails - even though none of the
synchronization check boxes are checked. Often this
has been because another network card was active, in
addition to the ethernet or radio card that is being
used to connect to the device. In this case, we've
had to stop the all network/radio cards and then
just start the network/radio card that is being used
to connect to the device.

- Once you've made your connection and done your work
you can disconnect from the terminal side and then
later reconnect by simply runing ActiveSync from
the terminal side. Options in the terminal's
ActiveSync program allow you to disconnect and
start the connection.

- If the terminal is powered off or suspended, simply
run ActiveSync from the terminal side again.

- If you ever have to cold-boot the device or the battery
on the device loses power completely, the partnership
information in the terminal will be lost. In order to
regain it, you must again make a serial, or perhaps
infrared, connection to the host PC that is running
ActiveSync. However, before doing so, you must use
the option on the File pull-down menu of ActiveSync
to delete the partnership because ActiveSync won't
let the terminal use the partnership you created
originally because it thinks your cold-started terminal
is a different terminal.

Before choosing the 'Delete Partnership' option from
the File pull-down menu be sure that the main ActiveSync
window shows that the current partnership is the one
with the device that was cold-started. If not, you must
first use the 'Mobile Device' option on the File pull-down
menu to switch to the correct partnership name. If
ActiveSync is currently connected to another mobile device
you will have to disconnect that other device before you
can change the 'Mobile Device' partner.

Once you've deleted the original partnership, be sure
that 'Allow serial...' is checked on the 'Connection
Settings' window of ActiveSync before trying to
establish a connection over the serial port or infrared.

- If you find that after establishing a connection, the
connection is immediately dropped, look for an option
in the ActiveSync settings on the terminal that
specifies that ActiveSync should 'disconnect when
complete when manually synchronizing.' You will
need to turn this option off.

Bar Code Configuration on Windows CE Devices
--------------------------------------------
Each kind of Windows CE device has its own unique way of
configuring the bat code settings. Most of the time, the
scanned bar codes can be set up to be routed to the keyboard
so that the Client can read the scanned data along with keyed in
data. This might require another utility to be running at the
same time - as is the case for the Intelligent Instrumentation
LanPoint CE.

The manufacturer usually also provides a utility for
configuring which bar code symbologies are active and perhaps
whether or not the scanned bar codes should have prefix (preamble)
and/or suffix (postamble) characters added.

Using the manufacturer's utility to configure the terminal works
just fine, but can be very tedious if you have a lot of devices
to configure. If there is a way to download a configuration file
along with the DCConnect Client files, then setting up device can
be done more quickly.

Part of the DCConnect Client product is a program called the
IBM CE Config Tool. This tool can be used to update registry keys
and create files on the CE device. If the Windows CE device
maintains its bar code configuration in the registry, then the
IBM CE Config Tool can be used to update the necessary registry
keys based on a configuration file (CECONFIG.INI).

This is the case for the Intermec 700 terminal. The Intermec 700
registry maintains the active symbologies and their parameters,
the preamble and postamble characters along with nearly every other
kind of configuration parameter from volume control to WEP
encryption key. The IBM CE Config Tool can set static registry key
values automatically and it can also prompt the user for values that may
have one or more valid choices. For those choices that the user must
enter or choose a value, the answer is saved to non-volatile memory so
that if the terminal is cold-started or has total loss of battery power,
the configuration can be restored without having to ask the user the
questions again. For more information about the IBM CE Config Tool,
please see Windows CE Configuration Tool.

Whether or not the device must be configured to use both a preamble
and postamble character depends on whether or not the Client must
be able to distinguish between keyboard and scanner input. If
there will be certain input fields for which the terminal user is
only allowed to scan data, then the Client will need to make the
distinction between keyboard and scanner input so that it can ignore
keyboard input for these fields. In this case, you must configure
a preamble and postamble character for all scanned data and you
must add to EMULATOR.INI the SCAN_SENTINEL_CHARS keyword. For more
about this keyword, see Keyword: SCAN_SENTINEL_CHARS.

In the case that the ability to distinguish between keyboard and
scanner input is not required, the device will still need to be
configured so that the postamble character is a carriage return;
otherwise the terminal user would have to press Enter after every
scan. Often the default postamble character is a tab character
instead of the required carriage return.

Using Hostnames Instead of IP Addresses for Windows CE Devices
--------------------------------------------------------------
When configuring the data collection terminals in the DCConnect server
configuration, you have the option to specify IP addresses or to
use hostnames. The latter allows devices to be configured to use DHCP
rather than fixed IP addresses. If hostnames are to be used for
Windows CE / Windows Mobile devices, each device must have its Device
Name defined uniquely. On many devices, setting the Device Name is done
in the Settings -> System tab -> About icon -> Device ID tab - > Device
name field. However on some CE devices the System icon in the Control
Panel is used instead - to set the Computer name in a similar way to
Windows PCs.

A Windows CE device defaults to a device/computer name such as Windows_Mobile
or something related to the device type. As long as the device is still
configured with the default name, it can't be referenced on the network by
that default name. But once that name is changed to anything else (and the
device is then warm booted), that device can be referenced by that name - for
example from a ping command on another system or by the DCConnect Server.

Depending on the network setup, it may be necessary to use the fully qualified
network name (hostname@domain) when trying to access the device. If this is
necessary, then when configuring the devices in the DCConnect server
configuration (Terminal Settings -> General tab -> Terminal Address -> TCP/IP)
the fully qualified name must be used there as well (along with the port
number if that is something other than 7500).

IBM CE Configuration Tool
-------------------------
The DCConnect Client product includes the IBM CE Config Tool
(CEConfig) which was created to simplify the configuration of
Windows CE devices. If you only have a couple of devices to
configure, it is probably not worth the effort to use the
tool. But if you have more than 10 devices then you will
probably save time using CEConfig to configure your terminals.

Note: Use of the IBM CE Config Tool requires that the Microsoft
eMbedded Visual Toolkit be installed because some Visual
Basic DLLs must be obtained from this toolkit and must be
loaded to the device in order for the Config Tool to run.
For more information about how to get this Toolkit please see
Hardware and Software Requirements for Windows CE Devices

In addition to simplifying the initial configuration of the
terminal, recovery of a terminal's configuration after a
cold-boot or total loss of battery power can be done
automatically if the CEConfig tool was used to set up the
terminal.

The tool can be used to do the following:

- Update the Windows CE registry. Often configuration
parameters such as IP address, 802.11 Network Name,
active bar code symbologies and volume setting are all
maintained in the registry.

- The tool can handle registry keys of the following types:

REG_SZ - Null-terminated string
REG_MULTI_SZ - Concatenated list ofnull-terminated strings
with extra null at the end
REG_DWORD - Numeric value
REG_BINARY - Series of hexadecimal characters

- Many values will be the same for all devices. These
can be set automatically when the tool runs without any
user intervention.

- Other values, such as the terminal IP address, will be
different on each device. The tool provides the ability
to prompt the user for values of this type.

- For some values that the user must enter, there may be
a certain set of valid choices. For example, if multiple
DCConnect Servers are installed, the user may need to be
provided a list of servers so that the appropriate one
can be selected. The tool can be set up to force the
user to select from a predefined list of valid choices
for a given value. You can also give the user a list
of choices and still allow them to enter a value not
in the list.

- Often the actual value that goes in the registry is
not very user-friendly and rather than showing the
actual list of values to the user you would prefer
to assign a meaningful name to each value and let
the user choose from the list of meaningful names.
For example, if the user had to choose from a list
of DCConnect Server IP addresses:

2.13.94.8
6.27.96.5
1.6.99.3
11.20.64.37
3.1.65.37

it might be better to present the user with a
list of the cities that these servers are
located:

Charlotte
Boca Raton
New York
Chicago
Pittsburgh

The tool allows you to make the association
between the values and the meaningful names
and just present the user with the meaningful
names.

- If the user must be prompted for answers that would
be the same for two or more questions, you need
only prompt once and the answer can be reused for
other values. For example, perhaps the DNS Server and
the WINS Server will always be the same server but
the user must choose from 4 servers. Once the
user chooses the server, the answer can be applied
to both the DNS Server and WINS Server values
in the registry.

- Every time the user is prompted to enter a value, the
answer provided by the user can be saved to non-volatile
storage. In the event of a cold-boot or total loss of
battery power, the CEConfig tool can be rerun and the
old answers will be available to reuse exactly as they
were entered. The tool can also be rerun and the
previous answers can be reviewed and each changed if
necessary.

- In addition to updating registry values, the CEConfig
tool can be used to create configuration files, such
as EMULATOR.INI. If the entire contents of the file
are fixed, the file can be created without any user
intervention. But if one parameter, such as the
DCConnect Server, has several valid choices, the user
can be prompted to enter the value just as can be
done for registry keys.

- The following directory and file operations can be
performed:

- Create a directory
- Remove a directory
- Rename a directory
- Copy a file
- Delete a file
- Rename a file

- The tool can start another program and wait for
it to complete.

- The tool can automatically reboot the terminal
after all configuration changes and file operations
are completed. The user will first be given a Yes/No
question of your choice. Only if the user responds
Yes will the reboot be peformed.

All of the above is accomplished by setting up a
configuration file called CECONFIG.INI and then
installing it and the CE Config Tool itself (CECONFIG.VB)
to the \Windows directory of the Windows CE device.
You would typically include these files in the
DCConnect Client .CAB file so that the CE Config
Tool and the DCConnect Client are installed at
the same time.

CECONFIG.VB is a Visual Basic application and
therefore requires that the Visual Basic runtime
be installed on the device. On some devices, such
as the Intermec 700, most of the Visual Basic
runtime files are already preinstalled. On other
devices, you will have to install them. Here are
some of the Visual Basic runtime files:

pvbform2.dll
pvbhost2.dll
pvbload.exe
vbscript.dll

Even when the Visual Basic runtime files are
preinstalled, a couple of additional VB files
need to be added in order to run the IBM CE
Config Tool. These are:

pvbdecl.dll
MSCEFile.dll

All of the Visual Basic runtime files are provided with
the SDKs that can be installed along with the Microsoft
eMbedded Visual Toolkit. Any of these files that are
not already on the terminal will need to be included
in the DCConnect Client .CAB file along with the Client
files and CECONFIG.VB and CECONFIG.INI. If you look at
the default DCCLIENT.INF provided with the DCConnect
Client files, you'll see references to pvbdecl.dll and
MSCEFile.dll.

The remainder of this section will discuss the content
of CECONFIG.INI. A sample CECONFIG.INI is provide in
the root directory where the DCConnect Client files are
installed. Please refer to that file for an example of
the proper syntax for some of the commands that can be
performed.

First a few general rules:

- You can include comments in the file by having the
first non-whitespace characters be either a
semicolon (;) or double slashes (//).

- You can have as much whitespace as you want before
and after the equal sign and before the keywords.
But each keyword, its equal sign and value must all
be on the same line.

- You can have blank lines between lines wherever you
want.

Setting Registry Keys with the IBM CE Config Tool
-------------------------------------------------
For each change to the registry that is needed, the .INI
file will specify a the full key value name, a type
identifier and the value to be assigned. There are a
number of type identifiers for registry key values:

* REG_BINARY
* REG_DWORD
REG_DWORD_LITTLE_ENDIAN
REG_DWORD_BIG_ENDIAN
REG_EXPAND_SZ
REG_LINK
* REG_MULTI_SZ
REG_NONE
REG_RESOURCE_LIST
* REG_SZ

To start with, the tool will only support REG_BINARY,
REG_DWORD, REG_SZ and REG_MULTI_SZ since they are the
most common types.

Technically speaking a registry key itself does not have
any assignment - although the value name "" is used as
the (Default) value for the key. When you specify the value
name in the .INI file, the full path for the key and the
value name will be combined into a single parameter for
the keyword KEY. For example if the following is
specified:

KEY = \HKEY_LOCAL_MACHINE\SOFTWARE\IBM\DC Connect\1.0\Server version

the 'Server version' part is actually considered the value
name and the rest is the key name. For simplicity, the .INI
file syntax will use the combination as shown above. If you
need to update the default value for a key, specify the key
name and follow it with the backslash. For example:

KEY = \HKEY_LOCAL_MACHINE\SOFTWARE\IBM\DC Connect\1.0\

Here's a more complete example of a key/value definition in
the .INI file:

[REGISTRY]
KEY = \HKEY_LOCAL_MACHINE\ABC\DEF\GHI\KEY
TYPE = SZ
VALUE = This is my reg string

In the example above, the type idenitfier is SZ, which is a
simple null-terminated string. The value to be assigned
will be all data from the first non-blank character after
the = following 'VALUE' up to and including the last
non-blank character on the line.

You can also enclose the value in double quotes. In this
case the double quotes are not considered part of the value
string. For example:

VALUE = "This is my reg string"

If the string contains any double quotes, then use two
double quotes for every one the string should contain,
whether or not the string is enclosed in double quotes.

VALUE = "This string ends with a double quote """

or without the enclosing double quotes:

VALUE = This string ends with a double quote ""

If nothing follows the = after 'VALUE', the key will
be set to an empty string. For example:

VALUE =

The REG_MULTI_SZ registry key type is a variation of REG_SZ
where the key value actually contains a series of strings,
each terminated by a null character, with an additional null
character at the end of the list. So when TYPE = MULTI_SZ,
you will be allowed to have one or more VALUE statements for
a given [REGISTRY] definition and they will all be appended
together with the imbedded and trailing nulls before being
assigned to the registry key value.

For TYPE = DWORD, the value is simply a number. For example:

VALUE = 33

You should not use double quotes around the value and you must
have some number after the equal sign. The number may also
be specified as a hex value using syntax such as:

VALUE = 0x0000000b

The value must start with 0x in order for the tool to
interpret it properly.

Finally for TYPE = BINARY, you can specify a string of
characters in the format 0xhh where hh is a hex value from
00 to ff. For example:

VALUE = 0x0d 0x0a

If the registry key is binary but is really a unicode string,
simply enclose it in double quotes - using the double quote
pairing if necessary. You may want to pad the binary unicode
string with nulls. If so, specify

TYPE = BINARY, LENGTH(nn)

where nn is the final length (in bytes) of the string. If
you want to specify a string of NULLs for the parameter,
use "" for the VALUE.

If a series of binary unicode strings should be appended
together, specify a series of TYPE, VALUE pairs for the
[REGISTRY] definition. For example:

[REGISTRY]
KEY = HKEY_CURRENT_USER\ControlPanel\Owner\Owner
TYPE = BINARY, LENGTH(72)
VALUE = ""
TYPE = BINARY, LENGTH(72)
VALUE = "IBM"
TYPE = BINARY, LENGTH(372)
VALUE = "8501 IBM Drive, Charlote NC 28262"
TYPE = BINARY, LENGTH(50)
VALUE = "1-800-IBM-HELP"
TYPE = BINARY, LENGTH(74)
VALUE = ""

For all specified KEYs, if the key/value pair does not yet
exist, it will be created.

You can specify more than one KEY = value for any
[REGISTRY] definition. Each will be set to same value.

In addition to being able to set key values that are
hard-coded in the .INI file, the tool will also provide
a mechanism to prompt the user for values. The following
kinds of TYPE keywords are supported:

PROMPT_DWORD
------------
Prompts the user for a number. If a VALUE = is specified,
that is used as the initial value in the entry field.

The user is only allowed to enter decimal values, not
hex. If hex values must be entered, the choices will
probably be limited to a certain set with certain
meanings. In that case the PROMPT_NAMED_DWORD_LIST
(see below) should be used.

If you want the user to be limited in the range of
values that can be selected, you can specify that range
following the PROMPT_DWORD parameter in the TYPE command.
For example, to limit the range to be 1-20:

TYPE = PROMPT_DWORD, 1, 20

Use the PROMPT keyword (described below) to inform
the user what the valid range is.

PROMPT_SZ
---------
Prompts the user for a string. If a VALUE = is
specified, that is used as the initial value in
the entry field.

PROMPT_SZ_LIST
--------------
Similar to PROMPT_SZ except that the user is
presented a drop-down list of possible
strings from which he must select one value.
By default the user cannot enter any value
except what is in the list. Use the ALLOW_ENTRY
keyword (described below) to allow th user to
enter a value other than the ones provided in
the list.

Use the VALUE = keyword for each entry that should
be part of the list. All values are added to the
listbox alphabetical order. The first VALUE
encountered in the file will be the one that is
highlighted by default.

PROMPT_DWORD_LIST
-----------------
Similar to PROMPT_SZ_LIST except that numbers are
used instead of strings.

PROMPT_NAMED_DWORD_LIST
-----------------------
This is a combination of PROMPT_SZ_LIST and
PROMPT_DWORD_LIST. The user is shown a list of
strings which correspond to certain values; the
user does not see the values. But when the
user selects a string, the corresponding DWORD
is actually what is stored in the registry key.

In the .INI file, the new keyword NAMED_VALUE
is used to specify the string that goes into
the list followed by a comma followed by the
number.

To simplify processing, the name part cannot
contain any commas. Otherwise it will be
treated as other strings - with regard to
doubling up double quotes that are part of the
string and enclosing the entire string in double
quotes. Here's an example:

NAMED_VALUE = "RED", 6

PROMPT_NAMED_SZ_LIST
--------------------
Same idea as PROMPT_NAMED_DWORD_LIST except
the name is a more user-friendly description
that you want to present to the user instead
of the actual value that will be assigned to
the registry key. For example, if you want
the user to choose from a list of server IP
addresses but you'd rather have him choose
the name of the server instead of the actual
IP address, you could set up a list of
choices such as the following:

NAMED_VALUE = "CHICAGO SERVER", "10.12.112.1"
NAMED_VALUE = "CHARLOTTE SERVER", "10.19.141.1"
NAMED_VALUE = "BOCA RATON SERVER", "10.44.100.1"

For all of the above, you must provide the following
keyword to specify the prompt that is shown to the user:

PROMPT = "Select the network name:"

The rules for what can follow the equal sign are the
same as for VALUE = when type = SZ.

For all of the TYPE = keywords that include "_LIST"
in the type name, the parameter, ALLOW_ENTRY, can be
added, preceded by a comma. This parameter indicates
that when showing a list of choices (as a drop-down list)
also allow the user to enter a value not in the list. For
example:

[REGISTRY]
KEY = \HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Tcpip\DefaultGateway
TYPE = PROMPT_NAMED_MULTI_SZ_LIST, ALLOW_ENTRY, SORT(15)
NAMED_VALUE = 10.94.101.30 (Chicago) , 10.94.101.30
NAMED_VALUE = 10.94.7.30 (Boca Raton) , 10.94.7.30
NAMED_VALUE = 10.94.7.12 (Charlotte) , 10.94.7.12
PROMPT = "Choose location for router:"

Notice that the example above also includes SORT(15) as the
last parameter of the TYPE = line. This parameter tells
the tool to sort the list by the 15th character in each
name (where the city starts) rather than by the first
character in the name. This parameter can be used for
any type that includes _NAMED in the named:

PROMPT_NAMED_DWORD_LIST
PROMPT_NAMED_SZ_LIST
PROMPT_NAMED_MULTI_SZ_LIST

Here are some other examples for setting registry keys:

// This example is just a simple prompt for the network name (key name made up)
[REGISTRY]
KEY = \HKEY_LOCAL_MACHINE\INTERMEC\RADIO\NETWORK NAME
TYPE = PROMPT_SZ
VALUE = ANY
PROMPT = Enter the network name:

// In this example, the user must choose from a list of predefined values; the
// user cannot enter his own value (because ALLOW_ENTRY not specified).
// 'WAREHOUSE1' is the default because it is first in the list.
[REGISTRY]
KEY = \HKEY_LOCAL_MACHINE\INTERMEC\RADIO\NETWORK NAME
TYPE = PROMPT_SZ_LIST
VALUE = WAREHOUSE1
VALUE = WAREHOUSE2
VALUE = WAREHOUSE3
VALUE = SHIPPING
PROMPT = Select the network name:

// In this example the value has to be set for two different registry keys
// Distance Between Access Points = SystemScale: 3=Small, 2=Medium, 1=Large
[REGISTRY]
KEY = \HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\SystemScale
KEY = \HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Config01\SystemScale
TYPE = DWORD
VALUE = 1

// This is an example of setting a binary key
// Code 39: Not active = 41 4d, active = 41 4c
[REGISTRY]
KEY = \HKEY_LOCAL_MACHINE\SOFTWARE\Intermec\ADCDevices\S9C\DevConfig\Code39\Decoding
TYPE = BINARY
VALUE = 0x41 0x4c

Creating Files with the IBM CE Config Tool
------------------------------------------
In addition to being able to update the registry, this tool can
also be used for creating text files in the device. Examples of
these files would be EMULATOR.INI for the DCConnect Client or
either DWTS.INI and CS2CBF01.CFS for DOS/Windows Terminal Services.
For these files, most of the file is often hard-coded. But there
might be a setting or two that needs to be prompted for from the user.

In order to tell the VB tool to create a file, we'll have a new kind
of section called [TEXT_FILE] that may include the following keywords:

PATH - Specifies the full path and file name for the file to be
created. If no path is specified, the file will be created
in the root directory. Here's an example:

PATH = \Storage Card\DCConnect Client\emulator.ini

FILE_FORMAT - Specifies whether output to the file should be written using
ASCII or UNICODE characters. If this keyword is not specified
the default is ASCII.

(In the initial release of this tool, only ASCII is supported).

You can also specify APPEND as a parameter for this keyword to
indicate all text lines should be appended to the end of the
current file.

TEXT - Specifies a line of text that should be written to the file
verbatim. Rules for specifying the text string are the same
as for specifying a VALUE when TYPE = SZ (see above) in a
registry key definition.

TEXT_PROMPT - Specifies a line of text that includes a place holder %s
that indicates where to fill in the value that will be
substituted. If for some reason you have an output string
that would include %s, use the TEXT command to specify that
part of the string and use MULTI_PART to combine the output
of that TEXT command with the TEXT_PROMPT command.

After the TEXT_PROMPT command you need to specify what will
be prompted for using the TYPE, VALUE and PROMPT keyword
as described above for registry keys. For example, suppose
a particular customer had multiple DCConnect Servers that
the DCConnect Client could talk to, the following commands
could be used to set up the TCPIP_HOST keyword in EMULATOR.INI:

TEXT_PROMPT = "TCPIP_HOST = %s"
TYPE = PROMPT_NAMED_SZ_LIST
NAMED_VALUE = "CHICAGO SERVER", "10.12.112.1"
NAMED_VALUE = "CHARLOTTE SERVER", "10.19.141.1"
NAMED_VALUE = "BOCA RATON SERVER", "10.44.100.1"
PROMPT = "Select the DCConnect Server:"

MULTI_PART - Used to specify that 2 or more TEXT or TEXT_PROMPT commands
should actually form a single line in the file. Is really
only needed for TEXT_PROMPT keywords but would apply to TEXT
keywords if encountered within the specified number of lines.
This is useful if you have to prompt for two or more values
for a single output line. For example:

MULTI_PART = 2
TEXT_PROMPT = "DIMENSIONS = %s,"
TYPE = PROMPT_DWORD, 1, 16
VALUE = 16
PROMPT = "Enter number of rows (1-16):"
TEXT_PROMPT = "%s"
TYPE = PROMPT_DWORD, 1, 20
VALUE = 20
PROMPT = "Enter number of columns (1-20):"

If the user answered 16 and 20 respectively for the
two questions, the single line written to file
would be:

DIMENSIONS = 16,20

Here's an example of creating an entire EMULATOR.INI file:

[TEXT_FILE]
PATH = \Storage Card\DCConnect Client\emulator.ini
FILE_FORMAT = ASCII
TEXT = "PF_MAPPING = Y"
TEXT = "NUM_PF_STRINGS = 0"
TEXT = "NUM_TOUCH_STRINGS = 0"
TEXT = "NUM_ROWS = 16"
TEXT = "NUM_COLS = 20"

TEXT = "SELECT_FONT = Lucida Console"
TEXT = "MENU_PASSWORD = 123"
TEXT = "FULL_SCREEN = Y"

Duplicate Answers in the IBM CE Config Tool
-------------------------------------------
Another feature of the tool allows you to use an answer from
a previous prompt in more than one [REGISTRY] or [TEXT_FILE]
section. For every TYPE = statement in the file you can have
a corresponding ANSWER = statement that tells the tool to
save the answer for later use in the file. For example, we
could add the following statement to the section above where
TYPE = PROMPT_NAMED_SZ_LIST is being used.

ANSWER = DCConnect Server

Note that the answer called 'DCConnect Server' is set to one
of the values "10.12.112.1", "10.19.141.1" or "10.44.100.1"
instead of the name for the value that the user chooses from:
"CHICAGO SERVER", "CHARLOTTE SERVER", or "BOCA RATON SERVER".

The value that results from this TYPE = statement (usually an
answer to a pop-up) can than be used in other [REGISTRY] or
[TEXT_FILE] statements by specifying USE_ANSWER(DCConnect Server)
as the second parameter on the TYPE = line when the TYPE is one of:

SZ
SZ_LIST
DWORD

For example:

// In this [TEXT_FILE] section we use the IP address entered by the user
// in the first [REGISTRY] section above to be part of a configuration file.
[TEXT_FILE]
Path = \SAMPLE.INI
FILE_FORMAT = ASCII
TEXT = "LOGNAME = \Storage Card\logfile.dat"
TEXT = "MAX_RECORDS = 1000"
TEXT_PROMPT = "IP_ADDRESS = %s"
TYPE = SZ, USE_ANSWER(DCConnect Server)

The answer called "DCConnect Server" can be used elsewhere in the file as many
times as needed.

You would normally use the ANSWER = statement associated only with TYPE =
statements that specify some sort of PROMPT_.... However, you can actually
use it associated with any TYPE = statement, to associate the answer name with
a particular value that you might need to use multiple times in the file. In
this case, answer name acts similar to an environment variable that can be
set once and used many times. So if you had to change the value of the
variable/answer, you do it in one place and all the other references to that
answer automatically get the new value.

File, Directory and Other Commands in the IBM CE Config Tool
------------------------------------------------------------
You can also include one or more [COMMANDS] sections in the
CECONFIG.INI file which allows you to perform operations such
as creating directories, copying files, deleting files, and
merging files. Here are the valid keywords in this sections:

MAKE_DIR = \Storage Card\Delivery System\Signatures

Used to create a directory. Just specify the name
of the directory to the right of the equal sign.

REMOVE_DIR = \tempdir

Used to remove a directory. Specify the full path
to the directory to be removed.

RENAME_DIR = \Storage Card\tempdir, \Storage Card\realdir

Used to rename a directory. Specify the source
directory name then a comma then the new name. Be
sure to use the full path in the new name as well.

COPY_FILE = \Storage Card\DCConnect Client\emulator.ini, \emulator.ini

Used to copy a file. Specify the source file then
a comma then the target file.

DELETE_FILE = \temp.xxx

Used to delete a file. Specify the full path to the
file to be deleted

RENAME_FILE = \Storage Card\emulator.ini, \Storage Card\emulator.bak

Used to rename a file. Specify the source file
then a comma then the new name. Be sure to use the
full path in the new name as well.

MESSAGE = "Any message to show user - perhaps instructing them to do something."

Will show the user a pop-up with an OK button. Use
this to instruct the user to do something. They
should press OK after they have done that task.

RUN_PROGRAM = "Program name", "Parameters"

Used to start another program. The tool will wait
for that program to complete before it continues
processing the script.

If there are any parameters for the program, you
must put a comma after the program name and
then list the parameters (the enclosing double
quotes are optional). You may have more than
one parameter, each must be separated by
spaces. Enter the parameters just as you
would on the command line.

REBOOT = "Yes/No message to show user. If press Yes, terminal will reboot"

Tells the tool to reboot the terminal. But first
a pop-up is shown, using the message text that
you provide as the parameter for this command.
This pop-up will have Yes and No buttons. A Yes
response will cause the tool to do the reboot.
A No response will cause the tool to keep on
processing the file; no reboot is done in
this case.

WARMBOOT = Synonym for REBOOT

COLDBOOT = "Yes/No message to show user. If press Yes, terminal will be cold-booted"

Tells the tool to cold-boot the terminal. But first
a pop-up is shown, using the message text that
you provide as the parameter for this command.
This pop-up will have Yes and No buttons. A Yes
response will cause the tool to do the cold-boot.
A No response will cause the tool to keep on
processing the file; no cold-boot is done in
this case.

This command is only available for Intermec devices.

FINAL_MESSAGE = "Text to show user"

If a REBOOT / WARMBOOT / COLDBOOT is not performed, when
the tool completes processing of the .INI file it will
show a message similar to "Process complete. Please reboot".
You can override that message using this FINAL_MESSAGE
command.

DONT_END = TRUE

Tells the CE Config Tool not to end when the final pop-up
is shown (showing the default or overridden FINAL_MESSAGE).
Use this in the case that you want the user to manually
warm boot or cold boot the terminal and you don't want the
user to clear the final pop-up. When this command is in
effect, pressing OK on the final pop-up will simply
redisplay it.

Here is an example of a [COMMANDS] section:

// Copy CS2CBF01.CFS and DWTS.INI from storage card to where the are needed
[COMMANDS]
COPY_FILE = \Storage Card\DeliverySystem\Install\CS2CBF01.CFS, \CS2CBF01.CFS
COPY_FILE = \Storage Card\DeliverySystem\Install\DWTS.INI, \DWTS.INI
MAKE_DIR = \Storage Card\DeliverySystem\Signatures

// Call the VB program that sets up the database. It uses the file CREATEDB.INI to get the
// Device ID
RUN_PROGRAM = "\Windows\pvbload.exe", "\Storage Card\DeliverySystem\Install\CreateDB.vb"

REBOOT = "Do you want to reboot activate these configuration changes?"

Preserving and Reusing the Answers in the IBM CE Config Tool
------------------------------------------------------------
One key feature of this tool is the ability to save the answers
provided by the user so that they can be reused or just reviewed
the next time the tool is run. This allows you to restore the
terminal automatically if the terminal is cold-booted or if a
total loss of battery power occurs. In order to put this
feature into effect, you must create a [SETTINGS] section at
the top of the file - before any [REGISTRY] or [TEXT_FILE]
section and within that section specify the keyword:

ANSWER_FILE_PATH = full path to answer file

For example:

[SETTINGS]
ANSWER_FILE_PATH = \Storage Card\answers.ans

When the tool encounters the ANSWER_FILE_PATH keyword, it tries to locate
the specified file. If found, the tool will ask the user what it should
do with the answers in the file. The user has three choices:

1) Use the answers exactly as entered; don't actually show the prompt for
any question.
2) Review the answers. In this case all the prompts in the .INI file
are shown using the answers from the answer file as the default in
the entry field.
3) Ignore the answers. All the prompts in the .INI file are shown
using the defaults specified in the .INI file; the tool acts as
if the answer file did not exist.

Regardless of what is done with the answers read from the file, the answer
file is always recreated using the new answers provided - except in the
case where the user chose option 1 to reuse the answers as-is; in this
case there is no need to change the answer file.

If the ANSWER_FILE_PATH keyword is used and the answer file specified
does not exist, then the tool will create the answer file using the
answers provided by the user during the current run of the tool.

How to Explore Registry Keys on a CE Device
-------------------------------------------
If you have installed the Microsoft eMbedded Visual Toolkit and you
have an ActiveSync connection to your Windows CE device, then you
can use the Tools pull-down menu in either the MS eMbedded Visual C++
Compiler or the MS eMbedded Visual Basic to start the Remote Registry
Editor for Windows CE.

You can view or change any value in the registry of the Windows
CE device. However, before you change any value you should be
absolutlely certain of what you are doing or the Windows CE device
may not work properly after the change(s) are made.

The Remote Registry Editor provides the option 'Export Registry File...'
on the 'Registry' pull-down menu. This allows you to create a readable
.REG file on your PC that shows all or part of the registry tree, listing
keys, values and the associated data. How much is written to the .REG
file depends on what key was highlighted when the 'Export Registry File...'
option was selected. If you want everything, be sure to select the
topmost level (e.g. Pocket PC (Default Device)).

It is recommended that you have an ActiveSync TCP/IP connection to
the device while using the registry editor - especially if searching
or exporting data; searching or exporting the registry can take a
long time over a serial connection.

Note that a .REG file may not show the data for a particular key
in the format that you expect. For example, the IpAddress which
is of type REG_MULTI_SZ does not show up in the file like a
normal IP address (e.g. 102.102.102.81). Instead it is listed as:

"IpAddress"=hex(7):\
31,30,32,2e,31,30,32,2e,31,30,32,2e,38,31,00,00,00,00

The 31,30,32,2e are four hex values for the four characters

'1' '0' '2' '.'

which of course are the first 4 characters of the IP address.

The 7 in hex(7) indicates REG_MULTI_SZ. Here is the list of values
that might appear and what they mean:

0 = REG_NONE
1 = REG_SZ
2 = REG_EXPAND_SZ
3 = REG_BINARY
4 = REG_DWORD / REG_DWORD_LITTLE_ENDIAN
5 = REG_DWORD_BIG_ENDIAN
6 = REG_LINK
7 = REG_MULTI_SZ
8 = REG_RESOURCE_LIST
9 = REG_FULL_RESOURCE_DESCRIPTOR
10 = REG_RESOURCE_REQUIREMENTS_LIST

So when searching a .REG file for the IP address, you would not
search for "102.". You would instead search for "31,30,32,2e".

IBM Get Registry Tool
---------------------
The DCConnect Client product includes a companion tool to the IBM
CE Config Tool that can be used to find out the value of registry
keys on Windows CE devices.

The GetReg tool (GetReg.vb) looks for a file called GetReg.in, in the root
directory, which lists one or more registry keys for which the current
value should be obtained. The following list of keys is from an example
GetReg.in that was used to obtain the radio parameters for an Intermec 730:

\HKEY_CURRENT_USER\Software\Intermec\80211Conf\Profiles\Profile_1\8021x
\HKEY_CURRENT_USER\Software\Intermec\80211Conf\Profiles\Profile_1\Association
\HKEY_CURRENT_USER\Software\Intermec\80211Conf\Profiles\Profile_1\CN1

Running the GetReg.vb program takes the input file and generates an output file
called GetReg.out, in the root directory, which is formatted to facilitate
copying and pasting into CECONFIG.INI for use with the IBM CE Config Tool.

The GetReg tool figures out the type of each registry key value and generates
the appropriate CE Config Tool entry. For example, the GetReg.in file shown
above produced the following content of GetReg.out:

[REGISTRY]
KEY = \HKEY_CURRENT_USER\Software\Intermec\80211Conf\Profiles\Profile_1\8021x
TYPE = BINARY
VALUE = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
TYPE = BINARY
VALUE = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00

[REGISTRY]
KEY = \HKEY_CURRENT_USER\Software\Intermec\80211Conf\Profiles\Profile_1\Association
TYPE = DWORD
VALUE = 1

[REGISTRY]
KEY = \HKEY_CURRENT_USER\Software\Intermec\80211Conf\Profiles\Profile_1\CN1
TYPE = SZ
VALUE = ""

The input file, GetReg.In, is allowed to have comments in it. Any line on which
the first non-blank character is # or ; or other the first two non-blank
characters are //.

Changing the Font Used By the Client on a Windows CE Device
-----------------------------------------------------------
The DCConnect Client uses a 'non-proportional' (aka'fixed' or
'monospaced') font to display all text so that it is easy to
line everything up. It also requests the bold version of the
font in order to make it as easy to read as possible.

By default, most Windows CE devices that we have tested, will use the
Courier New font as the fixed font. While this font works fine, it
is smaller than some other fixed fonts that are easier to read on
the Windows CE device. Once such font is called Lucida Console.
However this font has not been preinstalled on the Windows CE
devices that we have tested; Windows CE has very few font files
installed (*.TTF).

Fortunately, a Windows CE device can use the same font files that
are installed on a Windows NT / 2000 PC. And there are a lot
more to choose from. Using Windows Explorer, you can change to
the \Winnt\Fonts folder and double click on any font file to see
what it looks like. Unfortunately determining whether a particular
font is non-proportional involves visual inspection. There does not
seem to be any flag or keyword that identifies fonts as
non-proportional or not. When you double click the font file and
it shows examples of the font, part of the screen shows the lower
and upper case letters in the font. If the length of these two
lines is the same, then the font is most likely non-proportional
and could therefore be used by the Client on a Windows CE device.

Fonts that appear to be non-proportional are:

Courier New (COUR.TTF)
Courier New Bold (COURBD.TTF)
Courier New Bold Italic (COURBI.TTF)
Courier New Italic (COURI.TTF)
Letter Gothic (LC______.TTF)
Letter Gothic Bold (LCB_____.TTF)
Letter Gothic Bold Italic (LCBI____.TTF)
Lucida Console (LUCON.TTF)
OCR-B MT (OCRBMT.TTF)
OCR-A II (OCRA2_P.TTF)
QuickType II Mono (QT2M_P.TTF)

Any one of these fonts can be installed in a Windows CE device by
including it in the DCConnect Client .CAB file. For information
about how to include a font file in the .CAB file please see
Building a .CAB File to Install the Client on a Windows CE Device.

The destination directory for the font file should be %CE15% which
usually equates to the \Windows\Fonts directory. However in some
cases, such as for the Intermec 5020, the font file must be installed
to the Windows directory (%CE2%).

Once the font file is installed by the installation of the DCConnect
Client .CAB file, Windows CE has to be restarted in order for
that font file to be registered with Windows CE. Only after it has
been registered can the DCConnect Client use the font.

By default, the DCConnect Client asks Windows CE for a non-proportional
font and the Client uses the first one that is provided. This
behavior can be overridden using the SELECT_FONT keyword in
EMULATOR.INI. This keyword is used to specify the font name, not
the file name. In the list above, the font name is on the left.
For more information about using the SELECT_FONT keyword please
see Keyword: SELECT_FONT.

Serial Port Use on the Windows CE Devices
-----------------------------------------
The COM1 serial port on Windows CE devices can be used by the Client to
communicate with devices such as a serial printer or scale.

There is currently no officially available serial flavor of the Client
that runs on Windows CE devices and that can be used to communicate to
the data collection server via the serial port instead of over ethernet.

The Client will configure the serial port based on the downloaded serial port
configuration (when the serial port is used to talk to another device such as a
printer or scale).

Building a .CAB File to Install the Client on a Windows CE Device
-----------------------------------------------------------------
The best way to install the DCConnect Client on a Windows CE device is
through the use of a Cabinet File (.CAB). Installation of a .CAB file
not only copies files to the proper locations on the Windows CE device
but it can also be used to register DLLs, set registry values and create
shortcuts on the Start Menu and in other folders.

While the DCConnect Client product includes .CAB files for installing a
the DCConnect Client and a default configuration on Windows CE
devices, you will more than likely need to make changes to the default
configuration and would therefore need to recreate the .CAB file.

You do have the option to transfer the .CAB file to the device, install
it and then transfer the modified configuration files. However, that
is usually much harder to manage, particularly when you have a lot
of Windows CE devices to load and configure.

For this reason, the DCConnect Client product also includes the .INF files
(device INFormation files) that were used to create the .CAB files.
Unfortunately, there are enough minor differences between devices,
that we cannot provide a single .INF file that would work with all
the Windows CE devices that we support. However, if you compared
any two .INF files, most of the content would be similar and there
are cases where multiple devices types could share the same .INF
file.

The DCConnect Client product files includes the following .INF file,
each shown with the path in which they can be found relative to where
the Client files were installed:

dcclient.inf
ck30\sample\ck30.inf
cv60\sample\cv60.inf
imec600\sample\imec600.inf
imec700\sample\imec700.inf
imec5020\sample\imec5020.inf
imec6651\sample\imec6651.inf
lanptce\sample\lanptce.inf
sym81xx\sample\sym81xx.inf
sym90xx\sample\sym90xx.inf
x86emdbg\sample\x86emdbg.inf

All but the first .INF file listed above contain device information
specific to only one type of Windows CE device - the one that the
name implies.

But DCCLIENT.INF is set up to be able to create .CAB files for
many different devices with a minimal amount of changes. The rest
of this discussion will describe in great detail the contents of
DCCLIENT.INF.

The .INF file contains device-specific sections along with common
sections that apply to all devices. The .INF file provides the
ability to perform the following kinds of operations during
installation:

- Create directories
- Copy files to specific directories
- Specify where files should be obtained from on the build
machine
- Create or update registry keys
- Create shortcuts on the Start Menu, in the Startup Folder or
in any other folder.
- Register shared .DLLs with the operating system
- Call custom setup routines

Windows CE also uses this information to know what needs to be
undone when you request to uninstall a product that was installed
via a .CAB file.

Although the DCConnect Client product includes the .INF files for building
.CAB files, for licensing reasons, the product does not include the Cab Wizard
tool from Microsoft that is required to create .CAB files from those
.INF files. This tool must be obtained from Microsoft as
part of one of the Software Development Kits (SDKs) that are
part of the Microsoft eMbedded Visual Toolkit. For information about
how to obtain this toolkit from Microsoft for free, please see
Hardware and Software Requirements for Windows CE Devices.

Note: Some older Windows CE devices, such as the Intermec 5020 with
Windows CE 2.11, use a slightly different .INF file format and
also use a different tool (CABARC) for building the .CAB file.
Because the DCConnect Client now supports only Intermec 5020
terminals with Windows CE 3.0, the use of the CABARC utility
and its .INF file format are not described in this document.

The description that follows references the DCCLIENT.INF that is provided
with the DCConnect Client files; so you may want to view that in an editor
while reading this. When reviewing this file, note that any line preceded
by a semicolon is considered to be a comment and therefore will be ignored
by the Cab Wizard tool.

The .INF is made up of several different sections as described below:

[Version] - Gives information about the operating system and the
provider of the application. This section does not
usually need to be changed.

[CEStrings] - Defines variables used in the .INF file - in much the
same way that environment variables are defined. There
are two key variables that are defined here:

AppName = "DCConnect Client"
InstallDir = "\Storage Card\%AppName%"

AppName gives the name of the application and it is used
in several places including when specifying the
installation path, when creating short cuts to the
application and when setting up the registry entry.

InstallDir specifies where to install the files on
the CE devices. Its definition often includes the
use of %AppName% as a sub-folder name. %InstallDir%
is used throughout the file when specifying, not
only where files will go but also when defining
shortcuts and registry definitions.

Note: For devices running versions of Windows CE
prior to 3.0 (e.g. Intermec 600),
%InstallDir% cannot be used when defining
registry keys (in the section [RegSettings.All]).
Instead the literal meaning of %InstallDir% must
be used.

If there is non-volatile disk storage in the target
device then it is usually best to specify the %InstallDir%
be in that non-volatile storage. Many devices have a
removable compact flash card that serves both as
non-volatile storage and as a means of transferring files
to the device. For other devices this non-volatile
storage is internal and cannot be removed. The non-volatile
storage is often given the directory name '\Storage Card'
in the Windows CE file system.

The default DCCLIENT.INF defines the %InstallDir% to be
a sub-directory of \Storage Card for most devices. However,
that does not work for all devices. Here are two exceptions:

The Symbol 81xx terminal does not have a \Storage Card
directory either. The non-volatile flash storage on
this device is given the directory name \Application.
There is also an optional \Data directory which is
non-volatile storage.

Similarly, the HHP 7400 uses the directory name \IPSM
for its non-volatile storage.

[CEDevice.XXXXX] - There are multiple sections of this type - one for
each combination of processor / Windows CE version that
is supported. You can have sections where the XXXXX
portion has names like:

[CEDevice.X86EM]
[CEDevice.MIPS]
[CEDevice.SH3]

which specifies the processor type. But you can also
use more meaningful names that apply to a specific
device such as:

[CEDevice.IMEC600]
[CEDevice.IMEC700]
[CEDevice.LanPTCE]
[CEDevice.Symbol81xx]

This is actually necessary when two devices have the
same processor but use different versions of Windows CE.
This is the case for the Intermec 600 and Intelligent
Instrumentation LanPoint CE. Both have X86 processors,
but the Intermec 600 uses Windows CE version 2.12 while
the LanPoint CE uses version 3.0.

If you look through the .INF file, you'll probably notice
that the .XXXXX qualifier is used not only for
[CEDevice.XXXXX] but also for the following kinds of
sections:

[DefaultInstall.XXXXX]
[SourceDisksNames.XXXXX]
[SourceDisksFiles.XXXXX]

So this qualifier not only identifies the processor type
and valid Windows CE versions, but it is also used to
define which files are to be copied and registered and
where these files should be copied from on the build
system.

You should not have to change any of the [CEDevice.XXXXX]
sections that are already defined. But you may need to
create new ones if you have a new devices to support.

Note: If you have a device that has a processor / Windows CE
version combination that is not already listed in
the file, not only would you have to add the
appropriate sections to this file, but you would
also have to request from IBM, executables for the
DCConnect Client that are built for this processor /
Windows CE combination. In this situation, contact
your IBM representative to find out whether IBM is
able to do this and to find out whether there are
any charges involved.

[DefaultInstall] - This section works in conjunction with all of the
sections of the type [DefaultInstall.XXXXX] to specify
what installation operations should be performed. The
statements in this section apply to all devices. In
the default DCCLIENT.INF, the following statements are
in this section:

CopyFiles = Files.Client, Files.ClientData, Files.Fonts
CEShortcuts = Shortcuts.All
AddReg = RegSettings.All

The first line tells the Cab Wizard which sets of files
should be copied for all devices. The sections
[Files.Client], [Files.ClientData] and [Files.Fonts]
list one or more files, later in this .INF file.

The second line tells the Cab Wizard that the installation
should create all Short Cuts on the Windows CE device that
are defined in the section [Shortcuts.All] which is near
the bottom of the file (and is disucssed below as well).

The third line tells the Cab Wizard that the installation
should add to the registry those keys that are defined
in the section [RegSettings.All] - which is at the
bottom of the file (and is discussed below).

You can also specify the following statements in this
section if they apply to all devices:

CESetupDLL = ... ; Name of Setup DLL to run
CESelfRegister = ... ; Names of DLLs that must register
; themselves.

[DefaultInstall.XXXXX] - There are multiple sections of this type - usually
one for each [CEDevice.XXXXX] section that is defined. This
section can include the same statements that [DefaultInstall]
can include:

AddReg = ... ; Specifies one or more section names [xx.yy]
CEShortCuts = ... ; Specifies one or more section names [xx.yy]
CopyFiles = ... ; Specifies one or more section names [xx.yy]
CESetupDLL = ... ; Specifies a single .DLL name
CESelfRegister = ... ; Specifies one or more .DLL names

It's also valid to have no statements for some of the devices.

In DCCLIENT.INF you'll see that [DefaultInstall.IMEC700] includes
the following statements (actually commented out by default):

CopyFiles = Files.FullScreen, Files.CfgTool
CESelfRegister = pvbdecl.dll, MSCEFile.dll
CEShortcuts = Shortcuts.CfgTool

The 'CopyFiles' statement above lists a couple of sets of
files that should be installed - in addition to those that
are listed in the [DefaultInstall] section. These extra
files are needed only if the Client should run in "full-
screen" mode and if the IBM CE Config tool will be used.

The 'CESelfRegister' statement lists .DLLs that must be registered
with Windows CE during the install process. 'pvbdecl.dll' and
'MSCEFile.dll' are both Visual Basic product DLLs that are needed
to run IBM's CE Config tool. Intermec 700 terminals come
with the rest of Visual Basic runtime already installed.

The 'CEShortcuts' statement lists additional short cut
section(s) that should be included for creation of more
shortcuts - in addition to those short cuts that are
defined in the [DefaultInstall] section above. The
[Shortcuts.CfgTool] section below adds a shortcut for
the CE Config tool to the Start Menu.

[SourceDisksNames] - This section works in conjunction with all of the
sections of the type [SourceDisksNames.XXXXX] to specify
where, on the build PC, files are located so that the
proper ones can be found when creating the .CAB file. In
the default DCCLIENT.INF, the following statements are in
this section:

1 = ,"Common files",,.
2 = ,"Windows fonts",,c:\winnt\fonts

At the start of every statement is a number that is used to
identify a particular directory. The numbers 1 and 2 are
defined in the [SourceDisksNames] section while the numbers 3,
4 and 5 are defined in the [SourceDisksNames.XXXXX] sections
(although 4 and 5 are not always used). You will have as
many different numbers as you have different directories on
the build PC from which to copy files.

These numbers 1-5 are used later in the [SourceDisksFiles]
section for each file listed to indicate where each file
should be found. So the numbers serve as a very short
directory identifier.

The first parameter (goes before the first comma) and third
parameter (goes between the 2nd and 3rd commas) are always
empty (their use is not even documented!). The second
parameter is a comment that show up during .CAB file
creation and installation. The last parameter is the
fully qualified path in which to find files.

IMPORTANT: Do not end the directory name with a backslash
because the .CAB Wizard takes this to mean the
next line should be added to the end.

In first statement above, the directory identifier 1 is
set up for the "Common files", which are to be found in
the current directory '.' - which is the current directory
at the time that the Cab Wizard tool is run. If you look
in the [SourceDisksFiles] section, you'll see that the
directory identifier 1 is used for 'etscheck.lic' and any
other file that should be found in the current directory.

In the second statement statement, the directory identifier
2 is set up for the "Windows fonts" which are found in the
Windows NT/2000 font directory. If you look in the
[SourceDisksFiles] section, you'll see that the directory
identifier 2 is used for font file 'lucon.ttf'.

[SourceDisksNames.XXXXX] - There are multiple sections of this type - usually
one for each [CEDevice.XXXXX] section that is defined. Because
each processor / Windows CE combination requires the creation
of different .DLL and .EXE files, then each of these sections
points to a different source directory in which to find the
appropriately built .DLL and .EXE.

For example, in DCCLIENT.INF you'll see that [SourceDisksNames.IMEC700]
includes the following statements:

3 = ,"IMEC700 files",,IMEC700
4 = ,"VB Runtimes",,"g:\wincetools\wce300\MS Pocket PC\Runtimes\arm"
5 = ,"VB Controls",,"g:\wincetools\wce300\MS Pocket PC\Controls\arm"

Directory identifier 3 specifies the IMEC700 directory
relative to the current directory. Directory identifiers
4 and 5 specify where to find the Visual Basic product files
that are installed as part of the Microsoft eMbedded Visual
Toolkit SDK for the MS Pocket PC. Note that the last part of
these directory paths is 'arm' which is for the Intel StrongARM
processor - which is the processor that the Intermec 700 uses.
In [SourceDisksNames.IMEC6651], the last part of these directory
paths is 'mips' which is for the Toshiba MIPS processor used by
the Intermec 6651.

Note you can list one or more directory identifiers in these
sections for anticipated later use - even if currently no files
will be used from that directory.

As is shown above, the sample DCCLIENT.INF references the
directory g:\wincetools\... as the location to find the
Visual Basic .DLLs. This is the directory on our test
system where the Microsoft eMbedded Visual Toolkit SDKs
were installed. On your system this directory name
will more than likely be different. By default,
installation of the SDKs will be to C:\Windows CE Tools.

[SourceDisksFiles] - This section works in conjunction with all of the
sections of the type [SourceDisksFiles.XXXXX] to
specify where each individual file is located by
associating each with one of the previously defined
directory identifiers (1-5 in this case). In the
default DCCLIENT.INF, the following statements are in
this section (some of which may be commented out):

etscheck.lic = 1
emulator.ini = 1
logfile.log = 1
logfile.ndx = 1
etspt.exe = 3
etspt.dll = 3

; Fonts
lucon.ttf = 2

All files in this section are usually also listed in one of
the [Files.YYYYY] sections later in the .INF file. The job of
the [SourceDisksFiles] and [SourceDisksFiles.XXXXX] sections
is simply to specify where each file should be found. But
the job of the [Files.YYYYY] sections is to specify which
files will be included in the .CAB file (in conjunction with
the 'CopyFiles' statements in the [DefaultInstall] and
appropriate [DefaultInstall.XXXXX] sections). Therefore it is
possible to have entries in the [SourceDisksFiles] and
[SourceDisksFiles.XXXXX] sections that are commented out
in or are not included in any of the [Files.YYYYY]
sections. Therefore, if you want to temporarily remove
a file from being included in a .CAB file, you can comment
it out in the appropriate [Files.YYYYY] section but do not
have to comment it out in the [SourceDisksFiles] or
[SourceDisksFiles.XXXXX] sections.

However, the Cab Wizard does expect to find each file listed
in this section - based on the associated directory identifier.
So every file listed in the [SourceDiskFiles] section must
be found even if it will not be included in the .CAB file.

If there are files that exist for some .CAB files and not
for others, they should be specified in the appropriate
[SourceDisksFiles.XXXXX] sections as described below.

In the example above, 4 files are associated with directory
identifier 1 which is defined to be the current directory
in the [SourceDisksNames] section. The font file, lucon.ttf,
is associated with directory identifier 2 which is also
defined in the [SourceDisksNames] section.

But the executable files, etspt.exe and etspt.dll, are
associated with directory identifier 3 which actually
indicates a different directory depending on which .CAB
file is being built. You'll note that 3 is defined in each
of the [SourceDisksNames.XXXXX] sections to be a different
directory because these executables have to be built
differently based on the processor and Windows CE version.

[SourceDisksFiles.XXXXX] - There are multiple sections of this type - usually
one for each [CEDevice.XXXXX] section that is defined. Every
one of these sections does not have to list any files; some
could be set up just as placeholders.

Each of these sections is used in conjunction with the
common [SourceDisksFiles] section to tell the Cab Wizard
where to find individual files - based on the associated
directory identifier.

These sections should be used to list files that would
not be found for every kind of .CAB file that can be
built. Using the default DCCLIENT.INF as an example,
notice that the section [SourceDisksFiles.IMEC700] lists
the following files:

pvbdecl.dll = 4
MSCEFile.dll = 5
ceconfig.ini = 1
ceconfig.vb = 1
etsuser.dll = 3

The files with directory identifiers 3, 4 and 5 are
located in different places based on the definition
of each of these directory identifiers in the
matching [SourceDisksNames.XXXXX] section - in this
case [SourceDisksNames.IMEC700]. But in the
section [SourceDisksNames.IMEC600], directory
identifiers 4 and 5 are not even defined because
the toolkit for the Intermec 600 does not include
the Visual Basic DLLs.

The default DCCLIENT.INF does not list any other
[SourceDisksFiles.XXXXX] sections except for the
one for [SourceDisksFiles.IMEC700]. But you
could have one for each XXXXX section in the .INF
file.

[DestinationDirs] - This section is used to specify where on the
target device files and shortcuts should go during
.CAB file installation. There is only one of
these sections. Therefore all .CAB files created
from this .INF file will install their files to
the same place on the target device.

For some reason the .CAB file syntax does not allow
for sections of the type [DestinationDirs.XXXXX]
even though that would seem to follow as the
logical place to specify the destination for
files that apply only to specific devices.

One statement in this section usually defines
the 'DefaultDestDir' in order to cover any
[Files.YYYYY] and [Shortcuts.ZZZZZ] sections that
are not explicitly listed here.

In the default DCCLIENT.INF, the following
statements are listed:

Shortcuts.All = 0,%InstallDir%
Files.Client = 0,%InstallDir%
Files.ClientData = 0,%InstallDir%
Files.Fonts = 0,%CE15% ; \Windows\Fonts
DefaultDestDir = 0,%InstallDir%

;Uncomment the following if including the CE Config Tool
;Shortcuts.CfgTool = 0,%InstallDir%
;Files.CfgTool = 0,%CE2% ; \Windows

;Uncomment the following if including the full screen files
;Files.FullScreen = 0,%InstallDir%

The first parameter to the right of the equal sign
is always 0. The second parameter specifies the
directory on the target system in which to install
the files that are listed in the [Files.YYYYY] or
[Shortcuts.ZZZZZ] section to the left of the equal
sign. (A .lnk file is created for each shortcut).

Most of the statements reference the %InstallDir%
variable that is defined at the top of the file.
However, all files listed in [Files.Fonts] will
be installed to the Windows CE fonts directory -
as defined by the directory identifier %CE15%.
Likewise, all files associated with the IBM CE Config
Tool (those listed in [Files.CfgTool] will be
installed to the \Windows directory.

Note that because the 'DefaultDestDir' is defined
to be the same as most of the statements, this
section could be reduced to just 3 lines (DefaultDestDir,
Files.Fonts and Files.CfgTool). If you do not have
a 'DefaultDestDir' statement and you do not include
one of the [Shortcuts.ZZZZZ] or [Files.YYYYY] sections
that is defined in the file, you'll get an error
when running the Cab Wizard.

In addition, any Files.YYYYY or Shortcuts.ZZZZZ
sections that are referenced in this section must be
part of the the [DefaultInstall] or the appropriate
[DefaultInstall.XXXXX] section or an error will
result when running the Cab Wizard. That is why
Shortcuts.CfgTool, Files.CfgTool and Files.FullScreen
are commented out above. These sections do not
apply to the IMEC600, for example, and if
uncommented, they would result in an error when
building the IMEC600 .CAB file.

[Shortcuts.All] - This section is one of two that defines certain
shortcuts that should be created on the target
device during installation of the .CAB file. This
[Shortcuts.All] section is specified as part of the
[DefaultInstall] section in the 'CEShortcuts' statement.
Because it is part of the [DefaultInstall] section, it
applies to all .CAB files that are created from this
.INF file.

The default DCCLIENT.INF contains the following
statements:

%AppName%,0,etspt.exe,%CE17% ; Put it in the Start Menu
%AppName%,0,etspt.exe,%CE4% ; Put it in the Startup folder
%AppName%,0,etspt.exe,%InstallDir% ; Backup shortcut in install dir

The first parameter is the text for the short cut
that will appear on the target device. In all cases
above, %AppName% is used. This is defined to be
"DCConnect Client" in the [CEStrings] section at
the top of the .INF file. So the first statement,
which adds an entry to the Start Menu, will add a
an entry called "DCConnect Client" to the
Start Menu.

The second parameter is 0 if the shortcut points to a
file. It is non-zero if it is a shortcut to a folder.

The third parameter is the name of the file that the
shortcut will open. This file must be listed in one
of the [Files.YYYYY] sections. In all three cases
the shortcut opens the DCConnect Client executable.

The last parameter specifies where the shortcut will
go. This is the only parameter that is different
between the three statements.

- The first statement adds the shortcut to the
directory defined by the Windows CE directory
identifier %CE17%. For most devices this is
the Start Menu. But in some cases this is
the Favorites menu (Intermec 600).

- The second statement adds a shortcut to the
%CE4% directory which is the Windows CE
Startup folder. This causes the DCConnect
Client to be started whenever the device
is rebooted.

- The third statement adds a backup of the
shortcut to the directory into which the
DCConnect Client files are installed.

Note that this section did not have to be called
[Shortcuts.All]. The 'All' part could have been
anything as long as all occurrences of it are
consistent.

The installation of the .CAB file on an Intermec 5020
does not seem to acknowledge the %CE17% identifier
for adding a shortcut to the Start Menu. We found
that you can use %CE11% to add the Shortcut to the
Programs folder off the Start Menu. But even though
that is successful, the name that shows up on that
menu is the name of the executable 'etspt.exe'
instead of the first parameter.

[ShortCuts.CfgTool] - This is an additional list of shortcuts that
are only needed for the creation of certain .CAB
files. Notice that ShortCuts.CfgTool is only part
of the following sections:

[DefaultInstall.IMEC700]
[DefaultInstall.Symbol81xx]
[DefaultInstall.HHP7400]

in the default DCCLIENT.INF file (usually commented
out). The statements in [ShortCuts.CfgTool] are:

CE Config Tool,0,ceconfig.vb, %CE17% ; Put it in the Start Menu
CE Config Tool,0,ceconfig.vb, %InstallDir% ; Put it in the install dir

The first adds to the Start Menu (or Favorites
Menu) a shortcut for opening the IBM CE Config
Tool Visual Basic executable. The second adds
a backup of the same shortcut to the installation
directory.

[Files.YYYYY] - There are usually multiple sections of this type.
Each lists a particular set of files that could be
included in the various .CAB files that can be
created from the .INF file.

Files must be split into different sections when
either of the following is true:

- Files must be installed into different directories
on the target device

- Some .CAB files will include certain sets of files
and other .CAB files will not.

The default DCCLIENT.INF includes 5 different
[Files.YYYYY] sections for the following reasons:

- [Files.Client] - These are the DCConnect Client
executables. These could actually be combined
with the files listed in [Files.ClientData]
because all .CAB files include them and they
all install to the same place for the devices
handled by this .INF file.

However, there may be cases where the data files
and executables have to be in separate directories.
This is actually the case for Intermec 5020
terminals with version 2.11 of Windows CE (not
handled by this .INF file). For that terminal,
executables have to go into the \Windows directory
which is not non-volatile storage. The data
files were set up in non-volatile storage so
that transactions would not be lost in the
event of a terminal reset or total loss of
battery power.

- [Files.ClientData] - These are the data files
read or created by the DCConnect Client. See
the previous bullet for explanation as to why
these are separated from the Client executables.

- [Files.Fonts] - Although all .CAB files include
the file(s) listed in this section, these file(s)
are installed to the Windows CE fonts directory
(as is defined in the [DestinationDirs] section).

- [Files.FullScreen] - The file(s) in this section
are only set up to be included for some of
the possible .CAB files (e.g. IMEC700). They are
installed to the same directory as the Client
(as is defined in the [DestinationDirs] section).

- [Files.CfgTool] - These are the file(s) that
are part of IBM's CE Config Tool which was
created with Microsoft's eMbedded Visual
Basic. All files in this section are installed
into the \Windows directory. And these files
are not installed for all .CAB files.

If you look back at the [DefaultInstall] section
you'll see that the 'CopyFiles' statement
references the first 3 of these [Files.YYYYY]
sections. Therefore they are a part of all .CAB
files created from this .INF file. The other
two [Files.YYYYY] are only part of a couple of
the device-specific [DefaultInstall.XXXXX]
sections.

To temporarily exclude a file from the creation
of .CAB files, you can simply comment it out in
the appropriate [Files.YYYYY] section. You do
not have to also comment it out in the
[SourceDisksFiles] or [SourceDisksFiles.XXXXX]
section. Only if the file does not actually
exist on the source PC will it have to be
commented out in those sections.

Four parameters make up a statement in one of
the [Files.YYYYY] sections:

- The first is the file name without any path
specified (files are found on the build PC based
on the [SourceDisksFiles] and
[SourceDisksFiles.XXXXX] sections. Files are
installed on to the target device based on the
[Files.YYYYY] section they are in and based
on the [DestinationDirs] section.

- The second parameter is usually blank - unless
the source file name is different from the
target file name. In this case, the second
parameter is the source file name. You must
also make sure the appropriate [SourceDisksFiles]
or [SourceDisksFiles.XXXXX] section uses the
source file name.

- The third parameter is always blank.

- The optional fourth parameter is a flag, entered
as a hex value, that specifies certain things
to take into account when copying the file:

0x00000001 - Warn user if an attempt is made to
skip a file after an error has
occurred.
0x00000002 - Do not allow a user to skip
copying this file.
0x00000010 - Do not overwrite the file if it
already exists in the destination
directory.
0x00000400 - Only copy the file if it already
exists in the destination directory.
0x20000000 - Do not copy file if the target
file is newer.
0x40000000 - Ignore date while overwriting
the target file.
0x80000000 - Create a reference when a shared
file is counted.

These flags can be combined if necessary. For
example to create a shared reference for a file
that cannot be skipped use: 0x80000002.

[RegSettings.All] - This section defines what registry updates
must be made during the installation of the
.CAB file. You may have more than one
[RegSettings.RRRRR] sections - each with
a unique .RRRRR in the name.

RegSettings.All is referenced in the section
[DefaultInstall] for the 'AddReg' statement.
If you had an additional [RegSettings.RRRRR]
section that only applied to a certain
device-specific [DefaultInstall.XXXXX]
section, then you would add an 'AddReg'
statement to that [DefaultInstall.XXXXX]
section and reference the [RegSettings.RRRRR]
section.

The default DCCLIENT.INF file includes the
following statement in this section:

HKLM,"Software\IBM\%AppName%",path,0x00000000,%InstallDir%

The parameters are as follows:

- The first parameter is one of HKCR, HKCU or
HKLM which are short for HKEY_CLASSES_ROOT,
HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE
respectively. This specifies the registry
root location.

- The second parameter specifies the subkey name.
In the statement above, part of the subkey name
is the %AppName% which is defined to be
'DCConnect Client' in the [CEStrings] section.

- The third parameter is the name of the value
to be set. If empty, the '(default)' registry
value name is used.

- The fourth parameter is a flag that specifies
what type the value is. It can be one of the
following:

0x00000000 = REG_SZ (null-terminated string)
0x00010000 = REG_MULTI_SZ (concatenated strings with
extra null at the end)
0x00000001 = REG_BINARY
0x00010001 = REG_DWORD

You can also combine any of the above with
0x00000002 to specify that if the registry
key already exists it should not be overwritten.

- The last parameter is the actual value to be
stored. For REG_MULTI_SZ, the different
strings should be separated by commas. For
REG_BINARY, this must be a list of numeric
values separated by commas, one byte per field,
and must not use the 0x hexadecimal prefix.
For REG_DWORD, plus and minus signs can be
used and the number can be specified as hex
or decimal.

For the strings specified for either REG_SZ
or REG_MULTI_SZ, the variables %InstallDir%
and %AppName% can be used as all or part of
the string value - but not for all devices.
For the Intermec 600, substitution is not
performed for these variables. Therefore
you have to literally specify the entire
string as it should appear in the registry.
For example, the statement above would have
to be specified as follows for the Intermec 600:

HKLM,"Software\IBM\%AppName%",path,0x00000000,\Storage_Card\DCConnect Client

Thel statement in the [RegSettings.All] section
will create the key:

\HKEY_LOCAL_MACHINE\Software\IBM\DCConnect Client

and create a value named 'path' of type REG_SZ
associated with that key and assign it the value:

\Storage Card\DCConnect Client

When the DCConnect Client starts up, it looks for
this registry key to figure out where its data
files are located.

Make sure you understand the meaning of all of the sections in the .INF file before making
any changes. Additional comments are at the top of the file which describe what sections
of the files might need to be changed.

If you want to recreate a .CAB file and have made the appropriate changes to the .INF
file, you can use the MAKECAB.BAT file, which is provided with the DCConnect Client
product, to run the Cab Wizard against the .INF file.

Following are a couple notes about how to use MAKECAB.BAT and what it does:

- MAKECAB.BAT uses the environment variable SDKROOT to locate
the Cab Wizard tool. SDKROOT must be set to point to the
root directory where the SDKS are installed (such as for
MS Pocket PC, Intermec 600, LanPoint CE, ...). By default
this would be "C:\Windows CE Tools" but you may have changed
that when you installed the SDKs. On our test system we
changed it to G:\WinCETools.

SDKROOT is NOT set up automatically by the installation of
the SDKs. Therefore you will need to set it up yourself
(using the System settings in the Control Panel) or you
could change MAKECAB.BAT by replacing %SDKROOT% with the
appropriate path. It is recommended that you set up the
environment variable rather than changing the file because
installation of future CDs and fix packs will replace
this file in the installation directory.

- MAKECAB.BAT is set up to take two parameters: the .INF file name (without the .inf
extension) and an indicator of which device section to process. The second parameter
must be one of the XXXXX values that is used in any of the [CEDevice.XXXXX] sections
of the .INF file. For example, to build a .CAB file for the IMEC700 sections of
DCCLIENT.INF, you would run the following at a command prompt:

makecab dcclient imec700

If the device section and the .INF file name are the same, you can pass a single
parameter. For example, if you had copied dcclient.inf to imec700.inf and wanted
to build a .CAB file for the IMEC700 sections from that file, you could run the
following:

makecab imec700

If you look at the directory where the Client files are installed, you'll see
a SAMPLE directory under every Windows CE parent directory (e.g. IMEC600, IMEC700,
LANPTCE, ...). In each SAMPLE directory is a .INF file with a name that
matches the device (IMEC600.INF, IMEC700.INF, ...). The way these are set up
allows you to run MAKECAB.BAT with a single parameter.

- The Cab Wizard tool will generate a .CAB file using a name that combines the
.INF file name (without the .INF extension) and the XXXXX value passed in to
specify the device/cpu. So if you ran 'makecab dcclient imec700' the Cab
Wizard tool creates dcclient.imec700.cab. And if you ran 'makecab imec700'
the Cab Wizard tool creates imec700.imec700.cab.

Because these generated names can be a little unwieldy, MAKECAB.BAT will
rename the generated .CAB file to elimate the .INF file part. So for the
generated name dcclient.imec700.cab, MAKECAB.BAT would change it to
imec700.cab. And for imec700.imec700.cab, MAKECAB.BAT would also change it
to imec700.cab.

In a nutshell, when MAKECAB.BAT is done, it will take the last parameter
provided to it and add the .CAB extension.

- When MAKECAB.BAT calls the Cab Wizard, it tells it to write any warnings
or errors to MAKECAB.OUT. After the Cab Wizard is done and MAKECAB.BAT
tries to rename the .CAB files, MAKECAB.BAT types out the contents of
MAKECAB.OUT so that you can see if the Cab Wizard generated any warnings
or errors.

Be sure to inspect MAKECAB.OUT for errors that prevent the .CAB file from
being built. It is not unusual to get warnings even when a proper .CAB
file is generated. For example, the following warning is harmless:

Warning: Section [DestinationDirs] key "Files.Fonts" is not using the string "%InstallDir%"

- The CAB Wizard utility requires the files cabwiz.ddf and makecab.exe to
be in the same directory as 'cabwiz.exe'. This should be taken care of
automatically when the SDKs for the Microsoft eMbedded Visual Toolkit
are installed.

Reinstalling the DCConnect Client on a Windows CE Device
--------------------------------------------------------
If during the reinstall of a DCConnect Client .CAB file you get errors about files
being in use and the installation is unable to continue, before retrying the
install, try uninstalling the Client as is described below in the section
Uninstalling the DCConnect Client on a Windows CE Device.

Uninstalling the DCConnect Client on a Windows CE Device
--------------------------------------------------------
If the DCConnect Client is installed using a .CAB file that was created as described
in Building a .CAB File to Install the Client on a Windows CE Device.
then the Windows CE 'Remove Programs' function should be able to uninstall the Client
after doing one possible manual operation. If the .CAB file installed a font file
such as LUCON.TTF and the terminal has been rebooted causing Windows CE to find and
register that font file, then an error will be given during the uninstall process when
trying to remove the font file. The error will state that the file is in use and the
uninstall will not complete. In order for the uninstall to be successful, the font file
must first be deleted manually and then the 'Remove Programs' operation should be done.

On a Pocket PC Device, the Remove Programs icon can be found by choosing Settings from
the Start button and then going to the Settings tab. On the Intermec 600 with version
2.12 of Windows CE, the Remove Programs icon is on the Control Panel which can be
accessed by choosing Settings from the Start Menu.

Starting the Client on a Windows CE Device
------------------------------------------
If the DCConnect Client is installed on the Windows CE device using
a .CAB file that was created as described above in the section
Building a .CAB File to Install the Client on a Windows CE Device
then there will be a shortcut on the Start Menu for starting the
"DCConnect Client". On some devices, this shortcut is created on
the Favorites menu or Programs Menu under the Start Menu instead of
directly on the Start Menu.

The installation of the .CAB file should also create a shortcut
in the Windows Startup folder. This will cause the Client to be
started automatically whenever the device is rebooted.

On Windows CE only, the Client is designed such that if a second
copy is started, it locates the first copy and brings it to the
foreground and then the second copy ends itself. This was done
because on Windows CE, once another application moves to the
foreground, bringing the Client back to the foreground requires
going through the following steps:

Start button -> Settings option -> System tab -> Memory icon ->
Running Programs tab -> select DCConnect Client -> Activate button

But since the second copy locates the first, all you have to do
to find the running copy is to click on the DCConnect Client
option on the Start Menu (or the Client's bar code mini-icon
at the top of the start menu).

Building CFRs for Windows CE Devices
------------------------------------
For DOS-based terminals running the DCConnect Client and the original IBM 752x
terminals, CFRs were built as 16-bit .EXE files. However, when the Client is
running on a Windows CE device, CFRs must be built as Windows CE DLLs. In
addition, if the building of your CFR requires linking any libraries that
weren't part of the C compiler, these libraries must also be rebuilt as
Windows CE libraries.

Note: Even CFR DLLs and libraries that were built for the Client running on
Windows 95/98/Me/NT/2000/XP/7/Server cannot be used on a Windows CE device.

The CFR source files (.C and .H files) that were used when building DOS CFR
exectuables should not have to change when you want to create CFR DLLs for
Windows CE from that same source.

Note: Because DOS-based devices, Windows devices and Windows CE devices all use
different CFR executables, when configuring terminals using the DCConnect
User Interface, terminals using different CFR executables will have to be
in different 'function groups' - even if all of the rest of the configuration
(transaction programs, validation files, ...) are the same.

During our testing we built our test CFRs using the Microsoft eMbedded
Visual Toolkits and associated device-specific SDKs. For more information
about acquiring and installing the toolkits and SDKs, please see
Using Microsoft eMbedded Visual Toolkits to Build CFRs for Windows CE Devices.

As was noted in the previously referenced section, there are many different
processor types / Windows CE version combinations for the various Windows CE
devices available from terminal vendors. And for each of these combinations
a separate CFR DLL has to be built. So a CFR built for an Intermec 700
terminal (Intel StrongARM processor, Windows CE 3.0) would not run on an
Intermec 600 terminal (AMD X86 processor, Windows CE 2.12) or an Intelligent
Instrumentation LanPoint CE terminal (AMD X86 processor, Windows CE 3.0).

Therefore if you are using different models of Windows CE device (e.g. Intermec
600 and Intermec 700) you will have to create different CFR executables for
each model and have different function groups in the DCConnect User Interface
for each model. But if the models you were using all had the same processor /
Windows CE version (e.g. Intermec 700 and Symbol 81xx), the same CFR
executable could be used for all terminals and all could use the same
DCConnect function group (provided the rest of the terminal configuration
was the same - except of course the terminal address).

There is one other thing to be aware of regarding the toolkit(s) used to
build CFRs. CFRs that are to run on a device with Windows CE 3.x or
earlier must be built with Version 3.0 of Microsoft's C++ compiler. Most
of the supported Windows CE devices fall into this category.

But CFRs that are to run on devices with Windows CE .NET (4.x) or higher
must be built with Version 4.0 of Microsoft's C++ compiler. Devices that
fall into this category include:

- Intermec CK30
- Intermec CV60
- Symbol MC90xx

We have included with the Client the necessary header files,
libraries, make files, project files and workspace files for building
CFRs for the various flavors of Windows CE devices listed in
Using the DCConnect Client on Windows CE Devices.

Make files, project files and workspace files that are intended to be
used with Version 3.0 of the Microsoft eMbedded C++ compiler will
have 'ce' in the name. For example:

- cfrsmpce.vcw
- cfrsmpce.vcp
- cfrsmpce.vcn
- cfrutlce.vcw

Make files, project files and workspace files that are
intended to be used with Version 4.0 of the Microsoft eMbedded C++
compiler will have '40' in the name instead. For example:

- cfrsmp40.vcw
- cfrsmp40.vcp
- cfrsmp40.vcn
- cfrutl40.vcw

Regardless of the version of the compiler used, the .DLL or .LIB
files have all been set up to have 'ce' in the name. For example:

- cfrapice.lib
- cfrutlce.lib
- cfrsmpce.dll

To compile a CFR using the Microsoft eMbedded Visual Toolkit project and
workspace files provided, follow the steps below:

If this has already been set up then you can skip to step 5 below.
Otherwise continue with step 2 in order to copy the necessary
files and to set up the CFRTOOLS environment variable.

2) First create a directory into which the CFR files can be copied. If
you are using the PC that is running the DCConnect Server, then create
the directory:

DCCLIENT\CFRTOOLS

under the directory where DCConnect is installed (e.g. C:\DCCONN).

3) Copy all files from the CFRTOOLS directory where the Client is
installed to the directory you created (e.g. C:\DCCONN\DCCLIENT\CFRTOOLS).

4) Using the System icon in the Windows Control Panel folder, set up
the environment variable CFRTOOLS to point to the directory that
you created (e.g. C:\DCCONN\DCCLIENT\CFRTOOLS).

5) Of all the files that are installed to the %CFRTOOLS% directory, the
following files are required for building Windows CE CFRs:

cfrapi24.h - Header file included by all CFR source
cfrwin32.h - Header file required for Windows CE CFRs
(automatically included by cfrapi24.h
when building Windows CE CFRs)

ck30\cfrapice.lib - CFR API library for Intermec CK30
cv60\cfrapice.lib - CFR API library for Intermec CV60
imec600\cfrapice.lib - CFR API library for Intermec 600
imec700\cfrapice.lib - CFR API library for Intermec 700 and compatible devices
such as Symbol PDT81xx, HandHeld Products 7400.
imec5020\cfrapice.lib - CFR API library for Intermec 5020 (CE 3.0)
imec6651\cfrapice.lib - CFR API library for Intermec 6651
lanptce\cfrapice.lib - CFR API library for Intelligent
Instrumentation LanPoint CE
sym90xx\cfrapice.lib - CFR API library for Symbol MC 90xx (and MC 91xx)
x86emdbg\cfrapice.lib - CFR API library for the Pocket PC
Emulation environment

These are the header files and CFR API library files needed for
building the various flavors of Windows CE CFRs.

6) Before proceding, it is suggested that you create a separate build
directory for your own CFR source (it can be, and probably should
be, the same directory that is used to build your DOS and 32-bit
Windows CFRs). This should be different from the directory that
the environment variable CFRTOOLS points to. This example will
use C:\MYCFRS for the build directory.

7) One of the files in the %CFRTOOLS% directory is CFRSMP24.ZIP which
is the sample CFR package. This package includes Microsoft eMbedded
Visual Toolkit (both versions) workspace and project files - as well
as the source and makefiles for the sample CFRs.

Copy CFRSMP24.ZIP from the %CFRTOOLS% directory to C:\MYCFRS.

cfrsmp24.c - True source for the CFR (included by cfrsmp32.c)
cfrsmp32.c - Wrapper file for CFRSMP24.C that allows us to create
CFRSMP32.OBJ

cfrsmpce.vcw - Version 3.0 Microsoft EMbedded Visual C++ workspace file
cfrsmpce.vcp - " " " " " project file
cfrsmpce.vcn - " " " " " generated make file

cfrsmp40.vcw - Version 4.0 Microsoft EMbedded Visual C++ workspace file
cfrsmp40.vcp - " " " " " project file
cfrsmp40.vcn - " " " " " generated make file

mycfrs.vcw - Blank workspace file for adding your own CFR projects

nmck30.bat - Builds from the command line, the Intermec CK30 sample CFR
nmcv60.bat - Builds from the command line, the Intermec CV60 sample CFR
nmi600.bat - Builds from the command line, the Intermec 600 sample CFR
nmi700.bat - Builds from the command line, the Intermec 700 sample CFR
nmi5020.bat - Builds from the command line, the Intermec 5020 sample CFR
nmi6651.bat - Builds from the command line, the Intermec 6651 sample CFR
nmlptce.bat - Builds from the command line, the Inteligent Instrumentation
LanPoint CE sample CFR
nms90xx.bat - Builds from the command line, the Symbol MC 90xx (and MC91xx) sample CFR
nmx86em.bat - Builds from the command line, the sample CFR that can run
in the Pocket PC Emulation environment

ck30\cfrsmpce.dll - Sample CFR built for Intermec CK30
cv60\cfrsmpce.dll - Sample CFR built for Intermec CV60
imec600\cfrsmpce.dll - Sample CFR built for Intermec 600
imec700\cfrsmpce.dll - Sample CFR built for Intermec 700
imec5020\cfrsmpce.dll - Sample CFR built for Intermec 5020 (CE 3.0)
imec6651\cfrsmpce.dll - Sample CFR built for Intermec 6651
lanptce\cfrsmpce.dll - Sample CFR built for Intelligent
Instrumentation LanPoint CE
sym90xx\cfrsmpce.dll - Sample CFR built for Symbol MC 90xx (and 91xx)
x86emdbg\cfrsmpce.dll - Sample CFR built for the Pocket PC
Emulation environment

cfrutl24.h - Header file for utility functions

ck30\cfrutlce.lib - CFR utility library for Intermec CK30
cv60\cfrutlce.lib - CFR utility library for Intermec CV60
imec600\cfrutlce.lib - CFR utility library for Intermec 600
imec700\cfrutlce.lib - CFR utility library for Intermec 700
imec5020\cfrutlce.lib - CFR utility library for Intermec 5020 (CE 3.0)
imec6651\cfrutlce.lib - CFR utility library for Intermec 6651
lanptce\cfrutlce.lib - CFR utility library for Intelligent
Instrumentation LanPoint CE
sym90xx\cfrutlce.lib - CFR utility library for Symbol MC 90xx (MC91xx)
x86emdbg\cfrutlce.lib - CFR utility library for the Pocket PC
Emulation environment

The sample CFR source file CFRSMP24.C includes the utility header file
CFRUTL24.H. And the appropriate 'flavor' (Intermec 700, Intermec 600, ...)
of cfrutlce.lib is linked when building each flavor of the sample CFR.

10) Copy your CFR source (and any include files) into C:\MYCFRS.

11) Now copy the appropriate sample project file CFRSMPCE.VCP (or CFRSMP40.VCP)
and give it a name that is appropriate for your CFR (perhaps based on a plant
location, a customer, or specific function it performs). This
example will use NEWCFR.VCP:

copy cfrsmpce.vcp newcfr.vcp

Note: If you will need build a CFR that requires version 3.0 of the
compiler (e.g. Symbol PDT 81xx) and you also need to build a
CFR that requires version 4.0 of the compiler (e.g. Symbol MC 90xx)
then you will have to create separate project files for use
by each compiler. Furthermore, you will have to create separate
workspace files for each compiler. In this case you should
name each project and workspace file so that it is clear which
compiler it is to be used with. For example:

copy cfrsmpce.vcp newcfr30.vcp
copy mycfrs.vcw mycfrs30.vcw

copy cfrsmp40.vcp newcfr40.vcp
copy mycfrs.vcw mycfrs40.vcw

The workspace file itself does not contain any specific
information that applies to one version of the compiler or
another. But each will reference a project file that can
only be used with one version of the compiler.

12) Now use Notepad or your favorite editor to make two global changes to
newcfr.vcp:

- Change all uppercase occurrences of 'CFRSMPCE' (or 'CFRSMP40') to the
name that you picked (e.g. 'NEWCFR').
- Change all lowercase occurrences of 'cfrsmpce' (or 'cfrsmp40') to the
name that you picked (e.g. 'newcfr').

Now save the project file.

13) One of the files that was part of the CFRSMP24.ZIP that you expanded
is MYCFRS.VCW which is a blank workspace file. We will add the new
project file to this workspace. You can add as many projects to
this workspace as you need.

Start the appropriate version of Microsoft eMbedded Visual Toolkit and
select the 'Open Workspace' option from the File pull-down. Select mycfrs.vcw
from your CFR build directory (e.g. c:\mycfrs).

14) Click mouse button 2 on the Workspace icon in the File View window
on the left and select 'Insert Project Into Workspace ...'.

On the resulting pop-up, select the .VCP file that you created
(e.g. newcfr.vcp).

Under the workspace name you will now see the project name
(e.g. 'newcfr files') with a plus sign next to it.

15) Click the plus sign to reveal 'Source Files', 'Header Files' ...

Then click the plus sign next to 'Source Files'. This will
show a single file, cfrsmp32.c, which is the sample CFR source
file. Click on this file name to highlight and then press the
delete key to delete it.

16) Click mouse button 2 on the 'Source Files' folder and select
the option to 'Add Files to Folder...'. This will bring up
a dialog box from which you can select one or more source
files. Hold down the control key and click all source files
that should be added. (If there is only one file to add, you
don't need to hold down the Control key).

17) If you have any project specific header files (.h files other
than cfrapi24.h, cfrutl24.h, cfrwin32.h) repeat step 14 with
the 'Header Files' folder and add those other .h files.

18) If you were creating a project file from scratch you'd have
to go into the project settings and set the proper compile
and link options, target directories, output file names, ...

However, since you start with the sample .VCP file, all of
these things are already set up. You will be able to build
all the different flavors of CFR that were set up in the
project file - provided you have installed the proper SDKs
as directed to at the start of this section.

The CFR name that is created in all cases is NEWCFR.DLL (or
whatever the name of your project is). However each flavor
is generated in its own subdirectory. For example, if using
version 3.0 of the compiler:

imec600\newcfr.dll
imec700\newcfr.dll
imec5020\newcfr.dll
imec6651\newcfr.dll
lanptce\newcfr.dll
x86emdbg\newcfr.dll

or if using version 4.0 of the compiler:

ck30\newcfr.dll
cv60\newcfr.dll
sym90xx\newcfr.dll

19) Each 'flavor' of CFR must be built separately. To select a
particular 'flavor' you must first set the Active Platform
and then set the Active Configuration for that platform

Choose the 'Set Active Platform' option from the 'Build'
pull-down menu and select the appropriate platform from
the list. For example, if building for the Intermec 700
or Intermec 6651, choose 'Pocket PC' or if building for
the Intelligent Instrumentation LanPoint CE choose
'LANpointCE_12'.

Then choose the 'Set Active Configuration' option from the
'Build' pull-down menu and select the appropriate
configuration from the list. For example:

newcfr - Win32 (WCE ARM) Intermec 700 Release
newcfr - Win32 (WCE MIPS) Intermec 6651 Release
newcfr - Win32 (WCE x86) LanPoint CE Release

newcfr - Win32 (WCE ARMV4I) Intermec CK30 Release
newcfr - Win32 (WCE ARMV4) Symbol MC90xx Release

the choices available to you will only be those that are
appropriate for the platform that you selected.

Note: The use of 'Intermec 700', 'Intermec 6651',
'LanPoint CE', ... in the configuration name is not
what you'd normally see for choices of platform if you
created your project from scratch. These were set
up in the sample project file using 'Configurations'
option from the 'Build' pull-down menu. See below
for more information about how to do this.

The active platform and active configuration can also be
set using the drop-down boxes towards the top of the screen.
You should see that the leftmost drop-down box in one row
shows the active project (e.g. newcfr). If you move the
mouse button over this drop-down box, flyover text should
pop-up that says 'Select Active Project'. To the right
of this drop-down box is the drop-down box to select the
active platform and to the right of that is the drop-down
box to select the active configuration.

20) Once you have set the active platform and configuration you
can press F7 or choose 'Build newcfr.dll' from the 'Build'
pull-down menu to start the compile. The CFR DLL (e.g newcfr.dll)
will be created in the appropriate subdirectory based on
the active platform and configuration:

... Intermec 600 Release IMEC600
... Intermec 700 Release IMEC700
... Intermec 5020 Release IMEC5020
... Intermec 6651 Release IMEC6651
... LanPoint CE Release LANPTCE
... Win32 (WCE x86em) Debug X86EMDBG

... Intermec CK30 Release CK30
... Intermec CV60 Release CV60
... Intermec Symbol MC90xx Release SYM90XX

In most cases your 16-bit CFR source can be recompiled into a DLL without any
changes. You may get a number of warning messages during the build that will
not cause any problems during run time. The messages are caused by mismatch
sizes of primitive types between the 16-bit and 32-bit systems. As an example,
'int' on 16-bit systems is two bytes in size while it is four bytes on 32-bit
systems.

Building More Than One 'Flavor' of a Windows CE CFR
---------------------------------------------------
If you need to build more than one flavor of CFR simply change
the active platform and/or configuration as described in the
second to last step in the previous section and then build the
new flavor of CFR as described in the last step in the
previous section.

Because the resulting CFR DLL name is the same in all case, just
in a different subdirectory, you will need to rename the CFR DLLs
before they are copied to the DCConnect Client CFR directory
(\DCCONN\CFR) for downloading to the Windows CE devices.

You can do this manually when copying the .DLLs to the DCConnect
Client directory or you can add 'Post-build' steps to the project
to do this automatically every time the CFR is build. Let's
assume you are creating CFRs for the following two configurations:

Win32 (WCE ARM) Intermec 700 Release
Win32 (WCE x86) LanPoint CE Release

We will therefore need to come up with unique CFR names for each
flavor - to be used in the \DCCONN\CFR directory. For example,
we could use the following:

CFR700.DLL
CFRLPTCE.DLL

IMPORTANT NOTE: Long names are not supported by DCConnect for CFRs;
you must use 8.3 format names.

Here are the steps for modifying the project settings (valid for
either version of the toolkit) to copy the compiled CFR DLLs to
these names, every time the CFR is built:

1) Once you've opened the MyCfrs workspace, choose 'Settings'
from the 'Project' pull-down menu and then click on the last
tab at the top called 'Post-build step'. (You may have to
use the right arrow button to scroll the tabs).

2) On the left side of the dialog, at the top, is a drop-down
box labelled 'Settings For:' which allows you to select a
configuration to which the changes should be made. To start
select:

Win32 (WCE ARM) Intermec 700 Release

3) Then double click on the first blank line under the heading
'Post-build command(s)' on the right side. An entry field
will open up that allows you to enter a command. In this
entry field, type a command similar to the following, based
on your CFR name:

copy imec700\newcfr.dll c:\dcconn\cfr\cfr700.dll

Then press Enter.

4) Now we must change the settings for the LanPoint CE.
So in the 'Settings For:' drop-down box on the left,
select the second configuration:

Win32 (WCE x86) LanPoint CE Release

5) Then back on the right double click on the first blank
line and enter the following command:

copy lanptce\newcfr.dll c:\dcconn\cfr\cfrlptce.dll

6) Click OK on the bottom right of the dialog and then choose
the 'Save All' option from the 'File' pull-down menu.

You should now be able to run the build again following the
last two steps in the previous section and the CFR DLLs will
be copied to the DCConnect \DCCONN\CFR directory.

Note: The DCConnect User Interface only checks for new CFRs
when it is started. Therefore if a new CFR is copied
into the DCConnect CFR directory while the User Interface
is already running, the User Interface must be shut down
and restarted in order for that CFR to be available to
assign to terminal configurations. (The DCConnect Server
does not have to be shutdown for this).

Building Windows CE CFRs from the Command Line
----------------------------------------------
You may want to be able to build your CFRs from the command
line rather than having to do it manually from the MS eMbedded
Visual Toolkit environment. This is especially helpful if you
have to build several different flavors of the CFR for different
devices.

Once you have successfully built your CFR using either version of
the MS eMbedded Visual Toolkit, you can generate a Windows CE make
file (.VCN). This can then be passed to one of the NM*.BAT files
provided in the sample CFR package to build the CFR.

To generate the Windows CE make file from the MS eMbedded
Visual Toolkit, choose the 'Export Makefile...' option from
the 'Project' pull-down menu. This will let you generate
make files for any projects in the current workspace. For the
'newcfr' project that we set up, the makefile name that is
generated is 'newcfr.vcn'. At the bottom of the window
is an option about writing dependencies. It is not
necessary to check this box because all of the NM*.BAT
files specify the 'rebuild all' option (-a) to ensure
that the entire CFR is rebuilt. Because CFRs build very
quickly this does not add much overhead and it ensures
all updated source is reflected in the executable.

Note: The NM*.BAT files that are to be used with the
version 3.0 of the eMbedded C++ compiler use the
environment variable WCEROOT to determine the root
directory where the version 3.0 of Microsoft
eMbedded Visual Toolkit is installed. For example:
G:\MSEmbedded30. If this toolkit is installed, this
environment variable should already be set properly.
If it is not defined, then you can define it using the
System icon in the Control Panel folder.

Since it is possible to install both version 3.0 and
version 4.0 of the compiler at the same time. The
batch files that are intended to be used with version
4.0 of the compiler (e.g. nmck30.bat, nmcv60.bat and
nms90xx.bat) all use the environment variable WCE40ROOT
to determine where version 4.0 of the compiler is
installed. Those batch files then set WCEROOT to be
set to what WCE40ROOT is set to before doing the compiler
because both versions of the compiler use WCEROOT.

WCE40ROOT is not automatically defined when the version
4.0 of the compiler is installed; you must set this up
using the System icon in the Control Panel. From there
go to the Advanced tab and choose the Environment
Variables button.

Once the .VCN file has been generated, from the command
line you can use any of the NM*.BAT files against that
.VCN file to build the CFR for a particular flavor of
CFR. For example, to build the Intermec 700 flavor
for the newcfr project that we created above, you
would run the following from command line:

nmi700 newcfr

And to build the LanPoint CE flavor for the same
project you would run:

nmlptce newcfr

If you had to generate different workspace and project
files for each version of the compiler, then you will also
generate a make file for each version of the compiler. For
example:

newcfr30.vcn

and

newcfr40.vcn

Then when running the appropriate NM*.BAT file you must
pick the make file that goes with it. For example:

nmi600 newcfr30
nmi700 newcfr30
nmi5020 newcfr30
nmi6651 newcfr30
nmlptce newcfr30
nmx86em newcfr30

nmck30 newcfr40
nmcv60 newcfr40
nms90xx newcfr40

If you created post-build steps as described in
the previous section, then command line make process
would not only build the CFR but it would also
perform the post-build step and thus would copy
the updated CFR to the \DCCONN\CFR directory.

Adding Another Configuration to a Windows CE CFR Project
--------------------------------------------------------
As was mentioned previously, the sample project includes
configurations with names like:

newcfr - Win32 (WCE ARM) Intermec 700 Release
newcfr - Win32 (WCE MIPS) Intermec 6651 Release
newcfr - Win32 (WCE x86) LanPoint CE Release

but these names are not names that you would get if you
created the project from scratch. In fact each of these
names is based on a similar configuration name without
the device identifier. The 3 configurations above are
based on the following 3 original configurations:

newcfr - Win32 (WCE ARM) Release
newcfr - Win32 (WCE MIPS) Release
newcfr - Win32 (WCE x86) Release

which are also part of the 3.0 version of the project. One
key difference in the settings for all of these configurations
is the directory in which the output files are generated. The
first 3 configurations use directory names such as IMEC700,
IMEC6651 and LANPTC. The last 3 use names such as ARMREL,
MIPSREL and X86REL.

If you wanted to create a new configuration for a
device such as the Symbol 81xx, you could perform
the following steps to do so:

Note 1: The Symbol 81xx (and HHP 7400) should be
able to use the same CFR as the Intermec 700
because they have the same processor and
Windows CE version. But we will use the
Symbol 81xx as an example any way.

Note 2: These steps apply whether you are using version 3.0
or 4.0 of the toolkit/compiler.

1) First set the active platform (Build -> Set Active Platform...)
and active configuration (Build -> Set Active Configuration...)
so that they are appropriate for the device. For the Symbol
81xx you choose 'Pocket PC' for the Platform and
'Win32 (WCE ARM) Release' for the Configuration.

2) Then choose (Build -> Configurations...) which will bring
up a window that shows the existing configurations and
has an 'Add...' pushbutton.

3) Click the 'Add...' puhsbutton. This brings up a new window
with 3 fields. The only change you should make is to the
last 'Configuration' field which will contain 'Release'.
Change that to something that applies to the appropriate
device (e.g. 'Symbol 81xx Release') and then click the
OK button.

Back at the 'Configurations' pop-up you should now see the
new configuration name at the end of the list. For example:

Win32 (WCE ARM) Symbol 81xx Release

4) Click the 'Close' button and you should now have this new
configuration as a choice in the 'Select Active Configuration'
pull-down list.

5) You will now need to make changes to the settings for this
new configuration. So first make this new configuration the
active one and then select 'Settings' from the Project
pull-down menu.

In the resulting Project Settings window, the selection
in the 'Settings For:' drop-down list should show the
name of the new configuration.

6) Now you can make changes to the settings on the right
side of this window by going to the appropriate tab
and making those changes. Here are a few settings you
may need to change:

- General tab: change the names of the Output Directories.
The default will be based on the configuration name
you selected. For example:

ARMSymbol 81xx Release

You'll probably want to simplify it to something
like:

Sym81xx

Make both the 'Intermediate files' and the 'Output
files' the same.

- C/C++ tab, Category=Preprocessor: the 'Additional
include directories' should be set to $(CFRTOOLS).
For some reason this is not set even though the
configuration that this was copied from did have
it set.

- Link tab, Category=Input: the 'Additional library
path' will need to be set to the directory that
contains the appropriate flavor of 'cfrapice.lib'
and 'cfrutlce.lib'. The Symbol 81xx, can use the
same libraries as the Intermec 700 because they
both have the same processor and Windows CE version;
therefore this field can be set to:

$(CFRTOOLS)\imec700

- Post-build step: Change the post-build command to
copy the CFR dll to a name that reflects the device
type.

7) When you have made all the changes to the Settings,
press the OK button. You should now be able to
compile the CFR for this new configuration.

8) If you are doing command line compiling, then
regenerate the makefile as described in the section

Building Windows CE CFRs from the Command Line.

9) Next you will need to create a new NM*.BAT for
the new configuration. We'll create NMS81XX.BAT
for the new Symbol 81xx configuration that we added.

First copy nmi700.bat (or whatever NM*.BAT file is
most appropriate) to nms81xx.bat.

10) If the processor and Windows CE version in the
file are not appropriate for the target device
you may need to change the following lines:

set OSVERSION=WCE300
set PLATFORM=ms pocket pc
call %WCEROOT%\evc\wce300\bin\wcearm.bat

The OSVERSION is set to the Windows CE version
(WCE211, WCE212, WCE300, ...). This is actually
used to determine the proper directory name under
the root directory for the SDKs (defined by the
environment variable SDKROOT. It defaults to
C:\Windows CE Tools). For example, if OSVERSION
is WCE300, then the directory that assumes is
C:\Windows CE Tools\WCE300 (g:\wincetools\wce300 on
our test system).

The PLATFORM will be set to one of the subdirectories
under the one specified by OSVERSION. For example, on
our test system, the directories 'MS Pocket PC' and
'LANPointCE_12' are under g:\wincetools\wce300.

The third line calls a batch file that adjusts the PATH,
INCLUDE, LIB and other environment variables so that
the proper files for the CE version and processor are
accessible to the compiler.

Between '\evc\' and '\bin\' will be the same value that
OSVERSION is set to (wce300, wce212, ...).

After '\bin\' is the name of a batch file that is based
on the processor type. This could be one of the following:

wcearm.bat - Intel Strong ARM processor
wcemips.bat - Toshiba MIPCS processor
wcemips16.bat
wcemipsfp.bat
wceppc.bat
wcesh3.bat - Hitachi SH3 processor
wcesh4.bat
wcethumb.bat
wcex86.bat - AMD X86 processor
x86em.bat - MS Pocket PC Emulator (using X86 processor)

Version 4.0 of the compiler includes these additional
possibilities:

wcearmv4i.bat
wcearmv4t.bat
wceemulator.bat
wcemipsii.bat
wcemipsii_fp.bat
wcemipsiv.bat
wcemipsiv_fp.bat

11) You will need to change the call to 'nmake' in several places.
In 'nmi700.bat' this line looks like:

nmake -a -f %1.vcn CEflavor=300 CESubsystem="windowsce,3.0" CFG="%1 - Win32 (WCE ARM) Intermec 700 Release" > outi700

One way to determine the proper value for CEVersion and CESubsystem
is to use the 'Pre-link step' or 'Post-build step' tab of the
Project settings to call the following commands:

echo %CEVersion%
echo %CESubsystem%

Make sure you have the proper configuration selected before
setting up these commands. Then choose the 'Rebuild All'
option from the 'Build' pull-down menu. If you look in
the compile results window at the bottom, right above the
line that says:

Linking...

You'll see the actual values for CEVersion and CESubsystem.
For example:

300
windowsce,3.00
Linking...

And to get the value for CFG look at the top of the compile
output window for the title line that looks similar to:

-----Configuration: newcfr - Win32 (WCE ARM) Symbol 81xx Release ------

The CFG value is everything from 'newcfr' up to and including
'Release'. But when you put this into the new NM*.BAT, change
the first word (the project name - e.g. newcfr) to %1 because
this is a parameter that is pased to the NM*.BAT file.

So for our NMS81XX.BAT file, this new line will be:

nmake -a -f %1.vcn CEVersion=300 CESubsystem="windowsce,3.0" CFG="%1 - Win32 (WCE ARM) Symbol 81xx Release" > outs81xx

The CEVersion and CESubsystem did not actually change for this
case. But at the very end, after the > sign, we did change
'outi700' to 'outs81xx' so that the output of the compile is
written to a file that goes with nms81xx.bat.

12) The last line that needs to be changed is the one after the
call to nmake which is similar to:

if '%2'=='' call notepad outi700

Here we just have to change the 'outi700' at the end to
'outs81xx' just like we did in the previous step.

13) Now nms81xx.bat is set up to compile from the command line, any
CFR that will work with the Symbol 81xx terminal. Just pass
in the project name. For example:

nms81xx newcfr

If you create other CFR projects in the future which contain a
configuration called "Win32 (WCE ARM) Symbol 81xx Release" and
generate make files for them (*.VCN) then nms81xx can be used to
compile those CFR projects from the command line as well.

Setting Up a CE Device from Scratch
-----------------------------------
This section gives a high level overview of the steps to take
to set up a Windows CE device. However, because there are
differences in each device, even for those devices from the
same manufacturer, you will need to consult the documentation
that comes with the devices to get detailed information
about the following kinds of issues:

- What hardware is needed to be able to transfer the DCConnect
Client files to the device? Possiblities include:

- Serial cable to a dock
- Serial cable directly to a 9-pin serial port on the device
- Serial cable to an optical couple that attaches to the device
- Infrared
- Ethernet cable to a dock
- No extra hardware; device is loaded via radio once
communication parameters are set up
- Removable compact flash card that can be put into a
PCMCIA adapter and loaded from a laptop.

- What software is used to load the terminal once the necessary
hardware connection is in place? Possiblities include:

- Proprietary transfer software provided by the manufacturer.
- Web browser accessing a web server program on the device
- No extra software - if a PCMCIA adapter is being used
- Device uses FTP to download files from an FTP server
- Microsoft ActiveSync over serial, infrared, ethernet or
radio. This has been available as a free download from
the Microsoft website:

http://www.microsoft.com

As of June 2004, the latest version of ActiveSync is 3.7.1

- How can the device be configured? Possibilities include:

- Utility that is provided by the manufacturer and is
preloaded on the device
- Web browser accessing a web server program on the device
- If the configuration is maintained in the Windows CE
registry, then the IBM CE Config Tool can be used to
update the registry. Determining which registry keys
need to be set may take some time; but if a large
number of devices need to be configured this may be
a faster, more reliable method. In addition, the
configuration can automatically be completely restored
in the event of a cold-boot or total loss of battery
power. For more information about the IBM CE Config
Tool, see IBM CE Configuration Tool.

Settings that may need to be configured include:

- Radio parameters (e.g. 802.11 network name, AP density)
- Network parameters (e.g. IP address, subnet mask, gateway)
- Run in 'wedge' mode (feeds scanner input through keyboard)
- Bar code preamble and postamble
- Active bar code symbologies and their settings
- Volume setting
- Backlight duration

Once you understand the hardware and software required and
the configuration method, you are ready to begin the process
to set up your files and load them to the device. Here are
the high-level steps in that process:

Note: It may be required that you install the Microsoft
eMbedded Visual Toolkit in order to create or locate
all of the files that are needed in the terminal. If
you need to do any of the following, you will need to
install the toolkit:

- Build a customer ETSUSER.DLL (step 6 below)
- Use the IBM CE Config Tool (step 7 below)
- Use the Cab Wizard to create a .CAB file (step 8)
- Build a CFR for use on the Windows CE device

For more information about obtaining this toolkit see
Hardware and Software Requirements for Windows CE Devices

1) You'll probably want to create a separate load directory
(folder) that contains all of the files that you need to
load the terminal. We'll use C:\CEFILES. So create that
load directory and make it the current directory.
For example:

c:
md cefiles
cd cefiles

2) Copy into your load directory the license file from the
root directory where the DCConnect Client is installed:

ETSCHECK.LIC

3) Now you will need to copy the product executables:

ETSPT.EXE
ETSPT.DLL

but you must decide which ones are appropriate. Where
the DCConnect Client product files are installed you'll
find the following subdirectories that contain different
flavors of the Windows CE executables:

ARMNOPPC - Devices with StrongARM processor or compatible
and Windows CE 3.0 or compatible later version
but which are not Pocket PC devices
IMEC600 - Intermec 600 terminal
IMEC700 - Intermec 700 terminal
IMEC5020 - Intermec 5020 terminal
IMEC6651 - Intermec 6651 terminal
LANPTCE - Intelligent Instrumentation LanPoint CE

X86EMDBG - Pocket PC Emulator on Windows

choose the appropriate subdirectory and copy the ETSPT.DLL
and ETSPT.EXE executables from that subdirectory. If you
are using a Windows CE device other than the ones indicated
by each directory name, you may still be able to use the
executables from one of the above subdirectories as long
as your device has the same processor and Windows CE
version as one of these directories:

IMEC600 - Windows CE 2.12, X86 processor (AMD)
IMEC700 - Windows CE 3.0, Strong ARM 1110 processor (Intel), Pocket PC
IMEC5020 - Windows CE 3.0, SH3 processor (Hitachi)
IMEC6651 - Windows CE 3.0, MIPS processor (Toshiba)
LANPTCE - Windows CE 3.0, X86 processor (AMD)

X86EMDBG - Used only with Pocket PC Emulator on Windows

For example, if you have a Symbol 81xx terminal or an
HHP "Dolphin" 7400, both of which are Pocket PC devices which
run Windows CE 3.0 on an Intel Strong ARM 1110 processor, then
these terminals can use the executables in the IMEC700 directory
because the Intermec 700 runs the same version of Windows CE on
the same processor.

Note: Devices such as the Symbol PPT 88xx or the MA 1000 from
Group Mobile which have StrongARM or compatible (XScale)
processors and Windows CE 3.0 or later compatible
but which are not Pocket PC devices, must use the flavors
of ETSPT.EXE and ETSPT.DLL in the .\ARMNOPPC subdirectory
instead of the ones in the .\IMEC700 because the latter
requires a .DLL (AYGSHELL.DLL) that is only available on
Pocket PC devices.

4) Two other product files should also be copied from the
root directory where the Client is installed to your
load directory:

LOGFILE.LOG
LOGFILE.NDX

These are default (empty) files for the transaction
logfile on the terminal. These are included so that
an uninstall of the Client .CAB file on the device
removes these files. The Client will create these
files if they do not exist. However, the .CAB file
uninstall will not remove these files unless they
were part of the original .CAB file.

Note: The .CAB file is set up so that a reinstall
will not overwrite these files if they
already exist.

5) Now it is time to set up EMULATOR.INI with whatever parameters are
needed. For information about what parameters can be set in this file,
see Configuration using EMULATOR.INI.

You will probably want many of the following parameters (see the link
above for an explanation of each):

MAX_TRANSACTIONS = 10
NUM_PF_STRINGS = 0
NUM_TOUCH_STRINGS = 0
NUM_ROWS = 16
NUM_COLS = 20
PF_MAPPING = Y

TCPIP_PORT = 7500
TCPIP_HOST = 99.99.99.70

SELECT_FONT = Lucida Console

SCAN_SENTINEL_CHARS = 123, 125

FULL_SCREEN = Y

MENU_PASSWORD = ABC

MENU_ITEM = ...

The first 6 are pretty standard, although you may need to
adjust the MAX_TRANSACTIONS or the number of rows/columns.

TCPIP_PORT usually does not need to be changed from 7500
unless the Client is running in the Pocket PC Emulator on
the same machine as the DCConnect Server.

Be sure to set the TCPIP_HOST to the IP address of the
DCConnect Server.

Use the SELECT_FONT keyword if you will be loading a special
font file to the terminal. For more about this see
Changing the Font Used By the Client on a Windows CE Device.

Note: If using the SELECT_FONT keyword, you will not need
to copy the actual font file (*.TTF) to your load
directory - although you can certainly do so if you
wish. The .INF file used to create the .CAB file can
be directed to find the .TTF file where it resides
on your system.

If you use the SCAN_SENTINEL_CHARS keyword, be sure
your device will be configured to use the preamble and
postamble characters that you specify with this keyword.

Use FULL_SCREEN = Y if the device is a 'Pocket PC'
device and you want the Client to run without the
user being able to get to other applications. Be
sure to include ETSUSER.DLL in your .CAB file if
using this keyword.

Use the MENU_PASSWORD keyword if you want to
prevent the user from getting to most of the
menu options.

User MENU_ITEM if you want to add one or more
custom functions to the Client menus. Be sure
to include ETSUSER.DLL in your .CAB file if using
this keyword.

6) If you included the FULL_SCREEN or MENU_ITEM keywords in
EMULATOR.INI in the previous step, then you will also
need to create ETSUSER.DLL in your load directory so
that it can be included in your .CAB file. For more
information about how to build ETSUSER.DLL please see
Keyword: FULL_SCREEN and
Keyword: MENU_ITEM.

In the root directory where the DCConnect Client product
files are installed you can find the following files
used to build ETSUSER.DLL:

ETSUSER.*
NM*.BAT

You can modify the source and build ETSUSER.DLL
directly where the DCConnect Client files were
installed or you can copy the above files to
your load directory and make your changes there.
Wherever you decide to make your changes, the
resulting ETSUSER.DLL will be created in a
subdirectory with one of the following names,
based on the platform and configuration you
selected (or which NM*.BAT file you ran):

IMEC600
IMEC700
IMEC5020
IMEC6651
LANPTCE
X86EMDBG

So be sure that when you later set up your .INF
file that is used to bulid your .CAB file, you
specify the appropriate subdirectory so that the
Cab Wizard can find the ETSUSER.DLL that you built.

Take a look at the sample DCCLIENT.INF file (in
the root directory where the DCConnect Client
product files are installed) and note how ETSUSER.DLL
uses directory identifier 3 which specifies one
of the subdirectories listed above, depending on
the device in use.

7) If you will be configuring the device by updating its
registry using the IBM CE Config Tool, then be sure to
copy to your load directory from the directory
containing the Client product files:

CECONFIG.VB

You will also need to create a CECONFIG.INI that
specifies which registry keys updates and other
operations should be performed by this tool. For
more information about the IBM CE Config Tool see
IBM CE Configuration Tool.

A sample CECONFIG.INI is provided in the same
directory where CECONFIG.VB is found.

Note: You can use the CE Config tool to create
the EMULATOR.INI file that was described
in step 5 above. But you should only need
to do so if one or more parameters (such as
TCPIP_HOST) is not going to have the same
value for all of your terminals.

Even in this case, you should still
create an EMULATOR.INI file and include
it in your .CAB file. Otherwise an
uninstall of the Client .CAB file on the
device will not remove EMULATOR.INI.

Use of the CE Config Tool requires that some
Visual Basic DLLs be obtained from the Microsoft
eMbedded Visual Toolkit. You do not need to
copy those .DLLs to the load directory, but
when you set up the .INF file for building the
.CAB file in the next step, you will need to
specify where those DLLs should be found.

8) All of your files should now be in place. If
you wanted to, you could copy the files
individually to the device and put them in
their appropriate directories. However, this
would be very time consuming and error prone
if there are a lot of devices to set up.

Instead, it is best to create a cabinet (.CAB)
file that contains all of the appropriate files
and can easily be transported to the target
device and stored in non-volatile storage in
case the need to reinstall arises.

.CAB files are created using the Cab Wizard
tool that is part of the Microsoft eMbedded
Visual Toolkit. You must create a .INF file
to tell the Cab Wizard what files should be
installed, where they should be copied and
what short cuts and registry updates should be
made. For more about creating .CAB files, see
Building a .CAB File to Install the Client on a Windows CE Device.

9) Once you have created the .CAB file, you should
transfer the .CAB file to non-volatile storage
on the target device using the required hardware
and software specified by the device manufacturer.
Consult the documentation provided with the device
for information about what hardware and software
options are available for transferring files from
the PC to the device.

10) Once the .CAB file has been installed to the
device, you can use the Windows CE File
Explorer (Start -> Programs -> File Explorer)
to locate the .CAB file and then double click
on it to install it.

On some devices (e.g. Intermec 5020) a web-
based tool is used to install the application
using a browser on the PC.

On other devices if the .CAB file is found in
a certain directory, rebooting the terminal
will automatically cause the .CAB file to be
installed. For example, on the Intermec 700,
any .CAB file found in the \Storage Card\CABFILES
directory will be installed automatically when
the terminal is rebooted.

11) Once the .CAB file is installed, all of the files
are in place and the Client could actually be
started. However, there are a couple of situations
that might require other steps to be done first.

Note: If the terminal was rebooted to have the .CAB
file installed and other .CAB files were
installed at the same time then the installation
of one of the other .CAB files might actually
cause the terminal to reboot. In this case,
if the Client was configured to be in the
Startup folder, then it will start automatically.
If the IBM CE Config Tool is supposed to be
run, then you will need to exit the Client
so that the CE Config tool can be run.

Here are some other steps that might need to be
performed before the Client can be used:

- If the IBM CE Config Tool has been installed
and needs to be run to set up the registry and/or
files, then it should be run by selecting the
CE Config Tool from the Start Menu. The terminal
should be rebooted after these changes are made.

- If a font file has been installed, the terminal
must be rebooted so that Windows CE can load the
new font file when Windows CE restarts.

Note: If you installed both the font file and
are running the IBM CE Config Tool, then
the reboot that must be done after the
CE Config Tool is run will also take care
of having Windows CE load the new font file.

12) Once the IBM CE Config Tool has been run and the
terminal has been rebooted, the Client should be
ready to run.

If a short cut for the Client is installed in
the Startup folder, then the Client was started
automatically when Windows CE was restarted.

Otherwise, you can start the Client by selecting
DCConnect Client from the Start menu.

Note: If the Client is already running and you
try to start it again from the Start menu,
the original running copy of the Client
will be brought to the foreground instead
of a second copy of the Client starting up.

Terminal-Specific Issues for the Intermec 600 Terminal
------------------------------------------------------
The following sections below cover various topics for the Intermec 600:

- Intermec 600 Hardware and Software Requirements
- How to Configure the Intermec 600
- Intermec 600 Bar Code Configuration
- Rebooting the Intermec 600
- Intermec 600 Keyboard / Stylus Notes
- Intermec 600 Screen Notes
- Notes About Building Intermec 600 .CAB File
- Loading and Installing the Intermec 600 .CAB File

Please refer also to the Intermec 600 documentation:

600 Series Industrial Mobile Computer User's Guide
Windows 95 and Windows CE Configuration Utilities Reference Manual

both of which are available from Intermec's website:

http://www.intermec.com

Follow the links to 'Support' -> 'Manuals' ->
'Computers' -> 'Pen Notepad/Tablets' and then choose
the 600 or 601 terminal.

Intermec 600 Hardware and Software Requirements
-----------------------------------------------
The Intermec 600 does not have the ability to install
a radio card. Instead the 600 must be put into its
dock so that it can communicate to another PC. This
can be done via the serial port or via the 10-base T
ethernet port that are built into the dock.

The Intermec 600 is an older Windows CE device and as
such it comes loaded with Windows 2.12 instead of
version 3.0 that most other devices have today. As
a result, different executables must be created and
loaded to the Intermec 600 and LanPoint CE terminal
even though both have AMD 486 processors.

The Intermec 600 has an internal non-volatile flash
card that is given the directory name \Storage_Card
(note the use of the underscore here where a space is
used for other devices). The 600 also has the option
to use a removable non-volatile flash card. This
removable card is given the directory name \ATACard.
When rebooting the terminal the removable card should
be out of the terminal or the terminal will try to
boot from the removable card.

How to Configure the Intermec 600
---------------------------------
Configuration of the Intermec 600 is done using
the Control Panel (Start -> Settings -> Control Panel)
and Intermec Configuration Utility (Start -> Programs ->
Configuration Utility) that are preloaded on the
terminal.

Although the Configuration Utility has a
'Communications' button which takes you to a
screen where you can set IP address, subnet and
gateway, you actually have to use the Network
icon in the Control Panel to set these up.

Once the network parameters are set up, you
must start the network drivers by running
Start -> Programs -> NDIS Loader and choosing
the 'Load' button. In order for these drivers
to remain running, the 'ndisport' window must
remain up. So do not click the OK button.

Intermec 600 Bar Code Configuration
-----------------------------------
The Intermec 600 documentation does not mention
anything about configuring bar codes, setting up
preamble or postamble characters or setting up
a 'wedge' mode so that scanned bar codes are
routed to the keyboard.

Rebooting the Intermec 600
--------------------------
The Intermec 600 can be rebooted by pressing and holding
the following 3 keys:

[Gold] [Esc] [0]

for 3 seconds. The Intermec 600 preserves all registry
settings to non-volatile storage, so a reboot will not
destroy them.

However, the set of files that is loaded on the terminal
will revert back to the factory default - except for
those files that are in non-volatile storage (in the
\AtaCard and \Storage_Card directories). This means that
a reboot will delete the short cut for starting the Client
and it will delete any font file installed to the
\Windows\fonts directory.

Although you could go to the \Storage_Card\DCConnect Client
directory and run etspt.exe to start the Client, you should
reinstall the DCConnect Client .CAB file after a reboot so
that the shortcut can be recreated and any font file can
be reinstalled.

600 Keyboard / Stylus Notes
---------------------------
While the Intermec 600 has a physical keyboard unless you
are entering numbers, the period or pressing Enter, you will
need to use the software input panel (SIP) to enter alphabetic
and other characters.

The SIP is enabled by running Start -> Programs -> SIP Enable.
The SIP shows up as a window that you can move around. The
SIP also shows up in the task bar at the bottom of the screen.
Tapping twice slowly! on this task bar icon causes the SIP to
be mimimized. Tap again and the SIP is restored.

Use Start -> Programs -> SIP Disable to close the SIP.

Note: If you find that when you tap a menu item that leads
to another menu, the menu item from the sub-menu is
actually invoked, then try tapping the first item
on the side that would not overlap the submenu.

For example, when the Start menu is up and you tap
the right side of the 'Programs' item in the Start
Menu, then you may find that 'Communications' or
'Command Prompt' from the Programs menu is automatically
invoked. To avoid this, tap the left side of the
'Programs' menu.

To power the terminal on or off using the the I/O button you
must hold the button down for 3 seconds whether turning the
terminal on or off.

Although the Intermec 600 keyboard shows letters on the
actual keys, there is no way to generate these letters
with the way the terminal is shipped. You must use the SIP
keyboard to generate letters.

Intermec 600 Screen Notes
-------------------------
The Intermec 600 has a 1/4 VGA screen for which the screen
dimensions 16x20 fit very nicely. That is why the statements:

NUM_ROWS = 16
NUM_COLS = 20

are included in the sample EMULATOR.INI - found in the
IMEC600\SAMPLE directory where the Client product files are
installed.

You can actually set the screen dimensions to any combination
of values up to 20 rows and 40 columns and the Client adjusts
the font accordingly. For most cases there is not a font
available which allows the Client screen to perfectly fit in
the width and height available and as a result you will
generally see a small border around the actual text area.

Of course the more rows and columns that you try to fit on
the screen the smaller the font has to be and as a result
the characters may become too small for practical use.

You also have the option to change which font is being used, as
long as you select a non-proportional font. For more info, see
Changing the Font Used By the Client on a Windows CE Device.

Notes About Building the Intermec 600 .CAB Files
------------------------------------------------
A sample .INF file for building the .CAB for Intermec 600 terminals
is found in the DCConnect Client product files in IMEC600\SAMPLE\IMEC600.INF.
Here are some notes about the contents of that file:

- In the [CEStrings] section the InstallDir is set to "\Storage_Card\%AppName%"
instead of the more common "\Storage Card\%AppName%". Note the use of the
underscore instead of the space between 'Storage' and 'Card'.
- This is not a difference in the .CAB file but rather in what happens on
the terminal: the %CE17% identifier actually indicates the Start -> Favorites
folder for Windows CE 2.12 (which is what the Intermec 600 comes with) instead
of being directly on the Start menu as it is for Windows CE 3.0. This affects
where the DCConnect Client shortcut is created [Shortcuts.All] section.
- In the section [RegSettings.All] you will see that %InstallDir% is not
used in the last parameter. On the Intermec 600 this is not converted to
its true value (e.g. \Storage_Card\DCConnect Client) and is instead put
in the registry as is (%InstallDir%). Therefore the .CAB file must use
the value of %InstallDir% explicitly in this section rather than using
%InstallDir%.

Loading and Installing the Intermec 600 .CAB File
-------------------------------------------------
You will need to load the DCConnect Client .CAB file for
the Intermec 600 by removing the removable compact flash
card from the terminal and using a PCMCIA adapter to copy
the .CAB file from your PC to the compact flash card.

The terminal does not have to be turned off to remove or
insert the removable flash card. Unless the terminal booted
from the removable flash card, it will have the directory
name \AtaCard. Use the My Computer icon on the Windows
desktop or Start -> Programs -> Windows Explorer to
locate the .CAB file on the \AtaCard and double click
on it to install.

When the install completes, you should have a 'DCConnect
Client' entry in your Start -> Favorites folder.

Unlike other Windows CE devices, you should NOT reboot the
Intermec 600 after the .CAB file is installed. Apparently
any font file that is installed is immediately registered
with Windows CE and all registry settings are preserved to
non-volatile storage.

For more information about what happens during a reboot, see
Rebooting the Intermec 600.

Terminal-Specific Issues for the Intermec 700 Terminal
------------------------------------------------------
The following sections below cover various topics for the Intermec 700:

- Intermec 700 Hardware and Software Requirements
- How to Configure the Intermec 700
- Intermec 700 Bar Code Configuration
- Rebooting the Intermec 700
- Intermec 700 Keyboard Notes
- Intermec 700 Screen Notes
- Notes About Building the Intermec 700 .CAB File
- Loading and Installing the Intermec 700 .CAB File

Intermec 700 Hardware and Software Requirements
-----------------------------------------------
The Intermec 700 comes with non-volatile storage that is given the
directory name \Storage Card. This is where the DCConnect Client
files should be installed so that transactions are written to
non-volatile storage.

In order for the Intermec 700 to provide networking and scanning
capabilities, several .CAB files must be installed in addition to
the DCConnect Client .CAB file. These are the names of those files
that were used with the Pocket PC (not PPC 2002) load, version 1.12:

netpack.cab
itcdevmgmt.cab
itcdatacollection.cab
itcstingraysdk.cab

All of these should be installed to the \Storage Card\CABFILES
directory - which is the same place that the DCConnect Client .CAB
file should be installed. If not already on the terminal, these
must be obtained from the Intermec 700 Windows CE Developer's Kit CD.

Note: In earlier versions of the CDK, the itcdevmgmt.cab and
itcdatacollection.cab were combined into one .CAB file.

Before loading any .CAB file to the terminal, make sure the read-only
attribute for that .CAB file is set where the file resides on the PC.
This is the only way to force the .CAB file to have its read-only
attribute set after the file is copied to the terminal. If the .CAB
file does not have its read-only attribute set on the terminal, then
the .CAB file is deleted automatically after it is installed.

How to Configure the Intermec 700
---------------------------------
On the Intermec 700, you can use the Settings option from the Start
Menu to manually configure device Settings options such as those for
Data Collection and for Wireless Network (on the System tab) and for
Network (on the Connections tab).

The Intermec 700 settings are maintained in the registry, therefore you
can use the IBM CE Config Tool to set these values rather than manually
setting up every terminal. For more information about this tool please
see IBM CE Configuration Tool.

Following is a list of the registry keys and values that map to the various
configuration options. For each, the first line describes the option on
the currently specified tab that allows this registry key to be set via
the settings menus. The second line shows the registry key followed by
a comma and the registry value name. In parenthesis is the type for the
registry value.

Personal Tab
------------

Owner Information (Name, Company, Address, Telephone, E-mail)

HKEY_CURRENT_USER\ControlPanel\Owner, Owner (REG_BINARY)

// See default CECONFIG.INI for example of how to define the parts

Sounds & Reminders (System Volume)

HKEY_CURRENT_USER\ControlPanel\Volume, Volume (REG_DWORD)

// The 6 possible levels correlate to the following values:
// 0, 858993459, 1717986918, 2576980377, 3435973836, 4294967295

Today (Display Today screen if device is not used ... for ?? hours

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shell\Rai, SessionTimeout (REG_DWORD)

// Set to 0 to disable switching to Today screen

System Tab
----------

About, Device ID Tab (Device name)

HKEY_LOCAL_MACHINE\Ident, Name (REG_SZ)

// This is the Partnership name

Data Collection, Symbologies tab, Code 39 enabled with default settings:

HKEY_LOCAL_MACHINE\SOFTWARE\Intermec\ADCDevices\S9C\DevConfig\Code39, Decoding (REG_BINARY)

// Set to 2-byte binary value 41 4c to enable; set to 41 4d to disable

Data Collection, Symbologies tab, Code 39 enabled with default settings:

HKEY_LOCAL_MACHINE\SOFTWARE\Intermec\ADCDevices\S9C\DevConfig\Code128, Decoding (REG_BINARY)

// Set to 2-byte binary value 41 5a to enable; set to 41 5b to disable

Data Collection, Virtual Wedge tab, Enable:

HKEY_LOCAL_MACHINE\SOFTWARE\Intermec\ADCDevices\S9C\VirtualWedge, EnableStatus (REG_DWORD)

// Set to 1 to enable

Data Collection, Virtual Wedge tab, Preamble:

HKEY_LOCAL_MACHINE\SOFTWARE\Intermec\ADCDevices\S9C\VirtualWedge, Preamble (REG_SZ)

Data Collection, Virtual Wedge tab, Postamble:

HKEY_LOCAL_MACHINE\SOFTWARE\Intermec\ADCDevices\S9C\VirtualWedge, Postamble (REG_SZ)

Wireless Network, Edit Profile, Basic tab (Network Name)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms, DesiredSSID (REG_SZ)
HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Config01, DesiredSSID (REG_SZ)

// Both registry keys must be set

Wireless Network, Edit Profile, Encryption tab (Enable Data Security, ...)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms, Encryption (REG_SZ)
HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Config01, Encryption (REG_SZ)

// Both registry keys must be set. All options on this tab result in a single
// (very long) string that is set for this registry key.

Wireless Network, Edit Profile, Advanced tab (Card Power Management)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms, PMEnabled (REG_DWORD)
HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Config01, PMEnabled (REG_DWORD)

// Both registry keys must be set. 0 = Disable, 1 = Enable

Wireless Network, Edit Profile, Advanced tab (Interface Robustness)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms, MicroWaveRobustness (REG_DWORD)
HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Config01, MicroWaveRobustness (REG_DWORD)

// Both registry keys must be set. 0 = Disable, 1 = Enable

Wireless Network, Edit Profile, Advanced tab (RTS/CTS Medium Reservation)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms, RTSThreshold (REG_DWORD)
HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Config01, RTSThreshold (REG_DWORD)

// Both registry keys must be set. 500 = On, 2347 = Off

Wireless Network, Edit Profile, Admin tab (Distance Between Access Points)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms, SystemScale (REG_DWORD)
HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Config01, SystemScale (REG_DWORD)

// Both registry keys must be set. 1=Large, 2=Medium, 3=Small

Connections Tab
---------------

Network, Adapters Tab, Orinoco ... Driver, IP address tab (Use specific IP address)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Tcpip, EnableDHCP (REG_DWORD)

// Set to 0 to use specific IP address; set to 1 to Enable DHCP

Network, Adapters Tab, Orinoco ... Driver, IP address tab (IP Address)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Tcpip, IpAddress (REG_MULTI_SZ)

Network, Adapters Tab, Orinoco ... Driver, IP address tab (Subnet mask)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Tcpip, Subnetmask (REG_MULTI_SZ)

Network, Adapters Tab, Orinoco ... Driver, IP address tab (Default gateway)

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Tcpip, DefaultGateway (REG_MULTI_SZ)

Network, Adapters Tab, Orinoco ... Driver, Name Servers tab (DNS):

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Tcpip, DNS (REG_MULTI_SZ)

Network, Adapters Tab, Orinoco ... Driver, Name Servers tab (WINS):

HKEY_LOCAL_MACHINE\Comm\WLLUC461\Parms\Tcpip, WINS (REG_MULTI_SZ)

Not On Any Tab (these can't be set from the Settings screens)
-------------------------------------------------------------

Enable Backlight on Tap

HKEY_CURRENT_USER\ControlPanel\Backlight, BacklightOnTap (REG_DWORD)

// Set to 1 to enable turning on the backlight whenever screen is tapped

Intermec 700 Bar Code Configuration
-----------------------------------
In order for the Intermec 700 to support scanning and the
ability to configure the bar code symbologies in use, the
following .CAB file must be loaded to the terminal:

itcdatacollection.cab

For information about how to obtain and install this and other
required .CAB files please refer to the section above
Intermec 700 Hardware and Software Requirements.

When the above .CAB file has been installed, there will be an
icon called 'Data Collection' on the System tab of the Start ->
Settings option. This is used to enable 'Wedge mode', set the
preamble and postamble characters and to select which bar code
symbologies are active and adjust any settings for each.

Because the Intermec 700 maintains the bar code settings in the
Windows CE registry, you can use the IBM CE Config Tool to
configure all the bar code related settings rather than having
to do this manually for every terminal that must be set up.
To find out which registry keys applies to the various bar code
options, please refer to the previous section.

The 'Virtual Wedge' setting must be enabled in order for
the Client to be able to

In order for the DCConnect Client to be able to distinguish
between keyboard and scanner input, you should set up a
preamble and postamble character (e.g. { and } ) and then
be sure to tell the DCConnect Client which characters were
used by including the SCAN_SENTINEL_CHARS keyword in
EMULATOR.INI. For example:

SCAN_SENTINEL_CHARS = 123, 125

For more information about this keyword, please refer to
Keyword: SCAN_SENTINEL_CHARS.

Rebooting the Intermec 700
--------------------------
To warm-boot the Intermec 700, turn the terminal on and then press
and hold the I/O button until you see the screen go blank, signifying
the start of the reboot process. You need to hold the I/O button for
10-15 seconds before it reboots.

Warm booting the terminal simply restarts Windows CE; all files and
registry settings remain intact.

To cold-boot the Intermec 700, you must remove the battery and press the
small button that is right of center inside the battery compartment. When
you replace the battery and turn the terminal back on, the terminal will
go through its cold-boot process and reload the default set of files; all
non-default files that were not on the storage card and all registry
settings are removed as a result of the cold-boot process.

But if your .CAB files were set up with the read-only attribute and they
still reside in the \Storage Card\CABFILES directory, they will automatically
be restored. And if you used the IBM CE Config Tool to configure the
terminal, you should be able to rerun that tool and restore the
configuration.

Intermec 700 Keyboard Notes
---------------------------
The Intermec 700 keyboard gives you the capability to enter numeric and
alphabetic characters along with a few selected characters such as * / .
+ and -. Just pressing one of the keys with a number on it will
generate the number shown. To get alphabetic keys you must first
press the blue 'Alpha' key on the bottom row and then press the
appropriate number key 1, 2, 3 or 4 times to generate the letter.
When you press the blue key, the red LED that is marked with a
check mark, lights up to indicate you are in alphabetic mode.

To get an A in alphabetic mode, press the 2 key once.
To get a B in alphabetic mode, press the 2 key twice quickly.
To get a C in alphabetic mode, press the 2 key three times quickly.
To get a Z in alphabetic mode, press the 9 key 4 times quickly.

The terminal remains in alphabetic mode until you press the Alpha
key again.

The circular grey multi-arrow key in the middle of the top row is used
to generate the arrow keys and tab keys. Without any shift, up and down
result in the up and down arrow keys and left and right result in the
backtab and tab keys. To get left and right arrow keys, you must first
press the orange function (in the bottom left corner) and then press the
left or right side of the circular grey key.

In addition to the physical keyboard, the Windows CE Pocket PC
environment also supports a software keyboard that you use your
stylus with to type the appropriate keys.

When the software keyboard is available to an application, you'll see
a little keyboard symbol in the bottom right corner of the screen. Just
tap this symbol and the software keyboard will pop up at the bottom of
the screen.

When the DCConnect Client is running in full-screen mode, the keyboard
symbol is not available. Instead the toolbar of the DCConnect Client
contains an icon marked A-Z. This icon is used to show and hide the
software keyboard.

Intermec 700 Screen Notes
-------------------------
The Intermec 700 has a 1/4 VGA screen for which the screen
dimensions 16x20 fit very nicely. That is why the statements:

NUM_ROWS = 16
NUM_COLS = 20

are included in the sample EMULATOR.INI - found in the
IMEC700\SAMPLE directory where the Client product files are
installed.

Of course the more rows and columns that you try to fit on
the screen the smaller the font has to be and as a result
the characters may become too small for practical use.

You also have the option to change which font is being used, as
long as you select a non-proportional font. For more info, see
Changing the Font Used By the Client on a Windows CE Device.

The Intermec 700 can be configured to turn on the backlight
any time the screen is tapped by the stylus. However this
option is not available on any of the Settings screens on
the terminal; this option must be changed in the registry
and that can be done using the IBM CE Config Tool. To
find out which registry key must be updated, please see
How to Configure the Intermec 700.

Because the Intermec 700 is a Pocket PC device, the Client
can be set up to run in "full-screen" mode - which means
while the Client is running the terminal user cannot get
to any other application on the device. This is done
using the following keyword in EMULATOR.INI:

FULL_SCREEN = Y

and including ETSUSER.DLL in the DCConnect Client .CAB file.
For more information about full-screen mode, please see
Keyword: FULL_SCREEN.

Notes About Building the Intermec 700 .CAB Files
------------------------------------------------
A sample .INF file for building the .CAB for Intermec 700 terminals
is found in the DCConnect Client product files in IMEC700\SAMPLE\IMEC700.INF.
Here are some notes about the contents of that file:

- Full screen mode is set up by default by including
ETSUSER.DLL and by including an EMULATOR.INI that
contains the statement FULL_SCREEN=Y.

- There are commented out references to files and
shortcuts for the IBM CE Config tool.

Loading and Installing the Intermec 700 .CAB File
-------------------------------------------------
Whether you use Microsoft's ActiveSync or you copy files directly
to the compact flash card, be sure to copy the DCConnect Client
.CAB file to the \Storage Card\CABFILES directory so that it is
automatically installed after a reboot.

After the .CAB file is installed, the terminal must be
warm-booted following the process described above in
Rebooting the Intermec 700.

Terminal-Specific Issues for the Intermec 5020 Terminal
-------------------------------------------------------
Early versions of the Intermec 5020 terminal shipped with versions 2.11 or 2.12
of Windows CE. The Intermec 5020 currently ships with Windows CE 3.0 and any
5020 terminal not at version 3.0 can be upgraded to that level by purchasing
an upgrade CD from Intermec. For details, please go to Intermec's website:

http://www.intermec.com

then following the links to Support -> Developers Support -> 5020 Support -> FAQ.
The part number for the 5020 Upgrade Kit is: 072157.

All files provided with the DCConnect Client that apply to an Intermec 5020
and all comments in this documentation that apply to an Intermec 5020
apply only to Interemc 5020's that are loaded with Windows CE 3.0.

The following sections below cover various topics for the Intermec 5020:

- Intermec 5020 Hardware Requirements
- How to Configure the Intermec 5020
- Intermec 5020 Bar Code Configuration
- Rebooting the Intermec 5020
- Intermec 5020 Keyboard Notes
- Intermec 5020 Screen Notes
- Notes About Building the Intermec 5020 .CAB File
- Loading and Installing the Intermec 5020 .CAB File

Intermec 5020 Hardware Requirements
-----------------------------------
It is strongly suggested that a compact flash card be used with the 5020 in order
to provie non-volatile memory for transactions. A storage card is a good place to
store the DCConnect Client .CAB file and it can also be used as a method for
transferring files to the terminal - if you have a PCMCIA compact flash adapter and
a computer that is set up to use the PCMCIA compact flash adpater. The default .CAB
and .INF files provided in the IMEC5020\SAMPLE subdirectory of the Client assume
a storage card is being used.

How To Configure the Intermec 5020
----------------------------------
Configuration of the radio, network parameters, bar code parameters can be done using
the Intermec configuration utility on the terminal. This utility can be started by
choosing Start -> Programs -> Configuration.

Once you have the terminal radio and network parameters configured and the terminal can
be communicated with over the network, you can point a we browser to the terminal's IP
address and the Intermec Data Collection PC Unit Manager web page on the terminal will
come up. You'll be prompted for a password, which defaults to 'intermec'.

The Unit Manager allows you to configure the terminal, transfer files, install
applications as well as other operations.

Intermec 5020 Bar Code Configuration
------------------------------------
By default, the Intermec 5020 is configured to handle any of the bar code
symbologies that it supports. To make sure the ones that you will need are
supported, consult the Intermec 5020 Data Collection User's manual.

Also by default, bar code input is routed through the keyboard and a tab
character is automatically appended to the end. In most situations while
running DCConnect transaction programs, the tab will need to be replaced
by a carriage return character. The default tab character is defined as
a postamble character under the keyboard wedge configuration, it can be
changed to a carriage return by using one of three methods.

1) The first method is to start the Web browser of your choice. Enter the
TCP/IP address of the terminal you are configuring into the browser address
field. The browser will connect with the terminal and display the Intermec
Unit Management signon screen. Enter the password if it has been configured
or just click the button to continue to the next screen. Click the
"Configuration" item from the list left side of the next screen. On the
configuration screen click on the "Data Collection" icon. Click on the
"Virtual Wedge" tab, then click "postamble". Enter a '\r'(carriage return)
into the entry field and click the Apply button to complete the change.

2) The second way that the postamble can be set, is by starting the
configuration utility from the terminal's system menu. Select the
configuration pull down menu and take the "Data Collection" option. Select
the "Wedge" tab and change the postamble option from '\t'(Tab) to '\r'
(carriage return). (Tip: There is no lower case 'r' character on the 5020
keyboard. This character can be entered by pressing and holding the Alt key
while typing the 114 keys).

3) The Third method is to scan the configuration changes into the terminal.
Refer to the Intermec 5020 Data Collection PC User's guide for information
on using this method.

Once the carriage return is configured the data coming from the scanner will
look the same to the Client as if it was entered by way of the keyboard.

In order to change the default preamble and postamble characters in the 5020
terminal, you can use any one of the methods above and set preamble and
postamble character. These must match the same values used in the EMULATOR.INI
for the SCAN_SENTINEL_CHARS keyword. You should choose character values that
would not normally be entered at the terminal. For more about this keyword,
see Keyword: SCAN_SENTINEL_CHARS.

Rebooting the Intermec 5020
---------------------------
To warm boot the terminal (necessary to use font files) - use a paper clip
to press quickly in the small hole above the right enter key.

On a warm boot, the system reboots without changing the 5020 settings or
files.

To cold-boot the terminal, press and hold the power button (yellow at bottom
right of the keyboard) and use the paper clip in the hole above the right
enter key. After you pull the paper clip out, release the power button.

Only the network settings and scanner selection are preserved and restored
on a cold boot. All other settings revert to the default factory settings.
The set of files on the terminal also reverts back to its default - except
for those files that are on the non-volatile \Storage Card. A cold-boot
also sets the date and time back to 12am on June 1, 2001.

Note: Do not activate the scanner during the boot process or the 5020
will be unable to complete the boot. If the scanner is
accidentally activated during the boot process, reboot again.

Intermec 5020 Keyboard Notes
----------------------------
To bring up the Start Menu on the Intermec 5020, press and release the green
modifier key (next to the I/O button) and then press the 3 key. You can then
use the arrow keys to scroll through the list. Press Enter when the proper
selection is highlighted.

To lock the 5020 keyboard into alpha character mode (so that you don't have to
press the brown modifier key before each letter), press and hold the brown
modifier key until you her a tone. This will lock the keyboard into
alpha character mode. When you want to get out of alpha character mode, press
and release the brown modifier key again.

Note: Refer to Intermec's 5020 Data Collection PC Getting Started for more
information on using the 5020 keyboard.

Intermec 5020 Screen Notes
--------------------------
The Intermec 5020 has a 1/4 VGA screen for which the screen
dimensions 16x20 fit very nicely. That is why the statements:

NUM_ROWS = 16
NUM_COLS = 20

are included in the sample EMULATOR.INI - found in the
IMEC5020\SAMPLE directory where the Client product files are
installed.

Of course the more rows and columns that you try to fit on
the screen the smaller the font has to be and as a result
the characters may become too small for practical use.

You also have the option to change which font is being used, as
long as you select a non-proportional font. For more info, see
Changing the Font Used By the Client on a Windows CE Device.

Because the Intermec 5020 is not a Pocket PC device, the Client
cannot be run in "full-screen" mode.

Notes About Building the Intermec 5020 .CAB File
------------------------------------------------
A sample .INF file for building the .CAB for Intermec 5020 terminals
is found in the DCConnect Client product files in IMEC5020\SAMPLE\IMEC5020.INF.
Here are some notes about the contents of that file:

- The font file must be installed to the \Windows directory instead of
\Windows\Fonts.

- The short cut for starting the Client is installed to the Programs folder (%CE11%)
instead of the normal Start menu (%CE17%). For some reason the name that
ends up in the Programs folder is the name of the executable (etspt.exe)
rather than the name of the shortcut.

Loading and Installing the Intermec 5020 .CAB File
--------------------------------------------------
There are a couple of ways to install the .CAB file onto the Intermec 5020. If
the terminal has a removable compact flash card, then you can simply copy the .CAB
file to that card from your PC (using a PCMCIA compact flash adapter). Once you
put the flash card back into the terminal, you can use the File Explorer to
click on the .CAB file and install it.

The Client .CAB file can also be loaded and installed by using a browser (e.g. Netscape,
Internet Explorer, ...). Before the installation process can begin, you must be
able communicate with the terminal using TCP/IP. The terminal and access point
must be configured and must be able to respond to pings from the PC server.

You must define the minimum following network parameters on the 5020 terminal before
it can communicate in a RF network:

IP address
Subnet mask
Default router

If the 5020 has a Proxim radio, then, at a minimum, you will need to set
the following parameters to match the access points in use:

Domain
Security ID

If the 5020 has a Lucent 802.11 radio, then, at a mimimum, you will need
to set the following parameter to match the access points in use:

Network Name

Setting the above listed parameters on the 5020 terminal is documented in
the Intermec 5020 Data Collection PC User's manual under "Configuring the
Computer". The basic steps are to do the following:

1) Press and release the green modifier key next to the [i/o] button
on the bottom row of the terminal keyboard.

2) Press the [3] key. This will display the System Menu.

3) Using the up arrow key, scroll up the menu item list to select
"Programs". Press the right arrow key, this will display an
additional menu. Using the down arrow key, scroll down the menu
and select "Configuration". Press enter to start the configuration
utility.

4) Press and release the brown modifier key on the bottom row of the
keyboard, then press the Alt key followed by the 'C' key. This
will display the Configuration pull down menu. Scroll down the menu
and enter the Network option.

5) The items you need to define are under the Radio tab. Press the Ctrl
key followed by the Tab key to select the Radio tab. Use the Tab key
to select the "IP Address" item. Once an item is selected the right
and left arrow keys will expand and contact the item list. Expand
the "IP Address list and configure the "IP Address", "Subnet mask",
and "Default router" options.

6) Scroll down to the "Radio" item and expand this list. Scroll down to
the "Domain" option and configure it to match your access point value.

7) Using the tab key select the "Apply" button and press enter to complete
the configuration.

8) Press the brown modifier key, then the Alt key following by the 'F'
key. This will display the File pull down menu. Scroll down and enter
the "Exit" item to close the Configuration utility.

Before you continue with the DCConnect Client product installation, be sure you
can ping both the access point and the terminal.

Start the Web browser of your choice. Enter the TCP/IP address of the terminal
you just completed configuring into the browser address field. The browser will
connect with the terminal and display the Intermec Unit Management signon screen.
A password hasn't been configured, just click the button to continue to the next
screen. Click the "Application Manager" item from the list left side of the next screen.

The Application Manager is used to install and uninstall .CAB files onto the
5020 terminal.

Use the following steps to install the DCConnect Client .CAB file:

1) In the Install section of the Application Manager, use the Browse button
to locate your 5020 .CAB file for the DCConnect Client. There is also a
sample Client .CAB file that is located in the IMEC5020\SAMPLE directory
where the Client product files are installed.

Press the Open button on the 'Choose file' dialog when you have located
your .CAB file.

2) Click the Install button to start the installation process. First the
.CAB file has to be transferred which should take a half a minute to a
minute depending on its size.

3) When the .CAB file has been transferred, the installation will begin on
the terminal. You will be prompted for the location in which to install
the DCConnect Client. The default will be \Storage Card\DCConnect Client
and the 'Name' field will probably say '(Install here)'. Just press Enter
to accept this location.

4) Files will now be copied and the other .CAB file installation operations
will be performed. You should end up with a pop-up indicating setup
is complete. Press Enter to clear that pop-up.

If the product installed correctly, the new entry 'etspt.exe' will display on
the Start Menu in the Programs folder. On the terminal, press and release the
green modifier key, then press the '3' key to display the Start menu. Then
choose the 'Programs' entry. If you do not see 'etspt.exe' you can upload
\Windows\Setup.log to determine whay may have gone wrong.

After the .CAB file is installed, the terminal must be warm-booted (using the
paper clip in the hole above the right enter key) in order for the installed font
file to be registered with Windows CE.

Terminal-Specific Issues for the Intelligent Instrumentation LanPoint CE Terminal
---------------------------------------------------------------------------------
The best place to get information about the LanPoint CE is from the manuals
provided by Intelligent Instrumentation for the LanPoint CE. The following
manuals can be found on Intelligent Instrumentation's website, http://www.lanpoint.com:

LANPoint CE Installation and Maintenance Manual
LANPoint CE Developer's Manual
LANPoint CE Quick Start Guide

The sections listed below cover various topics from that documentation plus other
information specific to the DCConnect Client:

- LanPoint CE Hardware and Software Requirements
- How to Configure the LanPoint CE
- LanPoint CE Bar Code Configuration
- Rebooting the LanPoint CE
- LanPoint CE Keyboard and TouchScreen Notes
- Notes About Building the LanPoint CE .CAB File
- Loading and Installing the LanPoint CE .CAB File

LanPoint CE Hardware and Software Requirements
----------------------------------------------
The LanPoint CE terminal comes with non-volatile CompactFlash storage
that is given the directory name \Storage Card. This is where the
DCConnect Client files should be installed so that transactions are
written to non-volatile storage.

This is also where the Windows CE operating system resides and boots
from. When registry updates are saved to non-volatile storage, they
are written to a file called IIICEREG.DAT.

The LanPoint CE includes the following hardware features, some of
which are options:

- Built-in ethernet RJ45 10/100 Base-T connector
- 9-pin Serial ports COM1 and COM2
- PS/2 mouse and keyboard connectors
- PCMCIA type I, II, III
- Digital I/O (not currently supported by the Client)
- Battery backup
- External VGA connector
- Wand/wand emulatation laser Bar Code port
- Undecoded LAser port
- Slot reader port
- 69-key QWERTY keyboard
- Touch screen

If using a mouse or external keyboard, these devices must be
attached before the terminal is powered on in order for them
to be recognized.

The LanPoint CE has the option to use a Wireless Ethernet card
to communicate rather than the built-in ethernet port. A separate
manual is used to describe installation and configuration of
wireless hardware:

LanPoint CE Wireless Ethernet Supplement to the
Installation and Maintenance Manual

How to Configure the LanPoint CE
--------------------------------
There are several ways to configure the LanPoint CE
terminal:

- Using the appropriate icon(s) in the Windows CE Control
Panel (Start -> Settings -> Control Panel).

- Once the network parameters are defined and the terminal
is successfully communicating on the network, the Remote
Manager Utility (a web-based application) can be accessed
by entering the terminal's IP address into your favorite
browser. On the terminal the WebDevice application must
be running. It is called WDCE.exe and is located in the
\Storage Card\mgmt directory. For more information about
using the Remote Manager Utility, refer to the LanPoint CE
Developer's Manual.

The WebDevice utility consumes a lot of resources and
therefore cannot be run at the same time as the DCConnect
Client or it will degrade the performance of the Client.

- The following parameters:

IP address Gateway Subnet WINS address
DHCP DNS I/O Space Host controller IP

can be set via Serial cable and the use of the Monitor
program (MonitorCE.EXE) which starts up automatically
whenever Windows CE is started. A serial communications
program such as HyperTerminal must be used to communicate
with the Monitor program.

The program on the PC (e.g. HyperTerminal) must be
configured to talk to the serial port using the
communication parameters:

9600 baud, no parity, 8 data bits, 1 stop bit

The ASCII setup must have the following values
set:

Send line ends with line feeds
Send CR/LF at the end of each line

Special commands must be sent to the terminal for
each parameter that is to be configured. Please see
the LanPoint CE Developer's Manual for these commands
and more information about the Monitor program.

- Because the terminal settings are written to the
registry, the IBM CE Config tool can be used to
configure the LanPoint CE terminal. However, unlike
the Intermec 700, none of the Visual Basic files
are preloaded on the LanPoint CE; therefore you
must be sure to include all the required files in
the DCConnect Client .CAB file. For more information
about which files are needed and for complete
information about the IBM CE Config tool, please see
IBM CE Configuration Tool.

As of this writing, we have not yet identified which
registry keys should be updated. So you would have
to use the Remote Registry Editor of the Microsoft
eMbedded Visual C++ or Visual Basic toolkit.

- The LanPoint CE documentation also refers to a tool
that uses Telnet to access the terminal.

No matter what method is used to update the LanPoint CE
configuration in the registry, it is very important that
the registry be saved to non-volatile storage after the
changes are made. Otherwise the changes will be lost
when the terminal is restarted. There are two utilities
available to flush the registry to non-volatile storage.
The first one is the preferred one:

- The LanPoint CE includes a program called CEFlush.exe
(in the \Storage Card directory) that when run,
updates the registry to non-volatile storage and then
ends itself. This should be run after you have made
a change or set of changes to the terminal
configuration. If using the IBM CE Config Tool, then
before rebooting, the RUN_PROGRAM command should be
used to run CEFLush.exe.

- The second method uses a program called RegScan that
loads itself into memory and puts an icon in the
system tray. RegScan automatically scans for changes
every 15 seconds and updates non-volatile storage.
You can also double click the icon in the system
tray to have the update occur immediately. The
update of non-volatile storage takes about 5 seconds.

The problem with this method is that with RegScan
loaded into memory, you get the 5 second delay
every 15 seconds - which has a negative impact on
other programs running on the terminal - including
the DCConnect Client.

See the "LanPoint CE Developer's Manual" for more
information about these tools.

LanPoint CE Bar Code Configuration
----------------------------------
By default the LanPoint CE activates all bar code
symbologies that it supports. These include:

Code 3 of 9 Code 128
Code 16K Interleaved 2 of 5
Code 11 Industrial 2 of 5
UPC/EAN Matrix 2 of 5
MSI Plessey
Codabar

To change the active bar code symbologies and
their settings, you can use the Remote Manager
Utility described in the previous section.
These settings are maintained in the registry.
Therefore the IBM CE Config Tool can be used as
well - if you can determine which registry keys
should be updated.

Once the registry has been updated the terminal
will need to be rebooted before the changes take
effect. A utility called LPBLoad automatically
runs each time the terminal is powered on or
rebooted. This utility tests the bar code
controller and then retrieves the bar code
settings from the registry and loads them into
the bar code controller.

In order for the Client to receive scanner input,
the scanner input must be routed through the keyboard
using the WedgeCE.exe utility, located in the
\Storage Card directory. On the LanPoint CE, an
internal COM3 port is where the bar code scanners
send their inputs. The WedgeCE utility must be
told to grab the scanner data from COM3 and send
it to the keyboard. WedgeCE can also be used to
get serial input from the terminal's COM1 and COM2
ports and route that to the keyboard. Please refer
to the "LanPoint CE Developer's Manual" for
information about how to run the WedgeCE utility.

The LanPoint CE supports the settings of preamble
and postamble characters for bar codes. Therefore
these can be set in conjunction with the use of
the keyword SCAN_SENTINEL_CHARS in EMULATOR.INI to
allow the Client to distinguish between keyboard
and scanner input even though both come through
the keyboard. For more info, please see
Keyword: SCAN_SENTINEL_CHARS.

Rebooting the LanPoint CE
-------------------------
The LanPoint CE can be rebooted by powering it off or by
choosing the Restart option from the Windows CE Start menu.

Regardless of which way the terminal is rebooted.
only those files that were created on the \Storage
Card are preserved. All other diretories are set
to their defaults during the boot up process. The
registry is restored from its latest update that
was written to the file IIICEREG.DAT in the
\Storage Card directory.

LanPoint CE Keyboard and TouchScreen Notes
------------------------------------------
Unlike many smaller Windows CE devices, the LanPoint CE
has a complete keyboard and it therefore does not have
the need for a software keyboard.

Here are a few notes from the LanPoint CE documentation
about certain key / key-combinations. For each
combination, press and hold the first key while you press
and release the second key, then release the first key.

Ctrl+Esc = Opens the Windows CE Start menu
Esc = Cancels or closes current menu or dialog
Tab = Moves cursor between controls in a dialog
or to the next item in a drop-down list
Ctrl+tab = Moves cursor between tabs in a dialog -
from left to right
Alt+Tab = Opens the task manager window
Alt+x = Selects and opens menu item 'x' where 'x'
is the underlined letter in a menu item
Shift+x = Selects and opens sub-menu item 'x' where
'x' is the underlined letter in a sub-menu
name.
Ctrl+Arrow = Moves cursor to next word in a text field -
in the direction of the arrow pressed
Alt+Arrow = Opens a drop-down list
Shit+Arrow = Selects a letter in a text field
Shift+Ctrl
+Arrow = Selects a word from a text field
Enter = Changes made to settings are sent to
the Windows Registry, then flushed
to CompactFlash by RegScan
c = Closes a sub-menu item
Ctrl+c = Copies selected item to clipboard
Ctrl+v = Pastes clipboard contents
Ctrl+x = Cuts and places selected item in clipboard

The LanPoint CE also has a touchscreen that responds like a
mouse. Tapping the screen once on a menu item causes the same
response as left-clicking a mouse. Two quick taps generate
a double left-click response. Pressing and holding the Alt
key while tapping the screen results in the same response as
right-clicking a mouse.

The touchscreen can be recalibrated using the program TchCal.exe
which can be found in the \Storage Card directory.

LanPoint CE Screen Notes
------------------------
The LanPoint CE is available with either a monochrome
or color display. However, even if a color display is
installed, the DCConnect Client currently only shows its
text as monochrome characters.

The LanPoint CE has a 1/2 VGA screen (640 x 120 pixels) for
which the screen dimensions 8x40 fit very nicely. That is
why the statements:

NUM_ROWS = 8
NUM_COLS = 40

are included in the sample EMULATOR.INI - found in the
LANPTCE\SAMPLE directory where the Client product files are
installed.

Of course the more rows and columns that you try to fit on
the screen the smaller the font has to be and as a result
the characters may become too small for practical use.

You also have the option to change which font is being used, as
long as you select a non-proportional font. For more info, see
Changing the Font Used By the Client on a Windows CE Device.

Because the LanPoint CE is not a Pocket PC device, the Client
cannot be run in "full-screen" mode.

Notes About Building the LanPoint CE .CAB Files
-----------------------------------------------
If you will be using the IBM CE Config Tool be sure to
include in the .CAB file, all of the required Visual
Basic files; the LanPoint CE does not include any of
the Visual Basic files by default.

The sample .INF file for building the .CAB for the LanPoint CE
is provided where the DCConnect Client files are installed in
the directory lanptce\samples\lanptce.inf

Loading and Installing the LanPoint CE .CAB File
------------------------------------------------
The .CAB file can be transferred and installed to the
LanPoint CE terminal using one of the following
methods:

- Remove the CompactFlash card from the terminal and
load the .CAB file onto it from a PC that has a
PCMCIA CompactFlash adapter. After the card is
reinserted into the LanPoint CE, you can use the
Explorer to find the .CAB file on the \Storage Card
and then click on it to install.

Note: Early versions of the LanPoint CE had a
problem that prevented the .CAB file from
being installed if it was on the \Storage Card.
You'd get a message about needing to double-
click to install - when in fact that is what
you just did. If you have this problem, move
the .CAB file to the root directory or \Windows
directory and then double-click on it.

- Use the Remote Manager Utility to transfer and
install the .CAB file.

After the .CAB file is installed, be sure to use the CEFlush
or RegScan utility to ensure that the registry is saved to
non-volatile storage. The Client uses a registry entry to
locate its configuration and license files. If the terminal
is rebooted without saving the registry, this registry entry
will be lost and the Client will not be able to run.

After the registry has been saved, the terminal should be
rebooted - especially if a font file is installed.

Terminal-Specific Issues for the Symbol 81xx Terminal
-----------------------------------------------------
The following sections below cover various topics for the Symbol 81xx terminal:

- Symbol 81xx Hardware and Software Requirements
- How to Configure the Symbol 81xx
- Symbol 81xx Bar Code Configuration
- Rebooting the Symbol 81xx
- Symbol 81xx Keyboard Notes
- Symbol 81xx Screen Notes
- Notes About Building the Symbol 81xx .CAB File
- Loading and Installing the Symbol 81xx .CAB File

Symbol 81xx Hardware and Software Requirements
-----------------------------------------------
The Symbol 81xx terminal comes with non-volatile storage that is
given the directory name \Application. This is where the DCConnect
Client files should be installed so that transactions are written to
non-volatile storage.

An optional compact flash card can be installed for additional
non-volatile storage - and as a way of transferring files to
the terminal. If installed, this storage is given the directory
name \Data.

The Symbol 81xx terminal can be loaded using Microsoft ActiveSync.
This requires the use of a serial cable attached to the bottom of
the terminal or to a dock or the use of the infrared port. Once an
ActiveSync partnership has been established serially or via
infrared, an ActiveSync connection can then be made over the radio.
If you have large files to transfer, registry searching to do or
remote debugging to do, using ActiveSync over the radio will be
much faster.

The Symbol 81xx does support infrared for transferring files
without having to have established an ActiveSync partnership. Any
file that is transferred shows up in the 'My Documents' folder. A
.CAB file can be transferred this way and can then be installed.
However, after the install the .CAB file is deleted because this
kind of transfer does not set the read-only attribute even if the
file on the PC had the read-only attribute set.

Use of the scanner on the Symbol 81xx with the DCConnect Client
requires the use of the ScanWedge utility that is provided as
part of the Symbol Windows CE SDK. This SDK is available as a
free download from the Symbol website. Start at:

Symbol Developer Zone

If not already registered, click the 'New Customers' link.
Otherwise sign-in and select 'Developer Downloads' on the
left followed by the link under 'PocketPC/WinCE Platforms'.
Then select the 'PDT 8100 Windows CE SDK v1.00' or
'PDT 8100_2002 Windows CE SDK v1.00' depending on
whether the Symbol terminal you have is loaded with
the original Pocket PC or Pocket PC 2002.

How to Configure the Symbol 81xx
--------------------------------
On the Symbol 81xx, you can use the Settings option from the Start
Menu to manually configure device Settings options such as those for
Spectrum24 Setup (on the System tab) and for Network (on the
Connections tab).

The Symbol 81xx setting are maintained in the registry; therefore you
can use the IBM CE Config Tool to set these values rather than manually
setting up every terminal. For more information about this tool please
see IBM CE Configuration Tool.

The DCConnect Client product files includes a sample CECONFIG.INI (in
the directory SYM81XX\SAMPLE) that we used during testing. The registry
settings contained within were sufficient to reconfigure the terminal
after a cold-start so that it could run the DCConnect Client and
communicate with the DCConnect Server that had a Lucent 802.11 radio card.

Personal Tab
------------

Owner Information (Name, Company, Address, Telephone, E-mail)

HKEY_CURRENT_USER\ControlPanel\Owner, Owner (REG_BINARY)

// See default CECONFIG.INI for example of how to define the parts

Sounds & Reminders/Notifications (System Volume)

HKEY_CURRENT_USER\ControlPanel\Volume, Volume (REG_DWORD)

// The 6 possible levels correlate to the following values:
// 0, 858993459, 1717986918, 2576980377, 3435973836, 4294967295

Today (Display Today screen if device is not used ... for ?? hours

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shell\Rai, SessionTimeout (REG_DWORD)

// Set to 0 to disable switching to Today screen

System Tab
----------

About, Device ID Tab (Device name)

HKEY_LOCAL_MACHINE\Ident, Name (REG_SZ)

// This is the Partnership name

Backlight, Battery Power tab (Turn on backlight when ... is tapped)

HKEY_CURRENT_USER\ControlPanel\Backlight, BacklightOnTap (REG_DWORD)

// Set to 1 to enable turning on the backlight whenever screen is tapped

Spectrum24 Setup, (802.11 ESSID)

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms, ESS_ID (REG_SZ)

Spectrum24 Setup, Advanced, Mobile Unit Tab (Operating Mode)

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms, PortType (REG_DWORD)

// 1=ESS (Infrastructure), 3=PIBSS (Enhanced Ad-Hoc), 4=IBSS (Ad-Hoc)

Connections Tab
---------------

Network Adapters, 802.11b Wirless LAN, IP address tab (Use specific IP address)

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms\TcpIp, EnableDHCP (REG_DWORD)

// Set to 0 to use specific IP address; set to 1 to Enable DHCP

Network Adapters, 802.11b Wirless LAN, IP address tab (IP Address)

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms\TcpIp, IpAddress (REG_MULTI_SZ)

Network Adapters, 802.11b Wirless LAN, IP address tab (Subnet mask)

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms\TcpIp, Subnetmask (REG_MULTI_SZ)

Network Adapters, 802.11b Wirless LAN, IP address tab (Default gateway)

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms\TcpIp, DefaultGateway (REG_MULTI_SZ)

Network Adapters, 802.11b Wirless LAN, Name Servers tab (DNS):

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms\TcpIp, DNS (REG_MULTI_SZ)

Network Adapters, 802.11b Wirless LAN, Name Servers tab (WINS):

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms\TcpIp, WINS (REG_MULTI_SZ)

On the bottom right corner of the today screen is a small icon that can
be used to bring up the Network Interface Card Task Tray (NICTT) utility
which provides a quick way to view or change some of the network and radio
parameters. The registry keys below are used to store the values shown
by the NICTT utility. Most of these keys have counterparts listed above.
All the Values listed below are part of the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Symbol Technologies, Inc.\NICTT

The following list shows the key value and its type for some of the
options in the utility:

Location in Utility Value Name Type
------------------- ---------- ----
Mode tab (802.11 ESSID) ESSID0 REG_SZ

IP Config tab (DHCP / Static) EnableDHCP REG_DWORD
IP Config tab (IP Address) IpAddress REG_MULTI_SZ
IP Config tab (Subnet Mask) Subnetmask REG_MULTI_SZ
IP Config tab (Gateway) DefaultGateway REG_MULTI_SZ
IP Config tab (DNS) DNS REG_MULTI_SZ
IP Config tab (WINS) WINS REG_MULTI_SZ

The utility presents other options to change, including the Operating mode
and Channel. These apparently change the actual values in the key:

HKEY_LOCAL_MACHINE\Comm\NETWLAN1\Parms

'Operating mode' corresponds to the 'PortType' value name - as was
described above under the System Tab. 'Channel' is found under
this key as well.

Below are listed other values found under this key. To figure out how
they should be set, you will need to use the NICTT tool and/or Spectrum 24
utility on the Settings -> System tab to change the settings as needed and
the use the Remote Registry Editor to view how the values are set.

KerberosRealm
KerberosKDC
EncryptionKey4
EncryptionKey3
EncryptionKey2
EncryptionKey1
EncryptionKeyId
KerberosEnable
MUEncryptionAlgorithm
Diversity
IntlRoaming
LongPreamble
Adhoc_TxPower
Ess_TxPower
PowerIndex
PowerMode

The ScanWedge Utility which is required for running and configuring
the scanner, uses the following base registry key to store all of
its options:

HKEY_CURRENT_USER\Software\Symbol\ScanWedge

Listed below are the set of value names that the ScanWedge tool looks
for to configure the scanner. For each is given the type and the
default setting that is assumed if the value is not defined in the
registry:

Default
Value Name Type Assumed Comments
---------- ---- ------- --------
Scanner REG_SZ "SCN1"
Type REG_DWORD 1 0=foreground 1=background 2=monitor
All REG_DWORD 1 0=all symbologies disabled, 1=enabled
UPCE0 REG_DWORD 1 0=disabled 1=enabled
UPCE1 REG_DWORD 1 0=disabled 1=enabled
UPCA REG_DWORD 1 0=disabled 1=enabled
MSI REG_DWORD 1 0=disabled 1=enabled
EAN8 REG_DWORD 1 0=disabled 1=enabled
EAN13 REG_DWORD 1 0=disabled 1=enabled
CODABAR REG_DWORD 1 0=disabled 1=enabled
CODE39 REG_DWORD 1 0=disabled 1=enabled
D2OF5 REG_DWORD 1 0=disabled 1=enabled
I2OF5 REG_DWORD 1 0=disabled 1=enabled
CODE11 REG_DWORD 1 0=disabled 1=enabled
CODE93 REG_DWORD 1 0=disabled 1=enabled
CODE128 REG_DWORD 1 0=disabled 1=enabled
PDF417 REG_DWORD 1 0=disabled 1=enabled
AutoTab REG_DWORD 0 0=Don't send tab at end, 1=send tab
AutoEnter REG_DWORD 0 0=Don't send enter at end, 1= send enter
Binary REG_DWORD 0 0=Convert ASCII to UNICODE, 1=no conversion
Data REG_DWORD 1 0=Don't send barcode data, 1=send data
Prefix REG_SZ "" Character(s) to add before barcode data
Suffix REG_SZ "" Character(s) to add after barcode data

The 'All' setting either disables or enables all symbologies. If 'All' is
set to 1 and specific symbologies (e.g. UPCE0, EAN13, CODE11, ...) are
defined in the registry and have a value of 0, then those specific
symbologies will be disabled and all others not in the registry will be
enabled.

Conversely, if 'All' is set to 0, then all symbologies are disabled
unless specific symbology value names are defined and their value is 1.

Symbol 81xx Bar Code Configuration
----------------------------------
By default, the Symbol 81xx does not activate scanning or
provide settings to make scanning work. However, part of
the Symbol Windows CE SDK includes a tool called
SCANWEDGE.EXE that can be used to route scanner input
to the keyboard. ScanWedge.exe also uses settings in
the registry for configuring which symbologies are
enabled and what prefix and suffix characters should
be appended to each bar code that is scanned. See
the previous section for a description of where in
the registry these settings can be found.

Because the scanner settings are maintained in the
Windows CE registry, you can use the IBM CE Config Tool to
configure all the bar code related settings rather than having
to do this manually for every terminal that must be set up.

In order for the DCConnect Client to be able to distinguish
between keyboard and scanner input, you should set up a
'Prefix' and 'Suffix' character (e.g. { and } ) in the
registry and then be sure to tell the DCConnect Client
which characters were used by including the
SCAN_SENTINEL_CHARS keyword in EMULATOR.INI. For example:

SCAN_SENTINEL_CHARS = 123, 125

For more information about this keyword, please refer to
Keyword: SCAN_SENTINEL_CHARS.

If the Client does not need to distinguish between
scanner and keyboard data, then you can eliminate
the use of the SCAN_SENTINEL_CHARS keyword in
EMULATOR.INI and the setting of the 'Prefix' and
'Suffix' values in the registry. However, you
should set to 1 the 'AutoEnter' registry value
described in the previous section.

When installing the DCConnect Client, be sure to
include the ScanWedge.exe in the DCConnect Client .CAB
file and make sure a shortcut is created for it in the
Startup folder. The sample .INF file provided with
the DCConnect Client (SYM81XX\SAMPLE\SYM81XX.INF)
includes commented out statements for including the
ScanWedge.exe tool and for setting up the shortcut
in the Startup folder.

While the ScanWedge tool is running, if you go to
the Today screen you will see a triangular bar code
icon with a red laser line in the bottom right
corner. If you tap this icon you will be presented
options to enable/disable the scanner or to bring
up the 'Show UI' screen which lets you test bar
code scanning.

Rebooting the Symbol 81xx
-------------------------
To warm boot the Symbol 81xx, which preserves all files and
registry settings, press and hold the appropriate key
combination listed below:

28-key = Backlight + Down arrow + Function
37-key = Backlight + Alpha + Function
47-key = Backlight + End + Function

To cold-boot the Symbol 81xx, you must press and
hold the Func key and then use the tip of the
stylus to gently press the reset button that is on
the right side under the battery cover. Then
replace the battery cover and turn on the terminal.

Symbol 81xx Keyboard Notes
--------------------------
Symbol has different models of the 81xx series of terminal
with different numbers of keys. Refer to the Symbol
documentation for information about how to use them. On a
couple of models there is an 'Alpha' key that must be
pressed to switch the terminal to a mode where the keys
generate alphabetic characters instead of numbers and
symbols. Once pressed the terminal remains in the Alpha
mode until the Alpha key is pressed again. There does not
appear to be any indication on the terminal as to whether or
not the Alpha mode is currently active.

In addition to the physical keyboard, the Windows CE Pocket PC
environment also supports a software keyboard that you use your
stylus with to type the appropriate keys.

Symbol 81xx Screen Notes
------------------------
The Symbol 81xx has a 1/4 VGA screen for which the screen
dimensions 16x20 fit very nicely. That is why the statements:

NUM_ROWS = 16
NUM_COLS = 20

are included in the sample EMULATOR.INI - found in the
SYM81XX\SAMPLE directory where the Client product files are
installed.

Of course the more rows and columns that you try to fit on
the screen the smaller the font has to be and as a result
the characters may become too small for practical use.

You also have the option to change which font is being used, as
long as you select a non-proportional font. For more info, see
Changing the Font Used By the Client on a Windows CE Device.

The Symbol 81xx can be configured to turn on the backlight
any time the screen is tapped by the stylus. The option
to change this is accessed from the Backlight icon on the
System tab of the Start -> Settings screen. You can set
this option separately for when the terminal is running
on battery and when it is running on AC power.

Like any other settings, these options may be changed
in the registry using the IBM CE Config Tool. To
find out which registry key must be updated, please see
How to Configure the Symbol 81xx.

Because the Symbol 81xx is a Pocket PC device, the Client
can be set up to run in "full-screen" mode - which means
while the Client is running the terminal user cannot get
to any other application on the device. This is done
using the following keyword in EMULATOR.INI:

FULL_SCREEN = Y

and including ETSUSER.DLL in the DCConnect Client .CAB file.
For more information about full-screen mode, please see
Keyword: FULL_SCREEN.

Notes About Building the Symbol 81xx .CAB Files
-----------------------------------------------
A sample .INF file for building the .CAB for Symbol 81xx terminals
is found in the DCConnect Client product files in SYM81XX\SAMPLE\SYM81XX.INF.
Here are some notes about the contents of that file:

- In the [CEStrings] section the InstallDir is set to "\Application\%AppName%"
instead of the more common "\Storage Card\%AppName%" because \Application
is the name of the non-volatile storage on the Symbol 81xx terminals.

- In the [SourceDisksNames.sym81xx] section notice that the product
executables use directory identifier 7 and that is defined to be
the ..\..\imec700 directory - which of course are the same executables
used for the Intermec 700. This is done because both the Intermec 700
and Symbol 81xx terminals run Windows CE 3.0 with the Intel StrongARM
processor. In the [SourceDisksFiles] and [SourceDisksFiles.sym81xx]
sections, the files that reference directory identifier 7 are etspt.exe,
etspt.dll and etsuser.dll.

- There are commented out references to Files.Symbol and Shortcuts.Symbol
which are for installing the Symbol ScanWedge.exe utility. In order
to use the scanner, you will need to get this utility from the Symbol
Windows CE SDK and uncomment the references to it in the .INF file. For
more information about this utility please see the section above
Symbol 81xx Bar Code Configuration.

- Full screen mode is set up by default by including
ETSUSER.DLL and by including an EMULATOR.INI that
contains the statement FULL_SCREEN=Y.

- There are commented out references to files and
shortcuts for the IBM CE Config tool.

Loading and Installing the Symbol 81xx .CAB File
------------------------------------------------
Whether you use Microsoft's ActiveSync or you copy files directly
to the compact flash card, be sure to copy the DCConnect Client
.CAB file to the \Application directory so that it is in
non-volatile storage. This preserves it in the event the
terminal is cold-boot or has a total loss of battery power.

Unlike the Intermec 700 terminal, there is no special directory
into which you can place the .CAB file to have it automatically
installed after a warm reboot or cold-boot. Therefore after
the file is transferred to the terminal you must use the
File Explorer (Start -> Programs -> File Explorere) to locate
the .CAB file. Once you've located it, tap the icon once to
install it.

If you are using the IBM CE Config Tool, you can run that
as soon as the .CAB file installation completes. This
process will typically include a reboot of the terminal.

If you are not running the CE Config Tool, after the .CAB
file is installed, the terminal must be warm-booted in
order to have any font file registered. Please see
Rebooting the Symbol 81xx.

Terminal-Specific Issues for Non-Pocket PC, StrongARM Compatible Devices
------------------------------------------------------------------------
This section gives a few notes about devices that are similar to the Intermec
700 or Symbol PDT81xx terminals as far as processor and Windows CE version are
concerned but that are not Pocket PC devices. Two such devices are:

Group Mobile MA1000 Intel StrongARM processor Windows CE 3.0
Symbol PPT 88xx Intel XScale processor Windows CE .NET

Because these devices are not Pocket PC devices, they do not include the AYGSHELL.DLL
that the Intermec 700 flavor of the Client uses to implement the FULL_SCREEN option in
EMULATOR.INI. So in order for the Client to run on these devices, you must use the
flavor of the Client provided in the following product directory:

.\ARMNOPPC

The ETSPT.EXE and ETSPT.DLL in this directory will run on non-Pocket PC devices (they'll
also run on Pocket PC devices) with a StrongARM or compatible processor and Windows CE
3.0 or later compatible version.

When building CFRs for non-Pocket PC devices of this type, you can still use the CFRAPICE.LIB
and other libraries and samples CFRs from the .\CFRTOOLS\IMEC700 directory because
AYGSHELL.DLL is not required by any of the CFR libraries or samples.

Building of .CAB files for non-Pocket PC devices of this type can also be done in a manner
similar to that for the Intermec 700. Just don't try to use the CE Config Tool (it requires
a Pocket PC environment) and don't use the FULL_SCREEN keyword in EMULATOR.INI.

Terminal-Specific Issues for the Intermec CK30 Terminal
-------------------------------------------------------
This section gives a few notes about using the DCConnect Client on the Intermec
CK30 terminal. This terminal uses Windows CE .NET (4.2) and has the Intel XScale
processor. Because of this, the DCConnect Client had to be built with Version 4.0 of
the Microsoft eMbedded C++ and the Intermec CK30 toolkit. This special flavor of
the Client can be found in the following product directory:

.\CK30

Also found in this directory, in the sub-directory .\CK30\SAMPLE is a sample
EMULATOR.INI, a sample .CAB file and sample .INF file used to build that .CAB file.

The EMULATOR.INI includes a couple of keywords worth noting:

FULL_SCREEN = Y
HIDE_MENU_BAR = Y

Because the CK30 has a smaller screen, the keywords above can be used to increase
the amount of the screen used by the Client. The FULL_SCREEN=Y keyword hides the
Windows CE task bar and start button while the HIDE_MENU_BAR keyword hides the
Client's own menu bar - thus requiring a key to be pressed to bring up the menus.
For more information please see Keyword: FULL_SCREEN and
Keyword: HIDE_MENU_BAR.

For information about configuring the CK30's radio parameters, network parameters,
scanner parameters, ... please refer to the User's Guide for the CK30 which is
available from Intermec's website: www.intermec.com.

When building CFRs for the Intermec CK30 you must build them using version 4.0 of
the Microsoft eMbedded C++ compiler. And you must link with the CFRAPICE.LIB that is
found in the .\CFRTOOLS\CK30 directory because that too had to be built with version
4.0 of the compiler.

Terminal-Specific Issues for the Intermec CV60 Terminal
-------------------------------------------------------
This section gives a few notes about using the DCConnect Client on the Intermec
CV60 terminal.

The CV60 can be loaded with either Windows XP or Windows CE. If loaded with XP
then use the 32-bit Windows flavor of the Client. For more details, please see
Using the DCConnect Client on Windows 95/98/Me/NT/2000/XP/7/Server.

Otherwise the terminal is loaded with Windows CE .NET (4.2). Because of this, the
DCConnect Client had to be built with Version 4.0 of the Microsoft eMbedded C++ and
the Intermec CV60 toolkit. And because the CV60 has an Intel Pentium III
processor, the executables for the CK30 will not work on it. This special flavor of
the Client can be found in the following product directory:

.\CV60

Also found in this directory, in the sub-directory .\CV60\SAMPLE is a sample
EMULATOR.INI, a sample .CAB file and sample .INF file used to build that .CAB file.

For information about configuring the CV60's radio parameters, network parameters,
scanner parameters, ... please refer to the User's Guide for the CV60 which is
available from Intermec's website: www.intermec.com.

When building CFRs for the Intermec CV60 you must build them using version 4.0 of
the Microsoft eMbedded C++ compiler. And you must link with the CFRAPICE.LIB that is
found in the .\CFRTOOLS\CV60 directory because that too had to be built with version
4.0 of the compiler.

Terminal-Specific Issues for the Symbol MC 90xx Terminal
--------------------------------------------------------
This section gives a few notes about using the DCConnect Client on the Symbol
MC 90xx terminal. This terminal uses Windows CE .NET and has the Intel XScale
processor. Because of this, the DCConnect Client had to be built with Version 4.0 of
the Microsoft eMbedded C++. Although Symbol provides an SDK for this terminal, it was
not necessary in order to build the Client for this device; nor is it necessary for
building CFRs for this device. The special flavor of the Client for this terminal
can be found in the following product directory:

.\SYM90XX

Also found in this directory, in the sub-directory .\SYM90XX\SAMPLE is a sample
EMULATOR.INI, a sample .CAB file and sample .INF file used to build that .CAB file.

When building CFRs for the Symbol MC 90xx terminal you must build them using version 4.0
of the Microsoft eMbedded C++ compiler. And you must link with the CFRAPICE.LIB that is
found in the .\CFRTOOLS\SYM90XX directory because that too had to be built with version
4.0 of the compiler.

Terminal-Specific Issues for the Motorola (Symbol) MC 91xx Terminal
-------------------------------------------------------------------
This section gives a few notes about using the DCConnect Client on the Motorola
MC 90xx terminal (formerly Symbol). This terminal runs Microsoft Windows CE 6.0 or
Microsoft Windows Mobile 6.5 Classic, or later, on the Marvell PXA320 processor.

It also features a VGA display and because of this, the DCConnect Client had to be
built with Microsoft Visual Studio 2005 C++ compiler. If you try to run the MC 90xx
executables on the MC 91xx, the Menu Bar shows up corrupted. But if the HIDE_MENU_BAR
option is in use, the MC 90xx would operate and display everything properly.

Although Motorola/Symbol provides an SDK for this terminal, it was not necessary in
order to build the Client for this device; nor is it necessary for building CFRs for
this device. In fact CFRs that were built for the Symbol MC 90xx or even the
Intermec 700 should run on the MC 91xx and compatible devices.

The special flavor of the Client for this terminal can be found in the following
product directory:

.\MC91XX

Because the only issue with the MC 90xx executables running on the MC 91xx is with
the displaying of the menu bar, files related to creating .CAB files and building
CFRs for the MC 90xx can also be use for the MC 91xx terminals.