Re^3: Import a DLL from C# to Perl

I called from C like this ...

With your Strawberry Perl, any compilation that is done (eg with Inline::C) will be done using gcc-7.1.0.
I don't see any issue with your code and gcc-7.1.0.
And, AFAIK, it doesn't matter whether the dll you want to load was built from C code or C# code or C++ code. Nor should it matter which compiler built it.

There is the problem that "result" is undeclared - which I "fixed" by commenting out "funci(&result)", as that else block will never be entered in my case, anyway.
The program then compiled and ran cleanly when built with gcc, outputting "DLL not found" (as expected).

If that program works fine for you, then it should be fine with Strawberry Perl and Inline::C ... unless, of course, DLLExportTest.dll wants to load a file (eg another dll) that is not locatable in the Srawberry Perl environment.

This Inline::C script runs fine for me on Strawberry Perl 5.26.0 and, after compilation, outputs "initdll returned: 0".

use strict;
use warnings;

use Inline C => Config =>
  BUILD_NOISY => 1;

use Inline C => <<'EOC';

typedef int (__stdcall *f_funci)();

int initdll()
{
    double a = 1;
    double b = 2;
        HINSTANCE hInst =
         LoadLibrary("C:\\dev\\teste\\DLLExportTest.dll");
    if( hInst != NULL )
    {
          f_funci funci = (f_funci)GetProcAddress(hInst, "Add");
        if (!funci) {
            printf( "could not locate the function\n" );
            return EXIT_FAILURE;
        } else {
            /* funci(&result); */
        }
      
        FreeLibrary( hInst ); // temporary
        return 1;
    }
    else
    {
        return 0;
    }
    
}

EOC

print "initdll returned: ", initdll(), "\n";
[download]

Cheers,
Rob

Comment on Re^3: Import a DLL from C# to Perl Download Code

Replies are listed 'Best First'.
Re^4: Import a DLL from C# to Perl by BrowserUk (Patriarch) on May 10, 2018 at 04:09 UTC
And, AFAIK, it doesn't matter whether the dll you want to load was built from C code or C# code or C++ code. There is a problem with C#, in as much as (AFAIK) it always produces .NET Managed Assemblies. Essentially, the DLL contains initialisation and thunking code to connect it to the .NET subsytems, that needs to be called for stuff to work. It's meant to be done by wrapping it in a COM wrapper; but there is another way: Reverse P/Invoke At that point, I've described more than I understand, so I'll leave it to the OP to follow the link and read about there. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit	[reply]
Re^5: Import a DLL from C# to Perl by syphilis (Archbishop) on May 10, 2018 at 04:56 UTC
... the DLL contains initialisation and thunking code to connect it to the .NET subsytems, that needs to be called for stuff to work I can't claim to have any knowledge about C#, but I think that paulorfmmb has indicated that he can access his C#-built dll from C code (presumably using his MS C compiler to build the C executable). I was thinking that if the same dll cannot be accessed by an executable built from the same C code, but built with a gcc (mingw-w64) compiler, then it's because of a difference in the environment under which the gcc-built executable is running. If that's so, then it's just a matter of fixing the environment when running the gcc-built executable. However, I guess it's also possible that building the executable with a Microsoft compiler does stuff that doesn't get done when building with gcc - and that this explains the failure of gcc-built apps to deliver. Or, FAIRK, maybe the problem is something entirely different again. Cheers, Rob	[reply]
Re^6: Import a DLL from C# to Perl by BrowserUk (Patriarch) on May 10, 2018 at 05:35 UTC
I guess it's also possible that building the executable with a Microsoft compiler does stuff that doesn't get done when building with gcc If he's building stuff using the VS GUI,or one of the XML build files it generates; it likely doing a crap load of stuff that he hasn't explicitly asked for. (eg. I think if you ask VS to link a C program to a C# dll, it knows to add (unseen) code to initialise the .NET runtime. (I think)) That said, I don't use gcc, so maybe that knows how to do all that stuff (now). With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit	[reply]
Re^4: Import a DLL from C# to Perl by paulorfmmb (Acolyte) on May 10, 2018 at 18:25 UTC
I still get the same result. Using DEV-C++ I can run the code with no problems, with Inline::C I get the same error.	[reply]
Re^5: Import a DLL from C# to Perl by syphilis (Archbishop) on May 11, 2018 at 03:33 UTC
Using DEV-C++ I can run the code with no problems, with Inline::C I get the same error I think the DEV-C++ success demonstrates that mingw ports of gcc are capable of providing what's needed - since DEV-C++ uses such a port of gcc. Inline::C and Inline::CPP provide a Config option (CC => 'C:/other/compiler.exe') that enables the use of a specific compiler. You could try specifying the DEV-C++ compiler as the one to use, and see how that goes. Though, for that to work, you might also have to import more of the DEV-C++ environment into the environment under which you're running perl. YMMV. You could also look at building your own perl with your MSVC compiler. I think (untested by me) that's still a fairly simple procedure: 1) Download and unpack the perl source. 2) Open a 'cmd.exe' shell and set up your MSVC environment. (This used to mean running vcvars32.bat ... dunno if that's still appropriate for your case.) 3) 'cd' to the win32 folder of the perl source. 4) Configure the "Makefile" file as appropriate. (Just follow the documentation that's in the "Makefile" file.) 5) Run 'nmake' then 'nmake test' then 'nmake install'. 6) Always run perl with your MSVC environment set. I expect that would deliver what you want - but, as we've already seen, what I expect and what you will get are not necessarily the same. Cheers, Rob	[reply]