Windows源代码泄露全景报道[转]
| /*W$最高机密—Miuqoms 98 源代码*/ ………… while(!CRASHED) /*如果不崩溃*/ { display_copyright_message(); /*显示版权信息*/ display_bill_rules_message(); /*显示比尔的规则信息*/ do_nothing_loop(); /*进行空循环*/ if (first_time_installation) /*如果是第一次安装*/ { make_50_megabyte_swapfile(); /*创建50M的交换文件*/ do_nothing_loop(); /*进行空循环*/ totally_screw_up_HPFS_file_system(); /*将HPFS文件系统完全搞乱*/ search_and_destroy_the_rest_of_OS/2(); /*搜寻并删除OS/2的所有残余信息*/ hang_system(); /*挂起系统*/ } ………… enn(); /*蓝屏*/ } |
如果说这只是曾经在Internet上广为流传的一则恶作剧，那这一次，微软帝国的“双子塔”确是真真实实的被恐怖分子给“炸”了！
微软遭遇“9.11”
2004年2月12日，也许是一个永远被载入IT发展历史的日子，因为在这一天互联网上爆炸性地传出了一条关于微软的消息——Windows 2000和Windows NT 4.0部分源代码泄露了！一时间各式各样相关的新闻和传言在互联网上迅速传播开来，各大网站都在第一时间将这一消息作为头条向外界公布。最早出现相关消息的BetaNews网站以及转载此消息的Neowin社区和Slashdot社区都人满为患，与此相关的议论呈几何级数增长；而被泄露出来的源代码副本则在一些P2P网络和 聊天室里进一步被秘密地散发。
微软在美国当地时间12日下午证实了相关消息的真实性。微软公司发言人汤姆·皮拉（Tom Pilla）对外界表示说：“今天，我们发现Windows 2000和NT 4.0的部分源代码非法地出现在互联网上。”他警告说，任何第三方传播这些源代码都是非法的行为，微软将对此采取严肃行动。皮拉还表示，现在还不能确定到底泄露了多少源代码，也不能确定泄露途径，美国联邦调查局（FBI）已经对此展开了调查。没有迹象表明泄露事件是由于微软公司的内部网络存在安全漏洞，被非法入侵所造成的。
这一消息也迅速影响到微软的股票，股价一度下挫。
据本刊了解，被泄露的Windows 2000和NT 4.0的源代码大小分别为203兆和229兆，是压缩包，解压之后约相当于一张普通光盘的大小。Windows 2000被泄露的源代码共有30915个文件，约有1，350万行代码。文件的时间戳是2000年7月25日，其中还包括了Windows 2000 SP1的部分代码。一些著名安全专家对这些文件进行研究后表示，文件中的代码并不完整，整个源代码应该在40GB左右，泄密文件仅仅是完整代码其中的一小部分。
追查线索来自“core dump”文件，或称核心文件(core file)，其中包含了一个错误报告(error report)，可能是在Unix测试编辑器vi运行出错时产生的。当程序在Unix操作系统中运行出现故障时，系统就会自动产生一个错误报告，错误报告将记录下出现问题时系统内存的情况。
| The actual strings which confirm this: PWD=/usr/ms/win2k_sp1/private/security/msv_sspi DOMAIN=mainsoft.com [email protected] ORGANIZATION=Mainsoft Co. Ltd. MWBATCH_SERVER=lod:8000 MSOFTLM_HOST=@xor MAINSOFTLM_HOST=@xor XAPPLRESDIR=/il2/users/eyala/app-defaults EDITOR=vi BASE_LIBPATH=/usr/lib Source: Post on Slashdot |
2月13日，又一个戏剧性的消息出现在互联网上——泄露的源代码并非出自微软，而应该是来自微软的长期合作伙伴Mainsoft公司！
据BetaNews当天的报道，这一线索是由一些独立侦探找到的，他们抢在联邦调查局之前找到了这些源代码泄露的源头——他们在研究网络上流传的源代码时发现在泄露的30915个文件中有一个错误报告，其中出现了Mainsoft的技术主管伊尔·阿拉鲁夫(Eyal Alaluf)的电子邮箱地址。因此他们断定泄露的源代码并非出自微软，而应该是来自微软的长期合作伙伴Mainsoft公司。而且很明显是从Mainsoft用于软件开发的一台Linux电脑中丢失的。
Mainsoft公司当天向外界证实目前正在对此事进行调查，以确定该公司是否与Windows源代码泄露事件有关。不过，微软没有对源代码泄露是否涉及Mainsoft作出评论，也未提供有关调查的详细资料。
舆论认为，尽管泄露出来的错误报告显示这段泄露代码来自“Mainsoft”，但是并不能说明这部分源代码是由该公司泄露出去的。可能是“黑客”通过入侵该公司的网络从而获得这部分源代码，然后散布到互联网上；另外，也有可能是该公司在抛弃存有这部分源代码的计算机时并没有对硬盘进行彻底格式化处理，从而导致源代码泄露。
Mainsoft公司介绍
总部位于加州圣荷西市的Mainsoft公司是微软公司的主要合作伙伴，1994年就同微软签订了授权协议，有权访问Windows源代码。微软于2001年实施共享代码计划之前，只有两家公司可以在微软的Windows接口源环境(WISE)计划下获得Windows源代码，Mainsoft便是其中之一。WISE计划的目的是要帮助软件开发人员使用Windows的API编写应用软件，并将它们部署到Unix操作系统中。
泄露的源代码就是Mainsoft通过微软许可用于开发在Unix上运行的Windows程序的MainWin产品的。利用这些代码可以开发Unix版本的Windows应用程序，如“IE浏览器”、“Outlook邮件”和“Windows Media Player”等。Mainsoft称，该公司已经在MainWin中使用了数百万行未经改动的Windows代码。
微软公司声明（2月18日，2004年，太平洋标准时间，上午9点）Redmond(美国微软总部)，2004年2月18日，本周四 ，微软在互联网上发现非法传播的一部分不完整的Windows 2000和Windows NT4产品代码。我们的调查表明，该事件并非是由微软企业网被恶意攻击造成的，也不是内部信息安全的疏漏，也与源代码共享计划以及政府安全计划无关，这些计划是让客户、合作伙伴、和政府单位合法地察看微软的源代码。
微软正继续与美国联邦调查局密切合作，对该非法行为展开调查。微软的源代码是拥有版权并且作为商业秘密是被保护的。此种将微软的源代码发布出来，提供给第三方，或是将其下载、使用的行为都是非法的。微软会采取所有适当的法律行动来保护我们的知识产权。这些行动包括直接或间接地与那些将这些非法传播的源代码拥有、寻求拥有、传播、下载或共享的人进行沟通。
尤其需要指出，微软正在通过信件向那些已经下载了这些代码的个人进行解释，告诫他们，这样的行为是违法的。另外，微软已经对一些发生非法共享这些源代码的对等网客户机制定了警报。这些警报会通知那些试图通过对这些网络专门的搜索来定位和下载这些源代码，这些人的行为是违法的。
任何关于正在进行的调查的问题应该咨询美国联邦调查局……
狼来了！
2月16日，有国外网站报道第一个基于泄露源代码的IE5.0版本漏洞被发现。本刊获悉，有关上述漏洞的信息是一位不知名的安全专家首先在几份安全邮件列表上发表的。该漏洞仅存在于IE 5.01，入侵者可以借此伪造一个Web服务器或者利用有毒邮件来设置一个URL链接，若用户点击便会触发攻击，造成拥塞并激活任意代码。不过目前的统计数字表明，只有不到10%的互联网用户仍在使用有问题的旧版IE。微软证实了上述说法并表示正在对问题进行调查。“这个漏洞不会对IE6造成影响”，微软安全部门经理Mike Reavey说，“不过这看起来好像是在我们的代码里面发现的。”
这个消息引起了广泛的关注，因为这个漏洞的发现证明了可以通过研究被泄露的Windows源代码来找出微软各类产品里面所存在的漏洞。而且这两个200MB大小的源代码文件已经在文件交换者和安全专家之间广泛流传，微软似乎无力阻止这一事态的发展。
几家欢乐几家愁
2月18日，微软公司发表声明警告那些拥有泄露出来的源代码的社区论坛尽快撤掉泄露的源代码相关内容。并且已经向部分从网上下载了泄露源代码的个人发出了律师函，警告他们这种行为违反了版权法。
另据法律专家表示，除了非法获得源代码者以外，其他已经下载了源代码的个人——尤其是开发人员，可能面临别的麻烦，因为私自查看Windows源代码的个人将可能被指控侵害商业秘密和软件专利权。不过微软并没有对业界一些程序员提出的特别问题发表意见。
泄露的代码对Linux是否具有借鉴价值，开源专家表示即使所有的代码泄露了，那对Linux意义也不大，因为Linux和Windows是不同的体系。
而来自开源社区的多篇文章指出，开源社区的开发人员如果染指微软这些被非法泄露的源代码，将有可能使自身处于一个非常危险的位置——除了研究和直接引用这些代码有可能被微软控告之外，更重要的是将可能对开源项目产生极其不利的影响。文章以Samba为例，假设一名参与Samba项目的程序员被证实看过Windows代码，按照“净室”原则，此人写过的Samba代码都将要被剔除和取代，而且这名志愿者或许还要被逼离开团队，让一名没有看过Windows代码，同时也没看过Samba代码的程序员来代替他的位置。而要找一名符合这样条件的程序员并不容易，这将会对整个项目带来难以估量的损失。
以SCO状告Linux社区事件为鉴，如果将来某一天，微软也象SCO那样状告Linux社区，法官们对于出现在Linux里面和Windows相似的代码将很难作出正确的判断。“微软代码泄露”这一事件，将会为微软在法庭证词上带来有利的方面。
何不走向开源之路？
Windows部分源代码泄露事件，使得微软必须重新考虑如何让开发者、合作伙伴以及用户查看源代码的同时保护其知识产权。尽管2月12日的源代码泄露事故不会改变微软通过其共享源代码以及政府安全程序的共享方式，业界观察人士及用户均希望微软能从此次泄露事故中吸取教训并在可能的情况下考虑开源概念带来的利益。
Microsoft-Watch.com 发表的一篇名为“Why Microsoft Should Open Source the Leaked Source”的评论建议，既然微软的Windows 2000和Windows NT 4.0产品的(部分)源代码已经泄露，就应该顺势将其开源。文章指出，微软如果允许开发人员、学者和专业技术人员帮助修改错误并帮助微软增进产品质量的话，这将解决很多长期的安全问题并增加一些简单但是非开源软件仍然未实现的功能。同时，如果微软将这些代码开放，这将有助于软件安全公司，以及安全开发人员更好的了解Windows的安全漏洞和结构。此外，允许Unix/Linux开发人员使用真正的Windows源代码进行开发和测试，将Win32 API、NTFS文件系统、SMB协议等Windows产物自然地融入到Unix/Linux的系统环境中。这将带来全新的网络和操作系统之间的兼容能力。人们将会看到软件移植将更快的在开源的Windows和Unix/Linux等操作系统之间进行。
微软实际上是自己最大的竞争者。公开Windows的源代码，会让微软的触角伸至以往无法触及的领域。
微软究竟泄露了什么？
操作系统可以说是世界上最复杂的软件之一。一般来说， 操作系统最核心的部分（或模块）包括进程管理、存储（内存和外存）管理、设备管理等，这些部分合起来称为“操作系统内核”。内核是操作系统的灵魂，它实际上是抽象的资源操作到具体硬件操作细节之间的一个接口。另外，还有一些比较重要的部分包括I/O管理、文件系统、网络以及外设等。
操作系统许多部分都是相互关联的，如果按照分层的观点来看，其中一些模块和功能是被其它模块调用或者为其它模块来提供服务的，如：如文件系统管理－设备管理模块－设备驱动程序。
如果将windows2000操作系统进行分层，则可以简单地划分为：用户界面、应用程序、作业管理、文件管理、输入输出（I/O）管理、进程通信、存储管理、处理器管理，最后是对各种硬件设备的操作。所有这些功能模块会对应到成千上万个按照一定方式组织在一起的源代码文件。
简化的Windows2000体系结构
各功能模块之间能够相互调用的前提是需要知道被调用模块的接口，以及传入参数、返回值等。所以即便有人获取了其中某几个模块的源代码，还是无法真正获取这个操作系统，更不可能根据这些泄露的部分源代码，来写一个操作系统或者上面的某个应用。
从这个角度说，只有获取了某个操作系统内核的所有源代码，才算真正获取了这个操作系统。
NT操作系统体系结构
上面给出了这次泄露事件中所涉及的两个操作系统的简单体系结构。根据当年Windows 2000产品发布时，Windows业务部高级副总裁Brian Valentine 和项目经理 Iain McDonald介绍的情况来看，有超过2500个开发人员参与了核心系统的开发，再加上一些外围的服务协助人员，总人数多达5000人。投入如此巨大的人力、物力、财力和如此长的时间开发出的软件，微软当然会视其为珍宝。
那么，在这次源码泄露事件中，微软究竟泄露了哪些东西？其重要程度又如何呢？这可以说是开发者真正关心的问题。笔者带着这些疑问，采访了一些研究过源代码的技术人员和不愿署名的专家。
根据记者所了解到的情况，解压后的622M的Windows 2000操作系统源代码共包含30,915个文件。
文件包解压后可以看到3个文件夹和一个索引文件“index”，索引文件中写明了包含的所有文件的文件名及其目录结构。
其中，比较重要的文件夹是“private”，此次泄露的一些重要源代码文件都在这个文件夹下，在以下的子文件夹中，包含了开发者普遍感兴趣的代码。从文件夹的组织和命名上，基本能够看出这些文件夹下的源代码的功能。
许多网友认为，比较重要的子文件夹有net、inet以及ntos等。在net文件夹中，居然包含有sockets及snmp的实现的代码。更引人注目的是ntos文件夹下的代码：
有网友认为，这就是操作系统的部分核心代码（即内核），如文件夹mm，就可能是内存管理模块的代码。
从整个“private”文件夹下的文件内容可以看出，Windows 2000操作系统最核心的部分应该没有泄露，大部分是一些诸如eventlog、regedit、taskmgr等程序。
在“eventlog”文件夹下，有个readme.txt的文本文件，里面描述了在eventlog项目中每一个文件的内容，除了test和enumsvc目录，都包含有测试程序。
还有些文件夹下的文本文件中，包含了十分重要的在开发过程中的一些bug信息和需要解决的问题，如在../private/shell/ 文件夹下的wontfix.txt文件中，记录了在一些应用中暂时还无法解决的和IE40的兼容性问题的列表，并给出了原因，可以猜测是希望解决的Bug问题列表。
从这些有趣的文件中，我们可以一窥当年微软程序员在编程或测试时遇到的问题。但是，从源代码中可以发现，许多问题的产生主要源于他们需要兼顾硬件成本、软件成本以及向后兼容性。
此外，在这些文件夹中，人们发现了很多gnumakefile文件，这是因为这些文件是Mainsoft公司用来开发Windows程序的Unix版本用的，所以里面会有这些文件。
这里面， 还可以发现一些名称非常有意思的文件/目录:
../private/genx/shell/gnumakefile
../private/genx/windows/inc/mobileq-apache.eml
../private/genx/letter to children - 2.eml (*)
../private/inet/mshtml/btools/bin/words of wisdom from dennis.eml
../private/inet/mshtml/build/ppcmac/ship/unix.e ml
../private/inet/mshtml/build/ppcmac/documentati on of problems in stress.eml
../private/inet/urlmon/iapp/gnumakefile
../private/inet/urlmon/mon/gnumakefile
../private/inet/xml/xml/tokenizer/parser/gnumak efile
../private/inet/xml/xml/tokenizer/dll/words of wisdom from dennis.eml
../private/inet/xml/xml/dso/letter to children - 2.eml
../private/inet/mshtml/gnumakefile
../private/inet/mshtml/tools/mips/utils/sed.exe
../private/ntos/w32/ntuser/kernel/
……
由于众所周知的原因，我们不便继续往下分析。但从上面给出的信息，大家可以大致了解这些源代码的组织方式和目录结构。
采访过程中，据一些深入研究过代码的专家介绍，源码不全，很多缺少头文件或库，但可以肯定，绝对是货真价实的源码。至于想拿这些代码去编译出一个完整的Windows当然是不可能的，因为许多核心的头文件都不存在，那些文件应该存在于微软的开发平台上，只有他们内部使用， 而一般人是见不到的。
“整个源代码基本上是用C、C++、ASM写的，有很多有意思的东西，比如Sol.c就是那个单人纸牌的source code。”
还有人声称，他已编译出几个小应用程序，和Windows 2000自带的程序比较，没看出明显差别，只不过都是英文版。还有网友把资源包从中文版Windows 2000里直接导出来，放在源码里编译生成中文版的计算器软件。
由于年代久远，在这些源代码中还发现有1989、1991年的代码，而且大部分代码都是C写的，只有少部分的C++和汇编(只在ntos中出现，大部分在io中使用)写的代码。
一些网友表示，从代码中至少可以学习好多微软高手的编程方法或者编程思想，的确感觉出自高人之手 。另外，有一些初始化代码，如：init386.c中的初始化硬件代码以及其它模块下的初始化源代码文件等，都非常有研究价值。代码的质量是非常不错的，模块设计小巧而紧凑，注释也非常清楚明了，直接表明了这块代码的作用和意图。
下面是某个模块代码前的注释：
/*++
Copyright (c) 1993 Microsoft Corporation
Module Name:
kiinit.c
Abstract:
This module implements architecture independent kernel initialization.
Author:
David N. Cutler 11-May-1993
Environment:
Kernel mode only.
Revision History:
--*/
有程序员表示，泄露的代码对每一个稍有水平Windows程序员都有极大的帮助，对中国程序员也是极大的促进。一位研究过代码的程序员甚至激动的说：“……我不得不再一次告诉大家，C语言依然是最NB的语言。新技术只是市场宣传的噱头……”
同时，一些专家表示，这些代码所带来的安全性威胁并不大。微软确实在明显的地方都检查了缓冲区溢出的可能性。更何况，这次泄露的源代码并不多，因此微软可以很容易检查其中可能暴露出的所有代码缺陷。如果是一个大的应用程序源码泄露，那造成的威胁就大得多了。而且，这些代码都是大约4年以前的代码，即便是有一些明显的问题，现在也应该补得差不多了。
但是，很多研究过源代码的网友却表示并不赞同。程序员晓辉（化名）说：“我仔细研究了在net、inet、ntos几个文件夹下的源码，觉得并不会像专家说的那么简单。反正我感觉非常恐怖，基本上Shell、snmp、socket的协议层，还有上层所有的应用程序代码基本上都有了。有了这些，估计很快病毒要大肆虐了。因为黑客对这些代码只要稍加研究，就可以对其工作机制一清二楚，我想他们会很容易找出这些代码的破绽。”他还表示，“最有可能出现的病毒和攻击，很可能来自于网络协议这块的代码。”
当然，这种说法还需要推敲，Linux操作系统的代码也是完全公开的，并未发现太多的攻击是由于公开源码。但是，对于处在黑客们虎视眈眈的目光下的微软操作系统来说，情况也许就大不一样了。
这次大规模泄密事件对微软的打击可能是致命的，微软多年以来的知识积累和安全信誉都受到影响，对于知识产权的保护来说实在是一件令人痛心的事情。并且这么大规模的泄露即便能够追查出源头，也难以控制其传播，正如一个国外的程序员所说的，“只要有机会，谁不会下载下来看看呢？”
记者就此事采访一位在北京某高校计算机系从事多年操作系统教学的老师时，他表示，“首先说明，在我多年的教学实践中，我一直是以Linux作为操作系统课程的教学实例的，教授学生分析和认识Linux的内核源代码，从中理解操作系统设计的方法和原理。这次泄露出来的代码，有一些学生下载后，拿给我看了，我并不认为他们的代码比Linux高明到哪里去，很明显，大部分人是抱着一种神秘和好奇的心态来看这个的。如果你真的想去花时间认真研究操作系统的话，我劝你还不如去读Linux的源代码，那个要完整并且容易得多！”
此次代码泄露的影响将是深远的，许多影响短时间内可能还无法估量，但有一点可以肯定，微软今后一定会加强安全保密措施更严格地看管自己的代码。
有一种说法，世界上最有价值的商业机密是什么？一个是“可口可乐的配方”，另一个是“微软操作系统的源代码”。其实，即便你拿到了可口可乐的配方，并生产出了跟可口可乐味道完全一样的饮料，你也不可能成为另一家可口可乐公司。同样，即便你拿到了微软所有系统的源代码，你仍然成不了微软，不是吗？
无法抵赖的尴尬？——微软操作系统Windows 2000源代码初窥
随着Windows 2000和NT部分泄露源代码的进一步流传，国内外（特别是国外）在网上发表的分析微软操作系统源代码的帖子愈发多了起来。
有一篇在国外网上署名Selznak发表的分析微软泄露源代码的文章非常有趣，它并不是选择源代码的功能来研究，而是研究了微软程序员留在代码中的一些注释。我们在这里节选文章的部分内容以飨读者：
这里主要讨论Windows 2000的源代码，泄露出来的源码据说占到了完整源代码总数的15％。里面包含winsock和inet等网络方面的代码，以及一些shell相关的代码。另外还包含一些开发者比较熟悉的如事件日志，一些默认的屏保程序的代码等。
这些文件的时间戳普遍都标明是2000年7月25日。代码包含在一个大小为213,748,207 bytes 的zip文件中（文件名是windows_2000_source_code.zip），已经在网上通过P2P网络广泛流传。令人啼笑皆非的是，一些相同大小的虚假的文件也在网上传播，解压后，你会发现里面只有一长串的0。
在看过源代码的人当中，有一些人认为，虽然绝大部分的代码的确出自微软，但是这些代码的某些注释（我们下文要详细分析这些有趣的注释）被篡改过，好像故意为了让微软难堪。我个人认为这种推断是毫无根据的。试想，让这些令人尴尬的注释真实地出现在成千上万行的代码当中，不是一件容易的事情；另外，谁又会冒着被控告的危险来专门做这件事情呢？
微软的尴尬？
在项目的最后期限即将到来时，几乎所有苦苦挣扎的程序员都会留下一些他们以后可能后悔的注释和评论，包括诅咒其工作，以及对其它模块的代码和需求的尖酸刻薄的评论。当然，也有负责任的程序员加入了一些突出的注释以便告诉其它人这个代码的关键部分。包含了像“UGLY TERRIBLE HACK”这样注释的代码，其实是优秀的代码，因为在糟糕的代码中，恶心的技巧被认为是理所当然的。
因此，故意寻找这些注释中令人尴尬的部分是伪善和毫无意义的。但是，在我们分析这些注释的过程当中，会发现这的确又是一件非常有趣的事情。
诅咒以及骂人的粗话：在注释中，你可以看到许多诸如“fucks”和“shits”这样的词，以及好几百个“craps”这样的词。一些是对编译器的抱怨，还有一些涉及到微软著名的日常build过程（如右）。
也有各种提及到“白痴”和“傻瓜”（idiots and morons）的地方，一些是针对外部的程序，一些则针对微软内部代码。在文件private/ntos/rtl/heap.c（标注日期是1989年）中，有这样的注释：
// The specific idiot in this case is Office95, which likes
// to free a random pointer when you start Word95 from a 、、// desktop shortcut.
（在这种情形下最白痴的是Office95，因为当你从桌面快捷方式启动Word95时，它可能释放一个随机指针）
另一个时间戳是1991年7月11号的文件private/ntos/w32/ntuser/kernel/swp.c中有如下的注释：
* for idiots like MS-Access 2.0 who SetWindowPos( SWP_BOZO
* and blow away themselves on the shell, then lets
* just ignore their plea to be removed from the tray
（MS Access 2.0居然调用SetWindowPos(SWP_BOZO，然后把自己从shell中清除。对于这种白痴程序，干脆眼不见心不烦)
“低能者”这样的词语也大量存在，例如在以下挑选出的源代码文件中：
private/genx/shell/inc/prsht.w:
// we are such morons. Wiz97 underwent a redesign between IE4 and IE5 （我们是如此低能，Wiz97已经遭受从新设计，在IE4和IE5之间）
private/shell/ext/ftp/ftpdrop.cpp:
//We have to do this only because Exchange is a moron.(我们不得不做这个，仅仅因为Exchange完全是一个“低能者”)
private/shell/shdoc401/unicpp/desktop.cpp:
// We are morons. We changed the IDeskTray interface between IE4 （我们真是低能，我们改变了连接IE4的IdeskTray接口）
private/shell/browseui/itbar.cpp:
// should be fixed in the apps themselves. Morons!
（他们自己应该在应用中打上补丁，低能！）
虽然微软的程序员在源代码中的涂鸦到了令人吃惊的地步，但这些话语还是不会太过于出格。在这些注释当中，你很难发现有明确的贬损微软和Windows操作系统的话。Bill Gates几乎没有被提及。没有种族主义或异口同声的指责和贬损，仅仅是一些个人化的语言。
如，在文件private/shell/ext/tweakui/genthunk.c中的以下注释:
* CallProc32W is insane. It's a variadic function that uses
* the pascal calling convention. (It probably makes more sense when you're stoned.
（CallProc32W调用是极其愚蠢的，这是一个使用了pascal调用习惯的函数，只有当你喝醉酒时，它可能才会起些作用！）
微软程序员也尽责认真地在代码中明示代码的关键部分给其它人。有超过4,000个地方涉及到“hacks”(技巧)，大部分是通告，包括以下部分，如：
在文件private/inet/mshtml/src/core/cdbase/baseprop.cxx:中
// HACK! HACK! HACK! (MohanB) In order to fix #64710 at this very late
在文件private/inet/mshtml/src/core/cdutil/genutil.cxx:中有
// HACK HACK HACK. REMOVE THIS ONCE MARLETT IS AROUND
诅咒以及骂人的粗话
对编译器的抱怨，如：在private/shell/shell32/util.cpp的这个文件中 ：
// the fucking alpha cpp compiler seems to fuck up the goddam（讨厌的） type
"LPITEMIDLIST", so to work
// around the fucking piece of shit compiler we pass the last param as an void *instead
of a LPITEMIDLIST
使用未被公开函数
在源文件private/mvdm/wow32/wcntl32.c中的注释:
// These undocumented messages are used by Excel 5.0
（这些未公开的信息被EXCEL 5.0所使用）
如，在源文件private/mvdm/wow32/wgdi31.c中的注释:
// InquireVisRgn is an undocumented Win 3.1 API. This code has been
// suggested by ChuckWh. If this does not fix the s 2.0
// problem, then ChuckWh would be providing us with an private entry
// point.
（InquireVisRgn是一个未公开的API，使用于Windows 3.1。这个函数由ChuckWh所调用，如果这个代码中存在的问题（s 2.0 problem）没有被更正，那么，ChuckWh就能给我们一个后门。）
在源文件private/mvdm/wow32/wgfont.c中的注释:
* This thunk implements the undocumented Win3.0 and Win3.1 API
* GetCurLogFont (GDI.411). Symantec QA4.0 uses it.
* To implement this undocumented API we will use the NT undocumented API
（这些代码在Win 3.0和3.1 API中。
GetCurLogFont (GDI.411). Symantec QA4.0 使用了它们.
要实现这些未公开的API，我们必须使用NT未公开的API。）
使用未被公开函数
private/ntos/w32/ntuser/kernel/mnpopup.c:
// Set the GlobalPopupMenu variable so that EndMenu works for popupmenus so
// that WinWart II people can continue to abuse undocumented functions.
（设置了GlobalPopupMenu变量供EndMenu函数使用，这个函数是用于实现弹出式菜单的。
看到这些代码，玩WinWart II的人一定又开始谴责未公开的函数。）
比如在文件private/windows/shell/accesory/hypertrm/emu/minitel.c:中出现的注释：
// Guess what? Latent background color is always adopted for mosaics.
// This is a major undocumented find...
（猜猜这是什么？隐藏的背景色值与mosaics的一样。这一个重大的未被记录和公开的发现…）
private/windows/shell/accesory/hypertrm/emu/minitelf.c:
// Ah, the life of the undocumented. The documentation says
// that this guys does not validate, colors, act as a delimiter
// and fills with spaces. Wrong. It does validate the color.
// As such its a delimiter. If...
（哈，没有被文档化！文档里说，这个家伙没有核查颜色，跟分隔符一样，然后用空格填充。胡扯！明明核查了颜色...明明核查了颜色...）
在文件private/inet/mshtml/src/other/moniker/resprot.cxx:中
//
goto EndHack;
//
如，在文件private/inet/mshtml/src/site/layout/flowlyt.cxx:中
// God, I hate this hack ... （上帝啊，我恨这些“技巧”！）
在文件private/inet/wininet/urlcache/cachecfg.cxx:中
// Dumb hack for back compat. *sigh*
在文件private/inet/wininet/urlcache/filemgr.cxx:中
// ACHTUNG!!! this is a special hack for IBM antivirus software
在文件private/ispu/pkitrust/trustui/acuictl.cpp中:
// HACK ALERT, believe it or not there is no way to get the
// height of the current HACK ON TOP OF HACK ALERT,
在文件private/ntos/w32/ntuser/client/dlgmgr.c中:
// HACK OF DEATH:
在文件private/shell/lib/util.cpp中:
// TERRIBLE HORRIBLE NO GOOD VERY BAD HACK
（糟糕的令人厌烦的毫无用处的技巧）
在文件private/ntos/w32/ntuser/client/nt6/user.h中:
* The magnitude of this hack compares favorably with that of the national debt.
（这种hack技巧的数量几乎可以和国债的数量相比。）
代码质量
尽管有上面所讲到的这些东西，但是代码的质量的确是极为优异的。模块很小，过程也是大小适中,代码的意图非常详尽，没有陷入诸如“从1加到i”这样的循环冗余之中。代码中的注释风格多种多样，有时注释代码块用“//”的方式，有时又用“/* */”的形式。在一些模块中，有的函数有其历史记录，另外一些又没有。有些函数在注释块中描述它们的变量，有些函数则没有。看来，微软并没有掉入强制执行过分严格的标准或广泛使用过于复杂的自动工具的陷阱之中。微软看来很相信他们的程序员能把注释写好，事实上是，他们的程序员做到了。
然而，不是一切都是完美的，如前面提到的，一些模块很明显的受损于这些矫揉造作的技巧。那些在MSInet控件刚刚发布就被迫将之运用在代码中并努力使之正常运作而受尽折磨的程序员，会像我一样为发现这是由于inet糟糕的代码所导致而如释重负。
从注释中，显然可以看出，大多数出现“uglier hacks”（丑陋的技巧）的地方是兼容性问题：既有向后兼容，也有硬件兼容或是特殊的软件所带来的问题。为了达到强大的兼容能力微软显然花费了很大的代价，这些都体现在程序员的汗水和优美的代码当中（因此具备相当的稳定性和可维护性）。
关于微软依赖于偷来的开放源代码的谣言广为流传，同时此谣言又受到广泛的置疑。微软有成千上万行的代码，很多代码是非常特殊的，这些代码很难从偷来的代码中受益：它们看起来也并不值得去冒触犯法律的危险。
微软早期版本的TCP/IP栈都是(合法的)取自BSD。不过这是很久以前的事了，当时微软还非常弱小。
如果在代码中同时搜索“linux”或“GPL”，不会找到任何的参考信息。搜索“BSD”仅会发现一些符合BSD约定的串。搜“GNU”会发现一些位于private/ genx/shell中关于GNUmakefile的参考信息，那里依次提到“mode for Emacs”。这些显然是合法的，仅仅用到了makefile，而且没有在最终代码中涉及到版权。
因此粗看代码，没有证据显示微软违反了GPL或是偷窃了别的开源代码。或许更仔细的检查能得到进一步的信息。
偏爱
值得注意的是，许多“hack”技巧都参考过其它一些独立开发的程序。在某些情况下这些程序是微软之外的公司开发的。例如：Borland开发编译器时发现了一个微软代码存在的BUG，他们就编写了一个补丁来弥补这个漏洞。但更多的这种补丁是由微软自己开发的。似乎存在着这样一种非正式的提供补丁程序的顺序关系：首先当然是微软，接着是独立的软件公司如IBM和Borland。
很有趣的是，在这些注释当中，我们终于看到了微软“声名狼藉”的“未公开特性”。其实微软应用程序的开发者很早就开始利用这些资料了（见“使用未被公开函数”中注释）。
担忧及其它？
既然提到微软的应用程序中使用了大量未公开的Windows函数，就有必要提及这样一个事实：近十几年来，微软一直受到美国联邦贸易委员会（FTC）的调查，以确定微软提供的操作系统软件的角色是否会使它在应用程序市场上取得不平等的优势。这就是当年所提及的微软操作系统和应用软件开发内部的“长城”问题，实际上，在微软内部，“长城”是不存在的，它只是横亘在其它软件公司和微软的操作系统之间。正是因为“长城”的存在，才使得微软的应用软件有了比其它公司开发的Windows软件更好的不平等的竞争优势。
可笑的是，十几年前，微软的雇员们一概否认自己的应用程序使用了未公开函数。时至今天，这已经成了一件众所周知的不争事实。微软方面也通过不断修改Windows许可协议来改善这种备受怀疑和指责的状况。比如，在2002年8月份，微软公司开始对外授权使用Windows的113个内部通讯协议；同年8月28日公布272个原先未曾披露的用来确保第三方软件与Windows兼容的应用编程接口（API）等。
这次的源代码泄露，微软是否还有这样的担忧，那就是，人们通过分析其源代码，又找到了有关这一方面新的不利于微软的证据，从而指责微软的垄断和不正当竞争呢？当然，这将是一个有趣的陷阱，如果你找到了控告微软的证据，微软也会先控告你，非法偷看和使用受法律保护的商业机密。
从另外一方面讲，即便有人偷看研究了微软的源代码，然后将它使用在其它软件中，微软是否就有足够的证据来控告别人呢？这里，笔者马上联想起发生在十几年前的“Geary事件”，这是微软同一个优秀的Windows程序员Micheal Geary之间的一场争论。当年微软控告Adobe的Michael Geary（当时在Adobe Type Manager工作），因为他描述了GDI中Microsoft的CreateDC()函数的一些实现细节（修改了某个GDI入口点使ATM能够移植Windows中），微软负责开发的人员认为，进行这一改动的只能是对Windows 3.0内部知识非常熟悉的人，于是微软指责他泄露了其商业秘密，研究过Windows的源码（微软认为Geary在为Cooper Software工作时，有机会得到这些不应得到的知识）。
实际上，揭示CreateDC()的实现方法根本算不上什么尖端技术，任何一个从事过Windows编程的人，只需要考虑几分钟就够了，根本不用非法偷看GDI的源代码。
有趣的是，在Windows3.1中，CreateDC()被微软重新实现了，目的就是防止ATM修改GDI。
Geary事件的意义就在于，有时并不需要得到Windows源代码，也一样能够认识Windows的内部（通过合法的“逆向工程”等）。
结论
微软担心这些代码会被竞争对手所利用，其实这也是缺乏根据的。对于应用程序，这的确是个威胁，但很难指望微软操作系统的竞争对手能利用它。就凭Apple和Linux现在所拥有的地位，都使它们不会去偷窃别人的代码，即使这些代码对他们来说的确是有用的。
简言之，这次源码泄露没什么值得惊奇的。微软从不使用开源的代码，他们的早期代码有时显得很古怪，但现在的代码是极优秀的。微软的程序员具有高度专业的技能，并拥有很高的热情。许多问题的产生主要源于他们需要兼顾硬件成本、软件成本以及向后的兼容性。