Using a regular dll with shared mfc dll - visual-c++

I have a regular dll with shared mfc dll. it was built on vc++ 6.0. I want to use it in vc++ 2008 windows form application.it has a header file, a lib and a dll.
I am adding some lines of the said header files
#ifdef DLLBUILD
#define DLLFUNC extern "C" __declspec(dllexport) WINAPI
#else
#define DLLFUNC extern "C" __declspec(dllimport) WINAPI
#endif
DLLFUNC int SC06StepInit(void)
When I add this header it shows multiple errors of same type
error C2144: syntax error : 'int' should be preceded by ';'
error
C4430: missing type specifier - int assumed. Note: C++ does not
support default-int
error start from line DLLFUNC int SC06StepInit(void) to all lines started with the same name DLLFUNC. I have no idea of starting any function with a name than return type and than again a name.
The source code of this dll also had all the functions in the same manner.
I want to know. What is this way of defining a function is called and to use such libraries.

Try this:
#ifdef DLLBUILD
#define DLLFUNC extern "C" __declspec(dllexport)
#else
#define DLLFUNC extern "C" __declspec(dllimport)
#endif
DLLFUNC int SC06StepInit(void);
You are trying too much in a macro:
extern "C"
DLL import/export attribute
WINAPI specification
Limit it. Find out how you should export the function, and who the client of your DLL are.

Related

Unresolved external when linking C++ Builder dll into MSVC C++ Project

I am trying to use a C++Builder 11.1.5 created DLL in MSVC 2022 C++ project. Both are 32bit. I can't build the DLL in MSVC as it uses some VCL objects.
My C++ Builder defines the external function thus:
extern "C" __declspec(dllexport) void __stdcall SetEnabled(bool val) {
...
}
MSVC uses a header to reference the function:
extern "C" __declspec(dllimport) void __stdcall SetEnabled(bool val) ;
I have created a .DEF file with the same name as the DLL, containing this:
LIBRARY MYTESTDLL
EXPORTS
SetEnabled
And I have generated a .LIB file from this .DEF file using MS lib.exe:
lib.exe /DEF:MYTESTDLL.def /out:MYTESTDLL.lib /MACHINE:x86
Finally, I have added MYTESTDLL.lib to my MSVC project in the Linker->Additional Dependencies section.
But, when I build the program, I get this error:
Error LNK2019 unresolved external symbol __imp__SetEnabled#4 referenced in function _WinMain#16
I've tried adding the ordinal (#4) to my .DEF file and rebuilding the .LIB file, but I still get the same error.
In a hex editor, I can that __imp__SetEnabled is in the .LIB file, but clearly not in a way that MSVC likes.
Have I missed a step somewhere? Is there anything obviously wrong with what I've done?
Changing the MSVC header used to reference the function to:
extern "C" __declspec(dllimport) void SetEnabled(bool val) ;
and adjusting the C++Builder DLL to export the functions using __cdecl resolved the issue. I didn't realize that the __stdcall exported functions need decorating in .DEF file.
That said, I find that the DLL is fine unless I try to execute code in it that uses the VCL. Then things don't work properly. I wonder if it's not possible to write a DLL in C++Builder containing VCL code for use in MSVC?

Cross platform dynamic libraries in "C" (Microsoft and gcc)

