Mingw support

[azmeuk]

I applied the patches in the patches Alexpux repository that are used to build the archlinux mingw-w64-ois package, and so, allow to build libOIS with mingw on GNU/Linux. If #9 is merged, I would like to add the mingw builds to the continuous integration script, and so, make sure the build is perennial. Please have a look.

[Alexpux]

Here is patches rebased to current state: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-ois-git

[Ybalrid]

I am unsure if this is still relevant. I will need some time to review this

[azmeuk]

@Alexpux new patches seem more relevant than this PR :)

[Ybalrid]

I need to setup mingw to be able to test this. I will get back to you about that ;-)

[Ybalrid]

I haven't took the time to setup the mingw toolchain, but I looked at the patches, they should be easy to re-apply by hand, but some things should probably be done differently.

The patches basically boils into the following :

• including UNIX standard headers in some files (where they missing? Maybe the Linux code is valid "by chance". We should enforce the IWYU rule anyway, so this is good)
• hard-coding the usage of ASCII version of Win32 functions that can optionally be in "UNICODE" mode (using array of WCHAR for strings)
• modifying some autotools configuration files
• hard-coding things that where not available in mingw at the time relating access to some windows specific APIs...

Mingw probably (I hope) implemented the missing features by now, autotools are gone (long live CMake!), the hard-coding for non-Unicode is strange but understandable (but if the rest of the code cannot use wchar strings, you should explicitly call the ASCII function, not redefine the macro to something else. You could break somebody else's code if not done carefully).

[Ybalrid]

mingw support only required the change of one line of code in the Win32 Input Manager. See PR #37 I'm going to drop theses outdated patches now ;-)