Preos 0.58 : Runc est mort ! - Page 1

Ajout de quelques foncitonnalites :

+ Archive auto-extractible sans fichier lanceur externe.
+ Libraries peuvent etre compressees, et etre regrouppees dans un seul fichier.
+ On peut ainsi ajouter les libs dynamiques comme des libs statiques.
kpack doors.9xz graphlib.9xz userlib.9xz filelib.9xz ziplib.9xz doorsp
Creer un fichier compresse doorsp contenant les libs dynamiques necessaires a son fonctionnement. les libs restent accessibles aux programmes externes non-compresses.
+ Tout lib dynamique non-compressee sera prioritaire a une lib compressee.
+ 2 nouvelles RAM-CALLS FindArchive, ExtarctArchive
+ La compression se fait avec shrnklib mais le kernel accepte n'importe quelle librarie dynamique qui exporte une fonction particuliere On pourrait faire une lib dynamqieu supportant la comprression ttpack, et donc utiliser cela pour compresser les programmes et faire des archives auto-extractibles, mais je ne le ferais pas moi-meme.
+ On peut utiliser plusieurs niveaux : je vais faire un utilitaire de compression on-calc base sur ziplib.
Je veux executer le programme : machin
+ machin
-> ziplib
-> ziplib compresse par shrnklib dans doorsp
-> Desarchivage de shrnklib/ relocation
-> extraciton ziplib
-> shrnklib disparait de la ram
-> Extraction du programme par ziplib.
-> Destruction de ziplib
-> Execution du programme
+ Et le mieux : je fais fais tout ca en moins de 300 octets
+ Bref runc est mort.

hmm... mais c'est qu'il devient bien ce preos
runc est mort... je m'en suis jamais servi
ce soir je dl cette release

Pas encore sorti de sa phase de private beta test.
Desole, c'etait pour mettre l'eau a la bouche.

ça parait compliqué dit comme ça
mais ça sonnebien

PpHd> ah merde

squale92 a écrit :
ça parait compliqué dit comme ça
mais ça sonnebien

Heu

Je veux executer le programme : machin
+ machin
-> ziplib
-> ziplib compresse par shrnklib dans doorsp
-> Desarchivage de shrnklib/ relocation
-> extraciton ziplib
-> shrnklib disparait de la ram
-> Extraction du programme par ziplib.
-> Destruction de ziplib -> Execution du programme

=> compliqué



mais la résultat peut rendre bien

C'est totalement transparent et est fait tout seul par le kernel.
C'est au cas ou ziplib est archive dans un pack compresse par shrnklib.
Et on vveut executer un fichier compresse avec ziplib.

OK, OK...

>+ Archive auto-extractible sans fichier lanceur externe.

Et je suppose que ça fait 2 copies en RAM si le fichier est archivé, une compressée et une décompressée. Ou alors comment fais-tu???

Kevin Kofler
a écrit : Et je suppose que ça fait 2 copies en RAM si le fichier est archivé, une compressée et une décompressée. Ou alors comment fais-tu???

Non. Je ne suis pas si bete. Ca efface la twin si le programme detecte qu'il est un twin, et recupere le programme archive originel avant de s'extraire (Si c'est lance de home ou de tictex). Si c'est lance par kernel::exec, pas de pbs non plus.
Bref en RAM, il n'y a que la copie decompressee. S'il ne se trouve pas dans la VAT ou s'il n'est pas une twin, forcement il ne s'effacera pas.

Je sais, tu vas dire que c'est sale. J'ai essaye, ca marche tres bien. Pas de bogues de la part d'ams, ni de tictex (bien qu'il sorte un msg d'erreur a la sortie). Enfin je vais bien tester cela ce soir.

Mais ça a quand-même besoin de la RAM supplémentaire au moment de l'extraction.
Crois-moi, il y a une raison pour laquelle Thomas Nussbaumer utilise des lanceurs externes alors qu'il aime bien les programmes en un morceau.

Non, je te dis. Ca efface la twin puis ca extrait. Pas le contraire. (En fait ca efface pas vraiment a cause d'un pseudo bug de tictex - ou d'ams au choix, mais ca cree une variable de 4 octets). Crois moi si je te dis que ca marche
En nostub vous etes limite a 8 K, ou 24 K, donc il faut quand meme un lanceur.
Pas en kernel

Et la je dois faire les docs, corriger ziplib () et mettre au point le compresseur on-calc avec ziplib

N'en profite pas pour relancer la polémique entre kernel et nostub.

C'est toi qui la relance Moi je parle d'un kernel. C'est tout.

Je dois aussi corriger certains bugs critiques. Immagine cela :

fichier libpack1 compresse avec shrnklib, dedans ziplib.
fichier libpack2 compresse avec ziplib, dedans shrnklib.

La lorsqu'on veut extraire ca va faire un joli plantage (intercepte soit). Je vous laisse imaginer pkoi

En fait, dans cette situation, aucune des deux libs n'est disponible
erf (ca y est rage va me faire un procès pour copie illégale)

PpHd
a écrit : Non, je te dis. Ca efface la twin puis ca extrait.

Donc si j'ai bien compris:
- tu passes le contrôle au kernel
- le kernel recherche le fichier en archive correspondant au twin
- il efface le twin et lit les données compressées à partir de la mémoire archive
Ai-je bien compris là?

Je recode ziplib. J'ai deja vu 4 bugs. Arg
Et c'est chiant a faire

Correction de 4 nouveaux bugs du a mon implementation.
Test pratiquement reussi.
Reste a corriger un pb de lookage des fichiers zippes.

Et on ne peut plus zippe un fichier archive.


Autre chose: mettre au point le systeme de laucncher pour preos.

comment ça ? enfin tu veux faire quoi je veux dire quand tu parles de launcher ?

Top secret

et heu...ton projet archiver, tu le fusionne à preos c'est ça ?

Nan. Il reste independant. Mais il sera complementaire a preos.

#impatient#

Tres impatient !

Ca devrait arriver demain pour les beta-testeurs.
J'ai finis zpack (archiver on-calc).

c pas mal le truc d'un seul fichier qui contient toutes les librairies...
u petit temps de décompression, mais pas génant.

par contre, une chose :
qd on lance un prog qui a besoind e libs sans avoir shrnklib, ça met crash intercepted...
(je sais que, dnas le readme, il est dit qu'il faut shrnklib... mais y'a plein de newbies qui lisent pas le readme)
=> ça serait peut-être mieux de mettre un message comme quoi on n'a pas trouvé shrnklib !

sinon, qd on essaye d'exécuter le STDlib que tu fournis, ça lance aucun prog (normal, vu qu'il n'y a que des libs de dans), mais faudrait peut-être mettre un message, pr le dire à l'utilisateur...
(encore pr les types qui font pas gaffe aux readme)