can I mix __cdecl export calls with __stdcall import calls in a DLL?

I am writing a module for a third party application; the application uses __cdecl calling convention.

At the same time, I have a legacy DLL which uses __stdcall calling convention.

Can I create a wrapper that in one end exports __cdecl functions, while in the other end imports __stdcall functions? which other options do I have?

Thanks,

EDIT:

Here is some extra information that my help clarify my situation.

There is a third_party.exe that need to gain access to skeleton.dll. The source code skeleton.dll contains the header file below and compiles using __cdecl.

#ifdef _EXPORTING
  #define DECLSPEC    __declspec(dllexport)
#else
   #define DECLSPEC    __declspec(dllimport)
#endif

#ifdef __cplusplus
   extern "C" {  
#endif

DECLSPEC int ICD_Create(char* id);
...
...
...

Ideally, I would use the skeleton source code to develop my DLL; unfortunately, it would be too time consuming to port my current VB6 legacy code into C++. Given this, I had to hack my VB6 code by following this guideline (It is a work around, but it allows me to use an ActiveX DLL as a standard C DLL).

I am not 100% confident of the modified VB6 calling convention, nor how to modify it. The exercises use __stdcall, and there seem to work fine with a test application I developed. However, when I test it with the third party application, it calls properly certain functions but in other开发者_开发百科 functions it crashes.

The architecture would look like:

Application: ThirdParty.exe (out of your control: Uses __cdecl) 
     |
     |
Plugin module: Skeleton.dll (your code)
     |
     |
Legacy DLL: ModifiedVB6.dll (out of your control: Seem to work with __stdcall)

The legacy DLL generates a dll, lib and def file; No header file.

---

The DLL will typically come with a header file (.h) and an associated import library (.lib) that deal with the calling conventions, exported function prototypes etc.

Simply include the header file, link to the import library, and you will be able to call the functions directly.

That header file will specify that the functions use the __stdcall calling convention. You most definitely do not, and should not, write a separate wrapper DLL. That would be adding a completely gratuitous layer of complexity.

---

Having re-read your question, and your comment, I believe that you have the following architecture:

Application (out of your control)
     |
     |
Plugin module (your code)
     |
     |
Legacy DLL (out of your control)

The legacy DLL exports its function using __stdcall. The application imports function from the plugin using __cdecl.

If that synopsis is correct then of course you must import from the legacy DLL using __stdcall and export to the application using __cdecl. Since those parts of the interface are outside your control you have no option.

However, I am finding the question and comments very hard to follow. Perhaps I have not fully understood. Feel free to add more information to clarify in an edit to the question.

---

Following the update I suspect that your problems are all concerning how to interface the VB6 legacy DLL with your C++ DLL. Since you don't have a header file (.h) for the VB6 DLL you are presumably writing your own translations.

If I recall correctly, VB6 only supports __stdcall which is what you are currently using. Your problems are therefore most likely to be due to erroneous translations of the exported VB functions into C++ prototypes.

I think your best course of action is to focus on getting these prototype translations correct. Perhaps you could consider doing that in the context of a separate standalone test project to avoid the complexity of the full application.

If you want further help from Stack Overflow I think you will need to supply the VB6 function declarations and your attempted translations, but I think that would be the subject of new question(s).

---

__declspec(dllexport) is only needed to tell the compiler to export the identifier from the DLL. This has nothing to do with the calling convention of a function you define (and possibly) export, or that of a function you import. That should be specified separately, and __stdcall is fine (but note that vararg functions must be __cdecl, since the caller must clean up the stack).

Yes, you could wrap your DLL with another DLL that imports it and exports functions that have __cdecl calling convention, but it might confuse users of the DLL. I would not do this, but it is possible.