encore un TSR ;) - Page 3

mais euh arrête de trouver des bugs !

pour les problèmes d'exécution, je suis en train de refaire la fonction d'exécution (ça va permettre d'avoir un viewer de texte, et d'exécuter les progarmmes compressés et les ppg), donc je vais pas trop chercher à débugguer ça pour l'instant

Si t'appuis sur F3+Haut trés rapidement alors qu'on est pas dans MicroShl, l'icone Home s'affiche en premier (c juste un défaut d'affichage).

j'ai une vague idée pour corriger ce bug.

Revenir à la fin de la dernière ligne quand on appuis sur bas depuis la fin de l'avant dernière ligne (quand y a un ligne de 5 icones et une ligne de 2, si le curseur se trouve sur la 5è icone et qu'on appuis sur bas, le curseur bouge pas. C surtout génant quand la dernière ligne n'est pas affiché à l'écran)

ouep, ça devrait être faisable, ça va aller dans ma TODO list

Et est-ce que tu pourrait les racourcis du menu Apps (Apps affiche le le menu à icone et si on appuis sur 7 puis 1, ça ouvre le prgm courant dans l'éditeur) comme avec ID.

ça désactive ceux d'ID ?

Bah... je c pas, g pas installé ID (je savais pas si ct compatible, et puis bon, pour un débogage, vaut peut-être pas trop en demandé trop à la calc, je trouves assé de bug comme ça).
Et puis ID fait 7Ko.

j'hésite beaucoup à le rajouter, je trouve que MicroShl est plutôt un complément à ID donc _ça serait dommage de mettre du code en double (et ça prend quand même un peu de place de gérer ça)
je vais voir, vu que je vais gagner 500o, je pourrais peut-être les reperdre comme ça

Avec ton nouveau format, t'av pas dit que ct possible d'utiliser certaines fonctions d'un TSR pour un autre TSR ou programme ??
Ce serait peut-être plus pratique de convertir ID, nan ??

ID n'est pas compatible avec le nouveau format

2 petites questions : il me faut un raccourci clavier pour tout sélectionner, et un pour archvier (aute que <> + A). tu me conseilles quoi ?

Ui, je c, il a été programmer avant que tu ne mettes au point ton format, mais ce serait pas plus simple de convertir ID au nouveau format ??

faut demander à ExtendeD , c'est vrai qu'il n'y a pas grand chose à faire

Bah... étant donnée que le code source est inclu dans le fichier zip, je suppose qu'il est possible de le modifier puis de lui soumettres les modifications (y a rien de précis dans le readme) ??

bah en fait, faut juste que l'un des 2 TSR le fasse, y a pas vraiment besoin d'une réelle interaction entre les 2, nan ?

A priorie, les deux semblent compatible, mais g l'impression qu'il y a un leak de mémoire (de 168Ko, je suis passé à 167).

Je viens de resortir ma calc poussièreuse pour le tester, il commence à avoir l'air sympa ce ptit programme
Voilà quelques petits bugs :
- Impossible de supprimer un dossier, même vide : "Argument must be an empty folder name."
- 'Enter' dans un dossier vide fait une Argument Error puis un crash.
- L'exécution de SIDE ou de mon patch pour 89 Titanium (qui ne fait qu'un ST_helpMsg lancé d'un shell) jette une Internal Error.

Je jetterais bien un coup d'oeil aux sources, tu ne les distribues pas ?

MacIntoc
: A priorie, les deux semblent compatible, mais g l'impression qu'il y a un leak de mémoire (de 168Ko, je suis passé à 167).

A quel moment ?

Je viens de resortir ma calc poussièreuse pour le tester, il commence à avoir l'air sympa ce ptit programme

merci

- Impossible de supprimer un dossier, même vide : "Argument must be an empty folder name."

ok, je vais voir ça. J'ai dû confondre entre le nombre de variables dans le dossier et le nombre maximal de variables dans le dossier

Je jetterais bien un coup d'oeil aux sources, tu ne les distribues pas ?

j'attend d'avoir refait l'exécution des programmes ; je reprends tout à 0, en utilisant cette fois kernel::exec

- 'Enter' dans un dossier vide fait une Argument Error puis un crash.

c'est bizarre, chez moi ça marche (mais il me semble que c'est pas super joli la façon dont je traite les dossiers vides, je vais revoir ça)

