If I were to provide an example of what I want, I would point to the little control thingy for Apache that sits in the Windows system-tray. You can start, stop, restart the Apache service. You can't config Apache through this (you can't config Apache any way other than editing the httpd.conf file by hand anyway) but this is the closest I can think of as an example of what I want to accomplish.

Except, I would like to use a web-based interface for my own program to do what this Apache thingy does instead of a native Win doohickey.

I would also like to use the web interface to modify some of the conf params. This portion seems easy -- I can use Config::Simple or some such, or just open up a conf file, tie the values to a hash, and display them in an html form that can then be used to modify and save the conf file back out again.

What I can't grasp is how to control a non-web, continuously running program via a web interface.

Why do I want a web interface? Simply because the web is about as cross-platform an interface technology as one can get. My current program is just a simple Perl script that is launched from the command line, and it runs until Ctrl-C or until it die-s because of some boo-boo. I am thinking of evolving this to something that can be controlled by another program (my web interface), can be eventually cross-platform -- it is right now running on Windows, hence, my evolution to a Win service, but there is no reason why it couldn't run on a *nix box.

I am answering paulbort and Tachyon's comments right here -- I don't have to read the params everytime the script wakes up. It just reads them when it launches until it dies, much like what Apache does. I certainly do not want to muck around with Win registry -- shudder.