简介面向BCB6开发者与需要分发C Builder程序的团队这份运行库合集专门解决目标机器未完整安装BCB6环境时程序无法启动的部署难题。压缩包共306个文件、35.22MB其中184个bpl为运行时包114个dll为动态链接库另有2个lib导入库、1个ocx串口通信控件、1个msm安装合并模块以及h、dep、srg等辅助文件分别支撑VCL组件加载、函数链接、串口交互、控件注册和资源描述大幅降低运行环境依赖覆盖运行所需的绝大多数组件。已有638人学习下载。借助这些库文件BCB6程序可在纯净Windows系统上直接运行免去为每台目标机安装完整开发环境的负担。同时读者能从文件组成中理解DLL、静态库与导入库的分工差异遭遇缺少运行库导致的启动报错时可快速定位缺失项并补齐适合打包发布、部署调试与离线备份。1. BCB6 的运行库客户机器上那个“没有找到 vcl60.bpl”弹窗是哪来的接手过 BCB6 程序的开发者几乎都在客户电脑上见过类似弹窗“没有找到 vcl60.bpl因此这个应用程序未能启动”。第一反应往往是程序写错了但真相是编译时开了动态运行库exe 只挂了一个调用桩真正干活的代码都放在外面的 bpl 和 dll 里。这篇笔记把 BCB6 常用运行库一次讲清哪些文件必须带、怎么用工具反推依赖、怎么打成靠谱的安装包以及现场报错时怎么定位。适合正在维护老系统、做绿色版发布或者被“装上后打不开”折腾过的人往下看。2. 分清 BPL 与 DLLBCB6 程序真正依赖的运行库清单2.1 动态链接模型BPL 是 VCL 世界的“运行库”BCB6 写的是 C 代码但窗体那一套东西是基于 VCL 组件库的。组件库和运行时库在编译时可以打包成“运行时包”也就是 .bpl 文件。.bpl 本质上是 DLL只是里面装了 VCL 专用的类、组件和函数导出。exe 在启动时按导入表逐个加载这些 bpl任何一个找不到进程直接弹窗退出。BCB6 的包命名有规律包名加版本号6.0 对应的就是“60”。所以最常看到的几个是 rtl60.bpl、vcl60.bpl、vclx60.bpl。Windows 加载这些文件时先找 exe 所在目录再找系统目录。所以“程序目录里有 rtl60.bpl但 system32 里也有一份旧的”实际加载的是程序目录那份这个顺序在排查时报错时特别有用。2.2 常用 BPL 全表rtl60、vcl60、vclx60 各负责什么下面这张表是 BCB6 程序里最常见的依赖按“什么时候会用到”来理解比死记文件名更可靠文件名职责常见出现场景rtl60.bpl运行时库字符串、内存管理、容器类绝大多数 BCB6 程序vcl60.bplVCL 组件框架窗体和控件的基础用到 TForm、TButton 等可视组件vclx60.bplVCL 扩展组件一些公共控件和辅助类多数窗体程序都会带vcljpg60.bplJPEG 图像编解码用 TJPEGImage 或 TImage 打开 JPGvcldb60.bpl数据库可视组件用了 TDBGrid、TDataSource 等dbrtl60.bpl数据库运行时支持用了数据集组件但界面层较薄adortl60.bplADO 数据库封装用 TADOConnection、TADOQuery这不是“全都要带”的清单。一个最简单的登录窗体依赖可能只有 rtl60.bpl、vcl60.bpl、vclx60.bpl 三个。真正精确的清单要用导入表分析工具去确认具体做法放在第 3 章。提示bpl 文件不要按网上流传的“运行库合集”一次性塞给客户。装多了不会让程序更稳定反而可能因为版本错位让别的软件报错。2.3 真正叫 dll 的那几个cc3260mt.dll、bcbmm.dll、midas.dll除了 bplBCB6 程序还会依赖少量带 dll 后缀的文件这几个是现场最常见的问题源。cc3260mt.dll 是 C 多线程运行时库BCB6 编译的 exe 在动态链接 RTL 时经常引用它它是前面那套 VCL 运行时之外的另一条依赖线。bcbmm.dll 是内存管理相关的 DLL老版本里常见的是 borlndmm.dllBCB6 环境里一般是 bcbmm.dll。这两个文件是否真的需要取决于工程选项和第三方组件必须以导入表实测为准。midas.dll 比较特殊。使用 TClientDataSet 或 DataSnap 的老程序会依赖它但它是一个 COM 组件。普通 bpl 复制到 exe 目录就能被加载midas.dll 光复制还不够还要注册一次否则运行时创建数据模块会报“COM 类工厂不可用”。这个区别在打包时经常被忽略。还有一类是系统 DLL比如 kernel32.dll、user32.dll、gdi32.dll。它们永远不该被打进安装包。判断方法很简单如果文件在系统目录里且带数字签名就不要动它也不要把它复制到程序目录去“覆盖”。2.4 Build with runtime packages 与静态链接的选型逻辑BCB6 的工程选项里有两个开关Project - Options - Linker 里的 Use dynamic RTL以及 Project - Options - Packages 里的 Build with runtime packages。两个都开着exe 会非常小依赖上面那一堆 bpl 和 dll。两个都关掉VCL 和 RTL 会被静态链接进 exe体积从几百 KB 涨到两三 MB但程序独立性强复制到新机器往往能直接跑。我的习惯是给外部客户发布的小工具优先做静态链接省掉“客户机器缺运行库”这个最常见的售后理由给公司内部多模块系统发布保留动态链接因为多个 exe 可以共享一套运行库后续升级组件库时不用重编所有模块。静态链接并不是万能药。只要程序里用了 TClientDataSetmidas.dll 该带还得带该注册还得注册。而且把两个开关同时关掉之后必须重新确认一遍导入表因为某些第三方组件包会强制要求动态链接编译能过、运行时照样缺 bpl这种翻车我在项目里见过不止一次。3. 从导入表反推依赖别靠猜把缺的文件查出来3.1 用 Dependency Walker 查依赖树最常见的依赖分析工具是 Dependency Walker也就是 depends.exe。打开它把 BCB6 生成的 exe 拖进去左侧会列出所有导入模块右侧是函数级导入导出。它最大的价值是能递归展开 bpl 之间的依赖vcl60.bpl 自己还依赖 vclx60.bpl如果只看到 exe 依赖 vcl60.bpl 就停下部署后照样报错。需要注意depends 展示的是 exe 直接和间接依赖的完整树其中混着大量系统 DLL。要重点关注树里带 60 的 bpl以及 cc3260mt.dll、bcbmm.dll、midas.dll 这些非常规文件。第一次跑出结果后建议把树展开截图或者存成文本后面做最小集验证时照着对比。3.2 用 dumpbin /imports 快速筛查命令行依赖如果开发机上装了 VC 或 Windows SDK 的命令行环境可以用 dumpbin 快速列出导入模块比图形界面更适合写进批处理dumpbin /imports 模拟项目X.exe | findstr /i \.bpl \.dll/imports 参数让 dumpbin 输出这个 PE 文件的所有导入模块和导入函数。后面接 findstr 是为了过滤出带 .bpl 和 .dll 后缀的行把系统函数的噪音去掉。如果只想看 bpl把过滤条件收紧dumpbin /imports 模拟项目X.exe | findstr /i \.bpl这条命令在 32 位 exe 上可以正常工作BCB6 生成的是 32 位 PEdumpbin 能完整读出导入表。它输出的是模块名加函数名开头几行就是依赖文件列表够做部署清单了。缺点是没有递归展开 bpl 的二级依赖所以实际部署前还是要配一次 Dependency Walker 或直接做最小集实测。3.3 手工二分法验证最小集别信工具信启动测试依赖工具给出的清单通常是“完整覆盖”但部署现场追求的是“最小可用”。我一般会在干净的测试目录里做二分法新建空目录只放 exe。按依赖清单复制 bpl 和 dll数量先给足。启动程序确认能正常运行。从清单里删掉一个怀疑不必要的 bpl再启动。如果正常说明这个文件不必要如果报缺说明它确实要。反复删直到删掉任意一个文件就会报错这时得到的就是最小集。这个流程有个坑启动成功不代表运行成功。某些组件用的是运行时动态加载主窗体出现后才去 LoadLibrary。所以每次删完文件不仅要启动还要把登录、查询、导出这些关键功能路径各跑一遍记录在哪个功能上崩。这一步懒不得血泪经验都在这里面。3.4 用加载监视确认实际加载路径分析依赖时另一个常用工具是进程监视类的工具Process Monitor 是其中典型。它能显示进程加载某个模块时到底去哪些目录找过、最终从哪个目录加载成功。现场排查“明明复制了还是报缺”时特别有用。过滤条件这样设进程名填目标 exe操作类型选 Load Image路径包含 bpl。跑一次启动日志里会列出每次加载记录的路径和结果。如果 exe 确实加载了程序目录里的 vcl60.bpl但后续某个函数调用失败问题往往不是缺文件而是版本错位。如果日志里出现 NAME NOT FOUND那才是真的缺文件或放错目录。4. 给 BCB6 程序打包运行库集合、复制脚本与安装脚本4.1 自动收集运行库的 bat 脚本确认最小集之后把收集动作固化成脚本免得每次发布都手点复制。下面这个 bat 从开发机的 BCB6 安装目录收集常用运行库到当前目录下的 runtime 文件夹echo off setlocal rem 改成你机器上BCB6的Bin目录 set SRCD:\bcb6-sdk\bin set DST%~dp0runtime if not exist %DST% mkdir %DST% rem 按第3章查出的清单增删下面是常见项 for %%F in (rtl60.bpl vcl60.bpl vclx60.bpl vcljpg60.bpl cc3260mt.dll bcbmm.dll) do ( if exist %SRC%\%%F ( copy /y %SRC%\%%F %DST%\%%F nul echo [] %%F ) else ( echo [-] %%F not found in %SRC% ) ) echo 收集完成请检查 runtime 目录 endlocal脚本的逻辑是按预设名单从 src 复制到 dst。SRC 路径在每台开发机上不一样必须手动改成实际安装目录建议写成相对路径或放到共享目录里统一维护。清单不是固定的要以第 3 章的导入表为准比如程序没用到数据库就不要把 vcldb60.bpl 列进来。跑完后打开 runtime 目录对照依赖快照过一遍确认没有文件缺失。4.2 用 Inno Setup 把运行库装到 exe 同目录收集好的运行库最终要进安装包。这里最容易被新手搞错的是目录结构Windows 搜索 DLL 时不会自动搜索 exe 的子目录runtime 子目录里的 bpl 并不会被加载。所以安装脚本里必须把所有 bpl 和 dll 和 exe 放到同一目录[Setup] AppName模拟项目X客户端 AppVersion1.0.0 DefaultDirName{pf}\MockProjectX [Files] Source: D:\dist\模拟项目X.exe; DestDir: {app}; Flags: ignoreversion Source: D:\dist\runtime\*.bpl; DestDir: {app}; Flags: ignoreversion Source: D:\dist\runtime\cc3260mt.dll; DestDir: {app}; Flags: ignoreversion Source: D:\dist\runtime\bcbmm.dll; DestDir: {app}; Flags: ignoreversion Source: D:\dist\runtime\midas.dll; DestDir: {app}; Flags: regserverDestDir 全部指向 {app}也就是 exe 所在目录保证加载器能直接搜到。midas.dll 单独加了 regserver 标志Inno Setup 会在安装时自动调用 regsvr32 注册它卸载时会自动反注册比自己在 [Run] 段写 regsvr32 命令更可靠。注意不要把 bpl 安装到 system32。多个 BCB6 程序存在时system32 里一份旧版 bpl 会污染所有依赖它的程序。运行库跟着 exe 走是 BCB6 分发的最稳习惯。4.3 数据库程序的特有处理midas.dll、BDE、ADO使用 TClientDataSet 的程序除了注册 midas.dll还要想清楚它产生的连接方式。DataSnap 老架构下客户端和服务端都要有 midas.dll版本必须一致。如果只是用 ADO 连本地数据库依赖的是系统里的 OLEDB 驱动BCB6 本身没那么多额外文件但 Windows XP 上可能要先装 MDAC 2.8Win10 以上系统自带不需要额外处理。最麻烦的是老项目用了 BDE。BDE 不只是一个 dll它是一整套数据引擎包含 idapi32.dll、管理配置、驱动文件等一两百个文件。BCB6 自带的 BDE 在安装时有一个单独的选项很多部署环境里没有装它程序启动后一打开数据集就报错。遇到 BDE 项目我一般建议在安装包里单独做 BDE 组件目录或者趁维护窗口期迁移到 ADO靠复制几个 dll 解决不了 BDE 的问题。4.4 发布前的验收清单打包完成不等于发布完成。下面这张表是我每次发版前会走一遍的验收项检查项做法过关标准干净环境安装虚拟机装全新 32 位系统安装过程不报错首次启动双击 exe主窗体正常出现无弹窗关键业务路径登录、查询、导出、打印各跑一遍全部通过离线场景断开网络再启动不依赖联网组件安全软件干扰用带杀软的镜像测试bpl 和 dll 不被隔离干净虚拟机是最便宜的调试场很多“我机器上好的啊”的问题在干净环境里半小时就能暴露。建议准备一个只装系统、不打补丁的 32 位虚拟机每次发布前用它做终检比现场折腾客户机器省太多时间。5. 部署踩坑与排查BCB6 运行库的 4 个报错和 1 个套路5.1 报错“没有找到 rtl60.bpl / vcl60.bpl”现象双击 exe系统弹窗提示没有找到 rtl60.bpl 或 vcl60.bpl程序直接退出。原因exe 是按动态运行库编译的安装包里却没带对应 bpl或者文件带了但放在了 runtime 子目录。Windows 加载器只按既定搜索顺序找文件不会自动进入程序的子目录。解决先把所需 bpl 复制到 exe 同目录再启动测试。如果已经复制到同目录仍报错用第 3 章的加载监视工具确认它实际去哪儿找文件了大概率是系统目录里有一个同名但被锁定的文件或者程序被安全软件改了依赖路径。这个报错只要在干净目录实测一次基本能定位。5.2 报错“procedure entry point ... could not be located in vcl60.bpl”现象程序启动时弹窗内容是类似“The procedure entry point System某方法 could not be located in the dynamic link library vcl60.bpl”。原因机器上至少有另一个 BCB6 程序或另一个安装包往系统目录写过不同版本的 vcl60.bpl。BCB6 的 bpl 对版本很敏感导出符号对不上就会报这个错。它本质上是“文件存在但内容不对”不是缺文件。解决把当前程序确认可用的 vcl60.bpl 复制到 exe 同目录利用应用目录优先加载压过系统目录里的旧版。如果系统目录里那版已经被多个程序共用先备份再在干净环境里验证删除后所有相关程序是否正常。不要直接覆盖系统目录里的 bpl那会引发连锁反应。5.3 同目录放了 bpl 还是报缺 vclx60.bpl现象exe 旁边明明放了 vcl60.bpl启动后却提示缺 vclx60.bpl。原因依赖是树状的。exe 依赖 vcl60.bplvcl60.bpl 内部又依赖 vclx60.bpl。只查了 exe 的一级依赖没看 bpl 的二级依赖导致少带文件。解决用 Dependency Walker 打开 exe把树展开到第二层把所有带 60 后缀的 bpl 都记下来按完整树去复制。第 3 章的二分法在这里同样有效每次只在完整集合里删一个文件能很快确定真正影响启动路径的是哪一个。5.4 64 位系统上装了还是打不开属于有点玄学的场景现象32 位 BCB6 程序在 64 位 Windows 上安装安装过程顺利但启动时提示缺少某个 dll 或 bpl。原因常见于安装包被识别成 64 位后装进了 Program Files而程序和运行库目录分离或者 regsvr32 被 64 位系统重定向注册了 64 位版本的 COM 组件但 BCB6 程序是 32 位找不到对应注册表视图。解决BCB6 程序发布永远用 32 位安装包。Inno Setup 的 32 位包在 64 位系统上会自动把 {pf} 指向 Program Files (x86)regsvr32 也会按 32 位视图处理。运行库仍放 exe 同目录系统重启后再做一次安装验证。不要手工往 SysWOW64 里复制 bpl那相当于手动制造 system32 污染。5.5 排查套路二分法从系统目录回到应用目录面对一个“装了运行库还是报错”的现场最有效的套路是从系统目录往回找。先记录报错模块名再看这个文件是否存在、在哪个目录、版本号是多少。如果系统目录有同名文件先备份再把它隔离到备份目录然后把程序同目录的运行库切到有效版本重新启动。如果问题还在就用加载监视工具跑一次启动看它到底加载了哪一份。最后配合二分法从完整依赖集合里逐个剔除文件找到真正影响启动的最小集。这套流程把“玄学报错”变成可重复的实验也是我做 BCB6 部署排查时的标准姿势。6. 进阶给每个 BCB6 版本留一份“依赖快照”上线前 10 分钟过一遍维护老系统最怕的不是装不上是“上个版本能跑这个版本怎么不行”。BCB6 程序改动不大但编译器选项、第三方组件版本、运行库目录任何一个变化都会让依赖悄悄变掉。所以我养成了一个习惯每次发布前生成一份依赖快照把文件名、版本、哈希全记下来跟着安装包一起归档。生成快照可以用一个很短的 batecho off set RUNTIME%~dp0runtime rem 按当前发布版本的导入表维护这个名单 set FILESrtl60.bpl vcl60.bpl vclx60.bpl vcljpg60.bpl cc3260mt.dll bcbmm.dll midas.dll if exist deps.txt del deps.txt echo [BCB6 runtime snapshot] %date% %time% deps.txt for %%F in (%FILES%) do ( if exist %RUNTIME%\%%F ( echo %%F deps.txt certutil -hashfile %RUNTIME%\%%F MD5 deps.txt ) ) echo dependencies dumped to deps.txt脚本遍历清单里的运行库把文件名和 MD5 哈希写进 deps.txtcertutil 是 Windows 自带命令不需要额外工具。这条输出看着不起眼但现场排错时价值很大如果客户装了但起不来先比对快照里文件的版本和哈希再看是加载路径问题还是文件被安全软件替换了。我甚至会把快照内容写进安装包的说明文件里当作交付物的一部分。前几年我经手过一个老客户端上线时为了省事把 vcl60.bpl 直接丢进了系统目录结果半个月后另一个程序开始报 entry point。那次排查花了两天最后只能靠恢复系统还原点收场。从那以后所有运行库一律跟 exe 走发布包一律留依赖快照。这套习惯替我省掉了大量远程售后也希望帮到你。本文还有配套的精品资源点击获取
