I understand that is not possible to have applications with multiple entry points under Windows.
I have a MFC application and I added code for making it running as a service (main() entry point and other required stuff) but it looks that Windows will always run the WinMain() from MFC instead of my main.
The question is how can I disable the WinMain() from MFC in order to be able to run my own main().
Probably the same problem would apply if you want to run the same application as a console application.
What do I have to change in project properties in order to build it as a console application (main instead of WinMain)?
Is commenting my CWinApp the only solution?
If you look at the linker settings you can change the entry point. This is where you want to be looking.
Related
I have a project that consists of a DLL and a windows console application .exe.
The .exe calls the DLL. In the DLL I am creating a Dialog box.
AFX_MANAGE_STATE(AfxGetStaticModuleState());
MyDlg* dlg = new MyDlg;
dlg->Create(IDD_DIALOG1);
I had to add AFX_MANAGE_STATE(AfxGetStaticModuleState()) so it knew to look in the DLL for the resources. However this seems to be causing a problem when control is returned to the EXE.
When I "return 0" in the main() function of the EXE the console window does not go away. I have to physically close it in order for the EXE to stop running. If I remove AFX_MANAGE_STATE(AfxGetStaticModuleState()) from the DLL (along with all references to MyDlg since they won't work without it) everything works fine when control is passed back to the EXE.
Why would this be happening?
Fixed. My DLL is using DAO. I had to add AfxDaoTerm(); before exiting. Thank you
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 creating Win32 application and I have two projects.
The first one is a static library which contains _tWinMain() function, that is the entry point of a Win32 application.
The other one is an application which links this .lib. That way, the app doesn't have to create its own _tWinMain() function, because it's in the .lib file.
First, I build the static library. Then I build the application. The problem is that when I start debugging (F5), the window shows and then immediately closes (either in Debug or Release configuration). The problem doesn't occur when I start the program without debugging (Ctrl+F5) or just open the .exe file.
Is it possible to debug while having the entry point in a static library?
I think it should be possible. Did you try what happens when you start the application with F11 or F10 instead of F5? It will then start the application, but breaks directly at WinMain.
SOLVED:
I had a small bug in one of my functions (always remember to initialize variables ;) ). _tWinMain() quited because of that. Now everything works fine, with the entry point in static library as described above. Thanks everyone for help and sorry for bothering you :)
I have a CWinApp-based application that is built as a DLL that is loaded by another 3rd party application as a plugin. My app exposes an exported StartPlugin() method that creates a CDialog derived dialog. This exported function is somehow called by the 3rd party application. I'd like to be able to run my DLL outside of the 3rd party application so I can test and play around with UI stuff (not for unit testing).
How can I create a test harness that will allow me to run my dll code? I'm not sure how the main application launches my dll plugin, but I'm speculating that it's creating a User-Interface thread? So would I just need to create a simple exe that can somehow load my dll and create a new thread or something. Any links to tutorials or articles that explain something like this.
Use the Visual Studio wizard to create a MFC application, probably Dialog based. Have a button on the dialog to run your plugin. In the button code do a LoadLibrary with the name of your DLL, then call GetProcAddress to get a pointer to the StartPlugin function. Then you can call StartPlugin.
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)