Auto-Restart a Console Application - console-application

I am looking for the console application equivalent of Application.Restart() but cannot seem to find a way to do this.
It has been suggested by others to simply call my Sub Main with Args when I need to restart. However the reason I need the functionality to physically restart the application is because the first thing I do is check for updates and install them if they any are availible.
The update technique itself works perfectly, the system installs new updates but changes do not take effect until next time the application runs obviously.
As the application is run from a batch file as a scheduled task only once a week any updates I release would not take effect for two weeks!
I had the same problem with a windows forms application however the ability to call Application.Restart allows changes to take place imediately. Can the same be achieved when creating a console application?

2 Possibilities i can think of.
First one start another instance of the application and close the current one using something like
System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
and
Environment.Exit(int exitCode)
second if it's not possible to run 2 instances at the same time for some reasons u can create another application that gets started by the batch. Make it run your application and let it get an info if the updating process is done so it can first close the current application and then run another one

Related

Using wh_shell hook for custom windows-shell(explorer.exe replacement program) C++

So I have spent that past week and a half working on code to simply setup the hook procedure for wh_shell for a program that will replace explorer.exe in the registry and will run as the main desktop program. There seems to be very little information and sources for using this outside of just the windows API which is a bit undescriptive and doesn't explain everything to a great detail. For some reason I just cant get it to work, no matter if I run it inside of explorer.exe, or if I replace the register and make it the default shell. I'm going to ask a couple of things in this post because I think that if you can answer one of these questions you likely have the answer to more.
So first I just have a question about hooks in general: When I run the SetWindowsHookEx(...) function -resource below- it says for var lpfn that a dll is not necessary if the hook is only used to monitor the current process. Now obviously when monitoring events such as window_created, those are events within a different processes which makes me think that the hookproc has to be within a DLL(which is how ive programmed so far). But this is questionable to me because when u are running SetWindowsHookEx(...) the process I wish to monitor do not yet exist until the user decides to start them. Do these processes notify the system when wh_shell events are being done so that I my hook doesnt need to get placed into every process upon creation, or is it more like when I run SetWindowsHookEx(...) with wh_shell that it will place a hook in all processes when the are created. The second resource states that the system just calls the hookproc when these things happen, so then do I even need a DLL, or what process does it need to be hooked to because I dont think it needs to be hooked into everything.
So second I have a question regarding setting my process as default shell - see resources - the resource states any process that registers itself as the default shell(which I assume is just modifying the registry to my process, if not and there is more please let me know) needs to call the SystemsParameterInfo(...) function. So first, does this func need to be called before running SetWindowsHookEx(...) or is there some expected spot it should be elsewhere in my code? Then in regards to the other variables it doesnt specify for, just curious what the recommended would be to set them as, like what are they set as for explorer.exe, and maybe a few other examples(including things NOT to do).
Finally for the sake of testing, using the console will be the most helpful to me here. The console will be used for input to run functions and commands for now(like open the register and swap back the shell to explorer.exe). If my hookproc is within a DLL, I need it to output some messages, I dont want to muddle the same console and I also dont even know if it will output to the same console, so what might be a recommended or potential solution for outputs(again this is temporary and for testing so it doesnt have to be perfect or even great)?
Also I would think windows 11 shouldn't be an issue, but I havent tested on windows 10 system...
I havent included any code as Im pretty sure most of this stuff can be answered without it and that its so few lines of code that its not like typical questions where its like examine my code and help me, maybe some example code you can show me would be really helpful.
Thankyou!
SetWindowsHookEx(...)
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa
defaultShell
https://learn.microsoft.com/en-us/windows/win32/winmsg/about-hooks#wh_shell
regards to WH_SHELL section
Testing Environment:
Windows 11 vm running in Hyper-V Manager
You haven't mentioned an important parameter in your description and that is the last argument of SetWindowsHookEx, the thread id.
When it is set to 0 then ..
'[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.'
That said, then like everything in Windows programming nothing is as what the documentation states, its as if the documentation is a wish-list Microsoft will like Windows to be when it grows up.
Actually even if you manage to get everything right you will see that the shell messages you will get will be VERY few compared to what the documentation states.
I am working on the same issue and when I get it going I will post the results here.

Blocking processes to start on startup from a service & continue running service after some processes are down.

I have a C++ windows service running on system privileges and I need to make some changes in some of my DLLs that are loaded to several windows processes (explorer.exe, etc.).
The only time to do so is when these processes are down. I'm trying to make to impact to the UX minimal, so I don't wan't to force quit those or to popup any annoying message boxes and ask the user to do so.
I have tried to start this task on the startup of my service, the issue is several of these processes start before I finished it.
I'm trying to understand if there is a way to delay the start of processes on Windows startup, until I finish my task. Is there any event or anything familiar that I can set that will block those?
The other option is to do the needed task on shutdown. I did not find a way to do so yet, and all the related questions seem a bit old (how to delay shutdown and run a process in window service
), and regard to older version of windows.
This solution needs to be compatible with Windows versions greater than 7.
You can do this by using MoveFileEx and setting MOVEFILE_DELAY_UNTIL_REBOOT which will replace the file at the next reboot.
This should be well before any other processes have started, but without more details on your usecase its hard to tell if this'll work for you. Either way, searching for this flag should give you lots of information about this kind of issue.
According to the documentation, this has been supported since XP.

