13,826
社区成员
发帖
与我相关
我的任务
分享DLL的dllimport与dllexport差别？
输入函式__declspec(dllimport) 与输出函式__declspec(dllexport) 有什么区别呢？我知道他们不同，但差别在哪呢?我用的全是__declspec(dllexport) ， __declspec(dllimport)一般在什么时用呢？说说一般在什么时分别用到它们？谢谢。
...全文
请发表友善的回复…
发表回复
tethy 2002-05-14
- 打赏
- 举报
关于winXP的源代码的报道我也见过，是今年4月2日，鉴于此日前一天的特殊性，我有理由对此消息真实性表示怀疑，当然 说不定Bill.Gates还是个搞笑的天才，能把手底下的人说服了用Basic写OS，然后号召大家用u-edit之类的工具手工把file header改成coff之类的格式，呵呵，然后让那帮法官直发懵
whitetiger8 2002-04-29
- 打赏
- 举报
大家说的非常好，我实在不好给分，只是像征性的给了分。希望大家谅解
whitetiger8 2002-04-28
- 打赏
- 举报
这个问题的点数太少，真精彩。真想再加上100分！很快结贴
windofsun 2002-04-27
- 打赏
- 举报
进来学习
常宁 2002-04-27
- 打赏
- 举报
其实使用uedit32通常可以看出很多执行文件或动态库的开发工具来，每种开发工具的开发都很有特点，比如COFF格式，很有特色，因此用uedit32通常可以判断开发工具。很少的情况下判断不了，但是这种情况可以忽略不计。比如BC的最高位为反子节就很有特点。
MFC是一个CLASS Lib因此理论上是开发工具无关的（尽管由于MS的封闭，导致了不可兼容其他开发工具），而且最开始的MFC用MSC开发，因此你可以找到这种用于MSC的MFC库。我所知道的只有MSC7可以用。不要因为你的无知而误导别人。星少的通常有三种情况，第一，刚刚加入，第二 不愿帮助别人，第三，水平差。我以前是第二种，现在改了（从今年2月份开始回复帖子）。以后大家共同努力：）
其实在BCB中Exe文件里可以认为这两个声明可以混用。他们其实就是一个标记而已。但我不推荐混用，特别是在定义DLL时候。
MFC是一个CLASS Lib因此理论上是开发工具无关的（尽管由于MS的封闭，导致了不可兼容其他开发工具），而且最开始的MFC用MSC开发，因此你可以找到这种用于MSC的MFC库。我所知道的只有MSC7可以用。不要因为你的无知而误导别人。星少的通常有三种情况，第一，刚刚加入，第二 不愿帮助别人，第三，水平差。我以前是第二种，现在改了（从今年2月份开始回复帖子）。以后大家共同努力：）
其实在BCB中Exe文件里可以认为这两个声明可以混用。他们其实就是一个标记而已。但我不推荐混用，特别是在定义DLL时候。
whitetiger8 2002-04-27
- 打赏
- 举报
呵呵，太激烈了！我非常关注。而且我希望两大高手，要讨论有个结果时，最好再来个总结性的发言！谢谢！我们受益非浅啊！
libamboo 2002-04-27
- 打赏
- 举报
学习
playmud 2002-04-27
- 打赏
- 举报
但例外的情况是，某个DLL文件中不具备全部的被调函数，它也要靠调用其他的DLL函数来实现自己函数中的某些功能，那么最下端被调用的DLL中，只有导出函数export，而上层调用别人的DLL成了主调的身份，要导入，所以也就有了import。
我觉得上面的话是正确的。
import export能不能互换，按照常宁的说法应该肯定有的时候可以，是不是所有的时候都可以呢？
我觉得上面的话是正确的。
import export能不能互换，按照常宁的说法应该肯定有的时候可以，是不是所有的时候都可以呢？
playmud 2002-04-27
- 打赏
- 举报
我觉得建议争论下去，星少的不一定是水平差。
只要不骂人，只要关于知识的争论是完全必要的，可能你一直想当然的事情是错误的呢。回答了所然，而没有说明白所以然很难是大家的水平提高。
只要不骂人，只要关于知识的争论是完全必要的，可能你一直想当然的事情是错误的呢。回答了所然，而没有说明白所以然很难是大家的水平提高。
wfu 2002-04-27
- 打赏
- 举报
mark!
telescope 2002-04-27
- 打赏
- 举报
幼稚，当然幼稚，先有的MSC，后出的MFC，MSC怎么用MFC=>啊，是不是又要用什么复杂工具啊？？？你再给大家推荐一个这样的工具吧。
我用debug看Windows文件，既不是C++也不是Basic，全是乱码，哈哈！
95、98源码就不要贴了，人家那篇文章里没提，要贴就贴Win XP的源码吧，先告诉大家，什么时候贴呀？我看就选在CSDN倒闭的那一天吧！
对啦，贴的时候把证据也贴上，别把DOS3的源码贴上，后面注Win XP=> ！！
我用debug看Windows文件，既不是C++也不是Basic，全是乱码，哈哈！
95、98源码就不要贴了，人家那篇文章里没提，要贴就贴Win XP的源码吧，先告诉大家，什么时候贴呀？我看就选在CSDN倒闭的那一天吧！
对啦，贴的时候把证据也贴上，别把DOS3的源码贴上，后面注Win XP=> ！！
yuyulily 2002-04-27
- 打赏
- 举报
呵呵，精彩！
iec 2002-04-27
- 打赏
- 举报
学习
tdsoft 2002-04-27
- 打赏
- 举报
import export的互换，不应该是设计者的本意吧？我们想了解的问题应该是为什么能这样？
diabloyj 2002-04-27
- 打赏
- 举报
telescope(望远镜)说的Windows XP 原碼的事我也看到了。我私人认为是不可确定的消息。^_^
95 98原碼我想应该是redpower(常宁)在开玩笑的。谁要有这个东东还不得了啦。
import export的互换我做的实验是可以的但只限于在调用程序中。
由此肯定有的时候是可以互换的。
而是不是所有的时候都可以呢？这个问题我也很想知道可又怎么来证明呢？
请教redpower(常宁)用uedit32或Editplus等编辑软件判断执行文件或动态库开发工具的经验。需要我另开帖子吗？
95 98原碼我想应该是redpower(常宁)在开玩笑的。谁要有这个东东还不得了啦。
import export的互换我做的实验是可以的但只限于在调用程序中。
由此肯定有的时候是可以互换的。
而是不是所有的时候都可以呢？这个问题我也很想知道可又怎么来证明呢？
请教redpower(常宁)用uedit32或Editplus等编辑软件判断执行文件或动态库开发工具的经验。需要我另开帖子吗？
telescope 2002-04-27
- 打赏
- 举报
OK,那就总结一下：
某些人的观点：
1.其实这两个东西在调用DLL的时候如果用错了，也没什么。效果一样
2.MSC同样可以用MFC=>
3.理论上是开发工具无关的（不可兼容其他开发工具）
某些人对另一些人的评价：
1.我认为你说的是最差的
2.幼稚
3.无知
某些人对自己的评价：
星少的通常有三种情况，我以前是第二种（编者注：不是水平差的那种，也不是新来的那种），现在改了（编者注：是改成水平差的了还是改成新来的了？喔，一定是改成星多的那种了！！[玩笑]）
另一些人对自己的评价：
1.最差
2.幼稚
3.无知
4.白痴
另一些人在讨论前后的状态：
1.原来对export和import的认识，export是导出标记，import是导入标记；现在已经不知道它们都是干什么的了（思维溢出错误：南和北都一样，站在南极往哪个方向看都是北，站在北极往哪个方向看都是南，方向就是方向，干嘛要区分南北？！！）
2.原来认为VC是微软最先进的编程工具，别人都做不出来，其核心是MFC；Microsoft C是微软已经过时的产品。现在已经不知道它们哪个更好了（大脑短路：MSC是用MFC=>，反正它们都是微软的编程工具，干嘛要区分好坏？）
3.原来我不知道Windows是用什么语言写的；现在我白痴（Windows95、98和WindowsXP都是微软的操作系统干嘛非得要WindowsXP的源码，Windows95、98的不行吗？而且Windows95、98是WindowsXP=>，已知WindowsXP是Basic语言写的所以Windows95/98一定是Basic语言写的；按照这个理论，DOS是Windows95/98=>，所以DOS也一定是Basic语言写的，我越想越觉着对，DOS是盖茨他们写的，盖茨这家伙就会Basic）
4.原来我无知，认为MFC是不能和其他编程工具兼容的；现在我...（肚子迷糊：原来平台无关性就是不兼容的意思）！
大家在网上遇见我以后有没有胜读十年书的感觉（你们好好想想，也可能是胜读十一年书）？
某些人的观点：
1.其实这两个东西在调用DLL的时候如果用错了，也没什么。效果一样
2.MSC同样可以用MFC=>
3.理论上是开发工具无关的（不可兼容其他开发工具）
某些人对另一些人的评价：
1.我认为你说的是最差的
2.幼稚
3.无知
某些人对自己的评价：
星少的通常有三种情况，我以前是第二种（编者注：不是水平差的那种，也不是新来的那种），现在改了（编者注：是改成水平差的了还是改成新来的了？喔，一定是改成星多的那种了！！[玩笑]）
另一些人对自己的评价：
1.最差
2.幼稚
3.无知
4.白痴
另一些人在讨论前后的状态：
1.原来对export和import的认识，export是导出标记，import是导入标记；现在已经不知道它们都是干什么的了（思维溢出错误：南和北都一样，站在南极往哪个方向看都是北，站在北极往哪个方向看都是南，方向就是方向，干嘛要区分南北？！！）
2.原来认为VC是微软最先进的编程工具，别人都做不出来，其核心是MFC；Microsoft C是微软已经过时的产品。现在已经不知道它们哪个更好了（大脑短路：MSC是用MFC=>，反正它们都是微软的编程工具，干嘛要区分好坏？）
3.原来我不知道Windows是用什么语言写的；现在我白痴（Windows95、98和WindowsXP都是微软的操作系统干嘛非得要WindowsXP的源码，Windows95、98的不行吗？而且Windows95、98是WindowsXP=>，已知WindowsXP是Basic语言写的所以Windows95/98一定是Basic语言写的；按照这个理论，DOS是Windows95/98=>，所以DOS也一定是Basic语言写的，我越想越觉着对，DOS是盖茨他们写的，盖茨这家伙就会Basic）
4.原来我无知，认为MFC是不能和其他编程工具兼容的；现在我...（肚子迷糊：原来平台无关性就是不兼容的意思）！
大家在网上遇见我以后有没有胜读十年书的感觉（你们好好想想，也可能是胜读十一年书）？
diabloyj 2002-04-26
- 打赏
- 举报
To redpower(常宁)
如你所说。只要DLL中用的__declspec(dllexport)
在调用Dll的程序中用__declspec(dllexport)，__declspec(dllimport)都可以。不过我并不是要你讲什么大道理，只是想知道为什么会这样，那么__declspec(dllimport)的存在还有什么意义。
如你所说。只要DLL中用的__declspec(dllexport)
在调用Dll的程序中用__declspec(dllexport)，__declspec(dllimport)都可以。不过我并不是要你讲什么大道理，只是想知道为什么会这样，那么__declspec(dllimport)的存在还有什么意义。
diabloyj 2002-04-26
- 打赏
- 举报
收藏
常宁 2002-04-26
- 打赏
- 举报
声明：
哦，对了，忘了声明以下，以前做过MSC/C++的人都习惯称呼MS C/C++ 7.0为MSC7就如同说BC5指的是Borland C++ 5.0一样。前面的那个兄弟是不是新手？不会连这个都不知道把？还有谁说MSC和VC是DOS和Windows之间的差别？MSC同样可以用MFC,而且Windows本身使用MSC写的，一些不太重要的部分，比如画笔，写字板之类的用VC写，其实这些用什么写倒没有什么不同，不过说他们之间的关系是DOS和Windows我看你就太过了。其实MSC和VC更像是BCB和BC一样，BCB5.0的引擎就是BCC32.exe 这个东西就是Borland C++ 5的编译器的升级，最高版本的BC是5。05如果没有记错的话，现在的BCB6的编译器是5.6，所以本质上BCB仍然是BC,而VC仍然是MSC.我上面写得关于extern "C" 和__declspec地描述是MS和Borland的官方说法，我想应该比较明确了，如果说得有什么不妥，可能使我个人翻译能力有限。不过熟悉VC和BCB得人肯定能够理解我的描述。
哦，对了，忘了声明以下，以前做过MSC/C++的人都习惯称呼MS C/C++ 7.0为MSC7就如同说BC5指的是Borland C++ 5.0一样。前面的那个兄弟是不是新手？不会连这个都不知道把？还有谁说MSC和VC是DOS和Windows之间的差别？MSC同样可以用MFC,而且Windows本身使用MSC写的，一些不太重要的部分，比如画笔，写字板之类的用VC写，其实这些用什么写倒没有什么不同，不过说他们之间的关系是DOS和Windows我看你就太过了。其实MSC和VC更像是BCB和BC一样，BCB5.0的引擎就是BCC32.exe 这个东西就是Borland C++ 5的编译器的升级，最高版本的BC是5。05如果没有记错的话，现在的BCB6的编译器是5.6，所以本质上BCB仍然是BC,而VC仍然是MSC.我上面写得关于extern "C" 和__declspec地描述是MS和Borland的官方说法，我想应该比较明确了，如果说得有什么不妥，可能使我个人翻译能力有限。不过熟悉VC和BCB得人肯定能够理解我的描述。
常宁 2002-04-26
- 打赏
- 举报
__declspec(dllxxport)在32位系统中为了替代 __export而产生的，后面提到的是16为系统中用于释放函数。32位系统的DLL要简单与16为系统的DLL。
在BCB中这个问题就不大相同。首先后一种声明同样可以用于32为系统。而且事实上很多情况下比第一种方式用得更多。__declspec(dllexport)在VC中可以避免函数名称，效果类似于.DEF方式。但是不能定义导出函数的序号。在VC中推荐采用.def方式，但是确实__declspce(dllexport) 要比.def方式省事，在VC中如果DLL被显性调用，这两种方式差别不大，但是如果隐性调用，__declspec方式可能会导致.exe文件也需要重新编译，否则不能正常运行（注意，是可能，不是一定）
不使用 __declspec(dllimport) 也能正确编译代码，但使用 __declspec(dllimport) 使编译器可以生成更好的代码。编译器之所以能够生成更好的代码，是因为它十分清楚函数是否在 DLL 中，因此可以生成跳过间接级别的代码，而在跨 DLL 边界的函数中通常存在这些间接代码。但是，必须使用 __declspec(dllimport) 才能导入 DLL 中使用的变量
如果在用 C++ 编写的 DLL 中有希望从 C 语言模块访问的函数，应使用 C 链接而不是 C++ 链接来声明这些函数。除非另外指定，C++ 编译器使用 C++ 类型安全命名约定和 C++ 调用约定。若要指定 C 链接，请为函数声明指定 extern "C"。这就是extern "C"的真正作用了，不管如何说明extern 是否用于兼容，只要明白意思就可以了。
至于__declspec(dllexport) __declspec(dllimport)为什么在调用的时候能够互换，我没有看到这两个关键字的处理程序，不敢发表言论。但是可以看出，这两个东西仅仅是为了兼容VC的32位DLL而被引入，因此，很有可能是个宏定义。如果是这样，也就不难解是为什么可以互换在调用的时候。
在BCB中这个问题就不大相同。首先后一种声明同样可以用于32为系统。而且事实上很多情况下比第一种方式用得更多。__declspec(dllexport)在VC中可以避免函数名称，效果类似于.DEF方式。但是不能定义导出函数的序号。在VC中推荐采用.def方式，但是确实__declspce(dllexport) 要比.def方式省事，在VC中如果DLL被显性调用，这两种方式差别不大，但是如果隐性调用，__declspec方式可能会导致.exe文件也需要重新编译，否则不能正常运行（注意，是可能，不是一定）
不使用 __declspec(dllimport) 也能正确编译代码，但使用 __declspec(dllimport) 使编译器可以生成更好的代码。编译器之所以能够生成更好的代码，是因为它十分清楚函数是否在 DLL 中，因此可以生成跳过间接级别的代码，而在跨 DLL 边界的函数中通常存在这些间接代码。但是，必须使用 __declspec(dllimport) 才能导入 DLL 中使用的变量
如果在用 C++ 编写的 DLL 中有希望从 C 语言模块访问的函数，应使用 C 链接而不是 C++ 链接来声明这些函数。除非另外指定，C++ 编译器使用 C++ 类型安全命名约定和 C++ 调用约定。若要指定 C 链接，请为函数声明指定 extern "C"。这就是extern "C"的真正作用了，不管如何说明extern 是否用于兼容，只要明白意思就可以了。
至于__declspec(dllexport) __declspec(dllimport)为什么在调用的时候能够互换，我没有看到这两个关键字的处理程序，不敢发表言论。但是可以看出，这两个东西仅仅是为了兼容VC的32位DLL而被引入，因此，很有可能是个宏定义。如果是这样，也就不难解是为什么可以互换在调用的时候。
加载更多回复（22）
