Runtime: Add Environment.Is32BitProcess

[elachlan]

Background and Motivation

There are lots of cases where a check like this is done IntPtr.Size == 4 to check for a 32bit process. It is possible to use !Environment.Is64BitProcess but this might not always be the case.

Proposed API

namespace Microsoft.Build.Shared
{
+    public static bool Is32BitProcess => IntPtr.Size == 4;

Usage Examples

It would replace code like this:
https://github.com/dotnet/runtime/blob/06731c2dba95f3000e274f5c0a47e24181e88928/src/coreclr/src/System.Private.CoreLib/src/System/GC.cs#L136

Risks

I believe the change is low risk.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Symbai]

It is possible to use !Environment.Is64BitProcess but this might not always be the case.

Why or in which case is !Environment.Is64BitProcess not possible? According to the source it only returns this public static bool Is64BitProcess => IntPtr.Size == 8; And your API would be in the same namespace and doing exactly the same but just compare against 4 instead of 8. So unless I am missing something your API only avoids typing an additional ! in the end, right?

[danmosemsft]

Maybe it's far fetched but perhaps one day we have 128 bit words? But code written today may be gone by then. I think the main value is ease of reading.

[elachlan]

!Environment.Is64bitProcess does not equate to intptr.size == 4. It's more explicit to have an is32bitProcess, or a property with an enum which lists 64bit or 32bit. It's more self documenting.

[Wraith2]

Maybe it's far fetched but perhaps one day we have 128 bit words? But code written today may be gone by then. I think the main value is ease of reading.

I'd like to think you're right but my work requires I deal with cobol and vb6 so I think pessimism may be a good idea here.

[stephentoub]

Maybe it's far fetched but perhaps one day we have 128 bit words?

I think it's very unlikely adding such a property will make code written using it any more future proof against such a hypothetical future. Instead of code like:
```C#
if (Environment.Is64BitProcess)
{
... // handle 64-bit
}
else
{
... // handle 32-bit
}

you'll just get code like:
```C#
if (Environment.Is32BitProcess)
{
    ... // handle 32-bit
}
else
{
    ... // handle 64-bit
}

[danmosemsft]

This is true. So the only value is readability. This seems marginal.

[elachlan]

Maybe we can update the xml documentation on the property so that its explicit that true is for a 64bit process and false is for a 32bit process?

[Clockwork-Muse]

I'd like to think you're right but my work requires I deal with cobol and vb6 so I think pessimism may be a good idea here.

I mean, the iSeries platforms have a nominal 128-bit address space, and have for decades. 16-byte pointers, due to "single level store".

[terrajobst]

Video

• We already have Is64BitProcess and Is64BitOperatingSystem. Given that we're extremely unlikely to support either 16bit or 128bit, how would this be different from negating those properties?

C# namespace System { public partial class Environment { public static bool Is32BitProcess { get; } // public static bool Is32BitOperatingSystem { get; } } }

[danmosemsft]

Fair enough.

[danmosemsft]

But I will return here 10 years from now when we work on 128bit support 😄