你好，奥卡斯战壕的人-yiteyi-C++库

null

你好！我的名字叫Martyn Lovell，我是VisualC++图书馆团队的开发领头羊。你可能看过我的博客

之前，（尽管我似乎从来没有足够的规律）。你最近也可能在电视上看到我第9频道 . 我想给大家一个关于我的团队目前正在关注的事情的快速更新[你应该在接下来的几周里看到他们中许多人的博客文章]。记住，我在这里讨论的东西还没有达到我们需要的质量，所以在我们发货之前，东西可能会改变或消失。

我们正处于奥卡斯的第一个发展里程碑。如果你是一个狂热的博客读者，你可能已经听说我们这次运行的开发过程有点不同，为了更加敏捷。我们把每一项功能都放在自己的“功能分支”中，在那里它必须一直存在，直到达到一个没有已知错误的标准，并且更接近可以发布的标准。一小部分开发人员/测试人员和其他人专注于这个特性，直到它完成为止（我们称他们为‘特性团队’），我们希望这能保持我们的运输分支机构有更高的质量，同时也确保在我们知道它们的状态足够好，不会延迟我们的发布之前，它们不会进入产品。当然，构建这么大的产品是复杂多样的，所以不是每个特性都能适合这个模型，但这是我们使用的总体规划。到目前为止，它运行良好，但当然，这样一个计划的证明将只会真正出现在产品周期的后期。

特写组

现在，我的团队正在开发三个专题小组，第四个小组即将启动。我先来谈谈这些。

MSBuild: 我喜欢图书馆团队的一点是，我们几乎运送所有的资源。总的来说，我为我们的货源质量感到骄傲，而且我认为我们应该知道，我们所做的每件事都会被我们的客户看到[另外，当然，这也增加了我有时写的文章长度评论的价值——比如atldef.h中atlstake上的评论

J ]. 作为一个更实际的问题，发布源代码使得调试和理解我们的库变得更加容易。我不知道，通过阅读文档和书籍，我能学到多少关于MFC的知识，就像我头几年编写MFC应用程序和通过库源代码进行调试那样多。我们的库使用一组非常复杂和复杂的基于NMAKE的构建脚本进行构建。使用NMAKE是非常实际的，因为几乎每个人都理解它，而且也是很好的讨厌鬼，因为拥有NMAKE的团队也是风投家族的一部分。你会惊讶于我们的建筑有多复杂。CRT的构造尤其粗糙。

几年来，我们一直兴奋地看着MSBuild团队从头开始构建一个新的构建系统。过去曾为我工作过的几个人都参与了MSBuild的工作，我认为他们在从头开始重新设想我们产品的这一部分并为这个问题提供下一代解决方案方面做得很好。几个月前，我们决定将我们所有的VC构建迁移到使用MSBuild，现在我们已经有一个功能小组在做了几个月了；他们就快完成了。我真的很高兴看到新产品问世。一个伟大的结果是我们的旧版本完全春季清理。尽管它们仍然是部门中最复杂的构建，但它们比过去更容易理解和理解。

开发过程：在几乎每个产品周期的开始阶段，我们需要做的一件事就是重命名我们的库dll。你可能想知道我们为什么这么做。如果我们在多个版本中保持我们的DLL名称和它们的二进制约定相同，显然会更简单。对于我们图书馆的某些部分来说，我们可以想象这样做，我们认真地考虑过。CRT并不是每一个版本都有实质性的改变，因为它是一个纯C API，当CRT改变时，通常可以用一种兼容的方式来完成。在上一个版本中，我们做了一些不兼容的更改[例如，我们将时间扩展到64位]。我们图书馆的其他部分更需要改变。给定C++类版本的方式，不可能对我们的STL或MFC进行重大更改，而不必重新版本包含这些类的DLL。

保持相同的DLL名称也有一个测试问题。我们必须确保我们所做的错误修复或添加的扩展不会对现有应用程序造成微妙的问题。我们必须确保我们的新版本在所有与旧版本相同的平台和场景中进行测试。这被称为平台类型兼容性栏（我发现了一篇关于平台和库类型的好文章）

在这里 –上下文是.NET，但概念相似）。在90年代中期，我们尝试为几个VC版本点击这个兼容性条，但成功率非常有限。每一个以相同的DLL名称发布的新的主要版本都有重大问题，因为我们不小心给DLL的现有用户带来了问题。

