Nix on Windows?

Development
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.

5 Likes
22

From this post - Working across file systems | Microsoft Learn - 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:

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.
1 Like
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.

1 Like
26

@zimbatm btw I opened Rewrite build system in non-autoconf · Issue #2503 · NixOS/nix · GitHub on what I consider a blocker for building Nix as a proper windows executable.

3 Likes
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.

2 Likes
28

https://twitter.com/GeoffreyHuntley/status/1055407117589303296?s=19

He has been working on this for quite a while now

2 Likes
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.

4 Likes
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 Symlinks in Windows 10! - Windows Developer Blog

1 Like
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.

1 Like
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 Win32-LongPath-2.2 - Windows file functions that use very long paths and Unicode. - metacpan.org 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)
4 Likes
37

Hi, I’m just sorta new to Nix and learning about it.

Is there a tracking issue somewhere for native windows support?

Much like what was said in this comment I am not as interested in WSL since it doesn’t play nicely with various IDEs

2 Likes
38

Image of Windows with installed native Nix is at
magnet:?xt=urn:btih:8124507E71C42E5496F922589B3FB79D7C9A90F0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80 (login Administrator, password Abc123)

Note that it is in early alpha and many things do not work as well as on Linux (for example, Nix Store is not protected from writing)

12 Likes
39

I made a #nix-windows IRC channel on Freenode, BTW.

3 Likes
40

I got up to half, but I gave up because it was too big. I hope the official version of nix for windows will be released someday.
.
Of course it sounds ridiculous. It might be faster to @volth join ms and make ㅡ.ㅡ. hehe

1 Like
41

Hi @volth, are you still around? I’ve missed you on GitHub, and interestingly GitHub knows that you had some branches that were ahead of their nix-windows counterpart-forks. I was curious if you’re still working on Nix for Windows, if you could send those commits to us somehow, etc. (I can be reached at cole.mickens@gmail.com or in #nix-windows too if thats better).

2 Likes