Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a client for Windows #315

Closed
alpe opened this issue Nov 17, 2020 · 5 comments · Fixed by #1231
Closed

Add a client for Windows #315

alpe opened this issue Nov 17, 2020 · 5 comments · Fixed by #1231
Labels
enhancement New feature or request

Comments

@alpe
Copy link
Contributor

alpe commented Nov 17, 2020

Add a wasmcli for Windows.
See #312 (comment)

Current workaround would be to use the docker image

@webmaster128
Copy link
Member

Copying over from chat:

I think it is important to have the same binary name (wasmd/wasmd.exe) for both UNIX and Windows for documentation reasons.
IIRC, a documentation like wasmd query wasm contract-history cosmos18r5szma8hm93pvx6lwpjwyxruw27e0k5uw835c will work on Windows, even if the binary is called wasmd.exe

Then we can have a wasmd, which is not a deamon and only includes a client. But hey, who cares.

@alpe alpe added the enhancement New feature or request label Dec 14, 2020
@greg-szabo
Copy link

I've found a downstream dependency that might require wasmd to be Windows-compatible:

The Regen Network binary (and any other wasm-enabled binaries for that matter) uses wasmd as its dependency. This means that the Regen binary cannot be built on Windows. Any downstream project will have to make the same decision Ethan discussed in the comment or specifically, they should only include client-side functionality, if they want to build their binary on Windows too.

I think downstream developers would want to use wasmd in its entireity.

Interestingly, wasmvm can be built on Windows and it generates a wasmvm.dll file. (The included Makefile assumes it's called libwasmvm.dll so the copy command breaks.) So, in theory, implementing Windows compatibility shouldn't be a hard task.

My use-case is that I need the user to be able to sign Regen transactions using a Ledger device on a Windows desktop. The Linux Subsystem only supports disk drives for USB connectivity, not Ledger devices. Hence the binary has to be built natively for Windows. (Other VM solutions might also work, but the point is to keep this simple and safe for the end-user.)

@ethanfrey
Copy link
Member

Not sure how this compiles, but it definitely won't run. However, wasmer just added windows support to their develop branch 4 days ago. wasmerio/wasmer#347 (comment)

With the next release of wasmer, we should be able to properly build for windows and can close this.

p.d. does Regen just need the client side functionality (signing submitting tx and querying) or actually running non-validating nodes on Windows?

@webmaster128
Copy link
Member

Interestingly, wasmvm can be built on Windows and it generates a wasmvm.dll file. (The included Makefile assumes it's called libwasmvm.dll so the copy command breaks.) So, in theory, implementing Windows compatibility shouldn't be a hard task.

Since 1.0 or so Wasmer supports cross-compilation. So you can compile the Wasm compiler (Wasmer/singlepass) on Windows and get a .dll. However the compilation target cannot be Windows and you'll get an unsupported OS error at runtime when trying to do so.

The ticket Ethan linked is promising but untested and unreleased.

@alpe alpe added this to the v2.0.0 milestone Oct 18, 2021
@ethanfrey ethanfrey modified the milestones: v2.0.0, v1.x.0 Apr 25, 2022
@alpe
Copy link
Contributor Author

alpe commented Mar 3, 2023

We have windows client support now: #1197

I think it is important to have the same binary name (wasmd/wasmd.exe) for both UNIX and Windows for documentation reasons.

The argument makes sense. I will rename the wasmd-client.exe binary

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants