Add an architecture property to Process class

[Dewera]

It would be nice to have a property as part of the Process class that specified whether the process running was a 32 or 64 bit process.

[jkotas]

Process architecture seems to be very Windows-specific concept. Is there such a thing on non-Windows systems?

[Dewera]

Can't say I know a lot about OS internals regarding non Windows systems, but I believe it is possible to run 32 bit applications on both 64 bit Linux and macOS.

[Gnbrkm41]

Apple has marked 32bit apps as "outdated" and has prompted the developers to update for a while, and finally dropped support entirely in the recent update:

Starting with macOS Catalina, 32-bit apps are no longer compatible with macOS.

I wonder why one would need this? Some scenarios and use cases would be nice to have in an API proposal.

[Gnbrkm41]

FWIW: System.Runtime.InteropServices.Architecture enumeration

[Dewera]

Maybe it is more of a Windows thing then. I'm not a huge user of systems outside of Windows, however, seeing as Windows still holds a very large market share, it could be useful.

In regards to use cases, it is often very useful to know whether a remote process is running under WOW64 or x64. This can obviously be accomplished by making a call to IsWow64Process, however, seeing as though this PInvoke call is already used internally in the Process class, would it not make sense to just expose the result as a property?

[danmoseley]

@tmds, thoughts? Are there ways to run a 32 bit app on a 64 bit Linux?

[gfoidl]

Are there ways to run a 32 bit app on a 64 bit Linux?

Yes it's possible. E.g. see https://askubuntu.com/a/454254

[jkotas]

You can even run ARM Code on X86 Linux.

My question is more about whether it is possible to reliably tell from outside of the process whether it is running one of these emulated environments.

[tmds]

I'm not sure we need such a specific info on Process. The use-case mentioned involves Windows WOW64 or x64. @Dewera can you elaborate what you want to do want do to with this info?

If I'd want to get such info on Linux, I'd look at the process filename, and then read the ELF header architecture.

[Dewera]

If we're discussing Windows usage then debugging remote processes is a large usage case. Examples would include interacting with threads (different context structure / function calls require you to differentiate between WOW64 / x64,) reading / interacting with pointer values in memory etc

Whilst I'm not as familiar with OS internals on Linux platforms, I'm sure the above applies to them as well.

I believe this addition would be well received by the many people out there using .Net to write debugging tools, particularity with the recent additions of lower level API's that make the development of these tools much more easier.

[jkotas]

debugging remote processes is a large usage case

I won't disagree with that, but it does not make sense to have a full featured remote process debugger API to be part of the core framework. It should be a separate NuGet package.

[Dewera]

I won't disagree with that, but it does not make sense to have a full featured remote process debugger API to be part of the core framework. It should be a separate NuGet package.

I do agree that it makes sense to have a separate package for a full featured remote process debugging API, but, I don't believe process architecture will be used just for this purpose and could be utilized in various other circumstances. On top of this, it requires a relatively small amount of code to generate the result for this property, and on Windows, an API call to IsWow64Process is already being used internally here

[danmoseley]

I think we would want to make sure we could usefully implement this for Unix, if we add it (maybe "look at the process filename, and then read the ELF header architecture." is well defined and reasonable). There is some Windows specific API in the core libraries for historical reasons: we do not want any more. There was a similar discussion recently on https://github.com/dotnet/corefx/issues/306.

[tmds]

imo use-cases are too specific to put this on Process class. Probably an application that cares to know this is going to do more specific stuff that isn't provided by corefx.