Je jetterais bien un coup d'oeil aux sources, tu ne les distribues pas ?

J'attend d'avoir fini ce que je dois rajouter, dans une semaine ou 2 si tout va bien. Mais je peux te les envoyer avant si tu veux

Je n'ai pas trop suivi l'histoire, mais pourquoi un programme kernel, et pourquoi un désinstalleur qui n'est pas celui de Kevin ?

Flanker
: J'attend d'avoir fini ce que je dois rajouter, dans une semaine ou 2 si tout va bien. Mais je peux te les envoyer avant si tu veux

Oui, je veux bien

pourquoi un désinstalleur qui n'est pas celui de Kevin

Oui, j'aurais pu mettre UnInevhk 3.00, mais UnHook est 40% plus petit et je l'ai créé quelques semaines avant la sortie d'UnInevhk 3.00, donc je trouve que la question serait plutôt pourquoi celui de Kevin ?

Pourquoi un programme kernel ?

1) c'est plus simple à programmer au niveau de la compatibilité 89/92+ (avec les RAM_CALL)
2) ça me permet d'avoir une lib qui installe les TSR, ce qui simplifie la programmation de TSR de façon générale (maintenant, il me suffit juste de savoir programmer une fonction void TSR(EVENT* event)
3) ça permet de rejeter les problèmes de compatibilité / restrictions sur le kernel (enfin, ça sera le cas quand Preos 0.70 sera sorti, son RAM_CALL kernel::ghost_space permettra d'avoir un programme qui marche sur toutes les TI sans avoir à l'alourdir, et il n'y a pas besoin d'inclure h220xtsr (j'ai 10 TSR sur ma calc, et j'ai pas envie de l'avoir dans chaque programme)
4) j'utilise des RAM_CALL de Preos pour alléger le contenu en RAM. En fait, MicroShl installe juste une partie en RAM et exporte des fonctions (une seule pour l'instant), quand on choisit une action (renommer, par exemple), la partie en RAM appelle MicroShl comme une lib dynamique standard. Ca me permet d'avoir 4ko d'utilisation de RAM, au lieu de 6 (et bientôt au lieu de 7 ou 8 quand j'aurai fini la partie exécution). En plus, ça va me permettre de gérer simplement 2 types de compression (ZIP et XPAK)

P.S. mail envoyé

Alors, les réactions sont différentes selons qu'on instal en premier MicroShl ou ID.

Si MicroShl est installé en premier, tous fonctionne, mais les kbdprgmX sont lancés 2x succéssivement.

Si ID est installé en premier, les raccourcis (kbdprgmX et menu) ne marchent que lorsque MicroShl est en cours d'affichage. Et il a l'air d'y avoir un leak de 26 octets si un kbdprgm est lancé depuis une autre section que MicroShl.

Sinon, faut que MicroShl pense à effacer son en-tête quand on lance un des éditeurs avec les raccourcis menu.

Si MicroShl est installé en premier, tous fonctionne, mais les kbdprgmX sont lancés 2x succéssivement

oups, petit oubli de ma part ...

Si ID est installé en premier, les raccourcis (kbdprgmX et menu) ne marchent que lorsque MicroShl est en cours d'affichage. Et il a l'air d'y avoir un leak de 26 octets si un kbdprgm est lancé depuis une autre section que MicroShl.

ça, c'est plus étrange, va falloir y réfléchir un peu plus sérieusement. Je vais jeter un coup d'oeil dans la source d'ID

Sinon, faut que MicroShl pense à effacer son en-tête quand on lance un des éditeurs avec les raccourcis menu.

µ
quel en-tête ?

La bar de RAM, le nom, le type et la taille du fichier courant.

Flanker : tu as l'air de rechercher un pointeur vers les données des dossiers du Desktop de façon plus propre qu'ID, c'est quoi ta méthode exactement ?

euh j'en sais rien ça fait à peu près un an que j'y ai pas touché à ça. Je me souviens juste avoir faire tourner le désassembleur et l'éditeur hexa. Si je me replonge dans le code, je retrouverais peut-être

va falloir que je change un peu mon code, il est laid
en fait c'est tout con, l'adresse des dossiers est sauvée dans un pointeur tout au début du handler (attribut 0x4 des applications flash) du desktop.
Le début du code du handler donne ça :

link    a6,#$FFE8
movem.l d3/a2-a3,-12(a6)
move.l  12(a6),a2  ; <- là on récupère l'event à traiter
lea     $82FC,a3 ; <- adresse des dossiers

je vais modfier ça un peu pour faire plus propre (au moins vérifier que c'est un lea, l'instruction. Là je ne fais aucune véfication. Ca se voit que je ne pensais pas distribuer ce programme ^^

opur le get_attribute, il y a un ROM_CALL qui fait la même chose, mais quand j'ai programmé ma routine, je n'avais ni ordi ni doc et je ne savais pas qu'elle existait. Et depuis, je l'ai conservée

Ok.
Faut aussi pas avoir peur de l'offset utilisé avec ce pointeur, s'ils font évoluer un peu leur app Desktop ça pourrait facilement casser (c'est encore bon sur AMS 3).

ouep, faudrait l'améliorer un peu, disons que c'est une bonne base

Ça serait bien de présenter aussi mon avis sur les actions de Flanker...

Bah voilà qui est fait, de quoi tu te plains ?

Flanker
:

Pourquoi un programme kernel ?

1) c'est plus simple à programmer au niveau de la compatibilité 89/92+ (avec les RAM_CALL)

LOL l'excuse... On arrive très bien à s'en passer. Et au pire, on fait 2 versions.

2) ça me permet d'avoir une lib qui installe les TSR, ce qui simplifie la programmation de TSR de façon générale (maintenant, il me suffit juste de savoir programmer une fonction void TSR(EVENT* event)

<SARCASM>C'est sûr que c'est trèèès difficile de copier-coller la dizaine de lignes d'assembleur pour appeler le prochain TSR de la liste chaînée...</SARCASM> (Avec les CM_EVHK_*, c'est plus compliqué à gérer, mais c'est pour ça que je suis contre.)

3) ça permet de rejeter les problèmes de compatibilité / restrictions sur le kernel (enfin, ça sera le cas quand Preos 0.70 sera sorti, son RAM_CALL kernel::ghost_space permettra d'avoir un programme qui marche sur toutes les TI sans avoir à l'alourdir,

Tu veux dire kernel::kernel_space? Et sinon, il suffit d'appeler __gethwversion. Et le prochain h220xTSR renverra aussi un code de retour unique pour les HW>=3, donc tu pourras réutiliser la détection déjà effectuée par h220xTSR.

et il n'y a pas besoin d'inclure h220xtsr (j'ai 10 TSR sur ma calc, et j'ai pas envie de l'avoir dans chaque programme)

Samuel Stearley ne le met pas non plus dans les siens. Tu n'es pas obligé de mettre quoi que ce soit. Tu peux aussi tester la présence de h220xTSR ou HW2Patch/HW3Patch tout aussi simplement que le test de la présence du kernel.

4) j'utilise des RAM_CALL de Preos pour alléger le contenu en RAM. En fait, MicroShl installe juste une partie en RAM et exporte des fonctions (une seule pour l'instant), quand on choisit une action (renommer, par exemple), la partie en RAM appelle MicroShl comme une lib dynamique standard. Ca me permet d'avoir 4ko d'utilisation de RAM, au lieu de 6 (et bientôt au lieu de 7 ou 8 quand j'aurai fini la partie exécution).

4 KO TSR kernel + 3 KO kernel > 6 KO (TSR _nostub). Et le chargement et relogement d'une librairie kernel, c'est leeeent. Trop lent pour un TSR.
Et puis, si tu veux vraiment le faire, tu peux aussi utiliser un fichier externe sans kernel, Complete le fait très bien.

En plus, ça va me permettre de gérer simplement 2 types de compression (ZIP et XPAK)

Tu sais ce qu'est un compresseur exécutable (à la PepZip)?

LOL l'excuse... On arrive très bien à s'en passer. Et au pire, on fait 2 versions.

ah bon ? ah bah heureusement que tu me le dis, je ne m'en serais jamais douté

<SARCASM>C'est sûr que c'est trèèès difficile de copier-coller la dizaine de lignes d'assembleur pour appeler le prochain TSR de la liste chaînée...</SARCASM>

où ai-je dit que c'était difficile ?

Tu veux dire kernel::kernel_space? Et sinon, il suffit d'appeler __gethwversion. Et le prochain h220xTSR renverra aussi un code de retour unique pour les HW>=3, donc tu pourras réutiliser la détection déjà effectuée par h220xTSR.

sauf que là je n'aurai pas à toucher à mes programmes en cas de nouvelle calc.

4 KO TSR kernel + 3 KO kernel > 6 KO (TSR _nostub).

sauf qu'a priori le kernel il ne sert pas qu'à mon TSR c

Et le chargement et relogement d'une librairie kernel, c'est leeeent. Trop lent pour un TSR.

évite de parler de ce que tu ne sais pas, merci

Et puis, si tu veux vraiment le faire, tu peux aussi utiliser un fichier externe sans kernel, Complete le fait très bien.

c'est chiant à faire proprement

Tu sais ce qu'est un compresseur exécutable (à la PepZip)?

nan ! vas-y, explique moi !

au passage, tu n'iras pas te plaindre que les gens lancent des trolls dans tes topics

Flanker
:

Tu veux dire kernel::kernel_space? Et sinon, il suffit d'appeler __gethwversion. Et le prochain h220xTSR renverra aussi un code de retour unique pour les HW>=3, donc tu pourras réutiliser la détection déjà effectuée par h220xTSR.

sauf que là je n'aurai pas à toucher à mes programmes en cas de nouvelle calc.

Avec h220xTSR non plus, vu que h220xTSR ne fera plus rien pour HW_VERSION>=3 (il ne peut rien faire! Il ne fera plus que tester la présence du HW3Patch, sinon, ERROR: Unsupported hardware version), et l'offset pour l'adresse sera tout simplement 0.

Et le chargement et relogement d'une librairie kernel, c'est leeeent. Trop lent pour un TSR.

évite de parler de ce que tu ne sais pas, merci

Évite de m'accuser d'ignorance sans fondement, merci.

Et puis, si tu veux vraiment le faire, tu peux aussi utiliser un fichier externe sans kernel, Complete le fait très bien.

c'est chiant à faire proprement

Donc tu avoues que Samuel Stearley est un meilleur programmeur que toi?

Tu sais ce qu'est un compresseur exécutable (à la PepZip)?

nan ! vas-y, explique moi !

Tu veux vraiment que je t'explique?
Sérieusement, c'était une question rhétorique, et ta réponse ridicule évite une fois de plus mon argument en cherchant à me ridiculiser...

Flanker
: au passage, tu n'iras pas te plaindre que les gens lancent des trolls dans tes topics

C'est toi qui as commencé par faire de la pub pour le kernel!

Ce n'est pas un crime.
S'il veut parler de kernel dans le topic de son projet qui est un shell kernel, c'est son droit le plus strict, et s'il n'a pas envie que son topic soit trollé, je ne peux que lui donner raison... A lui de voir.