Nouvelle convention de TSR - Page 1

Bon voilà, comme les TSR actuels sont un peu limités, j'aimerais bien disposer d'un nouveau standard pour tous types de TSR.
Je voudrais :
- un seul désinstalleur doit suffir à tous les désinstaller, qu'il soit si possible compatible kernel. nostub (sinon tant pis pour le mode nostub ^^)
- dans un seul handle il puisse avoir plusieurs types de tsr (trap, hook, auto-int)
- qu'on puisse communiquer avec eux (leur dire qu'on va les enlever, par exemple, ou les prévenir qu'on va supprimer un autre TSR)
- si possible avoir importation et exportation de fonctions d'un tsr à l'autre, sur le modèle des libs kernel

si vous avez de nouvelles idées...

pour l'instant, je pensais avoir un handle principal qui contiendrait une liste de longword, avec chacun dans la partie haute le type de TSR (ça fait 16 types possibles) et dans la partie basse le handle correspondant. Comme il y a au maximum 2000 handles (enfin, c'est trop rare qu'il y en ai plus), on peut passer à 21 types possibles (suffisament pour les trap et auto-int).
Pour les EV_Hook:
Chaque handle pourrait ne contenir que du code pur, sans aucune info : un Hook principal parcourrait la liste et appelerait les Hook à ce format les uns après les autres, avant de passer la main aux Hook qui sont à des formats plus vieux.

Pour les autres TSR :
là je sais moins
j'aimerais une fonction capable de gérer les Events pour offrir un moyen simple de communication, et qui ne prenne pas trop de place.
Ensuite, il faut bien stocker les adresses des anciens trap ^^ (mais on peut faire la même chose que pour les hooks pour ça)

Si c'est pas perdu t'entendre avec Kevin pour avoir quelquechose de compatible qu'il s'engage a ne pas casser pour son plaisir personnel dans 10 jours.

de toute façon, là ça n'a plus rien à voir avec sa convention
elle sera complètement différente, donc pour la compatibilité... bof
enfin, disons que son désinstalleur ne verra pas ces TSR-là, mais ça casse pas vraiment la liste chaînée des TSR actuels

Je suis contre. Il y a déjà une convention pour les hooks d'évènements qui marche très bien, je ne vois pas pourquoi je devrais l'étendre seulement parce que monsieur Flanker ne veut pas la respecter telle quelle. Et en plus, même si j'accepte ces extensions, <SENS FIGURÉ>demain</SENS FIGURÉ>, ce ne sera toujours pas assez pour lui (la preuve: déjà vécu ), alors c'est non sans discussion possible.

je ne vois pas le rapport avec le schmiblick ? je ne parle pas d'une extension de ta convention là

et c'est pas parce que tu dis non qu'elle verra moins le jour

Tu parles d'un remplacement total, donc c'est encore pire. Tu ne t'engages pas à respecter la convention que le reste de la communauté utilise, donc pour moi tu es tout aussi anti-coopératif que M$.

remplacement ? où ça ?

encore une fois, je ne vois pas en quoi je suis anti-coopératif ou alors, encore une fois, tu n'as rien compris à ce que je veux faire

Flanker
: remplacement ? où ça ?

Flanker :
Pour les EV_Hook:

(emphasis mine)

Flanker :
de toute façon, là ça n'a plus rien à voir avec sa convention elle sera complètement différente, donc pour la compatibilité... bof

et alors ? en quoi ça remplace ?

Flanker :
encore une fois, je ne vois pas en quoi je suis anti-coopératif ou alors, encore une fois, tu n'as rien compris à ce que je veux faire

J'ai très bien compris que tu veux remplacer ma convention par une autre, jetant ainsi à la poubelle des années de travail pour la compatibilité inter-hooks de ma part.

Il ne fais pas un remplacement il fais une nouvelle convetion vu que la tienne refuse d'évoluer.

Flanker
: et alors ? en quoi ça remplace ?

C'est une convention pour les hooks d'évènements, donc c'est un standard concurrent au standard établi (qui est le mien).

et alors, tu veux bien remplacer le format kernel par le nostub, jetant ainsi à la poubelle des années de travail pour la compatibilité inter-hooks de la part de plein de gens. Et puis, faut pas exagérer, elle est quasiment vide, ta convention

Uther
: Il ne fais pas un remplacement il fais une nouvelle convetion

En d'autres mots: "Cet animal n'est pas un porc, c'est un cochon."

Putain Kevin tu commences à vraiment me faire chier à gueuler dès qu'on fait un truc qui doit remplacer qqc qui vient de toi

