Asked  6 Months ago    Answers:  5   Viewed   84 times

In a .NET 2.0 C# application I use the following code to detect the operating system platform:

string os_platform = System.Environment.OSVersion.Platform.ToString();

This returns "Win32NT". The problem is that it returns "Win32NT" even when running on Windows Vista 64-bit.

Is there any other method to know the correct platform (32 or 64 bit)?

Note that it should also detect 64 bit when run as a 32 bit application on Windows 64 bit.

 Answers

96

UPDATE: As Joel Coehoorn and others suggest, starting at .NET Framework 4.0, you can just check Environment.Is64BitOperatingSystem.


IntPtr.Size won't return the correct value if running in 32-bit .NET Framework 2.0 on 64-bit Windows (it would return 32-bit).

As Microsoft's Raymond Chen describes, you have to first check if running in a 64-bit process (I think in .NET you can do so by checking IntPtr.Size), and if you are running in a 32-bit process, you still have to call the Win API function IsWow64Process. If this returns true, you are running in a 32-bit process on 64-bit Windows.

Microsoft's Raymond Chen: How to detect programmatically whether you are running on 64-bit Windows

My solution:

static bool is64BitProcess = (IntPtr.Size == 8);
static bool is64BitOperatingSystem = is64BitProcess || InternalCheckIsWow64();

[DllImport("kernel32.dll", SetLastError = true, CallingConvention = CallingConvention.Winapi)]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool IsWow64Process(
    [In] IntPtr hProcess,
    [Out] out bool wow64Process
);

public static bool InternalCheckIsWow64()
{
    if ((Environment.OSVersion.Version.Major == 5 && Environment.OSVersion.Version.Minor >= 1) ||
        Environment.OSVersion.Version.Major >= 6)
    {
        using (Process p = Process.GetCurrentProcess())
        {
            bool retVal;
            if (!IsWow64Process(p.Handle, out retVal))
            {
                return false;
            }
            return retVal;
        }
    }
    else
    {
        return false;
    }
}
Tuesday, June 1, 2021
 
Andres
answered 6 Months ago
76

I ran into this issue not long ago. The short answer is that if you run a 32 bit application on a 64 bit machine then it's registry keys are located under a Wow6432Node.

For example, let's say you have an application that stores its registry information under:

HKEY_LOCAL_MACHINESOFTWARECompanyX

If you compile your application as a 64 bit binary and run it on a 64 bit machine then the registry keys are in the location above. However, if you compile your application as a 32 bit binary and run it on a 64 bit machine then your registry information is now located here:

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCompanyX

This means that if you run both the 32 bit and 64 bit versions of your application on the same machine then they will each be looking at a different set of registry keys.

Wednesday, June 9, 2021
 
Powering
answered 6 Months ago
11

There are several ways - also used by CMake itself - that will check for "not 64Bit":

if(NOT "${CMAKE_GENERATOR}" MATCHES "(Win64|IA64)")
    ...
endif()

if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "4")
    ...
endif()

if(NOT CMAKE_CL_64)
   ...
endif()

References

  • CMAKE_GENERATOR
  • CMAKE_SIZEOF_VOID_P
  • CMAKE_CL_64
Thursday, July 29, 2021
 
Wilk
answered 4 Months ago
19

Because you called your procedure 'fillArray', I assumed you like to fill a whole memory block with a byte value. So I did a comparision on different approaches. It is 32 bit masm code, but the results should be similar in 64 bit mode. Each approach is tested with both aligned and unaligned buffers. Here are the results:

Simple REP STOSB - aligned....: 192
Simple REP STOSB - not aligned: 192
Simple REP STOSD - aligned....: 191
Simple REP STOSD - not aligned: 222
Simple while loop - aligned....: 267
Simple while loop - not aligned: 261
Simple while loop with different addressing - aligned....: 271
Simple while loop with different addressing - not aligned: 262
Loop with 16-byte SSE write - aligned....: 192
Loop with 16-byte SSE write - not aligned: 205
Loop with 16-byte SSE write non-temporal hint - aligned....: 126 (EDIT)

The most naive variant using the following code seems to perform best in both scenarios and has the smallest code size as well:

cld
mov al, 44h   ; byte value
mov edi, lpDst
mov ecx, 256000*4  ; buf size
rep stosb

EDIT: It's not the fastest for aligned data. Added MOVNTDQ version which performs best, see below.

For the sake of completeness, here are excerpts from the other routines - the value is assumed to be expanded into EAX before:

Rep Stosd:

mov edi, lpDst
mov ecx, 256000
rep stosd

Simple While:

mov edi, lpDst
mov ecx, 256000
.while ecx>0
    mov [edi],eax
    add edi,4
    dec ecx
.endw

Different simple while:

mov edi, lpDst
xor ecx, ecx
.while ecx<256000 
    mov [edi+ecx*4],eax
    inc ecx
.endw

SSE(both):

movd xmm0,eax
punpckldq xmm0,xmm0    ; xxxxxxxxGGGGHHHH -> xxxxxxxxHHHHHHHH
punpcklqdq xmm0,xmm0   ; xxxxxxxxHHHHHHHH -> HHHHHHHHHHHHHHHH
mov ecx, 256000/4   ; 16 byte
mov edi, lpDst
.while ecx>0 
    movdqa xmmword ptr [edi],xmm0    ; movdqu for unaligned
    add edi,16
    dec ecx
.endw

SSE(NT,aligned,EDIT):

movd xmm0,eax
punpckldq xmm0,xmm0    ; xxxxxxxxGGGGHHHH -> xxxxxxxxHHHHHHHH
punpcklqdq xmm0,xmm0   ; xxxxxxxxHHHHHHHH -> HHHHHHHHHHHHHHHH
mov ecx, 256000/4   ; 16 byte
mov edi, lpDst
.while ecx>0 
    movntdq xmmword ptr [edi],xmm0
    add edi,16
    dec ecx
.endw

I uploaded the whole code here http://pastie.org/9831404 --- the MASM package from hutch is required for assembling.


If SSSE3 is available, you can use pshufb to broadcast a byte to all positions of a register instead of a chain of punpck instructions.

movd    xmm0, edx
xorps   xmm1,xmm1      ; xmm1 = 0
pshufb  xmm0, xmm1     ; xmm0 = _mm_set1_epi8(dl)
Friday, August 6, 2021
 
Amber
answered 4 Months ago
54

I can't explain why this is happening, but it appears that non-deterministic finalization of the Image objects on the finalizer thread is affecting the encoding of images on the main thread. (Image implements IDisposable, so you should call Dispose on it to deterministically clean it up when you're finished using it; otherwise, it will be finalized at an arbitrary time in the future.)

If I change your example code to the following, I get the same results from every call to Save:

using (Image sourceToConvert = Bitmap.FromFile("c:\tmp\F1.tif"))
    sourceToConvert.Save("c:\tmp\F1_gen.png", ImageFormat.Png);           

for (int i = 0; i < 100; i++)
{
    using (Image sourceToConvert = Bitmap.FromFile("c:\tmp\F1.tif"))
        sourceToConvert.Save("c:\tmp\F1_regen.png", ImageFormat.Png);

    // files are the same
}

Note that I did find one further oddity: when running a 32-bit (x86) build on Windows 7 SP1 x64, the first two calls to Save returned different results, then every subsequent call to Save produced the same output as the second call. In order to make the test pass, I had to repeat the first two lines (before the loop) to force two saves before performing the equality checks.

Wednesday, September 29, 2021
 
assylias
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share