Ultimately I want to end up with a single set of source files that compiles to a Windows or Linux dynamic library depending on which platform compiled it.
The problem seems to be that Windows requires that annotations be made to both the header file declarations and the source file definitions. DLL Tutorial For Beginners
Linux dynamic link libraries seem to require annotations only in the source file definitions.
I can #define a preprocessor string to handle the difference of the source code definitions.
#if (_MSC_VER >= 1900) // (Visual Studio 2015 version 14.0)
#define EXPORTED __declspec(dllexport)
#else
#define EXPORTED __attribute__((visibility("default")))
#endif
Both Windows and Linux ignore empty #define statements.
You may not use annotations in Windows. You can use DEF file for declare export functions .def files C/C++ DLLs
For linux you need to use annotations, e.g.:
int
#ifdef __GNUC__
__attribute__((visibility("default")))
#endif
myfunction(int param) {
return 0;
}
This solves the problem that Windows requires functions
in the DLL header and the DLL source file be annotated
and Linux requires only the LIB source functions to be
annotated. Both Windows and Linux ignore empty #define
statements.
//
// Dynamic Link Library for Linux and Windows
//
// If not >= Visual Studio 2015 (version 14.0) then
// Linux is assumed
//
// This file is inlcluded in all of the LIB/DLL Source
// and the LIB/DLL caller.
//
#if (_MSC_VER >= 1900) // (Visual Studio 2015 version 14.0)
// Windows Function Definition (LIB/DLL Source)
#define EXPORTED_DEF __declspec(dllexport)
// DLL_EXPORT is defined at top of LIB/DLL Source of exported functions
#if defined DLL_EXPORT
// Windows Function Declaration (DLL Header)
#define EXPORTED_DEC __declspec(dllexport) // DLL Export
#else
// Windows Function Declaration (Caller Header)
#define EXPORTED_DEC __declspec(dllimport) // DLL Import
#endif
#else
// Linux Function definition (LIB/DLL Source)
#define EXPORTED_DEF __attribute__((visibility("default")))
#define EXPORTED_DEC // Linux cannot see this
#endif

#define new DEBUG_NEW in stdafx.h

I've noticed that several of our projects do the whole
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
thing in their stdafx.h.
Will this memory leak detection work as intended when specified in the stdafx?
Don't put it in stdafx.h. Doing so can give you undesired side effects.
Here's why.
In most cpp files, you have something like this:
#include "stdafx.h"
#include <AcmeHeader.h>
#include "MyHeader.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
Note that the redefinition of new is explicitly supposed to happen after all headers are included. If you define DEBUG_NEW in stdafx.h, then that definition will also be applied to AcmeHeader.h and MyHeader.h, which can cause problems with headers that try to redefine operator new.
I've also run into cases where I've wanted to remove the redefinition of "new" for just one or two files, but that's a rare situation.

What is a keyword to dynamic library export / import in linux?

I'm developing a chat server.
this is my source.
#if defined(_WIN32) || defined(_WIN64)
#ifdef PENGCHAT3SERVERLIB_EXPORTS
#define PENGCHAT3SERVER_API __declspec(dllexport)
#else
#define PENGCHAT3SERVER_API __declspec(dllimport)
#endif
#elif defined(__unix) // is this right?
#define PENGCHAT3SERVER_API //....?????
#endif
I have two questions.
first, defined(__unix) is ok?
second, what is keyword dynamic library export / import in linux?
I'm very wondering.
Please help me
thanks.
If you're building on Linux, there is no need for a specifier or special measures; all function symbols are exported by default.
#define PENGCHAT3SERVER_API
You want to look for the __unix__ (preferred) or unix defines, but you should consider making it the default instead.

Problems with Defining exports

I am trying to build a Dynamic DLL in VC++ 2008, now in a .h file, I declare the following
#ifndef PREFILTER_LIBRARY_H
#define PREFILTER_LIBRARY_H
#ifdef PREFILTER_EXPORTS
# define PREFILTER_API __declspec(dllexport)
#else
# define PREFILTER_API __declspec(dllimport)
#endif
#endif
While in the PreFilter.h file I am writing
class PREFILTER_API PreFilter
{
...
};
The problem is I keep getting:
warning C4273: 'PreFilter::Apply' : inconsistent dll linkage
I see that the dllexport part of the above macros is not highlighted and is commented which should have been the other way around, plus I have another .h file that contains Apply() method.
Can't figure out what I am doing wrong here. I am trying to export the functions of PreFilter.h
Add PREFILTER_EXPORTS to the list of preprocessor constants in Dll project settings: Project - Properties - Configuration Properties - C++ - Preprocessor - Preprocessor definitions.
When this file is used in Dll project, PREFILTER_EXPORTS is defined in the project, and PREFILTER_API is expanded as __declspec(dllexport). In any other project, where PREFILTER_EXPORTS is not defined, PREFILTER_API is expanded as __declspec(dllimport).

Resources