Bit specific code in agnostic assemblies???

re: Bit specific code in agnostic assemblies???

Frank Hileman — Thu, 11 Aug 2005 18:21:42 GMT

This is useful information. If you use PInvoke, you are then "locked" into distributing 2 assemblies, and this technique won't work? There is no way around this?

re: Bit specific code in agnostic assemblies???

joshwil — Thu, 11 Aug 2005 18:31:39 GMT

Using P/Invoke doesn't automatically lock you into 2 assemblies. For instance, P/Invoking to the Win32 API will work find as long as the signatures are correctly defined (i.e. things that scale are defined as IntPtr/UIntPtr and the structs don't have wierd packed layouts that can't be easily transitioned to 64-bit).

Additionally if you are writing your own native code to P/Invoke to as long as you provide an interface that follows these conventions (and your dlls are named the same thing on both platforms, you may have to do some path magic to make this work) then everything will just work with an agnostic assembly.

The problems crop up when you have something like a structure that has wierd packing that doesn't carry over to 64-bit or you have different interfaces on 32-bit and 64-bit. Even in this case as mentioned above if the functionality is the same and it is simple enough you could wrap the native call with a managed helper which knows (using the if(IntPtr.Size==8)/else trick) how to call the appropriate API depending on the platform and magically do the right thing (whatever that is) with arguments and return values.

re: Bit specific code in agnostic assemblies???

Frank Hileman — Fri, 12 Aug 2005 22:30:59 GMT

Ok, I think I understand. I did do quite a bit of work porting from 32 to 64-bit processors in the past (alpha), so I understand the issues. It sounds like PInvoking to Win32 is not a problem, as long as we use the right signature.

So let's consider that other case, PInvoking to our own unmanaged dlls -- and specifically what if you want one unmanaged build for both 32 and 64, is that an absurd idea? In the past I would think it would not even run... Maybe you have covered this before.

Can you give an example of a structure with weird packing? I understand that if you assume pointers are the same size everything is messed up.

re: Bit specific code in agnostic assemblies???

joshwil — Fri, 12 Aug 2005 23:14:05 GMT

Frank --

I'm not sure I understand the question. Are you asking if you can have a single unmanaged DLL and P/Invoke to it from managed code running under either the 32-bit or 64-bit runtimes?

If that is the question then the answer is no. Given that your unmanaged code has to be either 32-bit or 64-bit and a process can only load DLLs of its native bitness then you won't be able to load your unmanaged DLL in one of the processes.

I'll try to find an example of a structure that breaks on 64-bit, I don't have one at the ready (most don't).

Der managed P/Invoke Mediator

Dirk's Blog — Mon, 06 Mar 2006 01:08:02 GMT

MDbg, Managed-debugging, and 64 bit

Mike Stall's .NET Debugging Blog — Wed, 08 Mar 2006 19:48:02 GMT

V2 CLR added support for 64-bit (amd64 and ia64), and that includes managed-debugging support. So a 64-bit...

Attorney Search » Bit specific code in agnostic assemblies???

Attorney Search » Bit specific code in agnostic assemblies??? — Sun, 20 Apr 2008 20:35:24 GMT

PingBack from http://lawyers-for-injury.info/attorney-search/?p=280