27 ms·

Cross-compiling binaries for Windows is easier than building natively

454 points by emidoots 4y ago

colejohnson66 4y ago
Are symlinks on Windows really such a big issue? I’ve never heard of projects using symlinks in their tree. If Windows developers are complaining about you doing something unusual, why is it their fault?
- slimsag 4y ago
  Certainly better to avoid it if at all possible, and I'll be eliminating them specifically to improve Windows compatibility. It's not that unusual, though, a quick search turns up 1.1k GitHub repositories with `git config core.symlinks true` in their documentation or CI pipelines - including quite popular projects like Ava, Apache Arrow, Solana, Chrome Devtools, adobe-fonts, IBM/houdinID, travis-ci, RabbitMQ, various Google projects & more.
  - colejohnson66 4y ago
    I agree that Windows could do more to support the developers on other platforms. Symlinks just seem like a petty thing to complain about IMHO. Didn’t realize how common they were though. NTFS does support them, however. Is Git just not supporting them properly?
    - fortran77 4y ago
      That's exactly it. Windows developers know NTFS has Symbolic Links https://docs.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links?redirectedfrom=MSDN https://docs.microsoft.com/en-us/windows/win32/fileio/creati...
      - bilekas 4y ago
        Maybe I missed something on this discussion but symlinks and NTFS are not really related.. They have them yes, how they're handled is different.
        fragmede 4y ago
        How are they not related? If NTFS didn't have symlinks we wouldn't be having this discussion. Critically, the modern standard for removable drives, exFAT does not support symlinks, so you can't count on Windows' support for symlinks if the user is git cloning on a drive that's using exFAT.
        pjmlp 4y ago
        https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
        forgotpwd16 4y ago
        Pointing to this page is meaningless. `mklink /d` only works on NTFS but errors out ("The device does not support symbolic links.") on exFAT. GP acknowledges NTFS has symlinks and remarks that exFAT doesn't.
        pjmlp 4y ago
        NTFS is the only filesystem that matters for Windows developers.
      - CoastalCoder 4y ago
        What's the standard for being an "actual Windows user"? Asking because I doubt e.g. my mom knows that NTFS has symlinks.
        pjmlp 4y ago
        Is she a Windows developer? https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
        slimsag 4y ago
        The developers who complained to me about this are Windows developers regularly. One is even a professional AAA DirectX gamedev.
        pjmlp 4y ago
        Apparently not professional enough to know a feature as old as Windows 2000.
        Dylan16807 4y ago
        > What's the standard for being an "actual Windows user"? I think you misread that line.
        slimsag 4y ago
        Their message originally read "Actual Windows developers know NTFS has Symbolic Links"
        Dylan16807 4y ago
        So it did say "developers" and not "users"? I think they misread the line. (Whether it was right or not, so you don't need to tell me anything about that.)
    - slimsag 4y ago
      Well, it feels 'petty' and simple until: 1. You run into it, go "AH, wow, okay, I'll enable Developer Mode" 2. It still doesn't work, you're confused, you Google around a bit more and find out actually you also need to use a Git config option 3. You retry, now the symlinks work, but your compiler fails because "Destination Path Too Long", huh, that's weird 4. You google a bit more, and discover you need to set a registry option. So you do it, but you still get that error.. 5. You discover there's another Git option you need to set And then you're like, hey, what was I doing again? Where did the last hour of my time go? It's death by a thousand paper cuts.
      - deleted 4y ago
        [deleted]
      - giantrobot 4y ago
        Yak shaving.
    - pjmlp 4y ago
      It does support them, mklink. https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
      - colejohnson66 4y ago
        Yes, Windows does, but this post is complaining about support. Which led me to ask if Git is the problem. Cause Git also supports symlinks, but is clearly having issues on Windows.
        bogwog 4y ago
        I would assume the issue is that they need to disable symlink support by default on Windows because symlink support is disabled by default on Windows.
    - Pathogen-David 4y ago
      NTFS has supported them for ages. The main issue is that they're locked behind elevated permissions or having developer mode enabled (as of Windows 10.) My understanding is Microsoft's concern is that applications and OS components not expecting them could lead to security issues. Not sure how real that concern is, but that's the excuse I've heard.
      - nemothekid 4y ago
        >Not sure how real that concern is, but that's the excuse I've heard. Bufferoverun I guess? I haven't programmed Windows in years, but there's plenty of code I've seen that is pretty much char path[MAX_PATH]; res = some_func(&path); from there you put in a large path and then you get your RCE.
        MereInterest 4y ago
        That would be for removing the 260 character limit, not for enabling of symlinks.
      - MereInterest 4y ago
        I've looked before, and have never found a definitive answer from Microsoft. I've heard some speculation that it the nebulous security issues would be from a program that checks the permissions of a symlink's target, then opens the symlink. An attacker could then modify the symlink after the permission check but before the file is opened, escalating access by pointing to a restricted file.
        pxc 4y ago
        It's a kind of attack called a symlink race, which is also possible on other operating systems. There are kernel parameters for hardening against symlink races on Linux, and they just disable symlinking into world-writable locations. I'm not sure why Windows can't use a less invasive mitigation like that, but I guess there must be one.
        4y ago
  - deleted 4y ago
    [deleted]
- gizmo686 4y ago
  The higher level thing to notice is that Windows is a second class platform for much of the software world. As such, it is in a position where it needs to bend the knee for compatibility with the dominant platform if they want it to be an active player in the larger ecosystem. In the case of symlinks, the hard part is already done, to the point where it is a toggle that has already been implemented, the UX of enabling it is just bad.
  - pjmlp 4y ago
    For game developers and GUI applications it is first class. Apparently being the best in symlinks hasn't made a difference in the Year of Desktop Linux.
  - jeroenhd 4y ago
    Both soft links and hard links, as well as directory junctions, have been possible in Windows since Windows XP (though soft links have only been available since the release of Windows Vista 18 years ago). In fact, hard links are essential parts of Microsoft's solution to the DLL hell problem without wasting gigabytes of space. The problem people are running into is that the OS hasn't been designed with wild symlinks in mind and therefore can't guarantee its security principles if any user is able to symlink however they please; if I read the context [1] correctly, it seems like an elevation of privilege is suspected to be very easy to gain if a standard-level user is allowed to place arbitrary soft links on a file system. I see little reason for Microsoft to enable the "all users can soft link" setting by default. They'd need to audit their OS and userland code to determine where soft links may introduce vulnerabilities in order to change the default and a few developers that absolutely insist on using soft links inside git repos for some obscure reason isn't going to get them to make such an effort. Microsoft has made enabling the feature a bit easy [2] but I can find very little about the security analysis done for this change, so enabling dev mode might open your computer up to a whole class of vulnerabilities. I personally don't see a reason to use symlinks in a dev environment, but I suppose *nix developers think otherwise, probably to duplicate files across a source repository for some reason? If your intent is to work together cross platform then there are loads of restrictions you need to deal with. Linux applications tend to trip up over CRLF, every file system has their own stupid restrictions, build tools and shell scripts need to somehow become platform agnostic, you name it. You can blame Windows for being different but the truth is that Windows is still the most commonly used desktop operating system in the world by a huge margin. macOS and Linux are the odd ones out and there is no good reason why the POSIX/X11 system design is better or worse than Cacoa or Win32; it's a mere difference of convention. [1]: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links https://docs.microsoft.com/en-us/windows/security/threat-pro... [2]: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/ https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
- binarycrusader 4y ago
  You don't have to enable Developer Mode to enable symlink creation. Administrators have the right to by default and non-administrator users can get this by enabling the documented policy: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links https://docs.microsoft.com/en-us/windows/security/threat-pro... Developer Mode is just a bundle of useful developer-related settings and components that get applied to the device when enabled. There's a post here about this from the Developer Mode angle with a bit more background: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/ https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
- nicoburns 4y ago
  Projects don’t use symlinks because they aren’t supported on windows.
  - pjmlp 4y ago
    https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
    - Dylan16807 4y ago
      The command won't help when you don't have the permissions. Or do you just want it to be phrased "not supported for users on normally configured systems"? There, then.
      - pjmlp 4y ago
        Well, time to learn about /J flag.
        Dylan16807 4y ago
        Even if we pretend that's a symlink, it only works for directories, not files.
        pjmlp 4y ago
        We moved from Windows doesn't do it, it does but isn't available to non admins, it is but non admins can't do files,.... Yep.
        Dylan16807 4y ago
        We started at "not supported", talking about making symlinks inside projects. We backed off to "not supported on normal systems", which is a reasonable change to me. You mentioning junctions is not even close to a solution, and I am not moving the goalposts. If junctions worked, the complaint wouldn't have been needed from the start. No, this is about actual symlinks, not a similar feature that can do 5% of what symlinks can do.
- pjmlp 4y ago
  Nope, since XP that you can use mklink, and before there were Technet utilities for the same purpose. However using symlinks just isn't a thing in the Windows culture, people use at most Shell shortcuts.
- orwin 4y ago
  No, they're not really. And IIS is not that bad either. My main gripe with windows and why i won't develop on it anymore is simple that their system is too complex. I suppose this is the gripe of the article author as well tbh. Windows is horribly hard to learn. In a day, i learned how to create file, directories, change the stats on those, execute diff and patch, an do weird string modifications with grep and cut (and learn to commit and push with git). First day on an UNIX machine. First work week on a windows machine (at that time, i had already built a LFS): we have those two project with two different version of (proprietary JS front framework) and (weird php framework). Those don't use the same version of mycrypt.dll (and others, but this one i will remember for at least two dozen year). With the support of non-intern engineers including a windows DBA, it took us a week to manage to install the two different versions. A week prior, i was linking to a previous version of Ruby for my RoR app (it was around 2013). But since, i really respect windows sysadmin, they are the best of us. I will just never, ever want to work on a windows server again. I like learning, but putting that much effort for this little rewards? not worth.
jrm4 4y ago
Microsoft's days as a 'primary' desktop operating system are numbered. The OP doesn't seem to understand this, but even Microsoft itself does, which is why most of its major moves the past few years haven't been improving its own desktop, but positioning itself to control "open source" the best it can. More people within the MS ecosystem should understand this.
- deleted 4y ago
  [deleted]
- munchler 4y ago
  One can argue that desktops are no longer the primary computing environment, but I don't think there's any evidence that Windows is about to displaced within the desktop world. What are you proposing will become the primary desktop OS? Some Linux flavor of the month? MacOS? Neither seems at all likely in the foreseeable future.
  - jrm4 4y ago
    There won't be a "primary" and people will perhaps not pay much attention to which it is, any more than they pay attention to e.g. what Javascript framework their favorite site is using. I've come to realize while there may never be a "year of the Linux Desktop," there will likely be "years of Linux Desktops" -e.g. Ubuntu, but then also SteamOS, ChomeOS, maybe Android if you're being REALLY inclusive, etc.
- pjmlp 4y ago
  Better check those desktop market share numbers.
  - blibble 4y ago
    I suspect if you restrict it to developers the numbers would look very, very different on the stackoverflow survey windows is 41.2%: https://insights.stackoverflow.com/survey/2021#most-popular-technologies-op-sys-prof https://insights.stackoverflow.com/survey/2021#most-popular-...
Animats 4y ago
It is. I generate the Windows executables for a program by cross-compiling Rust on Linux. Then test with Wine. The Rust crates are cross-platform enough that I don't have to special case platforms. This is easier than having a Windows machine. The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files. If you dump the legacy OS stuff, it gets easier.
- ratww 4y ago
  Doesn't cargo-bundle do that? I haven't tried to use it to generate .msi files, only for iOS/macOS, but it has the feature!
  - Animats 4y ago
    Cargo-bundle was supposed to do that, but only the Mac part was completed. Nobody ever did the .msi output. I've been trying to get someone interested in doing that. That task needs someone very familiar with the Microsoft ecosystem, which I am not. Discussion in Rust tools forum here.[1] [1] https://internals.rust-lang.org/t/cross-platform-bundling/16773 https://internals.rust-lang.org/t/cross-platform-bundling/16...
    - deleted 4y ago
      [deleted]
    - giancarlostoro 4y ago
      I wonder if InnoSetup could be a good point of reference for anyone interested. It is in Delphi though, but there is also this guide I found whilst trying to figure out if you could run Inno Setup on Linux: https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd797 https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd7... Inno Setup was the best and easiest thing for me to ever use but when I was building Windows installers for use from a Windows OS. Update: Found this Cargo package rust-msi: https://github.com/mdsteele/rust-msi https://github.com/mdsteele/rust-msi
      - 4y ago
ntauthority 4y ago
Counterpoint for this rant (showing it's again not very objective, and just what your or your environment's expectations are): it's easier to cross-compile binaries for Linux (using Clang and a sysroot on Windows) than it is to natively compile on Linux (not using a sysroot, as that is the 'default' flow there) if your environment is mostly Windows already. We do this for one of our products, in fact. The post meanwhile seems to be part about open source policy (nasty, but not a technical issue - also including a new-to-me and hard to find on a Google or DDG search fact about the VS gallery endpoints having led to legal threats), part issues induced by 'weird' modern languages not caring to support Windows (as expected?), part Git for Windows not bothering to handle symbolic links cleanly (and the weird admin-only default thing that remained from Vista), and part... concerns where if people would spread the proper way of doing stuff (curl.exe bundled by default for downloads, or long file names being 'weird' - albeit less broken than claimed here) instead of just ranting this'd be fine too... but not really a coherent whole.
- thrdbndndn 4y ago
  My counterpoint is simpler: I use some of these tools (like VS Code) because they're better, not because they're open source. Also I don't think Pylance or whatever core extensions being closed source contradicts with the fact majority of VS Code (or vscodium) is open-source. And I don't see anything morally wrong that they want to close source some of their competitive products.
  - SergeAx 4y ago
    It may be not intuitive, but tools tend to be better because they are open source. My personal problem with Pylance or ssh tools is that they are not working with VS Code based forks. That means that VS Code is not that open source as it trying to look like. And this is suspicious for me.
    - anonymoushn 4y ago
      The ssh tool is incredibly slow and resource intensive and defaults to losing unsaved work on disconnect. An open source version would open up the possibility of a user fixing some of these issues.
labrador 4y ago
This what is called in Cognitive Behavioral Therapy "All or Nothing Thinking." Microsoft is a for-profit company. It is pro open-source when it helps them and closed source also when it helps them. I like the new Microsoft which has open sourced a lot of stuff. It's way better than the old closed source regime.
- unnouinceput 4y ago
  Oh, you and the article's author are either forgiven or seeing the best in people. Me, on the other hand, who lived the Microsoft with their shady dealings in Bill's / Ballmer's era, I remember their crushing on OEM's to not allow even a shred of openness in their systems. Only because of shifting in developer's in favor of Apple's / Google's Microsoft changed the tune with "Microsoft loves Linux". Bleah! I have no love for Microsoft despite my work involving their products 90% of my time. I am just realistic, they just love money, nothing else. And if money means open source, guess what?! They bought GitHub and they own everything that is published there. That's why plenty left GitHub and either started their own venture or went to GitLab. Sorry for my rant, I had to get it off my chest.
  - labrador 4y ago
    Gates and Balmer are long gone and it's no longer the same company. If they only loved money, they wouldn't be amenable to their workers unionizing. "CWA, Microsoft Announce Labor Neutrality Agreement" https://cwa-union.org/news/releases/cwa-microsoft-announce-labor-neutrality-agreement https://cwa-union.org/news/releases/cwa-microsoft-announce-l... Sorry to be this way, but I'm refreshing my memory about CBT today: Over-generalization: Make a comprehensive, negative conclusion that is beyond the current situation. Labeling and Mis-labeling: The extreme form of overgeneralization. Use fixed, comprehensive, and emotional language to label yourself or others. Disqualifying the Positive: Unreasonably believe that positive experiences, behaviors or qualities do not count. Jumping to Conclusions: Making a conclusion before having all the evidence. Emotional Reasoning: Draw conclusions from your own feelings, because what I think is what the facts are.
    - 4y ago
e4m2 4y ago
> Are derived community works, like say the D-language, Dart, or Zig bindings to the win32 API which are generated from those files open source - if Microsoft did not release them as such? Certainly. The source for these bindings is the WinMD file, which is MIT licensed. While it is true that its contents are generated wholly from non-FOSS sources, it doesn't impact end users of the metadata. Microsoft owns the original IDL/headers and can choose to license any related work however they like.
- deleted 4y ago
  [deleted]
- kibibu 4y ago
  If you read further down the issue comments, it's explained that the generated files don't contain all the info in the idl files.
- mhh__ 4y ago
  Although it's a point of pride that someone did manage to get D understanding the recent Win32 API specification extremely quickly (D is ridiculously good at this kind of metaprogramming), the bindings that actually ship with D at the moment are hand-maintained.
nshm 4y ago
For me SDK sizes are showstopper. Mingw packages are probably 100-200 Mb total. To build anything native one has to install Windows (20+Gb in modern version and then Visual Studio 40+Gb). Not so easy to fit it all on an SSD drive. Xcode also have this problem now. 8Gb for Xcode 7 is manageable. But why 70Gb for Xcode 11?
- recursive 4y ago
  There are very few things that actually require Visual Studio just to build.
  - steeleduncan 4y ago
    Interesting, how can I install just the cmake + msvc to do command line builds with windows? I'm also installing wsl2 + mingw because it is so much lighter for compilation than many, many gigabytes of vis studio.
    - aaron-stackbit 4y ago
      `msbuild` is what I used back in the day. It seems to still exist, but I have no idea if this is still preferred solution. I just use WSL 2 these days, and live with the extra io latency.
    - e4m2 4y ago
      Download the build tools[0] and choose the appropriate options. I'd personally consider the following a good baseline: MSVC v143, CMake tools, Windows 11 SDK, Clang tools (if you don't want/need these you can shave off 3.5 GB). `zig cc` is another interesting alternative, it's just a single ~62 MB download. [0] https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022 https://visualstudio.microsoft.com/downloads/#build-tools-fo...
      - steeleduncan 4y ago
        Thanks, I'll give that a try!
