在Microsoft的所有时间里，我一直在为Linux开发人员创建工具。 从弗吉尼亚大学毕业后，我于2016年8月开始工作，在那里我学习了计算机科学和管理。 在学习期间，我主要使用C ++进行编程。 我的主要操作系统是Linux。
我的经历似乎与Microsoft可能需要的并不完全匹配，但是那时该公司在技术和文化方面都在发生重大变化。 该公司正在进入一个新的状态，在该状态下，所有操作系统（包括Linux）对其都非常重要。
我在Microsoft的工作始于Linux团队。 我在那里做SQL Server产品。 我被邀请加入这个团队，希望能将我在Linux方面的经验带入其中。 尽管我刚刚被排除在外，但由于我的经验，我对团队很有价值，这一事实令我印象深刻。
几年前，为Linux开发SQL Server变体的想法本来是愚人节的笑话，但在2016年，它是完全真实的。 在他们发布产品的第一个版本后不久，我加入了团队。 我开始改进SQL Server工具包，特别是对于管理员。 该工具包旨在管理Linux服务器和应用程序。 在Linux上使用SQL Server需要使命令行工具具有Linux用户所习惯的外观。
另外，我有机会设计了用于Linux的SQL Server GUI的第一个版本。 我从Visual Studio Code的分支开始，今天称为Azure Data Studio。 这是一个基于电子的应用程序，无论使用什么操作系统，都可以与任何类型的SQL Server一起使用。
在Microsoft的第一年，我从Linux的SQL Server中学到了很多东西。 以这种知识，我还可以包括基于技术和业务思想的结合来管理项目的开发和支持的方法的开发。
WSL团队，Chocolatey和Boxstarter在Microsoft Build 20182017年8月，我加入WSL（Linux的Windows子系统，Linux的Windows子系统）团队担任项目经理。 在Microsoft Build 2016上的宣布期间，我第一次听说了WSL。第9频道的相关视频“
在Windows的Ubuntu上运行Bash！ ”，发布后立即成为病毒。 显然，与会议上其他许多公告相比，它对观众更感兴趣。 在几分钟内，在为会议要点评分的框架内对WSL技术进行了简短的讨论。 但是，由此引起的观众直接发疯，更不用说记者了。 曾经有一段时间，Channel9支持团队担心用户对该视频剪辑的高度关注实际上是由于DDoS攻击造成的！ 微软发言人在Windows上运行的Ubuntu上启动Bash。
发现Windows用户需求的第一个团队是在Windows控制台上工作的团队。 在开发过程中，他们一遍又一遍地听到人们想要Linux Bash之类的东西。 结果，团队产生了以下想法：“如果仅使Bash shell能够在Windows上运行，那为什么会类似于Bash？”
这并不是说这很容易做到。 WSL的创建需要结合Windows的深入知识和系统，而Windows的深层知识是该系统核心的开发团队所拥有，它是由Microsoft Research开发的一项技术，称为picoprocess。 有趣的是，微微进程是使SQL Server在Linux上运行的技术。
picoprocess应该在用户模式下提供未修改的Linux实现。 Windows内核团队一直在开发用于将Linux系统调用连接到Windows的垫片。 换句话说，WSL使得可以在Windows NT内核上运行针对Linux编译的代码。 无需重新编译代码或使用虚拟机。
我们并没有创建自己的Linux发行版。 事实是有许多这样的分布。 WSL中可用的第一个Linux版本是Ubuntu。 我们联系了Canonical专家，以了解他们是否希望帮助我们处理WSL。 他们对我们的想法充满热情。 这导致了Ubuntu在Microsoft Store中出现的事实。 顺便说一句，上一句话本身听起来很不寻常。 现在，在Microsoft Store中，您可以计算6个分布。 我想知道某些操作系统上可用的其他应用程序商店是否还有其他操作系统？
Microsoft Store现在有6个可在WSL中使用的Linux发行版然后，我们编写的代码是与Linux兼容的内核系统调用，该调用充当Linux进程与Windows内核之间的接口。 Linux大约有340个系统调用。 问题是要决定首先执行哪个系统调用。 与任何操作系统一样，在Linux上，随着新版本OS的发布，会添加新的系统调用，但绝不会删除旧的调用，从而确保了向后兼容性。 首先，实现了对某些系统调用的处理，而其他所有内容都包装在诸如“尚未实现”之类的事件中。 这使WSL团队可以开始准确地分析Linux用户所需的系统。
首先应该实现哪个系统调用这个问题的答案意味着需要与将要使用WSL的人们建立联系。 在Build大会上有关此技术的消息旨在使人们开始使用WSL并提供反馈。 为了获得WSL，您必须是Windows Insider计划的成员。 任何人都可以连接到该程序。 您可能会认为该计划的参与者只是那些对Windows感兴趣的人，但是在超过一千万的订阅者中，却有各种各样的人感兴趣。 他们不仅对Windows感兴趣，还对例如游戏，蓝牙和WSL的新功能感兴趣。
对使Bash shell在Windows上运行感兴趣的用户组之一是与开发在Linux服务器上运行的Web应用程序有关的Web开发人员。 组装应用程序的整个过程通常是一系列Bash命令。 此外，如果有人决定寻求Web应用程序开发方面的帮助，例如在Stack Overflow上，他可以找到的大多数代码示例都将设计为在Linux上运行。 对于将Windows用作计算机进行Web开发的用户来说，这不是特别好。 通常，对于这类开发人员而言，最简单的方法就是切换到Mac平台。 在macOS上，类似的代码示例可以正常运行。
WSL在Windows上出现的头几周，一个企业用户
就可以运行XEyes。 该程序在WSL中运行的X11窗口系统上运行。 XEyes是一个简单的程序。 她显示跟随鼠标光标的卡通眼睛。 但是这个示范炸毁了社交网络。
XEyes通过WSL在Windows上运行我们讨论了很多有关如何收集有关WSL的用户评论的确切信息。 用于收集反馈的传统工具是UserVoice。 我们有一个专门为WSL设计的UserVoice网站，该网站收集了数百个想法和关于各种问题的数千张选票。 关于是否应该使用GitHub，真正的问题浮出水面。 由于Web开发人员是最早对WSL感兴趣的用户组之一，因此GitHub问题非常重要。 但是WSL并不是一个开源项目。 在GitHub上放置这样的项目看起来很奇怪。 我们决定满足开发人员的要求，并在GitHub上创建了一个页面，用于报告问题，进行反馈和讨论。 从那时起，我们收到了数千条关于与Windows上使用Linux有关的许多问题的消息。
成千上万的人在WSL
GitHub存储库中留下了错误消息。 WSL团队对每个此类消息进行了审查和讨论，并对每个消息进行了评论。 此后，决定了进一步的行动。 如果为了实现一定的机会或解决某种错误，有必要编写新代码-创建此代码并将其添加到WSL项目中，然后将其放入Windows Insider程序下分发的所有Windows程序集中。 从接收错误消息到纠正错误的整个周期都不需要花费很多时间-大约几周。
结果，由于WSL团队对用户请求的操作响应，可以说社区参与了WSL的创建过程。 人们通过UserVoice或GitHub报告问题或希望，团队对此进行了审查，并对项目进行了更改，这些更改随后出现在Windows Insider项目的内部版本中。
当我加入WSL团队担任项目经理时，我专注于使WSL脱离beta版。 用户投诉主要与兼容性和性能有关。 但是，我认为，如果用户担心此类事情，则意味着他们认真使用了我们的开发。 只有在特定软件系统的帮助下解决了一些大问题的人员才能考虑性能。 结果，尽管我们还有很多事情要做，但是我们这样做是有原因的，这样人们就可以使用WSL解决更多的问题，从而可以更快地解决他们的问题。
随着WSL的功能开始扩展，我们努力使WSL更接近开发人员，而不仅仅是传统上使用Microsoft生态系统的用户。 参加PyCon和OSCON之类的活动非常有趣。 在场的开发人员惊讶于Microsoft代表也参加了这些活动。 开发人员对在Windows环境中运行Linux的想法不信任。 在这些活动中，我展示了SQL Server，WSL和Visual Studio Code。
WSL在各种活动中的演示我回应了他们的怀疑评论，并提出了一些尝试，请尝试给我看一下。 当怀疑者开始执行自己的命令，小脚本和代码片段时，我总是对发生的事情产生强烈的反应：“等等，这确实是Linux。 你是怎么做到的？ 我为什么不知道呢？” 他们常常得出这样的结论：我们创造了满足他们需求的东西，看起来很有趣。
我们考虑了用户对WSL兼容性和性能的抱怨，并发布了新的系统架构
WSL 2 。 通过在Windows中包含Linux内核，它提供了完全的兼容性，并将速度提高了20倍。 我在创建WSL 2的基础以及在2019年5月举行的Build大会上观看了该技术的发布方面获得了有趣的经验。 如今，WSL项目已经超过了beta版本，而升级到了版本2。
此外，我与其他团队一起在Microsoft工作，试图确保WSL可以与他们的产品一起使用。 使用WSL的一个重要示例是Visual Studio Code。 这是用于开发JavaScript和Node.js项目的最流行的代码环境。 当我意识到使用此编辑器的开发人员可以从WSL中获得巨大收益时，我对Visual Studio Code产生了兴趣。 最初，它与编写大量代码无关。 主要目的是简化在WSL环境中运行的Node.js程序的调试。 这将使开发人员有机会使用WSL在Windows计算机上开发针对Linux版本的Node.js设计的程序。 调试此类程序看起来就像在Linux上调试它们一样。
首次尝试将 Visual Studio Code与WSL和Node.js 集成事实证明，这对于JavaScript和Node.js来说是可能的之后，我们开始收到许多对其他语言（例如C ++和Python）进行类似操作的请求。 我对WSL和VS Code集成的这个示例很着迷，发现我对此都非常感兴趣。 这使我成为了为Linux开发人员构建工具的新角色。 现在，我专注于VS Code中面向C ++开发人员的工具。 当然，在这项工作中，我专注于Linux。 很高兴在今年的PyCon活动上看到相应的WSL扩展发布时对Visual Studio代码远程开发的演示。 同时，引入了我的团队正在开发的C ++扩展。
尽管我没有花很多时间在Microsoft上，但我很高兴能够参与为Linux开发人员开发的许多工具。 该数据库和对Windows上Linux的支持，以及用于编写和调试代码的工具。 我计划继续在Linux上工作，并创建全世界的开发人员都会喜欢使用的工具。
亲爱的读者们！ 您是否使用WSL？
