Supprimer le twin - Page 1

Est-ce possible, dans un prog C, de copier le prog en RAM, d'exécuter ce code, puis de supprimer le twin à partir du code alloué par le prog?

Si oui, est-ce qu'il faut recréer le twin après?

L'est pas claire ta question

Pour exécuter un prog, il suffit de faire une copie en RAM, donc c'est inutile de créer un twin (sauf pour lancer tictex, sinon ça bug avec le GUI...). Et si c'est inutile de créer un twin, y a pas besoin de le supprimer

guilc
a écrit : Pour exécuter un prog, il suffit de faire une copie en RAM

Pollux va etre content qu'on lui file une telle info

Pollux
a écrit : Est-ce possible, dans un prog C, de copier le prog en RAM, d'exécuter ce code, puis de supprimer le twin à partir du code alloué par le prog?

Je pense que oui.

Si oui, est-ce qu'il faut recréer le twin après?

Je pense que non.

À vérifier.

Thibaut a écrit :
L'est pas claire ta question

Elle est très claire. C'est la réponse qui n'est pas évidente.

Oui, sinon ca crash des un appel a SymFind????

Kevin : effectivement, je crois que je viens de comprendre


Il ne suffit pas tout simplement de détourner le champ handle du SYM_ENTRY du twin vers la copie ?
Comme ça on peut effacer l'original, et la copie sera effacée par le TIOS (qui croira effacer le twin originel).

Non ?
Bon j'ai pas comrpis alors

Je ne sais pas.
Ce que je sais, par contre, c'est que ça *risque* d'être très sale...

c clair

préparez les eponges

Ca marchera pas !!!! Faut pas toucher au twin et a l'original sans tout changer !
Sinon, crash !

bon donc en gros vous savez pas
tant pis, je vais faire des essais

XDanger> Ce que je sais, par contre, c'est que ça *risque* d'être très sale...
Certes, mais c pas du code statique mais du code partagé, donc remis à jour facilement en cas d'incompatibilité

C'est une excuse bidon!
Avec des raisonnements comme ça, vous vous étonnez encore que tout le monde se plaint de l'état bogué des librairies dynamiques???

N'importe quoi, en effet...
Les kernels ont été améliorés depuis DoorsOS II 0.98... mais DoorsOS II 0.98 reste un des plus utilisés. Donc la mise à jour est juste une illusion.

Le problème n'est pas que ça, c'est aussi que si on programme de manière sale en se disant "je vais corriger plus tard":
* tant que ce n'est pas corrigé, tous les utilisateurs reçoivent un programme / une librairie bogué(e).
* cet "argument" garde toujours la même "validité" et donc on repousse toujours les corrections à faire. Pire, on rajoute toujours plus de saletés en se disant à chaque fois "on va corriger après".
C'est ces raisonnements-là qui font que certaines librairies dynamiques en mode kernel ont toujours été (et sont toujours, même si PpHd a fait un effort pour améliorer la situation) très boguées.

Conclusion: utilisez des librairies statiques, leurs mainteneurs sont plus responsables. Par exemple, dans TIGCCLIB, nous corrigeons toujours tous les problèmes très peu de temps après leur signalation.

Vous critiquez sans savoir de quoi vous parlez. Attendez de voir, car il me semble qu'aucune des critiques que vous faites au kernel ne s'applique ici...

Et il est même possible que Kevin se mette au format GT Virtual Machine (si si!)

Ouais, si tu le sors vraiment un jour...

Franchement, je pense que je continuerai à préférer le C et l'assembleur:
1. Je n'aime pas les VMs (j'en ai déjà eu marre de VB et de ses DLLs de plusieurs MO: MSVBVM??.DLL et toutes ses dépendances), et encore moins sur calculatrice. Les VMs gaspillent de la place et ralentissent les programmes. Il vaut vraiment mieux programmer en un langage compilé, d'autant plus qu'on est sur une calculatrice.
2. En tant que membre de l'équipe de TIGCC, je n'ai pas très envie d'aller programmer avec des compilateurs concurrents à TIGCC, et je considère GTC et GT-BASIC comme des concurrents de TIGCC.

