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

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)

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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
chanpreetAuthor Commented:

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

chanpreetAuthor Commented:
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
Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
then take a look at SvCom
the fastest way to change your app to a service (1 days work tops)
Wim ten BrinkSelf-employed developerCommented:
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. ;-)
chanpreetAuthor Commented:
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

Wim ten BrinkSelf-employed developerCommented:
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...
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.