Discussion :

[Roland Chastain]

Bonjour !

J'ai découvert un petit programme en C très intéressant, qui s'appelle UCI Filter :

http://www.nnuss.de/Hermann/UciFilter.html

Pour expliquer la chose en deux mots, c'est un programme qui s'interpose entre Arena (ou un autre programme du même genre) et un moteur de jeu d'échecs. Au lieu de donner à Arena le chemin du moteur, on lui donne le chemin d'UCIFILTER.EXE avec le chemin du moteur comme paramètre. UCI Filter intercepte les messages échangés dans les deux sens et les communique (en en filtrant certains). Si cette explication n'est pas assez claire et si le sujet vous intéresse, je pourrai proposer une démonstration de la façon dont le programme fonctionne.

Je me suis lancé dans une tentative d'adaptation en Pascal. Avec le temps et avec votre aide, j'espère y arriver.

Voici ce que j'ai fait jusqu'ici (en pièce jointe, avec le code original). Ce n'est pas grand chose mais j'aimerais déjà avoir votre avis.

Je bute sur l'en-tête de cette procédure :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

void HandleDurchPipeErsetzen( DWORD EinOderAus, HANDLE* pMeinHandle, HANDLE* pEngineHandle, HANDLE* pOriginal )

Quel serait l'équivalent de l'astérisque ?

[Alcatîz]

Bonjour,

Pour expliquer la chose en deux mots, c'est un programme qui s'interpose entre Arena (ou un autre programme du même genre) et un moteur de jeu d'échecs. Au lieu de donner à Arena le chemin du moteur, on lui donne le chemin d'UCIFILTER.EXE avec le chemin du moteur comme paramètre. UCI Filter intercepte les messages échangés dans les deux sens et les communique (en en filtrant certains). Si cette explication n'est pas assez claire et si le sujet vous intéresse, je pourrai proposer une démonstration de la façon dont le programme fonctionne.

L'explication est claire mais une démo serait éminemment intéressante.

Quel serait l'équivalent de l'astérisque ?

Il s'agit de pointeurs, donc de paramètres de type pHandle.

[Roland Chastain]

L'explication est claire mais une démo serait éminemment intéressante.

Bien. Pour cette démonstration j'utiliserai Arena, en français (le fichier langage est à télécharger séparément sur la même page).

Je vais installer un nouveau module.



Je sélectionne "UciFilter.exe".



Arena me demande s'il doit démarrer le nouveau module module tout de suite.



Je clique sur "non". J'ouvre la fenêtre de gestion des modules, et je sélectionne UCI Filter.



