![Powerbuilder Powerbuilder](http://www.softwareprotection.info/wp-content/uploads/2013/12/s3.png)
PowerBuilder is the award-winning development software / tool owned by SAP that simplifies the. Ascential Test - Enable - PowerDesigner - SQL Anywhere.
Firstly my original question link regarding PB 10.5 on windows 7 64-bit has been mostly answered in the following link - Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine? Currently have a 32-bit application on Windows XP. Client wants it working in Windows 7 64-bit. I know this is a big jump and PB 10.5 has been unsupported for a long time now. Has any one successfully fooled around with The Runtime Packager PowerBuilder runtime DLLs and got any of the following DLL's wokring in a Windows 7 64-bit system? Libjcc.dll libjutils.dll pbacc105.dll pbdwe105.dll pbdwr105.dll pbdwr105.pbd pbjag105.dll pbjvm105.dll pbshr105.dll pbtra105.dll pbvm105.dll I realize these are 32-bit DLL's but I need to start somewhere and not sure how to tackle this one.
Hoping for anyones help or advise. Debuggin the app has been a bit of challenge only because of the environment setup for us isn't working perfect.
We have a virtual machine with Windows 7 64bit. Installed PowerBuilder 10.5 on it. It actually runs. However trying to debug the app from this point yeilds all kinds of issues. One of them is each window with a datawindow is completely blanks, no feilds, nothing. I have not tried to run your above suggestion so I will look at that.
Someone had also suggested possibly running the application with a /DEBUG swicth from a command line. Then looking at the output through PBL Peeper.
– Apr 3 '13 at 17:11. I suspect the most useful answer to you is a completely useless answer. First point is that PB 10.5 pre-dates Windows 7. Very obviously, any success of 10.5 on Windows 7 is going to rely on Microsoft's ability to provide forward compatibility of applications. (MS's success with providing forward compatibility is stellar compared to other platforms I've used, but has never been perfect.) Windows 7 was released around the PB 11.0 time frame, IIRC.
It took Sybase to somewhere in the 12.0 cycle to announce that they would support Windows 7. Support for a new platform is a good feather for your marketing cap, so a reasonable interpretation of this delay is that they found some issues and had to work them out.
(To the best of my knowledge, Sybase never listed those issues in one place, although some probably show up in the bug lists published with each patch.) I'm going to go out on a limb and bet that if you created a 10.5 application with one line in the application Open event: MessageBox ('Hello World!' ) and deployed this to Windows 7, it would work.
Conversely, from what we've inferred from Sybase's behaviour, there exists some combinations and permutations of features that will fail when deployed to Windows 7. Where your application lies in this n-dimensional spectrum of features and complexity is hard to tell. So, I suspect that your most useful answer to your question is that it doesn't matter if I've had success with a 10.5 application on Windows 7; my experience may not have a bearing on your application's success on Windows 7. There are known risks, even if we don't know exactly what those risks are. I do use PB11.5 IDE on Win7/64 (that is also 32b) without problem. Concerning the runtime packager, I do not use it anymore because I develop and maintain several products that are released asynchronously and may occur to need different runtimes, sometimes from different major PB version (10.5 / 11.5) and sometimes from different releases (EBF) of the same major.
As PB seems very picky regarding the version of the runtime (in the sense that you'd better distribute the exactly same build for the runtime as the version the application is build with), I place the runtimes dll in the same directory as the application files. There is no problem for a PB 10.5 / 11.5 PB application to use its runtime files in the same directory. Export the registry information of those dlls from a working xp 32 bit system. If the dlls didn't reside in the powerbuilder's executable path, but something like C: windows system32 or one of system32's subdirectories instead then copy the dlls to the windows 7 64 bit system's related c: windows syswow64 folder area. If it was necessary to place them in a new location then modify the registry exports to point to the new location.
If you they were from the powerbuilder's executable path, then you don't need to modify the registry exports. Merge them into the registry. Rebooting might be required. I've had success with this when old dll and ocx files turned out to be necessary to keep stuff like office database apps working after upgrading office versions. You'll want to keep a copy of the dlls and registry merge files in offline storage incase you have to rebuild your system from scratch at some future date.