How do i make my program to run even when the user logs off

Posted on 2003-10-28
Last Modified: 2010-04-05
Hi There

I have written a Scheduler program in delphi which sits in the system tray This program checks for the time with the TTImer to execute the function.

This program would run on a server.

the problem i am facing is, when i log in as an administrator via terminal server remotely to the server and run this program, everything is fine.

but when i log off this program exits (hence doesnt make use of the scheduling)

i assume it would behave the same way if i log in on to the computer locally and run this program and log off

i want to know if there is a way to run a dephi application without it shutting down when the user logs off (for example the antivirus softwares etc)

Question by:chanpreet
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
  • 2
LVL 12

Expert Comment

ID: 9639574
you can create it as a service on NT platforms or call the RegisterServiceProcess function under win9x
I always have 2 exes and my setup chooses which one to install
to minimize the builds you can put the whole app in a dll and only load the dll in the apps
an alternative is SvCom .. allows you to have an NT Service AND a win9x 'service' in one exe

Author Comment

ID: 9639813

This program would run on a windows 2000 server, so i can run it as a service

what do i have to do to make my program run as a service?

what about user interaction? like changing the scheduling time etc


Author Comment

ID: 9639826
i have noticed that in delphi i would have to rewrite my application as a service.

that is not a vailable option and would prevent human interaction
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 12

Accepted Solution

Lee_Nover earned 60 total points
ID: 9639834
File - New - Service Application
read about services in the help
create a remote config app using sockets (TCP)
so you have a service that does only what it has to .. and a config tool
you can then use that config tool to admin your service over internet
LVL 12

Expert Comment

ID: 9639858
then take a look at SvCom
the fastest way to change your app to a service (1 days work tops)
LVL 17

Assisted Solution

by:Wim ten Brink
Wim ten Brink earned 65 total points
ID: 9640590
I have written a scheduler application too once but I wrore it in two parts. One was, as already suggested, a system service. This service would start the scheduled items when it's time to start them. The other part was a client application that connects to the service through an inter-process communication technique (I chose named pipes in this case) and this client tool would allow the user to configure the whole service and to add/modify/delete schedule items.
This is exactly what Lee is suggesting too.

However, from my own experience I know that you have to keep an eye on certain issues... Most important of all is the security of the service. A service still runs under a user account, but it logs on by itself to the system. This account can either be the interactive user or you'll have to specify a user account for the service when you configure it. Keep in mind that your service is limited to the access rights of this account.
Also, a service has some problems accessing networked resources like printers and mapped folders. If your service needs to be connected to folders on other systems then use UNC filenames (\\Machine\C$\Whatever) instead of mapping folders to local disks (E:\) names. The service is using a user account but still doesn't have complete access to everything.
And debugging is also a problem with system services. Make sure you start your service manually once you have it configured. The reason is simple. If it starts automatically and crashes because of a bug, you might have to reboot your system. But if you reboot, your service will be restarted again and probably crash again. It could well be possible that the service crashes will prevent you to log in again on your test computer in a normal way. Means you have to start in safe mode and try to disable the service first before you can reboot again with a bit more succes.
A good way to debug a service is by using two computers. One one system you develop the service and you make sure the binaries are written to a folder on the other computer. The other computer will be the test system, running your service and whatever else you need to test. This way, if the service crashes the test machine the damage is less severe...
Be aware of memory leaks. A service might be running for several days and if every scheduled item leaks a bit of memory, the whole system might slow down considerably after a few days because the system service is eating up all memory, including the memory in the swap file.
And make sure your system service doesn't take too much process time while it's just waiting for the next action. (OR while it's waiting for an action to terminate. The best way is by using multiple threads and lots of waitforSingleObject/waitformultipleobjects API calls. Be aware that if you keep everything in a single thread, your service might not respond to the client while it is processing a scheduled item.

I don't know how experienced you are as a Delphi developer but it took me about a month to write my scheduler, completely tested and all. It is in use now for about two years, running perfectly without any real problems. But I must say, it wasn't easy. And no, this scheduler is a commercial product so I can't share the source.

Btw. if you wonder if you should give the points to Lee or me, give them to Lee. He provided the answer. I just provide some additional warnings and hints. ;-)

