企业官网建设流程全解析

简介：面向BCB6程序开发者的运行库整合包，用于解决BCB6应用在未安装完整开发环境的计算机上无法正常运行的问题。压缩包共包含三百零六个文件，以一百八十四个包文件和一百一十四个动态库为主体，另有一些导入库、通信控件和安装模块等辅助组件，整体大小约三十五兆字节，可满足常见BCB6程序的部署依赖需求。这些文件分别承担动态链接、静态链接、串口通信控件注册以及安装包合并等功能，开发者可直接将对应组件随程序一起分发，省去在每台目标机器上逐一配置环境的麻烦。内容预览显示其中含有基础界面库、报表组件等典型运行依赖，适合软件开发人员、系统部署人员以及正在学习BCB组件机制的初学者参考。目前已有六百三十八人学习使用，资源类型集中、体积适中，是打包发布BCB6程序时非常值得保留的常用运行库集合。

1. BCB6 常用 dll：先把运行库边界摸清楚，再谈分发

用 BCB6 编译的程序，最让人抓狂的时刻往往不在 IDE 里，而在交付现场：exe 在自己机器上跑得飞起，到客户电脑上双击就没了下文。轻则弹窗提示缺少 cc3260mt.dll，重则直接报 0xc0000135，连窗口都看不到。这不是代码逻辑写坏了，而是 BCB6 的 exe 默认带着动态链接运行时依赖。这份「BCB6 常用 dll」运行库合集，解决的就是这个分发断层：把缺的核心运行库收齐，让工程补上漏掉的那条腿。

资源内容包括内存管理、C++ 运行时、VCL 基础包等文件，适合正在维护 BCB6 老项目、做免安装绿色包、或反复被客户机器缺 dll 折磨的开发者。他们不需要深入理解 Borland 的动态链接机制，只需要一份能直接对着清单补 dll 的参考。

2. 运行库依赖拆解：exe 到底在找哪些 dll 和 bpl

2.1 动态链接是默认路径：为什么 BCB6 产物天生带依赖

BCB6 编译产物对运行库的依赖，根源在 IDE 里两个默认开启的链接选项：

• Project → Options → Linker → Use dynamic RTL
• Project → Options → Packages → Build with runtime packages

第一个开关决定 C++ 运行时是否外部化，第二个决定 VCL 组件库是否外部化。新工程默认都是勾选状态，意味着编译器不会把 RTL 和 VCL 的实现代码写进 exe，只在导入表里记录对一堆文件名的引用。exe 启动时，Windows 加载器按依赖顺序去 exe 所在目录、System32、PATH 里逐个找这些文件，找到就加载，找不到就直接终止进程。

这解释了为什么开发机上一切正常：BCB6 安装程序早把这些 dll 和 bpl 写进了系统目录。目标机器是一台干净 Windows，自然跑不起来。

Use dynamic RTL 影响到的典型文件是 cc3260mt.dll 和 borlndmm.dll。前者是 C++ Builder 6.0 的多线程 C++ 运行时，后者是 Borland 内存管理器。几乎所有用到 new/delete 和 STL 的程序都躲不开内存管理这一层，所以 borlndmm.dll 出现在绝大多数动态编译的 BCB6 exe 依赖列表里。它也是后面避坑章节的重点角色，版本冲突问题几乎都集中在它身上。

Build with runtime packages 影响的是 bpl 后缀的一类文件。bpl 是 Borland Package Library，本质是 DLL 的变体，只是额外带类型注册信息。窗口程序几乎必带 vcl60.bpl 和 rtl60.bpl。dll 管语言运行时和内存，bpl 管界面组件和 RTL 大型封装，两者的加载方式是相同的，都遵循系统 DLL 搜索顺序。

2.2 常用运行库清单：一个文件对应一类功能

下表是 BCB6 程序最常依赖的运行库文件，按出现频率排列。这套运行库资源里的核心文件也以这张表为主，个别工程会多带第三方控件包，但跑不出这个范围。

逐个说关键点。borlndmm.dll 和 cc3260mt.dll 是普通 dll，加载优先级是 exe 所在目录优先于 System32。这个特性很重要：程序目录放一份正确版本，即使系统目录里有旧版，Windows 也会优先用程序目录的；反过来什么都不放，系统里的旧版本就可能接管，引发版本不匹配。

