Reputation: 23014
I ask this question as a guy with a strong Linux system programming background. I have very little experience in Windows development, and this has so far been limited to "Console Application"-type programs.
What is the canonical process of developing a server, knowing that it must run on Windows?
Does one build a Windows Service application right away? Is the debugging process really as obnoxious as it seems? Does a Windows developer start out with a Command Line Application for the sake of debugging, and only convert it to a service for deployment?
For comparison, I will offer that a Linux "server" is a regular command-line program in the chosen language. I'll define a server as a program that stereotypically,
It may be that Windows sysadmins expect entirely different interfaces to start, stop, and manage servers. I'm absolutely open to that; I just haven't seen that whole side of things yet.
$ ./my-server &
Starting...
$ head /var/my-server.log
2012-3-10 14:34:43.934 [info] Server started! Waiting for connection from client
$
Upvotes: 3
Views: 189
Reputation: 36308
Firstly: yes, it is almost always preferable for a server on Windows to be implemented as a system service. However, it is an added bonus if the server can also be run from the command line for troubleshooting purposes.
It isn't usually too difficult to structure your code so that the service-specific logic is abstracted into functions that can check whether you're running as a service or on the command line and behave accordingly. I prefer to have a single source module containing just the main() function and the service-specific stuff. For best results, ensure that only this module knows which mode you are running in. (Note also that this module can often be inherited from one project to the next with only modest changes.)
The other advantage of doing this is that it means you can do most of your debugging in command-line mode, without having multiple build options. You'll still need to test (and probably debug) the service logic itself but that's a much smaller job.
There's some additional information here you've probably already seen.
Upvotes: 3
Reputation: 126787
On Windows a service is something that
produces most of its human-readable output in forms of events sent to the event log;
accepts input from the operating system via whatever events it likes to respond, but must always respond to requests from the Service Control Manager (SCM) (like "start service" "stop service", "pause service", ...).
Exactly how these events are delivered depends on the facilities of the chosen programming language you use; in C (i.e. at OS level) you have to set up an event loop and examine the events received. Normally you'll perform the actual work in separated threads, with the main thread on the event loop.
Is deployed as a service, which is typically a console executable that registers itself to the SCM.
For more info about services in .NET see here; for the nitty-gritty details on how this all works at the C level (i.e. without any fancy language facilities) see here.
Upvotes: 2