[TP]Convertir Delphi en BP7

Bonsoir à tous,

Je cherche un petit utilitaire freeware qui me permettrait de convertir certain fichier source Dephi au format Borland Pascal 7. Les fichiers à recompiler sont le plus souvent des unités (donc pas d'interface graphique, ni d'acces aux fonctionnalités de windows) qui doivent pouvoir tourné sous MS-DOS 16 bits. Je pourrais vérifier les programmes à la "main" et apporter moi-même les modification, mais certain de ces sources sont plutôt longs. A vrai dire, j'ai trouvé sur le web exactement ce que je recherchais, mais en Delphi, alors que je programme sous Borland Pascal 7. L'idée, c'est de gagner du temps... D'ou ma question...

J'ai cru comprendre qu'il existait une version spéciale du compilateur Delphi qui permettait de compiler des programmes en ligne de commande et en 16 bits. Ce compilateur, est-il toujours présent dans les versions récente de Delphi ? (attention, la présence ce de compilateur "spéciale" n'était apparament pas documenté... il était livré avec la version 2)

La compatibilité Delphi / Borland Pascal est-elle totale ou doit on réécrire certain bout de code en BP7 ignoré par Delphi ? Si je pose cette question c'est parce que le projet sur lequel je travaille utilise pas mal d'Assembleur Inline en attaquant le système à la base...

Merci d'avance pour toutes vos réponses,

C'est totalement ridicule, il faut que tu fasse l'inverse, passer à delphi

Les libs graphique de BP 7 sont différentes de Delphi, et Delphi à définitivement remplacé BP 7 depuis de trèsnombreuses années.

Epictéte ... à raison :-|

COmpiler du delphi avec Tp7, c'est pas possible.

pour le compilateur delphi pour le dos, il suffit de faire nouveau --> application controle...

@++ Mathieu

Pascail.... BP7 est TP 7 c'est pas la meme chose....

Bonjour,

Malheureusement non. Je ne peux pas passer à Delphi. En effet, l'application sur laquelle je travaille est une application embarquée. A vrai dire, elle fera partie d'un lecteur/enregistreur multimédia de salon évolutif, capable de lire/écrire n'importe quel format audio et vidéo. (dont le DivX, toutes versions confondues) C'est un produit hybride mi-informatique, mi-électronique. Pour y stocker son OS orienté multimédia, OS conçu par mes blanches mains, je me suis donné 4 MB de mémoire flash. C'est peu pour y placer Windows et encore moins pour y stocker des applications Delphi. Il faut savoir que mon application attaque le hardware à sa base, donc tout a été écrit en assembleur. Les fichiers sont donc très lèger. Le pascal, je l'utilise pour "l'enrobage", c'est à dire pour la détection et l'affichage des information sur l'écran TV ou sur l'écran LCD. (notamment) C'est amplement suffisant. L'idée, c'est de convertir les unités de ce site : http://jfaul.de/atl/ afin que je puisse afficher les ID de ces formats reconnu aujourd'hui par mon lecteur de salon (MP3, Ogg Vorbis, MPC, etc).
J'ai donc deux solutions : soit je réecris tout en fonctions des specs techniques des formats (ce que j'ai commencé à fair avec le MP3, mais c'est long), soit je reussi à convertir ces fichiers Delphi en Pascal pur (BP7) et je gagne du temps... Je pourrais alors me consacrer à l'option "encodage" (MP3, Ogg Vorbis, etc) de mon lecteur de salon. J'espère avoir été plus clair...
Personnellement, j'attends une réponse simple : oui, c'est possible avec l'url du logiciel en question, ou non ce n'est pas possible et à ce moment je prendrais le temps de refaire toutes ces unités en pascal pur... J'ai commencé à les étudier et apparament il y a peu d'accès aux nouvelles fonctions de Delphi et encore moins aux fonctionnalités de Windows. Cependant, je ne suis pas un expert en programmation orienté objet ou en RAD. Je suis de la veille école qui programme encore en Pascal/C/ASM sous DOS 16/32 bits. D'ou ma petite question...

quand vous parlez de compilateur spécial 16 bits, je pense que vous
faites allusion à DELPHI 1 immédiat successeur de BP7

il était livré sur le CD de Delphi 2 et je crois sur celui de Delphi 3 et 4

Bonjour,

Il me semble... Cependant, n'ayant jamais eu de compilateur Delphi entre les mains je ne peux vous répondre avec certitude. J'avais lu ça sur certain forum dédié, sans plus. L'idée c'est de compiler du Delphi comme si c'était du Borland Pascal 7 (pour éviter la conversion du Delphi en BP7) autrement dit : il faut que ça tourne sous DOS 16/32 bits (via DOS4GW ou PMODE, peu importe)
Au risque de de me répéter, les unité en questions ne font pas accès au potientiel de Windows. Il y a juste certaine fonctionnalité spécifique à Delphi que je souhauiterais éviter de convertir en BP7 (comme l'unité Classes par exemple) J'aimerais juste pouvoir gagner un peu de temps...

Je suis désolé mais je ne crois qu'on puisse compiler des sources directement issues de Delphi avec BP7. Des unités à la rigueur ( il me semble que c'est ce que vous utilisez )... Une bonne idée serait d'essayer de compiler le tout avec un très vieux Delphi comme HRS y faisait allusion : Delphi1, 2 voire 3. Sinon cela doit être possible en utilisant BP7 pour le mode Window, mais apparemment ce n'est pas ce que vous cherchez. Je crois que la meilleure solution est de retaper les codes ( ou faire un copier/coller ! ) pour les complier en mode réel sous BP7. A moins qu'il existe un programme qui pourrait convertir les sources ( à mon avis non )...
a+

Bonjour,

Je suis plutôt surpris... En effet, les fichiers PAS de Dephi peuvent parfaitement s'ouvrir avec BP7, je vous pas pourquoi je devrais faire un couper-coller. De plus, comme je l'expliquais je travaille en "mode protégé" via PMODE ou DOS4GW (pour avoir acces à toute la mémoire), il est donc hors de question de travailler en "mode réel" pour ces quelques unités.
De plus, certaines unités spécifiques à Delphi n'existent pas en Pascal (comme l'unité Classes) A mon avis, la solution la plus simple serait de faire un portage de ces unités Delphi en Pascal. Cela ne devrait pas être trop dur mais ça va me prendre pas mal de temps... C'est fort regrettable.
En outre, toutes les réponses obtenus tournent autour de Windows ce qui a de quoi surprendre : en effet, la plupart des applications embarqués, utilisées dans le secteur industriel, tourne encore sous DOS. La raison en est simple : sa stabilité et la légereté. Personnellement, c'est exactement ce que je recherche... Il faut savoir que le développement électronique de la plupart des lecteurs de DVD utilise le même principe que le mien : attaquez les composants électronique directement en assembleur. Il existe bien des "basics" qui permettent de faciliter la tache du programmeur, cependant certaine fonctionnalité (multimédia notamment) ne sont accessible qu'en assembleur. L'intêret est donc léger, sauf pour débuter... Il n'y a que certain application, orienté explicitement Windows CE, qui échappe à cette régle... (ordinateur de bord dans les automobiles, PDA, etc) Finalement, on voit Microsoft de partout. Mon projet offre une compatibilité MS-DOS 7 mais il est 100% indépendant des produits de Microsofts car rien de mon code n'appartient à Microsoft...
Je sais ce qui me reste à faire... Dommage pour moi ! (notez que c'est ce que je fait depuis le début de mon projet, ça ne va pas me changer)

Cordialement,

Oui, oui, les fichiers s'ouvrent normalement avec BP7 mais je voulais parler de la structure particulière des fichiers sources Delphi qui est différente de la structure d'une source BP. Egalement en parlant de mode réel, je pense "mode qui n'a pas besoin de Windows", donc réel et protégé. C'est vrai, l'assembleur a des propriétés exceptionnelles car il permet de manipuler au plus près la machine et le hardware.

Bon courage pour votre projet ( qui semble assez compliqué néanmoins ! )
Une question : C'est vous qui avez construit (et assemblé électroniquement ) votre "lecteur de salon" ?

a+

Bonsoir,

En effet, je me suis occupé de tout : de la conception de certain PCB à la programmation des composants électronique. En lui même, le projet est assez simple en raison de sa structure modulaire. Ce n'est pas l'électronique qui en fait sa puissance mais son firmware, un miniOS dans une mémoire flash qui peut d'adapter en fonction des supports choisis. Par exemple, le même lecteur pourra lire, écrire et graver des MP3 si on lui installe le firmware orienté MP3 ou lire, écrire et graver de l'Ogg Vorbis, si on lui implante le firmware orienté Ogg Vorbis. Bien évidemment, il existera un multi-firmware intégrant à la fois la gestion du MP3 et de l'Ogg Vorbis, ces deux formats n'étant qu'un exemple vu la richesse des formats supportés actuellement par le lecteur. (VideoCD, DivX, etc)
Je retourne à ma programmation, merci quand même à ceux qui m'ont répondus.

Cordialement,

Salut !

Le genre de programme que vous recherchez n'existe a priori pas... En effet, si certaines personnes ont créé des programmes de conversion BP vers Delphi, il n'y en a pas dans le sens inverse. Il faudra faire sans...

J'ai regardé une des unités présentes sur le site que vous avez donné. J'ai vu qu'elle utilisait notamment les unité Classes et SysUtils.

En elles-même, ces unités n'apportent pas grand chose au code que j'ai entr'aperçu. On pourra donc facilement s'en passer.

Le gros, très gros problème que vous allez rencontrer ne se situera pas à ce niveau, je le crains. En effet, l'unité utilise les nouvelles fonctionnalités relatives aux classes offertent par Delphi.

En ce qui concerne le mot réservé class, on peut sans trop de risque le remplacer par object, en utilisant l'unité Objects.

Par contre, il est fait usage des propriétés (mot réservé property), qui ne trouveront malheureusement pas leur équivalent dans le langage Pascal Objet d'il y a plus de 10 ans.

Il va donc falloir malencontreusement trouver une manière de passer outre ce problème, en se servant de fonctions, etc...

N'hésitez pas à poser vos questions quant à la conversion Delphi => Pascal, qui risque d'être assez chaotique.

A+

L'électronique me passionne mais je n'y comprends rien malheureusement...
Pour revenir à la programmation, et comme l'a dit HDD34, Delphi utilise les classes, et à l'intérieur des classes des properties. Les properties n'ont pas d'équivalent direct en BP ou Pascal, mais il me semble qu'elles agissent comme n'importe quel champs d'un objet ( en se plaçant du point de vue de la POO ). Ce sont en général des variables de types simples ( integer, boolean ) et je pense qu'elles sont facilement remplaçables dans un code BP... Cela dit, l'utilisation de la POO, et avec tout ce que ça engendre ( mémoire ), ne convient peut-être pas au projet, qui est construit en grande partie en assembleur si j'ai bien compris... Ou alors je me goure !!
Il faudrait connaître l'avis de l'intéressé !
a+

Bonsoir à tous,

J'ai l'impression que pour beaucoup cette conversion de Delphi en BP7 releve du parcours du combattant. Hors, j'ai découvert que ces fameuses unités avait déjà été porté du Delphi en PHP. (et avec succès... je les ai testé... en plus, je programme moi-même en PHP) A mon avis, c'est le Delphi qui complique cette tâche qui me semblait pourtant être assez simple au départ. C'est pourquoi j'ai pris une décision (à vrai dire, la même que pour les ID3 du MP3... et ça marche, bien que mon unité ne soit pas complète) : je vais entierement reprogrammer l'extraction des tags à partir des documents qui détaillent l'implantation de ces informations dans les fichiers audio/vidéo. (MPC, Ogg, etcà) Je crois que ça sera beaucoup plus simple, pour vous, comme pour moi.
Pour finir, il n'est nullement question d'électronique ici. Disons que pour simplifier je travaille sur un lecteur de média comme il en existe tant mais sous DOS.

Cordialement,

Je ne vois pas vraiment l'utilité de revenir à BP 7 alors que tu travaille déjà avec Delphi.
Delphi est belle est bien le successeur de BP.

Oui mais Delphi n'impléménte pas directement l'utilisation de codes en assembleur ( et c'est très dur d'inclure du code assembleur dans Delphi ). De plus, Delphi travaille pour Windows alors que Mr Fantoni veut travailler sous DOS... Delphi ne convient pas ici.
a+

Bonjour,

Comme je l'ai expliqué précédemment, les périphériques de mon lecteur de salon sont "attaqués" directement en assembleur. Le code qui en résulte est au final très léger : seulement quelques octets. Le Pascal n'est là que pour l'habillage du programme/firmware, c'est à dire pour afficher des informations sur l'écran TV ou sur le LCD. Il suffit amplement.

Si je parlais de Delphi (dont je ne maitrise nullement les arcanes), c'est parce que j'ai trouvé des bouts de code dans ce langage qui pourraient m'aider dans mon projet. Je souhaitais avant tout gagner du temps en les utilisant car j'aurais pu développer moi-même les différentes fonctionnalités présentes dans ces unités (affichages des Tags/ID3 présents dans la plupart des formats audio compressés). Je cherchais juste un petit programme pour convertir ces bouts de code de Delphi en BP7 puisque le Delphi utilise le Pascal. Ca s'arrete là.
Je ne cherche abasolument pas à passer à Delphi puisque je travaille exclusivement en DOS 32 bits dans les applications embarquées que je développe.
La bonne nouvelle, c'est qu'en étudiant le code Delphi de ces bouts de code hier soir, je ne suis apperçu que seulement une partie de leur code source m'interessait réellement et que visiblement ces parties semblaient être 100% compatible avec le BP7. Il y a bien certaine fonction qui n'existe pas en BP7 mais je ne devrais avoir pas trop de mal à les reprogrammer, voire à les remplacer.

Merci quand même tout à ceux qui ont essayer de m'aider...

En effet, je doûte que vous ayez à reprendre exactement le code Delphi, qui offre une interface RAD, ce dont vous n'avez manifestement pas besoin.

Delphi, ce n'est que du Pascal Objet. Donc, le code source en lui-même doit être facilement portable, sans avoir à s'arracher les cheveux.

Il est par contre possible que la personne qui a créé ces unités se soit servi de fonctions internes à Delphi, auquel cas il faudra les réécrire.

Le cas échéant, n'hésitez pas à poser des questions si la transcription s'avère ardue.

A+

Bon courage pour votreprojet !
Et comme l'a dit HDD34, n'hésitez pas à poser des questions !
a+

Bonjour,

Actuellement, le portage des unités Delphi en Borland Pascal 7 s'effectue plutôt bien. Par unité, quelques heures me suffisent pour convertir le gros du Pascal Object en Pascal utilisable directement sous BP7. Cependant, comme je ne maitrise pas (ou mal) Delphi, je ne me heurte à certaine fonction/procedure "spécifique Delphi" dont je ne connais pas vraiment le fonctionnement. En voici la liste (pas exhaustive) :

- Cardinal : Pour l'instant, je remplace le Cardinal pour du Longtint. Les fonctions qui l'utilise fonctionne bien que certaine d'entre elles me donnent de drôle de résultat. Des idées ?

- Int64 : Visiblement des "integers" sur 64 bits. Je change le Int64 directement en Interger. Pas de problème en particulier à signaler.

- TFileStream, TStringStream, etc : spécifique à Delphi. Pour l'instant, j'ai remplacé certaine de ces fonctions par Assign, ... Close, etc. Les nouvelles procédures fonctionnent (compilation correcte) mais le résultat ne s'affiche pas. C'est là ou je rencontre le plus de mal car visiblement la gestion des fichiers dans certaines des unités exploitent le potentiel de Delphi... Ca risque d'être "coton" à porter en BP7...

Pour les reste, les unités qui permettent d'avoir les infos des ID3v1, ou sur la compression MP3, voire sur les TwinVQ fonctionne plutôt bien. Ca fait même tout "drole" de voir certaine de ces unités fonctionner parfaitement sous DOS... (comme détecter l'encodeur MP3 utilisé pour la compression d'un morceau de musique)

Pour le reste, si vous avez quelques pistes à suivre, je suis preneur...

Cordialement,

Bonjour !

Le type Cardinal doit exister sous BP7... Seulement, pas comme on pourrait l'espérer ! En effet, Integer et Cardinal sont des types spécifiques au compilateur, c'est à dire qu'ils sont codés sur un nombre de bits correspondant à la version du compilateur utilisé. Pour Delphi 2 et supérieur, il s'agit d'un compilateur 32 bits. Donc le type Integer est sur 32 bits, ainsi que le Cardinal, qui est donc un type entier sur 32 bits, non signé.
Mais sous BP7, nous sommes en 16 bits ! Donc le Cardinal est ici équivalent à un Word. Il est normal que vous trouviez des résultats étranges avec un Longint, car celui-ci est signé, et non le Cardinal. Il faut voir s'il n'est pas possible de réduire la résolution du nombre à sortir, ou alors le couper en deux Word(s).

L'Int64 n'a évidemment pas d'équivalent. On pourrait éventuellement le coder avec 4 Word(s).

En ce qui concerne TFileStream, détrompez-vous ! Il existe aussi sous BP7 des flux pour gérer les fichiers, en-dehors de Assign, etc... Ils s'appellent TDosStream et TBufStream, présents dans l'unité Objects. Je vous conseille personnellement le dernier, qui utilise un tampon pour accélérer les accès.

Pour TStringStream, on peut au besoin ce reporter sur TStringCollection. Mais la gestion risque d'être plus légère.

Si vous avez d'autres problèmes, n'hésitez pas à deemander !

A+

Bonjour

Tout d'abord une réponse à Axiome : la réponse à ton message se trouve quelques messages plus haut. Il te suffit de les lire...

Quant à la question qui intéresse Christophe, j'ai une suggestion (que je n'ai pas testée) :
Pourquoi ne pas compiler ces unités avec Delphi lui-même en lui précisant dans les options de compilation le mode 16 bits, application console seule &c ?

