Support for clang and updating exts' libraries

[LB--]

Some extensions are out of date with the latest versions of their respective SDKs/libraries or do not compile under all or most of VC++2008, VC++2010, VC++2012, and clang.

[SortaCore]

Was the SDKs ever supposed to compile under non-MSVC? I remember the SDK documentation requiring MSVC. Anyway, all extensions bar DarkEDIF should compile under VC2008+, and DarkEDIF ones should compile under VC2010+.

[LB--]

I'm trying to expand the accessibilities of the SDKs and Extensions to non-Windows users, so they can still compile for windows but on their e.g. Linux without having to use an emulator or VC++ port. clang also has really good C++11 support.

[SortaCore]

I think the biggest complications would be type definitions and calling convention notations, judging from liblacewing's format.

[LB--]

What do you mean?

[SortaCore]

Well, the standards define the sizeof(one_type) <= sizeof(other_type) so it varies per compiler. long, for example, may be a 64-bit variable on a 32-bit build for clang, whereas for VC it matches the build architecture (somewhat illogically as it's not longer than an int on 32-bit if it does - but I didn't write the spec :P). As for calling conventions, on VC it might be void __stdcall function(), but clang would be void __attribute__((stdcall)) function().

[LB--]

I've not had any issues so far; the sizes and such are the same and I'm pretty sure that such a modern compiler would not make it impossible to get a type with a desired size. I'll be the one pulling my hair out if clang has issues with the SDKs or MMF2. And besides, MMF2 and its SDKs are all 32 bit and use primarily 32 bit-sized variables, so it really should in theory only be a issue of making sure the code is as cross-compiler as possible.

I'll take on the clang stuff. I'm sure it can only be beneficial to e.g. James.