Windows GUI: Build for ARM64 PC

[cjee21]

Depends on:

• Add ARM64X build for MSVC2022 MediaInfoLib#2161

Note:

• If there is any condition where InfoTip needs libcurl then we need an ARM64X version of libcurl. If not, it should work as it is or we can use an ARM64EC version of libcurl for native code.
• The ARM64 is not added to all-in-one installer. It should be either added or there should be a way to direct ARM64 users to the correct installer or else they will have broken shell integration. Maybe time for an online stub installer?
  • Windows i386 -> i386 installer
  • Windows x64 -> x64 installer
  • Windows 10 ARM64 -> i386 installer
  • Windows 11 ARM64 -> ARM64 installer
  • Other Windows -> unsupported

[JeromeMartinez]

Thank you for your work, we'll launch a build soon.

If there is any condition where InfoTip needs libcurl then we need an ARM64X version of libcurl.

No, InfoTip is only for local files.
But at some point we may want to let the user enter a URL in the GUI (feature requested by several users) so we'll need to add libcurl to the DLL called by the GUI, we'll do it.

Windows 10 ARM64 -> i386 installer

why not the at x64 installer?
And @rednoah, could you say which binaries (i386 or x64) are installed currently on ARM64 machines? Does the x64 ZIP usable? (it is i386)

It is sad but IMO it is acceptable not to support Windows 10 ARM64 as it may be a very small count of users.
Or... Wouldn't it make sense to add a pur ARM64 version of the shell extension (not the tooltip which requires the DLL in full) in the i386 or x64 installer so Windows 10 ARM users would have a "slow" GUI+DLL but still a shell extension, with a small extra size of the installer?
See below.

Other Windows -> unsupported

Default would be to install the x64 version, great chances that there is some compatibility (at least for the GUI; for the explorer integration it seems not).

Maybe time for an online stub installer?

The extra size for the dual i386 / x64 had no complain (times change, it is relatively small enough now for not being remarked), I think I would like to keep it as is for the moment as the main file downloaded but we could work on the stub installer so it is ready when we decide to switch (I may accept at some point :-p), would you mind to do that?

Headaches with all the different cases of ARM64 / EC / X and GUI not supporting ARM64 and Windows 10 not supporting ARM64EC...
I see the following steps:

• @rednoah tests the next build (to be indicated when ready) of the ARM64 installer (if I understand correctly it is only for Windows 11, actually) and confirms that the shell extension (and the Tooltip?) are available and that the GUI is launched.

• a check that it is not Windows 10 (and leave if it is) should be added to the ARM64 installer, shouldn't it?

• hybrid stub: in the "Windows" (i386 & x64) installer, we add another check on arch & Windows version, if ARM64 and not Windows 10, download and launch the ARM64 installer.

• full stub, extra "Windows_Stub" installer we have a check on arch & Windows version, if Windows 10 ARM64, it is i386 installer, else if ARM64 it is ARM64 installer, else if x64 download it is the x64 installer, else download the i386 installer (the default if any other arch).

• support of Shell extension (Tooltip not supported) in Windows 10 ARM64 while keeping GUI & DLL x64 i386:
  In the "Windows" (i386 & x64) installer, we add a test on ARM64 (without Windows version) and install the ARM64X sparse package & package helper & shell extension DLLs, and @rednoah can test it (he has Windows 11 but he can test this build and say if the Shell extension is present and if he still can launch the GUI). (too low market share)

Is it too complicated and/or is there a better method?

[cjee21]

why not the at x64 installer?

Windows 10 does not have x64 emulation on ARM64. It is Windows 11 exclusive.

One of the reasons Windows on ARM has failed before but is now starting to gain market share.

[JeromeMartinez]

Windows 10 does not have x64 emulation on ARM64. It is Windows 11 exclusive.

Ouch.
OK, so x64 replaced by i386 in my proposal.

[cjee21]

a check that it is not Windows 10 (and leave if it is) should be added to the ARM64 installer, shouldn't it?

ARM64 installer checks for ARM64 and Windows 11 oninit and aborts if any condition not met. Should be good enough?

https://github.com/cjee21/MediaInfo/blob/033545d35b196d92e8ac9686b76f9850dd7ffd1d/Source/Install/MediaInfo_GUI_Windows_ARM64.nsi#L123-L132

