Issues detected during porting phase Cuneiform uses Windows' wchar_t, which is 16 bit. On Unix it is 32 bit. It is only used for export, though. Internally everything is an 8 bit char. 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. Also note that BMP files are little endian, but Cuneiform handles them as if they were native endian.