社区
进程/线程/DLL
帖子详情
在没有头文件的前提下,怎么调用DLL
guoln1010
2011-06-12 10:38:43
我现在做一个二次开发,可是买来的板卡只给了DLL文件,其他的什么都没有;通过dumpbin查看此DLL文件导出的函数,可是具体怎么调用这些函数呢?我查到的资料是:
1.LoadLibray、GetProcAddress。freelibray.
还有其他方法吗?这个方法怎么调用?没有头文件
...全文
732
12
打赏
收藏
在没有头文件的前提下,怎么调用DLL
我现在做一个二次开发,可是买来的板卡只给了DLL文件,其他的什么都没有;通过dumpbin查看此DLL文件导出的函数,可是具体怎么调用这些函数呢?我查到的资料是: 1.LoadLibray、GetProcAddress。freelibray. 还有其他方法吗?这个方法怎么调用?没有头文件
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
12 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
verybigbug
2011-06-13
打赏
举报
回复
这个,让供应商提供Document啊,这个是很基本的要求啊。除非你的DLL来路不正。
xiaoshiquan
2011-06-13
打赏
举报
回复
[Quote=引用 7 楼 guoln1010 的回复:]
引用 2 楼 magicfuzzx 的回复:
即使是GetProcAddress也需要函数的参数表,则需要用逆向的手段取得。
你买的至少也应该有个帮助文档之类的,查看下参数
还有一个问题就是:我需要调用很多歌DLL中函数,我的调用方法就是typedef 定义一个指针函数,然后GetProcAddress导出函数地址,难道每一个函数都需要这样使用吗?有没有简便方法?
[/Quote]
GetProcAddress是动态调用的方式,只能这样的。如果你想静态调用动态库,那你就用lib工具从Dll中导出个.lib文件,然后再自己手动写个头文件你就可以静态使用动态库了。只不过我觉得这样更麻烦
guoln1010
2011-06-13
打赏
举报
回复
[Quote=引用 2 楼 magicfuzzx 的回复:]
即使是GetProcAddress也需要函数的参数表,则需要用逆向的手段取得。
你买的至少也应该有个帮助文档之类的,查看下参数
[/Quote]
还有一个问题就是:我需要调用很多歌DLL中函数,我的调用方法就是typedef 定义一个指针函数,然后GetProcAddress导出函数地址,难道每一个函数都需要这样使用吗?有没有简便方法?
guoln1010
2011-06-13
打赏
举报
回复
[Quote=引用 5 楼 xianglitian 的回复:]
引用 4 楼 guoln1010 的回复:
引用 2 楼 magicfuzzx 的回复:
即使是GetProcAddress也需要函数的参数表,则需要用逆向的手段取得。
你买的至少也应该有个帮助文档之类的,查看下参数
恩 是有一个文档文件,里边是函数的说明,可是我动态加载DLL后,使用depends怎么没有显示已经调用的dll?难道哪一步骤有错误?
看看这个
http:……
[/Quote]
呵呵,太感谢了
向立天
2011-06-13
打赏
举报
回复
[Quote=引用 4 楼 guoln1010 的回复:]
引用 2 楼 magicfuzzx 的回复:
即使是GetProcAddress也需要函数的参数表,则需要用逆向的手段取得。
你买的至少也应该有个帮助文档之类的,查看下参数
恩 是有一个文档文件,里边是函数的说明,可是我动态加载DLL后,使用depends怎么没有显示已经调用的dll?难道哪一步骤有错误?
[/Quote]
看看这个
http://blog.vckbase.com/lishengg_blog/archive/2004/10/27/1102.html
注意第四条
guoln1010
2011-06-13
打赏
举报
回复
[Quote=引用 2 楼 magicfuzzx 的回复:]
即使是GetProcAddress也需要函数的参数表,则需要用逆向的手段取得。
你买的至少也应该有个帮助文档之类的,查看下参数
[/Quote]
恩 是有一个文档文件,里边是函数的说明,可是我动态加载DLL后,使用depends怎么没有显示已经调用的dll?难道哪一步骤有错误?
guoln1010
2011-06-13
打赏
举报
回复
改了一下就行了
typedef HANDLE ( __stdcall *pFUNCTION )(LPDWORD);
guoln1010
2011-06-13
打赏
举报
回复
[Quote=引用 5 楼 xianglitian 的回复:]
引用 4 楼 guoln1010 的回复:
引用 2 楼 magicfuzzx 的回复:
即使是GetProcAddress也需要函数的参数表,则需要用逆向的手段取得。
你买的至少也应该有个帮助文档之类的,查看下参数
恩 是有一个文档文件,里边是函数的说明,可是我动态加载DLL后,使用depends怎么没有显示已经调用的dll?难道哪一步骤有错误?
看看这个
http:……
[/Quote]
还有个问题,那就是已经能够熟练地调用硬件带的函数了,可是总是在调用handle返回值的函数时编译没问题,运行总是出现错误,这些函数都有一个设备参数
File: i386\chkesp.c
Line:42
The value of ESP was not properly saved across a function call.This is
usually a result of calling a function declared with one calling convention
with a function pointer declared with a different calling convention。
guoln1010
2011-06-13
打赏
举报
回复
[Quote=引用 9 楼 verybigbug 的回复:]
这个,让供应商提供Document啊,这个是很基本的要求啊。除非你的DLL来路不正。
[/Quote]
还有个问题,那就是已经能够熟练地调用硬件带的函数了,可是总是在调用handle返回值的函数时编译没问题,运行总是出现错误,这些函数都有一个设备参数
csx007700
2011-06-12
打赏
举报
回复
GetProcAddress 动态调用
找不到函数名的话用LordPE看看导出表
MagicFuzzX
2011-06-12
打赏
举报
回复
即使是GetProcAddress也需要函数的参数表,则需要用逆向的手段取得。
你买的至少也应该有个帮助文档之类的,查看下参数
aorons
2011-06-12
打赏
举报
回复
用GetProcAddress得到DLL函数地址,转换后调用。
自己写的
dll
的简介
为何
DLL
先看看静态库与
DLL
的不同之处 可执行文件的生成(Link期):前者很慢(因为要将库中的所有符号定义Link到EXE文件中),而后者很快(因为后者被Link的引入库文件无符号定义) 可执行文件的大小:前者很大,后者很小(加上
DLL
的大小就和前者差不多了) 可执行文件的运行速度:前者快(直接在EXE模块的内存中查找符号),后者慢(需要在
DLL
模块的内存中查找,在另一个模块的内存中查找自然较慢) 可共享性:前者不可共享,也就是说如果两个EXE使用了同一个静态库,那么实际在内存中存在此库的两份拷贝,而后者是可共享的。 可升级性:前者不可升级(因为静态库符号已经编入EXE中,要升级则EXE也需要重新编译),后者可以升级(只要接口不变,
DLL
即可被升级为不同的实现) 综合以上,选择静态库还是
DLL
1. 静态库适于稳定的代码,而动态库则适于经常更改代码(当然接口要保持不变),当
DLL
更改(仅实现部分)后,用户不需要重编工程,只需要使用新的
Dll
即可。 2. 由于静态库很吃可执行文件的生成(Link期)时间,所以如果对可执行文件的Link时间比较敏感,那么就用
DLL
。 使用
DLL
在介绍如何创建
DLL
之前,让我们先了解它是如何被使用的。 1. 显式
调用
(也叫动态
调用
) 显 示
调用
使用API函数LoadLibrary或者MFC提供的AfxLoadLibrary将
DLL
加载到内存,再用GetProcAddress()在 内存中获取引入函数地址,然后你就可以象使用本地函数一样来
调用
此引入函数了。在应用程序退出之前,应该用FreeLibrary或MFC提供的 AfxLoadLibrary释放
DLL
。 下面是个显示
调用
的例子,假定你已经有一个Test.
dll
,并且
DLL
中有个函数名为Test,其声明式是void(); #include < iostream > using namespace std; typedef void(*TEST )(); int main( char argc, char* argv[] ) { const char*
dll
Name = "Test.
dll
"; const char* funcName = "Test"; HMODULE h
DLL
= LoadLibrary(
dll
Name ); if ( h
DLL
!= NULL ) { TEST func = TEST( GetProcAddress( h
DLL
, funcName ) ); if ( func != NULL ) { func(); } else { cout << "Unable to find function \'" << funcName << "\' !" << endl; } FreeLibrary( h
DLL
); } else { cout << "Unable to load
DLL
\'" <<
dll
Name << "\' !" << endl; } return 0; } 注意 1. 显示
调用
使用GetProcAddress,所以只能加载函数,无法加载变量和类。 2. 此外GetProcAddress是直接在.
dll
文件中寻找同名函数,如果
DLL
中的Test函数是个C++函数,那么由于在.
dll
文件中的实际文件名会被修饰(具体被修饰的规则可参考函数
调用
约定详解或者使用VC自带的Depends.exe查看),所以直接找Test是找不到的,这时必须把函数名修改为正确的被修饰后的名称,下面是一种可能(此函数在
DLL
中的
调用
约定为__cdecl): const char* funcName = "?Test@@YAXXZ"; 2. 隐式
调用
(也叫静态
调用
) 隐式
调用
必须提供
DLL
的
头文件
和引入库(可以看作轻量级的静态库(
没有
符号定义,但是说明了符号处于哪个
DLL
中))。 有了
头文件
和引入库,
DLL
的使用就跟普通静态库的使用没啥区别,只除了
DLL
要和EXE一起发布。 显示
调用
与隐式
调用
的优缺点 显示
调用
使用复杂,但能更加有效地使用内存,因为
DLL
是在EXE运行时(run time)加载,必须由用户使用LoadLibrary和FreeLibrary来控制
DLL
从内存加载或卸载的时机。此外还可以加载其他语言编写的
DLL
函数。 静态
调用
使用简单,但不能控制
DLL
加载时机,EXE加载到内存同时自动加载
DLL
到内存,EXE退出时
DLL
也被卸载。 创建
DLL
下面我们着重讲解如何在VC下创建
DLL
首先要建立一个Win32的
DLL
工程。再把普通静态库的所有文件转移到
DLL
工程中,然后: 为所有的类声明加上__declspec(
dll
export)关键字,这有这样编译器才能自动为你产生引入库文件(否则你需要自己写.def文件来产生,因为不常用所以在此不再阐述其细节) 对于
DLL
的用户来讲,类声明就需要用另外一个关键字__declspec(
dll
import)(此关键字对于类和函数而言并非必须,但对于变量而言则是必须的)。所以通常我们会定义一个宏来包装之,比如 #ifdef MY
DLL
_EXPORTS # define MY
DLL
_API __declspec(
dll
export) #else # define MY
DLL
_API __declspec(
dll
import) #endif 这样我们就能写出如下的类 class MY
DLL
_API MyClass { ... }; 当然在创建
DLL
的工程里需要包含preprocessor(预处理指示器)MY
DLL
_EXPORTS,而在用户工程里面则不应该包含MY
DLL
_EXPORTS。 其实上面说的VC早就帮我们做好了。如果你创建的
DLL
工程叫做Test,那么此工程自动包含TEST_EXPORTS。如果你在创建工程的时候选择了Exprot Symbols, 那么VC还会自动帮你创建一个示例文件Test.h,此文件定义出 #ifdef TEST_EXPORTS # define TEST_API __declspec(
dll
export) #else # define TEST_API __declspec(
dll
import) #endif 你自定义的文件都应该包含此文件以使用TEST_API。(如果
没有
选择Exprot Symbols,那么就得自己动手写出这段宏了) 示例文件中还包括了一个类,变量,以及全局函数的写法 class TEST_API CTest { public: CTest(void); // TODO: add your methods here. }; extern TEST_API int nTest; TEST_API int fnTest(void); 通过上面的示例我们也可以看出全局(或者名字空间)变量和函数的声明方法 细节讨论 1.
DLL
的入口函数
Dll
Main并非必须,如果
没有
它,编译器会帮你自动生成一个不做任何事的
Dll
Main。 2. 如果是可以定义在
头文件
里面的东西:包括宏,常量,内联函数(包括成员内联函数)以及模板。那么在
DLL
中的定义中可以不必包含TEST_API,和普通的定义
没有
区别。 如果一个类完全由内联函数和纯虚函数构成,那么也不需要TEST_API这样的关键字。一个不带成员函数的struct也一样。 3. 所有未经__declspec(
dll
export)导出的类都只能作为
DLL
内部类使用。当然外部仍然可以使用其内联成员函数(
前提
是该成员函数不应该
调用
任何未经导出的函数或者类成员函数) 发布
DLL
1. 程序库的作者应该将三件套:
头文件
,引入库文件和
DLL
一同发布给用户,其中
头文件
和引入库是专为静态
调用
的用户准备,也就是C/C++用户。(此外有些
DLL
内部使用的
头文件
,如果
没有
被接口
头文件
直接#include,那么该
头文件
就不必发布,这和静态库是一样的)。 2.
DLL
的用户只需将
DLL
和可执行程序一同发布即可。 C++程序使用C语言
DLL
(静态库规则一样) C不存在class, 所以由C创建的
DLL
必然也不会出现class;对于全局变量的使用C和C++
没有
什么不同,所以我们把焦点集中在全局函数上(此外全局变量的规则一样)。 我们知道C++程序要使用C语言的函数就必须在函数声明前加上extern "C"关键字,这对于静态库和
DLL
没有
什么不同。 但是这个关键字不能直接出现在
头文件
函数声明中,否则
DLL
无法通过编译, 原因很简单,C语言并
没有
extern "C"这个关键字。 1. 一种作法是把C向C++迁移的责任交给
DLL
创建者。定义出一个宏,以使
DLL
(C工程)中不出现extern "C"或者只是extern,而在用户工程(C++工程)中保持原样。幸运的是windows早已为我们设计好一切,这个宏就是EXTERN_C(存在于 winnt.h中) : #ifdef __cplusplus #define EXTERN_C extern "C" #else #define EXTERN_C extern #endif 注意上面必须是extern而不是空。因为虽然C的函数声明不是必须添加extern,但是变量声明则必须添加extern。 有了EXTERN_C,在
头文件
中这样定义函数: EXTERN_C TEST_API int fnTest(void); 2. 另外一种做法是把把C向C++迁移的责任交给用户,用户在包含
DLL
头文件
的时候以extern "C"来include: extern "C" { #include "my
dll
.h" #include "my
dll
core.h" ... } 可以把上述的extern "C"段放在新的
头文件
中和
DLL
一起发布,这样C++用户只需要包含这个
头文件
就可以了。比如Lua库就自带了一个etc/lua.hpp文件。通常此文件会由
DLL
作者提供,所以此时迁移的责任仍在
DLL
创建者。 注意用户不要试图以extern "C"来重新声明函数,因为重复声明是允许的,但是必须保证和
头文件
中的声明相同。 3. 这种做法的一个变形就是直接在C
头文件
中以extern "C"将所有函数和变量声明包含之,这样就无需像上面那样多提供一个额外的
头文件
了。通常像这样(my
dll
头文件
): #include
头文件
段 #ifdef __cplusplus extern "C" { #endif 函数和变量声明 ... #ifdef __cplusplus } #endif 创建标准的
DLL
,使其可被其他语言使用 通常我们会希望
DLL
能够被其他语言使用,因而我们的
DLL
往往不会提供类定义,而只提供函数定义。(因为许多编程语言是不支持类的)。 此时函数的
调用
约定必须是__stdcall(在vc下默认是__cdecl,所以你不得不手工添置),因为大部分语言不支持__cdecl,但支持__stdcall(比如VBScript,Delphi等)。 此外我们希望导出到
DLL
中的函数名能够更易被识别(用户使用才会更方便),也就是说
DLL
应该编译出无修饰的C函数名。 所以我们可能会 1. 如果你只用C语言,那么必然以C文件创建
DLL
(自动编出C符号名),考虑到潜在的C++用户(此类用户多以静态
调用
方式使用
DLL
,因而需要看到其函数声明),我们还需要使用EXTERN_C关键字(详见上面的讨论)。 2. 如果你使用C++,那么必然以C++文件创建
DLL
,这时你应该直接以extern "C"修饰。 结论 所以要创建能够为任意编程语言使用之
DLL
,我们应该 1. 只创建函数 2. 声明__stdcall
调用
约定(或者WINAPI,CALLBACK,
前提
是你必须包含windows
头文件
) 3. 以CPP文件 + extern "C" 或者 C文件 + EXTERN_C 4. 当然还需要
DLL
_API的声明(如果光有
dll
export,那么
DLL
也只能被显示
调用
)。 更完美一点 不应该使用
dll
export和extern "C"而应该使用.def文件。虽然经过上面的4个步骤,我们的
DLL
里面的C函数名已经相当简洁了,但仍不是最完美的:比如一个声明为function的函数,实际在
DLL
中的名字确可能是function@#。而使用.def文件,我们可以让
DLL
中的函数名和声明的函数名保持一致。 关于.def的详细用法可参考: 微软
DLL
专题 使用 DEF 文件从
DLL
导出 在
DLL
与静态库之间切换 前面我曾经提到对于使用
DLL
的用户__declspec(
dll
import)关键字可有可无,当然
前提
是
DLL
中不包括变量定义。 所以要把库既能够做成
DLL
,也能够做成静态库,那么就应该作出类似下面这样的定义: 1.
DLL
不包括变量的定义 #ifdef TEST_EXPORTS # define TEST_API __declspec(
dll
export) #else # define TEST_API #endif 然 后只要把工程的配置属性(Configuration Type)简单地在Static Library (.lib)或者Dynamic Library (.
dll
)切换即可(VC会自动地为
DLL
添加预处理器TEST_EXPORTS,为静态库取消TEST_EXPORTS)。 2.
DLL
包含变量定义,也是标准的做法 #ifdef TEST_BUILD_AS_
DLL
#ifdef TEST_EXPORTS # define TEST_API __declspec(
dll
export) #else # define TEST_API __declspec(
dll
import) #endif #else #define TEST_API #endif 如果要将库做成
DLL
,那么需要
DLL
创建者添加预处理器TEST_BUILD_AS_
DLL
和TEST_EXPORTS,后者通常由编译器自动添加;如果做成静态库则不需要添加任何预处理器。 用户则可以通过添加或取消TEST_BUILD_AS_
DLL
来使用动态库或静态库。 对于
DLL
的用户,TEST_BUILD_AS_
DLL
这个名称似乎起得不好。下面的做法或许会更合理些: #if defined(TEST_API) #error "macro alreday defined!" #endif #if defined(TEST_BUILD_
DLL
) && defined(TEST_USE_
DLL
) #error "macro conflict!" #endif #if defined(TEST_BUILD_
DLL
) // build
dll
# define TEST_API __declspec(
dll
export) #elif defined(TEST_USE_
DLL
) // use
dll
# define TEST_API __declspec(
dll
import) #else // build or use library, no preprocessor needs # define TEST_API #endif 相关链接 微软
DLL
专题 Windows API编程之动态链接库(
DLL
)
我的 串口 modbus
dll
本动态库 c++
调用
方式 1.添加
头文件
和动态库文件 #include "myModbus.h" #pragma comment(lib, "myModebus.lib") 2.
调用
功能函数 //打开串口 可设置 波特率 停止位 校验位 等 CmyModbus t_mod; t_mod.openPort(1,9600); //发送数据
前提
打开串口 bool a = t_mod.sendMsg("aslkdjf"); //设置接收包 char rstBuff[100]; UINT a; //接收数据
前提
打开串口 bool b = t_mod.getMsg(rstBuff, a); b = !b;
VC++动态链接库(
dll
)编程视频教学
动态链接库的开发编译属于VC++程序员技能。 本课程学习之后能够理解动态链接库原理,学会编译静态库、动态库,学会通过lib和
头文件
链接动态库,学会直接通过代码访问
dll
中函数
qucsdk:Qt编写的自定义控件插件的sdk集合,包括了各个操作系统的动态库文件以及控件的
头文件
和sdk使用demo。心中有坐标,万物皆painter,欢迎各位咨询、购买、定制控件,QQ:517216493 微信:feiyangqingyun
项目介绍 Qt编写的自定义控件插件的sdk集合,包括了各个操作系统的动态库文件以及控件的
头文件
和sdk使用demo。 体验地址 体验地址: 提取密码:877p 文件名称:bin_quc.zip 尊贵提示:可付费购买控件完整源码,每个控件都有独立的使用demo 版本说明 sdk分带日期的目录,建议用新版本。 其他文件夹为对应日期的版本,而且同时提供了debug和release的动态库。
头文件
请使用对应文件夹下的
头文件
,因为控件一直在升级完善。 强烈推荐使用最新版,目前共163个控件。 理论上小版本向上向下兼容的,比如5.12.3的
dll
可以放到5.12.0中使用。 目录说明 sdk目录下的include文件为控件对应的
头文件
。 sdk目录为各个Qt版本对应的动态库文件。 sdkdemo目录为演示如何
调用
动态库文件。 snap目录为各个控件的运行效果图,一直更新。 使用说明 第一步:
前提
是q
基于SIP开发软件电话的一些资源(转自YOUTOO)
摘自:http://mbstudio.spaces.live.com/blog/cns!C898C3C40396DC11!955.entry 2007/1/30 oSIP协议栈(及eXoSIP,Ortp等)使用入门(原创更新中) (CopyLeft by Meineson | www.mbstudio.cn,原创文章,欢迎转载,但请保留出处说明!) 本文档最新版本及文中提到的相关源码及VC6工程文件请在本站找,嘿嘿~~ (首页的SkyDriver公开文件夹中,可能需要用代理才能正常访问该空间——空间绝对稳定,不会丢失文件!) (最近工作重心不在SIP开发,SO本文档也
没有
机会更新,有技术问题也请尽量咨询他人,本人不一定能及时回复。) 一直没空仔细研究下oSIP,最近看到其版本已经到了3.x版本,看到网上的许多帮助说明手册都过于陈旧,且很多文档内容有点误人子弟的嫌疑~~ Linux下oSIP的编译使用应该是很简单的,其Install说明文档里也介绍的比较清楚,本文主要就oSIP在Windows平台下VC6.0开发环境下的使用作出描述。 虽然oSIP的开发人员也说明了,oSIP只使用了标准C开发库,但许多人在Windows下使用oSIP时,第一步就被卡住了,得不到oSIP的LIB库和DLL库,也就
没有
办法将oSIP使用到自己的程序中去,所以第一步,我们将学习如何得到oSIP的静态和动态链接库,以便我们自己的程序能够使用它们来成功编译和执行我们的程序。 第一阶段: ------------------------------------------------------ 先创建新工程,网上许多文档都介绍创建一个Win32动态链接库工程,我们这里也一样,创建一个空白的工程保存。 同样,将oSIP2版本3.0.1 src目录下的Osipparser2目录下的所有文件都拷到我们刚创建的工程的根目录下,在VC6上操作: Project-Add To Project-Files 将所有的源程序和
头文件
都加入到工程内,保存工程。 这时,我们可以尝试编译一下工程,你会得到许多错误提示信息,其内容无非是找不到osipparser2/xxxxx.h
头文件
之类。 处理:在Linux下,我们一般是将
头文件
,lib库都拷到/usr/inclue;/usr/lib之类的目录下,c源程序里直接写#include 时,能直接去找到它们,在VC里,同样的,最简单的方法就是将oSIP2源码包中的Include目录下的 osipparser2目录直接拷到我们的Windows下默认包含目录即可,这个目录在VC6的Tool-Options-Directories里设置,(当然,如果你知道这一步,也可以不用拷贝文件,直接在这里把oSIP源码包所在目录加进来就可以了),默认如果装在C盘,目录则为 C:\Program Files\Microsoft Visual Studio\VC98\Include。 这时,我们再次编译我们的工程,顺利编译,生成osipparser2.
dll
,这时,网上很多文档里可能直接就说,这一步也会生成libs目录,里面里osipparser2.lib文件,但我们这里
没有
生成:) 最简单的方法,不用深究,直接再创建一个工程,同上述创建动态链接库方法,创建一个Win32静态链接库工程,直接编译,即可得到osipparser2.lib。 ------------------------------------------------------ 上面,我们得到了Osip的解析器开发库,下面再编译完整的Osip协议栈开发库,同样照上述方法,分别创建动态链接库工程和静态链接库工程,只是要拷的文件换成src下的osip目录下文件和include下的osip目录,得到osip2.
dll
和osip2.lib。 在编译osip2.
dll
这一步可能会再次得到错误,内容含义是找不到链接库,所以,我们要把前面编译得到的osipparser2.lib也拷到osip工程目录下,并在VC6中操作: Project-Setting-Link中的Object/Library Modules: kernel32.lib user32.lib ... xxx.lib之类的内容最后增加: osipparser2.lib 保存工程后再次编译,即可成功编译osip2.
dll
。 ------------------------------------------------------ 至此,我们得到了完整的oSIP开发库,使用时,只需在我们的程序里包含oSIP的
头文件
,工程的链接参数里增加osipparser2.lib和osip2.lib即可。 ------------------------------------------------------ 下面我们验证一下我们得到的开发库,并大概了解一下OSIP的语法规范。 在VC里创建win32控制台程序工程,将libosip源码包的SRC目录下的Test目录内的C源程序随便拷一个到工程时,直接编译(工程设置里照前文方法在link选项里增加osip2.lib,osipparser2.lib引用我们之前成功编译得到的静态库文件)就可以运行(带参数运行,参数一般为一个文本文件,同样从Test目录的res目录里拷一个与源文件同名的纯文本文件到工程目录下即可)。 该目录下的若干文件基本上是测试了Osip的一些基本功能函数,例如URI解析之类,可以大概了解一下oSIP的语法规范和
调用
方法,同时也能校验一下之前编译的OSIP开发库能否正常使用,成功完成本项工作后,可以进入下一步具体的oSIP的使用学习了。 ------------------------------------------------------ 由于oSIP是比较底层的SIP协议栈实现,新手较难上手,而官方的示例大都是一些伪代码,需要有实际的例子程序参考学习,而最好的例子就是同样官方发布的oSIP的扩展开发库exosip2,使用exoSIP可以很方便地快速创建一个完整的SIP程序(只针对性地适用于SIP终端开发用,所以我们这里只是用它快速开发一个SIP终端,用来更方便地学习oSIP,要想真正掌握SIP的开发,需要掌握oSIP并熟读RFC文档才行,exoSIP不是我们的最终学习目的),通过成功编译运行一个自己动手开发出的程序,再由浅入深应该是初学都最好的学习方法通过对使用exosip开发库的使用创建自己的SIP程序,熟悉后再一个函数一个函数地深入学习exosip提供的接口函数,就可以深入理解osip 了,达到间接学习oSIP的目的,同时也能从eXoSIP中学习到正确使用oSIP的良好的编程风格和语法格式。 而要成功编译ExoSIP,似乎许多人被难住了,直接在XP-sp2上,用VC6,虽然你使用了eXoSIP推荐的winsock2.h,但是会得到一个 sockaddr_storage结构不能识别的错误,因为vc6自带的开发库太古董了,需要升级系统的Platform SDK,下载地址如下: http://www.microsoft.com/msdownl ... PSP2FULLInstall.htm(VC6的支持已经停止,这是VC6能使用的最新SDK) 成功安装后编译前需加OSIP_MT宏,以启用线程库,否则在程序中使用eXoSIP库时会出错,而编译时也会得到许多函数未定义的Warning提示,编译得到exosip2.lib供我们使用,当然,在此之前需要成功编译了osip2和osipparser2,而在之后的实际使用时,发现oSIP也需要增加OSIP_MT宏,否则OSIP_MT
调用
oSIP的线程库时会出错,所以我们需要重新编译oSIP了:),因为eXosip是基于oSIP的(同上方式创建静态和动态链接库工程,并需在Link中手工添加oSIP和oSIPparser的lib库)。 ------------------------------------------------------ 创建新工程,可以是任意工程,我们从最简单的Win32控制台程序开始,为了成功使用oSIP,我们需要引用相关库,
调用
相关
头文件
,经过多次试验,发现需要引用如下的库: exosip2.lib osip2.lib osipparser2.lib WSock32.Lib IPHlpApi.Lib WS2_32.Lib Dnsapi.lib 其中,除了我们上面编译得到的三个oSIP库外,其它库都是系统库,其中有一些是新安装的Platform SDK所新提供的。 至此,我们有了一个简单的开发环境了,可以充分利用网上大量的以oSIP为基础的代码片段和官方说明文档开始具体函数功能的测试和使用了:) ------------------------------------------------------ 我们先进行一个简单的纯SIP信令(不带语音连接建立)的UAC的SIP终端的程序开发的试验(即一个只能作为主叫不能作为被叫的的SIP软电话模型),我们创建一个MFC应用程序,对话框模式,照上面的说明,设置工程包含我们上面得到的oSIP的相关开发库及SDK的一些开发库,并且由于默认LIBC的冲突,需要排除MSVCRT[D]开发库(其中D代表Debug模式下,
没有
D表示Release模式下),直接使用eXosip的几个主要函数就可以创建一个基本的SIP软电话模型。 其主要流程为: 初始化eXosip库-启动事件监听线程-向SIP Proxy注册-向某SIP终端(电话号码)发起呼叫-建立连接-结束连接 初始化代码: int ret = 0; ret = eXosip_init (); eXosip_set_user_agent("##YouToo0.1"); if(0 != ret) { AfxMessageBox("Couldn't initialize eXosip!\n"); return false; } ret = eXosip_listen_addr (IPPROTO_UDP, NULL, 0, AF_INET, 0); if(0 != ret) { eXosip_quit (); AfxMessageBox("Couldn't initialize transport layer!\n"); return false; } 启动事件监听线程: AfxBeginThread(sip_uac,(void *)this); 向SIP Proxy注册: eXosip_clear_authentication_info(); eXosip_add_authentication_info(uname, uname, upwd, "md5", NULL); real_send_register(30); /* 自定义函数代码请见源码 */ 发起呼叫(构建假的SDP描述,实际软电话使用它构建RTP媒体连接): osip_message_t *invite = NULL; /* 呼叫发起消息体 */ int i = eXosip_call_build_initial_invite (&invite, dest_call, source_call, NULL, "## YouToo test demo!"); if (i != 0) { AfxMessageBox("Intial INVITE failed!\n"); } char localip[128]; eXosip_guess_localip (AF_INET, localip, 128); snprintf (tmp, 4096, "v=0\r\n" "o=josua 0 0 IN IP4 %s\r\n" "s=conversation\r\n" "c=IN IP4 %s\r\n" "t=0 0\r\n" "m=audio %s RTP/AVP 0 8 101\r\n" "a=rtpmap:0 PCMU/8000\r\n" "a=rtpmap:8 PCMA/8000\r\n" "a=rtpmap:101 telephone-event/8000\r\n" "a=fmtp:101 0-11\r\n", localip, localip, "9900"); osip_message_set_body (invite, tmp, strlen(tmp)); osip_message_set_content_type (invite, "application/sdp"); eXosip_lock (); i = eXosip_call_send_initial_invite (invite); eXosip_unlock (); 挂断或取消通话: int ret; ret = eXosip_call_terminate(call_id, dialog_id); if(0 != ret) { AfxMessageBox("hangup/terminate Failed!"); } 可以看到非常简单,再借助于oRTP和Mediastreamer开发库,来快速为我们的SIP软电话增加RTP和与系统语音API接口交互及语音编码功能,即可以快速开发出一个可用的SIP软电话,关于oRTP和Mediastreamer的相关介绍不是本文重点,将在有空的时候考虑增加相应使用教程,文章
前提
到的地方可以下载基本可用的完整SIP软电话的VC源码工程文件供参考使用,完全CopyLeft,欢迎转载,但请在转载时注明作者信息,谢谢! 第二阶段: --------------------------------------------------- 得到了一个SIP软电话模型后,我们可以根据软电话的实际运行表现(结合用Ethereal抓包分析)来进行代码的分析,以达到利用eXoSIP来辅助我们学习oSIP的最终目的(如要快速开发一个可用的SIP软电话,请至前面提到的论坛去下载使用oRTP和Mediastreamer快速搭建的一个基本完整可用的SIP软电话##YouToo 0.1版本的VC源码工程文件作参考)。 现在从eXosip的初始化函数开始入手,来分析oSIP的使用,这是第二阶段,第三阶段就是深入学习oSIP的源码了,但大多数情况下应该
没有
必要了,因为在第二阶段就有部分涉及到第三阶段的工作了,而且oSIP的源码也就大多是一些SIP数据的语法解析和状态机的实现,能深入理解了SIP协议后,这些只是一种实现方式,没必要完全去接受,而是可以用自己的方式和风格来实现一套,比如,更轻量化更有适用目的性的方式,oSIP则只起参考作用了。 eXosip_init()是eXosip的初始化函数,我们来看看它的内部实现: 首行是定义的 osip_t *osip,这在oSIP的官方手册里我们看到,所有使用oSIP的程序都要在最开始处声明一个osip_t的指针,并使用 osip_init(&osip)来初始化这个指针,销毁这个资源使用osip_release(osip)即可。 我们可以在代码中看到很多OSIP_TRACE,这是调试输出宏
调用
了函数osip_trace,可以用ENABLE_TRACE宏来打开调试以方便我们开发调试。 其它就是很多的eXosip_t的全局变量eXosip的一些初始化操作,包括最上面的memset (&eXosip, 0, sizeof (eXosip))完全清空和下面的类似eXosip.user_agent = osip_strdup ("eXosip/" EXOSIP_VERSION)的exosip变量的一些初始值设置,其中有一个eXosip.j_stop_ua = 0应该是一个状态机开关,后面可以看到很多代码检测这个变量来决定是否继续流程处理,默认置成了0表示现在exosip的处理流程是就绪的,即ua是 not stop的。 osip_set_application_context (osip, &eXosip)是比较有意思的,它让下面的eXosip_set_callbacks (osip)给osip设置大量的回调函数时,能让osip能访问到eXosip这个全局变量中设置的大量程序运行时交互的信息,相当于我们在VC下开启一个线程时,给线程传入的一个void指针指向我们的MFC应用程序的当前dialog对象实例,可以用void *osip_get_application_context (osip_t * osip)这个函数来取出指针来使用,不过好象exosip中并
没有
用到它,可能是留给个人自已扩展的吧:) 还能看到初始化代码前面有一段WIN32平台下的SOCK的初始化代码,可以知道eXosip是用的原生的winsock api函数,也就是我们可能以前学过的用VC和WINAPI写sock程序时(不是MFC),用到的那段SOCK初始代码,还有一段有意思的代码,就是 jpipe()函数,它们返回的是一个管道,一个有2个整型数值的数组(一个进一个出),查看其代码发现,非WIN32平台是直接使用的pipe系统函数,而WIN32下则是用一对TCP的本地SOCK连接来模拟的管道,一个SOCK写一个SOCK读,这段代码是比较有参考价值的:) j = 50; while (aport++ && j-- > 0) { raddr.sin_port = htons ((short) aport); if (bind (s, (struct sockaddr *) &raddr, sizeof (raddr)) transactionid)); } 即,只是打印一下调试,并
没有
完整实现什么功能,我们学习时,完全可以用相同的方法,定义一大堆回调函数,并不忙想怎么完全实现,先都是只打印一下调试信息,看具体的应用逻辑根据抓包测试分析和看调试看程序走到了哪一步,
调用
了哪一个回调,来明白具体回调函数要实现什么用途,再来实现代码就方便多了,当然,如果看透了RFC文档,应该从字面就能知道各个回调函数的用途了,这是后话,不是谁都能快速完全看懂RFC的,所以我们要参考eXosip:) 我们对其中的重要的回调函数进行逐个的分析: --------------------------- osip_set_cb_send_message (osip, &cb_snd_message) SIP消息发送回调函数 这个函数可能是最重要的回调函数之一,消息发送,包括请求消息和回应消息,一般情况下,状态机的状态就是由它控制的,发起一个消息初始化一个状态机,回应一个消息对状态机修改,终结消息发送结束状态机…… 看cb_snd_message的函数实现,要以发现,其主要代码是对参数中的要发送的消息osip_message_t * sip进行分析,找出消息要发送的真实char *host,int port的值(这些参数可以省略,但要发送消息肯定需要host和port,所以要从sip中解析),最后根据sip中解析出的传输方式是TCP还是 UDP选择最终进行消息发送处理的函数cb_udp_snd_message,cb_tcp_snd_message处理(它们的参数一致,即本函数只是补全一些省略的参数并对消息进行合法性检查)。 **毕竟eXosip是一个通用的开发库,它考虑了要支持TCP,UDP,TCPs,IPV4,IPV6,WIN32,*nix,WINCE等等多样化的复杂环境,所以,我们可以略过我们暂时不需要的部分,比如,IPV6相关的代码实现等。 由于我们大多数情况下SIP是用的UDP,所以先来看一下cb_udp_snd_message的实现,它从全局变量exosip中获取可用的 sock,并尽最大能力解析出host和port(??难道前面的函数还不够解析彻底??如最终仍无port信息则默认设置为5060),使用 osip_message_to_str (sip, &message, &length)函数将要发送的格式化的SIP消息转换成能用SOCK传输的简单数据并发送即完成消息发送,代码中有许多复杂的环境探测和错误控制等等等等,我们可以暂时不用过多关注,可以继续向下,结尾处有一个keeplive相关代码,从代码字面分析,可能是SIP的Register消息的自动重发相关代码,可以在后面再细化分析。 cb_tcp_snd_essage的函数实现要比上文的udp的实现简单很多,主要是环境探测错误控制方面,因为毕竟tcp是稳定连接的,对比一下代码,可以看到主要流程还是将SIP消息转换后,发送到从SIP消息中解析出的host和port对应的目标。 看完两个函数,可以知道,eXosip需要有两个sock,是一个数组,0是给UDP用的,1是给TCP用的,要用SOCK当然要初始化,就是下文要介绍的eXosip的网络相关的初始化了,上面的exosip_init可以看成是这个开发库的系统初始化吧:) 至些,我们应该知道了oSIP开发的SIP应用程序的消息是从哪里发出的吧,对了,就是从这个回调函数里,所谓万事开头难,就象开发WIN32应用程序时,找到了WIN32程序的main函数入口下面的工作就好办了,下面就都是为一些事件消息开发对应的处理函数而已了:) osip_set_kill_transaction_callback 事务终结回调函数 对应ICT,IST,NICT,NIST客户/服务器注册/非注册事务状态机的终结,主要是使用osip_remove_transaction (eXosip.j_osip, tr)将当前tr事务删除,再加上一系列的清理工作,其中,NICT即客户端的非Invite事务的清理比较复杂一些,要处理的内容也比较多,可以根据实际应用的情况进行有必要的清理工作:) cb_transport_error 传输失败处理回调 对应于上面说到的四种事务状态机,如果它们在处理时失败,则在这时进行统一处理。 从代码可知,只是在NOTIFY,SUBSCRIBE,OPTION操作失败才进行处理,其它错误可直接忽略。 osip_set_message_callback 消息发送处理回调 根据type不同,表示不同的消息发送状态 OSIP_XXX_AGAIN 重发相关消息 OSIP_ICT_INVITE_SENT 发起呼叫 OSIP_ICT_ACK_SENT ACK回应 OSIP_NICT_REGISTER_SENT 发起注册 OSIP_NICT_BYE_SENT BYE发出 OSIP_NICT_CANCEL_SENT Cancel发出 OSIP_NICT_INFO_SENT,OSIP_NICT_OPTIONS_SENT,OSIP_NICT_SUBSCRIBE_SENT,OSIP_NICT_NOTIFY_SENT,OSIP_NICT_UNKNOWN_REQUEST_SENT 我们可以看到,eXosip
没有
对它们作任何处理,我们可以根据自己需要,比如,重发2xx消息前记录一下日志之类的,扩展一下retransmission的处理方式,发起Invite前记录一下通话日志等等。 OSIP_ICT_STATUS_1XX_RECEIVED uac收到1xx消息,一般是表示对端正在处理中,这时,主要是设置一下事务状态机的状态值,并对会话中的osip的一些参数根据返回值进行相应设置,里面有许多条件判断,但我们常用的一般是100,180,183的判断而已,暂时可以忽略里面复杂的判断代码。 OSIP_ICT_STATUS_2XX_RECEIVED uac收到2xx消息,这里主要跟踪一下Register情况下的2xx,表示注册成功,这时会更新一下exosip的注册字段值,以便让eXosip能自动维护uac的注册,BYE的2xx回应是终结消息,Invite的2xx回应,则主要是初始化一下会话相关的数据,表示已成功建立连接。 其它4xx,5xx,6xx则分别是对应的处理,根据实现情况进行概要的查看即可。 report_event (je, sip)是代码中用来进行事件处理的一个函数,跟踪后发现,其最终是使用了我们上文提到的jpipe管道,以便在状态机外实时观测状态机内的处理信息。 OSIP_NIST_STATUS_XXX_SENT即对应于上面的uac的处理,这里是uas的对应的消息处理,相比较于uac简单一点。 前面简单介绍了一下大量的回调函数及它们的概要处理逻辑,可能会比较混乱,暂时不用管它,只需要记得一个大概的形象,知道一个SIP处理程序是通过osip_set_cb_send_message回调函数来实现真实地发送各种SIP消息,并且SIP的标准事务模型是由oSIP实现好了,我们只需要给不同的事务状态设置不同的回调处理函数来处理事务,具体的状态变化和内部逻辑不用管就可以了。 下面来说一下消息处理回调函数用到的SOCK的初始化函数,即我们上面说的除了系统初始化外的网络初始化函数eXosip_listen_addr: 从上文知道了,系统将初始化两个SOCK,一个UDP一个TCP,但查看代码发现还有第三个,TCPs的,但好象还不能实用,现在不管它,代码首先是根据传输是UDP还是TCP来设置对应的数组值,并且如果
没有
提供IP地址和端口号,系统会自动取出本机网络接口并创建可用的SOCK(http_port 的方式暂不用考虑)。 SOCK初始化后,如何开始SIP事务的呢?看到这个
调用
eXosip.j_thread = (void *) osip_thread_create (20000, _eXosip_thread, NULL),对的,这里启用了一个线程,即,eXosip是
调用
oSIP的线程函数(没用系统提供的线程函数,是为了跨平台)进行事务处理的状态机逻辑是在一个线程中处理的,这样就明白了为什么一直没能看到顺序执行下来的程序启动代码了,接下去看,线程实际处理函数是_eXosip_thread,这里面的代码中,我们看到了上文提到的状态机控制开关变量while (eXosip.j_stop_ua == 0),即,当j_stop_ua设置为1时,osip_thread_exit ()结束事务处理即程序终结,再接下去看,_eXosip_execute是最终的处理函数了,而且它在程序未终结情况下是一直逻辑在执行,注意,要启用oSIP的多线程宏OSIP_MT。 看到_eXosip_execute的代码中有很多时间函数和变量,仔细看,除去一些控制代码,主要处理函数是eXosip_read_message (1, lower_tv.tv_sec, lower_tv.tv_usec),即取出消息,1表示只取出一条消息,其代码量非常的大,但同样的,其中也许多的控制代码和错误检测代码,我们在查看时可以暂时忽略掉它们。 eXosip_read_message读取消息时,即
没有
采用sock的block也
没有
用非block方式,而是采用了select方式,具体应用可查询fd_set相关文档。 根据jpipe_read (eXosip.j_socketctl, buf2, 499),我们可以估计,buf2中应该是保存的我们的控制管道的数据,具体作用至些还
没有
表现出来,应该是用来反映一些状态机内部的警示之类的信息,实际的SIP的处理的状态机的数据是存放在buf中,使用_eXosip_recvfrom获取的,获取后sipevent = osip_parse (buf, i)解析,使用osip_find_transaction_and_add_event (eXosip.j_osip, sipevent)来查询事件对应的事务状态机,找到后就如同其注解所说明的,/* handled by oSIP ! */,即我们上文设置的那一大堆回调函数,至此,我们知道了整个SIP应用所处理的大概流程了。 如果
没有
找到事务状态机呢?直接丢弃吗?不是的,如果这是一个回应消息,但
没有
事务状态机处理它,那它是一个错误的,要进行清理后才能丢弃,而如果是一个请求,那更不能丢弃了,因为UAS事务状态机要由它来启动创建的(回应消息表示本地发出了请求消息,即UAC行为,事务状态机应是由启动UAC的代码初始化启动的),整个逻辑应该是很简单的,但eXosip的实现代码却非常多,可见其花了非常多的精力在保证会话的稳定性和应付网络复杂情况上,我们可以对其进行大量的精简来构建满足我们需求的代码实现。 先来看错误的回应消息的处理函数eXosip_process_response_out_of_transaction,可以看到其代码就是一大堆的赋值语句,XXX= NULL,即将一大堆的运行时变量清空,再
调用
osip_event_free清空事件,或者就是一些复杂的情况下,需要通过解析现在的运行时数据,从中分析出“可能”的正在等待回应的对端,并发送相关终结通知消息等等,可以根据实际需要进行简化。 请求事件的处理 eXosip_process_newrequest,首先是对事件进行探测,MSG_IS_INVITE、MSG_IS_ACK、 MSG_IS_REQUEST……,对事件进行所属状态机分类,随后使用_eXosip_transaction_init (&transaction,(osip_fsm_type_t) tx_type,eXosip.j_osip, evt->sip)根据探测结果进行状态机初始化,实际
调用
的是osip_transaction_init,初始化后即将事件入状态机 osip_transaction_add_event (transaction, evt),由状态机自动处理后
调用
相应回调函数处理逻辑了。当然,eXosip为方便快速开发SIP终端应用,在下面又添加了许多自动化的处理代码,来和我们在回调函数中设置的处理代码相区分。 线程
调用
的事件处理函数代码最后是 if (eXosip.keep_alive > 0) { _eXosip_keep_alive (); } 这段代码印证了上文提到了,keep_alive是用来设置是否自动重新注册,由_eXosip_keep_alive函数来实现自动将eXosip全局变量中保存的注册消息解析后自动根据需要重新向SIP服务器发起Register注册。 同样,因为注册消息发起是UAC的行为,将它放在这里,可以看出来所有事件消息的事务状态机处理都是在这里,只不过这里只创建UAS的事务状态机,UAC的事务状态机的创建则要继续到下面找了,从我们的YouToo软电话代码中可知,发起呼叫和发起注册分别
调用
了 eXosip_call_send_initial_invite,eXosip_register_send_register这两个函数(另外用到的两个build函数则是分别构建这两个send函数要发送的SIP消息),查看这两个函数可知,UAC的事务处理状态机是在这里进行初始化的。 eXosip_register_send_register中可以看到是_eXosip_transaction_init (&transaction, NICT, eXosip.j_osip, reg)初始化UAC状态机,实际也同UAS是
调用
的osip_transaction_init函数,同样使用 osip_transaction_add_event (transaction, sipevent)将事件入状态机,状态机随后将自动处理
调用
相应回调函数处理逻辑了。 另有osip_new_outgoing_sipmessage(reg),表示发送消息,到这里,我们应该可以理解,真实的发送操作,是要到由状态机处理后,
调用
了消息发送回调函数才真正地将注册消息发送出去的。 同注册消息发送,它是NICT状态机,呼叫消息的发送是ICT,由eXosip_call_send_initial_invite处理,_eXosip_transaction_init (&transaction, ICT, eXosip.j_osip, invite)初始化了状态机,之前还有一个eXosip_call_init是用来初始化eXosip的一些参数的,暂时不管它,同样 osip_new_outgoing_sipmessage (invite)发送呼叫消息,但实际还是要状态机处理后
调用
消息发送回调函数真实发送呼叫请求函数的,osip_transaction_add_event (transaction, sipevent)则标准地,将事件入状态机,状态机将能处理随后的应用逻辑
调用
相应的回调函数了。 好了,作了这么多的分析,我们了解了eXosip是怎样
调用
oSIP来形成被我能方便地再次
调用
的了,可以看到,为了实现最大限度的跨平台和兼容性,代码中有大量的测试代码,宏定义和错误再处理代码,看起来非常吃力,但了解了其主要的
调用
框架: 初始化,回调函数设置,UAC和UAS事务处理状态机的启动,事件处理流程等,就可以基本明白了oSIP各个函数的主要作用和正确的用法了,下一步,可以参考eXosip来针对某个应用,去除掉大量暂时用不到的代码,来构建一个简单的SIP软电话和SIP服务器,来进一步深入oSIP学习应用了。 ------------------------------------------------------ [下回预告:完全基于oSIP的软电话实现及oSIP进一步学习] (CopyLeft by Meineson | www.mbstudio.cn,原创文章,欢迎转载,但请保留出处说明!) 附件为原作者提供的
进程/线程/DLL
15,471
社区成员
49,182
社区内容
发帖
与我相关
我的任务
进程/线程/DLL
VC/MFC 进程/线程/DLL
复制链接
扫一扫
分享
社区描述
VC/MFC 进程/线程/DLL
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章