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.

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.
Every dynamic library should use its own version of them.

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.

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. Other endianness problem is the x86 "bswap"
asm directive used. Also note that BMP files are little endian, but
Cuneiform handles them as if they were native endian.
