Converting a Delphi application to run as a servic

Question

I have a delphi app that logs data from various places and writes the data to a file. The app has quite an extensive GUI to allow display of the data, configuration of the options, etc.

One user has requested that the app be changed to that it can be run as a service. His reasoning is that the app could then be started at boot time and run without any user being logged in and would be available regardless of who was logged in.

My question is this: Is there any other solution that would enable me to install the app as it now exists so that it would still run with no user logged in and still be available to all users?

My gut feeling is that converting the app to run as a service is not trivial. I assume you would need 2 apps - the "headless" service application, and a GUI that was run by users on demand that could interact with the service (comments welcome here also).

Answer 1

You can try to use svrany, a tools to run an application as service. It's parts of Server Resource Kit Tools. try this link for 2003 server resource kit download.

Answer 2

There are commercial (and free) solutions like Firedaemon, which will run (almost) any application as a service.

On a sidenote, it shouldn't really be hard to separate logic and user interface - you should've done that already when you developed the application. Just because Delphi makes it easy to write business logic in the code behind associated with the user interface, that doesn't mean you should really do it. Have a look at the presentation pattern's at Martin Fowler's site.

Answer 3

It depends a little on your application, but generally it is achievable. Try this: http://iain.cx/src/nssm. Don't forget to start all services that you application depends on BEFORE you start your application as a service. Google around for info on how to do that.

Answer 4

You could write a simple service that starts your application. But if you care about your app future, I would go the service way. Yes, you would have to split the application in two pieces, the client/GUI part and the service itself, especially since Vista and 7 made much more difficult for a service to display a user interface for security reasons. Services have several advantages, they run in their separate session, they can be set to run with a given user that could be different from the logged-on one, only user with proper privileges can control them, Windows can automatically restart them (or perfom other actions) when they fail.

Answer 5

I usually create my application in such a way that it can be started as a service or as a GUI, via a commandline switch /GUI.

When the application runs with a GUI, I instantiate and start the service class "manually".

Advantages:

• It'll run the same code, making it very easy to debug the service. You can just put breakpoints and step through your code without having to "attach" to a running application.

• Because of the GUI, you can see what your service would be doing, and interact with it, via listviews and buttons, even on remote servers where you don't have a debugger. Having to interact with your service via logs and configurations is crappy and slow.

Example dpr, from a project that works like this:

program xxxx;

uses 
  SysUtils,
  SvcMgr,
  .......;

{$R *.res}

begin
  GlobalAppId := 1;
  MapMatcherController := TMapMatcherController.Create(nil);
  try
    if FindCmdLineSwitch('GUI',['/','-'],True) then
    begin
      Forms.Application.Initialize;
      Forms.Application.MainFormOnTaskbar := True;
      Forms.Application.CreateForm(TfrmMain, frmMain);
      Forms.Application.Run;
    end
    else
    begin
      SvcMgr.Application.Initialize;
      SvcMgr.Application.CreateForm(TsrvMapMatcher2, srvMapMatcher2);
      SvcMgr.Application.Run;
    end;
  finally
    MapMatcherController.Free;
 end;
end.

Oh, another thing to keep in mind is that services usually run as a "system" user, which means you'll have different privileges and settings (for example drive letter mappings).

Answer 6

In general is possible to have a mixed single exe which in turn runs as a service or runs as a full GUI standard application.

How much effort your application needs to fit this category is matter of how is it designed, specially in the kind of coupling it have between business logic and user interface logic.

One great example of this kind of application comes with Delphi itself: scktsrvr.exe in your $DELPHI\bin directory runs as a GUI application or as a service (run scktsrvr.exe /install to auto-register the service and use management console to start/stop it.

in folder $DELPHI\source\db you will find the project files (scktsrvr.dpr/res, ScktCnst.pas, ScktMain.pas/dfm). Take your time to inspect how is it done and, who knows... maybe this is what you're looking for your application.

Take in account since Windows Vista interactive services are not allowed to interact with the user at his/her desktop. An administrator have to enable the interactive services detection and the user have to change to session 0 desktop in order to interact with your service (by interact it means to see and interact with your service forms)