I have run into a case where a Windows Form application is being run regularly via a scheduled task on a Windows Server 2003 box. The GUI is, obviously, not being used to take in any user input, so it is at best pointless. But is it also dangerous? Could it cause anything to go pop on the box?
It should not really harm.
You may want to create a standard shortcut to the application then in "properties" select the "Run" -> "Minimized" option.
Don't forget to point the task sceduler to execute the new shortcut rather than the direct application.
The GUI is, obviously, not being used
to take in any user input, so it is at
best pointless.
Just because it doesn't take input doesn't mean it does nothing. While the GUI part of it is probably pointless, the application execution itself may not be.
A Windows Form application being run regularly is the same as any other process being run regularly, and it may have been for whatever reason that the developer of the app wanted a GUI to appear while it was doing its thing or may have had plans to allow users to interrupt the running process through the GUI.
The developer may even be using a GUI control for application execution. A "good" example of this would be using a web rendering control for its DOM processing capabilities.
Could it cause anything to go pop on
the box?
If it doesn't correctly dispose of any resources it uses then yes.
I wouldn't imagine GUI apps are any more notorious than console apps for this, but the fact that someone perhaps unnecessarily used a GUI app (maybe they had only been introduced to WinForms projects) is a strong indicator to check the code and make sure all appropriate resources are being disposed of correctly (think 'using' blocks).
Related
At my company we have a really old program, maybe written in Delphi or something. We don't have the source code. The program works well, but we want to:
Hide some features from the user.
Prevent some actions, if the user doesn't have the right priviliges.
Automate a sequence of actions inside the program, with a press of the button.
How could it be possible to write a wrapper program around this exisitng Windows application with GUI. Which:
Hides the original underlaying programs GUI.
Allows the user to control the underlaying program, but with our given rules.
The new program could be really simple, but I dont't know what are the right tools for this.
Maybe consider AutoIt to pilot "automagically" the old program, since this language features native methods to programmatically interact with GUI, and probably can also hide / protect "dangerous" controls too.
You can even implement a new GUI (with AutoIt itself, BTW it uses an UI designer close to Delphi's one), just to wrap the one only controls you need, with preliminary consistency checks before sending them to the old GUI.
I successfully used AutoIt to automatically install programs that required user interaction during setup to properly install them (i.e. old MySql setups), so I don't see what would be impossible to do with it in your case.
A project I'm writing at the moment requires a Windows Service to be written as it needs to run unattended. One requirement in the specification says that the service should also be able to be run interactively. This is no great problem as I can simply use Reflection to get at the OnStart/OnStop methods and use Console.ReadKey() to pause for keyboard input.
All that's really causing me to pause here is that in order to do this I need to change the output type of the project from Windows Application to Console Application. I'd like someone that has a detailed understanding of the differences between these two choices to explain what the difference is between them and if there are any ramifications for stability in production.
If, while executing in interactive mode, the service is NOT showing Forms, you can change the output type and expect no trouble. If Forms are needed, output type should remain Windows Application. As a general rule, I always start developing service apps as Console apps. It's easy to debug. When it is almost done with testing and debugging, I change to a service app.
This is more of a general theory question as I'm stuck on how to proceed since this is my first time developing an application...
I'm developing a reporting application in VS 2015 that requires two types of functionality. It needs to have a GUI so that users can interact with and create reports and those reports need to be scheduled via Windows Task Scheduler. I'm planning on using a Console Application for the scheduling portion. My question is, what would be the best way to implement this? As of right now I have two separate Projects in a single Solution. Is this the best route to take considering my needs or is there a better option that I'm not aware of? I've done some searching online but have not been able to find a valid solution. It's especially difficult since the scheduling portion needs to pull the application settings from the Windows Form Application.
Any help or guidance would be greatly appreciated. Thank you in advance!
The only reason you would need a console application would be if you actually needed a console interface. It doesn't sound like that's the case—the interface will be written in WinForms. Therefore, you don't actually need two separate applications. You can combine all the necessary functionality in a single executable.
The way to do this is by checking for command-line parameters that indicate whether the app should run interactively or headless. Probably, what you'll want to do is make the app run interactively when no command-line parameters are passed. This would be the normal case, the situation the user gets into when they double-click your app to launch it from Explorer.
When it comes time to schedule your app to run a task in the background (with Task Scheduler or anything else), you signal this by passing a special command-line parameter to your app. You can decide what this is, and you may need several of them if your app can do multiple things in the background. If configuration information/parameters need to (or can) be passed to the app to configure how it should perform the background task, you can pass these on the command line, too. Or, as you mention in the question, you could pull these settings from whatever was set/saved by the user the last time they ran the interactive version of the app.
The trick is just checking for these command-line parameters in your application's Main method. In the design I proposed, if there are no command-line parameters specified, then you just go ahead and create the main form like you normally would. If there are command-line parameters, then you need to parse them to see what action is being requested. Once you've parsed them and determined which background task should be run, you just run that background task—without ever creating/showing a form.
There are lots of different solutions for parsing command-line parameters. Using a library would probably be the easiest way, and also give you the most features. But if you just needed something really simple, like a /background mode, then you could easily write the code for this yourself, without taking a dependency on a library or needing to learn how to use it.
So you could do all of this with a single project in a single solution if you wanted to. Or, you could split different aspects of the functionality out into different projects that compile to libraries (e.g., DLLs), but still have only a single executable for simplicity.
We are developing C++ apps (lots of MFC) with Visual Studio 2005 on Windows.
From time to time it happens that our nightly builds and/or unit tests hang because some part of some app or helper tool opens a message box in a corner case that is hit by the build.
Since the automated stuff is run (by a Windows Service) without any desktop session attached, obviously no-one can confirm - or even read - the GUI messages.
Is there any way to have Windows prevent apps from opening dialogs? Or maybe a tool that watches a service session that auto-kills any app that opens a dialog box?
I'm thinking that most cases where apps display unexpected popup-messages, it will end up calling one of the MessageBox* functions from user32.dll and it might be just possible to "magically" have these functions fail for a certain login-session? (Just a wild idea.)
Obviously the "right" fix is to have stuff not opening any dialogs, but with 3rd party tools it ain't always possible and with our tools it would be nicer to have a failing unit test that tells me the test "illegally" opened a message box than have a hanging unit test.
(Side notes: We're using Boost.Test for our unit tests and FinalBuilder for our automatic build scripts.)
Note: Removed original tags [continuous-integration build-automation automated-tests] and rephrased question to be more process centric.
You can load a DLL in each of the processes which puts a hook onto MessageBoxA and MessageBoxW. You can either do this manually or via the Detours library. You can then either have it return straight away without calling the real function or you could even implement some form of logging to notify your CI of the error.
We use AutoIt to automatically dismiss dialogs in our commercial run-as-windows-service application. The concept is described and some sample scripts are available here:
http://www.coretechnologies.com/products/AlwaysUp/AutoIt/
Note that some of the AutoIt functions don't work properly in Session 0 (e.g. WinActivate) but you can usually find alternatives. Be sure to test in Session 0!
We're starting a new custom project right now from a client and one of the requirements is the process cannot be terminated unless the system is shutting down, restarting, or logging-off.
This application monitors the USB interface. We will be using WMI to query the device periodically.
The client want's to run the application on Windows XP Operating System and doesn't like installing .NET. So we targeted Visual Basic 6 as our language.
My main concern is this application cannot be terminated. Our Project Adviser talks about Anti-virus and yes, some of the anti virus cannot be terminated. I was thinking how to do the same in Visual Basic 6. I know there will be API involved on the project but where should I go? so API is ok with me.
I saw some articles that converts the EXE to a SERVICE, create Windows Service in Visual Basic 6, etc.
So please .. share your thoughts.
If you want to be evil, you can call the (officially) undocumented RtlSetProcessIsCritical NTDLL function. This will immediately BSOD the machine if your process is terminated.
You cannot create a process that cannot be terminated without some sort of kernel-mode hooking, which involves writing a driver. You might want to look into Rootkits: subverting the Windows kernel if you're interested in that. However, even with kernel-mode hooking there are still numerous ways to terminate processes. The alternative is to use user-mode hooking, easily bypassed but enough for very simple projects.
The solution you want to use will depend on how far you want to go with the termination protection. And even if you do succeed in preventing process termination, there may be ways of preventing your application from working properly - e.g. killing the WMI service.
I think you want to look at writing an NT Service.
More info here: http://www.montgomerysoftware.com/CreatinganNTServiceinVisualBasic6/tabid/161/language/en-US/Default.aspxlink text
It's really frustrating coding in VB6 right now specially I dumped my head in C# for 2 years though I coded in VB6 for 5 years..
Moving back is a pain as if I am starting a new programming language.
To be honest, you are trying to do something in VB6 that it really isn't that great at.
When you say 'cannot be terminated' - what do you mean by that? There are several levels there:
a) App shows a window but the user cannot close it with the X button, or it does not show one
b) App shows no windows or maybe sits in task tray
c) App shows no windows and cannot be shut down from the Applications tab of task manager
d) App cannot be shut down from the process list of task manager
(a) and (b) are probably easiest to do in straight VB. (c) is still possible, but getting uglier. (d) gets you into hack territory and would almost certainly be frownd upon if you did manage it.
If you really need to stop users closing then you can probably hack it to a greater or lesser degree, but the real answer is as the others have said - a system service (this is exactly the srt of thing they were intended for). However that is one thing that VB6 isn't good at so the best solution to your problem is c#.