Closed GoogleCodeExporter closed 8 years ago
This problem never shows up so far because the Open Hardware Monitor is built
for Any CPU, so it runs as 32-bit process only on 32-bit versions of Windows.
But of course if used as library only, this can lead to problems, as the
current implementation is simply wrong.
I will try to avoid adding .NET 4 as requirement. A starting point for fixing
this issue can be found here:
http://stackoverflow.com/questions/336633/how-to-detect-windows-64-bit-platform-
with-net
Original comment by moel.mich
on 16 Sep 2011 at 8:15
Either using Is64BitOperatingSystem in .NET 4 or IsWow64Process from the link
in the previous comment is a good solution. Would Ring0.cs be updated soon to
reflect this change?
Thank you so much.
Original comment by LingYM...@gmail.com
on 27 Sep 2011 at 2:03
Without using a new .NET Framework, you can replace:
{{IntPtr.Size == 4}}
to
{{(ushort)new
System.Management.ManagementObject("Win32_Processor.DeviceID='CPU0'")["Architect
ure"] == 0}}
Because {{(ushort)new
System.Management.ManagementObject("Win32_Processor.DeviceID='CPU0'")["Architect
ure"]}} returns 0 for x86 and 9 for x64
Using {{IntPtr.Size}} can erratically retrieve the number of bytes on an
assembly, when caller is compiled to any processor.
Original comment by lgp1...@gmail.com
on 29 Feb 2012 at 7:53
This issue was closed by revision r399.
Original comment by moel.mich
on 11 Jul 2012 at 10:28
Original issue reported on code.google.com by
LingYM...@gmail.com
on 16 Sep 2011 at 5:05