I have a Delphi application running in a server. This application do some critical work with my DB which is used in other applications and executes when a user logs in to Windows. It all is working fine, but, turns out the server's administrator sometimes reboot the server and does not log in to Windows. The server stays in Windows Login and my application doesn't start.
After a small research I decided to create a Windows Service to start my application even before a user logs in Windows. But, I have two forms. One form shows the Current Process that my application is executing and the other one edite a .ini file that its used to configure the first form.
What I need to be done is to create a service that starts my application before a user logs in Windows and after logging in, show my forms or open it but minimize it to System Tray.
Is it possible to use Windows Service with this behavior and minimize my forms to the System Tray?
A service cannot display a UI at all (including a System Tray icon) in Vista onwards, and it is discouraged in earlier versions. In all versions of Windows, you should be separating the UI out into its own non-service application that can be run by a logged-in user, manages the system tray icon for that user's tray, and communicates with the backend service as needed using any number of available IPC mechanisms (pipes, sockets, COM, RPC, WCF, etc).
Well, you can have a form in a service, but is has to run as Administrator and must be set up as an interactive service.
I've used SVCOM to create nice services with tray icons and a form that can minimize to system tray.
Have a look here: http://www.aldyn.ru/products/index.html
Hope this helps
Related
I'm working on a web project in which I need to be able to communicate directly with my customer's printer. The customer uses my application through a browser, and would like to be able to click a button to print tickets uninterrupted, meaning there is no printer dialog popup from the browser. This requirement eliminates many traditional ways of sending information to the customer's printer, and because I want a solution that will work on any browser, solutions that use VBSCRIPT or other browser-dependent solutions will not work.
My initial solution for this problem was to create a Java applet that was loaded into the page dynamically when a "Print" button was clicked. However, browsers like Chrome and soon Firefox are removing support for NPAPI, which breaks my Java plugin.
The current solution I'm working on is to create a service in C# that the user installs locally on their machine, and then when the customer clicks the "Print" button, my server communicates with that service directly. This way I can bypass the browser restrictions, and the service running on the customer's machine will have full access to communicate with the target printer. The downside to this approach is that the user now has to install an additional bit of software on their machine, and for each machine they wish to access my application on and print from, that machine needs to have proper port-forwarding and firewall settings configured. I can make this work for my current customer, but with future customers it becomes a hassle. Furthermore, my new approach currently only supports Windows machines, and if future customers are using OS X or Linux, I will need to port the service.
Has anyone faced this problem before, or are there any ideas out there for how to communicate with a client's printer that is browser-independent?
There's no possible solution to this that both supports Chrome and doesn't require something to be installed on the machine; you can't run arbitrary code that interfaces with the OS from within Chrome. And the only way to interact with that other code besides a local web server would be Native Messaging in an extension, but that doesn't fulfill your cross-browser requirement.
you can't communication directly because of security. i also develop 1 application in c# for remotely printing.
there is one way if your client have remote printer then you can do this task easily make small app on server and integrate with all remote printer and you can execute printer command from server and print will comes from client printer
I have a web application running in a GlassFish 3.1 service on Windows 7 and Server 2008. I would like this application to be able to control a number of other services on the same machine. In particular I want it to be able to start and stop Tomcat services.
Essentially the application is acting as a controller for other applications I deploy on the machine so I can set any security necessary on the controlled applications.
I notice that .Net has a ServiceController class so I'm assuming that programmatic control is possible but I would very strongly prefer a pure Java solution if possible.
All the searches I've done turn up a lot of information about running Java as a service and not much on controlling services from Java. Is what I'm trying to do possible? What security hoops will I need to jump through?
You can do Runtime.exec("net stop tomcat6"). Of course tomcat6 can be replaced with any other service name.
Also check out this tutorial
http://www.java-samples.com/showtutorial.php?tutorialid=8
I am creating a utility that runs as a service and starts applications. As long as I log in as an admin and start the service it will run the applications. I log out and the service (and applications) continue to run. But, if another user logs in with different credentials they cannot access the front end GUI of the applications started by the service utility.
I was wondering if there is a built in account which I could use that may solve the issue? Or if anyone has any ideas or insight in the matter?
Windows Services can only be set to "interactive" when run in the system account. Notice the placement of the "Allow service to interact with desktop" checkbox on the Log On tab when configuring the service (via the Control Panel Services application).
Beyond that, are the other users logging in via RDP? Run mstsc with the "/admin" flag to ensure that they are going to Session 0 where the service will display its windows.
And finally, beware interactive services! You are probably on Windows XP or 2003 which is why it kind-of works, but Windows Vista, 7 and 2008 behave very differently (search for "Session 0 isolation").
Why the option ‘Allow service to interact with desktop’ is only available for Local System account and not for any other account while configuring a windows service from control panel? I want to configure the windows service so as to allow interaction with desktop irrespective of the account it is configured to run with. How to achieve it?
that is a good question! I have never seen an official explanation from Microsoft, but I would guess that the reason has to do with permissions and rights and not wanting to mislead users.
Not all users are created equal. Some do not have the rights to display a user interface on session 0, or interact fully with arbitrary programs (and resources) it is running alongside. Having those users able to show GUI elements from a service may lead to confusion. For example, if a user account having limited rights starts an instance of Windows Explorer as a service, that window may not be able to accept dropped files from a "regular" explorer started by the interactive user. This sort of thing may be very difficult to diagnose and explain!
Note that Windows can certainly do what you like and we code it all the time in our service applications (http://www.CoreTechnologies.com/). Windows is simply not making that option available to you for any arbitrary user.
Of course please please take a step back and beware changes in Vista. "Session 0 Isolation" is a game changer for interactive Windows Services!
I created a Windows service and installed into users machine.
That windows service is very important and I do not want to user can change its startup type to "disable".
It seems "Plug and Play" service can disable the Startup drop-down listbox.
How can I make same behavior for my windows service?
I would imagine it has to do with setting the appropriate permissions on the registry key. But a user with sufficient permissions can do anything. If this is for a business application, I would try to stick to using group policy or user permissions. If this is for a commercial application then I would expect a lot of upset users and malware detection.