Récupération de vieux programmes en FORTRAN et en PASCAL

bonjour à tous, merci pour votre accueil sur ce forum, dont je découvre la grande richesse.
HISTORIQUE :
Le confinement m'a permis de faire du rangement dans mes cartons. J'ai redécouvert des programmes écrits pendant mes études (1990) en FORTRAN et/ou en PASCAL (V5).
Ces programmes de calculs scientifiques pour l'aéronautique légère (domaine de vol, portance des profils, des ailes ...), possédaient une interface très primaire.
Ces programmes tournaient à l'époque sous PC 80286, en DOS 3.3 et carte graphique Hercules.
Ils ne marchent plus sur mon ordinateur familial actuels (Windows vista) !!
Aussi, j'aimerai les faire fonctionner à nouveau et peut-être même les rendre plus conviviaux !
QUESTIONS / AIDE :
1 - Quel langage et quelle version pourrait reconnaitre ces vieilles versions, éventuellement les mettre à jour et les recompiler ? J'ai vu que DELPHI prenait la suite du Pascal, Est-ce le bon choix pout ne pas tout recommencer ?
2 - Quel éditeur de texte adapté me conseillez-vous ?
Vous trouverez ci-joint un de ces programmes (calcul et représentation du domaine de vol d'un planeur), les sous-programmes associés à l'époque, ainsi que le scan des résultats obtenus en 1991 (cas du planeur JP15-36).
Merci de votre aide, Cordialement.

Bonjour et bienvenue !

Pour faire fonctionner d'antiques programmes écrits pour DOS, rien de tel que... DOS : l'émulateur DosBox est fait pour cela. Il est possible d'y réinstaller Turbo Pascal.

Le compilateur Free Pascal offre une certaine compatibilité avec Turbo Pascal au niveau du langage, mais si le code d'origine contient des appels système de bas niveau ou des accès directs au matériel, je pense que c'est fichu d'avance.

J'ai compulsé les fichiers attachés, que de souvenirs ! :love:

;)

Bonjour et bienvenue !

J'ajoute mon grain de sel à la réponse d'Alcatîz.

Donc, effectivement la solution la plus facile, c'est DOSBox + Turbo Pascal. Encore faudra-t-il apprendre à utiliser DOSBox. Ce n'est pas la mer à boire mais ça va vous demander un effort quand même. Ensuite votre logiciel aura toujours besoin de DOSBox pour fonctionner. Mais bon, pourquoi pas ? Si vous voulez partager votre logiciel avec quelqu'un, vous pourrez faire un paquetage prêt à l'emploi incluant DOSBox.

Maintenant il y a une autre possibilité, qui demandera des modifications importantes dans le code, mais qui vous évitera la contrainte d'utiliser DOSBox, et qui vous permettrait d'avoir un rendu plus joli. Ce serait d'utiliser Free Pascal avec l'unité WinGraph. Vous aurez à refaire toute la base de l'affichage, mais sans avoir à changer l'architecture du programme. Ça vous prendra plus de temps mais au bout du compte vous aurez peut-être quelque chose de mieux. Pour vous faire une idée, je vous conseillerais de télécharger l'unité WinGraph et de compiler et d'exécuter le programme de compilation.

Concernant l'éditeur de texte, personnellement je recommanderais Geany ou Notepad++. Autrement Free Pascal est livré avec un éditeur qui ressemble à celui de Turbo Pascal.

Voilà, bon courage !

P.-S. Pour répondre explicitement à votre question sur Delphi, non Delphi n'est pas la solution, puisque vous ne voulez pas tout refaire.

Au cas où, voici la démo WinGraph compilée.

Merci beaucoup à Alcatiz et Roland Chastain pour vos conseils éclairés que je vais mettre en application.
Ne voulant pas réinventer l'eau chaude, je vais essayer de commencer par refaire tourner mes vieux programmes, dont certains sont encore sur disquettes 5 pouces 1/4, avec le couple "DOSBox + Turbo Pascal".
En parallèle je vais récupérer Geany, Notepad++ et wingraph et me pencher sur leur emploi !
Voici de quoi m'occuper bine sérieusement pendant le confinement !!
Au plaisir de vous lire !
Pascalement !
Patrick

Bonjour,

Ce code rappelle des temps anciens. L'usage important des majuscules pour avoir quelque chose de lisible alors. La découverte embryonnaire des variables locales. Un code qui doit gérer par le menu toute l'interface utilisateur. Etc.

Cependant il y a aussi des choses surprenantes qui mériteraient d'être regardées de près. Par exemple, dans la procédure DOMRAF on trouve ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

