Fonctionnement de la procédure EXEC

**DUGUERPF** · 31/01/2009, 20h39

Bonjour à tous !

Je m'amuse donc à développer un wargame depuis longtemps et la taille des fichiers augmentant, il m'est devenu impossible de tout garder avec un seul programme principal. Après avoir tourné en rond, désespéré comme il se doit, j'avais réussi à trouver dans la documentation, à l'époque, une procédure qui semblait résoudre ma difficulté et qui l'a fait pendant quelques années : EXEC.

En clair, j'ai créé un petit programme qui, par le biais de cette procédure EXEC, permettait de lancer le programme correspondant au besoin du moment. Pour passer l'information quant au programme à lancer, il suffisait de créer à chaque fin de programme un fichier temporaire qui donnait le nom du programme suivant à lancer, fonction des ordres données par l'utilisateur. Sinon, à défaut de fichier, il savait qu'il devait lancer le menu du jeu.

Voici ce que donnait la partie principale de ce petit programme. ANAMNA est le nom du wargame, de mon univers de jeu de rôle et de ce programme. ANAMNAD est le "début" (présentation animée du jeu "échappable") et ANAMNAM est le menu du jeu.

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
 
BEGIN
   LigneCmd:='';
   NomProgram:='ANAMNAD.EXE';
   SwapVectors;
   Exec(NomProgram, LigneCmd);
   SwapVectors;
   NomProgram:='ANAMNAM.EXE';
   SwapVectors;
   Exec(NomProgram, LigneCmd);
   SwapVectors;
   repeat
      {$I-}
      assign(ff,'ANAMNA.TMP');
      reset(ff);
      {$I+}
      readln(ff,version);
      if version<>ver then begin
         close(ff);
         efface_tous_les_fichiers_inutiles;
         textcolor(15);
         clrscr;
         writeln('ERREUR LANCEMENT PROGRAMME ''LES GUERRES D''ANÄMNA"')
         writeln('LANCEMENT INTERROMPU...');
         writeln;
         writeln('@ DUGUERPF / Les guerres d''AnäMna / 1996-2009 / ver 3.0.2703');
         halt;
      end;
      readln(ff,texte);
      if texte<>'FIN DU JEU' then begin
         NomProgram:=texte;
         SwapVectors;
         Exec(NomProgram, LigneCmd);
         SwapVectors;
      end;
      close(ff);
   until texte='FIN DU JEU';
   efface_tous_les_fichiers_inutiles;
   textcolor(15);
   writeln('@ DUGUERPF / Les guerres d''AnäMna / 1996-2009 / ver 3.0.2703');
END.

Et maintenant, la question : tout cela fonctionnait parfaitement jusqu'à WIN98, mais tout plante sous WINXP et plus. Quelqu'un a-t-il une soluce ?

**Alcatîz** · 01/02/2009, 11h14

Bonjour,

Tu peux essayer de réduire la taille allouée pour le tas de ton programme appelant avec la directive

Code :

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

{$M TaillePile,0,TailleTasMaxi}

**DUGUERPF** · 02/02/2009, 04h03

En fait, actuellement, ma commande est :

Code :

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

{$M $4000,0,0}

Mais, quelques soient les modifications, cela ne passe pas, y compris ce qui me semble le max :

Code :

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

{$M 16384,0,655360}

Euh, ai-je oublié de dire que de toute façon je ne comprends rien à cette commande ? De fait, les tas de mémoire, les piles et tout ça, c'est chez moi un peu comme les pointeurs. Pas brillant !

La ligne de commande que j'utilise était celle proposée dans l'aide fournie par TP pour la procédure EXEC...Elle ne me doit rien.

**Alcatîz** · 02/02/2009, 12h39

Envoyé par DUGUERPF

En fait, actuellement, ma commande est :

Code :

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

{$M $4000,0,0}

Un tas de 0 octet : je suppose donc qu'il n'y a pas d'allocation de mémoire dynamique dans ton programme ?

Mais il faudrait peut-être augmenter la taille de la pile car je pense que le programme appelé utilise la pile de l'appelant (je ne peux vérifier actuellement car je suis au boulot).

Pour détailler les différents paramètres de la directive $M :

La pile est la zone de mémoire dans laquelle sont déposés tous les paramètres passés aux différentes routines, où sont déposées les adresses de retour au code appelant, où sont effectuées les sauvegardes de registres, où sont allouées toutes les variables locales. Lorsque la pile déborde, c'est pratiquement le crash assuré; il ne faut donc pas définir une taille de pile trop petite. Essaye par exemple une taille de 16384 octets (ou même plus, la limite étant 64 Kb).

