Question de newbie sur les handles - Page 1

J'ai un doute horrible

Où se situe la taille d'un buffer par rapport au pointeur renvoyé par tios::HeapDeref : -2(an).w ou (an).w ??
Avec la macro doorsos:EREF, c'est pareil je pense (?).

Merci (j'ai honte ).
Jusqu'ici je ne m'étais jamais interrogé sur la question, jusqu'à ce que je découvre un bug dans Flash Savior, qui pourrait venir de ma gestion des handles de sauvegarde de la FAT/VAT (hein FlashZ, c'est sans-doute moi le responsable de la destruction de ta ROM avec la bêta qu'on t'as envoyé )...

Ouais c bien possible, apres je perdais regulierement des fichiers
C po un drame

Bon, pour la reponse, la taille se situe deux octets avant l'adresse renvoyee.

-2(an).w

Mais normalenemnt il faut pas y toucher, le tios le faisant tres bien

Y toucher permettra juste au TIOS de planter

Et c'est ce qui as dû se passer chez notre ami FlashZ.
J'étais persuadé que c'était à (an).w

Serais-tu prêt à retester la verson corrigée de FLS ?

Ouais.
En tout cas, ma ROM ne plante plus, pourtant, je n'ai pas reflashe...

OK, je code ça tout à l'heure, je te file la bêta dans la soirée si je peux

C'est Pen² qui va être content quand je vais lui dire que j'ai trouvé l'origine du bug méchant qui as détruit ton archive
... enfin, si c'est bien ça

et mon archive alors ??
qui me la rendra ??

pour les handle c'est effectivement -2(an).w
mais il n'y a que le nombre de MOTS [2 octets] et non pas le nombre d'octet ... car le bit n°15 sert au tios pour savoir si le handle est verouille ou pas

Donc un hdl a toujours une taille paire ?
Mais c'est plutôt le bit 0 qui empêcherai td'exprimer des tailles impaires

ben si tu alloues 21 octets le tios allouera 22 octets
et -(an).w sera :
$000B si pas verouille
$800B si verouille

enfin il me semble que c'est ca
... bon allez j'en suis preske sur : je me jete a l'eau

parce que g franchement la flemme de tester

pphd il doit bien savoir ca depuis qu'il a fait genalib !

Pourquoi ne peut-on pas allouer des buffers de 128 ko, si la taille est exprimée en mots

ben parce que le bit n°15 est utilise pour savoir si le handle est verouille ou pas !

Quel con

As-tu un truc pour allouer 2 handles qui se suivent à coup sûr ?
(j'ai pas envie de réfléchir aujourd'hui , c'est ma journée PpHd )

ben allouer un handle de la taille des deux handles lol !

lol non je suis pas aussi con que ça.

Je veux obtenir un espace mémoire de 80 ko (par exemple) linéaire... Comment faire ?
(sachant que je devrai forcément effacer la taille du 2ème hdl, mais c'est pas un pb)

soit tu fais ta propre routine d'alloc [bon courage ]

soit tu peux essayer HeapAllocHigh [on sait jamais !]
avec un peu de chance peut-etre

Mais SI ca marche et que tu effaces la taille par la suite tu dois bien t'assurer de n'executer AUCUNE ROMM_CALL suceptible de provoquer une defrag de la RAM !!!! sinon ca va planter etant donne que le deuxieme handle n'aura pas u format valide [je parle pour la taille]

Je clarifie l'histoire des -2(an) ou (an): la taille en mots se situe effectivement à -2(an), même si on est censé utiliser la ROM_CALL HeapSize pour obtenir la taille (en octets) d'un handle. Mais pour un fichier, et seulement pour un fichier, la taille du fichier se situe à (an). Mais ce n'est pas la taille du bloc mémoire. La taille du bloc mémoire fait au moins 2 octets de plus (place pour la taille du fichier) et peut être encore plus grande si la taille du fichier est impaire ou si le bloc a été alloué plus grand que nécessaire par un programme en assembleur (comme c'est le cas avec les fonctions de stdio.h dans la version actuelle de TIGCCLIB; préférez les fonctions de vat.h si c'est possible).
[edit]Edité par Kevin Kofler le 02-08-2001 à 19:33:10[/edit]

Bill Bob m'a soufflé la réponse : 2 HeapAllocHigh successifs, et on a à coup sûr les deux buffers contigües (y'a un tréma ?) !
Décidément, tu es fort

>Thibaut: Bill Bob m'a soufflé la réponse : 2 HeapAllocHigh successifs, et on a à coup sûr les deux buffers contigües (y'a un tréma ?) !

Malheureusement, c'est faux. S'il y a des TSRs installés avec HeapAllocHigh, il se peut qu'un TSR divise tes 2 blocs, surtout puisque TI a décidé (pour je ne sais pas quelle raison, peut-être qu'ils voulaient ainsi implémenter la protection anti-exécution en RAM de manière plus simple en fixant les adresses non protégées, mais ils doivent avoir abandonné cette idée - peut-être à cause du bogue de leur appareil qui fait que si la fin de la RAM est déprotégée, l'espace fantôme l'est aussi, bogue qui rend possible enter_ghost_space et h220xTSR -, puisque la protection peut être déplacée par la fonction $F du trap #$B) de faire un HeapMoveHigh lors de chaque exécution d'un programme en assembleur sur AMS 2, et donc que l'installation des TSRs avec HeapAllocHigh cause des "trous" plus ou moins grands qui ne peuvent être remplis que par des blocs suffisamment petits.

oui g bien precise qu'avec unpeu de chance ... le heapallochigh pouvait marcher ! mais pas a tout les coups !

Merde, il doit y avoir une solution.
Cherchons (je donne les ordres ) !

kevin: j'ai pas tout compris pour les tsr... il se passe quoi a l'installation d'un tsr?

oui moi non plus

Le problème est le suivant:

Supposons qu'au début, il n'y ait rien à la fin de la mémoire. Représentons-le par:
...000000000000000000000000000000000000000
Puis, lors du lancement de l'installateur (I) du TSR, AMS fait un HeapMoveHigh de l'installateur. (HeapMoveHigh déplace un bloc en fin de mémoire, comme s'il était alloué avec HeapAllocHigh dès le début.)
...00000000000000000000000000IIIIIIIIIIIII
L'installateur installe la partie résidente (R) du TSR.
...00000000000000000RRRRRRRRRIIIIIIIIIIIII
L'installateur peut-être déplacé quand l'exécution est terminé, la partie résidente non (car elle est lockée, et elle doit l'être pour que le TSR fonctionne). On se retrouve donc avec une mémoire de type:

...00000000000000000RRRRRRRRR0000000000000
trou-------------------------------^

Ce qui suit la partie "R" est un "trou" ou seuls les blocs suffisamment petits peuvent rentrer.
[edit]Edité par Kevin Kofler le 02-08-2001 à 21:45:27[/edit]

bon l'explication de kevin je l'ai pas comprise non plus
mais il y a peut de chance que la TI puisse alouer 80 Ko de RAM continue ! ... ca fait quand meme beaucoup
surtout s'il y a deja des handles verouilles en RAM grace a heapallochigh !

ok merci kevin