I have an Win32 application with no window written in C.
My question is: is there any way to handle the termination of my application. Ex. closing it from the task manager or via the console.
It is unclear from the question, but if this is a console mode application then you can call SetConsoleCtrlHandler to install a callback that Windows will call just before it terminates your app. Beware that this callback runs on a separate thread and that you have to complete the callback function quickly.
If it is a native Windows program that just doesn't create a window then you really do need a window to get notifications like this. Which is not a problem, it doesn't have to be visible. Just don't call ShowWindow().
Note that atexit() as mentioned will not work, these are rude aborts you are talking about that don't let the program go through its normal shutdown sequence.
You might like to take a look at the atexit() function (http://msdn.microsoft.com/en-us/library/tze57ck3%28v=vs.100%29.aspx).
Using this function you can install handlers which are called when the program terminates.
Related
As the title suggest: Which functions of an application are called when it's killed by Windows 10, either by End Task in Task Manager or Terminate it in Settings? Or there's no function called at all and all the threads are killed immediately?
I'm working on a program in which lots of data are corrupted/destroyed when user terminates it, I want to reduce the risk of that so I really need your help, unfortunately Google doesn't provide much help in this matter. Thank you.
I'm writting a DLL in ANSI C and I'm using Curl to make HTTP connections.
This DLL should be able to connect to my server to send some info just before the application terminates. I would like to know what is the best approach to achieve this. I have tried registering a callback function using atexit and also calling the connectToServer method in a destructor. I also tried to use the DllMain with the DLL_PROCESS_DETACH. On all cases, Curl is unable to connect to server(error code 7) because windows already unloaded required libraries used by Curl.
I have heard people saying the only way to achieve this on Windows is to create a separate process(watchdog) to monitor when the main process terminates and then open the connection in this other process.
The library I'm writting works both on Linux (.so) and Windows (.dll). On Linux, i'm using atexit and everything works fine. I would prefer not to use a watchdog process since I won't use it on the .so.
Is there a way to do this?
Thanks in advance.
You shouldn't do anything in DLL_PROCESS_DETACH for exactly the reasons you've found. The best way to handle this is an explicit call from the application to say "I'm shutting down, do any clean up needed".
If you really want to mess up the semantics of DLL_PROCESS_DETACH, you could manually use LoadLibrary to load the curl library directly from there, regardless of the existing linker setup, and call it through your own late binding.
I am using C and GTK+ for a gui project. For my project I have to make a lot systems calls. e.g system("copy myfile urfile"); or system("mp3player -embed filename") etc. and whenever my program calls the system an annoying console window appears and stays visible until the command is completely carried out. How do I hide that console window? Thanks.
NOTE: For my project I can use GTK+ , the C Standard Library , GLib, WinApi (not recommended) and system calls.
SCREENSHOT:
Using system() to create a new process does this by first starting a new command interpreter, which then in turn executes the command passed to system().
The command interpreter opens the console window.
Thus to avoid opening such a console windows you need to avoid starting the command interpreter. To do the latter try a function out of the spawn family (http://msdn.microsoft.com/en-us/library/20y988d2.aspx) or use the win32 api function CreateProcess() (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425) to directly start your application.
A side effect on doing so might be, that your application starts faster and also uses less system resourses.
In fact the above mentioned solutions will not work for system calls which explicitly need a command interpreter as in one of your examples (copy src dst).
Use the GLib processes spawning functions instead of platform-specific functions. For file copy you can use g_file_copy from GIO (shipped with GTK) instead of calling the cp or copy command. This makes your code more portable too.
I have a WPF app that uses a non-WPF vendor library. My app does not receive any events that the library fires. I've been told that this is because I need a message pump.
In another (very similar) question, the accepted answer suggested using System.Windows.Threading.Dispatcher.Run().
When I add in that call, however, my window won't pop up-- the app is effectively backgrounded and I have to shut it down with Task Manager.
I'm really stumped here, and I'm not even sure how to investigate it. Any help would be greatly appreciated.
You already have one if you use WPF, there's no other way that it can get any Windows notifications. Every WPF app starts life with a call to Application.Run() on the main thread. It is usually well hidden, auto-generated in the bin\debug\app.g.cs source code file. Application.Run() in turn calls Dispatcher.Run()
Your vendor is correct, without a message loop many COM components go catatonic. But since you have one you need to look for the problem elsewhere. Don't use the component on threads.
Basically, I have two applications that run sequentially (second is started by the first, and the first exits immediately after.) I'd like to pass ownership of a window the first application created to the second application. The actual contents of the window don't need to be passed along, it's just being drawn in by DirectX.
Alternatively, but less desirably, is it possible to at least disable the window closing/opening animation, so it at least looks like the desired effect is achieved?
(This is in C, using the vanilla Win32 API.)
Instead of separated application make a DLL that will be loaded by the first application and run within it.
I suspect that you're going to run into problems because the WindowProc function is located in the memory address space of the program that you're closing.
Also, a quick look at the second remark at the bottom of the documentation for RegisterClass doesn't seem to offer up much hope.
The only work around that I can suggest for what you've described is to not close the first application until the second application is finished with the window in question.
you can use API hooking to make your DLL capture API windows calls sent by the application window and respond as if your DLL is the windows DLL
for more information about hooking check :
Hooks Overview