Linked by Eugenia Loli-Queru on Sun 2nd Oct 2005 20:28 UTC
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.
Thread beginning with comment 39430
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
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)