rtl60.bpl、vcl60.bpl、vclx60.bpl 是 bpl 后缀。vclx60.bpl 很多基础窗体程序其实不依赖，但如果界面用了 ToolBar、StatusBar 这类扩展控件，链接器会悄悄把它加进依赖列表。这也是“老版本正常、新版本闪退”的经典原因：新功能引入新控件，运行依赖多了个包，打包清单还是旧的。

dbrtl60.bpl 只在工程里放了数据库相关组件时出现。ADO 组件一般在这个 bpl 里，而 BDE 是一整套独立运行库，不在标准运行库范围内，真用到 BDE 的工程要额外处理。

2.3 怎么查某个 exe 缺了什么：两条排查命令

第一种是静态查依赖。装了 Visual Studio 或 Build Tools 的情况下，在“开发人员命令提示符”里执行：

dumpbin /dependents MyTool.exe

输出会列出 exe 直接导入的 dll。注意一个坑：dumpbin 只列直接依赖，不会递归走进 bpl 内部看它自己还依赖谁。它告诉你 exe 需要 vcl60.bpl，但不会告诉你 vcl60.bpl 内部还依赖 rtl60.bpl。所以完整做法是顺着列表把每个 bpl 再 dump 一遍，直到依赖树闭合。嫌麻烦就用带依赖树展示的图形工具，把 exe 拖进去直接看 Missing 项，省事得多。

第二种是运行时确认。没有开发工具时，直接在目标机器上用 PowerShell 做存在性检查：

$need = @("borlndmm.dll", "cc3260mt.dll", "rtl60.bpl", "vcl60.bpl", "vclx60.bpl", "dbrtl60.bpl") foreach ($f in $need) { $inApp = Test-Path (Join-Path $PWD $f) $inSys = Test-Path (Join-Path $env:SystemRoot "System32\$f") if ($inApp) { Write-Host "$f OK(目录内)" } elseif ($inSys) { Write-Host "$f OK(System32)" } else { Write-Host "$f MISSING" } }

脚本逻辑是：对清单里每个文件，先查当前目录，再查 System32，哪边有都算能找到，找不到就输出 MISSING。实际排查时把 PWD 换成 exe 所在目录。bpl 通常不会放 System32，所以 MISSING 基本就是真缺。这个脚本只探测存在性，不做版本比对，版本问题见第 4 章。

3. 部署运行库：三种方式与自动拷贝脚本

3.1 三种部署方式对比：同目录、System32、安装包

拿到运行库资源后，第一步不是复制，而是想清楚放哪。三种常见方式，利弊差异很大。

第一种是 exe 同目录。把需要的 dll 和 bpl 与 exe 放同一文件夹，绿色包通常这么做。优点：目标机器不需要管理员权限，卸载时删除整个目录即可，不污染系统；缺点：每个程序都要带一份，磁盘冗余。对内网工具、U盘分发、客户现场调试来说，这是最推荐的方式，也是这套资源最典型的使用场景。

第二种是 System32。把运行库拷进 C:\Windows\System32，看似省事，所有程序共享一份，但最不建议。原因有二：写入 System32 需要管理员权限，Win7 之后系统对系统目录写入限制越来越严格，拷进去了也可能被还原；更麻烦的是，borlndmm.dll 和 cc3260mt.dll 在不同程序、不同版本之间互相覆盖，很容易引发别的软件崩溃。某个老管理软件本来正常，你为了跑另一个 BCB6 程序往里丢了份新 borlndmm.dll，老软件当场内存报错，这种现场真实发生过不止一次。

第三种是安装包。用 Inno Setup 或 NSIS 把运行库装到 Program Files 下，配合卸载逻辑，适合正式对外发布的产品。本质上和 exe 同目录是一个道理，只是多了路径管理和卸载注册。小工具没必要上安装包，但面向非技术客户的软件，一个能双击安装的 exe 比一堆散文件友好太多。

我的习惯：内部工具一律走 exe 同目录；对外正式版本才用安装包，且安装包只拷贝该程序真正依赖的少数几个文件，不把整包运行库全塞进去。

