strange behaviour of DLL

[ADoozer]

i was going to post this in the VC++ forum but im having problems viewing it, anyways.

i wrote a DLL in VC++ with a bunch of functions that i wanted to call from VB, this part is fine.

however when i test my code from VB, i get different results from testing within VC++

i wont post all the code but ill give a brief snapshot.

VBModule

Public Type myType
    A As Long
    B As Long
    C As Long
    '...
    K As Long
End Type

Public Declare Function FunctionCall Lib "D:\Visual C++\TestDLL\Release\TestDLL.dll" (ByVal hOffset As Long, ByRef theType As myType) As Long

VBFormCode

public sub command1_Click()
dim ret as long 
dim myOffset as long
dim fred as myType
myOffset=13
ret = FunctionCall (myOffset, fred)
end sub

[/code]

now this produces

4,557,2668,33924....638550

however when i call from my testC++ program the same ofset(13) produces

4,557,2668,47124....402930

the only difference i can see is that my VB app uses the release version of the DLL and the C++ app uses the debug version

this has got me totaly stumped, so any input is greatly appreciated.

If somethings hard to do, its not worth doing - Homer Simpson

 

[ADoozer]

update:

using the debug DLL yields the same results on VB and VC+.

now im realy puzzled.

If somethings hard to do, its not worth doing - Homer Simpson

 

[chiph]

What's inbetween C and K in your structure? Anything that takes less than 4 bytes of storage? (shorts, bytes, chars, etc).

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[strongm]

chiph's answer is hinting at a packing/alignment problem - just as we've been suggesting in the other forum where you are asking this question

 

[ADoozer]

VC

struct myType
{
	long A;
	long B;
	long C;
	long D;
	long E;
	long F;
	long G;
	long H;
	long I;
	long J;
        long K;
};

VB

Public Type myType
    A As Long
    B As Long
    C As Long
    D As Long
    E As Long
    F As Long
    G As Long
    H As Long
    I As Long
    J As Long
    K As Long
End Type

i could understand allignment issues if both the debug and release versions of DLL caused an error, but this isnt the case.

thanks.

If somethings hard to do, its not worth doing - Homer Simpson

 

[strongm]

debug" uses a whole bunch of different compiler flags to "release" in VC++ (although, to be fair, I'm not immedaitely aware of a difference in the packing option used; by default I think they both use the ... erm ... default)

 

[ADoozer]

im totaly stumped, for now im just going to use the debug DLL.

ive uploaded the VBproject(260k) and the VCproject(2.3m) files if anybody wants to take a look.

If somethings hard to do, its not worth doing - Homer Simpson

 

[comaboy]

What strongm and chiph are hinting at is that VB *cough* "doesn't do pointers"*. Therefore you maybe unaware of the way in which VB and DLL's communicate. Basically a question:

How big is this structure:
Dim L As Long (4 bytes)
Dim B As Byte (1 byte)

5 bytes, right? WRONG. You are actually storing the pointer to the memory location of where the data is stored.

Dim L As Long [32 bit pointer to (4 bytes) of memory]
Dim B As Byte [32 bit pointer to (1 byte) of memory]

This is probably how you are misaligning.

All the best and hope this helps!

*Actually it does, but varptr etc are pretty much undocumented and not the "VB way

 

[ADoozer]

i think strongm and chiph were most probably refering to me using diffent types in my type declaration that werent 4 byte alligned. (see thread222-462075 for more information)

however since i am passing "a pointer" to the first element of a 44 byte type, and all elements are 4 bytes, i cant see why an allignment issue could occur.

however im still stumped as to the strange behavior in code execution.

(see

http://support.microsoft.com/default.aspx?scid=KB;en-us;q106553

for information on passing data types to C DLLs)

the quest continues

thanx Dave

If somethings hard to do, its not worth doing - Homer Simpson

 

[ADoozer]

i should point out that the bit of the discussion i am referencing in thread222-462075 is right at the bottom.

If somethings hard to do, its not worth doing - Homer Simpson

 

[comaboy]

Heh, just read the other thread and feel like a complete idiot!

Oh well, not the first time, anyway!

 

[ADoozer]

lol, not to worry. happens to the best of us from time to time.

If somethings hard to do, its not worth doing - Homer Simpson

 

[avanderlaan]

As both chiph & strongm have suggested, this may be an alignment issue. Is the C/C++ structure alighment guaranteed by a #pragma pack statement, or are you relying on the /Zp option for the entire translation unit? NOTE: The default packing level used when neither the /Zp nor /pack switch is specified is 8, in both Win32 and Win64 build environments.

 

[ADoozer]

The #pragma pack directive modifies the current alignment rule for members of structures following the directive.

since my struct contains nothing but longs, there boundries WILL fall on the default alignment of 8 bytes. (wont they?)

anyway, this topic seems to have strayed away from the VB element, so i will repost in VC++ forum as soon as i can get access to it.

thanx for all the help

If somethings hard to do, its not worth doing - Homer Simpson