VF := (6*V2*COEF) + (2*VS/SQRT(5))*SQRT(45*V2*COEF2 + 1); // ? VF := 6*(V2*COEF + VS*SQRT(V2*COEF2 + 0.0222222)); ... for NN := 2 to 10 do begin A1[NN, 1]:= VS; A1[NN, 2]:= 1.25*(VS/VS)*(VS/VS)*(0.1*NN); // A1[NN, 2]:= 0.125*NN; Question : Est-ce voulu que A1[2, 2] := A1[1, 2] + 0.250; mais A1[i, 2] := A1[i-1, 2] + 0.125 pour i > 2 ? end; ... FOR NN:= 2 TO 10 DO BEGIN B1[NN, 1] := VSD; B1[NN, 2] := -0.125*(VSD/VSD)*(VSD/VSD)*NN); // B1[NN, 2]:= -0.125*NN; END;

---

Je ne sais pas si ce sont des choses sans conséquence.

Par ailleurs de nombreuses expressions pourraient gagner en efficacité (mais cela n'a peut être pas d'intérêt ici). Exemple, on trouve souvent ce genre de code :

Code:

---

1 2 3 4

FOR V:= VMax1 TO VDMax DO BEGIN // VMax = Trunc(VA) + 1, VDmax = Trunc(VD) + 1 A[V, 1]:= V; A[V, 2]:= ((N1-NR[2])/(VA-VD))*V+N1-((N1-NR[2])/(VA-VD))*VA; END;

---

Qui peut déjà se simplifier en :

Code:

---

1 2 3 4

FOR V:= VMax1 TO VDMax DO BEGIN A[V, 1]:= V; A[V, 2]:= N1 + (NR[2]-N1)/(VD-VA)*(V-VA); // On voit mieux une droite qui va de (N1 à NR[2] END;

---

Qui donne l'opportunité de faire apparaître un coefficient fixe a :

Code:

---

1 2 3 4 5

a := (NR[2-N1])/(VD-VA); FOR V:= VMax1 TO VDMax DO BEGIN A[V, 1]:= V; A[V, 2]:= N1 + a*(V-VA); END;

---

Après avoir fait tourner le code initial, une reprise pourrait s'avérer impressionnante. Avec les outils actuels, débarrassé en grande partie de la gestion de l'interface utilisateur, je pense que le code devrait se réduire à 300 ou 400 lignes (hors les objets générés automatiquement).

Salutations

Salut pour le fun, je suis entrain de transcrire ton petit soft sous Lazarus, et d'essayer de comprendre les calculs et les différents paramètres (pas facile, car les noms de variables ne sont pas très explicites, mais bon, pas trop grave). Il aurait été sympa d'avoir les fichiers .FEN ou au moins des captures de celles-ci (menu principal, entrée des valeurs) comme celles dans dans le PDF

Pièce jointe 575049

A+

Jérôme

Bonjour Jérôme,

Tu as du courage d'autant qu'il va falloir séparer le code utile du code IHM et celui propre aux bibliothèques graphiques de l'époque. Je pense par exemple que tous les segments de droites dans des boucles XY vont disparaître. Mais le filtrage va être assez difficile : le manque de commentaires et l'usage quasi général de variables globales brouillent bien les pistes.

Amuse-toi bien :mrgreen:

Salut, Jérôme,

