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

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.

There's no such thing as __cdeclspec(dllexport)

Ooops ... the strain is starting to show. I meant __declspec(dllexport) (as is written in the code I'm running).

I don't think that Win32::API ever attempted to cater for non-__cdecl function calls

Strange ... I recall it as being the other way round (in the early days, of Win32::API, at least). My recollection has it that you needed to use the __stdcall convention for Win32::API to work - and that catering for __cdecl is only a recent development. No matter ... as for you, nothing works for me any more, and I no longer have the box on which things did work - so I can't even see how it used to work.

Cheers,
Rob