3.2 批处理快速部署：从运行库目录拷到目标目录

最典型的落地场景：运行库已经解压到工作目录，现在要把 exe 发布到某个文件夹，希望把缺的运行库一起拷过去。批处理脚本如下：

@echo off setlocal rem 运行库解压后的目录，按实际路径改 set SRC=C:\runtime_dll\BCB6 rem 目标目录固定为脚本所在目录 set DST=%~dp0 set FILES=borlndmm.dll cc3260mt.dll rtl60.bpl vcl60.bpl vclx60.bpl dbrtl60.bpl for %%f in (%FILES%) do ( if exist "%SRC%\%%f" ( copy /Y "%SRC%\%%f" "%DST%\%%f" >nul echo [OK] %%f ) else ( echo [MISSING] %%f 源目录里找不到 ) ) echo. echo 拷贝完成，缺失项请单独处理。 pause

脚本逻辑：SRC 是运行库源目录，DST 是 bat 所在目录，FILES 是待拷贝清单。for 循环逐个检查文件在源目录是否存在，存在就覆盖拷贝并打印 OK，不存在就打印 MISSING。copy /Y 的 /Y 表示目标已存在时不询问直接覆盖，适合反复打包场景。

几点注意。一是 bat 里的中文提示受编码影响，如果最终运行脚本的机器区域设置不一致，建议把 echo 内容改成英文，或保持文件用 GBK 编码保存。二是 %~dp0 结尾自带反斜杠，拼文件名时不要再手动加 \，否则会变成双斜杠。三是这个脚本只拷贝固定清单，实际工程如果依赖第三方控件包，需要自己把对应 bpl 加进 FILES。

3.3 更可控的静默脚本：全量复制加缺失校验

批处理适合手工跑，自动化发布管道里我倾向用 PowerShell，因为可以拿退出码，让 CI 在缺文件时直接报错。下面脚本做两件事：先把运行库目录里的文件全部复制到发布目录，再按清单做存在性校验：

$src = "C:\runtime_dll\BCB6" $dst = Split-Path -Parent $MyInvocation.MyCommand.Path $required = @("borlndmm.dll", "cc3260mt.dll", "rtl60.bpl", "vcl60.bpl", "vclx60.bpl") # 全量复制 src 下所有文件到 dst，-Force 覆盖已存在文件 Copy-Item -Path (Join-Path $src "*") -Destination $dst -Recurse -Force # 逐个校验关键文件 $missCount = 0 foreach ($f in $required) { if (Test-Path (Join-Path $dst $f)) { Write-Host "[OK] $f" } else { Write-Host "[MISSING] $f" $missCount++ } } if ($missCount -gt 0) { exit 1 } else { Write-Host "部署校验通过" }

和上一节批处理的差别：全量复制不挑文件，省得手写清单漏项；校验阶段用 required 数组做精查，漏了就以退出码 1 失败，不会带着病发布。参数解析：src 指向运行库解压后的实际位置，dst 由脚本自动取当前目录，required 按需增删。

运行细节：PowerShell 默认执行策略可能阻止脚本运行，需要powershell -ExecutionPolicy Bypass -File deploy.ps1显式授权，或把执行策略改成 RemoteSigned。这不是脚本问题，是 Windows 默认安全策略，发布文档记得写清楚。

4. 运行库排查：五个常见问题从现象到解决

4.1 双击 exe 闪退，无任何提示

现象：exe 双击后鼠标转一下圈，然后什么都没发生，没有弹窗，事件查看器里也不一定有记录。

原因：最常见是缺少 bpl。bpl 缺失时有些系统直接终止进程，连错误弹窗都不给；也可能是加载器初始化 vcl60.bpl 时失败，界面还没起来就被杀了。

解决：先用 2.3 的 dumpbin 或依赖图工具看 Missing 项，把缺的 bpl 拷到 exe 同目录。经验说一句：闪退优先怀疑 bpl，弹窗提示缺 dll 才怀疑 dll，两者失败模式不同。把 vcl60.bpl、rtl60.bpl、vclx60.bpl 一起带上，大多数闪退当场解决。