et pendant que tu y es, pense à corriger tes Kg et Km en kg et km (même si on voit cette erreur partout, ce n'est pas la peine de la répandre encore plus).
:zoubi:

Citation:

---

Envoyé par Guesset

Bonjour Jérôme,

Tu as du courage d'autant qu'il va falloir séparer le code utile du code IHM et celui propre aux bibliothèques graphiques de l'époque.

---

Salut, pour la séparation du code ça va, ce n'est pas trop le problème sauf une ou deux sur la saisie des données dont je ne sais pas dans l'ordre les appliquer.

Les codes des sous-routines ne servent d'ailleurs que pour l'affichage graphique, mis à part une ou deux méthodes.

Citation:

---

Envoyé par Guesset

Je pense par exemple que tous les segments de droites dans des boucles XY vont disparaître.

---

Surement et c'est la le plus gros challenge, la mise en place du graphique avec TAChart. Il va valloir surement que j'ajuste les données.

Citation:

---

Envoyé par Guesset

Mais le filtrage va être assez difficile : le manque de commentaires et l'usage quasi général de variables globales brouillent bien les pistes.

Amuse-toi bien :mrgreen:

---

Je commence tout juste à décoder ce que veulent dire les variables en acronymes, et c'est clair que c'est plutôt difficile, comme tu le dis avec l'usage quasi général de variables globales. Et la non séparation des calculs. Et c'est la qu'il faut supprimer tout ce qui a un rapport avec l'IHM

Pour le moment je m'en sort pas trop mal avec les calculs, me reste à remplir la grille avec les résultats

Le plus dur à comprendre c'est l'utilisation du tableaux DAT, un peu sioux, et le nommage des données calculées par des lettres, on ne sait pas vraiment à quoi cela correspond.

Si @Planiste pourrait se manifester, pour plus de détails et répondre à certaine question, cela serait sympa.

Citation:

---

Envoyé par Jipété

Salut, Jérôme,

et pendant que tu y es, pense à corriger tes Kg et Km en kg et km (même si on voit cette erreur partout, ce n'est pas la peine de la répandre encore plus).
:zoubi:

---

Ok :oops::ccool:, je prend note, merci :zoubi:

A+

Citation:

---

Envoyé par BeanzMaster

Si @Planiste pouvait se manifester, pour plus de détails et répondre à certaine question, cela serait sympa.

---

Envoie-lui un email, un vrai : colonne de gauche, 3^e ligne.

Il y a quelques années, j'ai fait tourner sous Delphi des sources écrits pour DOS en Turbo-Pascal grace à Pasw32.
http://sunsite.icm.edu.pl/delphi/d20free/w32pas11.txt

Bonjour Jérôme,

Citation:

---

Envoyé par BeanzMaster

Le plus dur à comprendre c'est l'utilisation du tableaux DAT, un peu sioux, et le nommage des données calculées par des lettres, on ne sait pas vraiment à quoi cela correspond.

---

Je crois que la plupart des tableaux en une lettre (genre A, B, B1 ...) sont des tableaux de type x,y (tableaux à deux dimensions dont la deuxième 1..2 désigne X et Y). Ils devraient donc disparaître sous cette forme : ils ressemblent à des polylines utilisées, pour la plupart, à simplement tracer des segments de droites (avec un ajustement d'arrondi sur le dernier point).

Salut

Citation:

---

Envoyé par Guesset

Bonjour Jérôme,



Je crois que la plupart des tableaux en une lettre (genre A, B, B1 ...) sont des tableaux de type x,y (tableaux à deux dimensions dont la deuxième 1..2 désigne X et Y). Ils devraient donc disparaître sous cette forme : ils ressemblent à des polylines utilisées, pour la plupart, à simplement tracer des segments de droites (avec un ajustement d'arrondi sur le dernier point).

Salut

---

Salut, oui c'est que j'ai noté aussi. Du coup je vais voir si je passe par TAChart ou si je dessine le graph dans un Bitmap, ou via un TPaintBox

Vu que j'avais besoins de plus d'éclaircissement sur les menus et choix des options j'ai réussi à compiler le programme via un vieux TP7 tournant sous DOSBox trouvé sur SF Après pas mal de petite correction, car le prog à été fait sous TP4 ou 5. Ca fonctionne mais malheureusement sans les fichiers adhoc *.FEN, Error.msg nada. Je vais voir si je peux m'en passer.

Une petit utilitaire, complémentaire à DOsBox que j'ai oublié de mentionné permettant de lancer des applications pour DOS : D-Fend Reloaded (je m'en sert souvant pour lancer de vieux jeux ou demos graphique

A+

Jérôme

salut

les fichier FEN ne sont que des fonds d'ecran
il n'intervienne pas dans le fonctionnement de l'appli
il te suffit d'ouvrir windows.sys avec un editeur de texte
et lire la fonction loadwindows ou savewindows
cela permet de mettre en place un masque d'ecran

Salut,

Citation:

---

Envoyé par anapurna

salut

les fichier FEN ne sont que des fonds d'ecran
il n'intervienne pas dans le fonctionnement de l'appli
il te suffit d'ouvrir windows.sys avec un editeur de texte
et lire la fonction loadwindows ou savewindows
cela permet de mettre en place un masque d'ecran

---

Oui je sais, mais sans ces fichiers impossible de compiler l'application. Donc c'est pour cela que des captures d'écran de ces fenêtre pourraient aider à comprendre un peu mieux le code.
Niveau mathématique, les calculs ne sont pas très précis en plus. Par exemple le coef de gravité est arrondi, entre autre. D'après ce j'ai pu déduire et comprendre des formules et d'une discussion avec mon père qui est féru de FligthSimulator et qui est plutôt balaise niveau maths ;)