What is the difference between creating a MFC DLL from Visual Studio wizard and creating C++ Console Application and changing the configuration type to DLL instead of .exe?
You can surely figure out how to change a console application to dll type, but it's recommended to use the non-MFC DLL project template.
One major difference between a non-MFC and a MFC Extension DLL is that it would allow sharing resources like dialog templates or bitmaps to MFC appliactions by calling
// MFC extension DLL one-time initialization
AfxInitExtensionModule(PROJNAMEDLL, hInstance);
// Insert this DLL into the resource chain
new CDynLinkLibrary(Dll3DLL);
in DllMain(). Other benefits are that you can use MFC (CObject-derived) classes that sit in the dll and that the MFC Extension DLL can share the memory address space with the calling instance, meaning that two apps loading the same extension DLL will only share the code but won't interfere with allocated data.
Note that you need the "shared MFC DLL" project setting to use extension DLLs. Linking MFC statically into your project won't work. So extension DLLs aim at sharing code among different apps that run simultaneously, for example, but only use the code memory once. This way of code reuse was one intention at least when extension DLLs were introduced, but in the real world different apps tend to use different versions (dll hell, side-by-side). Speaking of:
One good use of an extension DLL is to customize an app (branding, localisation) just by installing differend versions of a dll.
Further reading: https://learn.microsoft.com/en-us/cpp/build/extension-dlls
According to Creating an MFC DLL Project it states:
An MFC DLL is a binary file that acts as a shared library of functions that can be used simultaneously by multiple applications. The easiest way to create an MFC DLL project is to use the MFC DLL Wizard.
This article Kinds of DLLs also states:
Using Visual Studio, you can build Win32 DLLs in C or C++ that do not
use the Microsoft Foundation Class (MFC) library. You can create a
non-MFC DLL project with the Win32 Application Wizard.
The MFC library itself is available, in either static link libraries
or in a number of DLLs, with the MFC DLL Wizard. If your DLL is using
MFC, Visual Studio supports three different DLL development scenarios ...
I believe the above explains the difference:
One version of the DLL exposes the MFC library.
One version does not.
That is my understanding.
Other related article: Create C/C++ DLLs in Visual Studio
An MFC DLL is a dynamic library that uses MFC components and the MFC runtime. This means that an MFC dynamic library usually requires the MFC support libraries along with the MFC runtime. To compile an MFC DLL requires the MFC include files and the MFC directives.
When you use the Visual Studio Wizard to create an MFC DLL all the compiler, linker, and other settings and options needed to create an MFC DLL are all generated for you along with an MFC DLL stub.
A Console Application is an application that uses the C++ Runtime from a console window.
When you use the Visual Studio Wizard to create a Console Application all the compiler, linker, and other settings and options to create a Console Application are all generated for you with a Console Application stub which is typically a Hello World type of application with a main() that contains a printf().
The source code for a DLL has required structure for a DLL main entry point that is different from the required structure for a Console Application main entry point. See the Microsoft article DllMain entry point which has this example source code:
BOOL WINAPI DllMain(
HINSTANCE hinstDLL, // handle to DLL module
DWORD fdwReason, // reason for calling function
LPVOID lpReserved ) // reserved
{
// Perform actions based on the reason for calling.
switch( fdwReason )
{
case DLL_PROCESS_ATTACH:
// Initialize once for each new process.
// Return FALSE to fail DLL load.
break;
case DLL_THREAD_ATTACH:
// Do thread-specific initialization.
break;
case DLL_THREAD_DETACH:
// Do thread-specific cleanup.
break;
case DLL_PROCESS_DETACH:
// Perform any necessary cleanup.
break;
}
return TRUE; // Successful DLL_PROCESS_ATTACH.
}
So the differences between an MFC DLL and a Console Application involves a number of areas:
the structure of the source code
the include files used in the compile
the libraries used in the link
the options used in the compile
the options used in the link
Changing the configuration type does not modify the source code or include files specified in the source code. Nor does changing the configuration type change all of the necessary compiler and linker options and property settings that need to be changed.
See this Microsoft article, DLLs and Visual C++ run-time library behavior, that discusses the structure of DLLs and their run time behavior which provides an idea as to the differences between an EXE and a DLL.
An Application (executable) is a module that can be run. It contains one entrypoint, the main() (console) or WinMain() (windows GUI) function. A running instance of an executable is called a "process" in Win32.
A DLL is a library, intended for use by other applications. It is loaded at runtime - "dynamically", hence the name. DLLs contain no main entrypoint, instead they "export" functions or even classes and data. Lacking a main entrypoint, DLLs cannot be run stand-alone, instead they are "loaded into a process's (application's) address-space". The process can use their exported items. It is a good way to implement commonly used operations, for example a company's "development environment" or "foundation" - SDKs are typically implemented as DLLs.
MFC is a C++ library containing GUI (and other) classes and functions, largely (but not exclusively) wrapping Win32 objects. An application or DLL can be using the MFC library, or not.
As for your question, creating a console application and then changing it to DLL makes no sense. The Wizard will create a main() function, which you will have to manually remove. And finally you will have what, a normal DLL... You can simply create a DLL from the start, whether it will be using MFC or not.
EDIT:
According to the documentation from Microsoft:
Each process provides the resources needed to execute a program. A process has a virtual address space, executable code, open handles to system objects, a security context, a unique process identifier, environment variables, a priority class, minimum and maximum working set sizes, and at least one thread of execution. Each process is started with a single thread, often called the primary thread, but can create additional threads from any of its threads.
So yes, processes need to contain at least one thread - terminating the primary thread also terminates the process. Furthermore, an executable must contain an entry point, it's what the primary thread will execute and return a value to the system. It's actually impossible to build an executable without a main()/WinMain() function, it will generate Linker Error LNK1561:
entry point must be defined
The linker did not find an entry point, the initial function to call in your executable. By default, the linker looks for a main or wmain function for a console app, a WinMain or wWinMain function for a Windows app, or DllMain for a DLL that requires initialization. You can specify another function by using the /ENTRY linker option.
As for DLLs, the term dynamic "linking" is indeed used by MS, however only to highlight the differences to static linking (what most developers consider linking). It's not linking in the usual way, ie resolving externals, changing symbol names to addresses, performing fixups and the like. A DLL has no unresolved externals and the so called "linking" means just locating exported items from the loaded DLLs (in the case of using an import library they are also assigned to local functions) - the linker is not involved in the procedure. Further information here.
Therefore I don't think that there was something "slightly wrong" in what I had posted above, and certainly not "literally everything".
As for whether my answer should be considered useful or not, I think I was right to suggest not creating an executable and changing it to a dll. An MFC DLL is a DLL "based on" (using) the MFC library - this was clear in my first post. The OP didn't ask about MFC extension DLLs particularly.
I have an MFC .exe application, and I created another project for a DLL with MFC dynamically linked to it.
Now, when I import that DLL through LoadLibrary, it crashes my application, because when the importing is done, the DLL calls AfxWinInit().
Should the DLL call AfxWinInit()? How do I avoid it? Or is something else wrong?
In your MFC application WinMain() calls AfxWinMain(). The AfxWinInit() is called at the beginning of AfxWinMain(). So the initialization is done by framework for you. There is no need to initialize it again.
MFC DLLs provide their own entry point, so you're not supposed to write one yourself. If you plan to write a DLL with MFC support, I'd suggest you start with a fresh MFC DLL created by the app wizard and then move your code there.
For MFC applications that load extension DLLs, use AfxLoadLibrary instead of LoadLibrary.
I'm working on a keylogger. Here I found an implementation that loads current keyboard in runtime. The problem is that no keyboard libraries from win8 or win7 are loaded correctly. But I managed to find one US keyboard library that works fine.
So, now, I would like to add that library to resources and to use it when I'm loading keyboard.
My question is, how do I navigate to that resource dll when calling LoadLibrary()?
If you really want an exe instead of installer, you can bundle a dll as resource. ReadResource and write it to file disk(some temp path, such as appdata\local\temp); and then runtime load it, here is the link about runtime load library; Finally you need to delete it.
I got one challenging task here.
We got one Dialog in exe file (made of C++), and now we want it to be an ActiveX control, so it could be loaded in C# .net form, However because of the complicated web of c++ header file, it's hard to pick up files to make a separate ActiveX dll.
So is that possible to export an activeX control from the exe file?
Thanks in advance.
An ActiveX control is a nothing more than a DLL. Yes it is possible to export an activeX control from an exe file. A typical scenario is to put an Image (your ActiveX control) as a Resource of another application and to extract it at runtime. Here one of the many available samples on the web.
I have created a context menu dll (C++ COM DLL) to show iconoverlays (using IShellIconOverlayIdentifier interface). To show the iconoverlays initially I have restarted the explorer. If the system restarts, to display the icon overlays, I need to manually register the dll and restart the explorer once again.
Is there any way to register my com dll before explorer starts. ??
Also, if I uninstall my application the DLL can not be removed. To remove the dll, I need to stop the explorer and other applications (For eg, thunderbird, visual studio) which use my dll, then unregister the dll. Then only I am able to delete the Dll. Is this correct.. Or any thing else I can do.
Thanks in Advance.
I wonder why you have to register your DLL on every restart of your system.
On the other hand it is quite normal that you have to restart explorer.exe and related programs to let the changes - especially done by shell extensions - take effect.
Further, the beahivour you encounter upon deletion is the standard procedure one has to go through when you want to delete your shell extension DLL.
You may want to use self-registrating DLLs. They include information required to store themselves in the operating system's registry and will automatically store themselves on your machine and become accessible when needed.
A detailed explanation can be found here : Self-Registration (COM)