Libérer la mémoire avant "progrun" - Page 1

Voilà mon problème, j'ai un prog qui prend beaucoup de mémoire et il doit pouvoir lancer un jeux. Malheureusement il n'y a pas assez de mémoire pour le programme et le jeu et celui-ci ne marche donc pas.

j'ai entendu que l'on pouvais libérer la mémoire avant de lancer un autre programme.

Quelqu'un serait comment faire?

Merci

La manière la plus simple d'implémenter une telle fonctionnalité serait de faire une architecture lanceur / programme principal comme TICT Explorer (les sources sont disponibles). Après, on peut libérer le handle du programme principal lors de l'exécution d'un autre programme, qui doit être faite par le lanceur. ( Ce n'est pas fait dans TICT Explorer. En revanche, TICT Explorer libère la pile utilisée dans le programme, chose que tu pourras aussi faire tant que tu y es.)

Je bloque là!

Je voudrais faire ceci :
Prog1 lance Prog2
puis Prog1 se décharge de la mémoire!

C'est possible?

Avec ce que je te conseille de faire, ça te donnerait:

lanceur du Prog1 lance Prog1
Prog1 communique au lanceur: lance Prog2
lanceur décharge Prog1 de la mémoire
lanceur lance Prog2
lanceur recharge Prog1 en RAM (à partir de l'archive)
lanceur continue l'exécution de Prog1

Évidemment, pour que ceci marche sans problèmes, il faudra que les données nécessaires pour continuer l'exécution de Prog1 au bon endroit (répertoire courant, position du curseur, ...) soient sauvegardées dans le lanceur.

Autre solution: Tu utilises un fichier de données externe pour tout ce qui est graphismes. Cela te donnerait:
Prog1 décharge les graphismes de la mémoire
Prog1 lance Prog2
Prog1 recharge les graphismes en RAM à partir de l'archive

ou alors les graphismes sont lus directement à partir de l'archive (c'est également possible avec un fichier de données externe).

Ici, tu libères moins de mémoire (le code de Prog1 reste en mémoire, seuls les graphismes sont libérés lors de l'exécution de Prog2), mais c'est beaucoup plus facile à programmer.

Autre solution. Tu attends quelques petites semaines, et un nouveau kernel avec exec_from_scrash.

PpHd: a part faire de la pub sur des prog kernel tu fou quoi???
Puis on en a rien a battre de la nouvelle version de unios... et dans ce cas la je ne pense pas que ce soit intelligent...

En effet moi j'utilise lorsque j'utilise un kernel () une version de teos que j'ai modifier.. et donc tous ceux qui utilise doorsos ou teos.. bein ne pouront pas utiliser son programme...
Si t'as encore des idees aussi bete propose ...

"exec from crash"?

"scratch" s'écrit "scratch", pas "scrash"...


Et je suis d'accord avec TiMad: ce n'est pas bien de se foutre de la compatibilité. Si je faisais de même, j'utiliserais depuis longtemps des dc.w $f800+x pour mes ROM_CALLs.
[edit]Edité par Kevin Kofler le 04-09-2001 à 01:34:34[/edit]

Au fait, si, TICT Explorer libère la mémoire utilisée par le programme principal lors de l'exécution d'un autre programme. (J'avais mal lu les sources apparemment, puisque c'est Thomas Nussbaumer lui-même qui me l'a confirmé.)

En effet, j'avais mal regardé. (Je viens de jeter un autre coup d'oeil sur les sources.)
[edit]Edité par Kevin Kofler le 06-09-2001 à 05:30:28[/edit]

C'est parce qu'il y a encore du monde avec doosos ou teos, qu'il y a des gens pour dire que ca merde.
Mais je bosse sur une nouvelle technologie base sur un kernel+nostub en un seul paquet