Add Windows binaries

[tomfitzhenry]

For issue #21.

I have built the 64-bit Windows DLL, on Linux (using make and the build dependencies in https://github.com/tomfitzhenry/scrypt/commit/d12fbb17ae4136e88741dc643b1648ca1e70760a ), and tested it on Windows, and it passes tests.

However, I am unfamiliar with the Windows platform, and so am not confident that this binaries works in all situations. I'm raising this pull request in an attempt to get comments from people who are more confident, until it's in a workable state.

This entire pull request is a cleaned up version of FauxFaux@57d134f .

[tomfitzhenry]

After speaking to a colleague, I'm aware of a potential problem. The potential problem is that the binaries MinGW rely on the target system having a C runtime (in this case msvcrt.dll), but Windows does not guarantee the existence of a C runtime. msvcrt.dll exists on most systems today, but is not part of Windows's API, so should not be relied on. Instead, application developers are expected to statically link with their own C runtime.

How to statically link with C runtime? Multiple solutions:

• Visual Studio makes this easy enough, so I'm told, but I don't have Windows or Visual Studio. Plus, I'm not sure what license the Visual Studio bundled C runtime is offered.
• Find a suitably licensed open source implementation of the C CRT.
• Implement the few parts of the C CRT against the win32 API (eww)

[tomfitzhenry]

http://mingw-users.1079350.n2.nabble.com/Statically-link-to-Microsoft-C-Runtime-Library-td5651499.html is relevant, though seemingly a dead end.

On why you can't/shouldn't assume msvcrt.dll is on the host: http://blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx

Note that the above two links recommend different things:

• MinGW recommends relying on the host having msvcrt.dll
• Raymond Chen says you can't/shouldn't rely on the host having msvcrt.dll