Delphi当初是企图自创一套不依靠操作系统的运行库，所以它的运行库包裹了Windows本身的那几个内核库，才显得大，而VFP是直接使用Windows内核库的，故小。Delphi在Windows上慢，是迫不得已的，因为它自己的库再快，也扭不过操作系统的调度，一到系统底层，它就仍然要调用Windows的内核（操作系统总不会让你接管内核部分），因此是很尴尬的脱裤子放屁之举。

但是GDI+有个最重要的问题，就是速度问题，bug不少，也令很多的程序员为之心痛，要扩展所显示的图片格式，想写acdsee类似的程序，还得自己写程序解码，当然，它的好用，傻瓜式的调用，体现的是面象对象编程的精华。呵呵。

想要快，在VFP注册DirectX的API库即可，跟用C写没什么区别。我测试过用VFP调用API的FTP功能，速度飞快，说明那没有阻隔的。

但是据我了解delphi内部使用了汇编程序封装windows消息过程，比vc的mfc确实要快，个人感受的确是这样的，delphi的应用程序反应速度要比mfc的快，也有人实测过，以数据的型势反应出来，不过Delphi群也蛮郁闷的，开发领导人被ms挖走搞C#开发，最后落得和vfp一样的下场。。。罪恶的ms呀，广大程序员伤不起哦。

好象是这样的，以前见过某国外狐友用vfp使用dx，经典呀。呵呵，这帖成了我们的对聊帖。。

对C#，我是看中它的语言封装，因为我一直遗憾VFP在面向对象的语言方面有点不完善（如不能编写类内类），对拖放数据之类，是没兴趣用的，也不打算用C#与SQL Server接口，倒是对用XML传递数据有兴趣，因为这是C#和VFP都支持的东西，而且很现成。

呵呵，C#现在如日中天，N多的人投身进去了。。。
XML类在.net的出现实际上也说明了一个问题，一个事实的工业标准，应用程序库都应该提供对它的支持，可惜的是C++目前没有这个打算，虽然有很多的第三方库，但一直没有融进STL库中，boost库好象有这个打算弄成标准了。

MFC慢是因为它要照顾更广泛的层面，里面做了太多太多的事情，而有些是被外人视为多余的。Delphi那个，之所以用汇编优化，不过是力图使糖衣的厚度减到最薄的手段而已，本质上还是把API包装成自己的界面，让人以为那是他们自己的东西。Windows那种与传统完全相反的调度机制（即操作系统调用程序函数），是很厉害的杀手，除非你的软件不在这个操作系统下运行，否则逃不出如来佛的掌控。

对了，C#我想弄一本书，不知你有没有电子版的？

,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU28_.jpg" border="0" />

[ 本帖最后由 TonyDeng 于 2011-10-20 13:35 编辑 ]

谢谢楼主。