WinHexCom - Ver. 3.11 - Shareware version for Home Users

A 32bit Windows Protocol Analyzer with ASCII and Hexadecimal Display
Features

Copyright  2000, Aerospace Software Ltd., Calgary, Canada
217 Edgedale Gardens NW, Calgary, AB, T3A 4M7, Canada
Fax: 403+241-8841, E-Mail: aerosoft@AerospaceSoftware.com, Web:
http://www.AerospaceSoftware.com
  ------------------------------------------------------------------------

Contents

   * General
   * Installation
   * Configuration
   * Half Duplex Operation
   * Full Duplex Operation
   * Logfile
   * Send Message
   * Checksum Calculation
   * Message Framer
   * HDLC Frame
   * PPP Frame
   * ICNI Frame
   * View Screen
   * Protocol Parsing
   * Message Time Stamp
   * File Transfer
   * Terminal Emulation
   * Hardware Requirements
   * RS232 Cables
   * RS422/RS484 Cables
   * Test
   * Compiling the Source Code
   * Pricing

  ------------------------------------------------------------------------

1.    General

WinHexCom is a 32bit Windows re-incarnation of the famous DOS based HexCom
protocol analyzer circa 1989.  A lot of changes have wrought the computer
industry since, not the least being that the old HexCom works decidedly
clunky under Windows 95 and almost won't work at all under Windows 98, not
to mention Windows NT, which was not even dreamed of in 1989.  So, it was
high time for an overhaul.

The design philosophy behind this program was to keep it straight and
simple.  The idea is to debug a protocol, not fight the tool.  All controls
and settings are permanently visible and only two communications ports are
supported.  More than two ports are seldom required in practice since one
can only meaningfully debug one data link at a time and with many ports,
the data display would become confusing, so two ports was set as the
logical limit.  You can run multiple instances of this program to debug 4
or more ports, but then you need a fast PC.

This program requires at least one standard PC serial communications
adapter for RS232, RS422 or RS485 operation.  RS232 is the common or garden
variety serial port frequently built into a PC.  If you need RS422 or
RS485, you'll know it.

  ------------------------------------------------------------------------

2.    Installation

There is nothing to install.  Simply copy the program files winhexcom.exe
and the key file winhexcom.key from the \bin directory to your hard disk
and run it.  The full version has a key file winhexcom.key, which must be
copied to the same directory as the executable program.

  ------------------------------------------------------------------------

3.    Configuration

Setup is simplicity itself.  By default, WinHexCom attempts to use the
first two communications ports of the PC.  If the port is already in use by
another program, or if it does not exist, WinHexCom will simply ignore the
port.  The port parameters can be set on screen.  Use the Combo Boxes to
select a different comm port, scroll to the desired speed, data width,
parity and number of stop bits.

The display can be toggled between Hexadecimal and ASCII display modes.
This allows easy analysis of serial communications between two devices.

If a comport is working properly, it's status checkbox will be ticked. If a
comport is not present, or already in use by another program, then the
status checkbox will be greyed and that port will be ignored.

  ------------------------------------------------------------------------

4.    Half Duplex Operation

The RTS output of the UART can be used to control the transmit buffer
enable of a RS485 adapter, for half duplex operation.  The Flow control
combobox, configures the behaviour of the RTS pin and is normally set to
None.  For Half Duplex operation, set the Flow control to RTS and configure
the RS485 adapter to use this pin to enable/disable the transmit driver.

WinHexCom is normally in receive mode, with RTS disabled.  When you
transmit a message from WinHexCom, it enables the RTS pin for the duration
of the message, then disables it again.  This allows one to debug two half
duplex RS485 channels effectively, using COM1 and COM2 to full capacity.
The communication is displayed in 4 colours, to enable one to see which
port sent or received what.

  ------------------------------------------------------------------------

5.    Full Duplex Operation