我们的经验告诉我们，如果要对库组件进行重大的修复或更改，我们应该对它们进行重新版本。我们努力保持源代码的兼容性，但不需要担心在当前版本上运行的产品的前一版本编译的代码。我们的开发过程刚刚完成DLL的重命名过程；我们已经有了新的、闪亮的msvcr90.dll和mfc90.dll的私有副本可供使用。

这个团队还致力于一个引人入胜的内部流程变革，这将大大增加我们的麻烦，降低我们工作的复杂性。但我没有空间来讨论这个。

STL/CLR公司： VisualStudio 8中最大的失望之一是我们没有资源来完成，并将STL/CLR传输到C++标准模板库中。你们这些在测试版的人将会在测试版2中看到该技术的早期版本

纯粹的器皿在这个项目的大部分产品周期，他们做了一些伟大的工作。但最终我们没有足够的人员和时间继续与他们一起工作，同时完成我们正在构建的其他功能。追溯到，我们非常雄心勃勃地尝试在C++ + CLI方言还在发展的同时构建这个库。

我们和Dinkumware在Whidbey发布后不久又重新开始工作，现在有了一个版本，可以满足我们原来的很多目标。特别是，自去年10月以来，我们已经做了一些有趣的优化工作，以了解在托管代码中，是什么真正驱动了基于模板、基于泛型的库的性能。我们还没有完成性能，但是在非正式测试中，我们看到了一些令人兴奋的结果，包括一组案例，其中模板与C++优化器相结合，即使在可验证代码中也能胜过.NET基类库。当我们设想几年前C++或CLI时，这些是我们梦寐以求的场景，看到它们实现的结果是令人兴奋的。

我们将启动一个功能小组，将当前版本的STL/CLR集成到Orcas中。这只是我们当前状态的一个快照，但它应该允许我们在未来的客户技术预览中从你们中的一些人那里获得反馈。在这个版本中，很多东西仍然是不完整的（因为我们仍然有一些未来的里程碑在使用Dinkumware来完成库的其余部分），但是它应该足以让您了解实现的味道，并尝试一下，然后向我们发送反馈。我们很想听听你的经历。

其他活动

服务：另一个一直在运行的团队是我们的服务团队。它的工作是处理现有功能中传入的bug，创建qfe和服务包，并帮助通过各种途径与我们联系的内部和外部客户。我们通过整个团队轮流成为这个小组的成员，这给了每个人一个机会来研究广泛的图书馆技术。我也为这个群体做了一些兼职帮助，我发现这些问题特别引人入胜——看到人们如何使用我们的产品，了解我们在未来版本中可以做些什么来提高生产力和减少痛苦，总是非常有启发性的。

我们的第一个VisualStudio8服务包的测试版就快到了。我们成功地在这个版本中添加了很多好的补丁，包括MSDN产品反馈中心中投票率最高的许多问题。（最近移到了

http://connect.microsoft.com ). 您的反馈使这成为我最喜欢的service pack体验之一。至少这一款在产品发货后很快就会面世。

规划Vista用户界面： Orcas是一个以Vista为中心的版本，一旦我们完成了上面描述的开发过程，我们就可以开始更新我们的库来更好地针对windowsvista。vside和MFC都需要了解大量新控件、消息和其他Windows元素。如果你回顾一下windowsxp，你会发现在这个版本的操作系统中添加了几乎一样多的控件，而我们在windowsxp发布时（2001年8月，就在我们发布VS7之前）没有时间添加这些控件。因此，我们回顾了WindowsXP中所有丢失的控件和UI元素，因此我们可以尝试将所有这些都放到VisualStudioOrcas中。这是一个大的计划工作，只是部分完成，但我们仍在这方面的工作，因为我们预计开始实施这些新的控制在未来6周的某个时候。

与工作无关

当我不写邮件或不工作时我该怎么办？好吧，这个周末我要去

太平洋西北芭蕾舞团（我是订户），我要建一个乐高模型我上周买的。我的未婚夫é我和e得去看看接待场所，我们还有几个聚会要和朋友一起去。如果我有时间的话，我需要完成最新版本的组织工作拼图旅行我和微软的一些朋友一起组织的活动。当然，我会玩的壁球两天，就像我每天一样。这个周末比大多数人都忙，但这仍然是我花时间做的一个很好的例子。