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.