in reply to Re^7: [OT - MS Visual Studio] How to build a dll that Win32::API can access
in thread [OT - MS Visual Studio] How to build a dll that Win32::API can access

Have you tried reverting to 0.41?

No - I've gone back to 0.20 (which used to work fine for me), and I've tried both 0.53 and 0.55. They're all behaving the same. If I build with __stdcall they can't find the "procedure". If I build with __declspec(dllexport) they segfault.

It's starting to really annoy me - so I'll give up. (It just becomes yet another challenge that I've failed.) Thankfully, I personally have no need for either Win32::API or Visual Studio.

Cheers,
Rob

Replies are listed 'Best First'.
Re^9: [OT - MS Visual Studio] How to build a dll that Win32::API can access
by BrowserUk (Patriarch) on May 25, 2008 at 09:04 UTC
      Try __cdecl

      Segfault.

      But ... if I want to specify either __stdcall (/Gz switch) or __cdecl (/Gd switch) am I supposed to first remove the __cdeclspec(dllexport) from the prototype and definition of the function ? I would assume that __cdeclspec(dllexport) implies the __cdecl convention anyway. So if the prototype and definition contain "__cdeclspec(dllexport)", then you're implying __cdecl when you build the dll with cl /LD double.c

      Cheers,
      Rob
        I supposed to first remove the __cdeclspec(dllexport) ...

        There's no such thing as __cdeclspec(dllexport). Just __declspec(dllexport).

        You can combine __cdecl with __declspec(dllexport) so:

        __declspec( dllexport ) int __cdecl test( int x ) { x *= 2; return x; }

        See exporting from a DLL.

        As for using __stdcall: I don't think that Win32::API ever attempted to cater for non-__cdecl function calls. It would have to set up the stack differently obviously, and to do that it would have to know how to detect what convention was being used by the DLL/entrypoint it was accessing, and I don't know of any way to do that.

        It could be written to try both. That is, if it attempt to obtain the entrypoint name with an underscore prefix, and succeeds, then set the stack up using the __cdecl conventions.

        If it fails with the underscore, then try without and if that succeeds use the __stdcall convention.

        However, there is also the __fastcall convention which (if memory serves) also omits the underscore, but uses yet another mix of register allocations, stacked parameters and caller cleanup vs. callee cleanup (I can't remember of the top of my head which uses which) conventions, so I don't know a way of making that determination. Or even if there is any way apart from knowing that certain well-known dlls use one convention and others use another?

        Sorry I cannot be more help. As I alluded to, despite having re-installed everything yesterday, I cannot even make stuff that I know used to work, work :( There is something being secreted away somewhere that is influencing this that I am just not aware of.


        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".
        In the absence of evidence, opinion is indistinguishable from prejudice.