0

I have a DLL which I wrote using C++. I'm loading this DLL in another C++ (console) project during runtime by the use of LoadLibrary(), and then accessing the function within the DLL by GetProcAddress().

Here's the DLL code:

   SHARED_CLASS string hill(string inmode, string inkey, string xinpassword, string outpword);

And here's how I load and call the function:

typedef string(_cdecl* MYPROC)(string inmode, string inkey, string xinpassword, string outpword);

HMODULE hInst = LoadLibrary(TEXT("Cipher.dll"));
MYPROC ProcAdd;
BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;

if (hInst == NULL)
{
    cout << "NOT LOADED";
    cout << "\n";
}
else
{
    cout << "LOADED";
    cout << "\n";

    ProcAdd = (MYPROC)GetProcAddress(hInst, "hill");

    if (NULL != ProcAdd)
    {
        fRunTimeLinkSuccess = TRUE;
        passwordmew = (ProcAdd)("-e", "xxxxxx", "lcgoanhoehfogjdclkmdmlmb", passwordmew);
    }
    else
    {
        DWORD dwError = 0;
        dwError = GetLastError();
    }
}

I have no problem with loading and calling the function (it is calling the correct function), the issue comes when passing the parameters to the function, the value that is passed on to the function is not the same as the value when I called the function.

Inside the DLL function, I have this condition, If you can see in my code when I called the function I passed on "-e" for the first parameter, supposedly it should fall into the if condition, but instead it is falling into the else condition. I debugged it and found that this is the same for all of the parameter values.

if (inmode == "-e")
{
    //it should go here
}
else
{
    //instead it goes here
}

The values being passed in appear to be in an array or something:

Screenshot during debugging

Any idea why?

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Ken
  • 19
  • 4
  • Can you tell us what the value is that arrives instead of the -e ? – Jerry Jeremiah Oct 07 '20 at 03:13
  • Are you using the same compiler and options for building both of these? – chris Oct 07 '20 at 03:13
  • I edit my post to add the screenshot of the value that is being passed on to the function. Yes I am using the same compiler for the two projects. Does it have something to do with character set? – Ken Oct 07 '20 at 03:31
  • 2
    If you mean the option I think you mean, the character set won't make a difference because `std::string` always uses `char` and the character set affects winapi macros. I was thinking more along the lines of debug and optimization options. If you, for example, mismatched debug and release on a `std::string` with a different size on debug and release, then a mismatching size would be allocated for the parameters and the data within could be interpreted completely wrongly. – chris Oct 07 '20 at 04:08
  • `string x[100`] is either *100 `std::string` objects* (!!) or *100 bytes of CS50 "string"*. Which is it here? This is why `using namespace std` causes problems and should be avoided whenever possible. – tadman Oct 07 '20 at 04:42
  • None-POD types, like std::string, are simply not safe to pass over the DLL boundary,, even if you use the same compiler and settings for both app and DLL. Use portable POD types only, like C-style `char*` strings. – Remy Lebeau Oct 07 '20 at 04:43
  • You're right @chris, I was using the release version of the DLL and I was running the console application on debug mode, after using a debug version of the DLL everything went perfectly. Please put your comment as the answer so I can mark it as the answer to this question. Thanks for the help! – Ken Oct 07 '20 at 04:43
  • @RemyLebeau, While I certainly would recommend that, does that mean the [answers](https://stackoverflow.com/a/22280181/962089) in the dupe are wrong to qualify this being okay with using the same compiler+options+runtime? My DLL knowledge is not complete enough yet. Or is there perhaps a difference between passing by value vs. reference that affects those qualifications? – chris Oct 07 '20 at 06:17
  • @chris it is certainly possible to make this work within a given situation with the right amount of work, but it severely limits portability, even to new versions/configurations of the same compiler. It is just not worth the risk. – Remy Lebeau Oct 07 '20 at 06:21
  • @RemyLebeau, I see, thanks. – chris Oct 07 '20 at 06:42

0 Answers0