Hi!

>Hi!
>
>>Take a look to the SRVAny application in the Windowse Resource kit. It allows to run ANY application as a Windows NT service.
>
>I'd like to add some words about "ANY":
>1. "Some applications may terminate upon logoff, even though they were started as a service, if they don't ignore the WM_ENDSESSION message (or CTRL_LOGOFF_EVENT)." (SRVANY.EXE description)

This is ONLY when somebody logged on to that computer with the same user name as used for the service account.

However, there is another, SERIOUS issue that cause you need to use SvcIt instead of SrvAny. SrvAny stops the application by the TerminateProcess() API function accordingly to help. So when you shutdown Windows and your process does something, you risk to corrupt data because your application could be terminated just at the ANY moment. (this is also from the SRVANY documentation). SvcIt close application using the WM_CLOSE event sending to the application that is MUCH more reliable, becuase you can, for example, in VFP handle it as ON SHUTDOWN event that will fire between code lines when _VFP.AutoYield = .T.

>2. "Microsoft does not currently recommend, and does not support, running Visual Basic applications as Microsoft Windows NT Services because the applications may exhibit unstable behavior when installed and run as Microsoft Windows NT Services." (Q175948)

Nice article, but this is explaining why it is not possible to write the Windows NT service using VB, not a running of VB application as a service. Note that VB have an AddressOf function that allows to organize CallBacks. Using this fact there is an idea to use it to write a service using VB. In VFP this is not possible at all. When running VB application using SRVANY, this article do not apply.

>3. "By convention, Microsoft Windows NT Services are designed to be non-interactive. That is, in most cases, they do their work without any user interaction. Services are usually configured and controlled with an applet installed in the Control Panel. This requires that the programmer add code to provide for these additional requirements:
>- Report warnings and errors in the system or application logs. You typically can't use output to the screen because there may be no user logged on.
>- Control the service through a separate application or through a Control Panel applet. This involves implementing a communication mechanism for your service.
>- Install and remove the service from the system." (Q175948)
>
>Therefore, an application must be specially developed to run as NT service,
>and IMO nobody can garantee a (stable) work of VFP application as NT service.

Cannot tell this for sure, you're probably right. However, VFP service is very easy to maintain and handle using 2 service applications. One is a main VFP service application and second is a guardian service that observe the activity of the main service and restart it as soon as it starts to show something weird. It is common approach to make some service more reliable and I already implemented such approach once.

BTW, you did given very nice article references at MS site for VB, making this your post favorite. Writing VB service is what I dreamed about, but you saved me a lot of time, thanks! ;)