Hi,


A Windows service generally cant have a built in user interface. In earlier 
versions of windows, you could state that the service was allowed to 
"interact with desktop" and thus show a GUI, but that has been disallowed in 
later versions of Windows (since Vista if I remember correctly).


Hence you should never create a service which require FM. Instead make your 
service with whatever non visual functionality it has, and seperately create 
a GUI application that can pick up the data produced by the service and/or 
communicate with it by some manner (COM, kbmMW, plain TCP/IP, Shared memory, 
ini files or a database or whatever you can think of as a shared 
communication path).


Unix based servers dont have the concept service. They just understand the 
concept of a process. That process can run in the background or in the 
foreground. Generally background processes should never have any GUI stuff 
in them, but be compiled as console applications and started as a background 
process either by the startup procedure of the Unix box (typically defined 
in /var/etc/init.d or /etc/init.d).


Again you should make an additional GUI application that communicates with 
the background process. A typical way on Unix machines, is to use files for 
communication. The GUI can for example write a new configuration file, and 
when its ready, signal to the background process that it should reload the 
configuration, by sending one of the 31 supported process signals available 
on standard Unix. It sends a signal by calling the system function kill with 
a process id and the signal number.


The background process then can react on some of the signal numbers (some 
like signal 9 will terminate the background process without it having a 
chance to react), and reload the configuration.




-- 
best regards


Kim Madsen
TeamC4D
www.components4developers.com


The best components for the best developers
High availability, high performance loosely coupled n-tier products