简介面向使用PowerBuilder进行DLL封装开发的程序员这套资源包含编译时必备的EN32T.H及配套头文件可解决编译器提示“Error opening file c:\windows\system32\cgen\en32t.h”的常见故障。压缩包共4个文件涵盖EN32T.H、DN32T.H两个头文件及对应的EN32T.pch、DN32T.pch预编译文件整体大小约596KB能够满足PB工程编译DLL时的环境依赖需求。资源已有598人学习下载说明该问题在开发中具有一定普遍性获取后可依据配套说明快速定位文件位置减少盲目搜索和试错成本。对于受此问题困扰的PB开发者是一份直接可用的排错补充材料。 你正在维护一套十年前的PowerBuilder系统某天想用Project画笔把整个应用编译成一个DLL结果点了Build之后C编译器窗口闪了一下然后抛出一行冷冰冰的红字fatal error C1083: Cannot open include file: EN32T.H: No such file or directory。这不是你第一次遇到这种环境问题但这次不一样——EN32T.H这个名字很陌生网上也很难搜到靠谱答案。这篇文章就把这整件事说透PB机器码编译为什么需要C编译器EN32T.H头文件从哪来、有什么用怎么配置环境让编译顺利通过以及我实际踩过的一堆坑。如果你正在维护老PB项目或者想把PB应用拆成DLL部署这篇文章应该能帮你少走很多弯路。1. PowerBuilder为什么要编译成DLL为什么偏偏需要EN32T.H1.1 PB的两种编译模式PowerBuilder从早期版本开始就提供了两种编译输出模式一种叫P-code一种叫Machine Code。P-code伪代码是PB默认的产物生成的是.PBD文件运行时靠PB虚拟机比如PBVM80.DLL、PBVM90.DLL逐条解释执行。P-code的好处是编译速度极快和PB版本绑定比较松缺点是执行效率比原生机器码差一些而且不适合做模块化的DLL分发。Machine Code模式下PB会把PowerScript脚本、窗口对象、数据窗口对象等统一编译成Windows平台的机器码输出为.EXE或.DLL。很多老项目选择Machine Code并不是为了追求性能而是为了部署方便——把整个应用打包成几个DLL文件比甩出一堆.PBD文件显得更规整也能在一定程度上保护源代码。还有一个历史原因是PBD文件在版本升级时经常出兼容问题而机器码DLL一旦生成部署到目标机器的行为更可控。但这里有个很多人没意识到的问题PB本身不是C/C编译器它承担不了把PowerScript转成机器码的底层工作。机器码编译的完整链路是PB先把自己的对象和脚本翻译成中间C代码然后调用外部安装的C编译器通常是Microsoft Visual C的cl.exe去编译这些C代码最后再用link.exe链接成DLL/EXE。所以你在本机装好PB还不够必须还要装一个可用的C/C编译环境PB才能完成整条编译链。1.2 EN32T.H在编译链路中的角色PB生成的中间C代码不是凭空来的它会引用一大堆PB运行时内部的数据结构、函数原型和常量定义。这些声明如果都写在生成的C文件里一方面会让中间文件膨胀得离谱另一方面也没法和PB运行时的实际导出符号保持同步。所以PB把公共声明提取到了几个固定的头文件里EN32T.H就是其中非常关键的一个。EN32T.H这个文件名的命名不算直观结合它的使用场景看EN代表Enterprise企业版32T对应32位Type类型合起来可以理解为“企业版32位类型定义头文件”。它在编译链路里的作用主要有两块一是用typedef把PowerScript里的基本类型映射成C语言类型比如boolean、integer、long这些在C层面对应的数据类型让PB生成的C代码能被编译器正确识别二是声明PB运行时库提供的一系列内部函数编译器看到这些extern声明后编译阶段不会报“未声明标识符”的错误等到链接阶段再去PBVM.DLL等运行时库里找真正的导出函数。打个比方PB相当于一家设计院图纸画好后交给外部施工队施工。施工队进场前需要一本“图纸设计规范说明”里面写清楚每个构件的型号和连接方式否则施工队看不懂图纸。EN32T.H就扮演了这本规范说明的角色。搞清楚这一点你就能理解为什么编译时报错时缺的不是PB的文件而是EN32T.H这个C头文件了。2. EN32T.H头文件的作用与获取方式2.1 头文件里到底有什么网上有朋友把EN32T.H传成“PB官方加密头文件”其实没那么神秘。它本质上就是普通C语言头文件打开后能看到典型的内容结构开头是一段文件说明注释然后是大片的预处理指令、typedef、结构体定义和extern函数声明。具体来说文件里会包含类似这样的东西PB运行时数据类型的别名定义、与DataWindow内部实现相关的结构体、错误码常量的宏定义以及PBVM运行时DLL里导出函数的外部声明。这些声明和PB版本是强绑定的——PB 8用的EN32T.H和PB 9的版本在结构体字段、函数签名上可能会有差异。2.2 从哪里找这个文件一般情况下EN32T.H会随PowerBuilder完整安装包一起安装到系统里典型路径是PowerBuilder安装目录下的Shared或API子目录。以PB 8/9时代常见的Sybase安装为例可能会出现在这些位置C:\Sybase\Shared\PowerBuilder\EN32T.H C:\Program Files\Sybase\Shared\PowerBuilder\EN32T.H如果你的机器上翻遍了安装目录也没找到那多半是安装时没有勾选“API/Header Files”之类的组件。这种情况下还有三个可行方案第一从原版安装光盘或安装ISO里直接搜索EN32T.H解压出来放到指定目录第二从一台已经正常配置好机器码编译的机器上拷贝一份注意PB大版本要一致第三实在找不到原文件可以联系厂商支持或从可信社区渠道获取。我个人不建议随便在第三方下载站抓一个版本下来用因为这类头文件必须和PBVM运行时DLL配套版本不匹配时编译也许能蒙混过关但运行阶段容易出各种诡异问题。2.3 放置路径与版本匹配怎么判断拿到文件之后放置路径有两套思路。一套是“临时方案”把头文件复制到PB生成中间C源码的输出目录让编译器直接用当前目录搜索。另一套是“长期方案”建一个专门放PB头文件的目录然后把该目录追加到系统环境变量INCLUDE里这样以后每个项目编译时都能自动找到不用反复拷贝。版本匹配的判断其实不难编译时如果出现error C2065: xxxxxx : undeclared identifier这类错误通常不是路径问题而是头文件版本和PB版本对不上。你也可以顺手对比一下头文件内部关于PB版本号的注释信息PB官方在做版本发布时一般会在头文件里留版本标记。3. 完整配置步骤让PB顺利编译出DLL3.1 检查编译器环境是否就绪在打开PB的Project之前先确认三件事。第一PowerBuilder版本和安装目录记清楚主版本号。第二一个可用的C/C编译器老PB项目最常见的搭配是Visual C 6.0也有用Visual C 2003/2005的。第三编译器对应的cl.exe和link.exe能否在命令行直接调用。检查方式很简单打开命令行窗口依次执行cl link echo %INCLUDE% echo %LIB% echo %PATH%如果cl显示“不是内部或外部命令”说明PATH里没有编译器路径后面PB调用编译器时肯定会失败。如果echo %INCLUDE%只返回原样的%INCLUDE%字符串说明INCLUDE环境变量还没设置编译器找不到标准头文件和PB头文件。3.2 配置环境变量我建议把编译器路径和相关环境变量写到系统级环境变量里而不是每次编译前手动执行批处理。以Visual C 6.0安装在C:\Program Files\Microsoft Visual Studio\VC98为例在“系统属性 → 环境变量”里做如下配置PATHC:\Program Files\Microsoft Visual Studio\VC98\bin;%PATH% INCLUDEC:\Program Files\Microsoft Visual Studio\VC98\include;C:\Sybase\Shared\PowerBuilder;%INCLUDE% LIBC:\Program Files\Microsoft Visual Studio\VC98\lib;%LIB%重点看INCLUDE这一行C:\Sybase\Shared\PowerBuilder就是EN32T.H所在目录。如果你把头文件放在了其他位置这一行就写对应的路径。注意路径里有空格时Windows命令行在某些情况下还是能处理但为了稳妥建议用短路径名或避免把编译器装到带空格的目录下。配置完环境变量后记得重开命令行窗口验证一次。3.3 在Project中打开机器码编译选项启动PowerBuilder后在Library树中找到你的项目对象通常带Project图标的那个双击打开Project画笔。在Project属性窗口里找到“Compiler”或“Code Generation”标签页不同PB版本的位置略有差异但关键字都差不多。把“Generate Machine Code”勾上这个选项就是机器码编译的总开关。接着看输出文件设置。Project属性里一般有“Executable File Name”或“Output Directory”字段默认填的是EXE文件名。要生成DLL直接把扩展名改成DLL。比如C:\Build\MyApp.dllPB会根据扩展名判断链接模式生成PE格式的DLL。某些版本还有一个“DLL”单选按钮或复选框含义一样勾上即可。3.4 编译与验证配置完成点击Build或Deploy按钮。编译过程中你会看到PB先做前置检查然后弹出黑色命令行窗口快速滚动大量C编译输出信息。看到这些信息意味着PB已经进入了C编译阶段EN32T.H的问题就是在这一阶段暴露的。如果最终没有致命错误命令行窗口会正常关闭输出目录下会出现MyApp.dll。生成成功后建议用工具验证一下DLL的属性。如果编译器自带dumpbin可以执行dumpbin /headers C:\Build\MyApp.dll在输出的文件头信息里可以确认DLL是32位还是64位以及导入表。没有dumpbin的话用一些PE查看小工具也能达到同样效果。这一步看起来多余实际能帮你提前发现位数不匹配之类的隐患。3.5 部署时的运行时配套辛辛苦苦编译出DLL部署时千万别忘记PB运行时组件。Machine Code DLL不是独立DLL它运行要靠PBVM*.DLL、DataWindow引擎DLL等一批运行时文件。以PB 8为例至少需要PBVM80.DLL、pbdwe80.dll还有可能有pbrtc80.dll。部署时有两种做法一是把开发机PB安装目录下的运行时DLL复制到目标机器的应用目录二是用PB自带的安装包制作工具打包分发。千万别靠“拷一个EXE/DLL过去就能跑”的惯性思维否则目标机器上会一直报“无法加载DLL”。4. 常见错误与排查实录4.1 报错cannot open include file: EN32T.H这是最典型的错误也是整篇文章的起点。错误本身说明PB已经成功调起了C编译器但编译器在include搜索路径里找不到EN32T.H。先检查这个文件在机器上是否存在再看INCLUDE环境变量是否包含文件所在目录。如果文件和路径都对还是报错可以试试把PB生成的中间C文件找出来手动执行cl命令复现错误逐步添加/I参数指定头文件目录这样能确认到底卡在哪一层。我在实际处理中遇到过一种情况环境变量配置正确但PB是以桌面快捷方式启动的而快捷方式的“起始位置”被改到了别的目录导致相对路径查找失败。解决方法是把PB快捷方式的“起始位置”改回PB安装目录问题立刻消失。4.2 找不到cl.exe或link.exe这类错误通常和环境变量PATH有关。VC 6.0的cl.exe在VC98\Bin目录下确认PATH包含该目录。还有一个历史坑VC 6.0在Windows 7及更高版本上兼容性不太好安装过程可能会提示组件问题装完以后命令行编译时经常报“无法找到mspdb60.dll”。建议右键cl.exe用管理员身份测试或者直接安装Visual C 2008 Express的编译器组件作为替代。新版本编译器也能编译PB生成的C代码但要注意LIB路径和运行时库的变化可能引入新的链接问题稳妥为主。4.3 DLL生成成功但加载失败这类问题最隐蔽。DLL明明存在大小也正常但调用方一加载就报错。常见原因我排一下优先级第一目标机器缺PB运行时DLL这是多数情况第二DLL依赖的C运行时库MSVCRT缺失或版本冲突第三PB应用引用的PBD资源文件没有随DLL一起部署。Machine Code DLL在运行时会动态加载其他PB库文件如果程序里有DataWindow对象、外部函数库这些文件缺失时DLL虽然能加载但执行到对应功能时会直接崩溃。排查时可以先用Dependency Walker这类工具检查DLL的静态依赖排除C运行时库的问题再确认PB运行库都部署到位。4.4 32位与64位混用问题经典PowerBuilder版本PB 12之前生成的DLL绝大多数是32位。把32位DLL丢到64位Windows上没问题但调用它的进程必须是32位。常见翻车场景是用C#开发平台项目默认AnyCPU部署到64位机器后进程以64位运行调用32位PB DLL直接抛BadImageFormatException。解决办法是把C#项目的“目标平台”强制设置为x86或者把PB DLL封装到独立32位进程中通过进程间通信调用。另外提醒一句如果目标机器数据库客户端是64位的而PB DLL是32位的数据库驱动也得用32位版本否则运行时连不上库。这种位数的连锁问题在混合环境里非常典型。4.5 我的排查顺序建议遇到机器码编译问题建议按下面这个顺序来能省不少时间先让编译器独立编译一个hello.c。如果编译器本身有问题先修编译器环境。再看PB能不能生成中间C文件。能生成说明PB和编译器已经对接成功。第3步才查头文件路径别一上来就查EN32T.H。链接阶段报错再查LIB路径和运行时库版本。按照这个顺序多数问题能在十分钟内定位。倒过来查的话经常绕一大圈才发现是编译器本身没装好。4.6 常见错误速查表错误现象可能原因解决思路cannot open include file: EN32T.HINCLUDE路径未包含头文件目录确认文件位置补全INCLUDE环境变量cl 不是内部或外部命令VC编译器未安装或PATH未配置安装编译器或将VC98\Bin加入PATHerror C2065: xxx undeclared identifier头文件版本与PB版本不匹配更换同版本的EN32T.H链接时找不到某个LIB文件LIB路径未配置或库文件缺失补充VC的LIB路径及PB运行时LIB目录64位进程无法加载32位DLL位数不匹配调用方改为x86模式或使用32位中间进程DLL加载后报缺少PBVM*.DLLPB运行时库未部署部署完整且版本匹配的PB运行时组件我自己在处理这堆老环境问题时最深的一点体会是不要把PB机器码编译环境当成黑盒。错误提示看起来很吓人但整条链路就那么几个环节——PB解析、生成C代码、调用编译器、链接、部署。每个环节都有对应的检查点理解了链路任何一个报错都能顺着链条追下去。如果公司还在维护PowerBuilder系统强烈建议把这一整套编译环境做成虚拟机镜像把PB版本、编译器版本、头文件位置、环境变量全部固化下来。等几年后原始团队成员都调走了新人接手时至少还能把编译环境跑起来不至于一上来就被EN32T.H卡住。本文还有配套的精品资源点击获取