Delphi/C++ DLL problem - unsigned long vs unsigned int?

(SOLVED: See self-reply. Thanks to those that answered).

I'm having a weird problem with a C++ DLL I am loading dynamically into my Delphi 6 Pro program. One of the function calls in the DLL is:

__declspec(dllexport) int foo(unsigned int A, unsigned long bitsetVector);

I have the function pointer cast in my Delphi function as:

foo : function(A: LongWord; bitsetVector: LongWord): integer; stdcall;

Almost all the other calls I have mapped out to the DLL work fine but this one, which returns an "invalid bitset field" error, indicating it doesn't like the bitsetVector value. The bitsetVector parameter is built by using the OR operator to set bits. All the enumeration constants used to set the bits are powers of 2 of course. I'm pretty sure it's a cast error somehow, so I'm wondering if there's some nuance about "unsigned int" vs. "unsigned long" that I do开发者_如何学Pythonn't know about. The MSDN C++ documentation shows them both as being 4 bytes each with a range of 0 to 4,294,967,295, so they look identical to me.

Bizarro note. I tried running a for loop, range 0 to 100, where I just passed the for iterator variable (i) as the bitset vector. All the odd number values failed while all the even numbers succeeded. This is why I feel like it's a casting error. Note, I have no corruption or memory errors. I did full checks with FastMM4 and there have been no stack crashes or heap corruptions despite the fact that several of the DLL calls receive LongWord parameters and usually "out" parameters usually suffer first in DLL integrations mismatches. Also, the values I get back from the C++ DLL look right.

If anyone out there has any ideas or thoughts about this, or perhaps some tangential knowledge that might reveal the real problem if it's not a casting problem, I'd like to know.

Thanks.

---

Thanks to those that responded. This turned out to be one of those cases where the symptoms were truly misleading. The real problem was that the first enumeration constant used to set bits, which had of course a value of 1, was illegal in the context of the call. That's why only "even numbered" bitset values succeeded. It was solely because the illegal enumeration value was not present. It turns out the DLL linkage was sound.