On Jan 29, 2015, at 3:33 AM, Alex J Lennon <ajlen...@dynamicdevices.co.uk>
wrote:
> Can anybody advise if this is an implementational issue or if I'm doing
> something wrong here?
You're doing something wrong, *and* there's an implementation issue.
Module GetPEKind() returns information about the specified module, which can
have absolutely no bearing on the actual runtime environment.
The C# compiler has a /platform:PLATFORM flag to specify the target platform:
mcs /platform:x86 myapp.cs
This sets a flag in the PE header, and Module.GetPEKind() extracts this
information. For example, build with /platform:arm, and Module.GetPEKind() will
return ImageFileMachine.ARM *for that assembly*.
.NET checks this PE header value during process startup. For example, if you
compile with /platform:anycpu, your app may run as a 32-bit process on 32-bit
windows, and as a 64-bit process on 64-bit windows. If you need to run as a
32-bit process on 64-bit windows (e.g. because a dependent .dll you use is only
32-bit), then you must build your app with /platform:x86 to force .NET to run
your app as a 32-bit process on 64-bit windows.
Mono ignores this PE header value. In the case of 32-bit vs. 64-bit processes,
you must use an appropriately built mono (e.g. mono32 for a 32-bit mono) in
order to get an appropriate bitness. (It's also entirely possible that there is
no option; at present on OS X, the Mono package only provides a 32-bit runtime,
though you can build a 64-bit runtime yourself.)
Offhand, short of using uname(3)/Mono.Unix.Native.Syscall.uname(), I'm not sure
of a good way to determine the processor architecture.
- Jon
_______________________________________________
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
