>>>>Usually these service applications need to be very reliable. To make a really reliable Windows service application it would be better (or at least easier) to do in NET. I have tried to emulate that in VFP before, but it was tedious and never as simple and sturdy as one written in NET. That service should write to the Windows events and log any errors. I also log start/stop events. If it's important enough it should also send emails about its status.
>>>>I have implemented an ftp download in C# using some third party library which worked very good, but I don't have it at hand. If you want to go that route I can look it up later for you.
>>>
>>>I wrote one such thing in Fox a few years ago, using (I think) Martina's code (she wrote the 2.0, original by Robert Abram), which is actually a wrapper around system API calls. It got installed, and it's perhaps still running - haven't heard the users complaining since. Don't have it anymore, but found some traces, that was november 2014. It was using windows scheduler to run invisibly. Some other apps by the same team were running as services. For FTP watch I considered running under task scheduler more appropriate - it's not communicating with other processes, not serving them in any sort of in-memory communication, so there's no need to run as a service.
>>
>>I think that's possible indeed, need to setup the scheduler so it works also when no one logs into the server. We have had problems in the past because the server would restart during the night because of a Windows update, and there is no log in. But maybe this issue has been solved.
>
>There's a checkbox in the setup of the task scheduler to do exactly that. The larger problem is the account under which it runs, which will cause problems later. Usually the admin doesn't remember or even know that it is used for a scheduled task, and sets it to expire the password. The task simply stops running when the password is changed and the new password not entered in the scheduler, and nobody notices that for days (depending on the importance of the task). Or, if you're lucky, its password is set to never expire, but the never expires when the admin leaves and the new one notices a security breach: aaaahhh I have an account whose password never expires, panic, change that asap. About 90% of the problems I had with the 30-60 installations of several scheduled tasks were of this kind.

There would be the advantage of the service, because it does not depend on a user account. The problem for the service would only exist, if the service needs rights on the network, then you would also need to setup an account for that. But an ftp download should not need any log on, can write to the windows events and send status emails.