By default from ARM64 architecture projects, `WIN32` is not defined. It
is supposed to be for this proxy stub to work. So I've set it with the
preprocessor for this project.
## PR Checklist
* [x] Closes release build failure after #7489
* [x] I work here.
* [x] Built on my machine.
## Detailed Description of the Pull Request / Additional comments
`WIN32` appears to convey two meanings depending on who you are:
- To most of Windows, `WIN32` appears to mean the Win32 API surface and
sometimes the major OS version that goes with it. (Specifically in
contrast to 16-bit Windows.)
- To others, `WIN32` appears to mean a 32-bit processor or a synonym of
`x86`.
This is generally not a problem for a few reasons:
- VS defines `WIN32` in the default targets/props only for the `x86`
processor type. **BUT**
- Windows defines `WIN32` if it's not already defined in both
`minwinbase.h` and `ole2.h` which generally speaking manage to get
compiled into practically everything especially since `minwinbase.h`
tends to sneak itself in somehow through `windows.h` and that's
**THE** include to use the Windows API surface.
- Windows also defines `WIN32` for itself unconditionally and relatively
globally when building itself.
However, it's a problem here because:
- `rpcproxy.h` is the only header included in `dlldata.c`, a file
generated automatically by `midl.exe` in the SDK when making a proxy
stub.
- `rpcproxy.h` only defines its contents for a proxy when `WIN32` or
`_M_AMD64` are found.
- Therefore, it's defined pretty naturally for x86 and AMD64 targets
from VS, but not for ARM64.
- ARM64 support is pretty new and those who are attempting to build for
ARM64 and against the public SDK with Visual Studio for a classic COM
proxy... seems like a relatively unlikely combination.
I will follow up with the Visual Studio, Windows SDK, and MIDL/COM teams
to try to remove this pitfall from the public tooling. But for now, this
is the fix.
d6954244ad