 |
| DLL gestion des pointeurs | |
| darkblue | 4-Sep-2018/13:46:48 |
| Bonjour, je teste pour voir comment fonctionne l'utilisation des DLL avec Rebol pour les api simples comme _getpid, _putenv-s, getenv de msvcrt.dll cela fonctionne bien mais des que les parametres des api sont un peu plus complexe comme des pointeurs de long ou int je n'arrive pas à recuperer les valurs exemple avec GetDiskFreeSpaceExA de kernel32.dll qui prend 4 parametres, une chaine de caracteres et 3 pointeurs : BOOL GetDiskFreeSpaceExA( LPCSTR lpDirectoryName, PULARGE_INTEGER lpFreeBytesAvailableToCaller, PULARGE_INTEGER lpTotalNumberOfBytes, PULARGE_INTEGER lpTotalNumberOfFreeBytes ); j'ai essayé différentes méthodes pour essayer de recuperer la taille dispo sur mon disque <code> lib: load/libray %kernel32.dll GetDiskFreeSpaceEx1: make routine! ["GetDiskFreeSpaceExA" path [string!] FreeBytesAvailableToCaller [integer!] TotalNumberOfBytes [integer!] TotalNumberOfFreeBytes [integer!] return: [integer!]] lib "GetDiskFreeSpaceExA"] GetDiskFreeSpaceEx2: make routine! ["GetDiskFreeSpaceExA" path [string!] FreeBytesAvailableToCaller [long] TotalNumberOfBytes [long] TotalNumberOfFreeBytes [long] return: [integer!]] lib "GetDiskFreeSpaceExA"] GetDiskFreeSpaceEx3: make routine! ["GetDiskFreeSpaceExA" path [string!] FreeBytesAvailableToCaller [struct! [a [integer!]]] TotalNumberOfBytes [struct! [a [integer!]]] TotalNumberOfFreeBytes [struct! [a [integer!]]] return: [integer!]] lib "GetDiskFreeSpaceExA"] GetDiskFreeSpaceEx4: make routine! ["GetDiskFreeSpaceExA" path [string!] FreeBytesAvailableToCaller [char*] TotalNumberOfBytes [char*] TotalNumberOfFreeBytes [char*] return: [integer!]] lib "GetDiskFreeSpaceExA" ; prise dans opencv *int: make struct! [[save] ptr [struct! [value [integer!]]]] none addr: func [ptr [binary! string!]] [third make struct! [s [string!]] reduce [ptr]] get&: func [ptr] [change third *int addr ptr *int/ptr/value] GetDiskFreeSpaceEx: make routine! ["GetDiskFreeSpaceExA" path [string!] FreeBytesAvailableToCaller [struct! (first *int)] TotalNumberOfBytes [struct! (first *int)] TotalNumberOfFreeBytes [struct! (first *int)] return: [integer!]] lib "GetDiskFreeSpaceExA" </code> Je n'ai jamais réussi à retrouver mes petits | |
| DideC | 14-Sep-2018/10:39:06 |
| Jn ne peux pas t'aider, si ce n'est que je sais qu'il faut biaiser avec des struct! ou quelque chose comme ça. LDCI pourrait surement te répondre, s'il passe par là. | |
| ldci | 15-Sep-2018/20:44:18 |
| Bon Il faut que je regarde les notes, mais effectivement le gros problème est de simuler les structures C avec Rebol . Je regarde des que possible  | |
| darkblue | 26-Sep-2018/7:53:41 |
| Merci de votre aide :D | |
| shadwolf | 26-Sep-2018/13:40:55 |
| darkblue ne soit pas dur avec ldci et dideC... ce n est pas de leur faute. On a essayer y a plus de 15 ans de faire de choses bien avec rebol2 load/library ( a lepoque on s etait meme acheter une version rebol/command pour y avoir acces car ca ne faisait pas parti de rebol/view normal). On assez rapidement conclut que c etait tres mais alors tres limité on en a parler avec Carl Sassenrath qui nous a dit: "MAis non c est vous qui etes trop bete je vais vous expliquer comment ca marche" ce qui a permis a certain de commencer des ebaucche de pont rebol vers openGL par example qui etant comme tout dans la commauté rebol le fruit de l effort d un individu sont tombés dans l'oubli quand leur auteur est passé a autre chose. Enfin on a dit a Carl (enfin surtout moi hein a l epoque le reste de la commauté se tournait deja vers red) que le support des DLL c etait de la crotte. Je me suis fait bashé mais quand meme mine de rien Carl est venu avec r3 dont le point essentiel rappellons le etait d introduire une nouvelle facon de s interfacer avec les DLL C mais aussi s integrer directement dans un programme en C... Au final r3 a pas plus avancé que ca le nouveau systeme n ameliorait pas vraiment les choses. et r3 osef. Apres vu que r3 est sensé etre mieux on a perdu la majorité des documentationz sur comment se faisait les interfaces avec DLL en r2. Encore une fois de l avis general de la planete y compris de l avis meme de l auteur de Rebol "IL Y A MIEUX A FAIRE DANS LA VIE QUE DE PERDRE SON TEMPS AVEC REBOL"... Ah ouai quand meme ... | |
| none | 26-Sep-2018/13:54:53 |
| le probleme principal de l import de librairy dans rebol c est que tu perds la notion de portabilité. En plus de faire un pont chiant a ecrire que tu devras maintennir constemement a mesure qu evolue la librairie (bon ok, kernel32.dll on est tranquil ca n evolue plus depuis 1995 ... ahahahaha). Enfin il y a des concepts C qui passent tellement mal en "pont C vers rebol" un example ? Okay les listes chainées ... Pour obtenir l espace libre de ton disque dur n est ce pas plus simple de faire un petit programme C qui va le faire super bien puis de parser le resultat depuis ton script rebol ? 1) ecrire petit programme natif C qui fait bien le boulot 2) ecrire le script qui va execute et interprete le resultat de petit programe en C... Enfin je me souviens plus si la fonction rebol pour executer une commande externe permet de recupere un resultat d execution. Ca me suprendrait meme pas que ca le face pas... On alors petit programme en C devient petit programme en C qui s execute et laisse un port ouvert pour envoyer le resultat a rebol quand rebol se connecte sur son port puis s eteind... Ouai ...Mais ca reste toujours moins chiant que load/library. | |
| darkblue | 27-Sep-2018/8:18:56 |
| Shadwolf, mon propos n'était pas ironique, s'ils retrouvent les infos sur le sujets quannd ils ont un peu de temps cela me va! Je remerciais la démarche | |
| shadwolf | 1-Oct-2018/19:57:29 |
| ok autant pour moi ceci dit load/library c est pas evident et c est la raison essentiel de l existance de r3. | |
|
Login required to Post. | |