architecture of release binaries don't match architecture of file name

[jeremyd2019]

I was asked to open an issue here in msys2/MINGW-packages#23182 (comment).

In general, it seems all *.exe assets in a git-for-windows/git release are 32-bit x86. However, in certain cases (such as WinPE, or some server core installations IIRC) WoW64 support may not be present. In those cases, Git for Windows itself would work properly, but the installer/extractor would not run. I suggest that the installer/self-extractor should be the same architecture as the contained binaries, if possible, with the possible exception that arm64 could be x86_64 since the contained msys2 there is still x86_64, so x86_64 support on the host is required for proper functioning.

Workaround for PortableGit, in MSYS2:

#!/bin/bash

pacman --noconfirm --noprogressbar -S --needed mingw-w64-clang-aarch64-7zip

PORTABLEGITURL="https://github.com/git-for-windows/git/releases/download/v2.47.1.windows.2/PortableGit-2.47.1.2-arm64.7z.exe"
PORTABLEGITEXE="$(basename "${PORTABLEGITURL}")"
curl -LO "${PORTABLEGITURL}"
cp /clangarm64/lib/7zip/7zCon.sfx arm64portablegit.exe
tail -c+$(($(grep -m 1 -aob ';!@Install@!UTF-8!' "${PORTABLEGITEXE}" | cut -d: -f1)+1)) "${PORTABLEGITEXE}" >> arm64portablegit.exe
mv -f arm64portablegit.exe "${PORTABLEGITEXE}"

I noticed that this project uses a custom 7zip self-extractor, and a GUI one at that (rather than the console one the above replaces it with). I guess some people really need their GUIs (though I would have expected users of Git to not be scared off by a console window)

[rimrul]

Inno setup can only produce x86 installers, so getting the installer to be amd64 (or maybe even arm64) would require significant changes. But for the SFX component for Portable Git this seems pretty doable.

[dscho]

Inno setup can only produce x86 installers, so getting the installer to be amd64 (or maybe even arm64) would require significant changes.

Given that Delphi seems to target only Win32 and Win64 (according to this page, at least, that talks about "the 64-bit binary version of Delphi Win32 and Win64 compilers" that's not even available in community versions of Delphi), amd64 support may be possible, but arm64 support seems to be unattainable.

Also, given that Git just assumes (naively, one might say) that a POSIX shell is present everywhere, and given that we do not have a Windows/ARM64-native version of bash.exe, I am wondering how useful it would be to provide installers that are native Windows/ARM64 .exe files when what they install won't really work...

[jeremyd2019]

Also, given that Git just assumes (naively, one might say) that a POSIX shell is present everywhere, and given that we do not have a Windows/ARM64-native version of bash.exe, I am wondering how useful it would be to provide installers that are native Windows/ARM64 .exe files when what they install won't really work...

if possible, with the possible exception that arm64 could be x86_64 since the contained msys2 there is still x86_64, so x86_64 support on the host is required for proper functioning.

So it sounds like, for the installers, if possible is probably false, or at least overly difficult. The installers don't run on minwin anyway for some reason (I tried with ValidationOS, which does have wow64 support).

Maybe I should download an evaluation of server and do some testing with whatever core/nano configuration doesn't have wow64 support. (I saw some references to an arm64 variant of server 2025, but I can't find any way to actually download it, even from uupdump which shows updates for it but can't get enough files to construct an iso).