Linked by Eugenia Loli on Sun 2nd Oct 2005 20:28 UTC
.NET (dotGNU too) 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.
Order by: Score:
Why not daemon?
by aquila_deus on Mon 3rd Oct 2005 13:47 UTC
aquila_deus
Member since:
2005-10-02

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.

Reply Score: 1

RE: Why not daemon?
by Anonymous on Mon 3rd Oct 2005 16:06 UTC in reply to "Why not daemon?"
Anonymous Member since:
---

Its ironic that you describe daemons as being equivalent to backgrounded processes. Its about as correct as your comments regarding flexibility and application design.

Reply Score: 0

RE: Why not daemon?
by sappyvcv on Mon 3rd Oct 2005 17:40 UTC in reply to "Why not daemon?"
sappyvcv Member since:
2005-07-06

You're serious? You don't understand the advantages of having an executable run in the background?

o_O

Reply Score: 1

Because..
by Anonymous on Mon 3rd Oct 2005 14:40 UTC
Anonymous
Member since:
---

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)

Reply Score: 1

Re: Because..
by aquila_deus on Mon 3rd Oct 2005 16:05 UTC
aquila_deus
Member since:
2005-10-02

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!

Reply Score: 1

RE: Re: Because..
by Anonymous on Mon 3rd Oct 2005 23:22 UTC in reply to "Re: Because.."
Anonymous Member since:
---

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.

Reply Score: 0

RE[2]: Re: Because..
by aquila_deus on Tue 4th Oct 2005 00:21 UTC in reply to "RE: Re: Because.."
aquila_deus Member since:
2005-10-02

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?

Reply Score: 1

RE[3]: Re: Because..
by jayson.knight on Tue 4th Oct 2005 08:37 UTC in reply to "RE[2]: Re: Because.."
jayson.knight Member since:
2005-07-06

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.

Reply Score: 1

RE[2]: Re: Because..
by aquila_deus on Tue 4th Oct 2005 00:31 UTC in reply to "RE: Re: Because.."
aquila_deus Member since:
2005-10-02

- 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.

Reply Score: 1

IM Application
by Anonymous on Mon 3rd Oct 2005 16:31 UTC
Anonymous
Member since:
---

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.

Reply Score: 0

RE: IM Application
by aquila_deus on Mon 3rd Oct 2005 21:36 UTC in reply to "IM Application"
aquila_deus Member since:
2005-10-02

See, you're deciding for the application developers now ;-)

Reply Score: 1