Au sujet des DLL et Panoramic

J'ouvre ce post pour continuer la discussion au sujet des DLLs et pour ne pas pourrir le post de Etamioreb


Franchement à choisir:

Je préfère avoir la possibilité d'avoir des appels de fonctions avec passage de paramètres en Panoramic natif plutot que de pouvoir faire des Dlls. En fait, une dll est une bibliothèque de fonctions figées, pré-compilée.

Donc si Panoramic permet de créer des fct, il n'est pas absolument nécessaire de créer des Dlls (sauf si on veut protéger et ne pas diffuser son source).
un simple include d'un fichier .bas regroupant des fonctions et vous avez l'équivalent d'une dll.

Par contre, dans mon exemple (cf post de Etamioreb), les fonctions que j'utilise ne sont pas dispo en Panoramic, donc dans ce cas, j'utilise user32.dll dans la mesure où c'est possible.

Si demain j'ai besoin de faire un calcul de checksum (style MD5) et que je trouve une dll me permettant de le faire, c'est clair que je ne vais pas m'amuser non plus à réinventer la roue.


Histoire de casser les espérances de certains :

L'utilisation de Dll en panoramic n'est pas non plus facile. Les différentes fonctions que l'on trouve dans les DLLs ne sont pas forcément compatible avec Panoramic.

Ce qui se passe actuellement, je parle pour moi mais je pense que Klaus ne me contredira pas :

Quand je fait une Dll en delphi c'est surtout pour faire une passerelle entre des fct de Windows qui utilise des objets complexes et Panoramic.

