I have a win32 DLL that includes Windows.h and makes use of the windows API. I want to load this DLL into an application that uses MFC.
Will this cause any memory leaks or strange behavior? or is it safe?
MFC is implemented on top of the Windows API. An MFC application can call into the Windows API without any restrictions. It is, however, not possible (nor required) to #include <windows.h> prior to including afxwin.h. If you do, afxv_w32.h will error out with the following message:
WINDOWS.H already included. MFC apps must not #include <windows.h>
The reason behind this is not a compatibility issue. It is due to the fact, that MFC has to set up several preprocessor symbols to control certain aspects of the compilation process. Those symbols must be defined prior to including windows.h (which afxv_w32.h eventually does include).
Likewise, there are no problems associated with linking against a .dll that is implemented using the Windows API. In fact, a default MFC application already links against a number of Windows API libraries, like kernel32.dll and user32.dll. If the header file declaring the .dll exports includes windows.h you need to make sure that it is included after afxwin.h. Otherwise the preprocessor will error out with the message quoted above.
Related
I was experimenting with DLL injection via CreateRemoteThread() (see my other question for details). I injected it into CMD.exe process (note, not the conhost.exe process). The thing is, I noticed that it actually loads 8 other Windows DLLs along with it. It loads them even if I never use any functions from those DLLs.
Now I wonder, is there a way to prevent this? My only guess for now is to not include <windows.h>, then copy definitions for most macros and load libraries that are actually needed via calls to LoadLibrary(). Yet, I guess, it's not the most elegant solution.
Maybe there is some well established method of preventing standard satellite DLL loads?
An option for cases where you only occasionally rely on a particular library is to treat it as delay-loaded.
In Visual Studio, this setting is found in the project properties window under Linker -> Input.
So, for example, if you expect to only sometimes call something from user32.dll you could add "user32.dll" to the Delay Loaded DLLs line (note that this does take .dll not .lib as for input libraries).
I'm working on a cross-platform c++/qt project with a plugin system, we are using so files on linux and dll on windows. We are using gcc on Linux and Visual Studio 2010 on Windows through cmake.
The problem is our plugins sometimes need to call a function from the application source code, which is working fine on Linux with gcc by just including the header files. But on Visual Studio, we got unresolved external symbol errors.
Is it because so and dll files works differently?
thank you.
The default behaviour for exporting symbols from dlls on Windows is exactly opposite: by default, symbols are invisible, you need to export them explicitly. With VC++ this is done by __declspec(dllexport) declarators.
EDIT (Information added): You are entering a region of non-standardized, system specific behaviour... There are much more problems associated with writing cross-platform "pluggable" component systems in C++ than you might be expecting. On Windows there are so called import libraries, which define all symbols exported from a dll. You have to link against these libraries in order to resolve these symbols. This is called implicit linking. You can also link explicitly which means loading dll and its exported symbols at run-time. However all these are just technical details compared to so called binary compatibility issues, which will almost certainly kill you, if not considered during the design of your component system.
I am wondering about one thing: You said you're using Qt. Qt application framework has got it's own cross platform conventions and rules for writing and building pluggable components. Why don't you stick with these...?
I have a Qt project and would like to use an external library that includes "afxstr.h".
Problem is that whenever I compile after linking to the lib and including their header, I get an error:
#error afxstr.h can only be used in MFC projects. Use atlstr.h
Of course, my project is not an MFC project and I can't use atlstr.h instead because it's not my library.
I'm looking for a quick solution!
I'm using VS2010.
The lib in question is the Interactive Brokers API.
The respective setting is Configuration Properties/ General, Use of MFC.
The compiler option implied from that is /D "_AFXDLL" when using MFC in a DLL.
As for linker options, curiously the explicit linking of windows import libraries (such as kernel32.lib) get removed.
Visual Studio seems to find the respective libraries automatically. However, the "Use of MFC" option is stored with the project file, so I can't say how it would translates to a custom build script.
The first include must be
#include <afx.h>
and you cannot include windows.h before that. Typically, that's the first include in stdafx.h if you use precompiled headers. Other than that, other MFC headers can be included freely as needed.
I doubt that this is the end of the story, getting MFC to play with anything is painful, and sometimes it's easier to give up :) A quick google reveals that there are solutions, but they involve additional code and are rather old.
well, you have already know this, just make it more clear:
.pro file add:
DEFINES += IB_USE_STD_STRING
avoid use MFC CString
I don't know how to do the following:
I'm using MS Visual C++ 6.0
I have a Win32 DLL project which is compilable.
I have another project, this time a Win32 Console project which uses
the DLL by including it's header file and linking the .lib file of
the DLL.
Now I want to have another project, similar to the second BUT without using the header file and the lib file.
Is that possible? Everywhere I read you need either dll+lib+h or dll+h. If thought if you know the interfaces, a DLL file is sufficient?
Btw, by "using a DLL" I mean, using the Classes and Functions defined in the DLL.
It is possible if you just have plain "extern C" functions. If this is the case the approach could be loading the dll with LoadLibrary, and then import each function with GetProcAddress, of course you need to know the function signature to create a properly declared function pointer. Using classes per contrary is almost impossible.
If your DLL contains classes, there are good chances that it is a COM component.
If this is the case, the #import directive (that you use like #include) builds some temporary include files containing the interface details. You should use COM to access your objects.
Otherwise, if you have a 'plain' DLL with C++ classes, you could access the exported symbols using linker: instruct it to dump the map (see here), to know the mangled names. But I don't think that's possible to build manually the interface...
I'm in the process of porting a large C++ application from Linux (gcc) to Windows (Visual C++ 2008) and am having linker issues with plugins. On Linux this wasn't an issue, as .so supports runtime symbol lookup, but dll does not seem to support this.
Some background information:
The application (the host), which hosts a scripting environment, provides interfaces to plugins (shared libraries that are loaded at runtime by script API calls), allowing the host and the scripting API to be extended without recompiling the host application. On Linux this is just a matter of including the host application's headers in the plugin source, but on Windows I'm receiving linker errors. I'm not sure exactly what I need to link with for Visual C++ to resolve these symbols.
One of our dependencies (open source, LGPL) has preprocessor declarations that it uses to insert __declspec(dllexport) and __declspec(dllimport) into it's headers. Some prior research indicates that I may have to do this as well, but I'd like to be sure before I go modifying a whole bunch of core headers. (I was previously able to get this working on MinGW, but we've decided that supporting Visual Studio is a requirement for this sort of commercial project.)
My question, in a nutshell: How do I link runtime-loaded dlls against a host exe in Visual C++?
Edit: To clarify the problem with an example, I have a class in my host application, Object, which represents the base type of an object that may be accessed by a script. In my plugins I have a number of classes which extend Object to perform other functions, such as integrating networking support or new visual elements. This means that my dll must link with symbols in the host exe, and I am not sure how to do that.
What do you mean by "runtime symbol lookup"? Do you mean dynamically loading libraries using dlopen and dlsym and so on? The equivalents in Windows are called LoadLibrary and GetProcAddress.
In windows, you don't export symbols from a executable. You should only export them from a dll. The right way to solve your problem is to rearchitect so that the exported symbols are in a dll that the executable and other plugin dlls can link against.
You can't, easily. The windows loader isn't designed to export symbols out of an EXE and bind them to symbols in a DLL.
One pattern that I have seen is the DLL export a certain function that the EXE calls. It takes as a parameter a structure which contains addresses of functions in the EXE for the DLL to call.
I have been implementing the same, constructing a plugin library to build under both Linux and Windows.
The solution under Linux is to use the -rdynamic option in the gcc command line. This exports all of the symbols in the main executable, so that a plugin can find them on loading.
Under Windows, the solution is to add __declspec(dllexport) in front of the definition of those functions in the exe that you want the dlls to use. Compilation will create a .lib file for the dlls to link to. Certainly works under Visual studio 2008.
Related post: https://stackoverflow.com/a/3756083/1486836
As 1800 INFORMATION says, don't do it like that. Move Object out of the executable and into a "third" DLL. Link the plugins and the executable against that.