One can use two comm ports, eg. COM1 and COM2 serial inputs to to monitor
full duplex communications between two devices.  In this case, usually
RS232 or RS422 adapters are used.  The Flow control combobox, configures
the behaviour of the RTS pin and is normally set to None.  You can use
None, Xon/Xoff, or RTS flow control, but if it is RTS, then you have to
connect the RTS pin to the CTS pin of the equipment under test.  The
communication is displayed in 4 colours, to allow one to see which port
sent what.

  ------------------------------------------------------------------------

6.    Log File

An important feature of WinHexCom is the communications logging capability.
The Log File is saved as Hyper Text Markup Language and can be viewed with
any HTML browser.  The colour scheme is preserved in the log file.  The
default filename extension is .htm.

  ------------------------------------------------------------------------

7.    Send Message

The Send Message function also operates in either ASCII or Hexadecimal
mode.  In ASCII mode, the message is transmitted as is, using the selected
COM port.  WinHexCom will terminate every ASCII string with a pair of
Carriage Return and Line Feed characters (0x0D, 0x0A).

In Hexadecimal mode, the message string should be entered as pairs of
numbers delimited with spaces and is converted to binary before
transmission.  Non hexadecimal characters are ignored.  WinHexCom performs
a round trip conversion and will echo the exact transmitted data on the
screen. If the screen does not show the same message you entered in the
send message box, then you have to fix the format and send it again.  In
Hexadecimal mode, WinHexCom will not add anything to the message string -
it will be sent as is.

Note that the transmission order is always Left to Right and Least
Significant Bit First.  In order to manualy build a valid HDLC message, one
really has to keep one's wits together.  A complicated HDLC message is best
figured out on paper first before you enter it.

Whenever a new, different message is entered, the history list will be
updated.  Any message in the list can be selected for transmission.
WinHexCom will not save the same message more than once.  Select the
comport you want to transmit on, by clicking the relevant Radio Button.

Note that if a comport is unavailable, or if the screen is stopped with the
stop button, or if a file transfer is in progress using X-modem or Binary
Dump, the send button will be inhibited.

  ------------------------------------------------------------------------

8.    The Checksum Calculator

The checksum calculator will compute the checksum of the current message in
the send message box.  You can select any of CRC16, CRC32, Arithmetic Sum
or Modulo Two Sum (XOR) algorithms.  Click the CheckSum button to compute
the frame check sequence of the hexadecimal string in the send message
box.  The computed checksum and its 1's complement will be shown in a
pop-up message box.

You can use the checksum calculator to verify incoming data or to compute
checksums for messages that you want to send.  Use the mouse to highlight a
message on the screen and then copy and paste it to the Send Message box
(Ctrl-C to copy and Ctrl-V to paste).  Once the message is in the Send
Message box, you can use the checksum calculator to calculate the frame
check sequence.

  ------------------------------------------------------------------------

9.    The Framer

The Framer will add a frame around a basic message in the Send Message
box.  Select the desired protocol type (HDLC, PPP or ICNI), then change the
Frame Check Sequence to the desired type (CRC16, CRC32, Sum or XOR). When
you click the Add Frame button, the message in the Send Message box will be
parsed and modified according to the protocol frame specification.  This
feature is a real time saver, especially for complex HDLC and PPP
expansions.

The Framer will always build correct messages.  In order to test the error
handling of a protocol, one does have to create and send bad messages as
well.  You can create a message frame and then go back and change it in the
send message box to add some bit errors, or to add garbage in front or
after the message before transmitting it.

Some default interlocks were added to make WinHexCom easier to use:
If you select a new Frame Type, the Checksum and Display View boxes will
change to the settings normally associated with that Frame Type.

Eg.: If you select a PPP Frame Type, the Display View will change to PPP
and the Checksum will change to CRC16.

You can then go and change it if you want.  It is therefore possible to use
CRC32 with the PPP frame or to view the raw data in Hexadecimal mode. You
just have to select those after selecting the Frame Type.


9.1    HDLC Frame

