Bonjour à tous,  
ca fait donc plusieurs jour que j'essaie de comprendre comment je peux passer des arguments a mon ServiceMain lors de son démarage...    
 
C:\le\chemin\jusque\mon\executable\service.exe -address 10.1.205.21 -port 8080
 
ma fonction :  
int ServiceMain(int argc,char* argv[])  
{  
 
 
}  
 
argc vaux toujours 1  
et argv = le nom de mon service ...  
ma question est donc comment je fais pour passer mes agruments -address et -port a ma fonction ServiceMain...?  
Quelqu'un qui a une idée?    
merci pour votre temps..  
a+  
Julie  

http://msdn.microsoft.com/library/ [...] cemain.asp
 
=>
lpszArgv  
[in] Pointer to an array of pointers to null-terminated argument strings. The first argument in the array is the name of the service, and subsequent arguments are any strings passed to the service by the process that called the StartService function to start the service.

je n'ai trouvé que 2 solutions à ce même problème:
 
1. tu installes ton service  normalement et tu vas ensuite "à la main" rajouter les options de démarrage avec l'outil windows qui sert à ça et qui te permet de modifier les paramètres des service a posteriori.
 
2. lorsque tu enregistres ton service, au lieu d'enregistrer l'executable comme "c:\...\service.exe", tu l'enregistres avec "c:\...\service.exe -address 10.1.205.21 -port 8080"

SoWhatIn22>
  1.quand on ajoute des parametres de démarrage, lors du prochain redémarage de la machine windows l'a oublié...
  2.c'est donc l'option que j'ai prise mais sauf que ses arguments passe par le main de mon programme et n'arrive jamais dans les arguments du ServiceMain
blackgoddess >
lpszArgv ne se remplie que si on utilise la fonction StartService (qui est un fonction qui permet de démarrer un service apartir d'un autre programme et ce n'est pas mon cas).
moi j'utilise donc
   SERVICE_TABLE_ENTRY DispatchTable[2];
   DispatchTable[0].lpServiceName = "webserver";
   DispatchTable[0].lpServiceProc = (LPSERVICE_MAIN_FUNCTION)ServiceMain;
   DispatchTable[1].lpServiceName = NULL;
   DispatchTable[1].lpServiceProc = NULL;
   StartServiceCtrlDispatcher(DispatchTable);  
C'est donc un pointeur vers la fonction mais les arguments dans tout ca??? on les mets où??

sachant que dans le cas où le service est lancé via l'outil de windows, tu peux spécifier les arguments, je ne vois pas le pb.  
 
D'autre part, si c'est un autre service qui appelle ce service, alors la fonction StartService() te permet de spécifier les arguments.
 
Enfin si ce sont des arguments "constants", tu les récupères via le main, donc tu peux les mémoriser et les utiliser plus tard, non?
 
Tout cela pour dire que je ne crois pas que ce que tu veux faire soit possible. D'un autre côté, on s'en sort très bien autrement.

question generale (un peu trop pe) : quand decider de faire un service ou un programme tournant en arriere plan ? Quels avantages/defauts viennent avec un service ?

l'avantage d'un service, c'est que:
   - il peut être configuré pour démarrer automatiquement avec la machine. Pas besoin d'attendre une ouverture de session.
   - il n'est pas attaché à une session. Donc même si l'utilisateur ferme la session, le programme peut continuer de tourner.
   - un service peut être administré depuis une machine distante.
 
les défauts: je n'en connais pas. C'est plutôt que souvent, il n'y a pas d'interêt à utiliser ce mode car les programmes sont propres à 1 utilisateur et à sa session.
 
il y a peu être des problèmes de droit, aussi. Mais comme je ne connais (comprends) rien aux droits sous windows, je ne peux pas t'en dire plus.

moi je creer 2 type d'install
   soit en demon ou qu'on dois (pas oublié) démarrer et arrêter
   soit un service que démarre au démarrage de win et s'arrete avec celui-ci.
 
j'ai fais des variables globales... ok je suis d'accord c'est pas très propres mais ca marche.
merci beaucoup pour l'aide...
Julie

> j'ai fais des variables globales
 
tu veux dire que tu as regroupé toutes ces variables dans une classe (en statique, ou en utilisant un singleton) ? arf

chrisbk > par defaut également un service tourne sous le compte LocalSystem, ce qui lui donne tout les droits locaux (plus qu'un compte admin selon certains cas je crois), mais par contre aucun droit réseau. (on peut le changer toutefois)
 
sinon, comme disait SoWhatIn32, il ne tourne pas sur la session d'un utilisateur, donc il n'est pas censé interagir avec l'utilisateur.
en cas de plantage par exemple, c'est au gestionnaire de service de décider quoi faire, mais en aucun cas il ne devra afficher un message a l'utilisateur, a part pour le prévenir d'un reboot imminent par exemple (le cas de blaster qui faisait crasher un svchost).
 
en gros, c'est beaucoup plus isolé de l'utilisateur qu'un prog tournant en arriere plan.