OS: Windows 10, 64 bit operating system, ARM based processor
Memory: 16GB
Java version 8 Update 301 (build 1.8.0_301-b09)
VASSAL: 3.5.3 and 3.5.8
Module: Main VASSAL engine
I have been running VASSAL 3.5.3 but also 3.2.17.
Why? I recall having problems with some modules in 3.5.3 (notably BCS-Last Blitzkrieg v4.10).
But that is not what has prompted this post.
Today I decided to download the current VASSAL engine which is 3.5.8 (64-bit version). It have me the following error message:
VASSAL
An error occurred while starting the application.
This version of %1 is not compatible with the version of Windows you’re running. Check your computer’s system information and then contact the software publisher.
OK
So I uninstalled 3.5.8 and then tried to re-install 3.5.3 (which had been working but which the install of 3.5.8 had uninstalled).
I get the same error message now in 3.5.3.
Is this an ARM processor thing?
What can I do to get a recent version of VASSAL going on my machine? 3.2.17 is still running okay, but the 3.5.x versions are getting the same error.
From 3.3.0, we started bundling Java with our Windows installer. The bundled Java is for a particular architecture—either x86 or x86_64, depending on whether you’ve downloaded the 32- or 64-bit version—and won’t run on ARM, so far as I know. It should be possible to install the generic bundle and run that with an independent Java installation (but not the Java 8 you mention that you have in stalled—you can’t run 3.5 with anything before Java 11).
You say you were running 3.5.3. Do you have any idea how? Did you install one of the Windows builds? If so, which one? If not, what did you install?
I have been playing around with things to see what I can and can’t do.
In 3.5.3 and earlier, I can install the 32-bit Windows version. During setup it gives me the following message, but allows me to install (and it runs successfully).
In 3.5.4 and later, I can’t install the 32-bit Windows version at all. During setup it gives me the following message (and won’t allow the installation to proceed).
The error message I quote in my original message comes up when I try to install the 64-bit package, so I can’t get that to work at all (which sounds like it might be because of the Java 11 issue you mentioned).
But it seems as though something must have changed in the installer from 3.5.3 to 3.5.4, because that seems to be the break point between allowing me the option to install the 32-bit package (which works) (as per the first message above) and not allowing me to do so (as per the second message above).
If the installer for the newer versions allowed me to install the 32-bit package it seems likely they would work.
Is there a way to get Java 11? I have run the Java updater and it gives me the Java 8 version I mentioned in my original post.
Thanks for explaining fully your situation. I couldn’t see how you’d have been able to run the 32-bit installer or what it installed, as neither would have been the correct architecture for you—so I poked around a bit and learned something:
Windows 10 on 64-bit ARM processors can run 32-bit x86 applications via an emulation layer. Wow. I had no idea that had happened. (Apparently emulation for 64-bit x86 applications is in the works, but isn’t released yet.)
The explanation for why 3.5.4 and later haven’t worked for you is this: In 3.5.4 we switched from advising users to use the 64-bit bundle on 64-bit Windows to mandating it. The installer checks whether it’s on a 32- or 64-bit architecture—but doesn’t check that it’s on an x86 architecture, because it never occurred to use that anyone would be able to run the installer on any other architecture. So for you, when you try to install the 32-bit bundle, which would otherwise work for you, the installer sees that you’re on a 64-bit system and refuses to go ahead. (The reason you’re able to run the installer at all is that the installer itself is 32-bit, even for the 64-bit bundle.)
So, this is going to require some investigation about what to do. I’m not sure if the program that creates the installer (NSIS) gives us any facility for checking if we’re running on an x86 or ARM CPU.
Unless you’re using Java 8 for something else, I’d uninstall it. So far as I know, it’s updater won’t look for anything beyond updates of Java 8.
There are a few different things you could do. We bundle Java builds from AdoptOpenJDK (azul.com/downloads/?os=wind … ackage=jdk) which I hadn’t know existed until just now. In either case, you would need to install the “other” bundle of VASSAL rather than either of the Windows ones.
That seemed odd because my system is ARM 64-bit Windows. I double checked my system specifications, which are copied and pasted below (with some redactions):
The installer seems to be wrongly identifying the system as being 64-bit x86.
An idea
It occurred to me that the existing installers could take advantage of the 32-bit x86 emulation layer which the ARM system uses by returning to recommending (rather than mandating) installation of the 64-bit package on 64-bit machines.
At the point of download, ARM users could be directed to download and install the Windows 32-bit package and use it on their 64-bit ARM machines (and the text of the recommendation that pops up in the dialogue box when installing the 32-bit package could reinforce that message).
But that may have its own challenges (which I don’t have the technical knowledge to comprehend), or it may just be a downright bad idea.
I am content using 3.5.3, and it may be that this issue ultimately gets addressed externally if a 64-bit x86 emulation layer finds its way into the world of ARM devices.
Thank you for exploring all of this. When I bought my ARM machine I had no idea that it would face so many compatibility challenges.
Installation worked without a hitch. No warnings or recommendations along the way.
I also used the VASSAL version you sent me to open each of the game modules I am currently using to test it further. It successfully opened all of the modules and ran logs from all of them.
The explanation for the previous problem is that the
RunningX64
check in the installer looks like it should check for the system being 64-bit x86, but actually it checks for just whether the system is 64-bit—and thus it incorrectly caught 64-bit ARM in a case that was for 64-bit x86 only. (The NSIS documentation is not clear on this point.)
Expect there to be an ARM 64-bit package released with 3.6.0-beta1 and all releases thereafter.