4.2 报错“无法定位程序输入点 xxx 于动态链接库 borlndmm.dll”

现象：程序能启动，到某个操作时弹窗提示无法定位程序输入点，或启动阶段直接报错。

原因：这不是缺文件，而是文件版本不对。borlndmm.dll 在系统目录中存在，但被多个软件覆盖过，当前这份和 exe 期望的内存管理接口对不上。BCB6 的 borlndmm.dll 和后续版本存在接口差异，老 exe 找的是老入口，新 dll 不给这个入口，加载器直接抛出无法定位。

解决：把运行库资源里配套的 borlndmm.dll 放到 exe 同目录，利用程序目录优先于 System32 的加载顺序把它顶上去。千万别往 System32 里覆盖，否则会把问题扩散给机器上的其他软件。这条的核心教训是：目录优先级是排错第一工具，放不进 System32 的问题，往往放同目录就解决了。

4.3 报错 0xc0000135，程序无法启动

现象：Windows 弹窗显示应用程序无法启动，错误代码 0xc0000135。

原因：0xc0000135 在 Windows 里对应的语义是找不到所需的 DLL，但它不告诉你缺的是哪个。BCB6 程序没有 .NET 依赖，所以这个错误出现在 BCB6 exe 上时，多半是加载器找不到某个 bpl，但也可能是目标机器本身缺 VC++ 运行库这类系统组件。两者都会报同一个码。

解决：先按缺 dll 处理，把 bpl 补齐看是否解决；补完还报，再去查 VC++ 运行库。很多 BCB6 程序间接调用系统组件，精简版 Windows 上缺了这些运行库也会报 0xc0000135，这时候补的不是 BCB dll，而是系统运行库。

4.4 新版本跑不起来，旧版本却正常

现象：同一台机器，旧版 exe 正常运行，新版 exe 双击即崩或提示缺少文件。

原因：新版代码加了新控件或新功能，链接器悄悄把新的 bpl 或 dll 加进依赖列表，发布目录却还是按旧版本清单打包。这是最典型的人为疏忽：不是运行库坏了，是清单没跟上代码变更。

解决：每次发布前用 dumpbin 重新查一遍依赖，把所有 Missing 项补进发布目录。vclx60.bpl 和 dbrtl60.bpl 是最容易被漏掉的两个。改代码后必查依赖树，比现场翻车再去补高效得多。

4.5 部署后其他程序开始报内存错误

现象：你的 BCB6 程序能跑，但客户机器上其他软件开始间歇性崩溃，弹窗大多和内存访问有关。

原因：几乎可以断定运行库被放进了 System32。borlndmm.dll 是全局内存管理器，不同程序对它版本要求不一致，你的部署覆盖了别人依赖的版本，别人的程序先崩。

解决：撤掉 System32 里的 BCB dll，运行库改放到 exe 同目录，再从原安装包恢复系统目录里被覆盖的旧版本。第 3 章强调 exe 同目录优先，不是没道理的。

5. 进阶：静态链接与自解压，彻底告别缺 dll

5.1 静态链接的两个开关：编译期把依赖写进 exe

如果不想每次发布都拖着一堆运行库，更彻底的方案是编译期改配置。两个开关同样在 Project → Options 里：

• Linker 页：取消勾选 Use dynamic RTL
• Packages 页：取消勾选 Build with runtime packages

第一个开关决定 cc3260mt.dll、borlndmm.dll 这类 C++ 运行库是否外部化，第二个决定 vcl60.bpl、rtl60.bpl 这类 VCL 包是否外部化。两个都取消后，编译器把运行库和组件实现直接编进 exe，输出体积明显变大，一个几百 KB 的小工具可能变成 2~3 MB，但换来的是目标机器零依赖。

这个方案不是没有代价。第三方控件通常以 bpl 形式分发，如果工程用了这类控件，取消 runtime packages 后编译可能报错，因为控件的运行期包是按动态加载设计的。另外静态链接后 exe 无法通过更新 bpl 做组件热更新，打补丁只能整包替换。适合小工具、内部工具、对分发环境敏感的现场软件；不适合几十个模块互相引用的大系统。

