Bruno van Dooren said:
i am developing a program that has to run on a pc as a service.
OK.
at this moment i run my code in a thread that i start from a command line
app. i do this for testing and debugging. i figured that this is simpler
than debugging a service.
OK.
now i have to put my code in a windows service, and i have to do this using
MSVC 6 preferably.
OK.
what is the easiest / best way to do this? there is no 'windows service'
project type like there is in VS .NET.
Arrrrrgggghhhh.
The world after Einstein, Heisenberg and Godel is so, so
relative. What does best really mean? Is what is easiest for me easiest for
you? But enough of philosophy ...
You have two choices. In the Platform SDK take a look at the sample in
MSSDK\Samples\winbase\Service
It is not the prettiest code you'll find but it does work and it does offer
you the shell of a service with almost no work even though there is no
wizard. Also be sure to read the README which contains this
<quote>
1) The use of the SERVICE.H header file and the accompanying SERVICE.C file
simplifies the process of writing a service. You as a developer simply need
to follow the TODO's outlined in the header file, and implement the
ServiceStart and ServiceStop functions for your service.
There is no need to modify the code in SERVICE.C. Just add SERVICE.C to your
project and link with the following libraries:
</quote>
In fact, it is probably better to say that you _shouldn't_ modify the file
(at least until you understand it) than that there is no need to do so. If
you feel you must I would suggest a careful read of the services overview in
MSDN and the chapter on services in Jeffrey Richter's book "Programming
Server Side Applications MS Windows 2000" as prerequisites.
The second option (I think) is to use the ATL COM App Wizard in MSVC 6 and
to choose the third option - "service". I say I "think" because while I have
written a bunch of services what I know of ATL could barely fill a thimble.
and if i have created a service, what is the best way to install it?
If you choose the sample service approach then you simply run it with the
install option ( -i command line argument). All that does is to use
CreateService() to set the few registry keys that define a service. In fact
that function is one of serveral others in the "service control API" that
exist for building applications which manage services.
i have never done service programming before, so i do not know if thee is
more than one way to do this, and what the best way would be.
The mechanics are easy enough. What's slightly strange at first blush is the
execution model. The main thread fills out a data structure that describes
the services that it supports and their handlers and then calls
StartServiceCtrlDispatcher() which idles it. Some time later the service
control manager (SCM) causes a thread to be created which begins executing
at the service's handler. Functions exist so that the service can report
status to the SCM while it is running.
What tends to bite developers is the different runtime environment that
services have:
1) Services should run as LocalService or LocalSystem and they should run on
the service desktop not the interactive one and they shouldn't display UI
elements or directly interact with a user as there can be multiple users
2) If they find a UI is necessary there should be a client program that uses
some IPC technique to make requests of the service.
3) If necessary the service should impersonate the user client only while
that's necessary rather than running as though it were he.
4) Services as a rule have around 15 to 20 seconds to clean up. Try to be
quick at saying your goodbyes.
5) Important information should use the native event logging mechanism and
it's associated message files to keep the size of the log small.
6) As LocalService has free reign over the local machine, always be mindful
of what your service does and how its capabilities could be abused.
7) Probably more stuff that escapes me now
Because of the different environment, it is possible that the behavior you
see while testing on the desktop will be different from the production
runtime behavior. If that should happen to you, then you might want to read
this:
http://msdn.microsoft.com/library/d...ry/en-us/dllproc/base/debugging_a_service.asp
Of course, I didn't find that link through personal experience. No, no, not
me. ;-)
Regards,
Will
