There has been discussion about whether or not to add some APIs to System.Environment or System.Diagnostics to allow one to deduce whether or not they are on a 32bit or 64bit system... Right now we don't have any with the caveat that if you _really_ need to know then maybe you should be thinking about your design... Should you really be using seperate 32bit and 64bit assemblies that run in 32bit or 64bit processes with your bitness specific knowledge compiled explicitly into those assemblies? Is there a better way to do what you're doing such that it doesn't have to be bitness specific?

That said, there are some times when it is hard to get around the need for that knowledge, and for those times as Kris mentions above there is IntPtr.Size, mind you this is significantly faster than using Marshal.SizeOf(typeof(IntPtr)) (or whatever the proper code is... ya'll get the point) as IntPtr.Size is a hard coded property of the IntPtr that is conditionally compiled to be either 4 or 8 depending on whether you're in a process that loaded up the 32bit version of mscorlib.dll or the 64bit version...

-josh

Just a quick question in regards to integer size and 32/64 bit. We're trying to find the definitive answer to a question about the size of an integer. In the x86/32 framework a C# integer is defined as System.Int32. Does this change on a 64bit machine, is it System.Int64 or does it remain System.Int32?

-- Scott

I double checked with Josh, and yes in C# and VB, "int" is System.Int32 no matter if you are on a 32bit or 64bit machine. You would have to specify Int64 if you wanted a 64bit int, or use IntPtr for it to change depending on the platform.

PingBack from http://feeds.maxblog.eu/item_1177680.html

PingBack from http://drugsmoviesblog.info/kris-stantons-weblog-simple-way-to-check-if-youre-on-a-64-bit-machine/