因為 Windows 的交叉編譯二進制文件比本地構(gòu)建更容易
我希望微軟做得更好，希望 Windows 成為一個不錯的開發(fā)平臺——然而，我經(jīng)?？吹轿④浽谕骈_源游戲：宣傳他們對開源和開發(fā)者的友好程度——只是為了在公司的腳下碾壓開發(fā)者龐然大物的靴子。
在微軟工作的人都是了不起、善良、有才華的人。這是針對公司的領(lǐng)導(dǎo)層，我覺得他在很多場合都壓垮了我自己和其他開發(fā)人員。這是求救。
“開源”C#、C++、Rust 和其他 Windows SDK 的真實來源是專有的
您可能以前沒有聽說過它，但是如果您曾經(jīng)在 C#、C++、Rust 或其他語言中使用過 win32 API 綁定，那么它們很可能是從名為microsoft/win32metadata的存儲庫中生成的。
不幸的是，這些生成的 SDK 的真實來源——Windows SDK.idl文件——是專有的，盡管它們位于同一個存儲庫中，根目錄下只有 MIT 許可證。
派生的社區(qū)作品，比如 D 語言、Dart 或 Zig 綁定到由這些文件生成的 win32 API 是否是開源的——如果微軟沒有這樣發(fā)布它們？我讓你決定。
Azure Kinect DK 不是開源的
如果你是少數(shù)幾個在 Azure Kinect 開發(fā)者工具包上花費數(shù)百美元的不幸者之一，你的眼睛會閃爍著可能性，盯著完全開源的microsoft/Azure-Kinect-Sensor-SDK存儲庫——這可能是短暫的.
不幸的是，Body Tracking SDK 是一個專有的二進制 blob – 因此，如果您希望改進身體跟蹤，添加ARM CPU 支持，讓它在 Linux 上運行，或者其他任何東西 – 你就不走運了。
.NET 不是開放的
如isdotnetopen.com 所述，盡管盡了最大努力，.NET 仍然不是一個開放平臺：
撞擊專有擴展以繼續(xù)鎖定 .NET。一種開放的編程語言缺少調(diào)試器領(lǐng)導(dǎo)層移除 hotreload 的決定激怒了社區(qū)和 devp 員工
我仍然感到震驚的是，他們確實讓 .NET 團隊dotnet watch在最后一刻恢復(fù)了 PR，以便他們可以將其作為一項功能出售。
VS Code 作為開源銷售，但它不是
VS Code 周圍的信息很清楚，盡管有點滑，關(guān)于開源：
Visual Studio Code – 開源（“代碼 – OSS”）
該項目采用了微軟開源行為準(zhǔn)則。
自由的。建立在開源之上。
同時：
- Python 集成 Pylance 是 100% 專有的
- vscode-cpptools 是專有的
- 實時共享不是開源的
- C# 和 C++ 調(diào)試器是專有的
- WSL 和 SSH遠(yuǎn)程開發(fā)擴展是專有的
- 遙測是選擇退出，而不是選擇加入
旁注：如果您正在制作 VS Code 擴展，請同時將它們發(fā)布到open-vsx.org，因為 Microsoft已向那些在 VS Code 產(chǎn)品之外使用其擴展注冊表的人發(fā)出停止和終止通知，因此無法使用在開源 fork vscodium中。
我可以使用專有軟件，但不要再將其標(biāo)記為“由天然成分制成”。
困擾我的并不是這個軟件是專有的。我每天都在使用專有軟件。我不是什么純粹主義者。
令我困擾的是，微軟推動這些項目是開源的，將它們托管在 GitHub 上，存儲庫中只有 MIT 許可證，并且在任何地方都沒有提及。
然后有人真正關(guān)心挖掘，卻發(fā)現(xiàn)隱藏的專有二進制 blob 并關(guān)閉了 GitHub 討論，結(jié)論是“法律說不，我們不會更改許可證”
“由天然成分制成?！?是什么感覺。我也理解他們?yōu)槭裁催@樣做，如果上面寫著有多少人會吃 VS Code 麥片：
VS 代碼！來自 Microsoft Corp 的專有編輯器！立即下載！
Windows 開發(fā)被破壞（符號鏈接）
雖然我正在宣揚我所有的悲傷，但在過去的一年里，我一直在 Zig 編寫游戲引擎 Mach 。你知道 Windows 開發(fā)人員經(jīng)常向我抱怨什么嗎？
我嘗試過這個。說文件不存在
我將他們指向我們的常見問題解答，它提供了兩個選項：
因為不知何故，在 2022 年，從 Linux 交叉編譯 Windows 原生二進制文件比在 Windows 上原生構(gòu)建更容易。
我希望 Windows 開發(fā)者的痛苦故事就此結(jié)束
- 長文件路徑：Azure、OpenSearch 和約90 個其他開源項目必須記錄如何在 Windows 上啟用長文件路徑，因為默認(rèn)限制為約 255 個字符?！芭?，但這是一個已解決的問題！，你只需要設(shè)置一個注冊表項！ ” – Twitter 上的 Microsoft PM 告訴我（但是，你知道，要小心，因為根據(jù)微軟啟用此選項可能會破壞文件資源管理器和其他應(yīng)用程序）（另外，順便說一句，確保你longfilepaths也在 Git 中啟用，因為在 WINdows 中啟用它本身是不夠的！）
- CRLF：（另外，你知道配置core.autocrlf對嗎？）
- PowerShell …順便說一句，Windows 10 附帶了一個過時的 PowerShell 版本，其中 HTTP 文件下載速度慢了約 122 倍，你知道你應(yīng)該更新那個帶外的，對吧？因為 Windows 更新不會為您執(zhí)行此操作。
Windows 中的開發(fā)人員模式又做了什么？
我對微軟的請求
同樣，在微軟工作的人都是了不起、善良、有才華的人。我對你沒有意見，我相信你正在以同樣的方式與微軟的龐然大物抗?fàn)帲愿纳崎_發(fā)者的生活。
我懇求微軟做以下事情：
(1) 停止在“開源”GitHub 存儲庫中隱藏專有代碼
這不符合開源精神。感覺就像代碼“由天然成分制成”。只是為了找到一個钚核心。如果許可證上寫著 MIT，則它不應(yīng)包含專有源代碼。
制定一項政策，永遠(yuǎn)不要將專有代碼放在 GitHub 上。當(dāng)項目包含專有代碼或依賴大量專有代碼才能有效使用時，請在自述文件中明確說明。
我厭倦了通過封閉的 GitHub 問題來發(fā)現(xiàn)這一點。
(2) 修復(fù)Windows上的開發(fā)者模式
我只是想重申，真實的人正面臨著我上面描述的問題。他們不會經(jīng)常通過您的反饋中心提出這些問題，您可以在其中計算它們，因為，驚喜！他們只是期望 Windows 開發(fā)會像這樣痛苦，并期望必須 24/7 全天候使用 Google 解決方法。
以下是解決此問題的方法：
如果有人安裝或啟動開發(fā)人員工具（WSL、VS Code、Git、PowerShell 等），則提示他們啟用開發(fā)人員模式。
您可以使用這些工具在 Windows 上進行開發(fā)，而不知道存在“開發(fā)人員模式”，這真是太瘋狂了。如果不了解 XCode，幾乎不可能在 Mac 上進行開發(fā)。
如果你打開開發(fā)者模式，讓 Clippy 彈出并提示用戶：
你想讓我啟用符號鏈接嗎（警告：這是一個安全風(fēng)險）？
要我更新 PowerShell 嗎？（或者堅持使用文件下載速度慢約 122 倍的舊版本？）
您要我啟用 >255 個字符的文件路徑嗎？（警告：可能會破壞文件資源管理器和其他應(yīng)用程序）
你要我安裝 Git 嗎？”
你想讓我配置 Git 以使用長文件路徑嗎？
你想讓我配置 Git 以使用符號鏈接嗎？
要我配置core.autocrlf嗎？
問題解決了！
謝謝
再說一次，我對那些努力改進 Microsoft/Windows 的人們毫不猶豫。這是反饋，我希望您能將其發(fā)送給正確的人。
