Update to 10.0.26100.1 SDK

[mikebattista]

          The new SDK didn't help with the exports and also the Hypervisor headers were changed to add AMD64 conditionals which requires some changes. It's confusing the cross-arch build of the partition and needs to be investigated.

Originally posted by @mikebattista in https://github.com/microsoft/win32metadata/issues/1928#issuecomment-2179524422

[riverar]

@mikebattista Did you want a hand with this one or is this a placeholder for your PR?

[mikebattista]

If you could take a look, that would be great. Here are the steps to follow to get to where I left off:

• Run scripts\UpdateSDK.ps1 10.0.26100.1.

• Fix the few reported libMappings.rsp errors related to multiple mappings by removing the alternative mappings

• The bottom of libMappings.rsp should have a hunk of removals as those are manual additions. Add them back by reverting the removal hunk in the git diff

• Remove "Hypervisor" from the below line given the changes to the Hypervisor headers in the latest SDK. You'll get a different error about a Hypervisor-related CloseApi not being found if you don't do this so things are broken either way https://github.com/microsoft/win32metadata/blob/948286f7c03b488f8665009224ad43898b950a7a/generation/WinSDK/Windows.Win32.proj#L51

• Run a clean build

You'll run into unresolved reference errors in the Hypervisor APIs. It looks like the referenced types are getting scraped during the arm64 and x64 passes which is expected given how the headers changed. The errors are reported in the Hypervisor.modified files which are generated by the crossarch part of the build.

[riverar]

@mikebattista Hm, think there's something going on with the crossarch tree merging and maybe some bad assumptions about enumerations always existing in x86. Just my early thinking so far.

[riverar]

@mikebattista WIP if you want to take a peek: https://github.com/microsoft/win32metadata/pull/1934

Some changes:

• Restored any headers, mappings, etc. that would lead to breakage downstream (e.g. left obsolete AllJoyn, P2P, etc. headers in)
• Added enum support to cross-arch tree merger + tests
• Dropped enums ISC_REQ_FLAGS, ASC_REQ_FLAGS, DNS_QUERY_OPTIONS due to mixed constant sizes/types (we should address this prior to update)
  • Related issue: #1933
• Updated NTDDI_VERSION for IDL passes

Am investigating some enum test failures now.

[mikebattista]

@mikebattista Hm, think there's something going on with the crossarch tree merging and maybe some bad assumptions about enumerations always existing in x86. Just my early thinking so far.

Based on your changes, looks like you were exactly right about this. Looking good.

[riverar]

@mikebattista Current blocker is that the Hyper-V platform reuses enum names across architectures, such as:

#if defined(_AMD64_)
typedef enum WHV_RUN_VP_EXIT_REASON
{
    WHvRunVpExitReasonNone                   = 0x00000000,
    WHvRunVpExitReasonMemoryAccess           = 0x00000001,
    // ...
}
#elif defined(_ARM64_)
typedef enum WHV_RUN_VP_EXIT_REASON
{
    WHvRunVpExitReasonNone                   = 0x00000000,
    WHvRunVpExitReasonUnmappedGpa            = 0x80000000,
    // ...
}

If we create architecture-specific types (e.g. WHV_xxx_AMD64 and WHV_xxx_ARM64), we then need to propagate that to any references (e.g. methods), which I don't think we support today. Attempting to merge any duplicate bitflag enums could work for the above example...

But then we'll run into the same problem with structures such as:

typedef union WHV_CAPABILITY_FEATURES
{
    struct
    {
        UINT64 PartialUnmap : 1;
#if defined(_AMD64_)
        UINT64 LocalApicEmulation : 1;
        UINT64 Xsave : 1;
#else
        UINT64 ReservedArm0 : 2;
#endif
        UINT64 DirtyPageTracking : 1;
        UINT64 SpeculationControl : 1;
#if defined(_AMD64_)
        UINT64 ApicRemoteRead : 1;
#else
        UINT64 ReservedArm1 : 1;
#endif
        UINT64 IdleSuspend : 1;
        UINT64 VirtualPciDeviceSupport : 1;
        UINT64 IommuSupport : 1;
        UINT64 VpHotAddRemove : 1;
        UINT64 Reserved : 54;
    };

    UINT64 AsUINT64;
} WHV_CAPABILITY_FEATURES;

I believe a similar architecture-specific references change is needed to fix CONTEXT (#1044) and others too.

[mikebattista]

Related to https://github.com/microsoft/wdkmetadata/issues/23 as well.