Because cross-compiling binaries for Windows is easier than building natively
I want Microsoft to do better, want Windows to be a decent development platform-and yet, I constantly see Microsoft playing the open source game: advertising how open-source and developer friendly they are - only to crush developers under the heel of the corporate behemoth's boot.
The people who work at Microsoft are amazing, kind, talented individuals. This is aimed at the company's leadership, who I feel has on many occassions crushed myself and other developers under. It's a plea for help.
The source of truth for the 'open source' C#, C++, Rust, and other Windows SDKs is proprietary
You probably haven't heard of it before, but if you've ever used win32 API bindings in C#, C++, Rust, or other languages, odds are they were generated from a repository called microsoft/win32metadata.
Unfortunately, the source of truth for these generated SDKs - the Windows SDK
.idl files - are proprietary despite living in the same repository with only an MIT license at the root.
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? I'll let you decide.
Azure Kinect DK is not open source
If you're one of the unlucky few who spent a few hundred dollars on an Azure Kinect developer kit, eyes shimmering with possibility and staring at that totally open-source microsoft/Azure-Kinect-Sensor-SDK repository - it was perhaps short lived.
Unfortunately, the Body Tracking SDK is a proprietary binary blob - so if you were looking to improve upon the body tracking, add ARM CPU support, get it working on Linux, or anything else - you're out of luck.
.NET is not an open
As covered in isdotnetopen.com, despite best efforts .NET is still not an open platform:
- ramming in a proprietary extension to continue to lockdown .NET.
- an open programming language is missing a debugger
- leadership decision to remove hotreload angers community and devdiv employees
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.
VS Code is marketed as open source, but it's not
The messaging around VS Code is clear, albeit a bit slippery, about being open source:
Visual Studio Code - Open Source ("Code - OSS")
This project has adopted the Microsoft Open Source Code of Conduct.
Free. Built on open source.
- The Python integration, Pylance, is 100% proprietary
- vscode-cpptools is proprietary
- Live share is not open source
- The C# and C++ debuggers are proprietary
- WSL and SSH remote development extensions are proprietary
- Telemetry is opt-out, not opt-in
Side note: If you're making VS Code extensions, please also publish them to open-vsx.org as Microsoft has sent cease-and-desists to those who use their extension registry outside of the VS Code product, so it cannot be used in the open-source fork vscodium.
I'm fine with proprietary software, but stop labeling it as "Made with natural ingredients."
It's not the fact that this software is proprietary that bothers me. I live with and use proprietary software daily. I'm not some purist.
What bothers me is that Microsoft pushes the idea these projects are open source, hosts them on GitHub, only has MIT licenses in the repositories, and doesn't mention it anywhere.
Then someone who actually cares digs in, only to find hidden proprietary binary blobs and closed GitHub discussions concluding 'legal said no, we won't change the license'
"Made with natural ingredients." is what it feels like. And I understand why they do it, too, how many people would eat the VS Code cereal if it read:
download now!VS Code! A proprietary editor from Microsoft Corp!
Windows development is broken (symlinks)
While I'm airing all of my greviences, I've been writing a game engine, Mach, in Zig for the past year. You know what Windows developers constantly complain to me about?
I tried it. It says the file doesn't exist
I point them to our FAQ, which gives two options:
- Option 1: Fix Windows
- Enable "Developer Mode" (warning: this turns on symlinks, which Microsoft says are a security risk)
- Enable symlinks in Git (Developer Mode is not enough.)
git config --global core.symlinks true
- Option 2: Cross-compile from WSL -> Windows using
zig build -Dtarget=x86_64-windows
Because somehow in 2022 cross-compiling Windows native binaries from Linux is easier than building on Windows natively.
I wish that was the end of the Windows developer pain story
- 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.
- "Oh, but this is a fixed issue!, you just need to set a registry key!" - Microsoft PMs on Twitter tell me
- (But, you know, beware, because according to Microsoft enabling this option may break File Explorer and other apps)
- (Also, BTW, make sure you enable
longfilepathsin Git too because enabling it in WIndows is not enough on it's own!)
- CRLF: (Also, you know to configure
- PowerShell ... BTW, Windows 10 ships with an outdated PowerShell version in which HTTP file downloadsare ~122x slower, you know you were supposed to update that out-of-band, right? Because Windows Update won't do that for you.
What does Developer Mode in Windows do again?
My plea to Microsoft
Again, the people who work at Microsoft are amazing, kind, talented individuals. I have no issues with you, I'm sure you are fighting the Microsoft behemoth in the same way to improve developer's lives.
I beg of Microsoft to do the following:
(1) Stop hiding proprietary code in 'open-source' GitHub repositories
It's not in the spirit of open source. It feels like code "Made with natural ingredients." only to find a plutonium core. If the license says MIT, it shouldn't contain proprietary source code.
Enact a policy to never put proprietary code on GitHub. Have it clearly stated in the README when a project contains proprietary code, or depends on substantial proprietary code to be used effectively.
I'm tired of finding this out through closed GitHub issues.
(2) Fix Developer Mode on Windows
I'm just trying to reiterate that real people are facing the issues I described above. They don't constantly raise these through your Feedback Hub where you can count them because, surprise! They just expect Windows development to be painful like this and expect to have to Google workarounds 24/7.
Here's how you can fix this:
If someone installs or launches developer tools (WSL, VS Code, Git, PowerShell, etc.) then prompt them to enable Developer Mode.
It's insane you can be using these tools, developing on Windows, without any knowledge a 'developer mode' exists. It's almost impossible to develop on a Mac without knowing about XCode.
If you turn on Developer Mode, have Clippy pop up and prompt the user:
Do you want me to enable symlinks (warning: this is a security risk)?
Do you want me to update PowerShell? (or stick with the multiple years-old version where file downloads are ~122x slower?)
Do you want me to enable file paths >255 characters? (warning: may break file explorer and other apps)
Do you want me to install Git?"
Do you want me to configure Git to use long file paths?
Do you want me to configure Git to use symlinks?
Do you want me to configure
Again, I've no qualms with the people spending their diligent efforts trying to improve Microsoft/Windows. This is feedback, I hope you'll direct it to the right people.
You can find me on Twitter @slimsag in case you need to send the Clippy hit squad.
Good post. Most of this, I can imagine they have some weak opposing argument, except this;
I have no idea how MS thinks that makes sense. Why is it like this? How have they not been working on this, shouldn't it be priority #1? Do the devs at MS do their Windows dev work, in Windows?