1

Vu que PpHd ne compte plus l'implémenter dans PreOS et que ca me serait utile dans TIM pour éviter la multiplication des fichiers externes de petite taille, en particulier pour la configuration des plug-ins, j'ai l'honneur de vous présenter mon nouveau projet qui je l'espère quittera vite cette section pour ce faire incendier par notre cher Kevin Kofler: adblib

Il s'agit d'une lib kernel (je ferai peut-être une version nostub si ca interesse quelqu'un et que kévin me prend trop la tête) qui permet la gestion d'une base de donnée archivée(style base de registre windows). Cela permetrai d'eviter de multipliers les fichier externes qui ne contiennent presque rien et peut-être permettre de mettre des données en commun entre applications. Le but est de l'integrer en standard a stdlib si PpHd le veut bien de manière a ce qu'un maximum de programmes puissent en profiter.

je n'ai pas encore établi les spécifications fixes de ce format car je voulais avoir vos suggestions avant de me lancer dans le problème. Je vous donnerai bientôt mes débuts d'idée d'implémentation. il faut que je fasse un peu de tri dans mon cerveau avant.
avatar

2

ca te dis pas de développer ext_SYM plutot ? pke apparement ca reviendrait presque au même, nan ?

3

pas vraiment vu qe ext sym c'est un système de sous répertoire avec protection, moi le but c'est de concentrer tous le fichier de petite taille des différentes applications dans un seul fichier en commun
avatar

4

Bah, c'est come ca que serait un sous-repertoire sous ext_SYM ... enfin, fragmenter en plusieurs fichiers invisibles suivant la taille totale

5

EXTSYM utilise plein de données qui me sont inutiles et consomment de la place. Ma lib doit fournir une manière simple de centraliser les donnée dans un seul fichier alors que EXT_SYM doit permettre de créer pulsieur sous dossiers. Selon l'implémentation que je compte faire il y a déja 18 octets de consommés par entrée. et je ne me demande si je ne vais pas le réduire pour revenir à 10 octets .
avatar

6

hum ...

7

Hum ext_Sym bouffz donc un handle par fichier, mais la methode a uther qu'un seul si g bien compris c sa ?
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

8

mon inplémentation est ultra simpliste pour gagner en taille et en vitesse:
Toutes les clé sont stockées a la suitedans le fichier selon le format suivant:
-taille(2octets)
-nom du propiétaire de la clé(8octets)
-nom de la clé(8octets)
-données( taille octets)
-eventuellement un octet pour alligner si la taille est impaire.

Ext_SYM est un sorte de SYM_ENTRY évolué pour gérér la protection de fichier
avatar

9

oué et le ssous-rep (en utilisant un handle complet par sous-dossier)