Highlevel Data Link Control (HDLC) is an 8 bit, synchronous protocol.  This
message frame is used on Ethernet networks. This is a robust frame with a
CRC16 or CRC32 Frame Check Sequence.  The contents of the frame can be
anything at all, but each specific standard has some requirements for
addresses, sequence numbers and data.  The neat thing about HDLC is that in
order to transmit or receive a packet, one need not know anything about the
packet contents, one only looks for flags and follows a standard recipe to
recover the data and verify the CRC.

Each frame starts and ends with a unique flag character 7EH.  There may be
one or more flags and idle bits between frames.

Transparancy is achieved through zero bit insertion.  A Flag character
contains a sequence of six 1 bits.  Therefore, if a data sequence results
in more than 5 consecutive 1 bits, a zero is inserted.  This creates a
small overhead, but the efficiency is far better than that of PPP.

The synchronous channel idles either with Flag characters or with 1 bits.
If eight or more consecutive 1 bits are received, it indicates an abort
command and the current packet (if any) should be discarded.

On transmission, the CRC is calculated first, then the zero bit insertion
is done and finally the flags are added, after which the packet is
transmitted flag to flag.  On receive, the data is received flag to flag,
the flags are stripped, then the 0 bit stuffing is removed, after which the
CRC can be verified.  The framer function is simple enough that it can be
done efficiently in hardware.

Flag Data... CRC Low, CRC High, Flag
Where,
Flag = 7EH
Data = 00H..FFH
CRC = ITU CRC16, polynomial 8408H, initial value FFFFH, final value 1's
compliment, constant result FB08H
Transmission order = Left to right, each byte LSB first

Note that the standard PC serial port operates in asynchronous mode only.
To parse synchronous HDLC you have to provide some hardware to interface
the synchronous stream with your PC serial adapter.  All that this hardware
needs to do, is to chop the stream into bytes and resend it with a UART and
RS232 driver.  The synchronous HDLC handler of WinHexCom will then use the
HDLC flags to figure out exactly where a packet starts/stops.  This allows
your network debug interface to be a very simple design.


9.2    PPP Frame

Point to Point Protocol (PPP) is an 8 bit, asynchronous form of HDLC.  The
same message frame is also used in X25 LAP-B, AX25 Amateur Packet Radio,
ISDN LAP-D and others.  This is a robust frame with a CRC16 Frame Check
Sequence.  The contents of the frame can be anything at all, but each
specific standard has some requirements for addresses, sequence numbers and
data.  The neat thing about PPP is that in order to transmit or receive a
packet, one need not know anything about the packet contents, one only
looks for flags and follows a standard recipe to recover the data and
verify the CRC.

Each frame starts and ends with a unique flag character 7EH.  There may be
one or more flags between frames.

Transparancy is achieved with a two pronged approach.  A PPP Escape
character 7DH is stuffed in to identify data bytes that equal a flag, a PPP
Escape, or any character smaller than 20H, while bit 6 of the offending
character is inverted, thus changing it into something else.

This allows the packet to pass through a channel without being affected by
control character handling (XON, XOF, CAN etc. can all cause problems on
some channels) and ensures that the start and end flags can be uniquely
identified.

On transmission, the CRC is calculated first, then the Escape stuffing and
bit inversion is done and finally the flags are added, after which the
packet is transmitted flag to flag.  On receive, the data is received flag
to flag, the flags are stripped, then the stuffing is removed and the bit
inversion undone, after which the CRC can be verified.  The framer function
is simple enough that it can be done efficiently in hardware.

Flag Data... CRC Low, CRC High, Flag
Where,
Flag = 7EH
PPP Escape = 7DH
Data = 00H..FFH
CRC = ITU CRC16, polynomial 8408H, initial value FFFFH, final value 1's
compliment, constant result FB08H
Transmission order = Left to right, each byte LSB first

Example message: 11 22 33 44 55 66 77 88 99
Example message with frame:  7E 7D 51 22 33 44 55 66 77 88 99 99 14 7E


9.3    ICNI Frame

