VCPKG should have a variable to indicate if the HOST supports x64 native executables

[walbourn]

For a port that has to use a custom Windows EXE at build or install time, the only variable that's easy to check is VCPKG_HOST_IS_WINDOWS. In almost all cases (except Windows Server) this would indicate that a 32-bit Win32 EXE should run on the "HOST" including Windows on ARM64 which can emulate x86.

What is missing is a VCPKG_HOST_IS_WINDOWS_X64 which would indicate that the "HOST" is either a Windows x64 native machine -or- that it's a Windows 11 on ARM64 machine which can emulate x64. This is needed to validate that a 64-bit Win32 EXE will run on the "HOST".

[Neumann-A]

I don't think this is necessary. Instead it should be controlled by the host-triplet you are using.

[walbourn]

The host triplet can't indicate if it's Windows 10 on ARM64 that has x86 emulation, but not x64 emulation vs. Windows 11 on ARM64 that has both x86 and x64 emulation.

[Neumann-A]

The host triplet can't indicate

You select the host triplet. If you don't give the required information that is on you. Simply use --host-triplet=arm64-windows and don't care about emulation at all?

[walbourn]

I think you are mis-understanding the scenario...

The issue I'm concerned with is if I'm authoring a port that leverages a binary tool that is only provided as x64 native. It's not built by the port, and it's used for all target triplets.

For example, in the cppwinrt port I'm authoring, at the moment the cppwinrt.exe is an x86 binary that runs on all Windows platforms. However, it's quite reasonable that in future the provider of cppwinrt.exe might decide to only ship a x64 native version of their 'compiler'. In that case, I do NOT have a way to express that requirement in the port. If I require the x64-windows host triplet, that's fine, but it can also work on the arm64-windows host triplet but only if it's Windows 11 or later.

[autoantwort]

Can you not simply compile the project for arm64 and use the arm64 executable on arm64 computers.

[dg0yt]

... a port that leverages a binary tool that is only provided as x64 native. It's not built by the port, and it's used for all target triplets.

Focusing on that tool: AFAIU it cannot be built. It can be put to its own (tool) port, to be consumed via a host dependency. But this leads to #24993 (comment).

[Neumann-A]

For example, in the #24967 port I'm authoring, at the moment the cppwinrt.exe is an x86 binary that runs on all Windows platforms.

That means you have a tools feature with a supports expression which says x86 & x64 and have a host dependency on the port itself with that feature.

but it can also work on the arm64-windows host triplet

That is lying to vcpkg. arm64 means your binary is arm64

[walbourn]

In this case without the 'tools' feature, the port does nothing (i.e. the 'core' feature is a NOP). I don't believe treating it as a 'feature' works.

Again, scenario here is:

1. A developer toolset (basically a compiler) are often provided as an x64-native only binary because development environments for Windows are all x64 native. This includes Windows on ARM64 with Windows 11 thanks to x64 native emulation.

2. The port can generate headers that target x86, x64, arm, and arm64 platforms.

At the moment, I'm already relying on the idea that a x86 only binary will run on any WINDOWS host system.

[dg0yt]

What is missing is a VCPKG_HOST_IS_WINDOWS_X64 which would indicate that the "HOST" is either a Windows x64 native machine -or- that it's a Windows 11 on ARM64 machine which can emulate x64. This is needed to validate that a 64-bit Win32 EXE will run on the "HOST".

• Scalability: VCPKG_HOST_IS_WINDOWS_X64 is an approach which doesn't scale well IMO.
• Point of control: VCPKG_HOST_IS_WINDOWS_X64 would be used in the portfile.cmake. This is too late IMO. What would be needed is a way to express the requirement in the supports field of the port manifest.
  What is possible now is:

  "supports": "(windows & x64) | (windows & arm64)"

  But this doesn't reflect the requirement that it takes "a Windows 11 on ARM64 machine which can emulate x64".
  There is some room for customization with triplet files:

  These predefined identifier expressions can be overridden in the triplet file, via the VCPKG_DEP_INFO_OVERRIDE_VARS option, and new identifier expressions can be added via the same mechanism.

[walbourn]

Here's another concrete example of my concern here.

The DirectX 12 Shader Model 6 HLSL compiler is provided as a 'prebuilt' binary that is x64 native only. The primary usage of this binary is at build-time to produce shader blobs. These blobs can be used by programs that are written for Windows 10 or Windows 11 on any architecture.

THEREFORE, if I want to create a VCPKG port that provided access to the latest version of the compiler released and validated by the team, it would only support Windows x64 or Windows 11 on ARM64 as "HOSTS" but supports targeting any platform.

In practical terms, supports: "windows" and VCPKG_HOST_IS_WINDOWS gets me most of the way there since MOST development systems are Windows x64. However, I want to provide a better experience for those running legacy Windows x86 to get a clear message that the port won't run on their system -AND- I want to provide a clear message to Windows 10 on ARM64 systems that it requires x64 native (i.e. move to Windows 11). I'm looking for a mechanism to do this in a port.

I agree that IF the team were to provide x64 and arm64 native binaries, that would be a better scenario, but the team is not currently doing that since it potentially doubles their test cost -and- it's not easy to validate ARM64 since hardware access is much less than Windows x64.

[Neumann-A]

what you want is a mixed-arm64-x64-windows-host triplet where VCPKG_TARGET_ARCHITECTURE has a per port customization. That is how it should work but I don't know if vcpkg supports per port customization of VCPKG_TARGET_ARCHITECTURE.

[walbourn]

Actually, the DXC HLSL Compiler case above is probably better captured as a tool port as supports: "windows & x64 & native", but this won't work on Windows on ARM64. The good news is that the DXIL team is planning to ship arm64 binaries soon to then it would be: supports: "windows & (x64 | arm64) & native". Consumers would use host: true.

The cppwinrt case is still a challenge. At the moment it's an x86 binary so it works in most cases for development--technically it would fail on a Windows Server system without the WoW64 subsystem. It is generating headers for all architectures.