Bon courage

Bonjour,

Compilez avec Delphi en 16 bits aurait ou être une solution s'il n'y avait pas d'assembleur inline dans mon code. (très difficile à porter en Delphi)Hors, la plupart des fonctions que j'ai programmé sont en assembleur, pour accès "direct" aux périphériques. La solution fut donc le portage de certaines unités Delphi en BP7, avec une éventuelle reprogrammation des fonctions spécifiques à Delphi. Hors, la plupart de ces fonctions me sont totalement inconnus et même si certaine me disent quelque chose, cela s'arrete là puisque je ne programme pas en Delphi.

Pour l'instant, le portage s'effectue sans trop de difficulté... fort heureusement...

Re-Bonjour,

Après les Cardinal et les Int64, je tombe sur les WideChar et autre WideString. Pour l'instant, je les remplace respectivemet par Char et String (ça marche), sans trop savoir ce qu'aporte WideChar et WideString au programme. A vous de me le dire...

Re bonjour

Les WideChar sont des caractères étendus, je crois qu'ils sont codés sur 16 bits au lieu de 8. Ça permet entre autres de permettre la représentation des idéogrammes & autres jeux de caractères très grands.
Les WideStrings sont naturellement des chaînes composées de ces caractères étendus.

Citation:

---

Compilez avec Delphi en 16 bits aurait ou être une solution s'il n'y avait pas d'assembleur inline dans mon code. (très difficile à porter en Delphi)Hors, la plupart des fonctions que j'ai programmé sont en assembleur, pour accès "direct" aux périphériques.

