Andres Jaan Tack
Andres Jaan Tack

Reputation: 23014

How to develop a server in Windows

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,

  1. produces most of its human-readable output in the form of logs,
  2. accepts input from the operating system (e.g. network or file system events) as opposed to "user clicked a button" or "user typed a command", and
  3. is deployed as a daemon.

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

Answers (2)

Harry Johnston
Harry Johnston

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

Matteo Italia
Matteo Italia

Reputation: 126787

On Windows a service is something that

  1. produces most of its human-readable output in forms of events sent to the event log;

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

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

Related Questions