[VC++ and VB6] Bad DLL Calling Convention

[Yoni]

Visual Basic uses BSTR for strings.  That is what  you should use as well.

N and O put together spell NO

[MyndFyre]

Visual Basic uses BSTR for strings.  That is what  you should use as well.

BSTR is a COM type, not a C type.

[UserLoser.]

Blerf.cpp:

Code Select Expand


void __stdcall Bleh(int blah, char *boo)
{
    if(blah > 0)
        strcpy(boo, "bleh");
}


Blerf.def:

Code Select Expand


Bleh=Bleh


APIDeclares.bas:

Code Select Expand


Declare Sub Bleh Lib "Blerf.dll" (ByVal Blah As Long, ByVal Boo As Long)


CoolModule.bas:

Code Select Expand


Sub Meh()
    Dim Eh As String
    Eh = Space(256)
    Call Bleh(1, Eh)
End Sub


Bleh, you get the point

[TehUser]

Code Select Expand

<snip>
   if (ret == "") {
      return product;
   } else {
      return ret;
   }


You're still trying to use == to compare strings.

[Kp]

Code Select Expand

<snip>
   if (ret == "") {
      return product;
   } else {
      return ret;
   }


You're still trying to use == to compare strings.

Yes, but unless his compiler is totally braindead, it's ok in this case.  ret was initialized to point at an empty string, and now he's comparing to see whether it points at an empty string.  If the compiler is pooling strings (and it really should!), then the two will have the same address and it'll be OK.

[Joe[x86]]

Code Select Expand

<snip>
   if (ret == "") {
      return product;
   } else {
      return ret;
   }


You're still trying to use == to compare strings.

Oops..

[...]

You're still trying to use == to compare strings.

[...]unless his compiler is totally braindead [...]

Lets asume VC++ is braindead. =p

[TheMinistered]

I was assuming he was using an MFC DLL considering he is just now figuring out how to do it... thus...

If we want to pass strings to a DLL as input or to get strings from a DLL as output and we want to do this in the most general way, we are told from Microsoft to use the BSTR type.

The only reason char* works in this case is because it's being passed as ANSI.  However, if microsoft encourages the use of BSTR in this case then why not?

Again from the MSDN documentation (in a remote part of it, to be honest !), we read what follows:

1.  Visual Basic always creates a new BSTR containing ANSI characters (not UNICODE ones!) when passing a string to a DLL
2.  Visual Basic always gets a BSTR containing UNICODE characters when getting a string from a DLL
http://www.codeproject.com/dll/BSTR_CString_conversion.asp

[Joe[x86]]

I'm not using MFC.