Un exemple (je simplifie à l'extreme pour que tous le monde comprennent):

Imaginons que les coordonnées de la souris sont stockées dans un emplacement mémoire composé de 2 variables (X et Y).
pour connaitre ces coordonnées, il faut appeler une fonction système en lui passant comme paramètre l'adresse d'un emplacement équivalent où la fonction doit écrire les valeurs.

Cela donnerai en Panoramic :

Code:

dim retour, tableau(2)
retour =  dll_call1("FonctionSysteme",adr(tableau))

Malheureusement on ne peut pas connaitre l'adresse d'un tableau en panoramic.
Donc pour contourner ce problème je vais écrire une Dll en delphi qui va faire cet appel et "formater" le résultat pour pouvoir l'utiliser sous Panoramic.

Cela donne :

Pseudo-source de Dll_delphi :

Code:

 Ma_fonction_delphi(x,y)
    dim retour, tableau(2)
    retour =  dll_call("FonctionSysteme",adr(tableau))
    x=tableau(0)
    y=tableau(1)
return

Pour l'appel dans Panoramic :

Code:

dll_on "Dll_Delphi.dll"
dim x,y,retour
retour = dll_call("Ma_fonction_delphi",adr(x),adr(y))

--> Création d'une DLL en delphi qui ne contient pratiquement rien...

Encore c'est un exemple simple mais imaginez une fonction qui a besoin de connaitre un emplacement qui contiendrai des variables de différents type.

Un exemple :

[emplacement]
entier Param1
entier Param2
reel Params3[3]
string A$
[/emplacement]

Aie! galère....
L'astuce serait que Panoramic passe à la dll delphi l'adresse d'une chaine de caractère suffisamment grande pour contenir tout le resultat qui sera formaté en ascii. puis s'amuser sous Panoramic après l'appel à la fonction à décomposer la dite chaine pour dispatcher les différents élements de l'emplacement dans les variables appropriées... Bonjour le boulot !


Donc : Dll, Dll, Dll,.... oui mais... pas si évident que ça...

Bonjour,
Si tu penses à moi pour les dll, tu fais erreur.

Pour ce qui est de Jack et la possibilité de faire des dll, je n'en suis pas sur, et très certainement je me trompe, mais il me semble avoir lu un jour que c'était dans les possibilités (mais je n'ai cité que de mémoire qui est faillible. Je ne vais pas aller relire le forum depuis le début pour ça).

Ensuite j'ai demandé si quelqu'un savais s il existait une dll pour connecter ou déconnecté au réseau local. Je n'ai rien demandé de plus. Si quelqu'un le sait et qu'il veut le dire, cela me ferait plaisir, comme je répond parfois à une question à l'un d'entre nous.

Cela ne va pas plus loin. En plus lorsqu'une dll est publiée (pas par moi évidemment), et que je peux la remplacer par des lignes de basic, je choisi la 2ème solution (et je pourrais citer des exemples. En plus lorsqu'il faut intégrer une dll dans un programme, il faut en plus la joindre.

Etamioreb et toi, avaient montré comment se servir d'une dll qui existe déjà, alors que je ne savais comment on pouvait faire.

J’arrête là pour ma défense. A vrai dire je n'aime pas m'en servir, mais c'est parfois bien utile. Pour ce qui est de la question que j'ai posé, ne continu pas à chercher. C'était juste une question. D'ailleur je la remet pour bien montré que je n'ai rien dit d'autre.

Citation :

Est-ce que quelqu'un connait une dll ou le moyen d'activer ou désactivé par programme la connexion au réseau local. Ça ça m’intéresse.

Salutation.

Non cosmos,

Pas à toi en particulier mais cela fait plusieurs fois que je lis cette demande de pouvoir faire des dll en Panoramic.
Ce que je veux dire c'est que Panoramic n'est pas vraiment adapté pour...
ni plus, ni moins...

Quand a faire des dll dans un autre langage pour combler des lacunes de Panoramic, je suis loin d'être hostile si il n'y a pas d'autre moyen de le faire. Et je serai heureux d'aider avec mes modestes connaissances en Delphi.
Et je pense que Klaus pense la même chose que ce je pense qu'il pense ce que je pense ... ou l'inverse...

bonjour, Nardo26 a raison, les fonctions sont plus intéressantes

@Nardo26:
Panoramic n'est pas vraiment fait pour faire des DLL ? Voir... Depuis longtemps, on suggère à Jack de pouvoir faire de vrais sous-programmes et fonctions en Panoramic, avec leurs paramètres formels et leurs variables locales. J'avais fait un post très détaillé proposant une méthode d'implémentation. ET je pense que Jack n'a pas exclu cela; ce n'est simplement pas la priorité du moment.

Mais si un jour Jack réalise ces sous-programmes et fonctions indépendantes, il serait certainement facile d'avoir une ligne de menu, à l'image de la ligne "Executable (.exe)", de type "DLL (.dll)" qui produirait une dll à partir de la ou des fonctions présentes dans le source du moment. Et l'avantage, c'est qu'on aurait automatiquement le passage de paramètres plus complexes, tels que les tableaux, puisqu'on passerait de Panoramic à Panoramic...

D'accord, c'est sûrement lointain, mùais je pense que la possibilité technique existe.

En complément avec ce que j'ai dis plus haut:

Si cette histoire de DLL est surtout pour un besoin de protéger ses sources, sans pour autant créer un executable, il y a peut être une solution.
Perso je n'en ressent pas le besoin, je n'ai rien à cacher, mais bon tout le monde n'est pas censé penser comme moi...

Imaginons que j'ai fais une librairie de procédure que j'autorise à inclure dans des programmes mais je ne souhaite pas que les personnes puissent lire son contenu... on pourrait imaginer un autre format de sauvegarde.

Prenons par exemple le langage Python, les sources possèdent l'extension .py mais on a aussi un format en byte-code (extension *.pyc) qui lui n'est pas éditable car c'est du source pre-digéré (encapsulé).

Nous avons déjà ce format dans Panoramic quand on génère un exécutable :
En fait dans le .exe on a une concaténation de l'interpréteur Panoramic qui va exécuter les commandes et le code source en format compressé (byte-code).
Jack dis-le moi si je me trompe, c'est bien ça ?

Il suffirait que le grand maître, s'il le souhaite et s'il en a le temps, donne accès à cette possibilité via un menu dans l'éditeur par exemple...
(Je suis conscient que cela fait pas mal de boulot car dans ce cas il faut revoir les directives include et chain et certainement d'autres choses)


Ooops on s'est croisé Klaus !

@Klaus : on s'est croisé

Pour générer une DLL il faut compiler le source. Cela oblige Jack de créer un compilo ou alors de faire une moulinette qui converti le langage Panoramic dans un autre langage avant de le passer dans un compilo libre de droit... (ce qui n'est pas le cas de Delphi)

J'ose même pas imaginer le boulot que cela represente...

Je ne pense pas que cela change quoi que ce soit par rapport à ce qu'il existe. Dans l'actuelle création d'un exe ou d'une application en format exe, il y a bien une forme de compilation, avec inclusion de l'interpréteur Panoramic dans l'exe (ce qui explique sa taille finale). Il suffirait de ne pas inclure l'interpréteur dans la dll, et de faire un dispatching conforme à la convention des DLL pour accéder aux fonctions et sous-programmes contenus dans la DLL. Bien sûr, cela n'est pas possuble pour un module qu'on appellerait par un GOSUB actuel: il faudrait des commandes
FUNCTION ma_fonction(par_1,...,par_n)
...
ma_fonction = resultat
return

SUBROUTINE mon_sousprogramme(par_1,...,par_n)
...
return

et dans le programme principal, on aurait quelque chose comme ceci:
EXTERNAL FUNCTION ma_fonction(par1,...,par_n) IN ma_dll.dll
EXTERNAL_SUBROUTINE mon_sous_programme(par_1,...,par_n) in ma_dll.dll
...
mon_resultat = EXTERNAL_FUNCTION(ma_fonction(1,2,"abcde",...))
CALL mon_sous_programme(...)

Et l'interpréteur lié au programme principal saurait alors quelle fonction ou quel sous-programme chercher dans quelle DLL, et saurait l'appeler puisque le passage de paramètres serait certainement fait par la convention STDCALL, ou alors par une convention propriétaire à définir.

Bonjour Klaus,

Ce que je veux dire c'est qu'une DLL standard (comme user32.dll par ex.) contient du code executable, compréhensible pour le micro. La difference, pour simplifier, c'est qu'une DLL contrairement à un executable classique ne possède pas de procédure main(), mais un tableau (descripteur) qui contient des pointeurs sur les fonctions de la DLL.

Dans le cas d'une applic exe faite par Panoramic, le seul code véritablement executable c'est le noyau(l'interpréteur). Le source reste du source (optimisé en byte-code certes mais tel quel, il n'est pas compréhensible pour le micro). C'est pour cette raison qu'un simple 'print coucou' fait 1.5Mo. Tu as 1560 Ko de code executable (noyau) + 3 Ko de code source (compressé). Si tu vires les 1560Ko, tu te retrouve avec un packet d'octet que le micro ne saura que faire...

Ce que je veux dire c'est qu'il faudrait un véritable compilo, qui traduirait le source Panoramic en langage-machine (instructions micro) pour pouvoir générer des DLLs.

Ou alors on ne parle pas de DLL au sens strict du terme mais à ce que je disais tout à l'heure une génération de fichier en format byte-code, dans un format spécifique à Panoramic (un équivalent du .pyc de python).

Une chose que je n'ai pas précisé tout à l'heure car cela me parait évident : la notion de fonctions avec passage de paramètres et de variables locales sont indispensables pour ce genre de fichier.


[Edit]
En fait dans un executable Panoramic, il y a concaténation du noyau exécutable et du source (format ASCII) crypté, nous n'avons pas de byte-code...
cf. https://panoramic.1fr1.net/t1120-exe-2-bas#9242
[/Edit]

effectivement, cela ne pourrait pas être une traduction en code binaire exécutable, mais uniquement en pseudo-code identique à celui généré par le compilateur pour un programme en *.exe. Le seul point qui rappelerait une DLL, ce serait la vectorisation de l'accès aux sous-programmes et fonctions. Mais je préfère duand-même la notion de DLL pour bien marquer qu'il s'agit d'un fichier physiquement distinct, remplaçable sans remplacer tout l'exécutable, par opposition à une bibliothèque qui est liée physiquement dans le fichier *.EXE pendant la phase de link, et donc présente en copie pour chaque exécutable produit, un peu comme c'est le cas pour l'interpréteur de Panoramic lui-même. Je pense qu'il est envisageable de faire un fichier indépendant, par exemple *.PLL" (Panoramic Link Library) selon cette philosophie.

Tout à fait d'accord avec toi Klaus !!

Mais là on parle d'un futur plus ou moins lointain...
Avant l'extension PLL, il faudrait avoir les fonctions avec passage de paramètres....

Perso, je vois ne l'intérêt d'une extension PLL que dans le cadre de la confidentialité.

Le jour ou les fonctions/passage de paramètre existent, un simple fichier bas que l'on inclus dans un programme principal me conviendrai amplement...

La confidentialité ne serait que pour une application pro et lorsqu'on ne souhaite pas communiquer ces connaissances/travail :
Ce qui est le contraire de ce que Jack a mis en place... la gratuité, le partage.

Dans ce cas, je pense qu'il serait normal que Jack perçoive des royalties... (peut-être sous la forme d'un module complémentaire payant?)

Je pense que ça va bien plus loin que la confidentialité des sources. Cela permettrait, même pour soi-même, de se constituer une bibliothèque de sous-programmes utilisables dans plein d'autres programmes, sans avoir à faire des #INCLUDE, à gérer le problème des noms de variables et labels, etc.

Pour ma part, dans ma vie d'informaticien antérieure, j'ai toujours constitué des bibliothèques de modules généraux, par exemple pour la gestion d'écran à une époque où on n'avait pas encore Windows, pour la gestion d'un système de fichiers particuliers, pour un log des actions d'une application, la gestion des transactions et beaucoup d'autres. L'idée, c'est de réaliser une fois pour toutes, des modules généraux qui serviront ensuite de "briques" pour la constitution des applications. Accessoirement, cela permet également de les mette facilement à la disposition d'autres utilisateurs, avec ou sans sources en accompagnement. Mais pour moi, c'est presque secondaire.

La commande include te permet déjà l'utilisation de bibliothèque....

Tout à fait d'accord avec toi sur le principe :

Perso pour mon travail, je réalise les softs de manière modulaire. Cela m'évite de réinventer la roue.

Même lorsque la carte sur laquelle tourne mes prog change (fin de fab du micro par ex.) je m'arrange pour ne changer que les drivers specifique à la carte et eventuellement le compilateur...
Actuellement j'ai fait un portage d'une applic qui tournait à l'époque sur micro-controlleur 68HC11 vers des nouvelles cartes basées sur du 9S12DG128A ou du 9S12DT256. il a fallu re-écrire le scheduler (noyau multi-tache) et quelques librairies (modbus,CAN,etc...) car le mécanisme des ITs et le mapping memoire n'est pas identique mais en dehors de cela je n'ai pratiquement pas touché une ligne de code pour la partie applicative.

Maintenant que les drivers, les makefiles et les fichiers de link sont réécrits, je peux recompiler sur ces nouvelles cartes des applics que j'ai écrits il y a presque 20 ans. (17 ans pour être exact)

Les librairies ne sont pas des DLLs... ce sont des fichiers objets que je link au final dans mon applic. La seule chose que je rajoute dans les fichiers de l'application principale, c'est des includes sur les déclarations externes des fonctions des différentes librairies que j'utilise.
Maintenant en un clic de souris je recompile la même application, avec les mêmes fichiers source pour 2 types de cartes différente, avec des micro différents et pas tout à fait la même chaine de compilation (compilo et linker de version différente)

Dans le cas de Panoramic, cette notion de librairie, tu l'a déjà fait lorsque tu as crée par exemple les GLIST, et tu n'as pas eu besoin de DLL pour le faire... lorsque j'ai fait le petit utilitaire de couleur RGB<->TSV j'ai appliqué le même principe (j'avais juste changé à un moment l'extension .bas en .lib pour pouvoir différentié le fait que ce soit une librairie)