xxxxx@earthlink.net wrote:
Peter:
I’m sorry I’m a bit confused. The dox say:
IN ULONG BufferLength,my signature says:
ByVal BufferLength As ULong, _and the actual value is created as:
DescriptorBufferSize = Convert.ToUInt64(Marshal.SizeOf(mydevicedescriptor))What I hear you and Tim saying is that this really a 32 bit value, which is what Marshal.SizeOf produces directly?
Yes. Longs in Microsoft’s native C and C++ compilers are a 32-bit type,
for confusing and inscrutable reasons that we’ve discussed in the past.
However, longs in the .NET languages (such as VB and C#) are a more
sensible 64-bit type.
If so, is this generally true (and I *was* wondering why you’d make the buffer lenght a 64 bit number, I mean 32 bits is 2billion bytes). Then I should use Integer type for all ULONGs?
This is why the signatures need to documented by MS for *each of the languages supported*.Full stop.
Microsoft doesn’t have a list of “supported languages” for the Win32
API. Many people use these APIs from Python and Ruby. Do they need
signatures for these as well? I think it’s a better plan is to
advertise the APIs in some “lowest common denominator”. Then, you can
develop a set of rules that let you convert them to whatever the
language-of-the-month is. There are many web sites (including the MSDN
CLR documentation) that talk about managed/unmanaged type mapping in
P/Invoke; they shouldn’t really have to put a note on every API page.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.