近来，针对我们的所有读者提出的问题，我们对微软.NET开发人员进行了采访，第一部分是他们对.NET平台的安全性做出的评论，在这一部分里，主要是他们对平台性能和一些易混淆的选项问题做出的解释。

转换语言会带来问题吗？


Builder.com:很显然，.NET会被编译成IL，这样就不得不使人注意到把IL转换成高级.NET语言（象C语言）的可行性，假设要这样做的话，会怎样？如果这样做，微软打算对此做何举措？

Eric Meijer：通常，所有的代码都是要被编译的——不管是C++,VB,.NET还是Java。如果只考虑代码编译的简单性，那么Java的beta代码要比.NET的MSIL简单。VB的简化版本也没有什么不同，这是软件开发的本质。

通常情况下，这些都不成问题。对于很多中、大型应用程序，编译代码并不会生成很多东西。你可能要花费很多年的时间来理解和掌握这些代码，更重要的是理解某些特定算法的真正原理，到那时你就完全掌握了编译器的知识，在产品开发前可能要有几年的时间。实际上，最好把世间花在代码上。

    但是也有很多人想要更进一步，想要知道Obfuscator提供的一些不公开的内容。微软决定不同.NET或.NET基础结构一起发布Obfuscator，因此就不会出现多年来象Java和其他主要编程语言之间obfuscator和de-compilers那样的竞争，当然可以得到其他的Obfuscator，如LSW DotNet-IL-Obfuscator, Dotfuscator, 和Demeanor for .NET。

C语言与VB.NET的性能比较
Builder.com:有谣传说C语言要比VB.NET编译IL代码快，我个人也用Beta2做了一个粗略的测试，结果也是如此。VB.NET编译器好像在生成的IL中插入了很多伪NOP代码，对此您做如何解释？

Mahesh Prakriya:这样的结果如IL中没有ops或者检查IL并不能得出这样的结论，由于JIT优化作用，JIT可以把每种情况下的IL都转化成同样的x86。NOPs并不重要，他们对最终生成的代码没有任何影响。

当时实现同一功能时，C语言并不比VB.NET快或慢这并没有结构上的原因，但是，VB支持不同的特性和含义（动态变量、非零边界数组、隐含后期衔接、出错处理等等），因此，看起来好像一样的代码实际上并不一样，ILDASM在特定的例子中的结果会很清楚的说明这一问题。

但是，在很多人逐渐发现这两种语言的相似之处之后，那么，如果说二者之间的差别在逐渐缩小甚至于不存在也不为过。最终，由于外来调用等因素所产生的很多差别还是存在的。

Paul Vick：当用户指定最大debug代码（在指令列，Debug+/Optimize-是等价的）时，VB编译器会在代码中生成多余的NOPs。NOPs能为Debugger提供更好的分布行为。比如，如果采用if…end中的if情况，在end行就不会有代码，但是为用户提供下一步指令也是非常好的，因此我们插入了一个NOP，同时把NOP同PDB中的End If联系起来。如果你不想要debugger代码（debug-）或者你想要优化IL(Optimize+)的话，就不会生成NOPs。

如果我记得没错，Beta2中也会出问题，在VB缺省默认模版的前面就会采用Optimaize-设置。因此，除非你知道系统特性以及如何进行正确的配置，否则在代码中就会生成NOPs，这个bug在最终版本发布前就已经发现，并且已经得到修复。

至于更大的问题，也不是不可能，在有些情况下，VC编译器比VB编译器能生成更好的IL，反之亦然。两个开发队伍能够开发两种不同的编译器，这一事实是必然的。但是，在大多数情况下，这些编译器会生成同样的IL，在某些特殊情况下，某个编译器能够生成更好的IL，我们就认为这种情况在非优化编译器里是个bug，并且已被修复。

其次，这两种语言是有区别的。如果我记得没错，Builder.com中的文章所提到的很多二者之间的区别都指的是二者语义的区别。尽管这两种语言的句式相似，但其含义却不相同，而且会生成不同的IL，这一点同样也是不可避免的，这也就是各有千秋，有些情况下，VB生成代码的速度要比VC快。

最后，我还要强调一下VB和VC之间如果非要分出谁强谁劣是没有意义的。情况不同，二者发挥的作用也不同，产生的结果也不同，但有一点是可以肯定的，那就是在某些特殊情况下，是能分出胜负的。