Link Le 16/07/2003 à 18:18 tu peux tout à fait ne pas n'utiliser que les symfind/symadd en lisant tout simplement dans la mémoire du Handle de la variable:
La SYM_ENTRY contient un champ handle, puis du fais (en lecture)
char *ptr;
HANDLE h;
h=DerefSym(hSym/*la valeur retournée par symfind*/)->handle
HeapLock(h);
ptr=HeapDeref(h);
//tes fonctions de lecture ici
HeapUnlock(h);
en écriture, c'est plus compliqué, regarde à la fonction SymAdd de TIGCC

Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
Dans tigcc, tu as simplement du code qui te montre comment faire, mais ce n'est pas optimal ce qui a été écrit par zejlko
Pour info, Link:
"
HeapLock(h);
ptr=HeapDeref(h);
"
peut être remplacé par "ptr=HLock(h);". HLock est un ROM_CALL (ROM_CALL_99).
jibax Le 17/07/2003 à 19:15 sinon, existe t'il un moyen d'écrire direct dans la mem flash (pour modifier des fichier archivés sans modifier leur taille????? ) parce que,si ca existe ca me rendrait grandement service ;..
Link Le 17/07/2003 à 20:25 jibax-> je ne crois pas, il me semble qu'il faut toujours les passer en RAM pour les modifier.
XDanger-> Merci, je ne retrouvais plus le bon ROM_CALL...

Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
Attend ... pas de méprise, écrire en FLASH, c'est pas écrire en mémoire archive, t oki ?
Merci KK, j'allais le poster en fait, j'ai vu ce topic sur votre board ...
jibax: archive/desarchive si c pour un fichier ...
une question : c'est normal que fgetc() ne lise pas la premiere ligne dun fichier ?
fgetc() lit caractère par caractère. Mais il devrait lire le fichier en entier, y compris la première ligne. Donc non, ce n'est pas normal.
Un fseek est-il nécessaire avant de commencer à lire ? Si ça ne l'est pas, ça pourrait expliquer le problème (je n'y crois pas du tout, mais bon...).
avec ou sans fseek jai le meme probleme
jhesite entre les fonctions fopen() et consorts et les fonction sym_machins
Fonctions de stdio.h: avantage principal: facilité d'utilisation, inconvénients principaux: plus gros et plus lent. Ca permet de porter les programmes plus facilement depuis le PC.
Fonctions de vat.h: le contraire. Tu contrôles pleinement tout ce que tu veux, tu peux même faire n'importe quoi, ce qui est plus difficile avec les fonctions de stdio.h.
geogeo Le 22/07/2003 à 17:50Edité par geogeo le 22/07/2003 à 21:43 Personnelement j'utilise les sym parce que ça va plus vite.
Tu procéde comme ça:
Ton code:
SYM_ENTRY *entry;
void *ptr;
entry=DerefSym(SymFind(SYMSTR("main\myfile)));
ptr=HeapDeref (entry->handle);
Si entry est différent de NULL c'est tout bon.
Après pour lire tu fait ça:
*(BYTE*)(ptr+52); Lit l'octet numéro 52.
Encore mieux avec memcpy.
memcpy (buffer,ptr,52); Copie dans buffer les 52 premeier octet du fichier...
Je pense mais je suis pas sur que si tu alloue ta structure en émoire et que tu définit des valeurs pour w et h ça marche.
hum
oir faire : niveauL nvo[nb_de_niveaux];moi en fait je voulais pouv
je relirais tout ca demain (après avoir réinstallé win sur mon nouveau dd)
(mais je peux p-e recharger les niveaux a partir du fichier a chaque fois, si le tableau de niveaux ne marche vraiment pas)
Si tu utilises vat.h, "charger" le niveau à partir du fichier ne coûte rien vu qu'il suffit de calculer le bon pointeur pour pouvoir lire directement (pas besoin de recopier quoi que ce soit).
avec les fonctions de stdio il suffit de repositionner le pointeur de lecture...
Mais avec les fonctions de stdio.h, tu dois tout recopier! Avec vat.h, tu peux lire directement dans le fichier à travers un simple pointeur. (Même s'il est archivé.) Cela économise de la RAM, et tu gagnes aussi du temps vu que tu ne dois rien recopier.
la structure aurait servi pour chaque niveau. je ne connais pas a lavance la taille du niveau (du moins pas quand je crée le tableau de niveaux)
Tu ne peux pas définir un tableau C si la taille des éléments n'est pas la même. Un tableau est un regroupement d'éléments de même taille.