Je remplace le nom du moteur (ainsi que le nom de l'auteur et le pays) par le nom du moteur que j'ai décidé d'utiliser, à savoir Pharaon de Frank Zibi. J'ajoute le chemin de "pharaon.exe" dans le champ "paramètres ligne de commande".



Il ne me reste qu'à charger ce nouveau module et à commencer une partie. Ça fonctionne ! Je peux ensuite ouvrir la fenêtre journal (dans le menu "modules") pour regarder de plus près ce qui se passe. Ah oui, je constate que certaines lignes ont été ajoutées par UCI Filter :

2016-02-14 06:33:32,985<--1:option name TimeCurrmove@UciFilter type spin default 1500 min 0 max 5000
2016-02-14 06:33:32,985<--1:option name TimeInfo@UciFilter type spin default 300 min 0 max 5000
2016-02-14 06:33:32,985<--1:option name TimeQuit@UciFilter type spin default 1000 min 200 max 1800
2016-02-14 06:33:32,986<--1:option name RemoveNonUci@UciFilter type check default true
2016-02-14 06:33:32,986<--1:option name RemoveStop@UciFilter type check default true

Vous me demanderez peut-être à quoi sert ce programme. Si j'ai bien compris les explications que donne l'auteur sur son site, il s'agissait au départ d'améliorer le fonctionnement d'Arena et de résoudre je ne sais trop quel problème. Mais peu importe : ce qui est intéressant, c'est la technique employée. Et cette technique pourrait être utilisée pour espionner le fonctionnement de logiciels du même genre qu'Arena mais qui n'ont pas de fenêtre journal.

Il s'agit de pointeurs, donc de paramètres de type pHandle.

Merci.

[Alcatîz]

[Roland Chastain]

J'ai fini ma "traduction". Elle se compile mais le programme ne fonctionne pas. Le contraire m'aurait étonné.

J'ai réuni dans une archive tous les fichiers nécessaires pour tester le programme, au cas où vous voudriez y jeter un œil. Au lieu d'Arena, j'ai utilisé Cute Chess, qui est une application console qui fait s'affronter automatiquement deux moteurs. Cute Chess est lancé par le fichier de commande test.cmd. Au bout de quelques dizaines de secondes (le temps est variable parce que les moteurs ne jouent pas toujours les mêmes coups), la sortie de Cute Chess est enregistrée dans un fichier test.log.

Le fichier ucifilter.exe inclus dans l'archive a été compilé à partir du C (avec MinGW-GCC). Si je le remplace par l'exécutable compilé à partir du Pascal, ça ne fonctionne pas : j'ai une fenêtre noire qui reste ouverte indéfiniment et pour finir je dois arrêter manuellement tous les processus. On peut voir dans le gestionnaire des tâches que les deux moteurs ont démarré mais apparemment l'un des deux (Pharaon, celui qui est lancé par UCI Filter) ne répond pas.

Je ne sais pas trop comment chercher l'erreur. Je pense essayer d'ajouter dans mon code des fonctions pour produire un journal. Si vous avez le temps de regarder le fichier source ucifilter.pas, peut-être verrez-vous l'erreur que j'ai faite. J'ai bien quelques idées mais il serait fastidieux de les exposer.

Il y a un endroit dans le code original qui me paraît bizarre. Je l'ai transcrit tel quel mais il ne me paraît pas logique. C'est dans la fonction EngineNachGui() :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
else if (
pFilter->bFilterNonUci
&& strcmp(Kommando, "id") == 0
&& strcmp(Kommando, "readyok") == 0
&& strcmp(Kommando, "copyprotection") == 0
&& strcmp(Kommando, "option") == 0
)

Ce que je comprends ainsi : si la valeur de Kommando est égale à "id" et égale à "readyok" et égale etc. Ce qui évidemment ne peut pas arriver. Ou alors est-ce que c'est moi qui comprends mal ?

[bataff]

Bonjour,

Ce que je comprends ainsi : si la valeur de Kommando est égale à "id" et égale à "readyok" et égale etc. Ce qui évidemment ne peut pas arriver. Ou alors est-ce que c'est moi qui comprends mal ?

Je comprends la même chose.
Peut-être que l'auteur de ce programme s'est tout simplement trompé en confondant par étourderie AND et OR (en c : OR = ||) ?

[Roland Chastain]

Je comprends la même chose.

Merci pour la confirmation.

Peut-être que l'auteur de ce programme s'est tout simplement trompé en confondant par étourderie AND et OR (en c : OR = ||) ?

Oui, c'est probablement ça. Et comme le programme fonctionne, il ne s'en est pas aperçu. Si ça se trouve, en corrigeant l'erreur le programme ne fonctionnerait plus.

J'ai relevé d'autres bizarreries dans le code mais j'ai essayé de les transcrire telles quelles, sauf dans la fonction EngineStarten() où il y avait des choses manifestement inutiles et que je ne savais pas comment traduire.

[Roland Chastain]

Je me demande si j'ai correctement traduit cet endroit :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
      while (isspace(*pEnde) && pEnde >= pAnfang)
        *pEnde-- = '\0';

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
      while (IsSpace(pEnde^) and (pEnde >= pAnfang)) do
      begin
        Dec(pEnde);
        pEnde^ := #0;
      end;

Est-ce qu'il faut décrémenter d'abord et assigner après, comme j'ai fait, ou l'inverse ?

[Roland Chastain]

Ah oui, effectivement, la valeur est assignée puis l'adresse est décrémentée.

Code C :

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
#include <stdio.h>
#include <string.h>
 
int main(void)
{
  char a[] = "123";
  char *p = strchr(a, '2');
 
  printf("%s\n", p); // 23
 
  *p-- = '.';
 
  printf("%s\n", p); // 1.3
 
  getchar();
 
  return 0;
}

Cela fait une erreur de moins. Mais le programme ne fonctionne toujours pas...

[Roland Chastain]

J'ai un doute sur la ligne suivante :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    if (!ReadFile(pLP->hDatei, pLP->pPuffer + pLP->AnzInhalt, pLP->Groesse - pLP->AnzInhalt, &AnzGelesen, NULL))
      FatalerFehler("Lesefehler", hEngine);

Si je la traduis ainsi,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    if not ReadFile(pLP.hDatei, pLP.pPuffer + pLP.AnzInhalt, pLP.Groesse - pLP.AnzInhalt, AnzGelesen, nil) then
      FatalerFehler('Lesefehler', hEngine);

j'obtiens un message d'erreur relatif au second paramètre : "variable identifier expected".

Quelle serait la bonne traduction ?

J'ai trouvé en tâtonnant une écriture que le compilateur accepte, mais je doute que ce soit la bonne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

    if not ReadFile(pLP.hDatei, (pLP.pPuffer + pLP.AnzInhalt)^, pLP.Groesse - pLP.AnzInhalt, AnzGelesen, nil) then

P.-S. Le code source complet se trouve dans le ZIP vers lequel j'ai donné un lien, plus haut dans la discussion.

[bataff]

Bonjour Roland,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (!ReadFile(pLP->hDatei, pLP->pPuffer + pLP->AnzInhalt, pLP->Groesse - pLP->AnzInhalt, &AnzGelesen, NULL))

Si je comprends bien cette ligne et le fichier, il s'agit dans le second argument d'une addition d'un pointeur sur un CHAR (pLP->pPuffer) et d'un entier (pLP->AnzInhalt).
Sinon la fonction ReadFile vient de la bibliothèque windows.h et son second argument doit être un pointeur sur un buffer récoltant les données du fichier à lire.
Donc, si j'ai bien compris, pLP->pPuffer + pLP->AnzInhalt semblerait correspondre à la position -pointée- pLP->AnzInhalt dans la chaîne de caractères pLP->pPuffer .

Le code (en Pascal) @pLP.pPuffer[pLP.AnzInhalt] pourrait alors peut-être convenir ?

Je viens de tester ta solution (pLP.pPuffer + pLP.AnzInhalt)^ par un petit programme plus simple sur des ^char (et de même avec des PAnsiChar) a et b :
b:=@a[2] fonctionne.
b:=a+2 fonctionne et fait la même chose (Ce qui est contradictoire avec la tentative infructueuse pLP.pPuffer + pLP.AnzInhalt ).
b:=(a+2)^ ne fonctionne pas, contrairement à ta dernière solution
(idem pour les 3 tests si je remplace 2 par un LongWord)

Et je ne comprends pas ces différences ... (ou j'ai dû mal comprendre le programme original en C ).

[M.Dlb]

Je tente ma chance !
Pointer(pLP.pPuffer + pLP.AnzInhalt)

Sans aucune certitude

[Alcatîz]

Je traduirais exactement comme Roland :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ReadFile(pLP.hDatei, (pLP.pPuffer + pLP.AnzInhalt)^, pLP.Groesse - pLP.AnzInhalt, AnzGelesen, nil)

[bataff]

Bonjour à tous,

C'est une véritable intrigue. Voilà quelques recherches que j'ai fais :

Sur la routine ReadFile : dans le site de microsoft (ReadFile), elle est répertorié ainsi :

BOOL WINAPI ReadFile(
_In_ HANDLE hFile,
_Out_ LPVOID lpBuffer,
_In_ DWORD nNumberOfBytesToRead,
_Out_opt_ LPDWORD lpNumberOfBytesRead,
_Inout_opt_ LPOVERLAPPED lpOverlapped
);

Pour vérifier comment elle était implémentée dans freepascal, j'ai téléchargé les sources de fpc version 3.0.0 win32 puis, par une ligne de commande avec l'instruction grep, j'ai recherché cette fonction de façon récursive à travers tous les fichiers du package. Je l'ai trouvé uniquement dans /packages/winunits-jedi/jwawinbase.pas :

function ReadFile(hFile: HANDLE; lpBuffer: LPVOID; nNumberOfBytesToRead: DWORD;
lpNumberOfBytesRead: LPDWORD; lpOverlapped: LPOVERLAPPED): BOOL; stdcall;
{$EXTERNALSYM ReadFile}

(uniquement la déclaration, son contenu doit être probablement dans une dll)

fpc a donc respecté fidèlement la déclaration de cette routine de microsoft.
Le second paramètre est un LPVOID. Dans le site de microsoft (ici), je lis que LPVOID est 'A pointer to any type'.

Test de ReadFile :
J'ai tapé ce petit programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
program test_readfile;
uses windows, sysutils;
var a,b : pansichar;
    t : unicodestring;
    h : Thandle;
    n,p : Dword;
begin
  a:='n'; t:='toto.txt'; p:=2;
  h:=fileopen('toto.txt',fmOpenReadWrite);
  if ReadFile(h,(a+p)^,10,n,nil) then 
    writeln('a : ',a,'  Nombre d''octets : ',n)
  else writeln('erreur');
  readln;
end.

(toto.txt est un fichier texte où j'ai écrit -n'importe quoi- : bcdefghijkl
Compilation réussie mais le programme me renvoie 'erreur' (readfile n'a pas accpté ...).

J'ai testé toutes les autres solutions proposées, y compris celle avec pointer : soit la compilation échoue, soit elle réussit et il y a un runtime error à l'exécution, soit elle réussit mais readfile n'accepte pas (=>erreur).
Paradoxalement, ce second argument a beau être 'un pointeur sur n'importe quoi' (lpvoid), aucune solution avec un pointeur fonctionne chez moi.

Par contre, si je déclare a comme char/ansichar ou comme un tableau de char/ansichar ou comme un string, et que je tape dans le second argument a, ça marche ... (le programme donne : bcdefghijk Nombre d'octets : 10 ).

Autre alternative (non testée) : Utiliser une autre routine, plus propre à fpc, permettant de faire la même chose que cette ligne, comme par exemple FileRead de l'unité sysutils ?

[Roland Chastain]

Merci pour vos idées.

J'ai ajouté une ligne que j'avais oubliée (dans la fonction StringLesen()) mais le programme ne fonctionne toujours pas. Dans le journal que le programme produit, on voit que le programme reste bloqué dans cette fonction, je ne sais pas pourquoi. Je crois que je ferais mieux de reconstruire un nouveau programme, morceau par morceau, en m'inspirant du programme existant.

@bataff

Oui, moi aussi, dans les exemples que j'ai vus, ce n'est jamais un pointeur qui est passé comme second paramètre à la fonction ReadFile(). J'ai consulté notamment ce tutoriel (il faut faire une ou deux petites modifications dans le code pour le compiler avec Free Pascal) :

http://alcatiz.developpez.com/tutori...fichier-cache/

Pour les fonctions de l'unité SysUtils, je pense qu'elles appellent les fonctions de Windows (lorsqu'on compile pour Windows, évidemment), donc dans mon cas autant utiliser ces dernières directement.

Je joins le dernier état du code. J'ai ajouté aussi dans le programme original du code pour produire un journal, afin de pouvoir faire une comparaison.

[Roland Chastain]

J'ai trouvé quelque chose.

Voyez cette ligne :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

pLP->pPuffer = realloc(pLP->pPuffer, pLP->Groesse + 1);

Je l'ai traduite ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

pLP^.pPuffer := StrAlloc(pLP^.Groesse + 1);

Mais ce n'est pas la même chose, n'est-ce pas ? Car avec realloc() les données sont conservées.

Voyez-vous quel serait l'équivalent de realloc() ?

[Roland Chastain]

Voici la solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ReAllocMem(pLP^.pPuffer, pLP^.Groesse + 1);

Cela fait un problème de moins.

[Roland Chastain]

Bonjour !

J'ai passé un coup de chiffon dans ce projet. Je vous le propose dans son état actuel, au cas où vous voudriez vous y pencher.

Projet de traduction en Pascal du programme UCI Filter de Volker Annuss.

Pour le moment, seule la version en C fonctionne correctement.

Mode d'emploi

1. Exécutez DEMO.CMD.
2. Dans la console, tapez "uci" puis appuyez sur la touche Entrée. La réponse du moteur UCI s'affiche dans la console.

C:\Atelier\C\chess\ucifilter>ucifilter.exe pharaon\pharaon.exe
uci
id name Pharaon 3.5.1
...

3. Tapez "quit" pour demander au moteur de se fermer.
4. Ouvrez le fichier UCIFILTER.LOG.

Voici le fichier UCIFILTER.LOG :

31/10/2018 11:15:52 471 -> main()
31/10/2018 11:15:52 095 -> HandleDurchPipeErsetzen()
31/10/2018 11:15:52 120 <- HandleDurchPipeErsetzen()
31/10/2018 11:15:52 095 -> HandleDurchPipeErsetzen()
31/10/2018 11:15:52 120 <- HandleDurchPipeErsetzen()
31/10/2018 11:15:52 134 -> EngineStarten()
31/10/2018 11:15:52 151 argv[1]=pharaon\Pharaon.exe Kommandozeile=pharaon\Pharaon.exe DirDrive=pharaon\
31/10/2018 11:15:52 168 <- EngineStarten()
31/10/2018 11:15:52 457 -> EngineNachGuiThreadStarten()
31/10/2018 11:15:52 462 <- EngineNachGuiThreadStarten()
31/10/2018 11:15:52 263 -> GuiNachEngine()
31/10/2018 11:15:52 387 -> EngineNachGui()
31/10/2018 11:15:57 369 -> WriteOption()
...

Maintenant si je compile la version en Pascal, et que je répète la procédure précédente, je n'ai pas la réponse du moteur. Mais il se ferme quand même quand je tape "quit". C'est déjà ça !

La version en Pascal produit aussi un fichier LOG :

31/10/2018 12:31:38 467 -> main program
31/10/2018 12:31:38 089 -> HandleDurchPipeErsetzen()
31/10/2018 12:31:38 128 <- HandleDurchPipeErsetzen()
31/10/2018 12:31:38 089 -> HandleDurchPipeErsetzen()
31/10/2018 12:31:38 128 <- HandleDurchPipeErsetzen()
31/10/2018 12:31:38 137 -> EngineStarten()
31/10/2018 12:31:38 145 CheminMoteur=uralochka\Uralochka11d.exe Dossier=uralochka
31/10/2018 12:31:38 163 <- EngineStarten()
31/10/2018 12:31:38 455 -> EngineNachGuiThreadStarten()
31/10/2018 12:31:38 459 <- EngineNachGuiThreadStarten()
31/10/2018 12:31:38 261 -> GuiNachEngine()
31/10/2018 12:31:38 380 -> EngineNachGui()
31/10/2018 12:31:51 401 <- EngineNachGui()
31/10/2018 12:31:52 500 <- main program

On voit que la procédure GuiNachEngine ne s'est jamais terminée. Non, c'est le fichier log qui était faux.

Voilà où j'en suis. Vous ne pouvez pas dire que je n'ai pas travaillé.

[anapurna]

salut

il y a quelque truc qui ne me parraissent pas tres coherent
ton code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
  lp.hDatei := pFilter.hVonGui;
  lp.Groesse := 10000;
  lp.pPuffer := StrAlloc(lp.Groesse + 1);
  lp.AnzInhalt := 0;
  lp.AnzVerarbeitet := 0;
  if lp.pPuffer = nil then
    FatalerFehler('Nicht genügend Speicherplatz', pFilter.hEngine);
 
  while TRUE do
  begin
    str_ := StringLesen(@lp, pFilter.hEngine);

ce que j'aurais fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
  lp.hDatei := pFilter^.hVonGui;
  lp.Groesse := 10000;
  lp.pPuffer := StrAlloc(lp.Groesse + 1);
  lp.AnzInhalt := 0;
  lp.AnzVerarbeitet := 0;
  if lp.pPuffer = nil then
    FatalerFehler('Nicht genügend Speicherplatz', pFilter^.hEngine);
  
  while TRUE do
  begin
    str_ := StringLesen(@lp, pFilter^.hEngine);
...

Pfilter étant un pointer l’accès à sa variable doit être préfixé non ?

[Roland Chastain]

Salut ! Ah oui, il y a un problème là. Bien vu !

Je vois qu'il y a des endroits dans le code où j'ai mis l'accent circonflexe, et d'autres endroits où je ne l'ai pas mis.

Je compile en mode Delphi. Donc ça ne fait peut-être pas de différence ?