Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Projets » transformation d'un shell en os multitache (20 réponse(s))

./POST DE DEPART (post n°0) Marquer comme non lu.

Onur

Ecrit le: Mercredi 7 juillet 2004 à 23:25

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

On en a un peu discuté avec geogeo. Ca nous semble faisable mais assez chaud quand meme.
Voici l'idée:
OrageShell va pouvoir grace à ceci "éxécuter" (ou faire semblant je vais m'expliquer) un programme en mode sécurisé.
Cad que l'utilisateur pourra lancer un programme, et même si le programme bloque (boucle infini par exemple), on pourra revenir à OrageShell sans souci.
Voici comment je veux faire ceci. Soit un programme à éxécuter en mode sécurisé (que je vais abrégér par PAEMS). On alloue une certaine place mémoire et on recopie le PAEMS. On copie pas tout. On copie jusqu'à ce qu'on rencontre un saut (conditionel ou pas), au lieu de recopier ce saut, on met a la suite une sorte de TestKey (par exemple la touche ON), si l'utilisateur appuie sur ON, on revient à OrageShell,sinon on éxécute le saut qui était dans PAEMS.
Ainsi, en éxécutant le programme qui est presque le PAEMS mais modifié avec TestKey, on peut faire une sorte d'éxécution de pas à pas.. que l'on peut stopper avec la touche ON.
Interet: s'il y a une boucle infini, on s'en sort sans probleme.

Voila, j'espère que c'est assez clair. Parce que ca c'est la version facile.

Une première difficulté dont le modèle précédent ne tient pas compte, a été vu par geogeo: l'allocation de la part de PAEMS. Cad que si le PAEMS alloue de l'espace mémoire, on les aura pas libéré en revenant de manière "forcé" à OrageShell.
La solution consiste à arreter de recopier non seulement quand il y a une instruction de saut mais aussi quand il y a une instruction du style ROM_CALL HeapAllocPtr, et on met en place un prog qui nous permet à nous ( à OrageShell quoi) de savoir ou est alloué quoi. Et dans le cas ou on revient de manière forcé (avec la touche ON), on fera HeapFree à tous ces blocs utilisés par le PAEMS.

Une deuxième difficulté que je vais préciser sans m'attarder est la sauvegarde du registre d'état. En effet, on arrete de recopier juste avant un saut. Mais la fonction TestKey qu'on va mettre à ce niveau va modifier les flags et donc le résultat d'un saut conditionnel (si jamais il est conditionnel). Il faut peut etre sauver d'autres registres d'ailleurs, ceux qui sont modifiés quoi.

Voila, il y a encore d'autres problemes, mais je vais pas les donner tout de suite.
Si on réalise ceci, on pourra plustard faire aisément de OrageShell, un OrageOS.

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°1 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 8 juillet 2004 à 00:03

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Il y a un autre problème auquel vous n'avaez probablement pas pensé, mais qui est bien plus important que tous les autres : en recopiant le PAEMS en mémoire, comme vous y insérerez des instructions, il va falloir modifier tous les sauts du programme en prenant en compte la taille des instructions que vous aurez ajoutées.
Je pense qu'il vous faudra faire 2 passes pour pouvoir gérer ça.

Mais une solution bien meilleure est d'utiliser la même technique de PreOs (ESC + ON), regardez comment c'est foutu dans les sources. On a de la chance, l'appui sur la touche ON produit une interruption du programme en cours (pas besoin d'insérer votre code TestKey), à partir de là, il vous suffit simplement de regarder si la touche ESC est enfoncée.
Ensuite, pour revenir au Shell, il faut restaurer la pile, ça veut dire qu'il faudra sauver sa valeur avant de lancer le prog.
Pour la protection contre les leak de mémoire, c'est probablement plus simple de faire comme PreOs (hé oui, il le fait déjà...) c'est-à-dire sauver la table des handles avant de lancer le prog (250 octets suffisent il me semble) pour voir lesquels sont utilisés et pouvoir comparer au moment où le programme se sera terminé.
Le problème est que ça empêchera les TSR de s'installer... Mais si l'installateur du TSR est bien programmé et active un certain flag dont j'ai oublié le nom de la convention _nostub de commentaires, tu pourras alors ne pas activer ton système anti-leak.

Je comprends que ce sujet puisse vous passioner, mais il y a déjà des programmes concurrents qui existent et qui font les choses très bien, et qui sont programmés par des mains de maîtres. Donc sans vouloir vous vexer, vous serez probablement les seuls à utiliser votre prog (mais je comprends que ce projet puisse être intéressant à programmer quand même).

Et sinon, pour info, ça n'est pas du multitâche.

./Post n°2 Marquer comme non lu.

Invité

Ecrit le: Jeudi 8 juillet 2004 à 00:05

Un problème de taille : le ralentissement de la machine !! Il est probable que, par exemple, le grayscale ne sera de loin pas parfait...

Rajout : Sasume, désolé mais les crashs ne sont pas tous gérés par les anti-crash actuels ; essais la ligne suivante dans l'écran Home :

Exec "F0000000"

et BOOM, un joli crash qu'aucun anti-crash ne sait empêcher à l'heure actuelle...
Alors on peut encore plancher dessus.

-Edité le Jeudi 8 juillet 2004 à 00:09 par tnt-

./Post n°3 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 8 juillet 2004 à 00:34

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Ca n'a rien à voir avec la combinaison ESC+ON.

./Post n°4 Marquer comme non lu.

Invité

Ecrit le: Jeudi 8 juillet 2004 à 01:19

