Question

I have written a quick C++ DLL in Visual Studio, with a single function called ReportVersion() that returns 1.

int _stdcall ReportVersion() {
    return 1;
}

I then created a VB.net EXE to call this DLL.

Public Class Form1

    Private Declare Function ReportVersion Lib "Test_DLL.dll" () As Long

    Private Sub btnVersion_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnVersion.Click
        Call MsgBox(ReportVersion())
    End Sub
End Class

If I press F5 and run in either Release/Debug mode, the return value of ReportVersion is 6824607285638070273.

If I build the solution and run the .EXE manually, the return value is 1 (as expected).

Where on earth is it getting 6824607285638070273 from?

For reference, I used these 2 articles as examples for creating them

http://edais.mvps.org/Tutorials/CDLL/CDLLch1b.html

http://edais.mvps.org/Tutorials/CDLL/CDLLch2.html

As I’ve never done a call between DLL/Application written in different languages.

Answer 1

Having emailed the original author of the linked articles, I was pleasantly surprised to get a response back about such an old article. This helped me understand the problem.

In VB6, the "Integer" type was a signed 16-bit integer, and the "Long"
type was a signed 32-bit integer.

In VB.NET, the "Integer" type is a
signed 32-bit integer, and the "Long" type is a 64-bit signed integer.
The "Short" type was also added to fill the 16-bit signed integer
role.

Indeed, if you convert the value given back to you by ReportVersion()
above you’ll see it comes out to 0x5EB5E02B00000001. As you can see
the low 8 digits (0x00000001) have the correct value in, where as the
high digits just have whatever data happened to be in memory next to
it at the time.

As for the discrepancy between running as an executable as opposed to
within the IDE, I can only imagine that perhaps that area of memory is
being cleared out prior to the application running so it actually
returns 0x0000000000000001 which is correctly evaluated as 1.