multiple cmake and windows build fixes:

[sezero]

• cmake < 3.13: LINK_FLAGS property is managed as a string not a semicolon-separated list.
• wavpack_local.h: define FASTCALL only if not already defined, and define it as __fastcall only when targeting i386.
• windows builds of client programs don't depend on iconv.
• lowercase several winamp sources for cross-compilability.
• winamp: thread_id must be a DWORD, not an int.
• winamp: sample_buffer should be int32_t, not long.
• winamp: change actual_size < 2147483648 comparison so that the constant fits into a signed int.
• winamp: change swprintf calls to _snwprintf
• winamp headers: make sure _MSC_VER is defined when checking its value.
• winamp headers: define NOVTABLE as __declspec(novtable) only for _MSC_VER, not _WIN32.
• winamp, wasabi: make extern declaration of In_Module mod more compatible.
• winamp: added missing void type to UTF8ToAnsi()

Build tested on i686 and x86_64 linux using cmake-3.9.6 and 3.11.2. Cross-build tested for i686 and x86_64 using mingw-w64 toolchains.

[dbry]

Thanks for these!

You mentioned that you tested the cross-build. Do you mean that you built the winamp plugin on Linux and tested that plugin on Windows using winamp? Which winamp version do you use? I haven't been keeping up with winamp, but it looks like there might be a 64-bit build now. Does that work with the WavPack plugin if it's built for 64-bit, or does it work with old plugins?

@evpobr you're far more experienced with cmake than I am; does this all seem good to go? Thanks!

[sezero]

You mentioned that you tested the cross-build. Do you mean that you built the winamp plugin on Linux and tested that plugin on Windows using winamp?

Build-tested only, not run-tested.

keeping up with winamp, but it looks like there might be a 64-bit build now.

It builds alright, but don't know whether there is a 64 bit winamp (not really interested in it, I just fixed annoyances in the way of build procedure.)

[evpobr]

CMake code looks good 👍