Le tas est la zone de mémoire dans laquelle ton programme va allouer ses variables dynamiques. Par défaut, un tas de 640 Kb est alloué à ton programme, sauf si tu définis un tas de plus petite taille.

La directive {$M TaillePile,TasMini,TasMaxi} signifie :

TaillePile = la taille de la pile, qu'il faudrait donc essayer d'augmenter
TasMini = la taille minimale du tas (en général 0)
TasMaxi = la taille maximale du tas

**DUGUERPF** · 04/02/2009, 03h54

Allocation de mémoire dynamique (essaie de prendre l'air sérieux du gars qui comprend la question et devine que la réponse n'est pas simple...).

Pour tout dire, encore un des mystère informatique pour moi. En fait, tas, pile et pointeurs sont liés dans ma découverte de TP et surtout dans mes incompréhensions, même si sur le papier cela paraît évident.

Note que j'ai essayé en mettant tous les paramètres au maximum de ce qu'offre la commande de compilation et que cela plante aussi. Mais cf pb avec les drivers souris : je vais essayer sous environnement DOS complet. On verra !

**darrylsite** · 04/02/2009, 18h59

J'aimerai bien pouvoir tester le wargame. Le jeu doit etre super genial.

**DUGUERPF** · 05/02/2009, 01h36

Super génial ??

Je ne sais pas. Mais une série de test par d'autres personnes, cela pourrait m'ouvrir de nouveaux horizons. Je l'avais fait pour le wargame en jouant par internet avec des volontaires pour dérouler les guerres affectant mon univers de jeu de rôle...Je ne l'ai pas fait encore pour le petit jeu de plateau.

Dés que j'aurai fini la traque absolue des derniers bugs et d'écrire la règle du jeu et un léger descriptif des commandes, je proposerai le jeu "ESPACE" via le site (et aussi dés que je saurais comment faire

). Très brièvement un jeu de plateau de 10x8 (parce que en 640x480...Bouh....), où chaque joueur démarre sur un côté avec des "neutres" au milieu (le nb de "neutre" ainsi que certains paramètres de la carte sont paramétrables). Chaque système possède un niveau de défense (0-3) et des ressources (0-9). Le vainqueur est celui qui, dans le nb de tour imparti, obtient le maximum de points (points = nb ressources possédés+nb_systèmes possédés+nb points de flotte détruits au combat). Ce que j'ai souhaité d'original (mais inspiré de Full Metal Planet) est que la table de combat ne fait pas intervenir de jet de dé aléatoire. Le résultat du jet est toujours de 1 sur 6 +/- un certain nombre de modificatifs (expérience de chaque flotte, le nombre de flottes encerclant l'ennemi et participant au combat, défense du système s'il appartient au défenseur, etc...). Enfin, chaque joueur (pas les neutres) possède un certain nombre de bonus qu'il peut utiliser pour augmenter les dégâts faits.

Le wargame est bien plus compliqué et surtout, en l'état, il ne fonctionne plus que par la plateforme TP7, ie, il faut lancer manuellement chaque "sous-programme", précisément parce que je ne parviens plus à faire le lien entre tous les sous-programmes par la procédure EXEC (CDFD de la question qui nous préoccupe...). Mais je peux l'envoyer avec quelques explications au besoin. J'ai toujours un bug majeur que je n'arrive pas à recaler, même si je l'ai isolé. Il me reste à déterminer pourquoi...(en clair, quand une unité est forcée de se replier et est détruite, il lui arrive de laisser un "fantôme" dans l'hexagone occupé qui ensuite empêche d'utiliser l'hexagone, le programme le lisant toujours comme "occupé". Le pire c'est que cela arrive parfois, pas toujours, donc difficile de débugger LE cas qui plante et qui semble très particulier).

**richard** · 07/02/2009, 18h18

Bonjour,

Je vais peut-être dire une sottise mais je m'interroge sur la nécessité de la procédure EXEC dans ce cas. N'eût-il pas été plus efficace de compiler ces sous-programmes sous forme d'unités et de les appeler via un programme principal qui aurait la même forme mais ne comporterait que les noms du programmes principaux de lancement de chaque unité au lieu de tous ces 'EXEC' ?
A priori la compilation séparée implémentée par le Pascal UCSD et reprise par Turbo et FreePascal sert exactement à cela, je crois.

**DUGUERPF** · 10/02/2009, 05h59

Il n'y a jamais de sottises, Richard !

Mais le problème, c'est que toutes les unités ensembles, et les programmes transformées en unité, cela explosait la limite maximum de TP7, y compris en virant les options de debugging du compilateur. C'est pour cela que j'ai du séparer le programme, chaque programme principal utilisant globalement les mêmes unités en fait. Je dis peut-être une bêtise, mais il me semble que la limite de TP7 est à 64k pour la compilation d'un programme, unités comprises (ne pas hésiter à éditer si je dis une ânerie).

