Nix on Windows?


#21

Wouldn’t WSL mean that you would still have to cross compile everything? Otherwise you’d just be creating Linux executables.

I suppose you could invoke Visual C++ impurely in Nix and produce some stuff that way. But we’re pretty committed to free software in Nix/Nixpkgs/NixOS community. I definitely don’t think we should be supporting it. I would encourage everyone to give GCC/MinGW another try. I’ve found it to be pretty useful.


#22

From this post - https://docs.microsoft.com/en-us/windows/wsl/interop - it would seem that invoking native windows executables from WSL is trivial. So cross compilation shouldn’t be necessary.

I guess the point is that they are orthogonal concerns. If you set allowUnfree, you can get unfree software; Visual C++ could be one of those. If you want to use the GCC/MinGW toolchain, that’s cool too.

But you said ‘impurely’, which makes me think I’m missing something - why would it be impure please?

Thank you!


#23

It will depend if the MS C++ toolchain can be moved into a derivation output or not. Ideally the installer can be instructed to install into $out. The last time I checked, Windows executables weren’t supposed to write into the WSL filesystem.


#24

Yeah I guess that can work. It looks like you should even be able to do execv(“hello.exe”, …). I wonder if there is a way to ask the kernel whether it supports that? If so, we can add “x86_64-windows” as an “extraPlatforms” in Nix:

After that we will just need to get bootstrap tools to work (it looks like there is no busybox available for windows?).

On Visual C++, I think you can just download the SDK directly from Microsoft:

https://developer.microsoft.com/windows/downloads/sdk-archive

You can probably get that packaged into a derivation. We already do a similar thing with XCode. However:

  1. XCode is the only known way to build iOS apps, while you can build Windows apps with GCC.
  2. XCode uses LLVM internally that is already supported in Nixpkgs. I suspect that lots of internal changes would be necessary for Virtual C++ to work in Nixpkgs.

#25

Well, if it’s enough for you to also run the resulting packages inside WSL…

EDIT: this really depends on how good WSL can get in general. It would be really interesting if most SW could just drop developing Windows variants and stick mostly with POSIX (over the long term). Getting compatibility on par with Linux vs. *BSD differences might be quite a difficult task for the implementors, but Microsoft is surely big enough to afford that, and it might theoretically even pay off for them, helping to keep more people using Windows.


#26

@zimbatm btw I opened https://github.com/NixOS/nix/issues/2503 on what I consider a blocker for building Nix as a proper windows executable.


#27

Has anyone looked into getting an official WSL release for NixOS? It looks pretty straightforward:

Someone interested could probably get it set up in less than a day and perhaps we can get it accepted in the store. I don’t have WSL set up on any of my Windows machines right now to work on this.


#28

He has been working on this for quite a while now


#29

I would reserve “x86_64-windows” and “i686-windows” for the versions free of WSL and Cygwin.
We already have them as a cross-compilation target (pkgsCross.mingwW64 and pkgsCross.mingw32) and they could bootstrap in the future.


#30

Do you see any other options here except

  1. Use Windows symbolic links (nixbld users must have SeCreateSymbolicLinkPrivilege)
  2. Use unprivileged hard links and store somewhere (in file streams?) information for GC about the “direction” of the links

#32

I think there is still hope that creating symlinks might come one day without special https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/


#33

"
Now in Windows 10 Creators Update, a user (with admin rights)
can first enable Developer Mode, and then
"

It does not seem more convenient than just to grant “SeCreateSymbolicLinkPrivilege” to the users who need it


#34

This could be done as part of the installer. Sounds more robust then messing with hard links.


#35

Do you see any other options here except

  1. Use Windows symbolic links (nixbld users must have SeCreateSymbolicLinkPrivilege)
  2. Use unprivileged hard links and store somewhere (in file streams?) information for GC about the “direction” of the links

Are there unprivileged directory hard links? These seem to be a substantial interesting problem for implementation…

When you are building against glibc, you could always patch glibc to treat desktop shortcut files (lnk) as symlinks — at least PocketBook did that for their Linux-based firmware with FAT32-formatted microSD cards, and it worked. I do not say it is a good idea; symlinks are probably better.


#36

Actually, there is no choice on how to implement symlinks.
There are symlinks in git repos (for example LLVM’s) and source tarballs, so the only option is to follow Git’s and archivers choice.

A funnier problem is the prefixes added by Nix (not only nix store paths like C:\nix\store\nj8672hwq8r54b9f1njs1i1dwajipncd-material-sprited-animation-view-ios-8af9ada\, but also build roots like C:\Users\User\AppData\Local\Temp\nix-build-chromium-73.0.3660.2.drv-0\chromium-73.0.3660.2-src\) often result in full paths longer than 254 chars. Supporting longer paths requires special effort not only from Nix itself but also from all the programs involved into build process (long paths passed to API must be absolute, must contain no \..\ and be prefixed with magic prefix \\?\).
That means:

  1. there is no reliable ready-made to do cp -r. Windows’ own xcopy does not work with long paths. robocopy does, but it has other bugs (it cannot copy from readonly nix store, so cannot be used on unpackPhase after fetchzip/fetchgit).
  2. stdenv.shell (the script language used in buildPhase, etc) should support long paths. Currently I am using Perl which does not support it out of the box, so I have to use https://metacpan.org/release/Win32-LongPath and thus resulting code is not portable. Perl’s own function open, glob, … do not support long paths and cannot be used on Windows reliable, Win32::LongPath's functions are Windows-only. So I am in doubt what could be a portable stdenv.shell then… nodejs? miniruby?
  3. Third party build tools should be fixed. So far only cmake correctly handled long paths (I did not investigated how, just saw a cmake warning about “path being longer than 255 bytes” but the build succeeded), ninja has the problem (https://github.com/ninja-build/ninja/issues/1514)