If this is just about utilizing user32.dll's MessageBoxA function, then the Inline::C cookbook contains this example.

Win32 can also do that:

use Win32;;
Win32::MsgBox( "Hi, from perl\nWhat can I do for you today?", MB_ICONQ
+UESTION );;
[download]

---

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

I tried using Inline::C and Inline::CPP and I get the same result. Looks like Perl doesn't have access to something from the C# enviroment. And it is not about the MessageBox, I'm just using it as an example.

I tried using Inline::C and Inline::CPP and I get the same result

According to what I found on StackOverflow the error is simply that a file cannot be found.
When you run the perl script, is it running in the exact same shell that successfully runs the C/C#/C++ programs ?
I'm thinking that the success you experience with the C/C#/C++ programs will depend upon certain environment variables being set correctly ... and that the failure you experience when running the perl script arises because one or more of those environment variables is no longer set (or has been altered).

Cheers,
Rob

With this code I was able to call the dll from a C code.

This C program you wrote to call your C++ wrapper that calls the C# function, did you build this C program using Visual Studio?

You don't mention which distribution of Perl you are using. Even on MS Windows, Perl is usually not built using Visual Studio. And since XS modules and Inline::C (and other Inline:: code) need to be built with the same tool chain as Perl was built with, presumably the XS, Inline::C or Inline::CPP code was not built with Visual Studio.

Maybe this Compiling perl on windows with visual studio thread is helpful to you.

Update: syphilis is correct in pointing out that Win32::API would not have been built with Visual Studio, either. What I neglected, though someone else did mention, is that C# uses .NET as well as the Windows API. According to a friend of mine, building .NET applications without Visual Studio can be very hard.

presumably the XS, Inline::C or Inline::CPP code was not built with Visual Studio

And nor would Win32::API have been built with Visual Studio.
This could definitely pose problems.

Could paulorfmmb please check which compiler is being used by perl. (Running perl -V:cc will provide that info.)
In fact, probably best to give us the full perl -V output.

Cheers,
Rob

Here is perl -V output

Summary of my perl5 (revision 5 version 26 subversion 2) configuration
+:

  Platform:
    osname=MSWin32
    osvers=10.0.16299.371
    archname=MSWin32-x86-multi-thread-64int
    uname='Win32 strawberry-perl 5.26.2.1 #1 Sun Apr 15 11:47:13 2018 
+i386'
    config_args='undef'
    hint=recommended
    useposix=true
    d_sigaction=undef
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=undef
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='gcc'
    ccflags =' -s -O2 -DWIN32 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE
+_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fw
+rapv -fno-strict-aliasing -mms-bitfields'
    optimize='-s -O2'
    cppflags='-DWIN32'
    ccversion=''
    gccversion='7.1.0'
    gccosandvers=''
    intsize=4
    longsize=4
    ptrsize=4
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=12
    longdblkind=3
    ivtype='long long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='long long'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='g++'
    ldflags ='-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
    libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\i686-w64-mingw32\lib C:\STR
+AWB~1\c\lib\gcc\i686-w64-mingw32\7.1.0
    libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
+ -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -
+lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomd
+lg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_
+32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    libc=
    so=dll
    useshrplib=true
    libperl=libperl526.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs
    dlext=xs.dll
    d_dlsymun=undef
    ccdlflags=' '
    cccdlflags=' '
    lddlflags='-mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c
+\lib"'


Characteristics of this binary (from libperl):
  Compile-time options:
    HAS_TIMES
    HAVE_INTERP_INTERN
    MULTIPLICITY
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_IMPLICIT_CONTEXT
    PERL_IMPLICIT_SYS
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    USE_64_BIT_INT
    USE_ITHREADS
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
  Built under MSWin32
  Compiled at Apr 15 2018 11:51:03
  @INC:
    C:/Strawberry/perl/site/lib
    C:/Strawberry/perl/vendor/lib
    C:/Strawberry/perl/lib
[download]

2 thoughts.One is to place your DLL in the GAC where .NET looks for dependmcies.You have however to sign the assembly in order to do that.Check How to: Install an Assembly into the Global Assembly Cache

The second is to use Process Explorer to check where your process is trying to load your dll from,and then place it in there.

Truth is that you have like 3 levels of indirection;A C++ programm calls a C# programm, both under managed CLR, which calls into the unmanaged Win32 API, most probably through P/Invoke, to get the messagebox function.What are you actually trying to do?

I was about to suggest ActiveState's PerlNET but seems it was discontinued.

You'd have to pack your Perl script into an executable, but it used to work.

Crossposted to StackOverflow. Crossposting is ok, but it is considered polite to inform about it so that efforts are not duplicated.

Sorry for the trouble. I didn't know.

The thing is I can't figure out what this "piece of glue" is.

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;
    }
    
}
[download]

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

Plain C