pjmlp 4y ago
Typical UNIX FOSS rant, not taking into account all the development workflows on Windows.
- shadowofneptune 4y ago
  It doesn't, no. If you are only working with libraries designed for Windows or are linking against binaries, most of the dev issues listed disappear. The point of the article is that the Windows push for open source introduces friction because the way of doing things with established OSS projects is so different.
  - pjmlp 4y ago
    Not every OS has to be a UNIX clone, we don't need an OS monoculture.
    - franga2000 4y ago
      You don't need to implement POSIX in order to not bundle your header files in a 9 GB "SDK" download, which isn't available as a direct URL download and can't be installed without user interaction via the GUI. This is a Microsoft issue, not a Windows issue.
      - jeroenhd 4y ago
        If MS would package just the header files, they'd probably get tons of complaints about compilers complaining about missing libraries, missing dependencies and toolsets not being available. The Windows SDK is not just a few C++ headers and a bunch of lib files to link against. It has a huge surface area. The documentation and toolsets assumes all API calls from Windows 3.1 APIs to UWP to be available. The SDK download (ISO format) is 1.1GB in size, requiring a total of 4GB of disk size to install (whether this includes the size of the installer itself is unclear). Big, but not unavoidably so, and you can pick and choose some features. It bundles debugging tools, the application identifier, a certification kit and MSI generation tools along with its headers (which seems fair to me); less than 1GB of extra kit on top of 1.8GB of headers and libraries you probably want as a Windows dev anyway. Just the headers won't leave you with a working dev environment even if you bring your own debugger. Unlike what some developers seem to think, you don't actually need to download Visual Studio to get the SDK, you can also download it separately from the website [1]. Pick the ISO version and extract the CAB files yourself if you want to manually pick and choose your files. The SDK ships as an installer but that just makes sense. Ubuntu ships their headers in DEB files as well, for example. You want to be able to add and remove these packages as you upgrade or downgrade your target API levels without having to manually set up a file system hierarchy. As for non-GUI interaction: `WinSDKSetup.exe /quiet /ceip off /features DesktopCPPx64` will install only the necessary headers and libraries for x64 C(++) development in the default location without sharing data with Microsoft. Found this command line with `wine WinSDKSetup.exe /?`. You can also add, repair, and uninstall packages with the same installer. [1]: https://developer.microsoft.com/en-us/windows/downloads/sdk-archive/ https://developer.microsoft.com/en-us/windows/downloads/sdk-...