[JeromeMartinez]

ARM64 installer checks for ARM64 and Windows 11 oninit and aborts if any condition not met. Should be good enough?

It is! I missed it, thanks for having done it before I ask.

[JeromeMartinez]

I edited my proposal.
Windows 10 ARM64 shell extension support is not a big need IMO, @cjee21 only if you are super motivated to do it...

[cjee21]

I edited my proposal. Windows 10 ARM64 shell extension support is not a big need IMO, @cjee21 only if you are super motivated to do it...

Very low market share. Probably extinct soon. So nah... :p

EDIT: running 32-bit means we also have to deal with file and registry redirections probably.

Or we can get the Qt x64 and ARM64 to build and post it to the Store replacing the current very outdated UWP version (I got 2022 version from store?) and it will serve Windows 10 ARM64 as well as users who can only install apps from Store. Qt one is now quite close to VCL in features compared to UWP/wx. It is also probably easier to put Qt one in Store as it does not attempt to write registry entries for shell extensions.

[JeromeMartinez]

Very low market share. Probably extinct soon. So nah... :p

OK, so let's keep with the i386 offer in the case of Windows 10 ARM64 and we don't really care.

Or we can get the Qt x64

Another topic but for the moment I am more in the mood of keeping VCL. It may change, I still need to think about it. But most of the remaining work does not depend on that, so you can go with it whatever is my future choice.

[JeromeMartinez]

Very low market share. Probably extinct soon. So nah... :p

I edited again my proposal and now it is relatively small amount of remaining work, @cjee21 would you mind to manage that?

[cjee21]

The Qt x64 one is more or less ready for the Store. The fully native Qt ARM64 one needs an ARM64 build of Qt WebEngine and Graph/FFmpeg plugins which is not something I can do. That's all for Qt.

I edited again my proposal and now it is relatively small amount of remaining work, @cjee21 would you mind to manage that?

Remains the stub installer right? I am not sure if I can manage to do that. Firstly, it requires knowing the URLs of the installers. Second, I just started doing NSIS this year and have no idea how to make a downloader yet. 😅

[JeromeMartinez]

Firstly, it requires knowing the URLs of the installers. Second, I just started doing NSIS this year and have no idea how to make a downloader yet. 😅

Not difficult but fair, you already did a lot, we'll check.

[cjee21]

But at some point we may want to let the user enter a URL in the GUI (feature requested by several users) so we'll need to add libcurl to the DLL called by the GUI, we'll do it.

@JeromeMartinez I pasted a url in the "File name" field of Windows File open dialog and it loads in MediaInfo 😆

[JeromeMartinez]

I pasted a url in the "File name" field of Windows File open dialog and it loads in MediaInfo 😆

😆
It is hidden for the moment, people usually don't try that and ask for a more obvious interface.
Anyway, WIN64X version of libcurl is in the pipe.

[cjee21]

It is hidden for the moment, people usually don't try that and ask for a more obvious interface.

Tried on Qt one and it appears to work but since Qt one produces blank output when passing urls in command line, it also produces blank using the file open dialog.

[cjee21]

@JeromeMartinez I tried making a full stub installer and it appears to work.

[JeromeMartinez]

I tried making a full stub installer and it appears to work.

Go, PR :).
The hybrid stub version should be even easier.

[cjee21]

Checked https://mediaarea.net/download/snapshots/binary/mediainfo-gui/20241205-2/MediaInfo_GUI_24.11.20241205_Windows_ARM64.exe

Looks okay other than MediaInfo_WindowsShellExtension.dll not digitally signed.

@g-maxime
..\..\%MI_SOURCES%\MediaInfo\Project\MSVC2022\ARM64\Release\MediaInfo_WindowsShellExtension.dll

[cjee21]

@JeromeMartinez So left the testing of ARM64 installer and after that if it is working fine, dealing with the combined installer and making a version-less stub.

[JeromeMartinez]

@rednoah please test this ARM build, especially the Windows Explorer integration (shell extension and tooltip).

[cjee21]

@rednoah please test this ARM build, especially the Windows Explorer integration (shell extension and tooltip).

Link no longer exists. Try this one: MediaInfo_GUI_24.11.20241205_Windows_ARM64.exe

[rednoah]

Nice work! I can confirm that it works on my arm64 machine, both tooltip and context menu.