Discussion :

[Bernard B]

Bonjour,

Je voudrais ré-écrire avec Delphi, un vieil interface graphique pour windows qui pilote une application en mode console.
Je n'ai qu'une doc limitée et incomplète des commande à envoyer au programme console.
Comment puis-je faire pour intercepter les commandes envoyées par l'utilitaire graphique et les renvoyer vers l'appli console, les retours dans l'autre sens ne sont que des acquittements et ne m'interressent pas pour l'instant au moins.
Merci

[ShaiLeTroll]

"Pilote" c'est vague
Est-ce via ?
- ligne de commande *
- des Pipes assimilable à l'entrée sortie classique mode texte *
- FileMapping partagé avec un échange de signaux (sémaphore / event)
- TCP/IP local
- SendMessage (est-ce une vrai application console ? GlobalAddAtom)

* ces deux là, suffit de faire un programme avec le même nom et appeler le programme console renommé ou dans un autre répertoire
Les deux sont simples à capturer et relayer

[Bernard B]

Effectivement il manquait une info :

Le dialogue se fait en ligne de commande ou je pense par les pipes assimilables à l'entrée sortie en mode texte effectivement.
Pour la première commande j'ai cloné (au seul sens du nom de l'appli) l'appli console et je recupère ainsi la première commande que je répercute avec un composant TDosCommande vers la vraie appli console et je peux même récupérer la réponse.
Mais ensuite je ne sais pas comment faire pour récupérer les autres commandes qui vont suivre et assurer les retours vers l'appli interface graphique.

[ShaiLeTroll]

Regarde ce sujet c'est la lecture des Pipes, tu dois pouvoir y greffer l'écriture dans TSLTShellExecuteWrapper.CallCmd sur hWritePipeInput.

[ALWEBER]

Regarde aussi du coté des application CGI avec le serveur internet microsoft. Un CGI n'est rien dautre qu'un EXE DOS qui communique avec le serveur via les canaux d'entrée/sortie matérialisés par les signes < et > dans les commandes MS DOS

[Paul TOTH]

quand je dois analyser des échanges entre applications je fini toujours par faire deux fois le boulot, dans ton cas:

1) une appli qui pilote l'appli console

2) une appli console qui sera piloter par la veille interface

ça te permet de savoir exactement ce qui se passe des deux côtés.

ça peut aussi prendre l'aspect d'un proxy, à savoir une appli console qui va recevoir des commandes de l'ancienne appli, les afficher, puis les envoyer à l'appli console d'origine, afficher son retour et le retourner à l'appli.

[Roland Chastain]

Bonjour !

Le sujet m'intéresse. J'ai plusieurs fois travaillé dessus, avec plus ou moins de succès. J'avais trouvé un programme en C qui fait cela et qui fonctionne très bien. J'avais essayé de le traduire en Pascal mais ma traduction n'a jamais fonctionné. Voir cette discussion.

Ensuite j'ai fait un autre essai en partant sur une base différente. Si je me souviens bien, ça fonctionnait mais pas très bien (c'était un peu lent). Voir cette discussion (la pièce jointe du dernier message).

Mon problème était le même que le vôtre (si j'ai bien compris) : je voulais pouvoir espionner les échanges entre une application graphique (un jeu d'échecs) et son "moteur" qui est une application console. Je ne savais pas qu'on appelait cela un "proxy", mais ce que je cherchais à faire c'est exactement ce que Paul a décrit.

Peut-on avoir accès aux applications en question, pour faire des essais ?

P.-S. Il doit y avoir des applications déjà existantes pour faire cela mais la difficulté est de les trouver. Peut-être que je n'ai pas cherché avec les bons mots.

[Bernard B]

Paul ton analyse est tout à fait exacte. C'est cela que je cherche à faire.
Le besoin de Roland est à mon sens exactement le même.