Dylan16807 4y ago
Configure autocrlf in what way? I don't want git to change my files, and I don't know what problems they're talking about.
- slimsag 4y ago
  Configure it to respect your preference ('don't change my files') and not pester you with hundreds of warnings any time you interact with Git if your preference differs: warning: LF will be replaced by CRLF in src/au/policy/dao/EmailQueue.java
- thayne 4y ago
  If you have some developers using window, and other developers using anything else, without some kind of line ending normalization, then you will end up with inconsistent line endings, possibly in the same file, and potentially diffs and commits where every line in a file is changed from one line ending to another.
forrestthewoods 4y ago
It’s funny because I find compiling and deploying for Windows far, far, far easier than Linux. That said, the complaints are all good and fair.
dataflow 4y ago
Now try building a "portable" binary that runs on a version of Linux older than yours.
- rocqua 4y ago
  Isn't that simply a matter of targeting an older glibc? I am probably missing something though.
  - dataflow 4y ago
    Yes, "simply". It's a very fun process. Around 100 times more fun than the onerous git config --global core.symlinks true
    - andrewmcwatters 4y ago
      Anyone who talks nonchalantly about glibc hasn't had their time eaten up by glibc.
      - Spivak 4y ago
        Like it’s absolutely a nightmare but you can eliminate a lot of problems by building on an ancient version of RHEL.
        jeroenhd 4y ago
        It says a lot about Linux development that for cases like these "just install the Linux equivalent of Windows XP in a container and run the tools inside that" is an accepted solution. It's a solution that works well and is used by loads of developers, but it's still comically silly.
        account42 4y ago
        There are other approaches like https://github.com/wheybags/glibc_version_header https://github.com/wheybags/glibc_version_header or sysroots with older glibc, e.g. https://wiki.gentoo.org/wiki/Crossdev https://wiki.gentoo.org/wiki/Crossdev - you don't need your whole XP, just the the system libs to link against. Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.
userbinator 4y ago
Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes <250MB of disk space, and the self-contained binaries it generates will work on any version of Windows starting at Win95. Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~255 character limit. Personally, I think 260 is long enough and plenty to work with, while at the same time discouraging the ridiculous verboseness that seems to have crept into "modern" software. Then again, I stay away from .NET, VSCode, and the like. I am reminded of this post by Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20070301-00/?p=27803 https://devblogs.microsoft.com/oldnewthing/20070301-00/?p=27...
- akelly 4y ago
  It's incredibly fitting that all the links on that post are 403 Forbidden
  - userbinator 4y ago
    That's Microsoft being (the new, not the old) Microsoft... they seriously fucked up the MSDN documentation when it was migrated to docs.microsoft.com, so I'm not surprised that a similar thing happened to the blogs: https://news.ycombinator.com/item?id=20351358 https://news.ycombinator.com/item?id=20351358
    - naikrovek 4y ago
      they knew they would and they advertised that fact, and made blog and content owners migrate their stuff if they wanted it kept. many chose not to. those are the people you should be angry with.
      - denimnerd42 4y ago
        that's quite a take.. expecting previous article writers to manually migrate their stuff is just as good as killing it.
wdb 4y ago
I agree that symlinks cause more trouble then is needed on any platform. Sadly, only Node really likes to use them to optimise the store of packages Personally, I don't have major issues compiling things on Windows for other platforms (macOs, Win32, Android, Linux). Only awkward thing is designing UIs
- fyrn- 4y ago
  I don't think that's what they sre saying, I think they sre saying it's stupid Microsoft requires hoops for such a basic feature, hence "Fix Windows" being option 1
  - childintime 4y ago
    Such a basic feature? If the OS dedups a file, by putting in a symlink behind the scenes, no one need know a symlink (or something else) exist. That makes for a better user experience. There are less concepts to absorb and less errors to be made, as the file-system won't have any cycles. Symlinks are a premature optimization in my book, or worse, bad design. On the user level, shortcuts are often the better solution, because they allow arguments to be passed in on the command-line. This story is really about the arrogance that is as abundant as it is inappropriate in linux world. Never have I heard of dependency hell or broken systems on Android, yet geriatric linux always needs the help of an administrator. The only place where linux still has some merit is on the server, where its classical but aging mainframe concepts still have some life left in them.
  - wdb 4y ago
    I don't agree that symlinks are a basic feature. It's a source of a lot of pain for me on my Mac
charcircuit 4y ago
>I'm still blown away that they literally made the .NET team revert the dotnet watch PR at the last minute, so that they could sell it as a feature. This is not even true. Due to limited resources they wanted to cut scope of what the .NET 6 update included and they thought that it would be okay to delay the dotnet watch feature because most people would still have hot reloading from using Visual Studio. The PR for bringing back the hot reload code was merged 3 days after the PR for removing it. https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/ https://devblogs.microsoft.com/dotnet/net-hot-reload-support...
- ripley12 4y ago
  > This is not even true. It is absolutely true. The CLI-first `dotnet watch` was pretty much done (I was using it in preview for months beforehand), and it was cut to promote hot reload as a Visual Studio feature. Source: I'm the person who raised the initial GitHub issue about the dotnet watch change, and I talked to multiple Developer Division employees off the record. It was a deeply unpopular move that came from the top (Julia Liuson).
  - charcircuit 4y ago
    So it's the public word of someone from the .NET team versus your unnamed sources. It sounds like there was a communication issue as from the blog post the reason given behind removing it wasn't to drive sales of Visual Studio. It sounds like if their team had more resources it wouldn't have been cut which invalidates the point of them using it to promote VS.
    - ripley12 4y ago
      That post by Scott Hunter was a way to save face after Liuson backed down. It is absolutely not truthful about the original reason for removing dotnet watch, and was widely criticized as such at the time. Please trust me on this; the whole dotnet watch drama consumed my life for a good week when it happened. If you want a source from the .NET team, Miguel de Icaza has since quit Microsoft and is able to be more open about what's going on: https://twitter.com/migueldeicaza/status/1537178691218046976 https://twitter.com/migueldeicaza/status/1537178691218046976 Even during the dotnet watch drama, he was willing to endorse a very critical take at odds with the public line: https://twitter.com/migueldeicaza/status/1451902388290392073 https://twitter.com/migueldeicaza/status/1451902388290392073
jmpeax 4y ago
Microsoft's own machine learning repo "Project azua" (https://github.com/microsoft/project-azua https://github.com/microsoft/project-azua) runs on JAX. Let that sink in.
- VWWHFSfQ 4y ago
  At this point Windows as a primary development platform is essentially dead. With a few exceptions (DX) nearly everyone writes code for Unix/Linux and then cross-compiles for Windows. Windows is the afterthought. Let that sink in...
  - ntoskrnl 4y ago
    That is true in some corners of the industry, but definitely not others.
  - Genbox 4y ago
    > nearly everyone writes code for Unix/Linux and then cross-compiles for Windows That's a very bold statement that I suspect is far from true.
  - delta_p_delta_x 4y ago
    > With a few exceptions (DX) 'Let me just exclude an entire multi-billion-dollar industry to cherry-pick examples to make my point sound stronger.' Yeah, no; Windows isn't going away.
dgfitz 4y ago
I’m surprised Qt hasn’t been mentioned yet for c/c++. You can get qtcreator and mingw baked in for the cost of a couple GB, and it “just works” even if you aren’t using the qt framework. I much prefer qtcreator to visual studio anyways. I suppose this breaks down for the use cases that aren’t c/c++ though.
- jcelerier 4y ago
  Sadly Qt ships MinGW 8.1 which is positively ancient (released in 2018). If you're starting a new project (which you likely are if you are installing an IDE aha) there's no reason not to go for more recent compilers - msys2 has GCC12 (https://packages.msys2.org/package/mingw-w64-x86_64-gcc https://packages.msys2.org/package/mingw-w64-x86_64-gcc) and Clang 14 (https://packages.msys2.org/package/mingw-w64-x86_64-clang https://packages.msys2.org/package/mingw-w64-x86_64-clang) which just work better overall, have much more complete C++20 support, have less bugs, better compile times (especially clang with the various PCH options that appeared in the last few versions), better static analysis, etc. Personally I use https://github.com/mstorsjo/llvm-mingw's https://github.com/mstorsjo/llvm-mingw's releases directly which does not require MSYS but that's because I recompile all my libraries with specific options - if the MSYS libs as they are built are good for you there's no reason not to use them.
xvilka 4y ago
And slash. They got it backwards.
- jeroenhd 4y ago
  / is used both in writing and in Maths. \ is a character used almost exclusively in programming. From a practical point of view, I find \ to be a much more suitable directory separator than /, for the same reason I think Microsoft's choice for blacklisting characters like ? and : from file names is silly. There are real world use cases [1] for adding the / to file names so it shouldn't be excluded! Microsoft has used the / for command switches since its inception, based on the way the DECS TOPS-10 (1970) used linker flags; with / already taken, they chose the Next Best Thing which is perfectly fine. When Unix came around a year after the TOPS-10 they used a forward slash for directories for some reason but there's no way one is better than the other. For what it's worth, Windows accepts forward slashes. Since Windows 1.0, actually, all the way back in 1985. Try it for yourself in your browser[2], open notepad.exe and save a file in A:/test.txt. Your path separator may be represented differently, but / works perfectly fine. Fun fact: in some locales (Japanese, for example) your path separator isn't even a backslash; the path separator is actually rendered as 0x5c, which corresponds to the Yen symbol in Japanese locales of Windows. In Korean locales, it'll show up as the Won symbol and you'll probably find many other path separator characters in other locales that existed way back in the console code page days. [1]: https://answers.microsoft.com/en-us/windows/forum/all/forward-slash-in-printer-driver-name-and-sharing/239712a4-db33-4d2d-ab9c-692d6714b50e https://answers.microsoft.com/en-us/windows/forum/all/forwar... [2]: https://www.pcjs.org/software/pcx86/sys/windows/1.01/ https://www.pcjs.org/software/pcx86/sys/windows/1.01/
  - dfawcus 4y ago
    Which is because not only Windows, but DOS itself supported it at least as far back as DOS 2.0 when they added sub-directory support. There was even an option (in CONFIG.SYS) to alter the 'switch character', which then also caused a lot of command line tools to accept '/' for paths. That option was eventually removed from the config file, but the underlying API retained until quite late. Maybe it was WinME's version of DOS which disabled the API. Despite all of that, the handle based Int 21 file APIs always supported being passed '/' as a path separator, and it was often accepted by some apps. DOS based 'C' source code often used "#include <some\\path\\file.h>", however many compilers also simply accepted "#include <some/path/file.h>", probably just as an artifact of the obvious implementation. This wasn't well known, so lots of DOS based 'C' source used '\\' in includes, plus also at the file API level.
bumblebritches5 4y ago
kazinator 4y ago
I use Cygnal for making a Windows version of TXR. https://www.kylheku.com/cygnal/ https://www.kylheku.com/cygnal/ You compile in the Cygwin environment where you have all the usual tools. Then shipping the program with cygwin1.dll from the Cygnal project gives it native-like behaviors.
kretaceous 4y ago
I mostly agree on the VSCode part. They should put it up front in the README, homepage and maybe a info modal/badge whenever a user installs said extension. But genuinely asking, how else would you 'label' VSCode? "A free and open-source code editor with some optional components that are proprietary"?
- SCLeo 4y ago
  Same as Google Chrome. No one claims Google Chrome is open source nowadays.
- behnamoh 4y ago
  Apple is worse in that regard. Is XCode open-source? Other than Darwin Kernel, is any part of macOS open-source? Did Apple even try to make Swift cross-platform? Is iCloud really comparable to OneDrive? How about Apple's locked and closed-source bootloaders?
  - jeroenhd 4y ago
    Swift itself works on most platforms. The problem with using Swift cross platform is that Apple only bothered to make their GUI toolkit available for their platform in the same way Microsoft only makes their dotnet GUI platforms available for Windows (without resorting to "official" replacements that are owned by the same company but not built into the system, like Xamarin). As a consequence, many Swift libraries only focus on macOS, just like many dotnet libraries focus on Windows (though recent efforts have improved that situation). You can probably get a lot of them working on Linux as well and if you use Swift for command line tools or web applications. I suppose you can probably run the most important tools cross platform, but the non-native ecosystem is clearly a second class citizen. The big difference between XCode and VSCode is that Apple doesn't claim XCode is open source; also, XCode is more comparable to Visual Studio than VSCode in terms of SDK integration and preconfigured tooling. Huge parts of the Darwin kernel are actually publicly accessible while Microsoft only provides kernel sources under NDA in things like education projects. Unless you count the WinXP source code leak, that is. C# is sort-of mostly open source-ish except that debugger features are closed and the community has little say in its development. Apple did in fact put effort into making Swift cross platform, as outlined here[1]; though their intention is that Swift programs use the system runtime on macOS/iOS/iPadOS, they put the effort into making a base layer freely available for other operating systems to gain some portability. I'd personally argue that Apple and Microsoft are similarly if not equally open in their development, but Microsoft advertises itself much more "open source" than Apple. Apple's approach of "you can look but you can't touch" is a lot more explicit and their supposed openness comes up in fewer marketing materials. [1]: https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation
cpeterso 4y ago
Mozilla’s automated builds of Firefox for Windows, macOS, Linux, and Android are all cross-compiled on Linux VMs. Cross-compiling is faster and cheaper, especially because Windows’ file I/O and process launching is so slow.
- behnamoh 4y ago
  > Windows’ file I/O and process launching is so slow. It's not Windows' fault, rather it's NTFS.
  - pxc 4y ago
    There's some documentation on this in some WSL issues on GitHub, but it's not just NTFS. It's stuff like the broader filesystem architecture's inclusion of pluggable 'filters' (kinda neat, but each layer of them incurs a performance cost) or the way commands on other operating systems depend on caches for certain syscalls that Windows doesn't keep, or keep anything equivalent to. Too tired to go find them atm
    - espenwa 4y ago
      This one? I remember it as an earnest description of the difficulties the WSL team had with the speed of NTFS - and I think it was one of the reasons for the switch to virtualisation in WSL2. <https://github.com/Microsoft/WSL/issues/873#issuecomment-425272829 https://github.com/Microsoft/WSL/issues/873#issuecomment-425...>
      - pxc 4y ago
        Yeah, that's the GitHub comment, thank you! My takeaway from that comment is that there are some important performances issues that apply generally to all filesystems on Windows. Maybe we can partially test whether that's the case by playing with WSL1 on ReFS, ExFAT (if that's even supported, with its limited permissions support, or ZFS, once OpenZFS on Windows stabilizes a bit.
  - rurban 4y ago
manigandham 4y ago
The comments here showcase why webapps and Electron/webview shells are so common now. Maybe WebAssembly and its up and coming runtimes can finally some of this mess.
- xyzzy_plugh 4y ago
  I disagree. Cross-compiling has nothing to do with why Electron is common. The browser is the runtime that currently fixes this mess. WebAssembly would need a runtime matching current browser runtimes to be a real contender, and the best choice here is... a browser. So now you have electron but it's WebAssembly, which isn't significant enough to make a dent in this mess.
codedokode 4y ago
The post mentions CRLF line end syntax, I don't understand why anyone should bother with it. Use \n only, it works everywhere including Windows. Any modern IDE can handle Unix line endings. The same about file paths, use forward slash (/) everywhere and don't waste your time supporting DOS era standards. I think the core.autocrlf option in Git is more harmful than useful (for example, it can change file hashes and break something) and should be removed. An option to warn about unwanted \r characters on commit might be useful though.
- deleted 4y ago
  [deleted]
- Shorel 4y ago
  > I think the core.autocrlf option in Git is more harmful than useful Nowadays, I am willing to agree with you. It breaks more things than fixes them.
- moogly 4y ago
  Agreed. autocrlf = input Then change your editors and IDEs to save files with LF line endings (preferably with something like .editorconfig) and you'll have fewer problems.
fritigern 4y ago
Windows is a legacy operating system, not something from 2022. I don't see any good reason to use it.
revskill 4y ago
Seriously, i use Windows because i could play video games after coding. Coding in linux machine is 10000x easier than Windows.
- alerighi 4y ago
  Depends on what you use. To me Visual Sudio is the best and most gestire complete IDE on the market and C# one of the best language. Every time I program on another system I miss Visual Studio.
- forgotpwd16 4y ago
  >i could play video games Have you tried gaming in Proton?
- vips7L 4y ago
  The only time I have trouble in Windows is when people coding on a Linux machine don’t use cross platform tools.
lovelearning 4y ago
I presume most MS managers were in engineering roles earlier. It doesn't make sense to characterize the same kind individuals as crushing merely after a role change. My hunch is they always had the instinct to crush but didn't have the power earlier.
prvc 4y ago
Would falsely representing software intended to be proprietary as "open source" in its marketing copy have an adverse impact on the enforceability of its putative license?
flohofwoe 4y ago
Good post (I couldn't quite follow the open source angle tbh), but for the "why doesn't Developer Mode make Windows behave more like Linux" part: this would probably disgruntle a lot of 'native' Windows developers. Windows was always its separate island, and at least in the past it had a lot of developer mindshare (so more like a whole continent than an island), and from the point of view of those Windows devs, Linux is the odd one out ;) One common solution is to use scripting languages for build automation that try to hide most of the differences (e.g. Python or Node.js instead of Powershell vs Batch vs Bash), and most importantly there's simply no way around testing on at least Windows, macOS and Linux.
tigerlily 4y ago
I used to use MXE [1] to compile fully static Windows binaries on Linux VMs hosted with Travis. It needed to crane in everything though, so it was a source of bottlenecks from time to time. I was also uncertain about the provenance of a lot of the dependencies in that toolchain. So when Travis died I took the opportunity to move Windows builds back to gnu with msys2, all over GH Actions. These are actually comparatively snappy and I’m reasonably satisfied with it. [1] https://mxe.cc/ https://mxe.cc/
deleted 4y ago
[deleted]
ncmncm 4y ago
Life is too short to spend on fooling with Windows.

454 points by emidoots 4y ago

Are symlinks on Windows really such a big issue? I’ve never heard of projects using symlinks in their tree. If Windows developers are complaining about you doing something unusual, why is it their fault?

slimsag 4y ago
Certainly better to avoid it if at all possible, and I'll be eliminating them specifically to improve Windows compatibility. It's not that unusual, though, a quick search turns up 1.1k GitHub repositories with `git config core.symlinks true` in their documentation or CI pipelines - including quite popular projects like Ava, Apache Arrow, Solana, Chrome Devtools, adobe-fonts, IBM/houdinID, travis-ci, RabbitMQ, various Google projects & more.
- colejohnson66 4y ago
  I agree that Windows could do more to support the developers on other platforms. Symlinks just seem like a petty thing to complain about IMHO. Didn’t realize how common they were though. NTFS does support them, however. Is Git just not supporting them properly?
  - fortran77 4y ago
    That's exactly it. Windows developers know NTFS has Symbolic Links https://docs.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links?redirectedfrom=MSDN https://docs.microsoft.com/en-us/windows/win32/fileio/creati...
    - bilekas 4y ago
      Maybe I missed something on this discussion but symlinks and NTFS are not really related.. They have them yes, how they're handled is different.
      - fragmede 4y ago
        How are they not related? If NTFS didn't have symlinks we wouldn't be having this discussion. Critically, the modern standard for removable drives, exFAT does not support symlinks, so you can't count on Windows' support for symlinks if the user is git cloning on a drive that's using exFAT.
        pjmlp 4y ago
        https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
        forgotpwd16 4y ago
        Pointing to this page is meaningless. `mklink /d` only works on NTFS but errors out ("The device does not support symbolic links.") on exFAT. GP acknowledges NTFS has symlinks and remarks that exFAT doesn't.
        pjmlp 4y ago
        NTFS is the only filesystem that matters for Windows developers.
    - CoastalCoder 4y ago
      What's the standard for being an "actual Windows user"? Asking because I doubt e.g. my mom knows that NTFS has symlinks.
      - pjmlp 4y ago
        Is she a Windows developer? https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
        slimsag 4y ago
        The developers who complained to me about this are Windows developers regularly. One is even a professional AAA DirectX gamedev.
        pjmlp 4y ago
        Apparently not professional enough to know a feature as old as Windows 2000.
      - Dylan16807 4y ago
        > What's the standard for being an "actual Windows user"? I think you misread that line.
        slimsag 4y ago
        Their message originally read "Actual Windows developers know NTFS has Symbolic Links"
        Dylan16807 4y ago
        So it did say "developers" and not "users"? I think they misread the line. (Whether it was right or not, so you don't need to tell me anything about that.)
  - slimsag 4y ago
    Well, it feels 'petty' and simple until: 1. You run into it, go "AH, wow, okay, I'll enable Developer Mode" 2. It still doesn't work, you're confused, you Google around a bit more and find out actually you also need to use a Git config option 3. You retry, now the symlinks work, but your compiler fails because "Destination Path Too Long", huh, that's weird 4. You google a bit more, and discover you need to set a registry option. So you do it, but you still get that error.. 5. You discover there's another Git option you need to set And then you're like, hey, what was I doing again? Where did the last hour of my time go? It's death by a thousand paper cuts.
    - deleted 4y ago
      [deleted]
    - giantrobot 4y ago
      Yak shaving.
  - pjmlp 4y ago
    It does support them, mklink. https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
    - colejohnson66 4y ago
      Yes, Windows does, but this post is complaining about support. Which led me to ask if Git is the problem. Cause Git also supports symlinks, but is clearly having issues on Windows.
      - bogwog 4y ago
        I would assume the issue is that they need to disable symlink support by default on Windows because symlink support is disabled by default on Windows.
  - Pathogen-David 4y ago
    NTFS has supported them for ages. The main issue is that they're locked behind elevated permissions or having developer mode enabled (as of Windows 10.) My understanding is Microsoft's concern is that applications and OS components not expecting them could lead to security issues. Not sure how real that concern is, but that's the excuse I've heard.
    - nemothekid 4y ago
      >Not sure how real that concern is, but that's the excuse I've heard. Bufferoverun I guess? I haven't programmed Windows in years, but there's plenty of code I've seen that is pretty much char path[MAX_PATH]; res = some_func(&path); from there you put in a large path and then you get your RCE.
      - MereInterest 4y ago
        That would be for removing the 260 character limit, not for enabling of symlinks.
    - MereInterest 4y ago
      I've looked before, and have never found a definitive answer from Microsoft. I've heard some speculation that it the nebulous security issues would be from a program that checks the permissions of a symlink's target, then opens the symlink. An attacker could then modify the symlink after the permission check but before the file is opened, escalating access by pointing to a restricted file.
      - pxc 4y ago
        It's a kind of attack called a symlink race, which is also possible on other operating systems. There are kernel parameters for hardening against symlink races on Linux, and they just disable symlinking into world-writable locations. I'm not sure why Windows can't use a less invasive mitigation like that, but I guess there must be one.
        4y ago
- deleted 4y ago
  [deleted]
gizmo686 4y ago
The higher level thing to notice is that Windows is a second class platform for much of the software world. As such, it is in a position where it needs to bend the knee for compatibility with the dominant platform if they want it to be an active player in the larger ecosystem. In the case of symlinks, the hard part is already done, to the point where it is a toggle that has already been implemented, the UX of enabling it is just bad.
- pjmlp 4y ago
  For game developers and GUI applications it is first class. Apparently being the best in symlinks hasn't made a difference in the Year of Desktop Linux.
- jeroenhd 4y ago
  Both soft links and hard links, as well as directory junctions, have been possible in Windows since Windows XP (though soft links have only been available since the release of Windows Vista 18 years ago). In fact, hard links are essential parts of Microsoft's solution to the DLL hell problem without wasting gigabytes of space. The problem people are running into is that the OS hasn't been designed with wild symlinks in mind and therefore can't guarantee its security principles if any user is able to symlink however they please; if I read the context [1] correctly, it seems like an elevation of privilege is suspected to be very easy to gain if a standard-level user is allowed to place arbitrary soft links on a file system. I see little reason for Microsoft to enable the "all users can soft link" setting by default. They'd need to audit their OS and userland code to determine where soft links may introduce vulnerabilities in order to change the default and a few developers that absolutely insist on using soft links inside git repos for some obscure reason isn't going to get them to make such an effort. Microsoft has made enabling the feature a bit easy [2] but I can find very little about the security analysis done for this change, so enabling dev mode might open your computer up to a whole class of vulnerabilities. I personally don't see a reason to use symlinks in a dev environment, but I suppose *nix developers think otherwise, probably to duplicate files across a source repository for some reason? If your intent is to work together cross platform then there are loads of restrictions you need to deal with. Linux applications tend to trip up over CRLF, every file system has their own stupid restrictions, build tools and shell scripts need to somehow become platform agnostic, you name it. You can blame Windows for being different but the truth is that Windows is still the most commonly used desktop operating system in the world by a huge margin. macOS and Linux are the odd ones out and there is no good reason why the POSIX/X11 system design is better or worse than Cacoa or Win32; it's a mere difference of convention. [1]: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links https://docs.microsoft.com/en-us/windows/security/threat-pro... [2]: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/ https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
binarycrusader 4y ago
You don't have to enable Developer Mode to enable symlink creation. Administrators have the right to by default and non-administrator users can get this by enabling the documented policy: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links https://docs.microsoft.com/en-us/windows/security/threat-pro... Developer Mode is just a bundle of useful developer-related settings and components that get applied to the device when enabled. There's a post here about this from the Developer Mode angle with a bit more background: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/ https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
nicoburns 4y ago
Projects don’t use symlinks because they aren’t supported on windows.
- pjmlp 4y ago
  https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
  - Dylan16807 4y ago
    The command won't help when you don't have the permissions. Or do you just want it to be phrased "not supported for users on normally configured systems"? There, then.
    - pjmlp 4y ago
      Well, time to learn about /J flag.
      - Dylan16807 4y ago
        Even if we pretend that's a symlink, it only works for directories, not files.
        pjmlp 4y ago
        We moved from Windows doesn't do it, it does but isn't available to non admins, it is but non admins can't do files,.... Yep.
        Dylan16807 4y ago
        We started at "not supported", talking about making symlinks inside projects. We backed off to "not supported on normal systems", which is a reasonable change to me. You mentioning junctions is not even close to a solution, and I am not moving the goalposts. If junctions worked, the complaint wouldn't have been needed from the start. No, this is about actual symlinks, not a similar feature that can do 5% of what symlinks can do.
pjmlp 4y ago
Nope, since XP that you can use mklink, and before there were Technet utilities for the same purpose. However using symlinks just isn't a thing in the Windows culture, people use at most Shell shortcuts.
orwin 4y ago
No, they're not really. And IIS is not that bad either. My main gripe with windows and why i won't develop on it anymore is simple that their system is too complex. I suppose this is the gripe of the article author as well tbh. Windows is horribly hard to learn. In a day, i learned how to create file, directories, change the stats on those, execute diff and patch, an do weird string modifications with grep and cut (and learn to commit and push with git). First day on an UNIX machine. First work week on a windows machine (at that time, i had already built a LFS): we have those two project with two different version of (proprietary JS front framework) and (weird php framework). Those don't use the same version of mycrypt.dll (and others, but this one i will remember for at least two dozen year). With the support of non-intern engineers including a windows DBA, it took us a week to manage to install the two different versions. A week prior, i was linking to a previous version of Ruby for my RoR app (it was around 2013). But since, i really respect windows sysadmin, they are the best of us. I will just never, ever want to work on a windows server again. I like learning, but putting that much effort for this little rewards? not worth.

jrm4 4y ago

Microsoft's days as a 'primary' desktop operating system are numbered. The OP doesn't seem to understand this, but even Microsoft itself does, which is why most of its major moves the past few years haven't been improving its own desktop, but positioning itself to control "open source" the best it can. More people within the MS ecosystem should understand this.

deleted 4y ago
[deleted]
munchler 4y ago
One can argue that desktops are no longer the primary computing environment, but I don't think there's any evidence that Windows is about to displaced within the desktop world. What are you proposing will become the primary desktop OS? Some Linux flavor of the month? MacOS? Neither seems at all likely in the foreseeable future.
- jrm4 4y ago
  There won't be a "primary" and people will perhaps not pay much attention to which it is, any more than they pay attention to e.g. what Javascript framework their favorite site is using. I've come to realize while there may never be a "year of the Linux Desktop," there will likely be "years of Linux Desktops" -e.g. Ubuntu, but then also SteamOS, ChomeOS, maybe Android if you're being REALLY inclusive, etc.
pjmlp 4y ago
Better check those desktop market share numbers.
- blibble 4y ago
  I suspect if you restrict it to developers the numbers would look very, very different on the stackoverflow survey windows is 41.2%: https://insights.stackoverflow.com/survey/2021#most-popular-technologies-op-sys-prof https://insights.stackoverflow.com/survey/2021#most-popular-...

Animats 4y ago

It is. I generate the Windows executables for a program by cross-compiling Rust on Linux. Then test with Wine. The Rust crates are cross-platform enough that I don't have to special case platforms. This is easier than having a Windows machine. The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files. If you dump the legacy OS stuff, it gets easier.

ratww 4y ago
Doesn't cargo-bundle do that? I haven't tried to use it to generate .msi files, only for iOS/macOS, but it has the feature!
- Animats 4y ago
  Cargo-bundle was supposed to do that, but only the Mac part was completed. Nobody ever did the .msi output. I've been trying to get someone interested in doing that. That task needs someone very familiar with the Microsoft ecosystem, which I am not. Discussion in Rust tools forum here.[1] [1] https://internals.rust-lang.org/t/cross-platform-bundling/16773 https://internals.rust-lang.org/t/cross-platform-bundling/16...
  - deleted 4y ago
    [deleted]
  - giancarlostoro 4y ago
    I wonder if InnoSetup could be a good point of reference for anyone interested. It is in Delphi though, but there is also this guide I found whilst trying to figure out if you could run Inno Setup on Linux: https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd797 https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd7... Inno Setup was the best and easiest thing for me to ever use but when I was building Windows installers for use from a Windows OS. Update: Found this Cargo package rust-msi: https://github.com/mdsteele/rust-msi https://github.com/mdsteele/rust-msi
    - 4y ago

ntauthority 4y ago

Counterpoint for this rant (showing it's again not very objective, and just what your or your environment's expectations are): it's easier to cross-compile binaries for Linux (using Clang and a sysroot on Windows) than it is to natively compile on Linux (not using a sysroot, as that is the 'default' flow there) if your environment is mostly Windows already. We do this for one of our products, in fact. The post meanwhile seems to be part about open source policy (nasty, but not a technical issue - also including a new-to-me and hard to find on a Google or DDG search fact about the VS gallery endpoints having led to legal threats), part issues induced by 'weird' modern languages not caring to support Windows (as expected?), part Git for Windows not bothering to handle symbolic links cleanly (and the weird admin-only default thing that remained from Vista), and part... concerns where if people would spread the proper way of doing stuff (curl.exe bundled by default for downloads, or long file names being 'weird' - albeit less broken than claimed here) instead of just ranting this'd be fine too... but not really a coherent whole.

thrdbndndn 4y ago
My counterpoint is simpler: I use some of these tools (like VS Code) because they're better, not because they're open source. Also I don't think Pylance or whatever core extensions being closed source contradicts with the fact majority of VS Code (or vscodium) is open-source. And I don't see anything morally wrong that they want to close source some of their competitive products.
- SergeAx 4y ago
  It may be not intuitive, but tools tend to be better because they are open source. My personal problem with Pylance or ssh tools is that they are not working with VS Code based forks. That means that VS Code is not that open source as it trying to look like. And this is suspicious for me.
  - anonymoushn 4y ago
    The ssh tool is incredibly slow and resource intensive and defaults to losing unsaved work on disconnect. An open source version would open up the possibility of a user fixing some of these issues.

labrador 4y ago

This what is called in Cognitive Behavioral Therapy "All or Nothing Thinking." Microsoft is a for-profit company. It is pro open-source when it helps them and closed source also when it helps them. I like the new Microsoft which has open sourced a lot of stuff. It's way better than the old closed source regime.

unnouinceput 4y ago
Oh, you and the article's author are either forgiven or seeing the best in people. Me, on the other hand, who lived the Microsoft with their shady dealings in Bill's / Ballmer's era, I remember their crushing on OEM's to not allow even a shred of openness in their systems. Only because of shifting in developer's in favor of Apple's / Google's Microsoft changed the tune with "Microsoft loves Linux". Bleah! I have no love for Microsoft despite my work involving their products 90% of my time. I am just realistic, they just love money, nothing else. And if money means open source, guess what?! They bought GitHub and they own everything that is published there. That's why plenty left GitHub and either started their own venture or went to GitLab. Sorry for my rant, I had to get it off my chest.
- labrador 4y ago
  Gates and Balmer are long gone and it's no longer the same company. If they only loved money, they wouldn't be amenable to their workers unionizing. "CWA, Microsoft Announce Labor Neutrality Agreement" https://cwa-union.org/news/releases/cwa-microsoft-announce-labor-neutrality-agreement https://cwa-union.org/news/releases/cwa-microsoft-announce-l... Sorry to be this way, but I'm refreshing my memory about CBT today: Over-generalization: Make a comprehensive, negative conclusion that is beyond the current situation. Labeling and Mis-labeling: The extreme form of overgeneralization. Use fixed, comprehensive, and emotional language to label yourself or others. Disqualifying the Positive: Unreasonably believe that positive experiences, behaviors or qualities do not count. Jumping to Conclusions: Making a conclusion before having all the evidence. Emotional Reasoning: Draw conclusions from your own feelings, because what I think is what the facts are.
  - 4y ago

e4m2 4y ago

> Are derived community works, like say the D-language, Dart, or Zig bindings to the win32 API which are generated from those files open source - if Microsoft did not release them as such? Certainly. The source for these bindings is the WinMD file, which is MIT licensed. While it is true that its contents are generated wholly from non-FOSS sources, it doesn't impact end users of the metadata. Microsoft owns the original IDL/headers and can choose to license any related work however they like.

deleted 4y ago
[deleted]
kibibu 4y ago
If you read further down the issue comments, it's explained that the generated files don't contain all the info in the idl files.
mhh__ 4y ago
Although it's a point of pride that someone did manage to get D understanding the recent Win32 API specification extremely quickly (D is ridiculously good at this kind of metaprogramming), the bindings that actually ship with D at the moment are hand-maintained.

nshm 4y ago

For me SDK sizes are showstopper. Mingw packages are probably 100-200 Mb total. To build anything native one has to install Windows (20+Gb in modern version and then Visual Studio 40+Gb). Not so easy to fit it all on an SSD drive. Xcode also have this problem now. 8Gb for Xcode 7 is manageable. But why 70Gb for Xcode 11?

recursive 4y ago
There are very few things that actually require Visual Studio just to build.
- steeleduncan 4y ago
  Interesting, how can I install just the cmake + msvc to do command line builds with windows? I'm also installing wsl2 + mingw because it is so much lighter for compilation than many, many gigabytes of vis studio.
  - aaron-stackbit 4y ago
    `msbuild` is what I used back in the day. It seems to still exist, but I have no idea if this is still preferred solution. I just use WSL 2 these days, and live with the extra io latency.
  - e4m2 4y ago
    Download the build tools[0] and choose the appropriate options. I'd personally consider the following a good baseline: MSVC v143, CMake tools, Windows 11 SDK, Clang tools (if you don't want/need these you can shave off 3.5 GB). `zig cc` is another interesting alternative, it's just a single ~62 MB download. [0] https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022 https://visualstudio.microsoft.com/downloads/#build-tools-fo...
    - steeleduncan 4y ago
      Thanks, I'll give that a try!

pjmlp 4y ago

Typical UNIX FOSS rant, not taking into account all the development workflows on Windows.

shadowofneptune 4y ago
It doesn't, no. If you are only working with libraries designed for Windows or are linking against binaries, most of the dev issues listed disappear. The point of the article is that the Windows push for open source introduces friction because the way of doing things with established OSS projects is so different.
- pjmlp 4y ago
  Not every OS has to be a UNIX clone, we don't need an OS monoculture.
  - franga2000 4y ago
    You don't need to implement POSIX in order to not bundle your header files in a 9 GB "SDK" download, which isn't available as a direct URL download and can't be installed without user interaction via the GUI. This is a Microsoft issue, not a Windows issue.
    - jeroenhd 4y ago
      If MS would package just the header files, they'd probably get tons of complaints about compilers complaining about missing libraries, missing dependencies and toolsets not being available. The Windows SDK is not just a few C++ headers and a bunch of lib files to link against. It has a huge surface area. The documentation and toolsets assumes all API calls from Windows 3.1 APIs to UWP to be available. The SDK download (ISO format) is 1.1GB in size, requiring a total of 4GB of disk size to install (whether this includes the size of the installer itself is unclear). Big, but not unavoidably so, and you can pick and choose some features. It bundles debugging tools, the application identifier, a certification kit and MSI generation tools along with its headers (which seems fair to me); less than 1GB of extra kit on top of 1.8GB of headers and libraries you probably want as a Windows dev anyway. Just the headers won't leave you with a working dev environment even if you bring your own debugger. Unlike what some developers seem to think, you don't actually need to download Visual Studio to get the SDK, you can also download it separately from the website [1]. Pick the ISO version and extract the CAB files yourself if you want to manually pick and choose your files. The SDK ships as an installer but that just makes sense. Ubuntu ships their headers in DEB files as well, for example. You want to be able to add and remove these packages as you upgrade or downgrade your target API levels without having to manually set up a file system hierarchy. As for non-GUI interaction: `WinSDKSetup.exe /quiet /ceip off /features DesktopCPPx64` will install only the necessary headers and libraries for x64 C(++) development in the default location without sharing data with Microsoft. Found this command line with `wine WinSDKSetup.exe /?`. You can also add, repair, and uninstall packages with the same installer. [1]: https://developer.microsoft.com/en-us/windows/downloads/sdk-archive/ https://developer.microsoft.com/en-us/windows/downloads/sdk-...

Dylan16807 4y ago

Configure autocrlf in what way? I don't want git to change my files, and I don't know what problems they're talking about.

slimsag 4y ago
Configure it to respect your preference ('don't change my files') and not pester you with hundreds of warnings any time you interact with Git if your preference differs: warning: LF will be replaced by CRLF in src/au/policy/dao/EmailQueue.java
thayne 4y ago
If you have some developers using window, and other developers using anything else, without some kind of line ending normalization, then you will end up with inconsistent line endings, possibly in the same file, and potentially diffs and commits where every line in a file is changed from one line ending to another.

forrestthewoods 4y ago

It’s funny because I find compiling and deploying for Windows far, far, far easier than Linux. That said, the complaints are all good and fair.

dataflow 4y ago

Now try building a "portable" binary that runs on a version of Linux older than yours.

rocqua 4y ago
Isn't that simply a matter of targeting an older glibc? I am probably missing something though.
- dataflow 4y ago
  Yes, "simply". It's a very fun process. Around 100 times more fun than the onerous git config --global core.symlinks true
  - andrewmcwatters 4y ago
    Anyone who talks nonchalantly about glibc hasn't had their time eaten up by glibc.
    - Spivak 4y ago
      Like it’s absolutely a nightmare but you can eliminate a lot of problems by building on an ancient version of RHEL.
      - jeroenhd 4y ago
        It says a lot about Linux development that for cases like these "just install the Linux equivalent of Windows XP in a container and run the tools inside that" is an accepted solution. It's a solution that works well and is used by loads of developers, but it's still comically silly.
        account42 4y ago
        There are other approaches like https://github.com/wheybags/glibc_version_header https://github.com/wheybags/glibc_version_header or sysroots with older glibc, e.g. https://wiki.gentoo.org/wiki/Crossdev https://wiki.gentoo.org/wiki/Crossdev - you don't need your whole XP, just the the system libs to link against. Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.

userbinator 4y ago

Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes <250MB of disk space, and the self-contained binaries it generates will work on any version of Windows starting at Win95. Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~255 character limit. Personally, I think 260 is long enough and plenty to work with, while at the same time discouraging the ridiculous verboseness that seems to have crept into "modern" software. Then again, I stay away from .NET, VSCode, and the like. I am reminded of this post by Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20070301-00/?p=27803 https://devblogs.microsoft.com/oldnewthing/20070301-00/?p=27...

akelly 4y ago
It's incredibly fitting that all the links on that post are 403 Forbidden
- userbinator 4y ago
  That's Microsoft being (the new, not the old) Microsoft... they seriously fucked up the MSDN documentation when it was migrated to docs.microsoft.com, so I'm not surprised that a similar thing happened to the blogs: https://news.ycombinator.com/item?id=20351358 https://news.ycombinator.com/item?id=20351358
  - naikrovek 4y ago
    they knew they would and they advertised that fact, and made blog and content owners migrate their stuff if they wanted it kept. many chose not to. those are the people you should be angry with.
    - denimnerd42 4y ago
      that's quite a take.. expecting previous article writers to manually migrate their stuff is just as good as killing it.

wdb 4y ago

I agree that symlinks cause more trouble then is needed on any platform. Sadly, only Node really likes to use them to optimise the store of packages Personally, I don't have major issues compiling things on Windows for other platforms (macOs, Win32, Android, Linux). Only awkward thing is designing UIs

fyrn- 4y ago
I don't think that's what they sre saying, I think they sre saying it's stupid Microsoft requires hoops for such a basic feature, hence "Fix Windows" being option 1
- childintime 4y ago
  Such a basic feature? If the OS dedups a file, by putting in a symlink behind the scenes, no one need know a symlink (or something else) exist. That makes for a better user experience. There are less concepts to absorb and less errors to be made, as the file-system won't have any cycles. Symlinks are a premature optimization in my book, or worse, bad design. On the user level, shortcuts are often the better solution, because they allow arguments to be passed in on the command-line. This story is really about the arrogance that is as abundant as it is inappropriate in linux world. Never have I heard of dependency hell or broken systems on Android, yet geriatric linux always needs the help of an administrator. The only place where linux still has some merit is on the server, where its classical but aging mainframe concepts still have some life left in them.
- wdb 4y ago
  I don't agree that symlinks are a basic feature. It's a source of a lot of pain for me on my Mac

charcircuit 4y ago

>I'm still blown away that they literally made the .NET team revert the dotnet watch PR at the last minute, so that they could sell it as a feature. This is not even true. Due to limited resources they wanted to cut scope of what the .NET 6 update included and they thought that it would be okay to delay the dotnet watch feature because most people would still have hot reloading from using Visual Studio. The PR for bringing back the hot reload code was merged 3 days after the PR for removing it. https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/ https://devblogs.microsoft.com/dotnet/net-hot-reload-support...

ripley12 4y ago
> This is not even true. It is absolutely true. The CLI-first `dotnet watch` was pretty much done (I was using it in preview for months beforehand), and it was cut to promote hot reload as a Visual Studio feature. Source: I'm the person who raised the initial GitHub issue about the dotnet watch change, and I talked to multiple Developer Division employees off the record. It was a deeply unpopular move that came from the top (Julia Liuson).
- charcircuit 4y ago
  So it's the public word of someone from the .NET team versus your unnamed sources. It sounds like there was a communication issue as from the blog post the reason given behind removing it wasn't to drive sales of Visual Studio. It sounds like if their team had more resources it wouldn't have been cut which invalidates the point of them using it to promote VS.
  - ripley12 4y ago
    That post by Scott Hunter was a way to save face after Liuson backed down. It is absolutely not truthful about the original reason for removing dotnet watch, and was widely criticized as such at the time. Please trust me on this; the whole dotnet watch drama consumed my life for a good week when it happened. If you want a source from the .NET team, Miguel de Icaza has since quit Microsoft and is able to be more open about what's going on: https://twitter.com/migueldeicaza/status/1537178691218046976 https://twitter.com/migueldeicaza/status/1537178691218046976 Even during the dotnet watch drama, he was willing to endorse a very critical take at odds with the public line: https://twitter.com/migueldeicaza/status/1451902388290392073 https://twitter.com/migueldeicaza/status/1451902388290392073

jmpeax 4y ago

Microsoft's own machine learning repo "Project azua" (https://github.com/microsoft/project-azua https://github.com/microsoft/project-azua) runs on JAX. Let that sink in.

VWWHFSfQ 4y ago
At this point Windows as a primary development platform is essentially dead. With a few exceptions (DX) nearly everyone writes code for Unix/Linux and then cross-compiles for Windows. Windows is the afterthought. Let that sink in...
- ntoskrnl 4y ago
  That is true in some corners of the industry, but definitely not others.
- Genbox 4y ago
  > nearly everyone writes code for Unix/Linux and then cross-compiles for Windows That's a very bold statement that I suspect is far from true.
- delta_p_delta_x 4y ago
  > With a few exceptions (DX) 'Let me just exclude an entire multi-billion-dollar industry to cherry-pick examples to make my point sound stronger.' Yeah, no; Windows isn't going away.

dgfitz 4y ago

I’m surprised Qt hasn’t been mentioned yet for c/c++. You can get qtcreator and mingw baked in for the cost of a couple GB, and it “just works” even if you aren’t using the qt framework. I much prefer qtcreator to visual studio anyways. I suppose this breaks down for the use cases that aren’t c/c++ though.

jcelerier 4y ago
Sadly Qt ships MinGW 8.1 which is positively ancient (released in 2018). If you're starting a new project (which you likely are if you are installing an IDE aha) there's no reason not to go for more recent compilers - msys2 has GCC12 (https://packages.msys2.org/package/mingw-w64-x86_64-gcc https://packages.msys2.org/package/mingw-w64-x86_64-gcc) and Clang 14 (https://packages.msys2.org/package/mingw-w64-x86_64-clang https://packages.msys2.org/package/mingw-w64-x86_64-clang) which just work better overall, have much more complete C++20 support, have less bugs, better compile times (especially clang with the various PCH options that appeared in the last few versions), better static analysis, etc. Personally I use https://github.com/mstorsjo/llvm-mingw's https://github.com/mstorsjo/llvm-mingw's releases directly which does not require MSYS but that's because I recompile all my libraries with specific options - if the MSYS libs as they are built are good for you there's no reason not to use them.

xvilka 4y ago

And slash. They got it backwards.

jeroenhd 4y ago
/ is used both in writing and in Maths. \ is a character used almost exclusively in programming. From a practical point of view, I find \ to be a much more suitable directory separator than /, for the same reason I think Microsoft's choice for blacklisting characters like ? and : from file names is silly. There are real world use cases [1] for adding the / to file names so it shouldn't be excluded! Microsoft has used the / for command switches since its inception, based on the way the DECS TOPS-10 (1970) used linker flags; with / already taken, they chose the Next Best Thing which is perfectly fine. When Unix came around a year after the TOPS-10 they used a forward slash for directories for some reason but there's no way one is better than the other. For what it's worth, Windows accepts forward slashes. Since Windows 1.0, actually, all the way back in 1985. Try it for yourself in your browser[2], open notepad.exe and save a file in A:/test.txt. Your path separator may be represented differently, but / works perfectly fine. Fun fact: in some locales (Japanese, for example) your path separator isn't even a backslash; the path separator is actually rendered as 0x5c, which corresponds to the Yen symbol in Japanese locales of Windows. In Korean locales, it'll show up as the Won symbol and you'll probably find many other path separator characters in other locales that existed way back in the console code page days. [1]: https://answers.microsoft.com/en-us/windows/forum/all/forward-slash-in-printer-driver-name-and-sharing/239712a4-db33-4d2d-ab9c-692d6714b50e https://answers.microsoft.com/en-us/windows/forum/all/forwar... [2]: https://www.pcjs.org/software/pcx86/sys/windows/1.01/ https://www.pcjs.org/software/pcx86/sys/windows/1.01/
- dfawcus 4y ago
  Which is because not only Windows, but DOS itself supported it at least as far back as DOS 2.0 when they added sub-directory support. There was even an option (in CONFIG.SYS) to alter the 'switch character', which then also caused a lot of command line tools to accept '/' for paths. That option was eventually removed from the config file, but the underlying API retained until quite late. Maybe it was WinME's version of DOS which disabled the API. Despite all of that, the handle based Int 21 file APIs always supported being passed '/' as a path separator, and it was often accepted by some apps. DOS based 'C' source code often used "#include <some\\path\\file.h>", however many compilers also simply accepted "#include <some/path/file.h>", probably just as an artifact of the obvious implementation. This wasn't well known, so lots of DOS based 'C' source used '\\' in includes, plus also at the file API level.

bumblebritches5 4y ago

kazinator 4y ago

I use Cygnal for making a Windows version of TXR. https://www.kylheku.com/cygnal/ https://www.kylheku.com/cygnal/ You compile in the Cygwin environment where you have all the usual tools. Then shipping the program with cygwin1.dll from the Cygnal project gives it native-like behaviors.

kretaceous 4y ago

I mostly agree on the VSCode part. They should put it up front in the README, homepage and maybe a info modal/badge whenever a user installs said extension. But genuinely asking, how else would you 'label' VSCode? "A free and open-source code editor with some optional components that are proprietary"?

SCLeo 4y ago
Same as Google Chrome. No one claims Google Chrome is open source nowadays.
behnamoh 4y ago
Apple is worse in that regard. Is XCode open-source? Other than Darwin Kernel, is any part of macOS open-source? Did Apple even try to make Swift cross-platform? Is iCloud really comparable to OneDrive? How about Apple's locked and closed-source bootloaders?
- jeroenhd 4y ago
  Swift itself works on most platforms. The problem with using Swift cross platform is that Apple only bothered to make their GUI toolkit available for their platform in the same way Microsoft only makes their dotnet GUI platforms available for Windows (without resorting to "official" replacements that are owned by the same company but not built into the system, like Xamarin). As a consequence, many Swift libraries only focus on macOS, just like many dotnet libraries focus on Windows (though recent efforts have improved that situation). You can probably get a lot of them working on Linux as well and if you use Swift for command line tools or web applications. I suppose you can probably run the most important tools cross platform, but the non-native ecosystem is clearly a second class citizen. The big difference between XCode and VSCode is that Apple doesn't claim XCode is open source; also, XCode is more comparable to Visual Studio than VSCode in terms of SDK integration and preconfigured tooling. Huge parts of the Darwin kernel are actually publicly accessible while Microsoft only provides kernel sources under NDA in things like education projects. Unless you count the WinXP source code leak, that is. C# is sort-of mostly open source-ish except that debugger features are closed and the community has little say in its development. Apple did in fact put effort into making Swift cross platform, as outlined here[1]; though their intention is that Swift programs use the system runtime on macOS/iOS/iPadOS, they put the effort into making a base layer freely available for other operating systems to gain some portability. I'd personally argue that Apple and Microsoft are similarly if not equally open in their development, but Microsoft advertises itself much more "open source" than Apple. Apple's approach of "you can look but you can't touch" is a lot more explicit and their supposed openness comes up in fewer marketing materials. [1]: https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation

cpeterso 4y ago

Mozilla’s automated builds of Firefox for Windows, macOS, Linux, and Android are all cross-compiled on Linux VMs. Cross-compiling is faster and cheaper, especially because Windows’ file I/O and process launching is so slow.

behnamoh 4y ago
> Windows’ file I/O and process launching is so slow. It's not Windows' fault, rather it's NTFS.
- pxc 4y ago
  There's some documentation on this in some WSL issues on GitHub, but it's not just NTFS. It's stuff like the broader filesystem architecture's inclusion of pluggable 'filters' (kinda neat, but each layer of them incurs a performance cost) or the way commands on other operating systems depend on caches for certain syscalls that Windows doesn't keep, or keep anything equivalent to. Too tired to go find them atm
  - espenwa 4y ago
    This one? I remember it as an earnest description of the difficulties the WSL team had with the speed of NTFS - and I think it was one of the reasons for the switch to virtualisation in WSL2. <https://github.com/Microsoft/WSL/issues/873#issuecomment-425272829 https://github.com/Microsoft/WSL/issues/873#issuecomment-425...>
    - pxc 4y ago
      Yeah, that's the GitHub comment, thank you! My takeaway from that comment is that there are some important performances issues that apply generally to all filesystems on Windows. Maybe we can partially test whether that's the case by playing with WSL1 on ReFS, ExFAT (if that's even supported, with its limited permissions support, or ZFS, once OpenZFS on Windows stabilizes a bit.
- rurban 4y ago

manigandham 4y ago

The comments here showcase why webapps and Electron/webview shells are so common now. Maybe WebAssembly and its up and coming runtimes can finally some of this mess.

xyzzy_plugh 4y ago
I disagree. Cross-compiling has nothing to do with why Electron is common. The browser is the runtime that currently fixes this mess. WebAssembly would need a runtime matching current browser runtimes to be a real contender, and the best choice here is... a browser. So now you have electron but it's WebAssembly, which isn't significant enough to make a dent in this mess.

codedokode 4y ago

The post mentions CRLF line end syntax, I don't understand why anyone should bother with it. Use \n only, it works everywhere including Windows. Any modern IDE can handle Unix line endings. The same about file paths, use forward slash (/) everywhere and don't waste your time supporting DOS era standards. I think the core.autocrlf option in Git is more harmful than useful (for example, it can change file hashes and break something) and should be removed. An option to warn about unwanted \r characters on commit might be useful though.

deleted 4y ago
[deleted]
Shorel 4y ago
> I think the core.autocrlf option in Git is more harmful than useful Nowadays, I am willing to agree with you. It breaks more things than fixes them.
moogly 4y ago
Agreed. autocrlf = input Then change your editors and IDEs to save files with LF line endings (preferably with something like .editorconfig) and you'll have fewer problems.

fritigern 4y ago

Windows is a legacy operating system, not something from 2022. I don't see any good reason to use it.

revskill 4y ago

Seriously, i use Windows because i could play video games after coding. Coding in linux machine is 10000x easier than Windows.

alerighi 4y ago
Depends on what you use. To me Visual Sudio is the best and most gestire complete IDE on the market and C# one of the best language. Every time I program on another system I miss Visual Studio.
forgotpwd16 4y ago
>i could play video games Have you tried gaming in Proton?
vips7L 4y ago
The only time I have trouble in Windows is when people coding on a Linux machine don’t use cross platform tools.

lovelearning 4y ago

I presume most MS managers were in engineering roles earlier. It doesn't make sense to characterize the same kind individuals as crushing merely after a role change. My hunch is they always had the instinct to crush but didn't have the power earlier.

prvc 4y ago

Would falsely representing software intended to be proprietary as "open source" in its marketing copy have an adverse impact on the enforceability of its putative license?

flohofwoe 4y ago

Good post (I couldn't quite follow the open source angle tbh), but for the "why doesn't Developer Mode make Windows behave more like Linux" part: this would probably disgruntle a lot of 'native' Windows developers. Windows was always its separate island, and at least in the past it had a lot of developer mindshare (so more like a whole continent than an island), and from the point of view of those Windows devs, Linux is the odd one out ;) One common solution is to use scripting languages for build automation that try to hide most of the differences (e.g. Python or Node.js instead of Powershell vs Batch vs Bash), and most importantly there's simply no way around testing on at least Windows, macOS and Linux.

tigerlily 4y ago

I used to use MXE [1] to compile fully static Windows binaries on Linux VMs hosted with Travis. It needed to crane in everything though, so it was a source of bottlenecks from time to time. I was also uncertain about the provenance of a lot of the dependencies in that toolchain. So when Travis died I took the opportunity to move Windows builds back to gnu with msys2, all over GH Actions. These are actually comparatively snappy and I’m reasonably satisfied with it. [1] https://mxe.cc/ https://mxe.cc/

deleted 4y ago

[deleted]

ncmncm 4y ago

Life is too short to spend on fooling with Windows.