(GrinWin) - Windows 10 Support Meta-Issue

[yeastplume]

This is a meta-issue to keep track of the tasks required to release a native Windows 10 x64 build. I've managed to get GrinWin (node with test-miner and wallet) mostly working, and there really shouldn't be too much standing in the way of a proper release (bar some testing and time in the field).

Some notes on building/env (nothing special here):

• Use windows rustup msi to install
• Use MSVC toolchain as advocated by the rustup installer (download and install the VC2017 installer package)
• Clang dlls for windows need to be installed: http://releases.llvm.org/download.html
• Disable TUI for now in grin-server.toml when running

Known Tasks: (More may come out as we get these done)

• Update croaring-rs to 0.3.8. This is currently hardwired to 0.3 in the code, (check if there's a reason for this?))
• Remove daemonize or ensure it's only compiled on linux/macos builds. Remove/make conditional the grin wallet start daemonize command
• LMDB on windows allocates ALL requested space on DB initialization, which is currently set to 500GB in Grin (intended as a maximum). This should check platform before doing this, and on windows it should start with a small file and reallocate as necessary. Apparently monero already does this, so we have a reference. Edit: PR for this working, but still a few discussion points: Dynamic LMDB mapsize allocation [1.1.0] #2605 Edit: Done
• What may have been thought to be memmap issues are actually windows-specific problems with file permissions (mostly more aggressive windows file locking). I've fixed several issues around this but they'll of course need to be tested on linux as well. I'll submit a PR for this shortly.
• txhashset unzip during fast sync fails to unzip for some reason, (Edit: was fixed, but appears to be an issue again after 1.0.2 (which was merged into 1.1.0 as well). Edit: fixed again Fix TxHashSet file filter for Windows. #2641
• Check txhashset is properly zipped and sent to peers that request it
• The TUI backend needs to be changed (via rust features) to use pdcurses backend to run on windows. This needs to be a dynamic selection based on build platform.
• The TUI appears when selected in grin-miner.toml, but appears quite small and freezes instantly
• CI / Automated builds for windows. Apparently windows support with rust is available on Travis CI, but no idea how easy it is to set up the proper build environment. Update: According to this: https://docs.travis-ci.com/user/reference/windows/ Rust is supported, VC 2017 Build tools are installed by default, GIT Bash is used (hopefully we can run the same build scripts as a result) and we should be able to use the Chocolatey to install LLVM. Provided nothing unexpected this would appear to be fairly straightforward. Update 2: Done for grin 1.1.0 and grin-wallet 1.1.0 with a caveat due to travis CI bugs, see [1.1.0] Travis automated windows builds #2626
• tests in store crate appear to pass, but investigate 'Corrupted storage' error log output (Update, this is most likely this: "Corrupted storage" error logs #2578)
• Restore test on windows doesn't work due to file locks in the test framework (can possibly leave this out if wallet is split first. Update: grin-wallet problem now after split, will address there.
  Remember: You Grinnin', You Winnin'!

[andreabenetton]

The TUI backend needs to be changed (via rust features) to use pdcurses backend to run on windows.
This needs to be a dynamic selection based on build platform.

Remove in grin Cargo.toml :

cursive = "0.9.0"

and add

[target.'cfg(windows)'.dependencies]
cursive = { version = "0.10.0", default-features = false, features = ["pancurses-backend"] }

[target.'cfg(unix)'.dependencies]
cursive = "0.9.0"

Cursive = "0.9.0" on windows branch, load anyway a ncurses v5.98.0 (instead of pancurses v0.16.1) that clearly halt the compilation with exit code 101 on my windows 10.

[andreabenetton]

Remove daemonize or ensure it's only compiled on linux/macos builds.
Remove/make conditional the grin wallet start daemonize command

The only piece of code that uses the daemonize library is contained in server.rs file line 166-181

Do you think to replace these lines via a conditional compilation on windows platform that creates on 1st execution a windows service via winapi crate ?

[yeastplume]

Nice, thank you for the dependency syntax.

I was just going to make the daemonize functionality linux only for now... sure we can look at running it as a service, but perhaps as a future enhancement.,

[hashmap]

@yeastplume can we close it?

[yeastplume]

Indeed