Add arm64 build

[kjk]

There is arm64 version of windows. Create a build variant for arm64.

[canny[bot]]

This issue has been linked to a Canny post: Add arm64 build :tada:

[Biswa96]

I have tried to build sumatrapdf for arm64. After some playing, two issues remain which are this project specific.

1. The fonts as resource addition need to be done without assembly.
2. libjpeg-turbo need to be updated for arm assembly.

[GitHubRulesOK]

Many lightweight credit card computer developers use basic text/PDF or PDFm image formats and use the resourceless base14 fonts of Helvetica, Times, Courier, that significantly helps with fast display, and print to serial IO. SumatraPDF is designed for windows (GDI) but windows w(h)ines very slowly in a pi.

[kjk]

@Biswa96

• The fonts as resource addition need to be done without assembly.

I believe nasm supports arm64 so it should be possible to use the same trick as for x86/amd64 ?

[Biswa96]

Nope, nasm is only for x86. https://en.wikipedia.org/wiki/Netwide_Assembler

[kjk]

You're right. Yasm then? (https://yasm.tortall.net/)

The build system (premake) is flexible enough to add custom compilers (that's how nasm is integrated).

Either yasm could replace nasm (if it's fully compatible) or be an addition just to compile the font.asm code for amd64

[wbsdty331]

Hello, Maybe we can try it? (update libjpeg-turbo and use yasm instead of nasm)

[kjk]

Started on arm 64 support.

Todo:

• [x] unrar, maybe upgrade to latest will fix it
• [x] openjpeg - missing popcount for arm
• [x] crash handler
• [x] fonts
• [x] dav1d
• [x] libjpeg-turbo
• [x] make arm64 builds available

[GitHubRulesOK]

This issue has been linked to a Canny post: Add arm64 build 🎉

In Progress or Complete :-)

[kjk]

It compiles, no idea if it works.

[GitHubRulesOK]

Hmm, thats interesting what might run it Raspberry 🥧 Pi? (Mine are Linux) can only find Blackberry 🍓 Strawberry or Xbox ☒

Tiny11 for Arm64 aims to make the base installer smaller and leaner, which is ideal for the Raspberry Pi’s hardware. Tiny11 has caused quite a stir in recent days. It offers a lighter Windows 11 installation, ideal for older, less powerful machines. The recent release of Tiny11 for Arm64 saw support for Windows 11. Our initial investigation used a micro SD card as the boot device, a mistake

[qwinsi]

Just want to add: I have a Windows11 ARM machine. I built it on my machine at commit https://github.com/sumatrapdfreader/sumatrapdf/commit/5d9fc739584aaae8f6318f8e4ddec283ba76691f successfully. (configuration = Release ARM64) Here's the VS2022 output:

========== Build: 24 succeeded, 2 failed, 0 up-to-date, 0 skipped ========== ========== Elapsed 06:33.117 ==========

The ARM64 binary executable works fine.

[kjk]

Thanks for the info @qwinsi Now I need to make the builds available on the website.

[kjk]

ARM 64 builds are now available via https://www.sumatrapdfreader.org/prerelease

The downside is that pre-release builds will now be updated once a day, not on every checkin.

[Biswa96]

Thank you for working on this.

Just wondering. Is the TODO in DbgHelpDyn.cpp required for normal usage? I have the diff from my previous attempt (https://github.com/sumatrapdfreader/sumatrapdf/issues/2566#issuecomment-1157818183). I can try to add those.

[kjk]

@Biswa96 any improvement (in form of PR) is appreciated

GetExceptionInfo() is not required but it does help in case of a crash.

Also, libjpeg-turbo and dav1d are compiled without arm assembly, making them slower on arm.

Not sure how to compile arm assembly with msvc toolchain - this would require reverse engineering of how dav1d is building for windows. It's ok to add a .exe of a tool, like I do for nasm.exe in bin\ directory for compiling x86 assembly.

libjpeg-turbo could use an upgrade to latest released version, which has arm assembly, I believe.

I don't have an arm device for testing which limits my ability to work on such issues.

[Biswa96]

Understood. I'll explore it.

GetExceptionInfo() is not required but it does help in case of a crash.

Is there any way to create a crash and see the output?

[kjk]

run with -crash-on-open cmd-line arg. this will trigger a crash when opening a file.

I will also add a command to Command Palette (Ctrl + K) to trigger a crash and a memory corruption, for testing

To see logs as they happen: go run .\tools\logview\

This is a helper program that shows all the logf() and logfa() Sumatra logs as they happen. Helpful for monitoring what happens when not running under a debugger.

Note: testing crash handler is better outside of the debugger as the debugger gets the first dibs at handling exceptions. I'm not sure I figured out how to tell Visual Studio debugger to keep going so that my exception handler (crash handling code) is executed.

[kjk]

Actually, crash me command was already there just not showing unless a document was opened.

I've added the corrupt memory command.

You can also run logview via .\doit.bat -logview.

On the downside, the logging from crash reporting doesn't show in logview. Need to look into that.

[kjk]

I fixed logview logging from crash reporting as well