Author Comment

ID: 9640781
Thanks Alex for your thoughts.

Is there anyway at all apart from me having to rewrite this application to get it to work.

this would require re-wriitng code for service and the config app

is there a tutorial anywhere where i can find some examples about writing services in delphi

i read somewhere about srvany and instsrv which make an exe into a system service (but yes i loose the interaction) and i realised the TTimer event no longer works

i wont be able to spend a month on this as its for a client who wont be ready to pay for the time.

i have had a look at SVCOM but couldnt find any component that takes an existing project to make it a has components to create new services from scratch

lastly ...are system processes the only processes that are running when a user is logged off... i have seen that mcafee and other similiar applications that dont have system services associated

LVL 17

Expert Comment

by:Wim ten Brink
ID: 9642330
What you could do is write a very small system service that just does one single thing: start up the scheduler application. However, this means the application runs under the service user account, thus when a user logs in, he won't be able to access it. (Even if it is the same user as the account used for the system service.)
The problem with Windows is that everything runs under a user account, even things like NAV and MacAfee. If you go to start/settings/control panel/administrative tools/Services then you'll see an overview of all services running on your system. I guess you'll find MacAfee between them. I know there should be a way to make a system service interactive with the currently logged on user but in general people use the client/service approach for this.
I know this will involve a rewrite of your code plus a steep learning curve. You will encounter even more problems than just creating the service since you might also have to work with multiple threads and keep then synchronised. I happen to be a fast learner but I do know how difficult it can be sometimes.

Creating a system service itself is not a big problem. Just create a new Service Application in Delphi and your service is mostly done already. Just set some properties to it and add the code to process whatever needs to be processed. You'll have to write code for the events that the TService component provides. In my case I kept it simple: On the OnServiceStart I created a datamodule and on the OnServiceStop I closed the datamodule again. This datamodule itself initialized some data inside my service and would spawn a separate thread that would be processing client requests. A second thread would take care to start the scheduled items at the appropiate time and this thread could be turned off if the client requests this. I did not use the OnExecute event of the service, btw...

There should be a few examples on the net for service applications. A quick search on Google for "Delphi service example" should provide a few useful ones. I used a few good books instead but I must say that you won't find much information anyway.

I have heard about tools that could "promote" an application into a system service but I never needed to do this. For my scheduler I could just start from the ground up. It was a complete redesign.

And yes, I know the customer might not pay for all the time you put in it. The scheduler I created had the same problem. The customer was only willing to pay for half the time I needed to develop it. However, I managed to find several other customers who were interested in this product and now, two years later it is a nice, cheap add-on for other products that the company I work for will sell. So perhaps you could do the same and sell copies of the scheduler to more customers.
Otherwise, keep it simple and tell the customer that you can't do this in such a short amount of time...

About system services. No, you could also create a device driver. They too can run outside the logged-on user context. But they are even more difficult to create. The problem you have is that you always have to split up the functionality between a part that runs unattended (service) and an interactive part that communicates with a user. Perhaps you could create the scheduler as an ISAPI dll instead and use webbased techniques to communicate with it. An ISAPI DLL will stay in memory after it is called for the first time and with the use of SOAP or just simple webpages you could actually make a nice client-application too. All this ISAPI dll has to do is start a separate thread for the scheduling.
This technique will have lots of other problems too. It might sound easier but you have to deal with other kinds of issues. At least, I've never tried this but it could be possible. An ISAPI DLL will be running in the context of a system service but since you don't have to create the service, the learning curve might be less steep.
But it might not work. I never tested this trick...

Featured Post

Enroll in May's Course of the Month

May’s Course of the Month is now available! Experts Exchange’s Premium Members and Team Accounts have access to a complimentary course each month as part of their membership—an extra way to increase training and boost professional development.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Have you ever had your Delphi form/application just hanging while waiting for data to load? This is the article to read if you want to learn some things about adding threads for data loading in the background. First, I'll setup a general applica…
Introduction I have seen many questions in this Delphi topic area where queries in threads are needed or suggested. I know bumped into a similar need. This article will address some of the concepts when dealing with a multithreaded delphi database…

710 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question