PowerBuilder 9.0安装包Win10/Win11兼容安装与连库验证
简介:PowerBuilder 9.0 安装包及配套说明面向需要搭建经典PB开发环境的高校学生、开发人员与上机考试备考者,重点解决旧版工具获取、部署及兼容性确认等问题。压缩包共69个文件、约282.22MB,以exe、cab、ex_等安装程序与数据组件为主,辅以ini、inf、lbl等配置介质文件,以及sql脚本、txt和docx说明、教程文档、zip组件,兼顾安装介质完整性与后续查阅。包内附有安装说明,并针对Windows 10环境整理了注意事项,便于在课程实验或备考前核对安装条件。已有2454人学习下载,在PB9学习与上机场景中具有一定参考价值。需要复现旧版开发环境、查阅常用函数或数据库连接示例的读者,可借助文档与脚本快速定位材料,也可通过教程补充基础操作与开发思路,适合作为环境搭建和入门复习的资料合集。
1. 一份 PowerBuilder 9.0 安装包能解决什么问题:三种还在跑老工程的现场
接手一套十几年前的管理系统,源码齐全、数据库还在跑,唯独开发环境搭不起来,这种局面在维护型项目里并不少见。PowerBuilder 9.0 安装包下载这件事,表面上是找一个几百兆的安装文件,实际要解决的是「如何在一台 Win10/Win11 机器上复现出 2003 年前后的开发环境」。它面向的人群很明确:接手遗留系统维护的外包团队、要把老 PB 应用的数据迁移到新系统的工程师、需要读老 PBL 源码做逻辑还原的人。这不是新项目选型,而是一次纯粹的维护性投入;安装包能不能装、装完能不能连库、跑起来会不会在某个画笔上翻车,决定了后面所有工作的起点。基于这几个约束条件,我一般按「先拆结构、再走安装、最后验运行时」三步来做。
2. 安装包里到底有什么:六个部件与补丁级别的甄别
很多人在拿到包之后直接双击 setup.exe 一路回车,装完发现 ODBC 接口没了、示例库连不上,再回头重装。原因不复杂:PB9 的安装包不是一个单体程序,而是六个互相独立的部件捆在一起,组件勾选页面一旦默认取消掉项,后面就得靠补装才能补回来。所以动手之前先看清包里到底装的是什么,比装快十分钟更重要。
2.1 六个部件与它们各自的职责
一个完整的 PB9 安装介质解压出来,常见结构大致是这样的:
PB9/ ├─ setup.exe 安装引导程序(InstallShield 打包) ├─ DISK1/ … 主安装数据 ├─ SHARED/ 共享组件(ODBC 驱动、帮助、注册工具) ├─ ASA/ 本地数据库引擎与示例库 └─ DOC/ 联机帮助与示例代码对应的功能部件可以按下面这张表来理解,装不装取决于你要干什么:
| 部件 | 典型目录或文件 | 是否必装 | 作用 |
|---|---|---|---|
| PowerBuilder IDE | 主程序 pb90.exe | 必装 | 画笔、调试器、PBL 库管理 |
| 数据库 native 接口 | pbodb90.dll、pbmss90.dll 等 | 按需 | ODBC 与各类数据库的 PB 专用驱动 |
| ASA 本地引擎 | ASA 目录 | 建议装 | 自带示例库,用于脱离生产库做验证 |
| InfoMaker | IM 目录 | 按需 | 报表制作,老系统常单独发报表工具 |
| 运行时 DLL | pbvm90.dll、pbdwe90.dll 等 | 必装 | 编译出的 exe 在目标机运行所需 |
| 示例与帮助 | Code Examples | 建议装 | 查 DataWindow 语法和旧写法 |
我自己的习惯是:IDE、native 接口、ASA、示例代码这四项全勾,InfoMaker 看项目里有没有 .pbl 报表需求再决定。PowerDynamo 那一类 Web 部署组件基本都是空的,勾了只是多占几百兆磁盘空间。
2.2 补丁级别比安装包版本更关键
PB9 在生命周期里出过多个补丁级别,同一个「9.0」字样下面可能对应不同的小版本。维护老工程时最怕的是:生产环境跑的是打过补丁的运行时,本地装的是最初版本,编译出来的 pbd 在客户机上直接报版本不匹配。
判断手上这份包是哪一档,装完之后最直接的办法是打开 IDE,看 Help → About 里的版本串,通常形如9.0.x (Build xxxx)。注册表里也有一份记录:
# 只读检查,确认安装落点和版本键 $paths = @( "HKLM:\SOFTWARE\WOW6432Node\<厂商>\PowerBuilder\9.0", "HKLM:\SOFTWARE\<厂商>\PowerBuilder\9.0" ) foreach ($p in $paths) { if (Test-Path $p) { Get-ItemProperty $p | Format-List } }这段脚本里<厂商>是安装时显示的产品厂商名,不同打包来源写法可能不一致,所以两个路径都探一遍。WOW6432Node这一支必须查,因为 PB9 是纯 32 位程序,在 64 位系统上安装信息会被重定向到这里。
提示:把装好的这份注册表分支导出成 .reg 留档,以后换机器或者和同事对版本,直接比对键值比肉眼翻界面快得多。
2.3 拿到包先做一次校验与归档
下载来源不可控的时候,别急着装。先算一遍哈希,和发布方提供的值对一下;没有提供值的,至少把哈希记下来,方便日后确认「我这台机器上装的是不是同一份」。
# 计算安装包哈希并记录到归档清单 $iso = "D:\pkg\PB9\setup.exe" $h = Get-FileHash -Algorithm SHA256 -Path $iso "{0} {1}" -f $h.Hash, $h.Path | Tee-Object -Append "D:\pkg\PB9\sha256.txt"-Algorithm建议用 SHA256,MD5 在老资料里常见但碰撞风险高,做归档校验已经不太合适。Tee-Object -Append的作用是同一份清单可以累积多个文件,以后整包迁移时一眼能看出哪几个文件被替换过。
归档我一般留三样东西:原始安装介质的只读副本、装完后导出的注册表分支、安装目录下的 pb.ini 与 pbodb90.ini。前两个用于重装,后两个用于排查「为什么同事的机器能连库,我的不能」——老 PB 项目里很大一部分连接问题最后都落在 ini 文件的差异上。
2.4 安装前的磁盘与权限确认
PB9 的安装目录最大会吃掉 1G 以上,加上示例库和帮助文档,留 3G 空间比较稳妥。路径本身有两条必须遵守的限制:全英文、无空格。C:\Program Files\PowerBuilder 9.0这种默认路径在部分老打包脚本里会被截断成C:\Program,编译时引用资源就会莫名其妙失败。我一般直接把根目录定成C:\PB9,短、无空格、权限简单。
权限方面,安装过程必须用管理员身份,装完之后的 IDE 首次启动最好也用管理员跑一次,让它把用户级的配置写全。之后再切回普通权限使用,避免长期用管理员开 IDE 带来的文件所有者混乱。
3. 在 Win10/Win11 上装 PB9:兼容模式、组件勾选与注册表落点
PB9 出厂年代对应的是 Windows 2000/XP,直接在现代系统上双击 setup.exe,十有八九会卡在某一步:要么安装程序在「Updating System Configuration」停住,要么装完 IDE 双击没反应,进程在任务管理器里一闪就消失。这些问题都不是安装包坏了,而是兼容层没有提前铺好。
3.1 装之前先给安装程序打上兼容标记
最省事的做法是给 setup.exe 单独设兼容性,而不是给整个系统降级。图形界面路径是右键属性 → 兼容性 → 勾选「以兼容模式运行这个程序」并选择 Windows XP (Service Pack 3),同时勾选「以管理员身份运行此程序」。批量部署时可以用注册表直接写:
# 给安装程序写入兼容性标记:XP SP3 + 管理员 $exe = "D:\pkg\PB9\setup.exe" $key = "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" if (-not (Test-Path $key)) { New-Item -Path $key -Force | Out-Null } $value = "~ WINXPSP3 RUNASADMIN" New-ItemProperty -Path $key -Name $exe -Value $value -PropertyType String -ForceWINXPSP3指定兼容层版本,RUNASADMIN让系统在启动时弹 UAC 提权,~是这一串标记的分隔前缀,缺了它系统不会识别。这条设置写在HKCU下,只对当前用户生效,换账户要重写一遍。
安装过程中如果卡在进度条某处超过十分钟,先别急着强杀。打开任务管理器看setup.exe是否还有 CPU 占用;完全没有占用的话,多半是安装程序在等某个 16 位子进程回调,此时强杀再重来通常无效,得先清掉%TEMP%下的 InstallShield 残留目录再装。
3.2 组件勾选页面的取舍
走到组件选择那一步,默认勾选往往不全。按前面的部件表,我的勾法是这样的:
| 组件 | 勾选建议 | 不勾的后果 |
|---|---|---|
| PowerBuilder | 必勾 | 没有 IDE |
| ODBC 接口 | 必勾 | 连库报 DBMS 不支持 |
| Native 数据库接口 | 按生产库类型勾 | 只能走 ODBC,性能差一截 |
| ASA / 示例库 | 建议勾 | 缺一个可离线验证的库 |
| InfoMaker | 看项目 | 报表 .pbl 打不开 |
| Web 部署组件 | 一般不勾 | 无影响,只占空间 |
有个细节容易被忽略:安装程序会问是否安装「共享组件」到公共目录,这一步选是。PB9 的 OCX 控件和 ODBC 驱动会注册到系统级,选否的话,同一台机器上其他账户登录后可能找不到驱动。
3.3 高分屏下的界面与 DPI 设置
Win10 之后默认缩放经常是 125% 或 150%,PB9 的画笔界面是按 96 DPI 画的,缩放后按钮被裁、DataWindow 设计区尺寸失真。处理方式是给主程序单独关掉 DPI 缩放:
# 关闭 pb90.exe 的高 DPI 缩放,避免画笔界面错位 $exe = "C:\PB9\pb90.exe" $key = "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" New-ItemProperty -Path $key -Name $exe ` -Value "~ HIGHDPIAWARE" -PropertyType String -ForceHIGHDPIAWARE告诉系统这个进程自己处理缩放,实际效果是把界面按 100% 渲染,字体略小但布局不再错乱。代价是在 4K 屏上字会比较小,通常配合把显示器缩放临时调到 100% 使用。
3.4 注册表与配置文件的实际位置
装完之后,配置并不只存在一个地方。IDE 的界面布局、最近打开的工程记在用户目录的 ini 里,数据库接口的参数在安装目录的 pbodb90.ini,而安装信息、组件注册在注册表。三处不一致时就会出现「设置明明改了却不生效」的玄学现象。
排查顺序我固定为:先看安装目录 pb.ini 的[Database]段,再看用户目录是否有同名文件覆盖,最后查注册表分支。用户目录的 ini 优先级高于安装目录,这一点在多人共用一台机器时特别容易出问题——A 改了连接参数,B 登录后用的还是自己的那份。
注意:不要把安装目录做成网络共享给多人同时开发,pb.ini 会被并发写坏,PBL 库文件也可能因为文件锁出现只读。要么每人本地一份,要么走源码管理导出。
4. 连库与第一个 DataWindow:事务对象、驱动和 PB.INI 的配合
环境装完只是把工具摆上桌,真正验证这套环境可用,是让 IDE 连上数据库、拖出一个 DataWindow 并成功检索出数据。这一步过了,后面读代码、改逻辑、编译发布才有意义。PB 的数据库访问模型和现在的 ORM 完全不同,它围绕一个叫事务对象(Transaction Object)的全局变量转,全局默认的那个叫 SQLCA。
4.1 三种连接方式怎么选
| 方式 | DBParm 里的 DBMS 写法 | 适用场景 | 主要代价 |
|---|---|---|---|
| ODBC | "ODBC" | 快速验证、冷门数据库 | 多一层驱动,性能略低 |
| Native 接口 | 按库类型,如"MSS Microsoft SQL Server" | 生产环境常规选择 | 需要对应 DLL 已安装 |
| 直连 ASA | "SYC Sybase Adaptive Server Anywhere" | 本地示例库验证 | 仅限 ASA |
维护老系统时,我建议先用 ODBC 打通,确认账号、网络、库名都没问题,再切到 native 接口调优。反过来的顺序会让你在驱动层和网络层之间反复怀疑,浪费大量时间。
4.2 用脚本设置 SQLCA 并连接
在应用对象的 Open 事件里写连接逻辑,是最常见的落地位置。下面这段可以直接抄改:
// 应用 open 事件:配置事务对象并连接数据库 SQLCA.DBMS = "ODBC" SQLCA.AutoCommit = False SQLCA.DBParm = "ConnectString='DSN=easdemo9;UID=dba;PWD=sql'" CONNECT USING SQLCA; IF SQLCA.SQLCode <> 0 THEN // SQLCode: 0 成功, 100 未找到, -1 出错 MessageBox("数据库连接失败", SQLCA.SQLErrText) HALT CLOSE END IFDBMS决定走哪个接口,写错会直接报「DBMS xxx is not supported in your current installation」,这基本等价于「安装时没勾对应驱动」。AutoCommit = False是老项目里更安全的默认值,意味着更新后必须显式COMMIT,好处是出错能回滚,坏处是忘了提交会锁表。DBParm里的ConnectString是 ODBC 专用写法,换成 native 接口时要改成Database、ServerName、LogId、LogPass这些分散属性。
SQLCode的三种取值要记牢:0 是成功,100 是没查到记录(不是错误),-1 才是真出错。很多老代码把 100 当失败处理,导致空表场景下一进界面就弹错误框。
4.3 SetTrans 与 SetTransObject 的区别
新手最常踩的一个坑,是分不清SetTrans和SetTransObject。前者让 DataWindow 自己用内部事务连接数据库,用完即断;后者共享外部传入的事务对象,连接复用。
// 推荐:共享应用级事务,性能好、可统一提交 dw_1.SetTransObject(SQLCA) dw_1.Retrieve() // 不推荐在循环里用:每次 Retrieve 都可能新建连接 // dw_1.SetTrans(SQLCA)SetTrans不是不能用,它在单次查询、不需要事务控制的场景下反而简单。但只要涉及多条 DataWindow 联动更新,就必须用SetTransObject,否则每条 DataWindow 各自提交,一条失败一条成功,数据就脏了。
4.4 更新、提交与回滚的标准写法
检索出来只是第一步,能不能正确写回才是关键。DataWindow 的 Update 返回值约定是:1 表示成功,0 表示没有行需要更新,-1 表示失败。
// 保存按钮:更新并显式提交 Long ll_rc ll_rc = dw_1.Update() IF ll_rc = 1 THEN COMMIT USING SQLCA; IF SQLCA.SQLCode <> 0 THEN ROLLBACK USING SQLCA; MessageBox("提交失败", SQLCA.SQLErrText) END IF ELSEIF ll_rc = -1 THEN ROLLBACK USING SQLCA; MessageBox("更新失败", SQLCA.SQLErrText) END IF这段代码的价值在于它覆盖了Update成功但COMMIT失败的情况——数据库连接中断、死锁、约束冲突都可能发生在提交阶段,此时必须回滚,否则会留下悬挂事务把表锁住。老项目里经常见到只判断Update返回值、不判断COMMIT结果的写法,线上偶发的「表被锁住」大多来自这里。
要让 Update 正确生成 SQL,DataWindow 还得配好三件事:更新属性里选择目标表、指定主键列、勾选可更新列。主键选错会导致更新影响 0 行却返回成功,这是最隐蔽的一类问题。
5. 五类现场排查:装不上、打不开、连不通、乱码、打印崩
这些问题我在不同机器上反复遇到过,下面按「现象 → 原因 → 解决」写,方便对照排查。
5.1 安装程序卡在进度条不动
现象:setup.exe 跑到一半停住,进度条长期不动,CPU 占用接近零。
原因:老版 InstallShield 在处理系统配置回调时会等待一个 16 位兼容子进程,现代系统上该进程无法正常创建;也可能残留了上一次中断安装的临时文件。
解决:先清理%TEMP%下以_is或{开头的残留目录,再确认 setup.exe 已加 XP SP3 兼容标记和管理员权限,然后重启机器重新安装。仍然卡住的话,改用解压工具把安装介质里的 DISK1 内容摊平到本地目录,从里面的 data 目录直接手工拷贝文件,再补跑共享组件的注册脚本。
5.2 装完双击图标没反应
现象:pb90.exe 双击后进程一闪而过,没有任何窗口和报错。
原因:主程序缺少兼容性设置,或者安装时依赖的 VC 运行库、MSXML 组件没注册成功。
解决:给 pb90.exe 加 XP SP3 兼容标记并以管理员身份运行一次;确认安装目录下 pbvm90.dll、pbshr90.dll 等运行时文件都在;用依赖查看工具看 pb90.exe 是否缺少某个系统 DLL,缺什么补什么。
5.3 连库报 DBMS 不支持
现象:脚本里写SQLCA.DBMS = "ODBC",运行时提示该 DBMS 在当前安装中不受支持。
原因:安装时 ODBC 接口组件被取消勾选,或者 pbodb90.dll 没有注册到系统。
解决:重跑安装程序,只勾选数据库接口组件做补装;补装后确认安装目录下存在 pbodb90.dll,并在 ODBC 数据源管理器里能看到对应 DSN。DSN 是 32 位的,64 位系统默认打开的是 64 位数据源管理器,要专门找 32 位那个版本。
5.4 中文数据检索出来是乱码或问号
现象:库里存的中文,DataWindow 检索出来显示成方框、问号或乱码。
原因:数据库字符集和 PB 连接的 NLS 设置不一致,或者客户端字体缺失。
解决:先确认数据库端的字符集,再在 pbodb90.ini 里调整对应的 NLS 配置项;ODBC 连接串里也可以显式带上字符集参数。改完必须完全退出 IDE 再重进,ini 只在启动时读取一次。字体问题则是另一回事,DataWindow 里指定了系统不存在的字体时会退化成符号字体,换成通用中文字体即可。
5.5 打印预览空白或打印时报错
现象:DataWindow 打印预览一片白,或者点打印直接抛异常。
原因:系统默认打印机是虚拟打印机(PDF 打印机、OneNote 之类),老版打印逻辑无法正确获取设备上下文。
解决:把一台真实物理打印机设为默认,或者装一个稳定的 PDF 打印机驱动并确保它能正常打印测试页;再检查 DataWindow 的打印规格里纸张尺寸是否与驱动支持的尺寸匹配,自定义纸张在老驱动上经常不被识别。
6. 运行时打包与版本共存:怎么确认这次装的是真能用
IDE 能开、能连库,不等于交付的 exe 在客户机上能跑。PB9 的运行时是一组 DLL,缺一个就是启动即报错,而且报错信息往往只有一句模糊的「找不到组件」。所以装完环境之后,我还会再走一遍运行时验证,确认这套安装是完整的。
6.1 最小运行时清单
| 文件 | 作用 | 是否必须 |
|---|---|---|
| pbvm90.dll | PowerBuilder 虚拟机,解释执行 pbd | 必须 |
| pbshr90.dll | 公共函数库 | 必须 |
| pbdwe90.dll | DataWindow 引擎 | 有 DataWindow 就必须 |
| pbtrs90.dll | 事务与数据库接口管理 | 连库就必须 |
| pbodb90.dll | ODBC 接口实现 | 走 ODBC 就必须 |
| libjcc.dll | Java 支持底层库 | 部分版本启动即依赖 |
清单的用法很简单:把编译出来的 exe、pbd 和上表文件放进同一个目录,在一台没装过 PB 的干净机器上双击。能起来、能连库、能出数据,才算交付成立。用注册表或 PATH 去找 DLL 的做法不要用在交付机上,路径污染导致的版本错乱极难排查。
6.2 多版本共存时的顺序问题
机器上同时装 9.0 和更高版本时,冲突主要发生在两处:一是 OCX 控件的 CLSID 注册,后装的高版本会覆盖低版本注册项,导致老工程打开时控件加载失败;二是 PATH 里运行时 DLL 的搜索顺序,exe 优先加载同目录,其次才是 PATH,所以同目录自查最可靠。真要共存,我给每个版本单独装目录、单独配快捷方式,PATH 里一个都不加,靠 exe 同目录的 DLL 决定实际版本。
6.3 四步验收法
新建一个空 Application,拖一个窗口,写上面那段连接脚本,连上库后建一个 DataWindow 检索十行数据,最后编译成 exe 拷到干净机器跑一遍。四步全过,说明这次安装包下载到的介质是完整的、组件是全的、运行时是配套的。
从那以后我每次装完 PB9,都会强制走一遍这四步,哪怕当时只是要打开一个老 PBL 看一眼代码。花十分钟换来的是不用在客户现场对着「找不到 xxx.dll」发呆。希望帮到你。
本文还有配套的精品资源,点击获取