Adding Windows ARM Support

[tresf]

TODO:

• Update and test JNA 5.6.0 (Done via Update JNA #732)
• Update JNA to support Windows ARM64 (Enable building jna for Darwin arm64 java-native-access/jna#1238)
• Bump JNA to 5.8.0, with win32-aarch64 support (Done via Improve printer status by adding job status information #757, Initial support for M1 CPU #783)
• Update HID4Java to support Windows ARM64 (Add win32-aarch64 support gary-rowe/hid4java#93)
• Update JSSC to support Windows ARM64 (Windows ARM64 Support java-native/jssc#75)
• Update JavaFX to support Windows ARM64 (tracking privately SUPQZ-11)
  • Probably won't happen very soon, might track separately.

---

Emulation status:

Fortunately due to Microsoft's great x86 emulation, QZ Tray works out of the box with AdoptOpenJDK11 32-bit.

Edit: Windows 10 for ARM64 has experimental support for x86_64 emulation now too.

What does NOT work (32-bit)

• No 64-bit support, limiting Java's heap space
  • This also breaks any 64-bit bundling we may provide in the future
• No JavaFX available for 32-bit
• Windows firewall rules appear to be missing, prompts on first run (fixed via Fix 2.1 firewall rules #609)

What (surprisingly) does works:

• The installer and our JNA cert installation
• Calls to the registry for printer details (needs more testing to know for sure)

Related:

• Upstream aarch64 JVM feature: Promote AdoptOpenJDK Version -> Windows ARM64 AdoptOpenJDK/TSC#141
  • If added, this will require all JNA/JNI libs to be compiled for ARM64 as well.
• Windows 10X (dual-screen) support Windows 10X Support #610

[tresf]

FYI, we've sent two Raspberry Pi's equipped with hardware for running Windows 10 ARM to the AdoptOpenJDK team for their build infrastructure. I'm hoping to obtain Windows ARM binaries of AdoptOpenJDK11 soon for native testing.

[tresf]

FYI, pinged HID4Java: gary-rowe/hid4java#93

[tresf]

Microsoft has released a Windows ARM Java binary early access:
https://github.com/microsoft/openjdk-aarch64/releases

So far QZ Tray 2.1 won't load at all due to the heavy reliance on JNA for folders, registry settings and certificate installs. The calls to JNA will crash the JVM.

I assume a JNA arm64 compile is the path to fix this: https://github.com/java-native-access/jna/blob/master/www/WindowsDevelopmentEnvironment.md#native

Quoting:

MSVC / Visual Studio

JNA uses the free MS Visual Studio C++ Express compiler to compile native bits if MSVC is set in the environment. The MS compiler provides structured event handling (SEH), which allows JNA to trap native faults when run in protected mode.

On 64-bit windows, you will still need to install mingw64 in order to compile a small bit of inline assembly.

To use the MS compiler, ensure that the appropriate 32-bit or 64-bit versions of cl.exe/ml.exe/ml64.exe/link.exe are in your PATH and that the INCLUDE and LIB environment variables are set properly (as in VCVARS.BAT).

Sample configuration setting up INCLUDE/LIB (see an alternative below):

export MSVC="/c/Program Files (x86)/Microsoft Visual Studio 10.0/vc"
export WSDK="/c/Program Files (x86)/Microsoft SDKs/Windows/v7.0A"
export WSDK_64="/c/Program Files/Microsoft SDKs/Windows/v7.1"

export INCLUDE="$(cygpath -m "$MSVC")/include;$(cygpath -m "$WSDK")/include"
# for 64-bit target
export LIB="$(cygpath -m "$MSVC")/lib/amd64;$(cygpath -m "$WSDK_64")/lib/x64"
# for 32-bit target
export LIB="$(cygpath -m "$MSVC")/lib;$(cygpath -m "$WSDK")/lib"

Since this specifically mentions mingw, I have some reservations with arm support, asked here: https://groups.google.com/d/msg/jna-users/UxpFZP4g_ls/gS1JYewdAgAJ

[tresf]

A small amount of progress with JNA: https://groups.google.com/d/msg/jna-users/UxpFZP4g_ls/Ji_wMjcpAQAJ

The current sticking point is a JNA dependency called libffi, which does currently offer windows arm64 support, but the build system has many caveats:

• Requires cygwin, mostly because its make scripts call posix tools such as make, grep, etc.
• Uses a custom msvcc.bat to wrap calls to cl.exe, obfuscating the calls
• Seems to suffer some compiler issues in regards to assembly generation. These were purportedly to have been fixed, but I can't seem to get the build system to work with them.
• Does not account for Windows line endings, forcing odd stuff like find . -name \*.ac|xargs dos2unix

Fortunately, someone's written a CMake script to build libffi, so that might be the path of least resistance: libffi/libffi#535. I will try that next. CMake automatically handles compiler commands, line endings and a bunch of other nuances that are very painful when using make on Windows.

[tresf]

Windows ARM64 support for JNA is available here: java-native-access/jna#1264. We didn't use cmake, it was too difficult to chain into JNA's existing Makefile.

[tresf]

Partial support for Windows 10 ARM64 is available here: https://github.com/tresf/tray/releases/tag/v2.1.4-RC

What doesn't work:

• Serial support: See Windows ARM64 Support java-native/jssc#75 (comment)
• HTML Support: No upstream version of JavaFX available