Can you please add an ARM64 build for those of us on the Surface Pro X?
1 Like
Don't they run the normal build?
The ARM CPU will run the x86 binary, but not perfectly, and at the expense of speed and battery life. For example, double-clicking on the desktop to open a default lister doesn't seem to work.
Up vote - I to have a Surface Pro X and would like to see a native ARM64 build of DOPUS.
1 Like
Hi Leo,
Also, if you try to do anything involving a file on the desktop on a Surface Pro X, it won't work. For example, double-clicking on a document on the desktop to launch the associated app just opens up a DOpus Lister, not the actual app. There's something very weird going on with file associations involving any file placed on the desktop.
Thanks,
Steve
Also, if you double-click on a folder on the desktop, it doesn't open the folder. DOpus just opens the default Lister. It's as if the double-click was just falling through to the desktop, so that rather than knowing that the user is trying to open a folder on the desktop, DOpus thinks that the user just double-clicked on the desktop, itself, to open a default lister. This isn't how things are supposed to work. This happens on the Surface Pro X. I don't know why DOpus behaves differently on it than on x86/x64 machines.
It's similar to when 64-bit was introduced, except a lot more niche and questionable in terms of if the platform has any future*. (* As in ARM Windows, not ARM generally, obviously. I'm typing this on an ARM phone and couldn't imagine using another CPU for those!)
It's a shame to us that Microsoft are selling ARM machines as a "pro" thing, which runs 32-bit code (or ARM builds no one makes), and without warning people that a third CPU architecture will break a lot of things without special builds.
Doing an ARM build would require a lot of extra work and complexity*, and we don't have the hardware to test on, given how expensive it is, and that we don't want it personally, which could offset that time and money cost. (*Six build targets instead of four, and Microsoft have still done nothing, this many years after 64-bit, to make Visual Studio support multiple build targets for developers who need everything rebuilt at once. Having to install potentially three versions of certain binaries, because in-process DLLs have to match the process that calls them. The installer itself would need to embed three builds of itself instead of two as well. Changing code so it knows which binaries to launch. And a lot of ongoing testing. So it's not just flipping a switch and rebuilding everything.)
It may happen if ARM Windows becomes popular in the future
(something that is very unclear today), but I believe Microsoft have mis-sold these as "Pro" devices without adequately warning customers of their limitations.
1 Like
Hi Leo,
Just checking in a year later. Has there been any change in the status or feasibility of an ARM64 build? Have the VS tools improved or is it still a nightmare trying to add a third variation of the build?
1 Like
Nothing much has changed regarding Windows on ARM, at least that I'm aware of.
Thank God that Directory Opus works well enough on the SPX as-is, in x86 translation. The only real problem is what I’ve described previously, with clicks on documents and folders in the desktop not opening those files or folders, only a default lister.
I’m running Windows 11 on my SPX, and in most ways, it’s less bad than Windows 10 (which isn’t a resounding endorsement 
). Microsoft needs to support ARM64 developers, but their efforts have fallen short.
I got the SPX because Intel CPU’s are so hot. They cause problems in Surface form factors, by damaging surrounding components (e.g. Flickergate, yellow spots on the screen, and swelling batteries). The SPX also looks great. But I would hesitate to recommend them to most people. They’re more like Microsoft’s science experiment than a production-ready device.
Still, I hope (against hope) that Microsoft will lurch forward, and that one day we’ll finally be able to ditch Intel for good. I sympathize with the difficulty of developing Windows ARM64 applications.
Just to let you know, in the 12.24.3 beta we've changed the installer to install the x64 bit version on ARM systems as an experiment (rather than the x86 version). Still no native ARM64 build though unfortunately.
What do you mean by that? There is a Build | Batch Build... option since vs2010, maybe even earlier...
Unless I'm missing something, Batch Build isn't really useful here as it seems to only remember one set of build targets which doesn't change when you change build types at the solution level (top level toolbar dropdowns).
At least, I can't see any way to, say, switch from a Debug to a Release build, without (in our case) manually toggling ~210 checkboxes (or 105 checkboxes after the Clear All button, but that's still rather a lot of clicking to change modes, and would require lots of thought about which things to turn back on).
No way to say "when I'm working on ARM, build docsvwarm.exe, docsvw64.exe and docsvw32.exe all from the same project; when I'm working on 64-bit, build docsvw64.exe and docsvw32.exe from the same project; when I'm working on 32-bit, build just docsvw32.exe".
So it couldn't replace the F7 hotkey for doing a normal Build. It seems more for ad-hoc tasks?
Ah, no, it cannot do anything that is not trivial...
Qualcomm’s Snapdragon X Elite, a 12-core Arm chip, has been making waves in terms of performance and efficiency. It's safe to say that the future of PCs will be (at least partially) ARM-based:
I got a Lenovo Yoga Slim 7x notebook and it's a great device and quite a lot of software is already native ARM64. To have a native ARM build of OPUS would be awesome. Fewer cycles consumed on a notebook, the etter.
BTW: With OPUS 13.x you seem to be on a roll! Great job! 
1 Like
I'm sorry, I have to disagree.
After all the hype about Qualcomm’s Snapdragon X, the actual market choice of devices turned out as a huge disappointment for me.
"Finally the MacBook Air killer with Windows" they shouted - what a fraud!
Apparently those folks have not understood what the essence of the Apple silicon MacBook Air is: a FANLESS machine!
Not a single Windows ARM device is actually offered which would even come close to the MacBook Air.
Still only noise generating devices (with a fan) or toy devices (with a tiny screen) are offered on the Windows ARM front.
Miserable!
I've got the MacBook Air M2 straight after the first 15 inch model came out last year, so that I can now support the JPEG library on macOS.
After all the Qualcomm/Nuvia hype I was looking forward to get a reference device for Windows on ARM platform development. Failure!
When you say "that the future of PCs will be (at least partially) ARM-based", then that future is actually still far away.
There is no reference device, and the market share is negligible. Even Apple's market share is huge by comparison.
So I see actually no reason for Windows on ARM platform support.
Though the current JPEG library is prepared as far as is possible by Visual Studio cross-compile for ARM.
Citation from file install.txt for the Visual Studio build in the JPEG source:
Note: test options for ARM code will be added as soon as Windows on ARM reference devices are available. To date there are no Windows on ARM reference devices available.
This was in January 2024, and the situation hasn't changed to date.
The compilation for ARM can already be done, but for execution of the code you need an ARM device.
Regards
Guido
JPEG developer
3 Likes