I called from C like this
#include <windows.h>
#include <stdio.h>
typedef int (__stdcall *f_funci)();
int initdll();
int main ()
{
if ( initdll() == 1 )
{
printf( "Server started!\n" );
}
else
{
printf( "DLL not found\n" );
return 0;
}
while ( 1 == 1 )
{
//printf( "..." ); // preform other dll releted actions
}
}
int initdll()
{
double a = 1;
double b = 2;
HINSTANCE hInst = LoadLibrary("C:\\dev\\teste\\DLLExportTest.d
+ll");
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;
}
}
| [reply] [d/l] |
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";
Cheers, Rob
| [reply] [d/l] |
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.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
| [reply] |
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] |