Need to update readme to make it clear how to use on Windows

[rmhrisk]

trafficstars

It seems it may not be directly obvious on how to get the module working on Windows, I am not sure what the issues are but it seems @microshine is working on getting them documented.

This bug is to track that activity.

[hildjj]

I was able to get it working on my local Windows box by following Option 2 from here:

https://github.com/nodejs/node-gyp#installation

I also needed npm i npm@2 -g to get past some node-gyp bug. On Appveyor, however, I can't seem to get past this error:

ec_jwk.obj : error LNK2001: unresolved external symbol _EC_POINT_get_affine_coordinates_GF2m [C:\projects\node-webcrypto-ossl\build\nodessl.vcxproj]

I don't yet know if that's the only unsatisfied link, or if it's just the first one the linker has found. Can someone more familiar with the code look at it? I've got a branch going to play with this, if you want to take a look.

My hope is that once we get this figured out, we can move to node-pre-gyp, and most people won't ever have to touch the C++ code.

[rmhrisk]

My best guess is Appveyor is picking up an older version of OpenSSL.

It seems like its installing 1.02, which isn't the latest but I would expect that function to be there even in that older version.

I guess the firs thing I would try would be updating that older version to:

https://slproweb.com/download/Win32OpenSSL-1_1_0.exe

@microshine and I will take a look and see what we can infer from logs in a bit.

node-pre-gyp looks interesting. You are right, the C++ is a means to an end, the goal in our current approach is to simply make a package that works in as many locations as possible.

Thanks again.

[hildjj]

I'm already downloading that, but you're right, I bet my version is getting overlooked. Will pursue tomorrow, thanks for the pointer.

[hildjj]

It turns out that Appveyor does have recent 1.0.2 already loaded. When I just compile against that rather than fighting it, everything worked. Here's the approach I'm suggesting:

• Add appveyor.yml, which does a matrix build of win32 and win64 on every checkin. If the commit message includes [publish binary], upload the binaries to a github release with the release number from package.json. Use node-pre-gyp for the build, and node-pre-gyp-github for the uploads.
• Modify .travis.yml to use node-pre-gyp, and do uploads as above. This should give us binaries for OSX and Linux. Matrix in whatever combinations people ask for.
• In package.json, add an install script that calls node-pre-gyp --fallback-to-build, which will look on github for a binary, download and use it if it exists, and otherwise build. Happily, this should radically reduce install time and complexity for those that find a binary.

I have two open questions:

• What to do about the openssl_root definition currently in binding.gyp? It's set for the directory you have on your system. Appveyor uses 'C:/OpenSSL-Win{32,64}'. I guess we could put in another condition to only set the environment variable if it's not already set? Alternately, you could just install to the same place Appveyor does, and we could reduce a little complexity.
• How to upgrade to OpenSSL 1.1? The binaries on slproweb.com change radically for 1.1, including only .dll's, and not the .lib files I think are needed to link statically. That means we probably have to include the .dll along with the distro, make sure it links correctly at run time, etc.

[rmhrisk]

This makes sense to me but I want to hear what @microshine thinks also.

As for your questions, the first I will leave to @microshine. For the second I think I would rather have builds break than check in OSSL binaries. Thoughts?

[Root-Core]

I would love to use the module on windows machines, as our project is limited to Windows x86. (Some binary node module links to an 32bit DLL and gets ported atm..)

The node-webcrypto module compiles under Linux, but no luck with windows, so I really like the idea of providing it precompiled.

[rmhrisk]

@Root-Core it definitely works on Windows, we re-wrote it specifically to remove a dependency that was causing issues with working on Windows and have tested it there extensively.

Getting it to build there however currently requires following the node-gyp build steps.

I like the @hildjj proposal and am hoping he can help us get this happening more smoothly for folks. If not we will get to it, just can't say when.

[hildjj]

Did @microshine have an opinion about the approach? Note, I'm currently using a version of the build script from node-sqlite, which we'll likely want to simplify a little.

[rmhrisk]

@hildjj no, not yet. I will talk to him tomorrow.

[Root-Core]

Okay, sorry you are right.. it takes some configuration. I just wanted to express my gratitude.

npm config set msvs_version 2015 helped a lot. But it failed to resolve the OpenSSL path, so i had to copy the folder from C:\OpenSSL-Win32 to C:\Build-OpenSSL-VC-32

And OpenSSL 1.1.0 is not working for me, as the lib\libeay32.lib library was missing. So I had to install OpenSSL 1.0.2 (32bit download).

It might help someone, so i decided to share my "solution".

[Root-Core]

Some news about the node-pre-gyp stuff? It is not that easy to run our project on all our development machines, as we need to install the compiler (VS2015) and OpenSSL and configure some stuff.

[hildjj]

I'm willing to spend some more time on it this week, if the committers want.

[prashcr]

@Root-Core Thanks for your solution! It helped me get past the libeay32.dll not found errors.

However I'm now stuck at the same problem as @hildjj

ec_jwk.obj : error LNK2001: unresolved external symbol _EC_POINT_get_affine_coordinates_GF2m [C:\projects\node-webcrypto-ossl\build\nodessl.vcxproj]

Are there any workarounds for this atm?

[microshine]

v1.0.16 supports static OpenSSL lib from NodeJS in Windows. Now it can be compiled more easier binding.gyp