I have created a 64-bit Windows application, and would like to include an Application Manifest.
I have compared several DLLs of other vendors, e.g. shell32.dll , and saw that they set the value "x86" as processorArchitecture; example:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
name="...."
processorArchitecture="x86"
version="...."
type="win32"/>
<description>....</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
My questions:
Is it really OK that a 64 bit application gets a manifest with processorArchitecture="x86" ?
Microsoft describes processorArchitecture as follows:
Specifies the processor. The valid values are x86 for 32-bit Windows and ia64 for 64-bit Windows. Optional.
This is very confusing to me. Why isn't amd64 / x86-64 listed? I have a 64-bit Windows, but I do not have an Intel Itanium architecture.
Edit July 2021: Microsoft has updated the description. The new description is: "Specifies the processor. Valid values include x86, amd64, arm and arm64. Optional."
Is it OK that, according to the manifest, my 64-bit applicaton depends on "Microsoft.Windows.Common-Controls" with processorArchitecture="x86" ? If my application "uses" a DLL like comctl32.dll for displaying controls, I assume it must be the same architecture, as 64bit cannot bind 32bit without a thunk.
Edit: It turns out that I made a mistake: I had looked at the DLL using the tool "Resource Hacker", which is a 32 bit app, and so I saw the 32-bit DLL through SysWOW64 while assuming it is the 64bit DLL. The real 64bit DLL contains processorArchitecture="amd64", as expected.