VB6以过于宽容(从而允许不良做法)和隐藏复杂性而闻名,这些复杂性可能是开发人员最好不需要知道的.但我发现,90%的应用程序可以在VB6中完成.
但是我希望看到更多关于推动信封工作以绕过VB6的局限性的例子.例如,我曾经通过调用Windows操作系统找到了一些在VB6中使用指针的代码.结果是对大文件(大约2MB)的一些字符串操作从30分钟降低到超过3秒.有没有人有其他超越VB6限制的例子？
NB 不是 VB.Net.
一个令人讨厌的伎俩是滥用CallWindowProc通过传递指针来调用任意代码.这在技术上打破了该函数的契约,因为它只应该与通过获得的句柄(不是直接代码指针)一起使用GetWindowLong; 但实际上很少有人真正知道这个实现被强制允许任意代码指针.这允许你调用任何函数指针,只要它是stdcall,并且需要4个与参数相同大小的WndProc参数.
上面提到的一个更糟糕的技巧是你可以用这种方式动态生成代码 - 只需将其粘贴在一个字节数组中,然后用CallWindowProc它跳转到它.这样,您可以将非VB6生成的本机代码嵌入到VB6应用程序中,而无需任何外部DLL.当然,在这个默认启用NX位的时代,它可能不再是一个好主意(如果它曾经是,那就是)......
许多VB6程序都是意大利面条,要么是因为它们是快速而肮脏的一次性完成,要么是因为它们是由黑客程序员编写的,没有面向对象编程甚至结构化编程的培训.
我想知道的是,如果你选择那些在指针中做梦的顶尖C++程序员,并让他们在VB6中编码,会发生什么.我在Fog Creek发现的是它们成为超高效的编码机.代码看起来很不错,它面向对象且功能强大,但您不会浪费时间使用低于您需要的工具.我花了数年时间编写C++/MFC代码,多年用Visual Basic编写代码,让我告诉你,VB6更高效,更高效......
关于Visual Basic 6的一个问题是,它并不总能让您访问完成应用程序所需的Windows好东西的全部功能.但是,它做得比几乎任何其他编程环境都好,让你在绝望或需要额外速度时插入C++代码(或调用C API).
这是在2001年写的:当今创建一个新的Windows程序时,恕我直言,最佳生产力的明显选择是VB.Net或C#.(JOKE: C#只是带有分号的Visual Basic.)
回到VB6:有许多很好的例子,说明如何调用C API来做一些特殊的事情或者只是为了更快地运行.这是我最喜欢的一些链接:
| 归档时间： |
|
| 查看次数： |
535 次 |
| 最近记录： |