et alors, tu veux bien remplacer le format kernel par le nostub, jetant ainsi à la poubelle des années de travail pour la compatibilité inter-hooks de la part de plein de gens. Et puis, faut pas exagérer, elle est quasiment vide, ta convention

entièreemnt de cet avis

Flanker
: et alors, tu veux bien remplacer le format kernel par le nostub, jetant ainsi à la poubelle des années de travail pour la compatibilité inter-hooks de la part de plein de gens.

???
Le format _nostub n'a rien d'incompatible avec le format kernel. Les exécutables ne sont pas tous dans une liste chaînée d'appels de fonction dans laquelle tout doit coopérer pour garantir le fonctionnement correct.

Et puis, faut pas exagérer, elle est quasiment vide, ta convention

Ben, c'est que j'aime bien les formats simples comme le _nostub ou ma convention de hooks. Et tu vois bien que je ne suis pas le seul! La tendance va justement vers le format _nostub parce qu'il est plus simple, et on évite de gaspiller de la place à gérer des formats compliqués.

K² > de toute façon, je ne prendrais pas ton avis en compte

Le format _nostub n'a rien d'incompatible avec le format kernel. Les exécutables ne sont pas tous dans une liste chaînée d'appels de fonction dans laquelle tout doit coopérer pour garantir le fonctionnement correct.

si c'est pour raconter des conneries, tu dégages

on évite de gaspiller de la place à gérer des formats compliqués

on évite de gagner de la place à utiliser des librairies dynamiques

Heu si on en revenait au TSR

Flanker
:

Le format _nostub n'a rien d'incompatible avec le format kernel. Les exécutables ne sont pas tous dans une liste chaînée d'appels de fonction dans laquelle tout doit coopérer pour garantir le fonctionnement correct.

si c'est pour raconter des conneries, tu dégages

Des conneries?! En quoi est-ce des conneries???

K² > je répondrais plus à tes posts, tu ne fais que troller

étrangement, j'ai le sentiment que Flanker aurait déjà été kické sur TICT, s'il avait ton comportement, Kevin...

bon, j'explique plus clairement :
un EV_Hook au format EvHk (enfin, la version 2, quoi) aura une liste de Hook et il va les exécuter les uns après les autres. Mais lui même sera au format EvHk, donc il ne cassera pas la compatibilité. Mais les Hooks dans la liste, eux, seront à ma convention à moi, sans aucune compatibilité avec la tienne

Kevin Kofler
:

Flanker :
encore une fois, je ne vois pas en quoi je suis anti-coopératif ou alors, encore une fois, tu n'as rien compris à ce que je veux faire

J'ai très bien compris que tu veux remplacer ma convention par une autre, jetant ainsi à la poubelle des années de travail pour la compatibilité inter-hooks de ma part.

mais lol
Elle est vraiment belle, la mentalité ^^ Si toi, tu fais le choix d'interdire les TSR kernels et de rester à un truc plus simple, je ne vois pas en quoi tu as à te plaindre que qqun choisisse de faire un truc plus vaste qui les implémente Encore, si Flanker avait fait exprès de tout casser pour le plaisir d'avoir 2 conventions, d'accord, mais là c'est toi qui as refusé ses ajouts ; après soit ils sont utiles et à ce moment-là c'était une bonne idée pour la communauté que Flanker rajoute ces possibilités (qui, sans ça, n'auraient jamais vu le jour), soit ils sont inutiles/trop lourds et à ce moment-là tu n'as pas non plus à te plaindre qu'il ait fait sa propre convention. Dans les deux cas, c'est tout bénéf pour les utilisateurs, alors pour toi qui dis agir pour le bien de la communauté, où est le pb ?

Tu n'as pas l'impression par moments que l'énergie que tu mets pour que tes progs soient utilisés est parfois (souvent ?) néfaste ? Parce que, si Flanker n'avait pas eu assez de motivation pour s'opposer à toi, ça aurait été encore un n-ième projet tué dans l'oeuf ^^ (comme l'ont été par exemple à une époque des tentatives de faire une lib dynamique pour TIGCCLib qui ferait qu'en C, le mode kernel serait un vrai mode kernel et pas un mode nostub avec un stub patché par dessus -- en l'occurrence tu as tout refusé en bloc, et personne n'était assez motivé pour maintenir un fork de TIGCC)

Flanker
: K² > je répondrais plus à tes posts, tu ne fais que troller

C'est toi qui ne fais que troller en accusant mes messages tout à fait cohérents d'être des "conneries". Ou alors il faudra que tu m'expliques en quoi ce sont des "conneries"...