简介面向PowerBuilder开发者的实用排错资源针对将PB工程编译为DLL格式时出现“Error opening file c:\windows\system32\cgen\en32t.h”报错而整理。压缩包内包含编译所需的两个核心头文件以及配套的pch预编译头文件共4个文件整体大小仅596KB。安装时将这些文件放到PB编译工具指定的cgen目录或相应Include路径下即可消除编译中断提示无需再手动搜索或逐一尝试版本。已有598人学习下载适合正在使用PB Classic或早期版本、被DLL编译环境问题困扰的开发者。借助pch文件还能保持预编译头与编译环境的一致性提升编译成功率是快速解决缺失头文件、恢复编译流程的轻量方案。资源体量小、文件结构清晰几分钟内即可完成配置对不熟悉cgen目录的初学者尤其友好。 做PB的老哥们应该都遇到过这种尴尬厂商丢过来一个DLL配套资料里躺着一个EN32T.H头文件C工程师照着文档写得好好的到你这边一用PowerBuilder声明外部函数就开始报错。更抓狂的是有时候你只是想拿C语言把这套接口重新封装成DLL给PB调用编译阶段就被这个头文件卡住提示找不到EN32T.H。PowerBuilder和C/C之间这层“翻译”工作绕不开头文件但很多人其实没搞清楚它到底是给谁用的。这篇文章我就从EN32T.H这个具体的头文件出发把PowerBuilder编译DLL、调用DLL这条链路上最容易翻车的几个环节拆开讲清楚包括怎么读头文件、怎么把C的声明翻译成PB能用的外部函数声明、没有头文件时怎么应急以及自己用VC编译封装DLL时要注意的工程细节。内容主要面向正在用PB 9到PB 2022接第三方DLL的开发者尤其是那些被厂商SDK文档“折磨”过的人。1. 先分清两个方向PB直接调DLL还是先拿C代码编译成DLL再给PB用1.1 “PowerBuilder编译成DLL”这个说法十次有九次是误会很多需求文档里写着“把PowerBuilder编译成DLL格式”这个说法本身就有歧义。PowerBuilder在PB 7、PB 8的机器码编译时代确实能把对象编译成DLL文件但那种DLL本质上是PB虚拟机上的扩展库依赖PowerBuilder运行时跟EN32T.H这种C语言头文件没有任何交集。如果你找的是这条路那大概率方向已经偏了。真正跟EN32T.H发生关系的是另外两个场景。第一个场景最简单你的PB程序要直接调用一个第三方DLL厂商给了DLL、给了示例代码还有一个EN32T.H头文件。这个头文件对PB程序本身不是必需的但它是一份“接口契约”里面写清楚了DLL有哪些函数、参数是什么类型、结构体长什么样。PB里看不到这些信息只能用声明外部函数的方式重新描述一遍描述的依据就是头文件。第二个场景更常见第三方DLL的接口太底层参数里有复杂的指针类型、嵌套结构体直接声明太痛苦于是你决定用C/C写一个薄封装层编译一个中间DLL给PB调用。这时候EN32T.H就成了编译器的必需品你的C源文件要#include EN32T.h才能拿到函数原型和结构体定义编译器找不到它工程直接编译不过。1.2 EN32T.H到底是给谁用的它又不在PB里运行理解这一点后面所有操作就顺了EN32T.H只服务于C/C编译过程它不会被打包到PB应用里也不参与PB运行时的任何动作。PB只认DLL的导出函数名、函数参数列表和调用约定它不解析头文件。你可以把EN32T.H理解成一张菜单。餐厅后厨C/C编译器按照菜单做菜编译出DLL你作为顾客PB程序只需要知道菜名导出函数名和菜品份量参数类型、返回值不需要钻进后厨看原料。所以PB侧的声明和C侧头文件里的声明可以长得不一样只要最终在二进制层面的调用约定、参数字节数、结构体布局保持一致就能跑通。这意味着一个关键事实哪怕你把EN32T.H弄丢了PB侧也能把DLL调起来只要你足够了解接口行为。反过来如果DLL是别人编译的你也没有原始工程那EN32T.H就成了最可靠的参考资料比搜索引擎里那些来路不明的说明靠谱一百倍。2. 读EN32T.H只抓四个关键信息函数原型、结构体、常量宏、调用约定2.1 一个典型的EN32T.H头文件长什么样厂商的SDK头文件格式五花八门但万变不离其宗。我手上这类设备接口头文件基本是下面这种结构我简化了一下关键词#ifndef EN32T_H #define EN32T_H #define EN32T_SUCCESS 0 #define EN32T_ERR_OPEN -1001 #define EN32T_ERR_READ -1002 typedef struct { char deviceId[16]; int status; long lastError; } EN32T_DEVICE_INFO; #ifdef __cplusplus extern C { #endif int WINAPI EN32T_OpenDevice(const char* devName); int WINAPI EN32T_ReadDevice(EN32T_DEVICE_INFO* pInfo); int WINAPI EN32T_CloseDevice(void); #ifdef __cplusplus } #endif #endif拿到这种头文件先别急着往PB里抄你只需要抓四样东西。第一是宏定义也就是#define开头的那些行。它们通常是返回值错误码、状态标志位PB侧要转成CONSTANT声明。第二是typedef struct定义的结构体这是最容易出错的地方字段顺序、字段类型、嵌套关系都不能错。第三是函数原型看返回类型、参数个数、每个参数的类型和传递方向。第四是WINAPI这样的调用约定标记它决定PB声明里要不要处理“函数入栈方式”Windows上通常对应FUNCTION声明的默认方式但心里要有数。2.2 翻译头文件时最容易忽略的两行第一行是extern C。如果头文件里被extern C包住说明这个DLL是用C编译的但导出函数按C命名方式导出没有C的名字修饰name mangling。你在PB里声明的函数名必须和导出表里的原始名字完全一致否则会提示函数找不到。第二行是WINAPI。在Windows SDK里WINAPI就是__stdcall。C语言的默认调用约定是__cdeclPB声明外部函数时默认按标准Windows约定处理。如果你遇到一个DLL导出函数声明没有WINAPI也就是__cdecl并且参数个数不固定那就要小心PB侧声明时有些版本需要用ALIAS FOR加上实际导出名否则栈平衡会出问题轻则返回值异常重则直接崩溃。读头文件的时候把这两行扫一眼能省下后面半天调试时间。3. 把EN32T.H翻译成PB声明一次完整的头文件转换实录3.1 常量、结构体、函数三张对照表一次写对现在按上一节那个头文件写一份PB侧的外部函数声明。第一步先翻译常量和结构体CONSTANT Long EN32T_SUCCESS 0 CONSTANT Long EN32T_ERR_OPEN -1001 CONSTANT Long EN32T_ERR_READ -1002 TYPE EN32T_DEVICE_INFO deviceId[16] AS CHARACTER status AS LONG lastError AS LONG END TYPE这里有个极其经典的坑C语言里的int在Windows平台是32位而PowerBuilder的INTEGER是16位。很多人照着C头文件把status声明成PB的INTEGER结果结构体长度对不上DLL调用直接返回无效数据或者报结构体错误。看到C的intPB这边一律要转成LONG。反过来看到C的longWindows上它也是32位所以PB里还是LONG这点和Linux上的64位long不一样需要格外注意。结构体里还有个容易出问题的地方CHARACTER数组。PB的CHARACTER确实占1字节deviceId[16] AS CHARACTER在内存里就是16个字节和C的char deviceId[16]是能对应上的。但是PB里给这个结构体字段赋值时不能用普通的字符串直接塞得逐位处理或者用Blob转换否则字符串越界会把后面字段冲掉。3.2 REF STRING预分配和CHAR数组的坑函数声明部分这样写FUNCTION Long EN32T_OpenDevice(STRING devName) LIBRARY EN32T.DLL FUNCTION Long EN32T_ReadDevice(REF EN32T_DEVICE_INFO pInfo) LIBRARY EN32T.DLL FUNCTION Long EN32T_CloseDevice() LIBRARY EN32T.DLL先看第一个函数C原型是const char* devNamePB里声明成STRING devName即可PB会以NULL结尾的ANSI字符串方式传进去对应const char*的参数没有任何问题。真正要注意的是那种DLL需要在缓冲区里写回数据的场景比如int WINAPI EN32T_GetVersion(char* buf, int bufSize);对应PB声明要写成FUNCTION Long EN32T_GetVersion(REF STRING buf, Long bufSize) LIBRARY EN32T.DLL调用前必须给字符串预分配空间STRING ls_buf ls_buf Space(256) EN32T_GetVersion(ls_buf, 256)如果不预分配ls_buf是空字符串DLL往里面写数据时会访问到不可用的内存轻则返回乱码重则直接让PB崩溃。这是PB调用C DLL最常踩的坑没有之一。第二个函数传结构体指针PB侧写法就是REF EN32T_DEVICE_INFO pInfo意思就是传结构体的引用底层等价于C的指针传递。第三个函数没有参数PB里写空括号即可注意别画蛇添足写个VOID进去。4. 没有EN32T.H怎么办用导出表逆向出接口定义的三条路4.1 dumpbin /exports先拿到函数名清单如果你把EN32T.H弄丢了又急着调DLL第一步永远是看导出表。用Visual Studio自带的开发者命令行工具一条命令搞定dumpbin /exports EN32T.dll输出会列出DLL导出的所有函数名、序号和入口地址ordinal hint RVA name 1 0 00001000 EN32T_OpenDevice 2 1 00001020 EN32T_ReadDevice 3 2 00001040 EN32T_CloseDevice拿到函数名至少知道了DLL能干什么。如果函数名恰好和厂商SDK文档、示例代码能对上那后面就轻松了。这里要提醒一句dumpbin的输出里函数名后面如果跟着8这样的后缀说明它是__stdcall方式导出后面的数字是参数占用的总字节数。比如EN32T_OpenDevice4意思是一个参数共4字节大概率是char*或int类型。这个信息对反推参数类型极有价值。4.2 没有原厂头文件怎么反推参数类型有函数名但不知道参数类型这是最难受的。我的经验是用“已知调用场景 函数名语义 返回值测试”三招配合。先看函数名。OpenDevice、CloseDevice这种参数基本就能猜个八九不离十。Open类函数一般接受一个设备名或路径字符串返回句柄或错误码Close类函数一般接受一个句柄或设备ID返回状态。再看调用场景如果这个DLL是配合串口设备用的大概率有设备名参数如果是对接加密锁的大概率有密码字符串参数。然后是测试。PB里声明一个最可能的签名用一个不破坏状态的函数试比如只调EN32T_CloseDevice()。如果成功返回且返回值范围合理说明调用约定和参数数量没问题。再逐个增加参数观察返回值变化。这种办法比较糙但确实能解决大部分问题。4.3 动态加载DLL最后一道兜底方案还有一种更保守的办法不在PB里直接声明外部函数而是用Windows API动态加载。PB可以通过声明LoadLibraryA、GetProcAddress、FreeLibrary几个系统API在运行时加载DLL并取函数地址。比如FUNCTION Long LoadLibraryA(STRING lpLibFileName) LIBRARY kernel32.dll FUNCTION Long GetProcAddress(Long hModule, STRING lpProcName) LIBRARY kernel32.dll FUNCTION Long FreeLibrary(Long hLibModule) LIBRARY kernel32.dll拿到函数地址之后还是得知道函数签名才能构造调用所以动态加载只能解决“找不到DLL”的问题不能解决“不知道接口”的问题。它更大的价值在于DLL本身缺失时可以给出友好提示而不是让PB直接报一堆不知所云的错。在没有头文件、也猜不准参数的情况下我建议先用这种办法确认DLL能否正常加载再回过头来反推函数签名。5. 自己用VC编译PB可调用的DLL时关于EN32T.H的工程细节5.1 一个最小封装的完整代码第三种场景也是最能体现EN32T.H价值的地方你自己用C写一个中间层DLL。比如PB直接调EN32T_ReadDevice要处理结构体、要管缓冲区太烦你希望封装成几个简单函数。新建一个Visual C的DLL工程把厂商的EN32T.H和EN32T.lib放到工程目录源文件这样写#include EN32T.h #include windows.h #include cstring extern C __declspec(dllexport) int PB_OpenDevice(const char* name) { return EN32T_OpenDevice(name); } extern C __declspec(dllexport) int PB_ReadDeviceStatus(int* status, long* lastError) { EN32T_DEVICE_INFO info; int ret EN32T_ReadDevice(info); if (ret EN32T_SUCCESS) { *status info.status; *lastError info.lastError; } return ret; } extern C __declspec(dllexport) int PB_CloseDevice() { return EN32T_CloseDevice(); }这里是C工程#include EN32T.h时头文件里的extern C会起作用告诉编译器按C方式链接第三方DLL的符号。你自己的导出函数也用extern C __declspec(dllexport)这样PB声明的函数名就是原始名字不带C修饰符。5.2 编译期间必须盯紧的设置设置一工程字符集。VC工程默认可能是Unicode字符集但PB传过来的字符串通常按ANSI处理而且EN32T.H里的char*也不会自动变成宽字符。建议把工程字符集设为“使用多字节字符集”否则你会遇到字符串参数乱码或者根本传不进去的问题。设置二运行时库。VC工程的运行时库选/MD多线程DLL通常比选/MT多线程静态库更稳妥。如果DLL是静态链接CRT而PB进程里已经加载了另一个版本的运行时库有概率出现内存管理冲突表现为传字符串参数时偶发崩溃。选/MD能降低这种风险。设置三位数匹配。这是最要命的一条很多人在最后一步栽了。PB IDE默认是32位进程它只能加载32位DLL。如果你用VC默认的x64平台编译出64位DLLPB调用时直接报“不是有效的Win32应用程序”。反过来也一样PB如果是64位部署环境就加载不了32位DLL。所以编译前先确认目标平台别凭感觉选。还有一个细节封装层函数如果要在PB里传结构体或者较大缓冲区回去一定要明确回调缓冲区的大小。我在封装层里习惯加一个bufSize参数而不是让PB这边猜这样可以避免大量缓冲区越界问题。6. PB调用DLL的高频报错按这条链路定位6.1 高频报错对照表这么多年下来PB调DLL的报错来来回回就那几类我把常见情况整理成一张表遇到问题直接对照报错现象大概率原因排查方向Error calling external function函数名没找到或参数签名不匹配用dumpbin核对导出名检查ALIAS FORDLL not found / 无法加载DLLDLL路径不对或依赖项缺失把DLL放PB应用目录或用依赖查看器查依赖不是有效的Win32应用程序位数不匹配确认PB和DLL是同一位数返回值正常但数据全乱结构体字段类型或长度不对重点查int与INTEGER、long与LONG的映射字符串内容乱码ANSI/Unicode不匹配检查VC工程字符集和PB字符串编码调用后PB直接崩溃指针参数方向错误或缓冲区未预分配检查REF关键字和Space()预分配这里多说一句“Error calling external function”这个报错是最具迷惑性的它可能是函数名找不到也可能是参数个数不一致还可能是调用约定不匹配。别盯着消息框看直接用dumpbin查一下DLL实际导出名。很多厂商的DLL导出函数名和文档里写的不完全一致多一个下划线或少一个4后缀PB侧就必须用ALIAS FOR来匹配否则就卡在这里。6.2 我的排错顺序供你参考遇到问题我一般按这个顺序排查。第一步确认DLL加载把DLL放到PB应用同一个目录先声明一个最简单的FUNCTION Long( ) LIBRARY EN32T.DLL能加载就成功了一半。第二步核对函数名和别名dumpbin导出表对着看该用ALIAS FOR就用。第三步检查参数映射尤其注意int、long在PB里都该用LONG别用INTEGER。第四步才看业务逻辑。这个顺序能帮你快速缩小问题范围。我有一次帮同事查一个DLL调用他调了三天没搞定我让他把DLL和PB应用放同一目录问题立刻消失——原因是DLL依赖了同目录下另外三个运行库而他把DLL单独拷到系统目录里运行库没跟着过去。这种问题不看依赖工具根本想不到。按照上面这套方法配合EN32T.H头文件PB调DLL这件事基本就是体力活了。做得多了你会发现C头文件其实就是一份“翻译原文”PB声明就是“译文”只要原文读得准译文不跑偏DLL调用就稳了。本文还有配套的精品资源点击获取