A moins de réduire la taille de chaque programme, ce qui était impossible vu ce que je lui demandais de faire. Pardon, ce qui me parait impossible, tout en étant suis sûr que des pros de programmation et de Pascal y parviendraient (aprés s'être énervés sur mes algorithmes et ma façon de faire

).

A titre indicatif, un des programmes ainsi découpé atteint déjà lui-même la taille maximale, m'ayant obligé à une révision complète de ses procédures pour qu'il fonctionne sans que je doive le redécouper ! C'est d'ailleurs depuis que la procédure EXEC ne fonctionne plus, ma laissant à penser qu'il est peut-être trop "gros" même pour cette procédure...

Voilà pourquoi je n'ai pas pu utiliser la procédure "classique"...Et que je suis toujours un programmeur en errance car du coup mon programme n'est plus "passable" car il ne fonctionne plus que sous TP7 ouvert et en manipulant les fichiers directement (

)...

**droggo** · 10/02/2009, 13h07

Beo,

En clair, beaucoup d'ennuis juste pour ne pas vouloir passer à un compilateur moderne et laisser les dinosaures dans leur placard.

**darrylsite** · 10/02/2009, 19h04

Envoyé par droggo

Beo,

En clair, beaucoup d'ennuis juste pour ne pas vouloir passer à un compilateur moderne et laisser les dinosaures dans leur placard.

J'ai cru comprendre qu' apres avoir lancé un exe, il revient toujours à la procedure principale pour determiner quelle exe il faut encore lancer.
Alors je me suis dis, pourquoi ne pas trouver une solution hybride lazarus/tp7.
On peut bien avoir une interface lazarus qui lance les processus à chaque fois qu'il est necessaire.

Ce sera un bel exemple de collaboration compilateur temps ancien/ temps moderne

**droggo** · 10/02/2009, 20h44

Gea,

Envoyé par darrylsite

Alors je me suis dis, pourquoi ne pas trouver une solution hybride lazarus/tp7.
On peut bien avoir une interface lazarus qui lance les processus à chaque fois qu'il est necessaire.

Lazarus ou FreePascal tout seul sauront parfaitement gérer tout ça sans faire appel à des exécutables différents, qui ne sont appelés successivement que pour outrepasser les limitations de TP.

On a là un exemple typique de ce qu'il est désormais absolument inutile de faire, les outils permettant de s'en passer existant depuis assez longtemps déjà, et étant donc bien rodés.

**DUGUERPF** · 11/02/2009, 04h48

Dans le fond, DROGGO a bien évidemment raison, d'où d'ailleurs ma volonté de passer à quelque chose de plus récent, et mon premier sujet sur ce forum. A la fois la volonté d'avoir quelque chose de plus puissant, plus souple et aussi graphiquement plus abouti.

Je ne dis pas que je n'irai pas (à preuve, Freepascal est toujours sur mon ordi et je programme des petits trucs dessus pour m'habituer). Mais passer un programme de dix ans dans cette "nouvelle interface" Pascal, et bien cela prend un temps que je n'ai pas (pour l'instant).

Imagine, je n'arrive même pas à faire tourner quelques centaines de lignes pour le jeu dans l'espace, alors qu'à la compilation, il ne me signale aucune erreur. Alors, le temps de chercher la cause....

Donc, dans le fond, tu as raison, mais il est vrai que je cherchais une solution plus immédiate pour au moins pallier à mon pb d'EXEC.

Enfin, et là je peux me tromper, mais l'installation de FreePascal nécessite les droits ADMIN, et là où je travaille, c'est impossible. Alors que TP7...ben, il se glisse partout, même sur des ordis méga-surveillés, et je peux faire tourner tout ce que je veux avec. Donc, les anciens, cela a parfois du bon

**droggo** · 11/02/2009, 13h14

Boe,

Envoyé par DUGUERPF

Donc, les anciens, cela a parfois du bon

Peut-être, MAIS pas pour ce que tu penses : ils permettent surtout de montrer les trous de sécurité des versions de Windows.

**darrylsite** · 11/02/2009, 13h57

Envoyé par droggo

Gea,

Lazarus ou FreePascal tout seul sauront parfaitement gérer tout ça sans faire appel à des exécutables différents, qui ne sont appelés successivement que pour outrepasser les limitations de TP.

On a là un exemple typique de ce qu'il est désormais absolument inutile de faire, les outils permettant de s'en passer existant depuis assez longtemps déjà, et étant donc bien rodés.

