I run a fair amount of *nix software on my Windows machine - not because it's easy, but because it has become apparent that this die-hard Mac user needs a more diverse portfolio (for personal reasons; I have successfully avoided Windows for my entire career to date). In fact, it's quite difficult compared to running the same software on macOS, which isn't too surprising since macOS is generally considered to be a member of the *nix family, while Windows is not.
This document contains a random bag of things that will cut you as you attempt to cross the streams, and also the occasional tip or trick.
- There are many choices of 'environments' for building / running things, such as: MSYS2, Cygwin, Anaconda, VCPKG, WSL. They can be used concurrently (with important caveats; keep reading), and the correct one to use for a given task likely depends on compatability requirements of the software you're making or using.
- path handling is a mess (WSL purports to ease this pain somewhat)
- Use ^ instead of " for quoting when possible
- Embrace the silo
- Be extremely fastidious, purposeful, and restrained with your environment variable configuration. In general, simply avoid making permanent changes to any environment variables.
- It's probably best to keep things installed by a given distribution as isolated as possible, unless it's explicitely obvious that sharing is intended.
- Use the front door. Often times, the environment you're using offers some kind of entry point that prepares the executing process for that environment, by setting (you guessed it) environment variables. You probably want the effects of any environment configuration defined by any of these environments to apply only to the environment it was created for. You can achieve that mostly by using the correct console / shell for each environment, and ONLY that environment. In a nutshell: recycle but DON'T reuse. This also means your shells and consoles (you will have several) are difficult to configure in a consistent way due to the incentive to not re-use. Talk about a first-world problem!
Failure to keep your worlds separated might lead to things like this:
Read this twice: https://github.com/msys2/msys2/wiki/MSYS2-introduction:
Key callouts:
Beware that mixing in programs from other MSYS2 installations, Cygwin installations, compiler toolchains or even various other programs is not supported and will probably break things in unexpected ways. Do not have these things in PATH when running MSYS2 unless you know what you're doing.
(you might think you know what you're doing, but allow me to suggest heeding the above warning)
Use msys2 shell for running pacman, makepkg, makepkg-mingw and for building POSIX-dependent software that you don't intend to distribute. Use mingw shells for building native Windows software and other tasks.
From https://github.com/msys2/msys2/wiki/Porting#user-content-filesystem-namespaces:
Paths in mingw Python
The mingw python provided by MSYS2 will try to produce paths that are right for the environment it's running in. According to the value of MSYSTEM, it will use either forward or backward slashes as os.path.sep.
Response files
When passing arguments with absolute paths to native Windows programs (such as /mingw64/bin/gcc), these paths get (in most cases) automatically converted by MSYS2 if they're in POSIX format. However, if you're passing these paths inside a file (e.g. a response file for GCC -- gcc @somefile), they need to be pre-converted to Windows native format.
Command line parsing
Windows programs parse the command line themselves, it isn't parsed for them by the calling process, as on Linux. This means that if wildcards (glob patterns) are to be accepted by the program, it has to be able to expand them somehow. MinGW-w64 supplies the correct start-up code, so it happens automatically, in a manner compatible with MSVC-compiled programs. If undesirable, the behavior can be disabled at program build.
Cygwin/MSYS2 programs have to deal with a mix of both approaches, but they can apparently deal with it. Note that they don't behave exactly like native programs, for example they understand single-quoted arguments.
Unless I'm missing something, I'd say they can only kinda sorta deal with it...
From "Everyone quotes command line arguments the wrong way":
Because the quoting rules for CommandLineToArgvWcmd's differ from those of cmd, we cannot give a command line intended for the former to the latter and and expect our arguments to survive the trip. Because this difference is subtle, it's easy to forget about it and leave latent bugs in programs that interact with cmd. All of cmd's transformations are triggered by the presence of one of the metacharacters (, ), %, !, ^, ", <, >, &, and |. " is particularly interesting: when cmd is transforming a command line and sees a ", it copies a " to the new command line, then begins copying characters from the old command line to the new one without seeing whether any of these characters is a metacharacter.
- download and run FileTypesMan
- select an extension you'd like to customize
- Choose "new action".
- Specify a Command something like shown below, being sure to quote the last argument (%1) which passes through the path to the document being opened
"G:\media-autobuild\local64\bin-video\mpv.exe" --config-dir=G:\media-autobuild\local64\etc\mpv --force-window "%1"
-
Make a .cmd file:
set root=C:\Users\andre\work\play-with-mpv set py=G:\Apps\Anaconda3\python.exe cd %root% %py% %root%\play_with_mpv.py
-
Schedule with Task Scheduler
File "g:\apps\anaconda3\lib\site-packages\pipenv\core.py", line 360, in find_a_system_python
python_entry = finder.find_python_version(line)
File "g:\apps\anaconda3\lib\site-packages\pipenv\vendor\pythonfinder\pythonfinder.py", line 108, in find_python_version
match = self.windows_finder.find_python_version(
File "g:\apps\anaconda3\lib\site-packages\pipenv\vendor\pythonfinder\pythonfinder.py", line 63, in windows_finder
self._windows_finder = WindowsFinder()
File "<attrs generated init dd945291b0b1e93a8c72035cacb0761f4492555d>", line 13, in __init__
File "g:\apps\anaconda3\lib\site-packages\pipenv\vendor\pythonfinder\models\windows.py", line 92, in get_versions
py_version = PythonVersion.from_windows_launcher(version_object)
File "g:\apps\anaconda3\lib\site-packages\pipenv\vendor\pythonfinder\models\python.py", line 417, in from_windows_launcher
creation_dict = cls.parse(launcher_entry.info.version)
File "g:\apps\anaconda3\lib\site-packages\pipenv\vendor\pythonfinder\_vendor\pep514tools\_registry.py", line 75, in __getattr__
raise AttributeError(attr)
AttributeError: versionThis can be caused by stale registry entries pointing to non-existent Python installations. Delete them. See also: pypa/pipenv#3380. You can work around this by specifying the full path to the interpreter when installing new environments:
pipenv install --python=G:\Apps\Anaconda3\python.exe
Sometimes when you're Pythoning, you encounter a module that needs to build native extensions, such as webrtcvad. Even if you have Visual Studio installed, that's probably not enough for everything to 'just work'. You probably want to grab the separate package called Build Tools for Visual Studio 2019. Install the C++ build tools, after which you can launch a "Developer Command Prompt for VS 2019" command prompt, which comes with all the environment variables you should need to build C++ stuff.
Remember what I said about re-use and silos? I guess not, because you went and configured your wsl user's $HOME to be your Windows user's home. Except hey now, those are two totally different kinds of filesystems. Sure, things appear to work fine for a short while, but one thing that doesn't work as expected from the WSL side is file permissions and ownership, which SSH will be happy to inform you about when you try to use public key auth. For example, note that a wsl resident (in this case Ubuntu) and PowerShell disagree about the permissions on my private key:
andre@honk ~ % cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"
andre@honk ~ % ls -al /mnt/c/Users/andre/.ssh/id_rsa
-rwxrwxrwx 1 root root 1675 Dec 30 2017 /mnt/c/Users/andre/.ssh/id_rsaPS C:\Users\andre\.ssh> ls id_rsa
Directory: C:\Users\andre\.ssh
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 12/30/2017 12:20 AM 1675 id_rsa
PS C:\Users\andre\.ssh> Get-Acl "C:\Users\andre\.ssh\id_rsa"
Directory: C:\Users\andre\.ssh
Path Owner Access
---- ----- ------
id_rsa HONK\andre HONK\andre Allow FullControlAs of 'Insider Build 17063', a new mount option "-o metadata" has appeared which purports to bridge file ownership and permissions between Windows and wsl. Even though that's almost two years old as I write this, that situation still seems kinda sketch to me, so I abstain. But if you must, read this.
- Disable fast boot, or every other boot might fail (probably specific to my config... Also this is a firmware setting, so why is this even here?!)
- DO NOT install the Razer Chroma whatever SDK if you enjoy playing any Blizzard game.
- Don't have too many NVidia SDKs installed concurrently ... or else be prepared for very lengthy driver updates.