-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix default install location used when running under x64 emulation on Windows arm64. #68671
Conversation
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue Details
This change makes us rely on our preprocessor define ( Another option is the use the I put up the version that just relies on the compile-time define, as that seemed like the simpler option. If we needed to query process other than the current one or needed some generic is_emulating_X_on_Y, we'd have to do the full query, but I don't think it is necessary right now. Addresses:
Validated manually running on Windows 11 ARM64 machine.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good solution. Thanks a lot!
My only regret is that we can't really automatically test this - unless we want to add a x64 on arm64 leg - which might be a good idea, but it's definitely outside the scope of this change.
Yeah, the non-existent automated testing is rough. Ignoring that we have to add host test runs on arm64 in general (which is definitely a good idea), x64 on arm64 would require updating to / running on win11 and downloading artifacts from a build for a different arch (plus whatever host test code and infrastructure itself). |
Honestly even though it's relatively complicated to setup x64 on arm64 testing, given our current woes with M1 machines in that setup (the entire dotnet-ef fiasco), it is probably worth it - but that would have to happen in the SDK/installer repo, since it's not just about host. |
Oh, yeah, I'd definitely agree it is worth it - especially (or at least) in an e2e situation like sdk/installer. |
IsWow64Process2
will returnIMAGE_FILE_MACHINE_UNKNOWN
as the process machine if the process is not a WoW64 process (x64 emulation is not, since it is 64-bit, not 32-bit running on 64-bit). The Windows implementation ofpal::is_emulator_x64
was checking that the process machine wasIMAGE_FILE_MACHINE_AMD64
, so it would always returnfalse
.This change makes us rely on our preprocessor define (
TARGET_AMD64
) to determine that the current process is x64 and then checks that the architecture of the host system (whichIsWow64Process2
will set regardless of whether the process is Wow64 or not) is notIMAGE_FILE_MACHINE_AMD64
. That is used as the indication that we are running (emulating) x64 on a non-x64 system.Another option is the use the
GetProcessInformation
API to determine the process info. I have an implementation of that in elinor-fung@32b9908.I put up the version that just relies on the compile-time define, as that seemed like the simpler option. If we needed to query process other than the current one or needed some generic is_emulating_X_on_Y, we'd have to do the full query, but I don't think it is necessary right now.
Addresses:
Validated manually running on Windows 11 ARM64 machine.