The ICNI frame is a simple packet used for point to point communication
over a full duplex link in an airborne platform.  The packet frame is not
robust, but it is intended for use in a low error rate environment.  The
addition of transmit and receive timeouts, error check and retries, make
this a reliable and robust  protocol.  The packets are very simple and
regular, which means that the code requirements are simple as well.  The
neat thing about this protocol, is that the packet length remains constant,
there is no padding added to the frames.

Each packet starts with a synchronization character EEH (Not unique, but a
high value, which is unlikely to equal a code, length or data byte),
followed by the message Code and Length.  The MSB of the message code is
used as a packet counter and is toggled for each new message - kept the
same for a retry.  If a message is received with the same sequence number
as the previous, the message is acknowledged, but discarded.

ACK, NAK and periodic HELLO messages have the Codes 7DH, 7EH and 7FH
respectively.  These messages have exactly the same form as the data
messages, which keeps the protocol simple and regular.

In the event of an error, a message can be retried up to 2 times.  When
nothing has been transmitted for a while, a HELLO message is stuffed in, to
show that the system is still alive.  ACK, NAK and HELLO messages are not
acknowledged, but a HELLO message is replied to once, with another HELLO
message.

The ICNI message frame does not have a unique end of frame flag.  One has
to rely on the message length and a timeout.  The version 3.00 parser looks
at the length only.  So, if you don't seem to receive anything, it usually
means that the packet length is wrong.  Remember that if you change the
Screen View to Hexadecimal, then you will see everything in raw form, which
will indicate why packets are missing.

As it is a common mistake to enter the wrong message length with this
protocol, the Framer will recalculate the message length when it is
framed.  This is in keeping with the idea that the Framer will always build
correct messages.  If you want  a message with a bad length, you have to
change the message manually in the Send Box.

Synch Code Length Data... Checksum
Where,
Synch = EEH
Code = 00H..7FH, with the MSB used as a single bit packet counter
Length = 00H..FFH of all Data bytes to follow
Data = 00H..FFH
Sum = Modulo 2 sum (XOR) of all bytes excluding Synch
Transmission order = Left to right, each byte LSB first

Example message: 11 05 11 22 33 44 55
Example message with frame: EE 11 05 11 22 33 44 55 05

  ------------------------------------------------------------------------

10.    The View Screen

The screen scroll bar will appear once the bottom of the screen is reached.
The screen is fully interactive.  You can type into the screen and whatever
you type will be transmitted immediately on the designated Send port.  Note
however, that in both ASCII and Hexadecimal modes, cursor movements will
not be transmitted, while in ANSI mode, cursor movements will be translated
into multi character ANSI escape sequences which will then be transmitted.
In order to send a preconfigured message, use the Send Message box.

Due to a Windows 9x memory manager bug, the screen is not quite
'bottomless'.  The screen will buffer up at most 96kB of data, at which
point it will be flushed and fill up again.  You can stop the screen output
and scroll backwards in the screen buffer at any time.

The Run/Stop buttons control the screen output.  If the stop button is
pressed, the screen and logger will stop, but up to 4kB of data will still
be buffered and sent to the screen and log file when the run button is
pressed.  This allows one to momentarily stop the screen to inspect an
interesting event, without losing any important data.  If the system is
stopped for a long period of time, the buffers may overrun.  In version
3.00, there is still a bug with this function and when the Run button is
clicked, the program may terminate.

If you toggle the the Screen View mode during operation, it will only
affect data from that point on.  WinHexCom will not rewrite the entire
screen.  This allows one to view startup messages in ASCII/ANSI and then
switch on the fly to Hexadecimal or PPP for debugging.

The screen allows cut, copy and paste operations, but only the copy
function is meaningful.  Highlight a message on screen with the mouse, then
press Ctrl-C to copy the highlighted text to the clipboard.  You can paste
the clipboard contents into the send message box for further manipulation,
or into another application for analysis.  If an area on screen is
highlighted, the Ctrl-X, Ctrl-C and Ctrl-V key presses will operate as
clipboard commands and will not be transmitted on the serial port.  If you
cut from or paste to the screen, it will modify the display, but the
information will not be transmitted, so only the copy command is
meaningful.

  ------------------------------------------------------------------------

