Preos 0.64 - Page 3

est-ce utile cette base ???

Dites le moi

nEUrOne
a écrit : est-ce utile cette base ???

Non.

>est-ce utile cette base ??? Non

évidemment tout ce qui pourrait donner un avantage sur le Nostub au Kernel est inutile pour toi.
Personellement si c'est bien fait ca pourrait être très utile pour mettre des donnée en commun entre plusieurs applications. Mais il faudrait éviter que ca devienne un bordel foure tout comme la base de registre Windows

Je ne pense pas qu'une base de donnée serait vraiment utile sur calculatrice, elle est suffisament rapide pour que chacun se la fasse à la volée ....

L'avantage c'est de centraliser les données avec un format commun standard!

Bof .. c'est inutile je pense sur calculatrice, le nombre d'apps et de fichier ne se compte pas souvent en milliers

Uther Lightbringer a écrit :
évidemment tout ce qui pourrait donner un avantage sur le Nostub au Kernel est inutile pour toi. Personellement si c'est bien fait ca pourrait être très utile pour mettre des donnée en commun entre plusieurs applications. Mais il faudrait éviter que ca devienne un bordel foure tout comme la base de registre Windows

Uther Lightbringer
a écrit : L'avantage c'est de centraliser les données avec un format commun standard!

Il faut mettre le code pour le faire dans TIGCCLIB alors, pas dans PreOs. Déjà parce que sinon, ça ne sera pas un "format commun standard" vu que les programmes _nostub ne pourront pas s'en servir, et puis parce qu'il n'y a aucun intérêt à avoir ça dans le kernel et pas dans TIGCCLIB.

Pourquoi ? C'est commun a tous les progs kernel PreoS

C'est le mot "kernel" qui me dérange dans ta phrase.
"tous les programmes kernel" != "tous les programmes". Les programmes kernel ne sont qu'une très petite minorité des programmes récents. Et les vieux programmes n'utiliseront pas les nouvelles fonctionnalités.

Donc franchement, si vous voulez vraiment ce genre de fonctionnalité (personnellement, l'idée de "base de registres" me fait peur), ça a sa place dans TIGCCLIB, pas dans PreOs.

Pas d'accord !

Moi, je ne veut pas d'un Windaube on-calc qui bouffe tout plein de ressources. Mon PC sert a ce genre de conneries.

Ca sera bien fait.

ha aussi une autre disparition du readme: kernel::exec_from_scratch(désolé je ne suis absolument pas sur de l'orthographe) j'ai mal vu ou c'est abandonné car je comptais m'en servir

Ah si tu comptais t'en servir je vais peut etre le resuciter
Des propositions pour un meilleur nom ?

Je le nom me va tant que c'est implémenté

Je croyais que personne n'en voulait, c'est pour ca.
Je prevois peut etre un kernel::exec_secure (pour eviter que le plantage) ne fasse tout quitter. Peut etre kernel::exec_secure_exclusif.
Arg, je sais pas !

Pour mon shell c'est très pratique ca éviterai voir des plantage quand on lance une appli trop grosse, sinon je me serai contenté d'un simple kernel::exec mais c'est quand même mieux kernel::exec_from_sc...
Le kernel secure serait bien pratique aussi.

Bon faut que je mixe les deux dans un seul ram_call :
kernel::exec_???? (a vous de voir)

+ Memorisation de la tache courante.
+ Derallocation du programme courant
+ Sauvegarde du point d'entree pour secure.
+ Execution programme.
+ Enlever le point d'entree.
+ Reallocation du programme
+ continuer.

N'oublie pas que les pointeurs changeront !
Tu comptes garder la section BSS ? Ou je peux l'effacer ?

Ca me va, je n'utilise pas la section BSS et je pourrais sauvegarder les variables utiles dans un fichier externe

La pile ne sera pas detruite. C'est au shell de la baisser s'il le veut.

PpHd
a écrit : Des propositions pour un meilleur nom ?

Déjà, c'est "scratch" et pas "scrach" comme écrit dans tes anciens fichiers readme.

Et puis, l'intérêt est assez limité. Un shell n'a qu'à faire ce que fait le TICT Explorer (shell en 2 morceaux, et on décharge le gros morceau de la RAM quand on lance un programme).

La pile ne sera pas detruite. C'est au shell de la baisser s'il le veut.

Si tu fais déjà une partie du travail, pourquoi ne pas le faire en entier?

bof de toute façon a moins d'être un violent sur l'usage de la pile(ce qui n'est pas mon cas) ca ne posera pas de problèmes

Mais ca pose quelques gros problemes cette pile. Pbs a resoudre.

bonjour j'ai installé preos sur ma ti 92+ avec la rom 2.09 et je remarque que la fonction carsh intercepted ne marche plus, es-ce normal?

merci

Dans certains cas, le crash ne peut pas être intercepté...
Mais normalement dans la plupart des cas, il peut être récupéré.

oui mais avant quand hibview deconne, il intercept mais maintenant non!

Je ne peux intercepter que si ca declenche une exeption du 68000.
Sinon je ne peux rien y faire.

Ou alors.

Reinstalle preos.

oui mais c'est bizarre qu'avant ca marchais ! et pas apres!

au meme moment !

que veux-tu que je te dises ? Reenvoies preos.