Class as a DLL
-
Just read an article on using classes as a DLLs following the class a __declspec(dllimport/dllexport) is needed. I was just wondering how MFC does it. On my system the MFC code is located in MFC140.DLL now when I inherit a let’s say CDialog class I don’t specify __declspec(dllimport) Thanks
-
Just read an article on using classes as a DLLs following the class a __declspec(dllimport/dllexport) is needed. I was just wondering how MFC does it. On my system the MFC code is located in MFC140.DLL now when I inherit a let’s say CDialog class I don’t specify __declspec(dllimport) Thanks
ForNow wrote:
I don’t specify __declspec(dllimport)
No because that declaration will be in the header file. You should take a look at Creating and Using a Dynamic Link Library (C++)[^] for more information. Basically the project that creates the dll needs
__declspec(dllexport)and every application the wants to use it needs__declspec(dllimport). This is usually controlled by a #define in the header that goes with the dll. If you create a DLL project in Visual Studio and select the "Export Symbols" checkbox, you get the following in the header:// The following ifdef block is the standard way of creating macros which make exporting
// from a DLL simpler. All files within this DLL are compiled with the WIN32PROJECT2_EXPORTS
// symbol defined on the command line. This symbol should not be defined on any project
// that uses this DLL. This way any other project whose source files include this file see
// WIN32PROJECT2_API functions as being imported from a DLL, whereas this DLL sees symbols
// defined with this macro as being exported.
#ifdef WIN32PROJECT2_EXPORTS
#define WIN32PROJECT2_API __declspec(dllexport)
#else
#define WIN32PROJECT2_API __declspec(dllimport)
#endif// This class is exported from the Win32Project2.dll
class WIN32PROJECT2_API CWin32Project2 {
public:
CWin32Project2(void);
// TODO: add your methods here.
};extern WIN32PROJECT2_API int nWin32Project2;
WIN32PROJECT2_API int fnWin32Project2(void);
-
ForNow wrote:
I don’t specify __declspec(dllimport)
No because that declaration will be in the header file. You should take a look at Creating and Using a Dynamic Link Library (C++)[^] for more information. Basically the project that creates the dll needs
__declspec(dllexport)and every application the wants to use it needs__declspec(dllimport). This is usually controlled by a #define in the header that goes with the dll. If you create a DLL project in Visual Studio and select the "Export Symbols" checkbox, you get the following in the header:// The following ifdef block is the standard way of creating macros which make exporting
// from a DLL simpler. All files within this DLL are compiled with the WIN32PROJECT2_EXPORTS
// symbol defined on the command line. This symbol should not be defined on any project
// that uses this DLL. This way any other project whose source files include this file see
// WIN32PROJECT2_API functions as being imported from a DLL, whereas this DLL sees symbols
// defined with this macro as being exported.
#ifdef WIN32PROJECT2_EXPORTS
#define WIN32PROJECT2_API __declspec(dllexport)
#else
#define WIN32PROJECT2_API __declspec(dllimport)
#endif// This class is exported from the Win32Project2.dll
class WIN32PROJECT2_API CWin32Project2 {
public:
CWin32Project2(void);
// TODO: add your methods here.
};extern WIN32PROJECT2_API int nWin32Project2;
WIN32PROJECT2_API int fnWin32Project2(void);
-
Thanks I was just curious how MFC does it the code is in MFC140.DLL and I don’t see any __declspec(import) When I want to use CDialog Also I assume when I follow theses steps in my .dll I’ll create a .lib Thanks
-
The exported labels are not in the dll, as that means nothing to the compiler. They are in one of the header files somewhere in the MFC include folders. So if you find the definition of CDialog it will somehow be defined there.
-
FYI I did a dependency walker against MFC140.DLL and I got all the entry points N/A meaning without function names
Well they will be in there somewhere, but MFC/C++ names get mangled up and are not always easy to recognise. Be that as it may, if the entry points didn't exist then the dll would not be usable. I have not used MFC for many years so cannot actually check any of this. The key point is to ignore the dll and inspect the header files.
-
Just read an article on using classes as a DLLs following the class a __declspec(dllimport/dllexport) is needed. I was just wondering how MFC does it. On my system the MFC code is located in MFC140.DLL now when I inherit a let’s say CDialog class I don’t specify __declspec(dllimport) Thanks
just read about the [Extension DLLs | Microsoft Docs](https://docs.microsoft.com/en-us/cpp/build/extension-dlls)
-
FYI I did a dependency walker against MFC140.DLL and I got all the entry points N/A meaning without function names
Exporting from a DLL Using __declspec(dllexport)[^]
Many export directives, such as ordinals, NONAME, and PRIVATE, can be made only in a .def file, and there is no way to specify these attributes without a .def file. However, using __declspec(dllexport) in addition to using a .def file does not cause build errors.
It's a protection scheme they are exported as privates or ordinals probably so they can avoid ANSI, MBCS, and Unicode issues on the call name.
In vino veritas