Perso je veux savoir exactement les commandes qu'envoie une appli graphique "ExifTooGui.exe" vers l'utilitaire bien connu "ExifTool.exe" que malgré une documentation assez touffue je n'arrive pas à piloter correctement dans certains cas via mon appli de gestion de photos.

[Roland Chastain]

Bonjour !

J'ai trouvé ce projet, UCI Protocol Sniffer, que j'ai pu compiler (avec Visual Studio) et faire fonctionner sans problème.

Je ne l'ai pas essayé avec ExifTool et ExifToolGUI, mais je crois que ça pourrait fonctionner.

Je ne suis pas utilisateur d'ExifTool, mais si j'ai bien compris, il fonctionne exactement comme un moteur d'échecs. L'utilisateur entre des commandes successives au clavier, et le moteur répond quelque chose dans la console. Le GUI ne fait que prendre la place de l'utilisateur, en écrivant et en lisant dans la console. Est-ce que je me trompe ?

[Bernard B]

Je pense que c'est exactement comme le jeu d'échecs :
Exiftool fait le boulot de traitement des photos en fonction de la ligne de commande que tu lui passes au demarrage, ou une fois qu'il est lancé car il est possible de lui demander de rester "ouvert".
Comme ces lignes de commandes peuvent être longues et complexes, ExifToolGui offre une interface graphique permettant de définir ce que l'on veux faire et transforme ce paramétrage en une ligne de commande qu'il envoie à ExifTool et il récupère le ou les résultats du traitement pour les afficher à l'utilisateur.

[Roland Chastain]

J'arrive à lancer ExifTool par l'intermédiaire de mon espion (UCI Protocol Sniffer) depuis l'invite de commandes. Malheureusement depuis ExifToolGUI ça ne fonctionne pas, je ne sais pas pourquoi. ExifToolGUI se plante quand j'essaie d'ouvrir un fichier.

Si vous voulez essayer vous-même, j'ai mis ensemble les deux programmes. Le vrai ExifTool se trouve dans le dossier exiftool. L'exiftool.exe du dossier principal, c'est uciPlug.exe que j'ai simplement renommé, comme les deux fichiers qui vont avec. J'ai aussi modifié les valeurs des chemins dans le fichier config.

[Roland Chastain]

C'est dommage que le code source d'ExifToolGUI, qui est un projet Delphi, ne soit pas disponible...

[Bernard B]

Merci Roland, je vais essayer.
Concernant le code c'est sûr, je vais peut être essayer de contacter l'auteur ??

[Jipété]

C'est dommage que le code source d'ExifToolGUI, qui est un projet Delphi, ne soit pas disponible...

Perdu !

Ça me disait quelque chose, et le hasard faisant bien les choses, voili voilou, plus qu'à cliquer (testé et vérifié)

[Bernard B]

Ça c'est super, clair et bien documenté en plus !

Je n'avais rien trouvé d'aussi clair pour l'utilisation des pipes standards en entrée comme en sortie

Je vais essayer, cela devrait aider pour capturer les échanges.
Merci

[Roland Chastain]

Bonsoir !

Dans les exemples d'utilisation d'ExifTool que je vois, on lui lance une commande avec des paramètres, il répond et il se ferme. Comment l'exécuter en mode dialogue continu ?

Le code indiqué par Jipété correspond à une utilisation simple (paramètres, réponse, fermeture), pas à un dialogue continu.

[Bernard B]

ExifTool à une commande stay_open qui evite "je pense" qu'il ne se referme à chaque fois.
La documentation d'exiftool est très complète, mais rédigée dans un style linuxien qui m'est toujours assez imperméable sans parler de la langue du chat qu'espire !

je cite :

-stay_open FLAG Keep reading -@ argfile even after EOF

-execute[NUM]
Execute command for all arguments up to this point on the command line (plus any arguments specified
by -common_args). The result is as if the commands were executed as separate command lines (with
the exception of the -config and -use options which remain in effect for subsequent commands). Allows
multiple commands to be executed from a single command line. NUM is an optional number that is
echoed in the "{ready}" message when using the -stay_open feature

