Application C/C++ Transparente pour Utilisateur

Bonjour,

J'espère que mon titre est assez clair et que le forum C++ est plus approprié que le C.

J'explique brièvement ce que je veux faire, en espérant avoir des réponses ou une aide de votre part tant sur la faisabilité de mon projet mais aussi sur les moyens de le faire.

J'ai une application C/C++ qui se lance via un .exe, rien d'exceptionnel.
Cependant cette application communique avec une application flash, c'est une sorte de module pour utiliser un périphérique et donc le rendre accessible au véritable programme développé sur Flash.

Ma question est de savoir si il est possible de transformer ce .exe en un service windows ou quelque chose d'équivalent qui renderait l'application c/c++ transparente pour l'utilisateur. En gros, qu'il n'est pas a lancer le .exe, mais seulement le .swf.

J'ai pour l'instant l'idée d'un service windows, cependant je ne sais pas comment le développer.

Bonjour,

Citation:

---

Envoyé par johntayback

Bonjour,
Ma question est de savoir si il est possible de transformer ce .exe en un service windows

---

Oui. Tu as un exemple assez complet dans la FAQ.

Citation:

---

Envoyé par johntayback

ou quelque chose d'équivalent qui renderait l'application c/c++ transparente pour l'utilisateur.

---

Une application sans IHM démarrée automatiquement ?

Citation:

---

Envoyé par 3DArchi

Une application sans IHM démarrée automatiquement ?

---

Oui ! sa serait parfait !

je peux réaliser ça comment?

Une application standard mais tu caches la fenêtre principale ou tu n'en créés pas.

donc pas une application console? et comment démarrer l'application automatiquement?

Citation:

---

Envoyé par johntayback

donc pas une application console?

---

Je ne sais pas s'il est possible de démarrer une application console sans affichage de la console.

Citation:

---

Envoyé par johntayback

et comment démarrer l'application automatiquement?

---

En l'ajoutant dans "Démarrer/Démarrage" à l'install.
Mais peut être que le service est le mieux pour toi. L'appli silencieuse est une autre approche. Tout dépend de qui l'utilise, comment elle est déployée et tout et tout.

Au pire, tu utilises FindWindow puis ShowWindow(...,SW_HIDE) pour planquer la fenêtre de la console à l'exécution.

Par défaut, le titre de la fenêtre devrait être le chemin complet de ton exécutable (cf. GetModuleFileName).

merci pour vos réponses.
je vais essayer de le lancer au démarrage et de cacher la fenêtre console.

J'ai regardé les fonctions ShowWindow et FindWindow, j'ai cependant un petit problème pour utiliser FindWindow.

Donc si j'ai bien compris je devrais avoir :

Code:

---

ShowWindow(hWnd, SW_HIDE);

---

En ce qui concerne le handle (hWnd) je doit le récupérer grâce à FindWindow.
Mais je ne sais pas comment renseigner les paramètres de cette fonction pour mon application console.

Code:

---

1 2 3 4

HWND FindWindow( LPCTSTR lpClassName, LPCTSTR lpWindowName );

---

Si vous avez un peu de temps pour m'expliquer.

lpClassName : mets NULL.
lpWindowName : le résultat de GetModuleFileName.

Voila ce que j'ai :

Code:

---

1 2 3 4 5 6

HWND fenetre; LPTSTR chemin; DWORD taille=4000000; GetModuleFileName(NULL,chemin,taille); fenetre = FindWindow(NULL,chemin); ShowWindow(fenetre, SW_HIDE);

---

Par d'erreur de compilation, par contre j'ai une erreur lors de l'exécution.

Code:

---

1 2 3 4 5

Exception de première chance à 0x7c91216c dans cps_project.exe*: 0xC0000005: Violation d'accès lors de l'écriture à l'emplacement 0x50000169. Exception de première chance à 0x7c9112b0 dans cps_project.exe*: 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x50000169. Exception non gérée à 0x7c9112b0 dans cps_project.exe*: 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x50000169. Le programme '[3312] cps_project.exe: Natif' s'est arrêté avec le code 0 (0x0).

