Discussion :

[Eric Sigoillot]

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+

[ALT]

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

[Christophe Fantoni]

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...

[Christophe Fantoni]

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...

[ALT]

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.

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

[haypo]

---
hdd34: C'est ce que je regrête dans TP7, il n'existe pas de nombre entier 32 bits NON SIGNE
---
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 . Et j'ai trouvé des trucs sympas comme "delete this;" (c'est du C, en décodé "autodestruction d'un object" :-p).

@+ Haypo

[Christophe Fantoni]

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,

[Eric Sigoillot]

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+

[Christophe Fantoni]

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,