11.    Protocol Message Parsing

When you select Hexadecimal or ASCII mode, you can see each and every byte
sent or transmitted.  This 'raw' mode is good for debugging packet frame or
ANSI terminal emulation problems.

Once your system under test creates the packet frames correctly, you can
switch to HDLC, PPP or ICNI View.  In these modes, WinHexCom will parse the
data stream and attempt to extract messages from it and HDLC/PPP stuffing
will be removed to yield plain messages.  Only messages with reasonably
valid frames will be displayed.  WinHexCom does not verify the message
checksums.  Message parsing reduces the amount of screen clutter
dramatically and will allow you to debug system operation, without seeing
all the inter packet garbage.

In ANSI mode, all valid ANSI escape codes will be suppressed.  Some ANSI
commands will be executed; mainly the ones for cursor movement and
screen/line editing.  The ANSI emulation is not perfect, but you should get
a reasonably formatted screen when connected to a target with ANSI terminal
output.

  ------------------------------------------------------------------------

12.    Time Stamping

WinHexCom performs a screen refresh every 50ms.  This refresh rate is used
to time stamp transmitted/received messages.  The time stamp is shown using
a simple millisecond counter which will overrun (wrap around) when it
reached FFFFH and includes a direction and port identifier.  Transmit on
COM1 is Tx1 and receive on COM2 would be Rx2.  This is followed by the 5
digit time stamp in milliseconds and then the message in hexadecimal
notation.

A PPP message with time stamp looks like this:
Tx1 16746  7E 7D 51 22 33 44 55 66 77 88 99 99 14 7E
Rx1 16746 7E 11 22 33 44 55 66 77 88 99 99 14

Note that on the received message, the PPP Escape code 7DH is removed and
the next byte 51H is XORed with 40H, to restore it to its plain state of
11H.  Any trailing flags are also suppressed, since inter message gaps may
be filled with flag characters.

  ------------------------------------------------------------------------

13.    File Transfer

Apart from the log file capability, WinHexCom also has a file send and
receive capability.  Two protocols are available: X-modem and Binary Dump.
These features are frequently used to load software into a unit under test
and is provided as a convenience.  You can also use it to transfer files
between PCs, but there are many better ways to do that.

The X-modem protocol operates in the standard mode with 128 byte packets
and a modulo two checksum, as originally created by Ward Christensen in his
ancient Modem2 program circa 1979, some time before the dinosaurs; as well
as the slightly more recent extentions for CRC16 error detection and 1
kilobyte packets, a.k.a. Y-Modem protocol.

X-modem provides a simple, but effective file transfer mechanism, with
limited error detection and recovery and will efficiently send or receive a
file to equipment under test.  It does not matter whether the receive or
transmit sides are started first, as long as you start both sides within
the usual 10 second limit.  A simple way to synchronize the transfer, is to
wait in the file selection dialogue and only press the file dialogue Open
button once both the transmit and receive sides are ready.  The Abort
button can be used to terminate the transfer when something goes wrong.

The Binary Dump is not really a protocol at all.  In this mode, WinHexCom
simply sends or receives the file as is, in 8 bit binary mode.  During
transmit, the file dump will continue until the end of file is reached, but
when a file is received, there is no telling when to stop.  The user
therefore needs to use the Abort button when the transfer activity ended,
to close the received file.  There is also a 15 second timeout, which will
terminate the transfer after 15 seconds of inactivity, so it is OK to start
a transfer, then go and get some coffee...

The protocol analyzer function requires the use of two serial ports
simultaneously.  The file transfer function does however only use a single
port.  The file transfer function will therefore use the port selected as
the Send port.  The protocol analyzer function is inhibited during file
transfers.

  ------------------------------------------------------------------------

14.    Terminal Emulation

DEC created a terminal standard which outlasted both their terminals and
the company itself.  The full screen editing capabilities of the VT100/ANSI
standard are frequently used in equipment configuration screens. As a PC
keyboard doesn't have the same keys as a DEC terminal, the terminal
emulation is not complete, but the subset of commands should be sufficient
for most applications, as it is usually only the cursor positioning, screen
write and erase commands that are actually used.

