Open tomfitzhenry opened 10 years ago
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:
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:
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 https://github.com/FauxFaux/scrypt/commit/57d134ffa5c6e55264e417b85e0befe818126fe4 .