Ravindra Okade explores three different approaches to creating a .NET service: a timer-based service, a service using a single worker thread, and a service using multiple worker threads.
Creating a .NET Windows Service: Three Different Approaches
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why does windows have to use service for long-running and non-UI programs? Why can’t an application, such as your IM client, be kept in background all the time so it can log everything for you? And why can’t people just double-click on a service .exe to start it?
All the service thing does is to limit the flexibility of programs and the innovation in application design.
Its ironic that you describe daemons as being equivalent to backgrounded processes. Its about as correct as your comments regarding flexibility and application design.
You’re serious? You don’t understand the advantages of having an executable run in the background?
o_O
Windows provides a better infrastructure for services, including standardised means of telling them to start, stop, and restart. In addition, the Services Control Manager also makes log entries when your application fails and tries to restart it for you, if you ask it to.
All this, for a few hundred lines of code in a normal application binary.
In addition, as a matter of security, services are not permitted to interact with the user’s desktop, so IM programs running as a service would be breaking Windows security.
An IM application such as that, would be much better structured as being one part end-client that runs in the context of the user’s desktop, and one part backend service, that serves all user desktops on the machine.
As for flexilibity and application design, well, flexibility breeds bugs, and these ‘limitations’ (read: interface requirements) will only stifle innovation in those that do not want/care to work within the rich and mature framework provided by the Windows platform.
David.
(I am as much of a Microsoft whore as I am an enthusiast for the UNIX way of thinking, before you ask)
1.You could write a framework, or many, for services on unix, and it would only be more flexible.
2.Why would anyone mind his IM running as a permanent service, that can do downloading and logging in background? And what about a personal web server with GUI for each user? Could it be implemented easier using Windows’ great service framework? 😉
3.The application developers choose what they want to do, not the OS.
Windows assumes too much!
1. You could, but it doesn’t appear to have been done. As a result, we don’t get niceties like the Services control panel and the SCM programming interface under Unix. This part of Windows is actually welldesigned and does not have any particular drawbacks.
2. Sure, could absolutely be done.
3. If you don’t need the windows services framework, don’t use it. Developers on windows have just as much choice.
1.Can a service have mutliple instances running for different users at the same time, without any extra coding?
2.<see above> PS: I’m not talking about a server that is able to handle multiple user profiles itself.
3.What other choices do they have if the app must be kept running after logout?
You are missing the point of what a service actually is…it’s a long running process that’s agnostic to users or GUI’s or whatnot (by design). Why would you want multiple instances running for different users? It’s up to the service itself to determine what users can access different parts of it…a classic example is SQL Server (which runs as a Windows service); the service itself determines who can do what, which is good orthagonal design as it keeps itself isolated from other processes, and is more secure by default.
– You have /etc/rc.d/SERVICE start/stop/restart. It’s more convenient to use than services.msc, and it’s easier to install. And the mechanism for logging and controlling services (signal) is available for all programs.
– The biggest drawback is not in its services, but that windows applications can’t switch to services in the middle.
You could quite easily do this as a service, but you would have to separate the GUI from the backend and implement IPC for communications between the two.
An IM client is a user/desktop level application however. There are few advantages to running it as a service (unless you want to run a pseudo-proxy/gateway type service). For most user gui-applications startup on login is enough.
See, you’re deciding for the application developers now 😉