---

Là, j'ai pas compris le sens de la phrase.

En ce qui me concerne, je pensais bien compiler les unités Delphi grâce au compilateur Delphi & non les unités BP 7. Car, une fois compilées, les unités - aux nuances de format de données près - devraient être immédiatement utilisables dans BP 7.

Cordialement

---
hdd34: C'est ce que je regrête dans TP7, il n'existe pas de nombre entier 32 bits NON SIGNE :evil:
---
Ton portage me semble bien complexe! C'est quoi ton programme ? Si c'est juste pour lire des tags MP3, pas besoin de porter un programme! Ca s'écrit en 4h un programme comme ça! (dont 1h pour trouver le bon site : http://www.wotsit.org, bonne doc sur tous les formats de fichiers -> .MP3) Mais à mon avis il fait un peu mieux que ça ce programme!

Bonne chance en tout cas. Moi je suis en train de porter un logiciel de Windows vers Linux ... galère galère. Y'a des fonctions à 29 paramètres (!!!) ... récursives :pleure: :pleure: . Et j'ai trouvé des trucs sympas comme "delete this;" (c'est du C, en décodé "autodestruction d'un object" :-p).

@+ Haypo

Bonjour,

Mon programme est un petit peu plus compliqué qu'un simple portage Delphi en BP de certaine fonction "cosmétique". Comme je le disais précédemment, le Pascal est juste là pour "l'enrobage" graphique de mon firmware. (l'interface de navigation et la gestion du LCD)
La majorité de mon programme est écris en ASM, soit en ASM Inline (via le BASM du BP) soit grace à MASM. (et les fichiers OBJ) Une programmation qui reste d'actualité lorsqu'il s'agit de développer des applications embarquées. (je travaille sur un lecteur-enregistreur de fichiers multimédias, DivX compris) On est loin des ressources nécessaire pour une application développé via un RAD. (pour info, le programme permettant la lecture des fichiers audio/video fait à peine 100 Kb...
Le Pascal me permet d'écrire quelque chose de simple. De plus, il n'était donc pas possible d'écrire mon firmware en autre chose qu'en C, ASM ou Pascal puisque mon firmware tourne essentiellement en DOS 16 bits.
En soi, le portage des unités Delphi qui m'interessaient est actuellement presque terminée. Pour l'instant, j'ai porté en BP les unités les plus importantes. Je ne désespere pas de porter celle qui me manque... Me manque plus que le temps...

Cordialement,

La réponse de Alt au sujet des WideChar et WideString est correcte. Il s'agit de caractères codés sur 16 bits de façon à permettre à Windows et consors d'accepter notamment les caractères asiatiques. Alors àmoins que les MP3 soit en mesure daccepter ce genre de caractères, on peut les remplacer par Char. Sinon, il faut se servir de Word.

Et pour Haypo, sache que le Pascal connaît aussi l'équivalent à delete this;. Il s'agit tout simplement de Free, qui peut se figuer par Dispose(@Self, Done);

A+

Bonjour à tous,

Je cherche un bout de code en Delphi (que je vais porter en BP7) capable de lire les entêtes des fichiers MPEG-1. Je galère pas mal pour trouver des indications précises sur le format (même le site mpeg.org ne donne que peu d'information utile) et seul l'étude d'un fichier source clairement documenté, en Delphi si possible, me permettra de porter ça en BP7. L'idée c'est au moins de pouvoir extraire la résolution et le taux de transfert de la vidéo, ainsi que toutes les informations concernant la piste audio. C'est un minimum...

Par avance, merci à tous ceux qui me répondront...

Cordialement,