Fallback to x64 directory if running x64 process on win-arm64 apphost #59890
Conversation
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
|
@ericstj could you please give this a shot? I did some validation but best I have now is x86 emulation on a win-arm64 machine, we should try the real thing (running x64 on a windows arm64 machine). |
No need unloading kernel32 dll Remove unnecessary variable Remove unnecessary else-if branch
|
Do you also plan to fix the mac side of this? It should also have different defaults when run translated. If you think about both together, would it make sense to make this part of the PAL? |
| } | ||
|
|
||
| // Check if we are running an x64 process on a non-x64 windows machine. | ||
| return pProcessMachine != pNativeMachine && pProcessMachine == IMAGE_FILE_MACHINE_AMD64; |
There was a problem hiding this comment.
One thing to be careful about is that pProcessMachine will be IMAGE_FILE_MACHINE_UNKNOWN if this process is not being run as WOW (eg: process = native = x64). That doesn't impact what this method returns, since it intends to communicate not native architecture but I can see that being a place of confusion in the future if this method was refactored. It be more future proof to just check pNativeMachine, this is what we do in the installer.
The reason being, that we've established that the dotnet folder is for the native architecture. Any future non-native architecture will get its own subfolder (if it isn't redirected by the OS).
Use sysctlbyname on macOS
|
@vitek-karas Anything else we need here? |
ghost
locked as resolved and limited conversation to collaborators
5 participants
Should fix #59473.