Pollux a du talent, mais ses idées ne sont pas toujours bien exploitables sur une calculette... La VM ne va en effet vraiment pas dans le sens de l'efficacité...

> GTC et GT-BASIC comme des concurrents de TIGCC.
Oui. C'est d'ailleurs pour cela qu'ils n'ont très probablement qu'une chance limitée de percer...

XDanger
a écrit : Oui. C'est d'ailleurs pour cela qu'ils n'ont très probablement qu'une chance limitée de percer...

C'est sûr que si on compare un compilateur on-calc et un pour PC

XDanger
a écrit : mais DoorsOS II 0.98 reste un des plus utilisés.

je ne voudrais pas dire, mais s'il n'y av pas sur ticalc.org le dossier nommé 'doorsos' pour les progs kernels, ça serait bcp - le cas il me semble


faudrait au - les renommer en 'kernel'

franchement kévin ton attitude me déçoit... je n'ai aucune envie de débattre là-dessus, de toute façon quand tu verras la taille des programmes GT-Basic je crois que tu fermeras ta gueule

ExtendeD: > C'est sûr que si on compare un compilateur on-calc et un pour PC
Bonne remarque. Mais combien de personnes programment on-calc, et combien programment on-PC ? Donc, ai-je extrêmement tort ?

Pen²: > je ne voudrais pas dire, mais s'il n'y av pas sur ticalc.org le dossier nommé 'doorsos' pour les progs kernels, ça serait bcp - le cas il me semble
Je ne voudrais pas dire, mais il faudrait que tu le signales au webmaster de ticalc.org si tu ne l'as pas déjà fait...
Mais je pense que c'est assez représentatif de la méconnaissance du monde entier à propos du kernel, c'est à dire le peu de place que le kernel a dans la communauté mondiale...

Pollux: > franchement kévin ton attitude me déçoit... je n'ai aucune envie de débattre là-dessus, de toute façon quand tu verras la taille des programmes GT-Basic je crois que tu fermeras ta gueule
Let's wait 2042 and see...
Pourquoi donc ne veux-tu pas débattre ? J'espère sincèrement, en tout cas, que ça n'est pas parce que tu n'as que peu d'arguments...

C'est moi qui ai proposé le nom "doorsos" pour le répertoire (à l'époque). Et cela parce que:
* les dossiers pour les programmes pour un certain shell sur ticalc.org portent toujours le nom du shell qui a inventé le format, même si ce n'est pas le meilleur (regardez dans les répertoires pour les autres calculatrices pour vous en persuader). Le format kernel sur TI-89/92+/V200 a été inventé par DoorsOS. Le seul "kernel" sorti avant était PlusShell 0.99 alpha, qui utilisait un autre format.
* à l'époque, DoorsOS fonctionnait encore.

XDanger a écrit :
ExtendeD: > C'est sûr que si on compare un compilateur on-calc et un pour PC Bonne remarque. Mais combien de personnes programment on-calc, et combien programment on-PC ? Donc, ai-je extrêmement tort ?

Peut-être qu'il n'existe pas encore de compilateur on-calc ? (en excluant CC qui n'a pas été bcp distribué, et l'autre compilo qui ne génère pas d'executable)

XDanger
a écrit : Oui. C'est d'ailleurs pour cela qu'ils n'ont très probablement qu'une chance limitée de percer...

Arf... En temps que 1er "vrai" compilateur oncalc je pense qu'au contraire il a de grandes chances d'avoir du succès. Et puis de toute façon, comme ça a été dit, il s'agit d'un compilateur oncalc et un autre sur PC, donc l'un si bien qu'il soit ne risque pas de concurencer l'autre...

J'ai des doutes sur Kevin en ce moment. Il est fatigué ?