non, je suis tout à fait d'accord, mais ce que je voulais dire, c'est que même si des programmes concurrents font des choses très bien, ils sont loin de tout faire, et on peut donc travailler sur un tel projet de manière à apporter quelque chose.

./Post n°5 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 8 juillet 2004 à 09:47

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Mon avis est que ce type de projets, s'il est conceptuellement et éducativement intéressant ("c'est bien pour apprendre"), n'a aucun intérêt pratique (ce ne sont ni la bonne machine ni le bon OS pour faire du multitâche convenable, voir Prosit - les projets de ce style ne sont au mieux que des "proofs of concept"), et ne peut que créer des bugs et incompatibilités...
-Edité le Jeudi 8 juillet 2004 à 09:48 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°6 Marquer comme non lu.

naPO

Ecrit le: Jeudi 8 juillet 2004 à 09:50

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 2430

Membre n°17

Inscrit le 01 février 2004

Je me souviens que limmt bossait sur ce projet avec "Windows Server 2003"... Bon oui d'accord, c'est limmt aussi

Tel un automate, le dinosaure noir s'avance vers le chef des toutous-bombes et dit : "SCHNAAA SCHNAAA SCHNAPPI ! SCHNAPPI-SCHNAPPI-SCHNAPP !!!!!!" (en attendant une meilleure signature)

Avec de vrais morceaux de pattes d'eph :

./Post n°7 Marquer comme non lu.

Orage

Ecrit le: Jeudi 8 juillet 2004 à 09:57

Membre privilégié

Groupe: Orage Studio

Messages: 261

Membre n°4

Inscrit le 30 janvier 2004

De toute façon ce projet c'est pour améliorer OrageShell que j'ai déjà "releasé", ce n'est pas pour sortir un nouveau programme, alors même si vous jugez ça pas trop utile, autant faire de OrageShell un meilleur prog, non ? Perso je trouve ça interressant.

./Post n°8 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 8 juillet 2004 à 12:02

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

En fait la mémoire c'est pas bête ce que dit sasume. Suffit de sauvegarder la table de handles avant l'execution du programme. A la fin du programme on restaure la table.

Mais le problème c'est pour un malloc? Comment ça se passe au juste?

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°9 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 8 juillet 2004 à 13:27

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Comment ça ?

./Post n°10 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 8 juillet 2004 à 14:07

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Quand on alloue de la mémoire avec la fonction malloc, comment ça se passe?

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°11 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 8 juillet 2004 à 14:22

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Pareil que HeapAlloc.

./Post n°12 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 8 juillet 2004 à 15:47

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°13 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 8 juillet 2004 à 19:10

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Je ne veux pas vous empêcher de faire ce projet. C'est une bonne idée de voir les techniques pour faire quelque chose d'aussi stable que possible - on ne les apprend pas assez à l'école.
Mais je trouve le projet d'une utilité limitée, principalement car beaucoup de programmes seront incompatibles... N'oubliez pas non plus que les fonctions d'AMS ne sont pas réentrantes.

Lionel Debroux - membre de TICT.

./Post n°14 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 9 juillet 2004 à 16:26

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Allez voir mes sources de Task Switcher sur le forum de la TICT...
Et en effet, pas besoin d'un Task Switcher juste pour faire un ESC+ON à la KerNO ou Iceberg.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°15 Marquer comme non lu.

Sasume

Ecrit le: Lundi 19 juillet 2004 à 12:18

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Où en êtes-vous messieurs ?

./Post n°16 Marquer comme non lu.

Onur

Ecrit le: Lundi 19 juillet 2004 à 14:31

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

Sasume :
Pareil que HeapAlloc.

cest bien ce qui me semblait, cest pour ca qu'on a pensé a la solution que jai dit plus haut.

Sasume :
Où en êtes-vous messieurs ?

nul part.

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°17 Marquer comme non lu.

Billy Charvet

Ecrit le: Mercredi 8 décembre 2004 à 18:32

Envoyer un message privé à Billy Charvet

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

Utiliser les auto-interruptions pour intercepter les ON et tuer le programme en cours,
et faire le multi-tâches. Ensuite pour continuer sur la protection anti-plantage,
changer les vecteurs d'interruptions pour des routines plus intelligentes, hooker les
ROM Calls d'allocation pour le resource tracking (ou bitmask des handles, bon c'est
un choix...) et introduire des routines pour pouvoir utiliser les ROM Calls malgré
qu'ils ne soient pas réentrants. (Donc mutex intégrés aux programmes).

Ca sera compatible avec rien, mais peut-être qu'on peut faire un patcheur.
En tout cas c'est un gros travail.

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°18 Marquer comme non lu.

Flanker

Ecrit le: Vendredi 10 décembre 2004 à 15:15

Membre: Disciple

Messages: 126

Membre n°207

Inscrit le 23 avril 2004

changer les vecteurs d'interruptions pour des routines plus intelligentes > un peu comme le font tous les anti crash, quoi
hooker les ROM Calls d'allocation pour le resource tracking > et comment tu fais ça sans écrire dans la ROM ?

./Post n°19 Marquer comme non lu.

Folco

Ecrit le: Mercredi 15 décembre 2004 à 19:40

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Flanker :
hooker les ROM Calls d'allocation pour le resource tracking > et comment tu fais ça sans écrire dans la ROM ?

ok, je me posais la même question.

Mais une autre aussi: Où trouve-t-on les différentes valeurs des hooks, et les évènements auxquels ils sont rattachés?

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."