ANSI (VT100) terminal emulation is still under development, although basic
functions do work for cursor movement, page up and down, clear line, clear
screen and so on.  What is still a bit flaky, is the ability to position
the cursor to exact X-Y co-ordinates.  While an ANSI screen is only 25
lines high, WinHexCom will allow an 'infinite' screen length, by scrolling
in increments of 25 lines, thereby creating multiple pages.  The X-Y
positioning commands will always operate in the page where the caret is.
It is possible to move the caret by clicking in the screen, which will of
course muddle up the co-ordination between where the target thought the
cursor was and where it now is, until the next clear screen or goto-xy
command is executed.  These differences between a PC screen and the
original DEC terminals will never be fully resolved, but is not much of a
problem in practice.  If you moved the cursor to another spot - well, you
know you did that, so you would expect things to be funny after.   In
version 3.00, these functions are largely working and the ANSI mode is
useable, but there are still a few strange things happening on the screen
which we would like to resolve.

The purpose of WinHexCom is first of all, to be an effective protocol
analyzer.  To this end, WinHexCom can operate two serial ports
simultaneously.  An interactive terminal emulator however requires that the
display of only one port be allowed, as the data from a second port will
upset the full screen information display.  The ANSI terminal therefore use
the port selected as the Send port and should disable the other port while
the ANSI session is in effect.  In version 3, both serial ports still
remain active and the ANSI terminal emulation as a whole is still rather
unreliable.

  ------------------------------------------------------------------------

15.    HW Requirements

WinHexCom requires a 'standard' serial adapter for RS232 (the usual one),
RS422 or RS485 (for industrial/military use).  WinHexCom is very tolerant
and if the port does not exist, or is already in use by another Windows
service, then it will simply be ignored.  The RTS pin can be used to
control the Tx buffer of a RS485 transmit driver. RS422 and RS485 are
electrically compatible, so it is sufficient to obtain a RS485 adapter for
both RS422 and RS485 protocol debugging.  RS422/485 adapters are
notoriously expensive, so we will try to source adapter cards at a
reasonable price.

If you want to use a communications port for another purpose, simply run
that program first, then launch WinHexCom, which will then grey out the
status box of the port which is already in use.  Alternatively, set the
second port on WinHexCom to a non-existent port, to allow the other
application to use one of the serial ports.

For the rare occation where you want to monitor 4 or more communications
ports, you can run multiple instances of WinHexCom.  Each instance can
handle 2 comm ports, but to do so successfully, you need a fast PC.


15.1    RS232 Cables

In order to monitor full duplex communications between two systems, you
need to make a set of Y cables.  Simply wire the receive pins of two serial
ports to the transmission lines concerned.  The serial port pin-outs of an
RS232 adapter is shown in figure 1.


Figure 1.    RS232 Serial Connections

 A PC has either a 25 or a 9 pin serial connector.

 Here is a list of the interesting pins on these connectors.  Ignore the other
 pins - leave them unconnected.

 9-pin Connector           (Male at PC)               25-pin Connector
 ----------------------------------------------------------------------
 1    CD    Carrier Detect (Its life Jim...)          8
 2    RX    Receive (...hlab ,hlaB)                   3
 3    TX    Transmit (Blah, blah...)                  2
 4    DTR   Data Terminal Ready  (Local PC ready)     20
 5    GND   Ground - common (Terra firma)             7
 6    DSR   Data Set Ready (Remote equipment ready)   6
 7    RTS   Request to Send (I beg yours?)            4
 8    CTS   Clear to Send (Shoot!)                    5

A general purpose loopback connector can be made as in figure 2 and is a
handy test tool.

Figure 2.    RS232 Loopback Connector

 Loopback Connector

 Connect the following pins together:
 ------------------------------------------------------------------------------
 RTS to CTS                   Ensures that CTS is always true
 DTR to both of DSR and CD    Ensures that DSR and CD are always true
 RX to TX                     Loop back data so we can talk to ourselves

 A loop-back connector like this is always very handy, so you can just as well
 make a good job of it and screw on a backshell and mark it as a loop-back
 test connector for future reference.

