Grin on native Windows

[jaspervdm]

Opening this issue to keep track of getting Grin to run on Windows natively. A simple cargo build fails when trying to build croaring. There might be additional crates giving issues but I didn't get past the first one.

It might be worth it to try and get just the wallet working on Windows, since that doesn't actually use croaring. It is however needed by other parts of Grin so it is listed as a dependency for grin_chain, grin_core and grin_store, so it will take some effort to try and untangle these.

At the moment this issue is not a priority for the devs, but if anyone else is willing to pick this up they are very much welcome.

[drizzt]

I'm able to build grin on Windows successfully.
Unfortunately it fails in sync with error:

Could not write to state storage, disk full? Os { code: 5, kind: PermissionDenied, message: "Access is denied." } }

If anybody wants to investigate on it: https://github.com/drizzt/grin/tree/windows

[sesam]

What build environment did you use?
Win 10 pro? Below 10 or below pro some features are likely missing / might make it harder to build.
Manually added features? (linux/ubuntu windows subsystem?)
Via cygwin / similar?
cargo/rustc versions and how were they installed?

This is also important to add into the build documentation. I can update the wiki.

[drizzt]

I cross compiled from Fedora 29 using cargo build --target x86_64-pc-windows-gnu (last rustup stable) and tested in on Windows 10 Professional

[sesam]

the -windows-gnu target probably means the binary uses the cygwin runtime library, which cares about permissions that a normal windows software might not be stopped by. On startup, grin goes into ~/.grin to do stuff.

Maybe try fixing up ownership and permissions on the .grin folder?
bash -c mkdir ~/.grin; chmod -R 775 ~/.grin; chown -R $USER:$USER ~/.grin

[drizzt]

Since building for Windows can be a problem I created a Dockerfile to simplify the process:
https://gist.github.com/drizzt/fa4d62fc1118b387078bc06bd6c69009

[ignopeverell]

You can play with the LMDB store size and see if that helps. Ultimately we should auto-detect the running environment to set it appropriately. But I expect you'll run in a few other issues after that...

[drizzt]

@ignopeverell I already did that in drizzt@604e421, but now it's failing during self.hash_file.flush():

grin/store/src/pmmr.rs

Lines 240 to 251 in 8d8f533

	pub fn sync(&mut self) -> io::Result<()> {
	self.hash_file
	.flush()
	.and(self.data_file.flush())
	.and(self.leaf_set.flush())
	.map_err(|e| {
	io::Error::new(
	io::ErrorKind::Interrupted,
	format!("Could not write to state storage, disk full? {:?}", e),
	)
	})
	}

when it's managing pmmr files (so it's not a problem of LMDB)

[ignopeverell]

I think it's an issue with how Windows handles memory mapping. Everything MMR related uses mmap. @yorickdowne previously filed this bug against WSL:

microsoft/WSL#3451

I understand you're not running against WSL but perhaps similar system calls are used under the hood.

[drizzt]

This should be another problem since no zero-length mmap is done in store/src/types.rs

[thorsteneb]

@drizzt I didn't dig into what your issue is here, "and" and "but", take a look at microsoft/WSL#3451 (comment) . That rabbit hole goes deeper than 0-length mmap, it has to do with how the Windows kernel interacts with file handles. My understanding is you can't make changes (delete, rename, change size, etc) when a handle is open. That's not how *ix behaves, and that throws quite a few packages for a loop.

[yeastplume]

Given RoaringBitmap/croaring-rs#42, is getting Grin working on Windows really that far off? Surely it would seem all that has to happen now is an alternate PMMR backend that doesn't use memmap?

[yeastplume]

Also confused because memmap crate claims to work and be tested on native windows, both msvc and gnu toolchains. This could just be a matter of tracing down an issue in https://docs.rs/crate/memmap/0.7.0

[cyberpunkbln]

Hello,

for my understandings, the problem is that mw/grin are an peer2peer application and under windows only a complete compiled wallet can deliver mw/grin functions. Webwallets, Paperwallets, nodejs/javascript and other known applications are not possible?

[0xmichalis]

We are releasing Windows binaries now so I suspect this issue is fixed?

[quentinlesceller]

Indeed @Kargakis, closing.

[cyberpunkbln]

Hello,
can anybody update the build docs in the wiki for windows 10? Can i use an gnu-mingw-toolchain?
thx