1. 10

I am looking to port some of my software to windows/ensure it works on windows. Wine will almost certainly not cut it; I don’t want to have any possibility of an issue arising because of it. A VM wouldn’t work either, because my computer is pretty weak, so I’m left with using genuine windows. Viable options are (from what I’ve seen): windows 7, windows 10 LTSC, and normal windows 10 enterprise. My main concern is the lack of a real terminal terminal/shell. I had used windows 10 LTSC at one point, with WSL, which was–ok. However, all the native windows terminals had serious rendering issues, I eventually resorted to running gnome-terminal through vcxsrv, but that had noticeable input lag–and I’m not normally a person who notices input lag. I would like to try microsoft terminal to see if it fixes those problems (seems likely it does), except it doesn’t work with windows LTSC or 7. So it looks like my options are:

  • Window 7: zero crap, but: no good terminal, need cygwin for a unix shell, support ending soon

  • Windows 10 LTSC: not much crap, WSL for unix, but still no good terminal

  • Windows 10: lots of crap, but WSL2 (better than WSL!) and ms terminal

So far I’m leaning towards using standard win10 and just dealing with the crap, but is there anything I somehow missed while looking for windowses?

  1.  

  2. 17

    Windows 2000.

    And no, I’m not really joking… maybe a little.

    1. 2

      It’s still the best for me. Great system when you were used to Win95, Win98, WinME before. Ran all the XP software and games but without the online activation hussle of XP when you changed or reinstalled the PC.

      1. 2

        Heh. I was going to say the same thing. I ran Windows 2000 from beta until EOL. It was NT 4 with DirectX.

        But, glad I don’t need to run Windows at all anymore.

      2. 9

        Finally made an account to post this. I’ve certainly been on team linux moreso than windows since the late 90s but in the past month I’ve gotten a very nice, very modern setup on the latest insider builds of windows 10. All of the “crap” can be disabled, and didn’t take a very long time in the new builds. Turn off cortana and whatever else starts on bootup and Windows is just absolutely no longer annoying. Specifically the start menu improvements. Just install stuff with chocolatey.

        The microsoft terminal is exactly what you’d want it to be though and paired with WSL2 specifically I find it reasonably uncompromising and fast. I have docker working within it perfectly atop both Alpine and Ubuntu-18.04.

        The docs here and at the “command line” blog are basically all I followed. https://devblogs.microsoft.com/commandline/ https://docs.microsoft.com/en-us/windows/wsl/about https://www.windowscentral.com/how-join-windows-insider-program

        Protips: you can pipe between windows and linux applications back and forth and it “just works”. Visual Studio Code has interop w/ the WSL that also “just works”, as does the “localhost” development story for things that open ports on the thin wsl2 sidecar hyper-v thing that runs a full linux kernel. You can browse your linux filesystem with explorer.exe and it’s fast. There are a few X servers for windows, but the paid X410 is the one that works the best and makes it so i can’t tell the difference between which windows are linux and which are classic windows programs.

        In general I never thought I’d be on team Microsoft in this respect. I pretty much think with these strides it’s likely the death of Windows a second class citizen in many respects.

        1. 1

          Thanks for the reference to X410. I’ve been dabbling more with WSL2 in an attempt to avoid macOS lock in, however VcXsrv was too quirky with Intellij for me.

          While I can still tell the difference between Intellij running natively on Windows compared to X410, particularly my intolerance for font rendering on Linux, it’s feeling acceptable enough to continue down the WSL2 path (still hoping for Intellij to support WSL2 directly ala VS Code Remote!).

          I’ll say that the new windows terminal app is promising too, but lacks a lot of the polish that I’ve grown accustomed to from iTerm2… primarily around searching output and generating clickable hyperlinks.

        2. 7

          Another option is “refuse to play”. I don’t like that I paid for an operating system and still get ads and crapware, so I give windows zero thought when I develop.

          1. 4

            For those who are wondering what LTSC means, it is “Long Term Servicing Channel”.

            1. 4

              Use Windows 10 LTSC indeed.

              1. 4

                Is there a reason you can’t use Cygwin? I use it for developing on Windows. The terminal is fine, and you can even build standalone windows applications without any Cygwin dependency.

                Edit: Referring to the mintty terminal and the mingw64-i686-gcc-core package.

                1. 3

                  It’s slow though, especially for CPU intensive tasks

                  1. 2

                    Came here to ask basically this. I do some Windows development occasionally and just use MSYS2 or whatever with mingw64. Yes it is not fast, but it is usable. I also occasionally just use good old cmd.exe with a Makefile since that is how I started and it’s not like you can’t do that anymore… How does the poster think we wrote software in Windows 95/98 days??

                    1. 1

                      Mainly I am concerned about input lag–which was quite high when running gnome-terminal from wsl through vcxsrv–although, it may be better with cygwin since that’s running as a native app–except, maybe not: siblings suggest it’s slow.

                    2. 2

                      Have you considered using a beefy Windows Desktop VM hosted in the cloud? Then your weak computer is just an RDP client, depending on your network connection it might be bearable.

                      I looked into AWS Workspaces before work gave me a Surface laptop with Win10 on it, I think Azure and GCP have their own offerings too.

                      1. 2

                        I’d definitely recommend this approach if you just want to occasionally use windows for testing. Much cheaper than buying a windows license outright.

                      2. 2

                        X11

                        1. 1

                          My experience of Windows 10 Enterprise is that it doesn’t have all of the crap that I see people complaining about Windows 10 for. Has to be Enterprise – Professional has all of the crap.

                          1. 1

                            The last Windows I used was Windows 2000 so I’m curious what does “crap” mean here.

                            1. 4

                              There’s ads in the start menu these days.

                              1. 2

                                Ads in the start menu, not being able to postpone updates.

                                1. 1

                                  Thank you and @danielrheath. That sounds egregious.

                            2. 1

                              Good news! You don’t have to port your application to Windows.

                              Because, your users, who appreciate your well crafted application, do not themselves use Windows, and also because of the other five good reasons.

                              (I just made that up. You’re in a better position than I am, Elronnd, to flesh out the argument.)

                              Cheers and happy hunting!

                              1. 3

                                Because, your users, who appreciate your well crafted application, do not themselves use Windows

                                Unless you know something I don’t (they’ve made two posts on lobsters, and lists no software authorship in their profile) that’s ridiculous.

                                It makes the core assumption that people who value good software don’t run Windows. Obviously, some people are forced to run Windows because they are forced to run certain applications. Other people run Windows because programs they actually like only work on Windows. And some people switched to Windows because it actually seems to have a better system layer for graphics and sound than Linux does*.

                                * That last one is me. I ragequit desktop Linux because of the double whammy of not being able to get audio out of my laptop’s HDMI port, not being able to run multiple monitors with different DPI settings, and irritatingly fidgity support for Bluetooth. Yes, I tried both with and without PulseAudio, and couldn’t get it to work either way. Neither of those two things seemed to be driver-related problems, since the laptop is basically just an Intel SoC in a case; that’s just the result of the FOSS desktop being chronically ten years behind the commercial offerings.

                                It also makes the core assumption that Elronnd is willing to just forgo users of the world’s most popular desktop operating system, who, as I said again, might have no choice, or might have different values, or might just not have very good taste. That’s a bad decision if you’re an OSS developer who wants to establish a new standard, and it’s a bad decision if you’re a commercial developer that’s trying to actually develop desktop software instead of engaging in the much-maligned-on-this-board practice of developing web-based SaaS.

                                1. 1

                                  notriddle, my message employed subtext. Please review. (Hints: the phrase “the other five good reasons” doesn’t connect to anything; it is left dangling. The parenthetical specifically states that I “made up” the preceding sentence. There is a striking difference between possible interpretations of my whole post vs. possible interpretations of the first twenty-five words alone.)

                                  Also, I use Windows every weekday, but not after 7pm.

                                  I believe that it’s morally wrong (and maybe ethically wrong, depending on who your peers are) to put another twig in the bonfire that is Windows. Why? Because the stage is set for software to define the nature of the lives of the next five generations of humans, and that software which does not preserve individual agency is software that diminishes it. That would be my reason, but Elronnd may have others. Whatever the outcome, I have done my moral duty: I said ‘don’t’ when asked how to port software to Windows.

                              2. 1

                                The windows 10 terminal has been steadily improving as MS fixes the corner cases in order to get a decent WSL experience. It seems quite capable of (for instance) allowing me to ssh into a Linux server & run emacs inside tmux there. So for me the most tolerable version of Windows is probably the latest Windows 10 release (1904?) with WSL if required.

                                1. 1

                                  You don’t really have a choice in this. Older versions of Windows are not alternative choices, but the same lack of choice shifted by a few years back. The same question in a few years will be:

                                  • Windows 10: zero crap, support ending soon
                                  • Windows 11: lots of crap
                                  1. 1

                                    The lack of support doesn’t bother me too much. The browser already provides what sandboxing I need for running websites; the most native applications can do is gain root, which is not so bad if they’re malicious, given they already have native code execution.

                                  2. 1

                                    This week a windows update completely thrashed my git index. To think that I paid for this shit :/

                                    1. 1

                                      Windows 10 is pretty nice actually. It shocks and dismays me to say that because I was a hater for many years, but the accessibility features are excellent now, and as you say WSL makes things tolerable save for the terminal situation.

                                      1. 2

                                        I am sad that my experience did not match up with yours at all. I had to use windows 10 for a period of time (linux driver for my wifi dongle crashed), and could–not–stand–it. Slow, buggy mess.

                                        1. 1

                                          This is where I think buying your hardware from a shop that really does careful driver integration helps a LOT.

                                          Alienware really puts a lot of care into tuning the drivers that go into the Windows 10 install in their laptops.

                                          1. 2

                                            I don’t think it’s the drivers; I think it’s just the OS.

                                            Certainly, I don’t believe any of the things I experienced were attributable to the drivers.

                                            1. 2

                                              I am honestly just curious - what were some of the things you encountered? I’ve been using Windows 10 as my primary at home work environment for the last few months since my Kubuntu install ate itself and it’s been pretty great.

                                              I’ll go back to Linux eventually when I have time to mess with things again but it’s a bit of an uphill battle on an unsupported rig like mine.

                                      2. 1

                                        Just my 2c, but I’m using Windows 8.1 with ClassicShell. This removes the crap and provides for longer support.

                                        The situation with the terminal is interesting. I may be wrong, but my understanding is that they’ve been improving the VT rendering progressively throughout Windows 10 while at the same time modularizing the code. The new windows terminal is using a new graphical display, but modules like the part translating VT and managing the underlying buffer are shared between the new terminal and the old one. The reason this matters is it’s all on github and the old/GDI based one can be compiled and works on Windows 8.1.

                                        For Windows 10 LTSC, I assume you’re meaning the 2019/RS5 version? In this case all of the above applies but it’s built in, ie., it has a GDI based terminal that has all of the VT support added in the last few years. If you mean the 2016 version, it doesn’t have WSL, and the VT support is much more primitive.

                                        I haven’t used WSL2 yet, but since it’s a Linux VM I’m curious to see how it compares to other Linux VM options, of which there are plenty. But it makes me wonder a bit because you’re suggesting that your hardware isn’t beefy enough to run a Windows VM on a Linux host, so why would it be different to run a Linux VM on a Windows host…?

                                        If you really want a low-crap experience, another option is Server Core or Hyper-V server. That means no graphical compositor, but it runs WSL1, has the GDI terminal mentioned above, has another decade of support, and may be low-crap enough to run in a VM. I managed to get the Visual Studio build tools to install on it, which works for compiling my software. The big issue with it though is it may be too different to “real” Windows such that it’s not a great test environment.

                                        1. 1

                                          I may be wrong, but my understanding is that they’ve been improving the VT rendering progressively throughout Windows 10 while at the same time modularizing the code. The new windows terminal is using a new graphical display, but modules like the part translating VT and managing the underlying buffer are shared between the new terminal and the old one. The reason this matters is it’s all on github and the old/GDI based one can be compiled and works on Windows 8.1.

                                          Ahhh, that’s interesting. So you think if I compile their terminal and compile the original (cmd.exe-analogue) one, it’ll run on windows pre-1903, and be fully vt100-compatible, no glitches or anything?

                                          For Windows 10 LTSC, I assume you’re meaning the 2019/RS5 version? In this case all of the above applies but it’s built in, ie., it has a GDI based terminal that has all of the VT support added in the last few years. If you mean the 2016 version, it doesn’t have WSL, and the VT support is much more primitive.

                                          I ran LTSC 2019. It had WSL1 and had the rendering glitches in all the in-built terminal emulators (including third-party ones like conemu).

                                          I haven’t used WSL2 yet, but since it’s a Linux VM I’m curious to see how it compares to other Linux VM options, of which there are plenty. But it makes me wonder a bit because you’re suggesting that your hardware isn’t beefy enough to run a Windows VM on a Linux host, so why would it be different to run a Linux VM on a Windows host…?

                                          There are a couple of things there. #1 is that it’s specifically tuned to be lightweight; low memory usage, kernel options tuning, dynamic memory/cpu scaling. #2, and possibly more importantly is graphical performance: the main reason that the VM is slow is that it uses software graphics rendering (I read about a way to make it take over the graphics card so it does use hardware rendering, but then there is no way to get graphical output from the host; it seemed very error-prone, difficult to set up, and an easy way to soft-brick your computer because you don’t get any graphical output. Fixable with live cd, of course, but overall more bother than I care to figure out.) With WSL2 there is no need for graphics, so that’s simply not an issue. With hardware support, virtualization is pretty close to zero CPU overhead for the guest. Now, I haven’t tried it personally, but from what I’ve heard it works well–and performs better than WSL1.

                                          If you really want a low-crap experience, another option is Server Core or Hyper-V server. That means no graphical compositor

                                          Ah, yeah, that probably wouldn’t work then. One of the things I want to test is a graphic-heavy video game, so–I need that compositor. (I assume compositor means something different on windows, something essential to graphics? On linux it just means an optional program you can run to make your windows look nicer.)

                                          1. 1

                                            So you think if I compile their terminal and compile the original (cmd.exe-analogue) one, it’ll run on windows pre-1903, and be fully vt100-compatible, no glitches or anything?

                                            I think it’ll run pre-1903, with the same level of vt100 compatibility as windows terminal. I’m not saying that it will have no glitches; if you’ve already determined that 1809 is glitchy with the software you’re running it seems unlikely that it will have been fixed since, but it’s possible.

                                            I ran LTSC 2019. It had WSL1 and had the rendering glitches in all the in-built terminal emulators (including third-party ones like conemu).

                                            Conemu is just running a regular windows console somewhere and screen scraping the output, so it’ll do the exact same thing.

                                            more importantly is graphical performance: the main reason that the VM is slow is that it uses software graphics rendering…With WSL2 there is no need for graphics, so that’s simply not an issue.

                                            But can’t any Linux VM be run without graphics in the same way as WSL2? If all you want is a command line, a Windows based SSH client to a Linux VM works with no graphics at all. X11 can be used over the network stack with both. It sounds to me that WSL2 implies there are no graphics, thus solving the Linux VM graphics performance issue, but using graphics with a regular VM is optional.

                                            I assume compositor means something different on windows, something essential to graphics? On linux it just means an optional program you can run to make your windows look nicer.

                                            It’s pretty much the same thing on Windows, but for a graphically intensive game a server core VM sounds like a bad idea.

                                            1. 1

                                              But can’t any Linux VM be run without graphics in the same way as WSL2? If all you want is a command line, a Windows based SSH client to a Linux VM works with no graphics at all.

                                              Well–what I want is to use linux as a dev environment for compiling/running the windows applications. So it would have to be running locally, with the windows partition mounted somewhere it could be seen, and able to run the windows apps.

                                              [compositor] pretty much the same thing on Windows, but for a graphically intensive game a server core VM sounds like a bad idea.

                                              Ahh, ok. Might consider that for the native install, then, but yeah, windows in a vm probably wouldn’t work out.

                                        2. 1

                                          FWIW, if it’s a console application there were seem to be more differences than I thought. I remember filing a bug because colors and/or ansi chars didn’t work on my machine (win7) when they were supposed to work on win10.

                                          I know this is vague and I can look up the specific bug if needed.