Can an application run the code of another application?

Hi,
I'm relatively new to C++ and WinAPI. So far I've managed to create an application, that is using the CreateProcess function and a STARTUPINFO structure to create a new desktop, launch inside that new desktop a new explorer.exe process and switch to it.
Next, because I wanted to be able to switch at any time between these two desktops, at a press of a key (LCTRL in my case), I've made another application that uses the SetWindowsHookEx function to create a global hook for the keyboard.
Because the hook is active only in the calling destkop, in the first app, using CreateProcess, before creating the explorer.exe process and switching to the new desktop, i've launched the executable of the second app twice: once in the current desktop and once in the new one.
Everything is working fine, I'm able to make the switch between desktops at any time, but now I've been asked to do something about the structure of the processes launched, somehow, to make the seconds app code run inside the first one, without creating a new process. Because this is my first post, I can't upload a snippet of the process tree, but the procexp application from live.systernals is showing the following structure:
---FirstApp.exe:
-------------SecondApp.exe (original desktop)
-------------explorer.exe (new desktop)
-------------SecondApp.exe (new desktop)
So basically, my question is: can I make the code of the application that hooks the keyboard run in the same thread as the FirstApp? This implementation, an app that starts these three processes, and the second app that hooks the keyboard, was my idea (I was not requested to do it this way, I was only asked to create a new desktop and switch between them), so I am open to suggestions towards making a better implementation for this problem too.
It could be possible since there is little difference between a DLL and an EXE on Windows, so I think you could try to export the routines from SecondApp and then import them in FirstApp with LoadLibrary.
But IMHO the clean way to do that is to break SecondApp in two pieces : a DLL containing code that actually does the job and an EXE that would be a simple frontend calling routines from the DLL.
That way, it will be trivial (and portable across different versions of Windows and SDK) to call the routines of the DLL from FirstApp.

Transparent UI / hidden UI after BringToForeground

I am programming in C++ using Qt (on Windows), I have a GUI application that can be run on the command line so that users can schedule it to be run using Scheduled Tasks.
Everything was working fine (I think), except when a user tried to schedule the task with the "run when user is logged on or not" option is checked. In this instance the application would run fine, but not pop up the GUI.
I thought maybe my problem was similar to this: https://serverfault.com/questions/101671/scheduled-tasks-w-gui-issue
I thought I found the issue because my GetProcID call was returning a list of ProcessId's and I was only using the first one it returned, which caused some issues. That process ID was then passed to BringToForeground.
After this change it now brings up a transparent, or non-existent other than the application icon on some machines (basically every test except my 3 machines that can debug). Works exactly as required on my test machines.
The application works well if the GUI app is already running and you make the same call on the command line (it passes the call to that process to run). The app also works fine in normal UI mode, (no command line params passed)
EDIT:
Does anyone have any ideas what might cause this? I am thinking it has something to do with the app not starting on the correct Desktop, but don't have a ton of experience with those and have no idea where to even begin.
EDIT 2: Only seem to have the issue when it is run remotely, or through virtualization. (still confirming if this is truly the case)

watchdog in vc++ application

I have written a simple vc++ background application. What am trying is like a watchdog service that could monitor if the application is running or not. If the application crashed then the service should start the application
For creating a setup through windows installer am using only the app.exe and app.dll.
Is that possible to create this watchdog - service in the exe itself ?
Unfortunately I have no idea of how to write such a program, does anyone have some example code that would demonstrate this technique please?
if so then how to make the default exe and watchdog exe as a single application to install ?
Your best route would be to create a separate service to act as the watchdog. Technically, it's possible to have the service and the "real application" in the same executable. You can differentiate between the two depending on how the exe has been started, but it will make maintenance quite difficult.
This article might be of interest.
Here - http://yadi.sk/d/EtzBRSMi3FqVH - is my implementation of WatchDog app, working in systray. Do not mind that it's written with Qt - the main functionality is with WinAPI.
This app is watching in processes list for several processes and restarts them if can't find. The second feature is that it monitors all windows in system for suspicious window title (for ex. "'My Great App' causes a system error and will be closed. Send message to developers ?") and, if find, restarts them too
P.S. I didn't i18n it, but I think there will no troubles )
Update: (according to #CodyGray comment)
Here's pastebin's links: WatchDog.cpp and WatchDog.h
Such a watchdog can be set up to, for example, write to a file every minute (or whatever). If the file hasn't been updated in two or more minutes then there is most likely a deadlock in the application and it has to be restarted.