864
社区成员
发帖
与我相关
我的任务
分享关于VB创建DLL输出函数的问题
对于这个问题我的理解不是很清晰，需要大家帮助一下，就是DLL输出函数是什么东西？想达到什么样的效果，求大家指教，如果有例子更好
不是要如何实现这个功能的代码，是想知道这个功能最终达到的目的是什么，谢谢大家
不是要如何实现这个功能的代码，是想知道这个功能最终达到的目的是什么，谢谢大家
...全文
请发表友善的回复…
发表回复
不懂别说哎 2021-02-05
- 打赏
- 举报
原来是这个意思啊，这个就有意思了，我琢磨琢磨去
三楼の郎 2021-02-04
- 打赏
- 举报
VB的ActiveX Dll做出来的是COM，输出函数（stdout）是标准DLL里的概念，虽然都是动态链接库，但是是不一样的，你对比下ActiveX的调用方式和Windows API的调用方式差别就知道了
脆皮大雪糕 2021-02-04
- 打赏
- 举报
你是看到我04年转的那篇觉得好奇吗？评论我没及时回复就来这问了？
VB里编译生成的DLL叫ActiveX DLL 本质是COM
"Active X"是微软为分布式计算制定的一套标准,它的前身就"OLE Automation"。当分布式应用通过网络通信时,Active X可以使用两种不同的机制对客户请求作出响应。一种是称为"分布组件对象模式(DCOM)",另一种是"远程自动化(Remote Automation)"。这两种分布式机制都具有着与组件物理位置无关的特点。也就是说,当构造一个Active X组件时,无需知道它将分布在哪台机器上。同样的组件,既可以将它放在本机,也可以将它分布在其它机器上而不需要重新编译。这样,根据网络的性能和网络结构的变化,我们可以方便地调整组件的分布策略。
还能看到另外一种类型的DLL，是以函数集合的方式来调用的。可以理解为一个函数库。只能运行在本机上。比如我们常见的win32API都是以调用DLL里的函数来处理的。
抛开分布式的情况，ActiveX DLL解决了版本（同一台机器上只有一个版本，即使多个DLL只要class id一致就只有一个是实际被调用到的）、模块化开发（每个dll是一个类，实例化成一个对象以后使用），语言问题（比如不用考虑是用stdcall 还是 cdecl调用方法）。
两种DLL文件名上看都是以DLL为扩展名，但本质和调用方式完全不同。
ActiveX DLL看上去不错的东西，但是当年很多VBer想要在VB里编译出那种函数集合方式的DLL。原因五花八门，比如炫技，突破微软本身的设定而做到的那种黑客炫酷感。但根本的原因在我看来是因为：
1、在上世纪末本世纪初的时候，存储还是很贵的东西，分给系统分区的空间捉襟见肘的。win95开始出现的注册表是一个会不断膨胀的东西，有点像系统中的癌瘤，不断膨胀消耗C盘空间，还不能轻易切除。所以当年“绿色软件”也就是不需要安装不需要写注册表拷贝到硬盘任意位置都能用的程序是被人推崇的。VB生成的ActiveX DLL和OCX 本质是COM是必须要在系统中注册一下才能用的。VBer就想既能使用VB6的高效开发又能做出“绿色软件”免得遭用户嫌弃。
2、在VB和VC并行的时候，有一个观点是VB适合做前台界面高效开发，VC适合做后台逻辑高效执行。VB一开始就一直给人一种低效、玩具语言的印象，自然VBer处于鄙视链下游。VC写ActiveX DLL 比写标准的DLL麻烦多了，所以市面上流行的DLL基本上都是标准DLL，VB编译的DLL只有VB容易调用，VCer不喜欢也不屑调用，部分VBer为了向底层或后台业务逻辑挺进想办法编译出标准DLL。
说一个心痛的往事，当年公司业务上需要有一个影像扫描和处理的功能，几个VCer对图像处理的理解不深，倒腾半天写出来的东西功能上效率上有问题，而且使用了winNT的API在其他系统上发生了不兼容的情况。后来我自告奋勇用VB写了这部分图形处理，效果比他们的东西好，但由于调用接口已经定义好发布出去了，不可能再改为COM调用方式，于是最后的方案是VC封装一层我的DLL，然后暴露函数接口编译成标准DLL供调用。七八年后，这套影像组件还在使用，但人们提起这个组件的时候都认为如此紧凑高效的图形处理必然是VC做的，直到又有一个新功能需要加入，他们把代码拿出来才发现核心功能是VB的。
但不论怎么样，VB6已经是终点了，微软并没有给出官方的编译出标准DLL的方法，VB.net也已经是另一个东西了。VB6各种突破限制的方法以及后来的第三方工具只能算是VBer的奇淫技巧，不被官方支持，也不知道会不会出啥乱子。毕竟我们输出的产品目标是稳定运行而不是炫技或斗气。如果还靠着微软吃饭那么就转.net框架和C# 要通吃就搞JAVA、python C++，不必在这些事情上纠结了。
VB里编译生成的DLL叫ActiveX DLL 本质是COM
"Active X"是微软为分布式计算制定的一套标准,它的前身就"OLE Automation"。当分布式应用通过网络通信时,Active X可以使用两种不同的机制对客户请求作出响应。一种是称为"分布组件对象模式(DCOM)",另一种是"远程自动化(Remote Automation)"。这两种分布式机制都具有着与组件物理位置无关的特点。也就是说,当构造一个Active X组件时,无需知道它将分布在哪台机器上。同样的组件,既可以将它放在本机,也可以将它分布在其它机器上而不需要重新编译。这样,根据网络的性能和网络结构的变化,我们可以方便地调整组件的分布策略。
还能看到另外一种类型的DLL，是以函数集合的方式来调用的。可以理解为一个函数库。只能运行在本机上。比如我们常见的win32API都是以调用DLL里的函数来处理的。
抛开分布式的情况，ActiveX DLL解决了版本（同一台机器上只有一个版本，即使多个DLL只要class id一致就只有一个是实际被调用到的）、模块化开发（每个dll是一个类，实例化成一个对象以后使用），语言问题（比如不用考虑是用stdcall 还是 cdecl调用方法）。
两种DLL文件名上看都是以DLL为扩展名，但本质和调用方式完全不同。
ActiveX DLL看上去不错的东西，但是当年很多VBer想要在VB里编译出那种函数集合方式的DLL。原因五花八门，比如炫技，突破微软本身的设定而做到的那种黑客炫酷感。但根本的原因在我看来是因为：
1、在上世纪末本世纪初的时候，存储还是很贵的东西，分给系统分区的空间捉襟见肘的。win95开始出现的注册表是一个会不断膨胀的东西，有点像系统中的癌瘤，不断膨胀消耗C盘空间，还不能轻易切除。所以当年“绿色软件”也就是不需要安装不需要写注册表拷贝到硬盘任意位置都能用的程序是被人推崇的。VB生成的ActiveX DLL和OCX 本质是COM是必须要在系统中注册一下才能用的。VBer就想既能使用VB6的高效开发又能做出“绿色软件”免得遭用户嫌弃。
2、在VB和VC并行的时候，有一个观点是VB适合做前台界面高效开发，VC适合做后台逻辑高效执行。VB一开始就一直给人一种低效、玩具语言的印象，自然VBer处于鄙视链下游。VC写ActiveX DLL 比写标准的DLL麻烦多了，所以市面上流行的DLL基本上都是标准DLL，VB编译的DLL只有VB容易调用，VCer不喜欢也不屑调用，部分VBer为了向底层或后台业务逻辑挺进想办法编译出标准DLL。
说一个心痛的往事，当年公司业务上需要有一个影像扫描和处理的功能，几个VCer对图像处理的理解不深，倒腾半天写出来的东西功能上效率上有问题，而且使用了winNT的API在其他系统上发生了不兼容的情况。后来我自告奋勇用VB写了这部分图形处理，效果比他们的东西好，但由于调用接口已经定义好发布出去了，不可能再改为COM调用方式，于是最后的方案是VC封装一层我的DLL，然后暴露函数接口编译成标准DLL供调用。七八年后，这套影像组件还在使用，但人们提起这个组件的时候都认为如此紧凑高效的图形处理必然是VC做的，直到又有一个新功能需要加入，他们把代码拿出来才发现核心功能是VB的。
但不论怎么样，VB6已经是终点了，微软并没有给出官方的编译出标准DLL的方法，VB.net也已经是另一个东西了。VB6各种突破限制的方法以及后来的第三方工具只能算是VBer的奇淫技巧，不被官方支持，也不知道会不会出啥乱子。毕竟我们输出的产品目标是稳定运行而不是炫技或斗气。如果还靠着微软吃饭那么就转.net框架和C# 要通吃就搞JAVA、python C++，不必在这些事情上纠结了。不懂别说哎 2021-02-04
- 打赏
- 举报
不是，我是想知道大家都说VB 的ATX DLL不能创建输出函数，我没明白什么意思
余思培 2021-02-03
- 打赏
- 举报
你的意思是让VB创建的DLL供其他语言调用？
