Firstly my original question link regarding PB 10.5 on windows 7 64-bit has been mostly answered in the following link - PowerBuilder 10.5 Application on Windows XP 32-bit to Windows 7 64-bit
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.
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!", "It's me!")
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. Good luck.
PB 10.5 runs fine on Windows 7 (32 or 64 bit) from my all of my experience. PB 10.5 is still relatively common at large corporate IT shops, along with 11.5, 12.5 & PB 2017 (and above).
The package manager, included with PowerBuilder will gather all the runtime libraries needed. Windows 7 64-bit can run 32 bit or 64 fine via SYSWoW64, the 'WoW64' stands for Windows 32-bit on Windows 64-bit. SysWoW64 process running in your Windows is part of your Windows operating system.
Related
We are moving from CefSharp to WebView2. Because of certain requirements, we are thinking of going ahead with the fixed version where the updates can be controlled by us. Now, on Microsoft's official distribution page we have 3 options available - x86, x64 and ARM64. We have users who use different combinations of OS and CPU architecture. One example is 32 bit Windows 10 Pro running on a 64 bit Intel processor. Here is where I am confused. Which one to ship to agents depending on their combinations of OS and CPU architecture. Can anybody help here? Here are the combinations -
I have not tried out and hence may be a blunt question - can x86 distributable be a safe bait for all these combinations? If yes, then what are the trade-offs?
I think x86 distribution is safe. If 32-bit OS is running, the entire system acts as purely 32-bit. It's impossible to use any 64-bit piece of code, so 64-bit applications won't work. You can also check this thread: If you want to run 64-bit app on 32-bit OS, you have to install a VM or something. I think that's not what you want.
In conclusion, I think you should choose the WebView2 Fixed Version according to the OS version.
I'm trying to find a solution to allow me to compile C code to a DOS executable from Windows 7 64-bit. I recently updated from XP 32-bit to Win7 64-bit, and now my Borland C++ 5.0 compiler won't work. I get an error when it tries to call tlink.exe 16-bit. I'm trying to avoid bringing over another computer with XP but that will have to be my course of action if I can't figure something else out soon.
My target is an embedded x86 running FreeDOS. As much as I'd like to transition to Linux I can't afford the time that would transition would take. Aside from the learning curve of never having used Linux, much of my code is DOS-dependent and would have to be re-written.
I'm hoping there's a windows setting I can just change but my research so far leads me to believe I need a more drastic change to my process. I've sniffed around at Turbo C 2.01, DJGPP, DOSbox... not really too confident to go down any of those alleys without some outside input
Run Virtual XP or VirtualBox and install Borland C++ inside. BTW, there is version 5.02 with some fixes (in case your version is exactly 5.0).
If you can find an old Microsoft Compiler, like 16 bit C / C++ 1.52 (which is included on the 32 bit C / C++ 4.1 cd-rom), or C 8.00 or earlier, it runs using a dos extender or in a 32 bit dos console window.
Why can't you run the Borland compiler using FreeDOS?
You could try to create a virtual machine with MSDOS on it, but you'd have to find a way to install MSDOS 6.22 on the virtual machine. At Microsoft's support site, they have links to a bootable ISO file for MSDOS 6.22. I still have the original floppies and started with those on an old system that has a floppy drive. It's a bit awkward to import / export files to / from the virtual machine.
This is the config.sys that I use that seems to work with Win 7 virtual machine. I had to increase buffers, stacks, and files to avoid a stack overflow problem with this setup.
dos=high,umb
buffers=40,0
files=60
lastdrive=e
shell=c:\command.com c:\ /e:1024 /p
stacks=64,512
switches=/f
device=c:\dos\himem.sys /numhandles:64 /testmem:off
device:c:\dos\emm683.exe ram i=b100-b7ff i=c600-c7ff i=cc00-cfff i=e600-efff frame=d000 a=32 d=128 notr
devicehigh=c:vmadd\cdrom.sys /d:mscd001
This is the autoexec.bat that I use (smartdrv is a bit pointless in this case so I commented it out with "rem" prefix) .
c:\dos\emm386 auto
lh c:\dos\mscdex.exe /d:mscd001 /m:7
rem lh c:\dos\smartdrv.exe
lh c:\vmadd\mouse.com
set path=c:\dos
set blaster=a220 i5 d1 h5 p330 t6
prompt $p$g
As for a compiler, Open Watcom seems to me to be the best choice in your situation. FrameworkPascal (written in the old version of Watcom) provides a 32 bit extender. Regarding the creation of a FreeDOS virtual machines, pickup the tools from Microsoft SysInteral. They include a tool that create a VHD. Once you get a FreeDOS running in a VM you can simply SYS the VHD and start it anywhere. There are plenty ready to run ISO images for FreeDOS, one worth mentioning is Seagate Seatools for DOS which is being distributed with the FreeDOS kernel.
Your best (but not only) solution for running all that is probably XPMode on Windows 7 Pro. It runs Windows XP 32 which of course provide 100 percent transparent compatibility via its NTVDM with DOS 16 bit real mode, 16 bits protected (Windows 3.1), and DOS 32 bit extenders.
NTVDM by the way is a feature that can be activated on Windows 10 Pro but it yet to be seen what exactly can be done with it there.
XPMode is a free downnload from Microsoft that installs a free version of Windows XP 32 bit in a virtual machine on Windows 7 Pro with full sharing of the cutpaste/copy buffer, USB, drives, screen and network card (web access). It can be toggled between a Window and full screen. The installation of XPMode is automated (after activation of the Windows 7 Pro VM). Microsoft provide various downloadable hot fixes that update the registry to activate the VM. There is an MS support downloadable hot fix that has to be run to allow the installation on the AMD Bulldozer architecture. XPMode hibernate its desktop and virtual hard drives making it a much more productive environment than a hardware based system.
With a little extra work Windows XP 32 bits can be installed on any virtual machine including Microsoft Virtual Machine on Windows XP 64 bits as well as Oracle Box and VMWare. XPMode however is probably the smoothest solution since some installations such as MS Virtual Machine for Windows XP 64 bits do not utilized the full physical display in full screen (only about 90 percent of it). If you install your browser and email in XPMode you can live in the full screen and forget about new versions of Windows.
I'm about to write an app that should work under OS X and Windows XP/Vista/7. The app will require a database engine. Can someone suggest one that can do the following:
Be compatible with Windows
Be compatible with OS X (and preferably with iOS)
Preferably be available by default in those operating systems, or require minimum installation.
I understand that all three items may be hard to come by. So just curious, whatever is available?
My favorite is Sql Lite: http://sqlite.org/
It requires no installation, and is a small binary.
I have a WPF app that uses Flash10c.ocx developed on a 32 bit machine. I didn't have to register the ocx on my dev machine, I just installed the latest flash, added a reference and started coding. When testing on a 64 bit system I get ye old "Class not registered" which I think mean I need to regsvr the ocx. Is it Ok to just copy the 32 bit ocx (I'm pretty sure its 32 bit as its located in C:\Windows\System32\Macromed on the dev system) to a 64 bit system and register it?
Update: regsvr32 /i flash10c.ocx errors out with "The module flash10c.ocx las loaded but the call to DllRegisterServer failed with error code 0x80004005"
Update 2: I've given up on this and decided to run Flash on 32 bit systems only. If anyone has a better answer I'd like to hear it but I'm marking the current suggestion as answered to give due credit for the effort.
The reason it's not working for you is that your WPF application is running as 64-bit.
A .NET application is able to run as 32-bit or 64-bit; and the CLR is JITing your app to whatever architecture the application is running on - in this case 64-bit.
Except you now want your 64-bit application to load a 32-bit dll. This is not possible. A 64-bit process can only load 64-bit dlls. A 32-bit process can only load 32-bit dlls. No amount of fiddling with COM object registration will change this; it's not a question of missing registry entries.
Adobe Flash only comes as a 32-bit dll. Adobe does not now (and hopefully will never) have a 64-bit version.
In order for your WPF .NET application to load the 32-bit flash dll, it needs to be running as 32-bit process. There is a way, in Visual Studio's build configuration, to force your .NET application to only target x86, rather than Any CPU.
The choices of CPU targets are:
Any CPU
x86
x64
Itanium
Flash, for what it's worth, doesn't have an Itanium version, either.
See StackOverflow: Visual Studio “Any CPU” target for more discussion about target cpus.
May be the flash installer is meant to be only for 32 bit OS. Hence it did not install properly on a 64 bit machine. The error means that you will need to manually register the ocx but will it register successfully that's a totally different question.
Edit 1: here is Adobe's statement of support for 64-bit systems (there is none) (I assume you are using 64 bit browser on a 64 bit machine)
Edit 2: Another forum message about Flash on 64-bit Windows.
I'm working on a VB2008 project that references two Access databases using Provider=Microsoft.Jet.OLEDB.4.0;
It would seem if the user does not have MSOffice on their machine, the program crashes with a "XXX stopped working" on startup on Vista and Win7.
I thought that Windows had XP and above had Jet functionality built in? Does anyone know why this is happening? What are the correct project/publish/prerequisites required please?
TIA
There is absolutely NO Jet support for x64 architectures. So the program will runtime error if you are running on an x64 proc and your application is compiling to AnyCPU.
Change the compile target of your application to x86 explicitly and your problems should go away...if I have correctly ID'ed the issue that is. If the failing machines are running x86 OSes then you'll have to look for another solution. But if the failing machines are running x64 OSes then I guarantee this is the problem.
Seth