windows support

[xmclark]

There seem to be a few barriers to windows support. There is an outstanding bug on wabt-rs that prevents building on windows. There is a hacky work around, but non-ideal.

The codebase also seems to import many linux-only libraries, so those would have to refactored or conditionally compiled.

Windows support would be a big win for portability, which I imagine is a priority for a tool that aims to be a cross-platform wasm runtime.

[syrusakbary]

Agreed! Supporting Windows will be a big win for a cross-platform runtime, which is in our goals.

Here are the things that we will need to do in order to have Windows support:

• wabt-rs upgrade: required for running wabt script tests & executing .wat files (we can work on a PR /cc @pepyakin)
• Support for Signal Handlers in non *nix systems
• Virtual memory allocation on Windows
• Make Stdio capturer (used in emscripten tests) work in Windows env
• Double check all emscripten syscalls

We will post here the updates once we start working on it.

[pepyakin]

It is a shame that wabt-rs doesn't work for Windows. Would love to help, but I don't have much experience with Windows nor have I a windows machine.

[syrusakbary]

@pepyakin no worries, we will help you on that creating a PR on wabt-rs when the time comes :)

@xmclark we just added Virtual memory allocation on Windows with #54, so we are one step closer to be on windows :)

[xmclark]

@syrusakbary that’s all great news!

I’ve already started the ball rolling with @pepyakin on windows support.

I’m also investigating signal support in libc for windows. Seems doable.

[xmclark]

I think libc should have basic signals support on windows as of this commit. It may require more tinkering.

I have spent the last few hours getting familiar with the details of stdio capture on windows. I think this is possible with just libc but it may be dirty. Time will tell! I am interested in any ideas for capture on windows.

[xmclark]

@syrusakbary I think I have a solution for capturing the stdio, but I can't help feel that capturing stdio in-process seems a little round-about. A problem is windows pipes don't seem to be buffered and that has made it a bit more compilcated. The WinAPI has buffered pipes, but it would be a completely different implementation from the libc pipe implementation.

How about storing the tests in a test executable crate and spawning it from integration tests? The standard output can be captured with normal safe rust. There is no platform specific code or unsafe code. I can't imagine the performance is any worse. Thoughts?

[syrusakbary]

How about storing the tests in a test executable crate and spawning it from integration tests? The standard output can be captured with normal safe rust. There is no platform specific code or unsafe code. I can't imagine the performance is any worse. Thoughts?

That's something we considered on doing before. However, we discared it because of:

• It makes the testing process more complicated: as it needs to do two different builds to test emscripten (one for the binary, other for the tests)
• It makes debugging emscripten tests much harder: since the binary would not be able to output any debug information (as it will be captured and then compared with the expected output)

The WinAPI has buffered pipes, but it would be a completely different implementation from the libc pipe implementation.

We can use two different implementations, one for *nix systems and other for Windows. It might be easier to achieve?

Ideally, I lean towards the second option since it makes the testing and debugging easier. Thoughts?

[syrusakbary]

We added experimental Windows, so it can now run WebAssembly files.

There is still some work to do regarding Emscripten (#176) but other than that everything is tested and green 🎉.

We are preparing for Wasmer 0.2.0 and will close this issue once we publish the wasmer.exe file :)

[CryZe]

Okay, so I was able to test it today and it seems like it does work for the most part. However there is something that seems to be broken. In my wasm file I have an exported function that returns a f64 value and that does not seem to be returned correctly by wasmer. I'm getting some garbage value on the host side. I'm not sure if that's just a windows abi mismatch or if this affects Linux and co. as well.

[xmclark]

@CryZe I am glad you're able to try it out! Could you post an issue that reproduces your problem?

[CryZe]

Yeah I'll open a full issue with a reproducible example (and maybe tested on Linux too) in a bit.

[syrusakbary]

We just published Wasmer 0.2.0 -> https://github.com/wasmerio/wasmer/releases/tag/0.2.0
The new crates are also published.

We created a separate issue to implement the emscripten syscalls in Windows #176.

Here's a useful PR that updates the wasmer-rust-example to the new 0.2.0 API.

Closing the issue :)