软件自由界发起的呼吁抵制
2011-10-20 12:58:18 
阿炯
自由软件基金会呼吁抵制Win8认证电脑
软件自由保护组织连发两篇博文：呼吁所有FOSS放弃Github
技术主权与生态控制的战争之Visual J++失败的思考
VB/VBA的解释器为何不跨平台
自由软件基金会呼吁抵制Win8认证电脑
2011年10月消息，微软宣布Windows 8认证电脑必须采用“Secure Boot(安全启动)”，自由软件基金会(FSF)就此发表声明，称限制性的安全启动将会让电脑只能运行微软的操作系统，限制用户安装自由软件GNU/Linux的自由，它呼吁签名抵制。
安全启动技术初衷是防止恶意程序，防止未授权的程序启动。FSF担心微软和硬件厂商会以限制安装其它操作系统的方式实现“安全启动”，果真如此，那么它应该被称为“受限启动(Restricted Boot)”。FSF鼓励所有电脑制造商抵制采用“受限启动”，鼓励电脑用户签名声明绝不购买或推荐限制用户自由的电脑，并积极鼓动其他用户避免此类的 “监禁系统”。
--2011-10-29
几个星期前微软要求win8认证客户机支持安全启动，启动进程内的所有固件和软件都需要可信CA签名，显然微软试图锁定启动进程，阻止安装无签名的第三方系统如Linux。前不久，自由软件基金会(FSF)就此发表声明，称限制性的安全启动将会让电脑只能运行微软的操作系统，限制用户安装自由软件GNU/Linux的自由，它呼吁签名抵制(原报道)。现在Canonical 和 Red Hat 联手发布白皮书UEFI Secure Boot Impact on Linux [PDF]，由Jeremy Kerr, Matthew Garrett, and James Bottomley撰稿，呼吁所有用户应拥有Secure Boot选择权，系统商应建立一个机制让用户来配置自己认可的软件列表，PC机应包含一个应用界面允许用户轻易启用/禁用Secure boot。
“We present a set of recommendations that will allow users the freedom to choose their software, while retaining the security features of UEFI Secure Boot, and complying with open source licenses used in distributions of Linux.”
另外：Linux基金会同样也于今日发表了一份UEFI Secure Boot白皮书：Making UEFI Secure Boot Work With Open Platforms，由James Bottomley and Jonathan Corbet撰稿。
“Linux and other open operating systems will be able to take advantage of secure boot if it is implemented properly in the hardware. This document is intended to describe how the UEFI secure boot specification can be implemented to interoperate well with open systems and to avoid adversely affecting the rights of the owners of those systems while providing compliance with proprietary software vendors’ requirements.”
两份白皮书都定义了UEFI Secure Boot 规范应如何定义，以让PC正常运行自由操作系统。
--2011-11-02
开源Linux厂商Redhat及Canonical发表联合声明，要求微软Windows 8系统认证硬件保留使用Linux操作系统的权利。Linux基金会也发表一份白皮书，希望让Linux操作系统等开源代码平台可以搭配UEFI的“安全 开机”(Secure Boot)功能运作。微软规定取得Windows 8认证(Designed for Windows 8标签)的电脑必须使用UEFI介面取代BIOS，而且必需使用其Secure Boot功能。该功能可以在电脑开机时，为避免Rootkit等恶意软件控制电脑，只使用认证过的软件开机。
事实上Linux阵营也都认同微软以UEFI取代BIOS，因为这样可以让操作系统与硬件更好的兼容，在硬盘、内存、电源管理等方面都可以有更好的表现，而且Secure Boot的确可以避免使用者的设备遭恶意软件绑架。但是Linux阵营担心的是，一般使用者可能在微软限制下而无法安装Windows之外的操作系统。
Linux基金会建议硬件厂商开放Secure Boot的设定，以方便各Linux系统可以在Secure Boot机制下启动，并使用其安全机制，支援多重操作系统开机。该基金会将建立一个独立的证书颁发机构，让多个操作系统可以取得Secure Boot所需的凭证。不过该系统是否能运作的关键在于硬件厂商是否支援。电脑硬件必须能够容许使用者重新设定其Secure Boot功能的相关凭证，否则开启Secure Boot功能时，该硬件仍仅能使用预设的微软操作系统。
微软原先设定仅有硬件生产厂商可以设定Secure Boot的操作系统凭证，Linux团体建议硬件设备厂商应该提供适当的机制，让使用者拥有更大的控制权可以改变相关设定。其在九月在Build 2011展示Windows 8系统，并通过由三星生产的平板电脑发送给开发人员，该电脑就可以将Secure Boot功能关闭。微软当时也在博客中表示，使用者可以控制自己的电脑设备是否开启Secure Boot功能，尤其是想执行先前版本操作系统的用户，但认为关闭Secure Boot功能很容易遭受攻击。
Linux团体希望所有的Windows 8系统至少要保留用户开关Secure Boot功能的选项，以方便使用者安装Windows 8以外的操作系统。Windows 8预计将于明年下半年上市，支持x86/x64及ARM处理器，目前微软已经释出开发人员预览版本。
软件自由保护组织连发两篇博文：呼吁所有FOSS放弃Github
软件自由保护组织（Software Freedom Conservancy，简称 SFC）在2022年7月发布新闻稿，表示其项目不再托管到 GitHub，并呼吁其他开源社区和开发者也这样做。该组织连续发布两篇博文，呼吁所有完全免费和开源 (FOSS) 开发者放弃 Github。
访问：《Give Up GitHub: The Time Has Come!》
对于放弃 Github 的理由，SFC 提供的理由包括：
1、Copilot 是一款营利性产品
该服务由微软和他们的 GitHub 子公司开发和销售--使用人工智能（AI）技术为开发者自动生成互动代码。人工智能模型的训练（根据 GitHub 自己的声明）完全是用托管在 GitHub 上的项目，包括许多在版权许可下的许可。这些项目大多不属于“公共领域”，它们是根据 FOSS 许可证授权的。这些许可证有一些要求，包括适当的作者归属，在 copyleft 许可证的情况下，它们有时要求基于和/或包含该软件的作品必须在与先前作品相同的 copyleft 许可证下许可。一年多来，微软和 GitHub 一直无视这些许可要求。他们对这些行为的唯一辩护是他们的前首席执行官的一条Twitter，他在Twitter上谎称关于这个话题的法律问题实际上已经解决。除了法律问题，GitHub 选择使用版权代码来为创建专利软件服务，其道德影响也很严重。
2、签订营利性的软件服务合同
2020 年，社区发现 GitHub 与美国移民和海关执法局（ICE）签订了营利性的软件服务合同。包括一些 GitHub 员工在内的活动人士，两年来一直呼吁 GitHub 取消该合同。GitHub 的主要答复是，他们的母公司微软多年来向 ICE 出售 Microsoft Word，没有任何公众投诉。他们声称，这在某种程度上证明了与一个政策有问题的机构有更多的业务。无论你对 ICE 及其行为的看法如何，GitHub 对提出这一重要问题的活动家的持续轻视和虚伪的回应表明，GitHub 将其利润置于社区的关注之上。
3、托管本身就基于专利软件
虽然 GitHub 假装支持 FOSS（就像他们之前的 SourceForge 一样），但他们的整个托管网站本身就是专利和/或商业机密软件。我们很欣赏 GitHub 允许它的一些员工有时为上游项目贡献 FOSS，但我们的社区已经被那些声称支持 FOSS，同时又积极说服社区依赖他们的专有软件的公司伤害过很多次了。我们不会让 GitHub 以同样的方式烧毁我们的。
4、不 FOSS
GitHub 与 FOSS 项目托管行业的大多数同行不同，因为 GitHub 甚至不提供任何自我托管 FOSS 的选项。他们的整个代码库是秘密的。例如，虽然我们对GitLab的"社区"和"企业"版并行的商业模式有不满，但至少GitLab的社区版提供了自我托管的基本功能，而且是 100% 的 FOSS。同时，还有一些非营利性的 FOSS 托管网站，如 CodeBerg，他们将自己的平台公开开发为 FOSS。
5、复制权
长期以来，GitHub 一直试图诋毁版权保护制度。他们的各个CEO经常大声疾呼，对复制权持否定态度，包括他们的创始人（也是前CEO）在OSCON的主题演讲中专门攻击复制权和 GPL。这一点从高层渗透下来。多年来，我们亲眼看到GitHub的员工在许多场合争论不休，以说服项目避免使用复制权；我们甚至看到 GitHub 的员工直接在 GitHub 的 bug ticket 上这么做。
笔者注：2018年6月微软以75亿美元收购GitHub之时，就是GitHub开始走向终结之始。
2011年，微软85亿美元收购Skype
2013年，微软75亿美元收购Nokia
2016年，微软260亿美元收购LinkedIn
......
技术主权与生态控制的战争之Visual J++失败的思考
1996年，微软推出Visual J++ 1.0时，整个软件行业都在为Java的崛起沸腾。这种“一次编写，到处运行”的语言似乎预示着跨平台时代的降临，而微软的入局被视为对未来的重要押注。然而到了2001年，Visual J++ 6.0却成为微软历史上最短命的开发工具之一，其消亡不仅标志着一款产品的失败，更揭示了技术战争中一个永恒的真理：谁掌握技术主权，谁就掌握生态的咽喉。失败原因可小结如下：
1.技术僭越：当微软试图重构Java基因
2.法律绞杀：一场16亿美元的认知革命
3.生态反叛：开发者用脚投票的启示录
4.涅槃重生：从J++废墟里崛起的.NET哲学
5.历史的回响：当技术冷战降临新时代
本节转自2025年2月的《和码说》，感谢原作者。
一、技术僭越：当微软试图重构Java基因
在加利福尼亚州山景城的Sun Microsystems总部，工程师们最初对微软拥抱Java的态度是矛盾的。1995年Java横空出世时，Sun将其定位为对抗Windows垄断的武器，而微软的加入仿佛宿敌伸出的橄榄枝。但这种幻想很快破灭——微软从未打算做一个顺从的“生态伙伴”。Visual J++ 6.0的代码编辑器里隐藏着一个危险的秘密：在标准Java语法之下，微软悄然植入了Windows基因。
通过Windows Foundation Classes（WFC），微软创建了一套深度依赖Windows API的图形库。开发者只需拖拽控件就能快速构建界面，但这些代码一旦离开Windows平台就会变成无法运行的死代码。更激进的J/Direct技术甚至允许直接调用Windows原生API，如同在Java的血管里注入了Windows的DNA。这种技术策略的背后，是时任微软开发工具部门负责人安德斯·海尔斯伯格（Anders Hejlsberg）的清醒认知。在多年后的《Behind the Code》访谈中，他坦言：“我们意识到，把命运交给别人的技术标准等于慢性自杀。当你依赖他人的平台时，对方随时可以改变规则——就像Sun对我们做的那样。
“这种”技术僭越”直接动摇了Java的立身之本。一位曾参与Visual J++开发的工程师透露，微软内部将这种策略称为“拥抱、扩展、再灭绝”（Embrace, Extend, Extinguish）。但这一次，Sun没有坐以待毙。1997年10月，Sun以违反Java许可协议为由将微软告上法庭，指控其蓄意破坏Java跨平台特性。这场诉讼如同照向深海的手电筒，照亮了微软技术野心的真正轮廓：不是要推广Java，而是要吞噬Java。
二、法律绞杀：一场16亿美元的认知革命
当Sun的法律团队在法庭上展示Visual J++生成的.class文件时，一个残酷的现实被揭开：这些字节码只能在微软的JVM上运行，与Sun的官方实现存在系统性偏差。微软的辩护词充满技术官僚式的狡黠——他们声称“优化”是为了提升Windows用户体验。但法官最终认定，微软通过技术手段制造了事实上的“Java方言”，构成对Sun知识产权的侵犯。
2001年的和解协议像一记重锤：微软支付16亿美元赔偿，并永久退出Java工具市场。这个数字背后是更深刻的认知代价。安德斯在回忆这段历史时说：“我们以为可以通过技术优势重塑规则，但低估了生态系统的反噬力。当你站在别人的地基上盖楼时，对方随时可以抽走砖块。”这场败诉成为微软技术战略的转折点，直接催生了两个改变历史的决定：放弃对Java的改造，转而全力打造完全自主的.NET框架；将安德斯从Delphi之父转型为C#语言首席架构师。
微软的挫败暴露了一个残酷现实：在别人的技术标准框架下创新，本质是戴着镣铐跳舞。即便强如微软，也无法突破“技术主权”的铁律。正如安德斯在节目中所言：“.NET的诞生不是偶然，而是我们在Visual J++的灰烬里找到的答案——唯有完全掌控技术栈，才能避免重蹈覆辙。”
三、生态反叛：开发者用脚投票的启示录
在法庭激战的同时，另一场战争在开发者社区悄然展开。1998年的JavaOne大会上，时任Sun首席科学家的比尔·乔伊举起一本《Java语言规范》，对着台下数千名开发者说：“如果有人试图用锁链束缚Java的自由，我们就用代码打破它！” 这句话像野火般在社区蔓延。曾经被Visual J++高效开发体验吸引的程序员们开始觉醒——他们意识到自己正被诱入微软的生态陷阱。
Borland JBuilder的崛起成为这场反叛的标志。这个严格遵循Java标准、支持跨平台部署的IDE，在1999年市场份额飙升至34%，而Visual J++则从巅峰时期的28%跌至不足10%。更致命的是开源运动的兴起：2001年IBM向Eclipse基金会捐出价值4000万美元的代码，催生出完全开放、可扩展的Java开发环境。一位从Visual J++转向Eclipse的开发者回忆道：“在Eclipse里，我找回了Java的初心——自由。而微软的J++就像个黄金牢笼，看似华丽，实则禁锢。”
这种生态反叛揭示了技术产品最本质的生存法则：开发者的忠诚不属于某个公司，而属于技术本身的价值观。微软试图用Windows生态同化Java社区，却忽略了后者对“跨平台自由”的宗教式信仰。安德斯在反思时承认：“我们过分迷信技术优势，却忘记了开发者生态的‘群体意志’。这是比法律败诉更深刻的教训。”
四、涅槃重生：从J++废墟里崛起的.NET哲学
Visual J++的死亡通知书，反而成为.NET的出生证明。2000年6月，比尔·盖茨在论坛上首次披露.NET战略时，特意强调其“技术主权”属性：从CLR（公共语言运行时）到C#语言，每个环节都完全受控于微软。这种彻底的技术自主性，正是用Visual J++的失败换来的认知升级。
安德斯作为C#之父，将这种哲学注入语言设计的每个细节。C#借鉴了Java的语法简洁性，却通过委托、属性、LINQ等创新构建起独特的技术护城河。更重要的是，.NET框架从第一天起就明确服务于Windows生态——这种“光明正大”的平台绑定，反而比Visual J++的隐性控制更容易被接受。正如安德斯所说：“.NET从不伪装成跨平台救世主，我们就是要做最好的Windows开发工具。清晰的定位反而赢得了尊重。”
这种战略转向的背后，是微软对“技术主权”认知的升华。2014年，微软宣布开源.NET Core，此时的开放是基于完全自主的技术底座。这种从“控制者”到“引领者”的蜕变，与Visual J++时代形成鲜明对比。今天的微软甚至为Java提供VSCode插件支持，但这种开放已无关生死——因为.NET早已完成技术主权的筑基。
五、历史的回响：当技术冷战降临新时代
Visual J++的故事在今天的科技战争中不断重演。2019年Google与Oracle的Java API版权案、2020年Epic Games对苹果应用商店的反垄断诉讼，本质都是技术主权之争的延续。当华为被禁止使用GMS服务时，它被迫推出鸿蒙系统的路径，与微软当年转向.NET何其相似。
我们正在进入一个技术主权比任何时候都重要的时代。当大国博弈渗透到每个技术标准，企业只有两种选择：要么像.NET那样建立完全自主的栈，要么像Eclipse基金会那样构建去中心化生态。夹在中间的骑墙者，终将沦为弃子。这段话恰如其分地解释了Visual J++的命运——它诞生于微软对Java生态的骑墙策略，最终在技术主权的铁壁前撞得粉碎。
如今，当开发者用Visual Studio Code编写着跨平台的Python代码，或是在Azure云上部署Linux容器时，微软早已不是那个执着于Windows绑定的帝国。但Visual J++的教训依然如幽灵般游荡在每一行代码里：在技术的世界里，没有中立的工具，只有永恒的生态战争。而胜利永远属于那些既深谙技术本质，又懂得尊重生态规律的清醒者。
VB/VBA的解释器为何不跨平台
1、Visual Basic/VBA的解释器，才是真正继承BASIC衣钵的那一脉。大家或许对1970年代的BASIC风靡一时有所耳闻，仔细想想，那时可是大中型机当道的时代。世界上主要的操作系统，都才刚开始有想法，几乎还是一机一码的时代，为何BASIC能够独领风骚？其实，最根本的原因，便是DEC为了让BASIC在各大机器上运行，放弃了编译机制，而改用解释机制。
解释器今天叫虚拟机或运行时，可以保证在靠近人的这一端，以不变的姿态（比如源码编写和提交）应万变（不同类型的机器平台）。看看今天的JAVA、Python、.NET，就知道这是一顶好的设计，应该说BASIC也算是解释型语言的鼻祖了，可为何没能在今天的跨平台编程界留下一席之地呢？不仅其子孙VB/VBA成了业界黑户，而且在其他平台上也没能出现旗鼓相当的选手，这是为何呢？
2、回顾历史，『机缘巧合和时势造英雄』应当最为贴切。BASIC的简单易用，极大降低了计算机的使用门槛，这是它在各大机器上受欢迎的外在驱动力。而内在的，就需要程序员为各类不同的机器编写解释器，以便用户能在不同机器上以近乎相同的方式进行使用。那时的计算机硬件制造，算是百花争鸣的时代，有很多厂商都在生产，因此写解释器的生意供不应求，甚至成为一个细小的行业。
和他的伙伴，恰好处于这样的环境，写解释器成为轻资产创业的不二之选。应当说，微软的基因里一开始就是要处理不同平台的需求，对于跨平台绝对是有很深的理解的。只可惜，那时硬件性能未跟上，业界对于解释机制视若过街老鼠，对其性能表现嗤之以鼻。或许是微软认清了现实，也或许是PC的头部（英特尔）开始形成，微软于1983年，给出了编译版的BASIC。
但并未获得IBM的认可，具体原因已无从查证。IBM强迫英特尔将芯片的生产销售许可授权给AMD，让英特尔亲手扶植了一个强大的竞争对手。或许大家可从这件事里看出些端倪，那就是IBM更希望客户或供应商处于充分的竞争环境，而不是拥有垄断地位来增强对IBM的议价能力。
随着DOS系统越来越不能胜任，1989年微软开始与IBM合作研发OS/2，为放弃DOS做准备。1991年，全鼠标驱动的BASIC随Windows3.0发布，微软也最终与OS/2分道扬镳。从这里，其实可以看出大家各有各的想法，只不过微软的野望更大而已，IBM终究不过是微软壮大的营养来源。
3、JAVA崛起后，准确地说是互联网崛起后，微软的种种应对，应当都是围绕当初的野望展开的。从早期的.NET的伪跨平台，到后来的Win8霸屏的企图，微软一统江湖的心思不再躲躲藏藏。如果对PE结构有了解的细心人，就会发现，PE结构早就将微软的雄心暴露无遗了。
PE是Windows上可执行程序文件的格式，比如各种应用程序的EXE/DLL/OCX/SYS等文件，就是该采用的该结构。不得不承认，从16位到32位，再到今天的64位，PE结构极具前瞻性。大家总是很奇怪微软的兼容能力为何如此变态，甚至疑问那得堆多少屎山啊。其实，人家在架构时，早就算计了，好吧！PE结构从32到64几乎没有变动，所以64位Win上的32位应用才能左右逢源。
看看具体的，IMAGE_FILE_HEADER中的Machine，用于标识应用程序适用的CPU类型，好家伙：IntelX86和IA64系列、MIPS系列、Alpha、SH系列、ARM系列、IBM PowerPC系列、AMD系列，几乎市面上能看到的CPU都包含了。
再来看看IMAGE_OPTIONAL_HEADER32的Subsystem，用于标识应用程序运行的操作子系统，有OS/2的身影，也有Posix、CE、EFI、XBOX的身影，更别提Win11里的Linux子系统了。
从这些痕迹，大概就能判断出，微软的Windows其实想做成操作系统的母系统。
4、所以，JAVA的一处编写，处处编译运行的跨平台，在微软的字典里其实是看不上的。微软要的是一处编译，到处运行的大一统。或者说，微软压根就认为，跨平台是系统的事，而非应用程序层面的事。
看看在这一概念下，微软干了些什么？微软在Win10出了ARM版，完美兼容Office等Win32应用，VB/VBA也可以运行在ARM芯片上。微软在Win11出了Linux版，2025年第一季度微软再次宣布会在Win11中全面优化Win32，相信不久Win32应用就可以跑起来了。所以，VB/VBA的解释器，就不太可能出海！很多事情，也就可以得到解释了。
软件自由保护组织连发两篇博文：呼吁所有FOSS放弃Github
技术主权与生态控制的战争之Visual J++失败的思考
VB/VBA的解释器为何不跨平台
自由软件基金会呼吁抵制Win8认证电脑
2011年10月消息，微软宣布Windows 8认证电脑必须采用“Secure Boot(安全启动)”，自由软件基金会(FSF)就此发表声明，称限制性的安全启动将会让电脑只能运行微软的操作系统，限制用户安装自由软件GNU/Linux的自由，它呼吁签名抵制。
安全启动技术初衷是防止恶意程序，防止未授权的程序启动。FSF担心微软和硬件厂商会以限制安装其它操作系统的方式实现“安全启动”，果真如此，那么它应该被称为“受限启动(Restricted Boot)”。FSF鼓励所有电脑制造商抵制采用“受限启动”，鼓励电脑用户签名声明绝不购买或推荐限制用户自由的电脑，并积极鼓动其他用户避免此类的 “监禁系统”。
--2011-10-29
几个星期前微软要求win8认证客户机支持安全启动，启动进程内的所有固件和软件都需要可信CA签名，显然微软试图锁定启动进程，阻止安装无签名的第三方系统如Linux。前不久，自由软件基金会(FSF)就此发表声明，称限制性的安全启动将会让电脑只能运行微软的操作系统，限制用户安装自由软件GNU/Linux的自由，它呼吁签名抵制(原报道)。现在Canonical 和 Red Hat 联手发布白皮书UEFI Secure Boot Impact on Linux [PDF]，由Jeremy Kerr, Matthew Garrett, and James Bottomley撰稿，呼吁所有用户应拥有Secure Boot选择权，系统商应建立一个机制让用户来配置自己认可的软件列表，PC机应包含一个应用界面允许用户轻易启用/禁用Secure boot。
“We present a set of recommendations that will allow users the freedom to choose their software, while retaining the security features of UEFI Secure Boot, and complying with open source licenses used in distributions of Linux.”
另外：Linux基金会同样也于今日发表了一份UEFI Secure Boot白皮书：Making UEFI Secure Boot Work With Open Platforms，由James Bottomley and Jonathan Corbet撰稿。
“Linux and other open operating systems will be able to take advantage of secure boot if it is implemented properly in the hardware. This document is intended to describe how the UEFI secure boot specification can be implemented to interoperate well with open systems and to avoid adversely affecting the rights of the owners of those systems while providing compliance with proprietary software vendors’ requirements.”
两份白皮书都定义了UEFI Secure Boot 规范应如何定义，以让PC正常运行自由操作系统。
--2011-11-02
开源Linux厂商Redhat及Canonical发表联合声明，要求微软Windows 8系统认证硬件保留使用Linux操作系统的权利。Linux基金会也发表一份白皮书，希望让Linux操作系统等开源代码平台可以搭配UEFI的“安全 开机”(Secure Boot)功能运作。微软规定取得Windows 8认证(Designed for Windows 8标签)的电脑必须使用UEFI介面取代BIOS，而且必需使用其Secure Boot功能。该功能可以在电脑开机时，为避免Rootkit等恶意软件控制电脑，只使用认证过的软件开机。
事实上Linux阵营也都认同微软以UEFI取代BIOS，因为这样可以让操作系统与硬件更好的兼容，在硬盘、内存、电源管理等方面都可以有更好的表现，而且Secure Boot的确可以避免使用者的设备遭恶意软件绑架。但是Linux阵营担心的是，一般使用者可能在微软限制下而无法安装Windows之外的操作系统。
Linux基金会建议硬件厂商开放Secure Boot的设定，以方便各Linux系统可以在Secure Boot机制下启动，并使用其安全机制，支援多重操作系统开机。该基金会将建立一个独立的证书颁发机构，让多个操作系统可以取得Secure Boot所需的凭证。不过该系统是否能运作的关键在于硬件厂商是否支援。电脑硬件必须能够容许使用者重新设定其Secure Boot功能的相关凭证，否则开启Secure Boot功能时，该硬件仍仅能使用预设的微软操作系统。
微软原先设定仅有硬件生产厂商可以设定Secure Boot的操作系统凭证，Linux团体建议硬件设备厂商应该提供适当的机制，让使用者拥有更大的控制权可以改变相关设定。其在九月在Build 2011展示Windows 8系统，并通过由三星生产的平板电脑发送给开发人员，该电脑就可以将Secure Boot功能关闭。微软当时也在博客中表示，使用者可以控制自己的电脑设备是否开启Secure Boot功能，尤其是想执行先前版本操作系统的用户，但认为关闭Secure Boot功能很容易遭受攻击。
Linux团体希望所有的Windows 8系统至少要保留用户开关Secure Boot功能的选项，以方便使用者安装Windows 8以外的操作系统。Windows 8预计将于明年下半年上市，支持x86/x64及ARM处理器，目前微软已经释出开发人员预览版本。
软件自由保护组织连发两篇博文：呼吁所有FOSS放弃Github
软件自由保护组织（Software Freedom Conservancy，简称 SFC）在2022年7月发布新闻稿，表示其项目不再托管到 GitHub，并呼吁其他开源社区和开发者也这样做。该组织连续发布两篇博文，呼吁所有完全免费和开源 (FOSS) 开发者放弃 Github。
访问：《Give Up GitHub: The Time Has Come!》
对于放弃 Github 的理由，SFC 提供的理由包括：
1、Copilot 是一款营利性产品
该服务由微软和他们的 GitHub 子公司开发和销售--使用人工智能（AI）技术为开发者自动生成互动代码。人工智能模型的训练（根据 GitHub 自己的声明）完全是用托管在 GitHub 上的项目，包括许多在版权许可下的许可。这些项目大多不属于“公共领域”，它们是根据 FOSS 许可证授权的。这些许可证有一些要求，包括适当的作者归属，在 copyleft 许可证的情况下，它们有时要求基于和/或包含该软件的作品必须在与先前作品相同的 copyleft 许可证下许可。一年多来，微软和 GitHub 一直无视这些许可要求。他们对这些行为的唯一辩护是他们的前首席执行官的一条Twitter，他在Twitter上谎称关于这个话题的法律问题实际上已经解决。除了法律问题，GitHub 选择使用版权代码来为创建专利软件服务，其道德影响也很严重。
2、签订营利性的软件服务合同
2020 年，社区发现 GitHub 与美国移民和海关执法局（ICE）签订了营利性的软件服务合同。包括一些 GitHub 员工在内的活动人士，两年来一直呼吁 GitHub 取消该合同。GitHub 的主要答复是，他们的母公司微软多年来向 ICE 出售 Microsoft Word，没有任何公众投诉。他们声称，这在某种程度上证明了与一个政策有问题的机构有更多的业务。无论你对 ICE 及其行为的看法如何，GitHub 对提出这一重要问题的活动家的持续轻视和虚伪的回应表明，GitHub 将其利润置于社区的关注之上。
3、托管本身就基于专利软件
虽然 GitHub 假装支持 FOSS（就像他们之前的 SourceForge 一样），但他们的整个托管网站本身就是专利和/或商业机密软件。我们很欣赏 GitHub 允许它的一些员工有时为上游项目贡献 FOSS，但我们的社区已经被那些声称支持 FOSS，同时又积极说服社区依赖他们的专有软件的公司伤害过很多次了。我们不会让 GitHub 以同样的方式烧毁我们的。
4、不 FOSS
GitHub 与 FOSS 项目托管行业的大多数同行不同，因为 GitHub 甚至不提供任何自我托管 FOSS 的选项。他们的整个代码库是秘密的。例如，虽然我们对GitLab的"社区"和"企业"版并行的商业模式有不满，但至少GitLab的社区版提供了自我托管的基本功能，而且是 100% 的 FOSS。同时，还有一些非营利性的 FOSS 托管网站，如 CodeBerg，他们将自己的平台公开开发为 FOSS。
5、复制权
长期以来，GitHub 一直试图诋毁版权保护制度。他们的各个CEO经常大声疾呼，对复制权持否定态度，包括他们的创始人（也是前CEO）在OSCON的主题演讲中专门攻击复制权和 GPL。这一点从高层渗透下来。多年来，我们亲眼看到GitHub的员工在许多场合争论不休，以说服项目避免使用复制权；我们甚至看到 GitHub 的员工直接在 GitHub 的 bug ticket 上这么做。
笔者注：2018年6月微软以75亿美元收购GitHub之时，就是GitHub开始走向终结之始。
2011年，微软85亿美元收购Skype
2013年，微软75亿美元收购Nokia
2016年，微软260亿美元收购LinkedIn
......
技术主权与生态控制的战争之Visual J++失败的思考
1996年，微软推出Visual J++ 1.0时，整个软件行业都在为Java的崛起沸腾。这种“一次编写，到处运行”的语言似乎预示着跨平台时代的降临，而微软的入局被视为对未来的重要押注。然而到了2001年，Visual J++ 6.0却成为微软历史上最短命的开发工具之一，其消亡不仅标志着一款产品的失败，更揭示了技术战争中一个永恒的真理：谁掌握技术主权，谁就掌握生态的咽喉。失败原因可小结如下：
1.技术僭越：当微软试图重构Java基因
2.法律绞杀：一场16亿美元的认知革命
3.生态反叛：开发者用脚投票的启示录
4.涅槃重生：从J++废墟里崛起的.NET哲学
5.历史的回响：当技术冷战降临新时代
本节转自2025年2月的《和码说》，感谢原作者。
一、技术僭越：当微软试图重构Java基因
在加利福尼亚州山景城的Sun Microsystems总部，工程师们最初对微软拥抱Java的态度是矛盾的。1995年Java横空出世时，Sun将其定位为对抗Windows垄断的武器，而微软的加入仿佛宿敌伸出的橄榄枝。但这种幻想很快破灭——微软从未打算做一个顺从的“生态伙伴”。Visual J++ 6.0的代码编辑器里隐藏着一个危险的秘密：在标准Java语法之下，微软悄然植入了Windows基因。
通过Windows Foundation Classes（WFC），微软创建了一套深度依赖Windows API的图形库。开发者只需拖拽控件就能快速构建界面，但这些代码一旦离开Windows平台就会变成无法运行的死代码。更激进的J/Direct技术甚至允许直接调用Windows原生API，如同在Java的血管里注入了Windows的DNA。这种技术策略的背后，是时任微软开发工具部门负责人安德斯·海尔斯伯格（Anders Hejlsberg）的清醒认知。在多年后的《Behind the Code》访谈中，他坦言：“我们意识到，把命运交给别人的技术标准等于慢性自杀。当你依赖他人的平台时，对方随时可以改变规则——就像Sun对我们做的那样。
“这种”技术僭越”直接动摇了Java的立身之本。一位曾参与Visual J++开发的工程师透露，微软内部将这种策略称为“拥抱、扩展、再灭绝”（Embrace, Extend, Extinguish）。但这一次，Sun没有坐以待毙。1997年10月，Sun以违反Java许可协议为由将微软告上法庭，指控其蓄意破坏Java跨平台特性。这场诉讼如同照向深海的手电筒，照亮了微软技术野心的真正轮廓：不是要推广Java，而是要吞噬Java。
二、法律绞杀：一场16亿美元的认知革命
当Sun的法律团队在法庭上展示Visual J++生成的.class文件时，一个残酷的现实被揭开：这些字节码只能在微软的JVM上运行，与Sun的官方实现存在系统性偏差。微软的辩护词充满技术官僚式的狡黠——他们声称“优化”是为了提升Windows用户体验。但法官最终认定，微软通过技术手段制造了事实上的“Java方言”，构成对Sun知识产权的侵犯。
2001年的和解协议像一记重锤：微软支付16亿美元赔偿，并永久退出Java工具市场。这个数字背后是更深刻的认知代价。安德斯在回忆这段历史时说：“我们以为可以通过技术优势重塑规则，但低估了生态系统的反噬力。当你站在别人的地基上盖楼时，对方随时可以抽走砖块。”这场败诉成为微软技术战略的转折点，直接催生了两个改变历史的决定：放弃对Java的改造，转而全力打造完全自主的.NET框架；将安德斯从Delphi之父转型为C#语言首席架构师。
微软的挫败暴露了一个残酷现实：在别人的技术标准框架下创新，本质是戴着镣铐跳舞。即便强如微软，也无法突破“技术主权”的铁律。正如安德斯在节目中所言：“.NET的诞生不是偶然，而是我们在Visual J++的灰烬里找到的答案——唯有完全掌控技术栈，才能避免重蹈覆辙。”
三、生态反叛：开发者用脚投票的启示录
在法庭激战的同时，另一场战争在开发者社区悄然展开。1998年的JavaOne大会上，时任Sun首席科学家的比尔·乔伊举起一本《Java语言规范》，对着台下数千名开发者说：“如果有人试图用锁链束缚Java的自由，我们就用代码打破它！” 这句话像野火般在社区蔓延。曾经被Visual J++高效开发体验吸引的程序员们开始觉醒——他们意识到自己正被诱入微软的生态陷阱。
Borland JBuilder的崛起成为这场反叛的标志。这个严格遵循Java标准、支持跨平台部署的IDE，在1999年市场份额飙升至34%，而Visual J++则从巅峰时期的28%跌至不足10%。更致命的是开源运动的兴起：2001年IBM向Eclipse基金会捐出价值4000万美元的代码，催生出完全开放、可扩展的Java开发环境。一位从Visual J++转向Eclipse的开发者回忆道：“在Eclipse里，我找回了Java的初心——自由。而微软的J++就像个黄金牢笼，看似华丽，实则禁锢。”
这种生态反叛揭示了技术产品最本质的生存法则：开发者的忠诚不属于某个公司，而属于技术本身的价值观。微软试图用Windows生态同化Java社区，却忽略了后者对“跨平台自由”的宗教式信仰。安德斯在反思时承认：“我们过分迷信技术优势，却忘记了开发者生态的‘群体意志’。这是比法律败诉更深刻的教训。”
四、涅槃重生：从J++废墟里崛起的.NET哲学
Visual J++的死亡通知书，反而成为.NET的出生证明。2000年6月，比尔·盖茨在论坛上首次披露.NET战略时，特意强调其“技术主权”属性：从CLR（公共语言运行时）到C#语言，每个环节都完全受控于微软。这种彻底的技术自主性，正是用Visual J++的失败换来的认知升级。
安德斯作为C#之父，将这种哲学注入语言设计的每个细节。C#借鉴了Java的语法简洁性，却通过委托、属性、LINQ等创新构建起独特的技术护城河。更重要的是，.NET框架从第一天起就明确服务于Windows生态——这种“光明正大”的平台绑定，反而比Visual J++的隐性控制更容易被接受。正如安德斯所说：“.NET从不伪装成跨平台救世主，我们就是要做最好的Windows开发工具。清晰的定位反而赢得了尊重。”
这种战略转向的背后，是微软对“技术主权”认知的升华。2014年，微软宣布开源.NET Core，此时的开放是基于完全自主的技术底座。这种从“控制者”到“引领者”的蜕变，与Visual J++时代形成鲜明对比。今天的微软甚至为Java提供VSCode插件支持，但这种开放已无关生死——因为.NET早已完成技术主权的筑基。
五、历史的回响：当技术冷战降临新时代
Visual J++的故事在今天的科技战争中不断重演。2019年Google与Oracle的Java API版权案、2020年Epic Games对苹果应用商店的反垄断诉讼，本质都是技术主权之争的延续。当华为被禁止使用GMS服务时，它被迫推出鸿蒙系统的路径，与微软当年转向.NET何其相似。
我们正在进入一个技术主权比任何时候都重要的时代。当大国博弈渗透到每个技术标准，企业只有两种选择：要么像.NET那样建立完全自主的栈，要么像Eclipse基金会那样构建去中心化生态。夹在中间的骑墙者，终将沦为弃子。这段话恰如其分地解释了Visual J++的命运——它诞生于微软对Java生态的骑墙策略，最终在技术主权的铁壁前撞得粉碎。
如今，当开发者用Visual Studio Code编写着跨平台的Python代码，或是在Azure云上部署Linux容器时，微软早已不是那个执着于Windows绑定的帝国。但Visual J++的教训依然如幽灵般游荡在每一行代码里：在技术的世界里，没有中立的工具，只有永恒的生态战争。而胜利永远属于那些既深谙技术本质，又懂得尊重生态规律的清醒者。
VB/VBA的解释器为何不跨平台
1、Visual Basic/VBA的解释器，才是真正继承BASIC衣钵的那一脉。大家或许对1970年代的BASIC风靡一时有所耳闻，仔细想想，那时可是大中型机当道的时代。世界上主要的操作系统，都才刚开始有想法，几乎还是一机一码的时代，为何BASIC能够独领风骚？其实，最根本的原因，便是DEC为了让BASIC在各大机器上运行，放弃了编译机制，而改用解释机制。
解释器今天叫虚拟机或运行时，可以保证在靠近人的这一端，以不变的姿态（比如源码编写和提交）应万变（不同类型的机器平台）。看看今天的JAVA、Python、.NET，就知道这是一顶好的设计，应该说BASIC也算是解释型语言的鼻祖了，可为何没能在今天的跨平台编程界留下一席之地呢？不仅其子孙VB/VBA成了业界黑户，而且在其他平台上也没能出现旗鼓相当的选手，这是为何呢？
2、回顾历史，『机缘巧合和时势造英雄』应当最为贴切。BASIC的简单易用，极大降低了计算机的使用门槛，这是它在各大机器上受欢迎的外在驱动力。而内在的，就需要程序员为各类不同的机器编写解释器，以便用户能在不同机器上以近乎相同的方式进行使用。那时的计算机硬件制造，算是百花争鸣的时代，有很多厂商都在生产，因此写解释器的生意供不应求，甚至成为一个细小的行业。
和他的伙伴，恰好处于这样的环境，写解释器成为轻资产创业的不二之选。应当说，微软的基因里一开始就是要处理不同平台的需求，对于跨平台绝对是有很深的理解的。只可惜，那时硬件性能未跟上，业界对于解释机制视若过街老鼠，对其性能表现嗤之以鼻。或许是微软认清了现实，也或许是PC的头部（英特尔）开始形成，微软于1983年，给出了编译版的BASIC。
但并未获得IBM的认可，具体原因已无从查证。IBM强迫英特尔将芯片的生产销售许可授权给AMD，让英特尔亲手扶植了一个强大的竞争对手。或许大家可从这件事里看出些端倪，那就是IBM更希望客户或供应商处于充分的竞争环境，而不是拥有垄断地位来增强对IBM的议价能力。
随着DOS系统越来越不能胜任，1989年微软开始与IBM合作研发OS/2，为放弃DOS做准备。1991年，全鼠标驱动的BASIC随Windows3.0发布，微软也最终与OS/2分道扬镳。从这里，其实可以看出大家各有各的想法，只不过微软的野望更大而已，IBM终究不过是微软壮大的营养来源。
3、JAVA崛起后，准确地说是互联网崛起后，微软的种种应对，应当都是围绕当初的野望展开的。从早期的.NET的伪跨平台，到后来的Win8霸屏的企图，微软一统江湖的心思不再躲躲藏藏。如果对PE结构有了解的细心人，就会发现，PE结构早就将微软的雄心暴露无遗了。
PE是Windows上可执行程序文件的格式，比如各种应用程序的EXE/DLL/OCX/SYS等文件，就是该采用的该结构。不得不承认，从16位到32位，再到今天的64位，PE结构极具前瞻性。大家总是很奇怪微软的兼容能力为何如此变态，甚至疑问那得堆多少屎山啊。其实，人家在架构时，早就算计了，好吧！PE结构从32到64几乎没有变动，所以64位Win上的32位应用才能左右逢源。
看看具体的，IMAGE_FILE_HEADER中的Machine，用于标识应用程序适用的CPU类型，好家伙：IntelX86和IA64系列、MIPS系列、Alpha、SH系列、ARM系列、IBM PowerPC系列、AMD系列，几乎市面上能看到的CPU都包含了。
再来看看IMAGE_OPTIONAL_HEADER32的Subsystem，用于标识应用程序运行的操作子系统，有OS/2的身影，也有Posix、CE、EFI、XBOX的身影，更别提Win11里的Linux子系统了。
从这些痕迹，大概就能判断出，微软的Windows其实想做成操作系统的母系统。
4、所以，JAVA的一处编写，处处编译运行的跨平台，在微软的字典里其实是看不上的。微软要的是一处编译，到处运行的大一统。或者说，微软压根就认为，跨平台是系统的事，而非应用程序层面的事。
看看在这一概念下，微软干了些什么？微软在Win10出了ARM版，完美兼容Office等Win32应用，VB/VBA也可以运行在ARM芯片上。微软在Win11出了Linux版，2025年第一季度微软再次宣布会在Win11中全面优化Win32，相信不久Win32应用就可以跑起来了。所以，VB/VBA的解释器，就不太可能出海！很多事情，也就可以得到解释了。
该文章最后由 阿炯 于 2025-04-25 09:43:53 更新，目前是第 3 版。