bonjour
j'ai crée un programme en c++ et je veux lance le .exe en arrière plan comme un precess pour ne pas déranger les utilisateur.
est ce qu'il y a une méthode pour faire ça?
merci
bonjour
j'ai crée un programme en c++ et je veux lance le .exe en arrière plan comme un precess pour ne pas déranger les utilisateur.
est ce qu'il y a une méthode pour faire ça?
merci
S'il n'a pas besoin d'un utilisateur connecté, faites en un service Windows, si c'est sous Windows bien sûr.
http://en.wikipedia.org/wiki/Windows_service
mon script s’exécute après l'ouverture du session d'un utilisateur
Je ne vois pas trop le problème.
Tout programme non console qui n'ouvre pas de fenêtre est dans ce cas de figure.
je vais éclairer le chose
j'ai crée un programme en c/c++ sous windows qui s’exécute au lancement d'une session windows ce programme se connecte sur une base de données MYSQL pour insérer (login utilisateur,nom du machine,ip adresse,date_heure se connexion) et sur mon programme j'ai rajouté une fonction qui s’exécute chaque 5 sec pendant 30 min si le poste agent n'arrive pas a se connecter à la base de données pour insérer les données et mon problème ce que le fenêtre dos reste afficher devant les yeux de l'utilisateur chose qui empêche son travail et aussi il peut la fermer avant de terminer le programme
ma demande est ce je peux lancer mon programme en arrière-plan comme ?si oui c'est quoi la méthode
voila mon code c/c++
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64 #include <stdafx.h> #include <conio.h> #include <winsock.h> #include <mysql.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <string> #include <iostream> #include <assert.h> #include <windows.h> int main(int argc, char **argv) { char* adr; char req [400]; adr=(argv[1]); char* us; us=getenv("USERNAME"); char* co; co=getenv("COMPUTERNAME"); char *ip; MYSQL *conn; char id[64]= {"0"}; ; int k=0; stop: conn = mysql_init(NULL); if( mysql_real_connect(conn, "127.0.0.1", "login", "pass", "user", 0, NULL, 0) == NULL) { k++; Sleep(5000); if (k==360){ exit(1); } else{ printf("%d",k); goto stop; } } else { strcpy (req, "INSERT INTO collecte_login(ID,MATRICULE,ACTION,IP,DESK,STAMP) VALUES ('0',"); strcat (req, "'"); strcat (req, us); strcat (req, "',0,'"); strcat (req, adr); strcat (req, "','"); strcat (req, co); strcat (req, "',NOW())"); mysql_query(conn,req); mysql_close(conn); } }
Vous cherchez midi à 14 heures.
Il n'y a plus de fenêtre DOS sous Windows depuis au moins 17 ans (Win95).mon problème ce que le fenêtre dos reste
Ce n'est pas une fenêtre DOS mais une console, donc
Vous êtes dans un programme console.Tout programme non console qui n'ouvre pas de fenêtre est dans ce cas de figure.
Assez logique avec une signature C d'il y a 40 ans :
Créez un projet Win32 NON CONSOLE, le nom du point d'entré sera très vraisemblablement WinMain et non main.
Code : Sélectionner tout - Visualiser dans une fenêtre à part int main(int argc, char **argv)
P.S.: moi, j'aurais penché vers l'utilisation des fonctionnalités intégrées d'Active Directory plutôt que ce bricolage.
http://technet.microsoft.com/en-us/l.../bb742436.aspx
Une console à plus de 17 ans si ont rentre dans se type de petit délire
Actuellement c'est une invite de commande ou l'emulation d'un terminal DOS
Il y a une méthode crade qui s'appel le Ghost.
En gros tu fais un programme qui va forker ton programme que l'ont va appeler papa.
En gros papa se termine salement sans fermer le fils et donc tu te retrouve avec un ghost soit un processus qui tourne sans réel attache en gros.
jouana, ton second prénom c'est Hibernatus ???
DOS n'a j'amais eu de terminal, c'est pas UNIXActuellement c'est une invite de commande ou l'emulation d'un terminal DOS
Et le prompt affiché par cmd.exe n'est pas une console TTY.
jouana, tu mélanges tout et n'importe quoi.
C'est bien, ranges ton grimoire du Moyen-age et rendor-toi.En gros tu fais un programme qui va forker ton programme que l'ont va appeler papa.
En gros papa se termine salement sans fermer le fils et donc tu te retrouve avec un ghost soit un processus qui tourne sans réel attache en gros.
Ce truc, c'est de l'Unix des années 60, et c'est pas parce que Windows était vaguement compatible POSIX 1 pour l'US Army, dans les années 80/90, qu'il faut l'utiliser.
P.S.: ce n'est pas un ghost, n'y même un zombi Unix, et il faut faire un détachement explicite de la console hérité par le programme parent. C'est dans les 3 premiers descripteurs de fichiers, si je me souviens bien de mes cours de paléontologie informatique.
Mouais les zombies sont encore utilisé sous linux et BSD.
Enfin bon après pas la peine d'être désagréable j'offre une solution comme une autres.
Ensuite penches toi sur la création de service windows, zaki_1982 tu devrais trouver ton bonheur.
Et un terminal n'est pas propre à UNIX, c'est juste une interaction entrée sortie, que tu retrouve sur beaucoup d'OS différents, TTY en est un parmi beaucoup d'autres.
Mais je te rejoins sur le fait que DOS n'est plus depuis windows NT et que l'ont a maintenant des émulations de ce derniers.
NONque l'ont a maintenant des émulations de ce derniers.
Il n'y a RIEN de DOS dans Windows. RIEN RIEN RIEN même plus l'intéruption 21, RIEN.
Sans rentrer dans un grand débat la dessus un petit extrait de Wikipedia
J'ai pas dit que c'était DOS mais que l'invite de commande est un émulateur de DOS.Windows XP qui en est la version 5.1, se passe presque intégralement de la ligne de commande, et l'invite de commandes qu'elle propose n'est qu'un émulateur, largement bridé, de MS-DOS.
Soit quelque chose qui imite le fonctionnement de DOS.
L'URL, s'il te plait, que j'aille corriger de ce pas.
MS-DOS, c'est pas qu'un interpréter de commande qui fait clignoter un curseur avec les commandes du BIOS. Faut arrêter de déconner à un moment.
Et il va contenir Linux quand je vais installer cigwin sur ma machine ?
Non, mais ce que après, les commandes "Linux", elle vont être comprise de l'interpréter de commande de Windows (Le PATH fait de petit miracle émulatique ).
Non, mais, ce qui faut pas entendre.
Comme si un primate imite le fonctionnement d'une amibe.Soit quelque chose qui imite le fonctionnement de DOS.
Enfin, tout ça pour faire un programme qui ne sert à rien puisque toutes ces informations sont déjà dans l'Active Directory du domaine Windows.
Je me rappelle que pour avoir créé simplement un programme non-fenêtré, j'avais compilé mon code en précisant que c'était un processus, dans l'IDE Dev-C++, et comparé à un Code::blocks ou je ne sais quoi, comme par magie ça avait fonctionné.
Désolé je ne me rappelle plus exactement comment j'avais réalisé ceci, mais ça doit pouvoir se retrouver facilement, et comme j'ai plus DevC++ d'installé sur mon PC ...
En tout cas tout ca pour dire que tu dois pas te compliquer la vie, normalement ca doit se faire comme ca.
Cdt,
Vespiras
"un processus" ou un service ?
Et oui, ce n'est pas compliqué, si on sait ce qu'on fait.
Bonjour.
Il y a deux méthodes et Bacelar les a donné : un service ou une application Win32 qui n'affiche pas sa fenêtre.
Pour le service, il suffit de faire une boucle et d'attendre que l'utilisateur soit loggé.
Pour l'application Win32, utiliser un timer.
PS : si le but de votre programme, c'est de scruter les logging des utilisateurs, vous avez ces informations dans le journal d'évènements Windows... Suffit de récupérer ces journaux.
Très moyen comme approche, une tâche planifiée, c'est mieux, et les logs sont automatiquement générés dans le journal d'évènements Windows.Pour l'application Win32, utiliser un timer.
Moi, fainéant, et fière de l'être.
Bonjour Bacelar.
Je veux bien croire qu'il y a de meilleures approches. Mais de là à dire que c'est très moyen, un malheureux petit timer de 5 secondes
PS : je le prends au second degré...
Alors l'approche timer :
- non partage du scheduling système : gaspillage de ressource système
- plantage sur problème transitoire (connexion réseau ...) : pas de logs automatique, pas de redémarrage automatique (celui qui me colle un try catch(...){}, je le baffe)
- Intégration dans une console de monitoring, monsieur le développeur, il va se la cogner à la main
- les timers, c'est la vraie jungle et les plus fiable, c'est du multi-threading obligatoire, est-ce justifié pour un pauvre programme basique ?
- paramétrage via un console standard que même Mme Michu peut maitriser, donc, a fortiori aussi un admin système, même pas très dégourdi.
- paramétrage au niveau des scripts d'installations totalement customisable avec des primitives que notre cher admin système connait sur le bout des doigts.
...
Avec un scheduled task, j'ai aucun de ces inconvénients et tout ces avantages GRATIS (0+0=0 ligne de code en plus ).
Non, franchement, je ne vois aucun avantages aux timers "embarqués" pour une application de ce type, mais alors au niveau emmerdes, c'est pas mal.
Mais je vois le mal partout (normal, je suis développeur et Murphy est mon ami ).
moldavi, je suis tout ouïe pour entendre votre plaidoyer pour le timer embarqué dans l'application.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager