On Sep 4, 6:40*pm, "Jeff Gaines" <whitedra...@xxxxxx>
wrote:
Quote:
> 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
The calls are the same no matter how you compile. What fails is that
your 64-bit process is trying to load a 32-bit DLL. It's actually not
even a .NET limitation, but a general Win32 one.
Quote:
> After correcting them (and often it is uint for int) they work fine
> in both.
Yet again, I cannot imagine any interop scenario where replacing uint
for int would fix an x86/x64 incompatibility problem. In fact, if you
end up directly calling 32-bit code from 64-bit code, there's
absolutely nothing you can do in prototypes or elsewhere to make it
work. The OS will make sure that it won't.
Do you perhaps mean that you accidentally use int/uint where you
should have used IntPtr/UIntPtr? This sort of thing would indeed
result in your code working against 32-bit DLLs, but failing against
64-bit.
Quote:
> So x64 acts as a check that I am getting my prototypes right. It
> just seems that somehow x64 is less forgiving than x86.
To reiterate: there are absolutely no differences in your C#
prototypes on x86 and on x64. Mainly because the relations between
types are always strictly defined (i.e., int is always 4 bytes, long
is always 8, IntPtr varies at runtime depending on platform, but you
will never get, say, an implicit conversion between int and IntPtr,
even if you compile on x86 - unlike C++ std::size_t).