ça serait possible de faire un patch pour supprimer la protection d'exécution en archive sur les 89 ?
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
si je comprend bien, il ne faut pas que des flashapp soient installées
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
je ne pense pas pour la 0.2, mais sur la 0.1 il ne fallait pas depasser une certaine taille
mhackgyver> Je parlais pas d'Xpand, mais de la méthode décrite dans le texte d'ExtendeD
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
PpHd Le 29/09/2003 à 13:46 La je crois que tu auras des problemes de GC.
PpHd Le 29/09/2003 à 18:58 Ben faut changer la fonction EM_GC alors #soupir#
PpHd Le 30/09/2003 à 09:14 Je ne sais pas. tout depend comment tu t'y prends.
Non, je ne vois vraiment pas comment il pourrait y avoir de problèmes. L'algo de EM_GC() de l'AMS est assez simple, en gros :
- Il scanne toute la mémoire archive et crée un petit tableau contenant pour chaque bloc la taille des données garbage
- S'il n'y a aucune données garbage, il quitte
- S'il a trouvé un bloc vide pendant ce scan (unused, le bloc dit 'de garbage collection'), il le met en 'in use', sinon tant pis
Loop:
- Il cherche le bloc d'archive contenant la plus grosse quantité de garbage à partir de la table qu'il a créé
- S'il n'y en a plus, il quitte
- Il marque ce bloc comme 'full' pour que l'eventuel FindEmptySlot() utilisé plus tard ne cherche pas dedans
- Il parcourt toutes les entrées du bloc
- - Si c'est une entrée contenant un fichier, il la case dans un autre bloc dans une entrée trouvée par FindEmptySlot() (bloc qui peut être l'ancien 'bloc de garbage collection' mis en 'in use'). S'il ne trouve pas de place dans un autre bloc, il ne fera pas de garbage collection pour le bloc.
- - Si c'est une entrée à supprimer ou une entrée vide, il ne fait rien
- Il efface le bloc (-> 'unused')
- goto Loop
Donc dans le cas avec un bloc entièrement plein, quelque soit ça position en mémoire archive (au début dans le cas de Pedrhum), il ne sera pas touché par une garbage collection.
Et à propos du bloc de garbage : le mettre en 'in use' à la main permet d'augmenter la mémoire archive de 64ko, et on peut effectivement remplir la mémoire à ras-bord ('Archive Size' de getconfg() n'est pas mis à jour, mais ça on s'en fout).
Mais au moment où l'AMS voudra faire une garbage collection quand on videra et re-remplira la mémoire, le FindEmptySlot() de EM_GC() ne trouvera aucune place libre, et la garbage collection échouera (en gros on ne peut sortir de ce problème qu'avec un ')' + '-' en mettant une pile).
Mais on peut faire facilement un petit programme qui fait le même travaille que EM_GC() mais en utilisant de la mémoire temporaire en RAM et non en archive pour corriger le problème. Je vais peut-être faire ce programme si j'ai le temps.
En fait l'AMS peut se passer de bloc de garbage collection, sauf quand la mémoire archive est très remplie. Si le bloc de garbage collection est supprimé (mis en 'in use'), et si une GC est effecutée, il y aura au moins un bloc d'archive vidé entièrement avec ses fichiers encore existants dispatchés à coup de FindEmptySlot() dans le reste de la mémoire archive, et ce bloc deviendra 'unused' (et peut être considéré comme le nouveau bloc de garbage collection).
Donc un programme étendeur de 64ko de mémoire archive doit mettre le bloc de GC en 'in use' quand l'utilisateur en a vraiment besoin (cad quand la mémoire est pratiquement remplie).
Mais alors il posait des problèmes avec une mémoire pleine, et donc ne servait à rien du tout ?
En effet. Première GC -> plantage.
Pourquoi un plantage ? Juste une GC qui ne fait rien du tout ?
PpHd Le 06/10/2003 à 09:28 Peut etre que GC n'a pas prevu que FindEmptySlot echoue.
PpHd : non, c'est bon, s'il échoue il ne fait pas le nettoyage du bloc dans lequel ça échoue.
Pen^2 : Tu saurais retrouvé où ça se trouve dans la séquence de reset ? Les seules opérations que j'avais vu effectuées sur la mémoire archive sont faites par le trap #11 fonction 7 : (entre autres) elle marque tous les blocs vides (testés avec EM_blockVerifyErase) comme 'unused', sauf un qu'elle ne touche pas. Donc pour cette opération si jamais elle ne trouve pas de bloc de GC, elle ne fait rien.
Il me semble que pendant le reset l'AMS peut aussi réinitialiser la mémoire d'archive si elle est erronée (pas physiquement).
Euh, oui, j'ai oublié ça, c'est fonction 6 du trap #11.
J'ai reçu un bug report bizarre, je ne pense pas que ça vienne d'Xpand mais on ne sait jamais : est-ce que quelqu'un utilisant Xpand pourrait me dire s'il n'y a pas de problème avec l'Auto Power-Down (un crash quand la calc s'éteint) ?
Ou quelqu'un pourrait laisser sa calc s'éteindre toute seule pour vérifier ?
ok, je le fais tout de suite
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
(même si ça reste un hack qui ne marche pas tout le temps, et c'est qd même assez contraignant sur 89/V200 HW2 de devoir installer un hook à chaque reset avant la première extinction, sinon reset obligatoire). Au fait PedRhum n'a pas de pbs avec les garbages collections?
Attention, édite tout de suite ton post! 
GNU Team
), avec l'ex secteur de GC marqué pour l'effacement)