-stay_open FLAG
If FLAG is 1 or True , causes exiftool keep reading from the -@ ARGFILE even after reaching the end
of file. This feature allows calling applications to pre-load exiftool, thus avoiding the overhead of
loading exiftool for each command. The procedure is as follows

1) Execute exiftool -stay_open True -@ ARGFILE , where ARGFILE is the name of an existing
(possibly empty) argument file or - to pipe arguments from the standard input. ......

[Roland Chastain]

@Bernard

Merci pour la documentation.

Avec un programme ainsi conçu,

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
program exiftool;
 
var
  s: string;
  t: text;
  i: integer;
 
begin
  assign(t, 'exiftool.log');
  rewrite(t);
 
  for i := 1 to paramcount do
  begin
    writeln(t, paramstr(i));
    flush(t);
  end;
 
  repeat
    readln(s);
    writeln(t, s);
    flush(t);
  until s = 'quit';
 
  close(t);
end.

j'ai pu capturer les éléments suivants :

-stay_open
True
-@
-
-v0
-overwrite_original
-sep
*
-c
%.6f°
-s3
-f
-GUI-SEP
-exif:Make
-exif:Model
-exif:LensModel
-exif:ExposureTime
-exif:FNumber
-exif:ISO
-exif:FocalLength
-exif:Flash
-exif:Orientation
-exif:DateTimeOriginal
-exif:CreateDate
-exif:Artist
-exif:Copyright
-exif:Software
-Gps:GPSLatitude
-GUI-SEP
-xmp-dc:Type
-xmp-iptcExt:Event
-xmp:PersonInImage
-xmp-dc:Subject
-xmp:LocationShownCountryName
-xmp:LocationShownProvinceState
-xmp:LocationShownCity
-xmp:LocationShownSublocation
image.png
-execute9

Cela en essayant d'ouvrir un fichier image.png.

Maintenant, pour faire exactement ce que voulez, je pense qu'en modifiant uciPlug ce serait possible. Il faudrait vérifier notamment que les paramètres de la ligne de commande sont bien transmis à ExifTool. On peut sûrement faire la même chose en Delphi, mais personnellement je n'en serais pas capable. Soit dit en passant, j'ai l'impression que C# a des facilités pour les "pipes" que Delphi n'a pas.

Mais le plus simple me paraît quand même de bâtir vos commandes en vous appuyant sur la documentation d'ExifTool, malgré son style et sa langue. :)

[sergio_is_back]

Regarde ici un exemple avec code pour l'utilisation des pipes avec Delphi

http://delphi.cjcsoft.net/viewthread.php?tid=48178

Ça te donnera peu être des idées... Tu remarquera qu'il s'appuie sur des fonctionnalités standard de l'API Windows

[Bernard B]

Ok Sergio pour les pipes. J'utilise déjà les pipes IPC dans une de mes applications bâtie avec une application principale qui dialogue avec des applications qui font des tâches de fond qui sont des PipeServeurs et l'appli principale contient autant de PipeClients connectés aux serveurs. Mais ce sont des pipes nommés et je maîtrise les deux côtés des choses.
Je n'avais pas trouvé avant l'exemple dédié au pilotage d'exiftool comment utiliser les pipes standards en entrée et en sortie.

Actuellement, j'ai fait un peu la même chose que Roland, à chaque appel d'exiftool par ExifTooGui je récupère comme lui la ligne de commande et avec la dernière doc j'envoie les commandes vers exiftool et je récupère bien le retour et d'éventuels messages d'erreur. Il reste maintenant à renvoyer tout cela vers ExistoolGui et l'affaire est faite.
Par contre le peu que j'ai réussi à récupérer m'a effectivement aidé à mieux comprendre par l'exemple la doc d'ExifTool. Et sur la même idée j'ai un vieux système d'automate que j'aimerais bien reprendre et qui fonctionne à l'identique mais là aucune doc !