On 04/09/2008 in message <OsRDyKpDJHA.4800@xxxxxx> Pavel
Minaev wrote:
Quote:
>The only case when a .NET assembly is platform specific is when it uses
>P/Invoke or COM interop to call into a native DLL/component, and that
>component is only available for a specific platform. For example, when you
>call user32.dll via P/Invoke, your assembly is still fine, because on
>32-bit OS it will load 32-bit user32.dll, and on 64-bit OS it will load
>64-bit user32.dll. But if you P/Invoke into some custom .dll, which you
>redistribute with your application, and which is 32-bit only, then, when
>your assembly is loaded and executed on 64-bit OS using 64-bit version of
>.NET, it will crash when it'll try to invoke that 32-bit DLL - and that's
>when you set the target platform for your assembly to "x86", so that even
>on 64-bit, it gets JIT-compiled to 32-bit code and run via WoW64.
OK, pretty well all of my apps use P/Invoke and COM as there is limited
support in NET for what I want to do (e.g. masked system icons in
TreeViews, showing the Explorer context menu etc.). I have found that many
calls which work in x86 fail (sometimes spectacularly) when compiled for
x64. After correcting them (and often it is uint for int) they work fine
in both. So x64 acts as a check that I am getting my prototypes right. It
just seems that somehow x64 is less forgiving than x86.
I will continue to experiment and try to find something that doesn't use
databases so I can allow it to run as x64.
--
Jeff Gaines Damerham Hampshire UK
All those who believe in psychokinesis raise my hand.