J'ai dit ça parce que le programme existe dejà sous tp7. Il sera plus rapide de faire les exe et de les lancer avec freepascal comme alternative à tp7 qui pose des problemes de memoire.
Comme il le dit, s'il doit adapter son programme pour que ça fonctionne bien sous freepascal (choix d'une bibliotheque graphique,...) sachant que ça fait plusieurs lignes de codes alors, je me dis que la solution la plus simple et rapide serait de lancer les exe comme l'ai dit plus haut.

**droggo** · 11/02/2009, 14h38

Goe,

Envoyé par darrylsite

J'ai dit ça parce que le programme existe dejà sous tp7. Il sera plus rapide de faire les exe et de les lancer avec freepascal comme alternative à tp7 qui pose des problemes de memoire.
Comme il le dit, s'il doit adapter son programme pour que ça fonctionne bien sous freepascal (choix d'une bibliotheque graphique,...) sachant que ça fait plusieurs lignes de codes alors, je me dis que la solution la plus simple et rapide serait de lancer les exe comme l'ai dit plus haut.

Je ne pense pas.

L'adaptation de TP à FP n'est pas vraiment difficile, et la solution retenue avec l'exécution successive de plusieurs .exe sera probablement à revoir (niveau découpage des exe, etc.) en cas d'évolution ultérieure du programme, ce qu'il faut toujours envisager, et encore plus pour un jeu.

Donc le travail fait actuellement sera certainement remis en cause, alors qu'une adaptation ...

En clair, beaucoup de travail fait, et probablement à refaire plus tard, pour s'en éviter un peu, qui ne sera pas à refaire.

Sans même parler de l'évolution des OS qui finiront par carrément refuser tous ces vieux programmes ("vieux" pris au sens : archaïques sur le plan matériel mis en jeu).

**darrylsite** · 11/02/2009, 15h22

Envoyé par droggo

Goe,

Je ne pense pas.

L'adaptation de TP à FP n'est pas vraiment difficile, et la solution retenue avec l'exécution successive de plusieurs .exe sera probablement à revoir (niveau découpage des exe, etc.) en cas d'évolution ultérieure du programme, ce qu'il faut toujours envisager, et encore plus pour un jeu.

Je parlais du mode graphique. Les fonctions et les procedés sont pas les meme pour tp7 et openGL par exemple.

**Alcatîz** · 11/02/2009, 18h00

Les programmes Turbo Pascal utilisant l'unité Graph, une fois recompilés avec Free Pascal, s'exécutent dans une nouvelle fenêtre et non dans la console, ce qui est très différent.

Au sujet d'un programme Free Pascal (Lazarus) qui lancerait les différents exécutables compilés avec Turbo pascal, il ne faut pas oublier que ceux-ci s'exécuteraient dans une machine 16 bits virtuelle (NTVDM.EXE).

**darrylsite** · 11/02/2009, 19h57

Envoyé par Alcatîz

Les programmes Turbo Pascal utilisant l'unité Graph, une fois recompilés avec Free Pascal, s'exécutent dans une nouvelle fenêtre et non dans la console, ce qui est très différent.

Au sujet d'un programme Free Pascal (Lazarus) qui lancerait les différents exécutables compilés avec Turbo pascal, il ne faut pas oublier que ceux-ci s'exécuteraient dans une machine 16 bits virtuelle (NTVDM.EXE).

freePascal considere maintenant l'unité graph comme obsolete.

**DUGUERPF** · 12/02/2009, 02h25

Je reviens sur la remarque concernant l'obsolescence de Graph sous FreePascal.

Inutile de dire que pour un jeu, c'est évidemment l'unité maîtresse du dispositif !
Question complémentaire : cela pourrait-il être la raison pour laquelle, même si Freepascal en mode "TP" réussit la compilation (aspect technique) ne parvient pas à exécuter l'ancien programme ?

Sinon, j'ai bien l'intention de venir à Freepascal. Les arguments développés sont évidemment tous justes.

Mais il est vrai que je ne sais pas trop où ou quoi chercher qui ne fonctionne pas et désactiver un programme complexe où tout s'imbrique procédure par procédure n'est pas facile pour trouver ce qui déplaît à Freepascal...

Mais il ne sera pas dit que je ne tenterai pas ! Et après réflexion, je vais me mettre ce WE sur la solution de darylsite. Ce premier exécutable est très court et sans graphisme, utilisant uniquement la fonction lecture d'un fichier qui est aussi très courante dans tout le programme pour stocker tous les hexagones/unités et leurs graphismes sur le disque dur. Ce sera un premier pas.
Ensuite, j'attaquerai morceau par morceau...

Fonctionnement de la procédure EXEC

Turbo Pascal

Discussions similaires

Partager

Partager