5.2 自解压包：把运行库和 exe 打包成一个文件

面向非技术用户交付时，散文件不合适。常见做法是用 7-Zip 自解压模块做 SFX 包：用户双击一个文件，运行库自动释放到临时目录，然后启动主程序。以 7z SFX 为例，配置文本大体是这样：

;!@Install@!UTF-8! Title="MyApp 安装与启动" BeginPrompt="即将复制运行库并启动程序，是否继续？" RunProgram="setup.bat" ;!@InstallEnd@!

配置里 Title 是自解压窗口标题，BeginPrompt 是用户看到的确认提示，RunProgram 指定释放完成后要执行的脚本。配合的 setup.bat 负责把释放到临时目录的 dll 复制到 exe 所在目录，或者直接在当前目录启动主程序。注意 SFX 释放目录通常不是 exe 最终目录，脚本要处理路径，常见做法是让 bat 在自身目录下完成拷贝再启动。

这个方式在运维里很实用。客户不关心你缺哪个 dll，他们只需要双击一个文件，程序打开。自解压包本质是把第 3 章的部署脚本和运行库封装进一层壳，对交付体验提升非常明显。

5.3 发布前自检：用清单比对代替人工记性

无论动态还是静态发布，建议打包前跑一遍清单比对。维护一个 manifest.txt，每行写一个必需文件，然后用脚本检查发布目录：

$manifest = ".\manifest.txt" $required = Get-Content $manifest $missing = $required | Where-Object { -not (Test-Path (Join-Path (Split-Path -Parent $MyInvocation.MyCommand.Path) $_)) } if ($missing) { Write-Host "以下文件缺失:" $missing | ForEach-Object { Write-Host " $_" } exit 1 } else { Write-Host "清单校验通过" }

清单比对逻辑很直白：读 manifest.txt 的每一行，逐个检查文件是否存在于脚本所在目录，有缺失就列出并返回退出码 1。把这个脚本挂进发布流程或每次打包前手动跑一遍，能挡住绝大多数运行库忘带的翻车。manifest.txt 本身要跟着工程变更走：每当依赖树里新增一个 bpl 或 dll，顺手加一行。

6. 验证加载路径：别让程序偷偷用了别人的 dll

运行库齐不齐是一回事，实际加载的是哪一份是另一回事。经手一台老旧的 XP 现场机器时遇到过这种情况：程序目录里明明放了对的 borlndmm.dll，程序还是启动失败，查到最后发现 exe 加载了 System32 里的旧版本。原因是程序目录那份文件拷进去时被只读属性挡住，加载器读不到它，回退到了系统目录。从那以后养成一个习惯：验证 BCB6 运行库部署，不只查文件在不在，还要查实际加载路径。

Windows 命令行里没有一条内置指令能直接看出进程加载的 dll 完整路径，tasklist /m 只能看到模块名，看不到加载自哪个目录。最实用的是用进程查看类工具，比如 Process Explorer。打开它，找到目标 exe 进程，查看模块列表，找到 borlndmm.dll 和 vcl60.bpl 那一行，确认路径列是否指向程序目录。如果指向 System32，说明部署优先级出了问题，优先查程序目录那份文件为什么没生效。

更自动化的做法是启动后立刻抓一次模块列表，和发布清单逐项比对。路径列里所有 BCB6 相关文件都应指向发布目录，出现一条异路径都要查。这个习惯能抓出三类隐蔽问题：文件根本没拷进去、文件拷进去但权限导致读取失败、程序目录有同名不同版本且版本不匹配。

同时保留一台干净机器做模拟验证：挑一台没装过 BCB6 的 Windows 虚拟机，把发布目录整个拷过去，双击跑一遍核心流程。这一步能直接暴露缺文件和路径加载问题，比开发机上看再多次都可靠。从那以后，每次发 BCB6 程序都强制走一遍“清单比对 + 干净机器验证 + 加载路径确认”三步，再没在运行库上翻过车。这套 BCB6 常用 dll 运行库资源正好支撑这套流程，解压后按第 3 章脚本部署、按第 4 章条目排查，基本能覆盖绝大多数场景。希望帮到你。

本文还有配套的精品资源，点击获取