Installing and running Joinmarket-Qt on Windows - problems

[AdamISZ]

Earlier last year in #344 it was observed that the original instructions for setting up Joinmarket-Qt on Windows didn't work. @kristapsk was able to run it successfully but we had no other feedback on this, so a change in instructions was merged on a best effort basis.

More recently we had feedback from a user in #513 that it wasn't possible to get it working by following the current instructions. See the comments reporting errors starting from here.

If anybody who is able to get it working in the current version (0.6.1+) can report on it here, that would be helpful.

[kristapsk]

I still have that one Windows 10 machine I can access, will try it later.

[kristapsk]

Haven't had time to fully and carefully test this on a fresh machine, but there's free Windows 10 evaluation VM images from Microsoft that can be used for testing - https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ (if somebody else wants to test this but don't have Windows at hand).

[RyanMilb]

I was able to replicate the same errors for the QT client that joseortiz3 encountered.

[kristapsk]

This looks like a good news for the future - Windows 10 is Getting Support for GUI Linux Apps.

[boskowski]

Joinmarket-Qt seems to run just fine on Windows (I'm running the master branch with Python 3.7 from python.org), no need to use WSL. The only addition I had to add make is adding pywin32; platform_system == "Windows" to requirements/gui.txt.

[AdamISZ]

Joinmarket-Qt seems to run just fine on Windows (I'm running the master branch with Python 3.7 from python.org), no need to use WSL. The only addition I had to add make is adding pywin32; platform_system == "Windows" to requirements/gui.txt.

Hi @boskowski ... not sure why I didn't answer at the time, but this is certainly very interesting, but I have a question - how did you deal with the libsecp256k1 and libsodium dependencies? For the former, was it the case that Joinmarkets' coincurve install automatically handled that? For the latter, I'm not sure myself, but I do remember having problems getting a libsodium dll installed for some reason (this was like 2 years ago though!).

[boskowski]

how did you deal with the libsecp256k1 and libsodium dependencies?

Hi @AdamISZ, libsecp256k1.dll is made available by the coincurve package. Apparently I didn't have to bother with libsodium as I already had the DLL in the search path, but it can be easily installed by extracting the appropriate file from the NuGet package (it comes with a .nuget suffix but is a zip-file).

One way is to download the package from https://www.nuget.org/packages/libsodium/ (click on "Download package" on the right), unzip it (first changing the suffix if necessary) and placing the correct DLL (runtimes/win-x64/native/libsodium.dll or runtimes/win-x86/native/libsodium.dll) in a directory that is in the Windows search path.

This can be done in a script using the NuGet API, e.g. (using curl and 7-Zip):

curl -Lo libsodium.zip https://www.nuget.org/api/v2/package/libsodium

or, to get a specific version

curl -Lo libsodium.zip https://www.nuget.org/api/v2/package/libsodium/1.0.18

and extract, e.g. for x64 using 7-Zip (writing to c:\windows\system32 requires admin rights, so this will require an elevated shell):

7z x libsodium.zip runtimes/win-x64/native/libsodium.dll -so > c:\Windows\system32\libsodium.dll

[AdamISZ]

@boskowski hi again; i tested this out and indeed it worked fine for me on Windows 10, so thanks again! But there is a detail I found puzzling: don't you have to copy the libsodium dll to Windows\System not Windows\System32 ? I tried the latter and it didn't load. Everything else worked out of the box from, as you say (1) installing python (2) pip installing base requirements and then (3) adding the pywin32 line before installing gui requirements.

[boskowski]

@AdamISZ you're quite welcome, thank you for the amazing work! On 64-bit systems, the system-wide library locations are %SystemRoot%\system32 for 64-bit libraries and %SystemRoot%\SysWow64 for 32-bit libraries (definitely counter-intuitive, also: %SystemRoot% generally resolves to C:\WINDOWS). When a 32-bit application runs on a 64-bit system, the operating system will redirect access from c:\windows\system32 to c:\windows\SysWow64. Could it be that you installed the 32-bit version of Python? If so, placing the 32-bit library in %SystemRoot%\system32 did not work (%SystemRoot%\SysWow64 would have been the right place), but putting it in c:\Windows\system worked because that directory is in the search path and Python was able to find it.

[AdamISZ]

I'm going to close this as resolved after merge of #618 and creation of the process in #641 after which we should produce binary builds for Windows of JM for each release, anyway.