I have noticed that Windows services are becoming increasingly popular. I have created a few of them myself.
What I’d really like to see is some sort of logical and physical division in the service controller that divides the core operating system services from third party services. For example, in the management
console there could be some sort of tabbed view that divides the core system services from third party services. Additionally, there could also be some sort of visual cue that gives attention to the critical services that the operating system absolutely must
rely on and will not shutdown.
I also use “sc” from the command line to control services so it’d be great to see some sort of division there as well.
A physical division between the two types of services would also be nice so that third party services could be completely wiped out and the system would be unaffected. (Maybe this is too optimistic
of an idea because it could create some problems with third party services that provide low-level hardware support.)
I’ve also noticed that we’ve come a long way with version control and resolving naming conflicts, yet these ideas are almost absent in the service controller. Since most services sport generic names,
this could only lead to trouble as more and more people move to NT platforms and services get more attention.
Also, when you use the event log wrappers in .NET to write out to the event log, users are still refered to Microsoft's Help and Support Center in the event log viewer when they go to view these events.
I've discovered a workaround for this problem, but hey, if Microsoft wants to provide technical support to my users for third party software, they are most welcomed. I don't really want to have to deal with it anymore.
I just feel that Windows services provide great functionality for background applications that run even when no user is logged in. Plus managing them is easy. But I feel they're too tightly integrated into the operating system and it's difficult to tell which
services are core services and which are third party extensions.
One limitation I find in the SCM is that, like Add/Remove Programs, it requires that the service exist and be functional enough that it be able to uninstall itself.
So if I install something, and then blow away the directory it's in, there's no way to remove the service entry from the Services control panel. I have to hack it out by hand with RegEdit.
What happens to me more often is I create a service, install it, and then some time later, decide to change the name. If I forget to remove the service before I rename it, I end up with the service entry under the old name as a zombie that I can't remove.
It'd be nice, in both those places, for the OS to offer the ability for an admin user to say 'hey, the app is gone, take it out of this list'.
You guys should check out System.EnterpriseServices namespace. I think all of your complaints can be developed by yourself. ServiceController class is an object you can use to communicate to all of the services on the machine.
As for seperation of services you build vs. system services it is probably typical that you would see the login as the best way to seperate them. Local System login is usually reserved for system services. Not to say you can't use it yourself. However ServiceController
also has a ServiceType enum that will provide the type of service, further ability to filter them.
These sound like some interesting and good ideas, I had a couple questions about them.
If there was a tabbed seperation between core services and third party services, where would you include things like a SQL Server, Exchange, or BizTalk service?
You also mentioned having a need to create some windows services, would you mind describing what you've needed to create them for?
Also, I think I remember seeing a uility in the resource kit you might be able to use to manually uninstall services entries without having to use Regedit directly.
While it is true that I could come up with certain solutions on my own, my strategy to deal with these problems would differ from the strategies (if any) used by other developers and vendors and that could cause a confusing experience for the end user. Also,
the majority of third party services also run under the local system account.
Services are really popular now for firewalls, antivirus software, database engines, etc. My current service application that I’m working on is conference software that allows users to chat with one another through multiple interfaces (telnet, specialized
GUI client software, and the Web). Running as a service has a lot of advantages: (1) it can be controlled via the service controller locally or remotely from another computer, (2) it has built in failsafe if the server should go down (you can give services
instructions on whether to restart or reboot the machine or whatever), (3) it can run when no user is logged onto the machine and users logging on and off don’t disrupt the server at all.
My service application has multiple services in it (which is one reason a tabbed view might be cool, and maybe a tree node view for service applications so you can see all the services that belong to them them), such as the interface for telnet, the interface
for smart clients, and the interface that exports Web services. It also has an NNTP service for newsgroups. I’m not the worst offender though. Oracle has like 10+ services.
With all the attention services are receiving today, I thought maybe the service controller would be organized more like the Global Assembly Cache in .NET which is pretty well guarded against naming and versioning conflicts with strong naming.
As for SQL Server, Exchange, or BizTalk, I’m not sure. They’re not core services and they’re not third party either. Maybe you should be able to create different sections like you can in the event log.
I agree with you, the Service Controller should have some better organization ability. You would think this would have been a natural decision as this is kind of the core management tool on a server. However, I still think you could quickly (within a day
or so) build yourself a really nice tool to take care of your needs specifically your desire to organize the processes in a single service.
Sometimes it's just better if you do it yourself.
Little off-topic: If you stop a service will that service be completely out of memory or at least free up some memory?
I had similar ideas in mind since some time. My idea was to split system32 into two folders. One system-specific part and an user folder, where all apps slap their DLLs into. The system-specific part would be under complete control of the OS, applications
incl. the administrator would only have read-only access, whereas Microsoft signed patchers and all could write to it. Naturally should there be a special case for the admin, to allow him read-write access on request.
Preferably that scheme should apply to everywhere, including the registry, services and what not. In addition to promote some more security, cleaning up an installation could be reduced to something like "rmdir \windows\user_* /s".
Too bad this will be next to impossible to implement (in a timely fashion and without breaking compatibility here and there)
I use the Black Viper web site to help me tweak my system so it has maximum performance. It explains each services purpose and suggests which could be turned of without causing problems. It would be nice if this info was built into the services control
panel applet. The visual clues suggested by tinytiger would help, but I would like additional information.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.