Finally, a RS232 Null Modem cable can be made as in figure 3 and is
probably the most used cable, so it is worth doing a very good job.


Figure 3.    RS232 Null Modem Cable

 A NULL Modem Cable
 ------------------
 There is an almost infinite number of ways to make such a cable.  The simplest
 method is a variation of the loopback plug.

 Connect the following pins together on each connector:
 RTS to CTS
 DTR to both CD and DSR

 Then run 3 wires (2 or 3 meters, whatever is convenient to reach the other PC)
 between the two connectors for your data connection:
 GND to GND
 RX to TX
 TX to RX

15.2    RS422 or RS485 Cables

These adapters are not standard.  Please consult the manufacturer of the
adapter for information on the pin-outs.  These devices are specialized, so
if you are using these ones, you'll certainly know what you are doing and
won't need our help!

  ------------------------------------------------------------------------

16.    Test

To test the operation of WinHexcom, connect the transmit and receive pins
(RS232 pins 2 and 3) on the serial port together, to loop the transmission
back, then type something in a Send Message box and press Send.  RS422/485
adapters do not have a standard pin-out. Please consult the card
documentation for those ones.

  ------------------------------------------------------------------------

17.    Compiling the Source Code

If you purchase an Enterprise Licence, then you will also receive a
complete copy of the source code of WinHexCom.  You can study it, re-use
parts of it, enhance it, or use it in a commercial product, provided that
whatever you do with the source code can be motivated as "fair use" in
terms of the Canadian Copyright Act.

You should be able to compile the source with a number of compilers since
the code is written in ANSI C.  It will however be easier to compile it
with the compiler system LCC-Win32 of Jacob Navia, which can be downloaded
and licenced (a minimal fee) from here:
http://www.cs.virginia.edu/~lcc-win32/

For your convenience, a recent version of LCC-Win32 is on the CD, in the
directory lcc_zip.  To install, simply click on all the files one by one.
This compiler is very small, fast and reliable.  Go to the web site above
for licencing information and the latest version.

A LCC-Win32 project file winhexcom.prj is provided.  You can import this
file with Wedit, the IDE of LCC-Win32 and make the project.  Note that
there are file dependencies in the project file: "ProjectPath
f:\lcc_work\WinHexCom".  You have to edit these dependencies to correspond
to your setup before you can import it successfully.

Before embarking on an enhancement of WinHexCom, it is advisable that you
first try to compile the code as is, to ensure that your setup works
properly.

Source Documentation is available in HTML format in the html directory.
The main page is index.html.

  ------------------------------------------------------------------------

18.    Price List

The development of WinHexCom proved to be far more time consuming than we
ever imagined, therefore we really appreciate it if you purchase a
licence.  A licence entitles you to a year of free updates and for a
registered customer, we will try our best to fix any reported bug within 2
business days.


18.1    Corporate Users:

Single user software licence: US $80.

Unlimited Enterprise software licence: US $200.
An Enterprise licence includes the C source code.

The licence entitles the user to one year of free updates, as from the day
of registration.

Dual port ISA bus RS422/485 adapter: US $120.

RS232 adapters are common things and available off the shelf almost
anywhere.

18.2    Home users:

Home users can use WinHexCom free of charge for hobbyist purposes.  If you
feel that we are going to starve if you don't pay for the program, then a
Pizza voucher would be welcome... :-)

18.3    Registered vs Non-Registered

There is no difference in the operation of the program, whether it is
registered or non-registered, except for the small nag messages on screen
and in the log files.  Obviously, if you have a problem, or want a
modification, or maybe want a complete protocol parser added to WinHexCom
for a proprietary protocol, then it will help if you have registered the
program...


Have fun!

Herman


  ------------------------------------------------------------------------

         Copyright  2000, Aerospace Software Ltd., Calgary, Canada
