Issues detected during porting phase

Cuneiform uses Windows' wchar_t, which is 16 bit. On Unix it is 32 bit.

vertstr.cpp does GUI drawing or somesuch. Disabled everything.

BYTE and CHAR are used interchangeably. Subtracting BYTE* from CHAR* gives
"invalid operands to binary -" error message.

Disabled use of dfon library. It seems to be some external dll file.
I have no idea what it's supposed to do.

The russian comments are encoded with CP1251.

As far as I can see, the code has two main deliverables codenamed Puma and Tiger.
Puma seems to be a DLL with the actual recognition code whereas Tiger
is an OLE (or something like that) wrapper. Puma has an additional library
collection called rpstr.

The RLING subdirectory seems to be compiled twice with slightly different
definitions.

There are a lot of duplicate definitions of some functions and variables.
Maybe MSVC is just lax and tries to "do what I mean". It may also have
something to do with Windows DLL symbol resolving rules.

Basic datatypes were multiply defined all over the tree (cttypes.h, 
c_types.h, nt_types.h). Now they are all in h/cttypes.h. Any multiple
definitions should be considered bugs.

Snp is problematic. snptools.h uses e.g. __SnpIterParent static but also
uses it as a friend for class SnpTreeNode. Gcc does not allow the second
kind to be static.

Cuneiform reads its data files as if it was installed on Windows. Meaning
like "\\BIN\\rec4cour.dat". Eventually this should be turned into nice
unix-style $PREFIX/rec4cour.dat. But to get started I just dump all
built items and data files to the root of the build directory. This means
that you must run pumatest in the build root directory. Otherwise
it will NOT work.

The dat files that come with Cuneiform have binary stuff mixed with
Windows line ending strings. When read in Unix they become '\r\n'.
Input data is validated by checking the lengths of read strings.
The additional '\r' causes these checks to fail.

Cuneiform stores its text strings in CHAR (signed char) and BYTE (unsigned char) 
arrays, which get compared against each other. This leads to pointer type mismatch 
warnings. Also giving BYTE pointers to libc string functions such as strlen give
these warnings. An easy fix would be to convert them all to chars, but it won't
work because at certain times the character values are compared to constants
larger than 127.

There is a call to a swab_my function, which is not defined anywhere. It seems
to be used inside PPS_MAC #defines. If it has something to do with endianness
swapping, then people working on that might look at commit 207 to find out
where they were originally.