---

Mon problème vient peut être de ma variable "taille", je ne sais pas comment je dois la dimensionner.

Merci.

Allouer ton "LPTSTR chemin" ne serait pas une mauvaise idée en soi, ça t'évitera d'aller jardiner n'importe où... :mouarf:

c'est à dire? je suppose que je ne peux pas faire un simple malloc()?

MAX_PATH est là pour toi :

Code:

---

1 2 3 4 5

const DWORD taille=MAX_PATH; TCHAR chemin[taille]; GetModuleFileName(NULL,chemin,taille); HWND fenetre = FindWindow(NULL,chemin); ShowWindow(fenetre, SW_HIDE);

---

[EDIT] : l'allocation n'est probablement pas nécessaire. Et malheureux, pas de malloc en C++ !

merci d'aider un malheureux! comme moi !

Citation:

---

Envoyé par 3DArchi

l'allocation n'est probablement pas nécessaire. Et malheureux, pas de malloc en C++ !

---

Allocation au sens large : pas forcément une allocation dynamique, une statique via un TCHAR chemin[MAX_PATH] est amplement suffisante pour ce cas précis...

La proposition de 3DArchi est encore bien plus simple: ne pas créer de fenêtre.

Code:

---

1 2 3 4 5 6 7 8 9

int WINAPI wWinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow ) { Structure_interprocess ipc; Mon_serveur serveur ( ipc );   serveur.run();   return S_OK; }

---

Il n'y aura aucun parasite de fenêtre nulle part, pas de console ni rien.

Citation:

---

MAX_PATH est là pour toi :

Code:

---

1 2 3 4 5

const DWORD taille=MAX_PATH; TCHAR chemin[taille]; GetModuleFileName(NULL,chemin,taille); HWND fenetre = FindWindow(NULL,chemin); ShowWindow(fenetre, SW_HIDE);

---

---

Attention, avec les paths longs unicode, MAX_PATH peut très bien être trop petit --> le path sera tronqué, ça va faire n'importe quoi.

Citation:

---

Envoyé par ac_wingless

Il n'y aura aucun parasite de fenêtre nulle part, pas de console ni rien.

---

Pour utiliser ta solution, je dois récréer un projet vide? Pour l'instant, j'ai un projet Console sur Visual Studio.

En tout cas ta solution m'intéresse car la méthode de la fenêtre invisible fonctionne bien quand je lance le .exe, mais la fenêtre reste affichée quand l'application se lance seule au démarrage.

Citation:

---

Envoyé par white_tentacle

Attention, avec les paths longs unicode, MAX_PATH peut très bien être trop petit --> le path sera tronqué, ça va faire n'importe quoi.

---

Ca n'est pas ajusté ? Il faut donc faire MAX_PATH*sizeof(wchar_t) ?

Citation:

---

Ca n'est pas ajusté ? Il faut donc faire MAX_PATH*sizeof(wchar_t) ?

---

Si, c'est ajusté. TCHAR path[MAX_PATH] pourra contenir un path de 260 (de mémoire) caractères unicodes.

Sauf qu'un path windows peut faire jusqu'à 32767 caractères... (la notation utilisée n'est alors plus là même).

Voir http://msdn.microsoft.com/en-us/libr...47(VS.85).aspx pour un petit aperçu de comment gérer les paths longs sous windows (c'est indispensable pour une appli certifiée).

Citation:

---

Envoyé par white_tentacle

Sauf qu'un path windows peut faire jusqu'à 32767 caractères... (la notation utilisée n'est alors plus là même).

---

Les paths sont limités depuis des lustres, je suis encore tombé sur ce problème cette semaine en décompressant une archive contenant une arborescence complexe dans un répertoire trop "profond", boum la tête...

Les paths "longs" sont en général réservés aux noms UNC, aux "chemins" de devices, mais rarement aux fichiers usuels. Pour la plupart des applications, la "limite" de MAX_PATH suffira amplement.