1. 31
  1.  

  2. 7

    Earlier examples of this problem:

    1. 3

      This reminds me of so many other situations wherein open-source projects have problems with Windows (that would not be problems if more of those devs were Windows devs) and usually people don’t notice right away because no one is testing it. I think this is still a thing when it comes to Python tools on Windows.

      1. 5

        Not all problems can be preempted by tests :)

        In this case it was more like the tests didn’t really do a full registry fetch; since the tests all run without needing internet iirc. Even if the tests did do a registry fetch, this would only be caught the next time someone ran the tests against a modified registry, you can’t preempt this problem until it happens. People did immediately notice however and ping the team so it could be rolled back.

        Last I checked we were testing all platforms for cargo and rustc.

        Many rustc devs use Windows so it’s not that bad. Though it did take a while to get proper debuginfo on windows way back.

        1. 2

          Not all problems can be preempted by tests :)

          Sure they can, if you’re willing to wait long enough on your test suite :)

          (I’m certainly not claiming that this should’ve been tested for. Sounds like it was handled fine.)

        2. 5

          Amen. I’ve personally been Linux-only for about a decade, but I maintain an open source command line tool that purports to work on Linux, Mac and Windows. Windows has been a neverending hole. (And I say that without blame. Perhaps it isn’t Windows fault, and it’s just my unfamiliarity with the platform, or maybe it’s just how end users have adapted their interaction with the platform. Nevertheless, this is my experience.) Just off the top of my head, without looking at my issue tracker:

          • Colors in a terminal are done completely differently than on Unix, and require synchronous interaction with the Windows console. If your tool writes to stdout from multiple threads, this is a problem. (I’ve fixed this.)
          • Windows users are split between cygwin and PowerShell/cmd users, which means Windows actually needs to be able to support ANSI coloring too. (I’ve fixed this.)
          • There’s no portable API for determining, on Windows, whether you’re at a tty or not when you factor in both console and cygwin users. (I’ve fixed this.)
          • Windows programs are responsible for doing their own globbing on arguments given to argv. (Not fixed.)
          • Long file paths require special attention and don’t Just Work. (Not fixed.)
          • Symlinks are a minefield, in general, especially when cygwin gets involved since cygwin has its own “seamless” path translation code. (Not fixed.)
          • Defining “aliases” or “wrapper scripts” is purportedly so hard (according to my users) that a configuration file for including common flags in my tool is a hugely desirable feature. (Not fixed.)

          There are more problems, but I’d have to go look at my issue tracker to remember them. Some of the aforementioned issues would be fixed if I were linking with cygwin and using those APIs, but then Windows users are forced to use two separate binaries based on which environment they’re in. (And there are operational problems with me using cygwin this way anyway, since I’m not using C.)

          I’ve also started getting bug reports from Windows users that are using Bash on Windows. I’m not looking forward to supporting a third environment just from within Windows itself.

          1. 1

            I’m helping an engineer at work setting up better dependency management for his c++ projects, the life of a windows dev is hard… I mean just getting a way to compile libmodbus properly is a challenge we still havent solved (Short of putting the files manually in the project or cross compiling from linux to windows)

            How do win devs get c/c++ libraries outside of the .net ecosystem?

            1. 3

              How do win devs get c/c++ libraries outside of the .net ecosystem?

              C/C++ projects usually have way less dependencies and they don’t change that often.

              Keeping the dependencies inside the source control is effective way of making sure you don’t have to setup dependencies again.

              1. 2

                I recently discovered Conan. Maybe that helps?

                1. 1

                  I like the idea, I’ll see if I can compile a package

            2. 3

              Doesn’t anyone learn how to make files with copy con myfile.txt anymore?

              1. 2

                I’d love to hear an epilogue where cargo and related projects are fixed to use the magic escaping path thing “\\?\” – is that planned/executed already?

                1. 1

                  From what I gather it’s not a practical solution as even explorer.exe does not use it.