My application throws the exception below.
Exception in thread "main"
java.lang.UnsatisfiedLinkError: Cannot
load 32-bit SW T libraries on 64-bit
JVM.
How to solve this? What is the name of jar file needed?
On 64-bit JVM's you need the 64-bit SWT. Current versions can be downloaded here:
http://archive.eclipse.org/eclipse/downloads/drops/R-3.6.1-201009090800/index.php#SWT
Note the first two downloads, the first is for x32, the other for x64.
Note: Even on 64bit Windows, if you use the 32bit JVM, you still need the 32bit SWT version!
I faced the same problems a couple of weeks ago. We develop an RCP application that must use 32bit SWT, but we work on 64bit machines.
What we had to do was to change Eclipse's configurations so it pointed to a 32bit JVM. We did it on Window -> Preferences -> Java -> Installed JRE's. On this preference page, we changed all references from "Program Files" to "Program Files (x86)".
I hope it helps you somehow.
For the latest link to SWT library downloads:
SWT project page
My answer is more less compilation of above posted answers, especially the comment of the user #ClickUpvote who provided (by my opinion) the best answer. So here it is, I tested it just before posting it:
If your application throws the exception below (On Windows 7 64 bit, with JVM 64)
Exception in thread "main" java.lang.UnsatisfiedLinkError: Cannot load 32-bit SW T libraries on 64-bit JVM.
Then the solution is as follows:
On 64-bit JVM's you need the 64-bit SWT.
Current versions can be downloaded as described below - pretty well hidden:
Go to: http://www.eclipse.org/swt/
Scroll down to Releases
Click on more at:
Stable
Windows, Linux, OS X, more...
In new page that opens just download this file (at the time of writing this post URL is
( http://download.eclipse.org/eclipse/downloads/drops4/R-4.4-201406061215/#SWT )
Windows (x86_64) (Supported Versions) (http) 6.3 MB swt-4.4-win32-win32-x86_64.zip
And that is exactly the version you need.
You're simply building against the wrong version of SWT. Either download the 64bit Eclipse or grab the delta pack and build against the correct target environment.
Those links are all a little out of date for downloads of the 64-bit versions. Try this one: http://jarfiles.pandaidea.com/swt.html, found after an hour of googling.
Related
I want to install some software on a pre-alpha XP build (codename Windows Whistler). However, 90% of the installers fail to run. I guess it is because of the kernel version, which I suppose is somewhere between 5.0 and 5.1 (as I remember even the software that should run under Windsows 2000 did not succeed to install).
How can I most correctly and efficiently change the values in registry so that I have a chance to test some software (I know there can be bugs because of missing features, I'm doing tests in the VM).
The same question about Windows XP x64 with kernel version 5.2 - where to change it so that basic software designed for Win XP x86 does install as it does on regular Win XP (or maybe there is some compatibility option in properties).
Thanks for your help.
UPD: Java Runtime Environment version 5 update xxx should work on Windows 2000 (and even on Windows 98 SE, I tested it). But it somehow refused to install on Whistler... Maybe they cut something important away during development to make builds faster to compile?
You can try Right Click on .exe -> Properties -> Compatibility -> Run this program in compatibilty mode for.. and then specify compatible versions of OS.
I use a 64-bit OS to develop a JavaFX application and use Maven to build my application with javafx-maven-plugin to generate an installation package. The resulting package contains only a 64-bit application. So, is there a way to create a multiarch installator or create a pair of x86 / x64 installators in one pass?
UPD
Could you provide an example of a targeted build-system based on maven? Is it needed to use differents OS or just differents JRE on OS x64? In last case how to build the pair of installers per one run? How to automatically add a suffix to application name to noting the architecture? Is it needed to use e.g. Jenkins, or it can be done with maven alone? Is there a some "classic" configuration of the targeted build-system? And more, is there some drawbacks to use 32-bit application on 64-bit OS? From my tests follows that 32-bit app (for my case) is slower on 32-bit OS than on 64-bit OS. But 32-bit and 64-bit application on 64-bit OS work equally.
this is indended, because the underlying installers contain that information. There is no future where this can be provided, this was a JDK-bug once, but closed as "wont fix". As the javafx-maven-plugin uses the official javapackager-tooling, all benefits/drawbacks of that tooling is valid here too. This is even in the official documentation: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html#A1307236
You need a build-system per targeted architecture.
EDIT: regarding your updated question: you can only create windows-launchers/installers on windows-systems, you can only create linux-launchers/installers on linux-systems, and the same form mac. This means in order to get launchers/installers from the one project, you have to run the build on every platform, and two times each. One time you have to call it with 32bit JDK being installed, and the other time with 64bit JDK installed (might work on Windows to only have JAVA_HOME being set, as maven picks this up), it does not need any tool like Jenkins, but if you have it, just use it.
About the performance I can't say anything, this is out of scope and is bound to the JRE itself.
Disclaimer: I'm the maintainer of that maven-plugin.
I am trying to install Sheridan controls (ActiveThreed 2.01) on Win7 64-bit, but evidently it is a 16-bit installer so it won't execute.
What would be the best way to get round this problem?
Can anyone comment on whether http://homepage3.nifty.com/takeda-toshiya/msdos/index.html would be helpful?
It took me months of googling to find a solution for this issue. You don't need to install a virtual environment running a 32-bit version of Windows to run a program with a 16-bit installer on 64-bit Windows. If the program itself is 32-bit, and just the installer is 16-bit, here's your answer.
There are ways to modify a 16-bit installation program to make it 32-bit so it will install on 64-bit Windows 7. I found the solution on this site:
http://www.reactos.org/forum/viewtopic.php?f=22&t=10988
In my case, the installation program was InstallShield 5.X. The issue was that the setup.exe program used by InstallShield 5.X is 16-bit. First I extracted the installation program contents (changed the extension from .exe to .zip, opened it and extracted). I then replaced the original 16-bit setup.exe, located in the disk1 folder, with InstallShield's 32-bit version of setup.exe (download this file from the site referenced in the above link). Then I just ran the new 32-bit setup.exe in disk1 to start the installation and my program installed and runs perfectly on 64-bit Windows.
You can also repackage this modified installation, so it can be distributed as an installation program, using a free program like Inno Setup 5.
You can't run 16-bit applications (or components) on 64-bit versions of Windows. That emulation layer no longer exists. The 64-bit versions already have to provide a compatibility layer for 32-bit applications.
Support for 16-bit had to be dropped eventually, even in a culture where backwards-compatibility is of sacred import. The transition to 64-bit seemed like as good a time as any. It's hard to imagine anyone out there in the wild that is still using 16-bit applications and seeking to upgrade to 64-bit OSes.
What would be the best way to get round this problem?
If the component itself is 16-bit, then using a virtual machine running a 32-bit version of Windows is your only real choice. Oracle's VirtualBox is free, and a perennial favorite.
If only the installer is 16-bit (and it installs a 32-bit component), then you might be able to use a program like 7-Zip to extract the contents of the installer and install them manually. Let's just say this "solution" is high-risk and you should have few, if any, expectations.
It's high time to upgrade away from 16-bit stuff, like Turbo C++ and Sheridan controls. I've yet to come across anything that the Sheridan controls can do that the built-in controls can't do and haven't been able to do since Windows 95.
I posted some information on the Infragistics forums for designer widgets that may help you for this. You can view the post with the following link:
http://forums.infragistics.com/forums/p/52530/320151.aspx#320151
Note that the registry keys would be different for the different product and you may need to install on a 32 bit machine to see what keys you need.
I am mostly posting this in case someone comes along and is not aware
that VB2005 and VB2008 have update utilities that convert older
VB versions to it's format. Especially since no one bothered to
point that fact out.
Points taken, but maintenance of this VB6 product is unavoidable. It would also be costly in man-hours to replace the Sheridan controls with native ones. Simply developing on a 32-bit machine would be a better alternative than doing that. I would like to install everything on Win7 64-bit ideally. – CJ7
Have you tried utilizing the code upgrade functionality of VB Express 2005+?
If not,
1. Make a copy of your code - folder and all.
2. Import the project into VB express 2005.
This will activate the update wizard.
3. Debug and get the app running.
4. Create a new installer utilizing MS free tool.
5. You now have a 32 bit application with a 32 bit installer.
Until you do this, you will never know how difficult or hard it
will be to update and modernize the program.
It is quite possible that the wizard will update the Sheridan controls
to the VB 2005 controls. Again, you will not know if it does
and how well it does it until you try it.
Alternatively, stick with the 32 Bit versions of Windows 7 and 8.
I have Windows 7 x64 and a program that will not run. However,
the program will run in Windows 7 32 bit as well as Windows 8 RC 32 bit.
Under Windows 8 RC 32, I was prompted to enable 16 bit emulation
which I did and the program rand quite fine afterwords.
I had 32-bit software with a 16-bit installer that I couldn't unzip. I solved it with otvdm which allows you to run windows 1.x, 2.x, 3 programs on win64. In fact, otvdmw allows you to select the program to run (otvdm is command-line).
16 bit installer will not work on windows 7 it's no longer supported by win 7 the most recent supported version of windows that can run 16 bit installer is vista 32-bit even vista 64-bit doesn't support 16-bit installer....
reference http://support.microsoft.com/kb/946765
Bottom line at the top: Get newer programs or get an older computer.
The solution is simple. It sucks but it's simple. For old programs keep an old computer up and running. Some times you just can't find the same game experience in the new games as the old ones. Sometimes there are programs that have no new counterparts that do the same thing. You basically have 2 choices at that point. On the bright side. Old computers can run $20 -$100 and that can buy you the whole system; monitor, tower, keyboard, mouse and speakers. If you have the patience to run old programs you should have the patience to find what you are looking for in want ads. I have 4 old computers running; 2 windows 98, 2 windows xp. The my wife and I each have win7 computers.
I'm working on a web site project with a Java component and am currently testing for cross-browser compatibility. Most is fine but the Java part won't load on 64-bit browsers. Looks like I need a 64-bit JRE to test. Where does one download the (off-line) 64-bit Java runtime installer for Windows?
The official download page is here: http://www.java.com/en/download/manual.jsp
Unless I'm blind, nothing 64-bit there for Windows except a link to notes. Said notes are here: http://www.java.com/en/download/faq/java_win64bit.xml#Java%20for%2064-bit
Particularly relevant excerpt:
"Users should download 64-bit Java software, if they are running 64-bit
IE. For downloading 64-bit Java click 64-bit manual download"
The only off-line installer, as far as I can tell, has only installed the 32-bit runtime. Then we're back at square one! Am I missing something or going nuts?
Might this be the download you are looking for?
Go to the Java SE Downloads Page.
Scroll down a tad look for the main table with the header of "Java Platform, Standard Edition"
Click the JRE Download Button (JRE is the runtime component. JDK is the developer's kit).
Select the appropriate download (all platforms and 32/64 bit downloads are listed)
I believe the link below will always give you the latest version of the 64-bit JRE
http://javadl.sun.com/webapps/download/AutoDL?BundleId=43883
The trick is to visit the original page using the 64-bit version of Internet Explorer. The site will then offer you the appropriate download options.
Java7 update 45 64 bit direct download link is:
http://javadl.sun.com/webapps/download/AutoDL?BundleId=81821
You can also just search on sites like Tucows and CNET, they have it there too.
I have a 32-bit Windows/Qt application using Postgres plugin. Recently, I've been intrigued to turn the app into a 64-bit app. So I checked the Qt docs for instructions, built Qt and its libraries into 64-bit successfully. Now the problem is Postgres does not provide libraries for 64-bit Windows! Obviously, the Qt Postgres plugin won't compile. I googled around a lot and didn't find any solutions, just a whole bunch of non-helpful discussion archive postings. So, is there a way for me to compile my app as true 64-bit while using Postgres in Windows?
ADDENUM
The problem isn't running Postgres as true 64-bit on Windows (which cannot be done) (I'm not managing the database, so I don't care even), but to compile my Qt app as 64-bit (which very much gains from being true 64-bit). But since it needs to access Postgres DB, I can't do it, Qt Postgres plugin will not compile and I won't have DB access.
So, should I just separate Postgres related stuff to a 32-bit DLL (can I use 32-bit dlls with 64-bit app even?), or even to a separate executable, or can I use some other framework for accessing it...?
Give me any, even dirty, solution to this problem and state the pros and cons it may have and what else it might affect or break.
I'm about to get Vista 64 on my work machine so I was looking this up as well.
Basically - No, Postrgresql will not compile in Windows 64bit (yet), though it has worked for years in *nix 64bit.
I found this link - from one of the maintainers of the Windows installer.