Win3x.Org

Qu'à cela ne tienne. Je donne une version "angulaire'



Je n'ai mis que le menu, mais j'estime que c'est sufisant, en revanche, je pense que pour une version améliorée grafikement de ludos, il y a moyen de garder le cercle central, non ?

Moi j'aime bien ce style...c'ets très sympa le problème c'est qu'il va falloir manipuler tout le bazar vga en mode graphique et çà ben je m'y connais pas trop.


A ce sujet: Pulkomandy, j'ai trouvé un moyen de vérifier si la carte est une VGA et non CGA ou EGA.

Mmh...
bon j'essaierai de dessiner une interface un peu sympa. sachant que les cercles ce n'est pas non plus ce qu'il y a de plus simple à tracer (calculer les cosinus et tout ça ...).

Donc, dans l'idée:
-Dans un coin (bas gauche), un bouton menu avec les applications. Ce menu se dépliera à l'envers, c'est à dire que lorsqu'on ouvrira un sous menu, le menu se décalera vers la droite et le sous menu restera toujours contre le bord de l'écran: sélections dans ce sous menu facile.
-En haut de l'écran, barre de menus ou d'outils faciles à atteindre, même système: un sous menu s'ouvre au-dessus de la barre qui se déplace vers le bas.
On peut choisir un seul de ces deux systèmes (menu sur une ligne, ou via un bouton et un popup, ou mélanger les deux).

Reste le coin en bas à droite qui ne sert à rien.

Tous les éléments non cliquables (horloge, statisitiques système, infos sur l'utilisateur, la ram...) peuvent rester au cantre. Pour l'instant le système n'est pas multitache, donc une appli devra avoir de quoi dessiner ces menus, et le système ne gérera rien d'autre une fois l'appli lancée.

Pour ce qui est de la carte vidéo, tu peux nous faire un petit prog SCANVDO qui dira quelle est la carte installée. Ensuite on avisera selon les capacités de chaque. 640x480x16/4096 en VGA, 640x480x16/16 en EGA, et 320x200x4/4 en CGA. Ça fait au moins deux interfaces différentes. (VGA et EGA sont identiques mais VGA permet de changer la palette de 16 couleurs ce qui est plutôt sympa)

Ou encore "bibilothèque", comme IBM les appelle sur ses AS/400 et iSeries...

...je crois que le mieux est d'utiliser le terme auquel tout le monde est habitué... "Dossier".

Il pourrait être intéressant de stocker l'arborescence des fichiers dans une base de données. C'est un moyen original de contourner les limites du fat16

PulkoMandy a écrit :

Il pourrait être intéressant de stocker l'arborescence des fichiers dans une base de données. C'est un moyen original de contourner les limites du fat16

C'est une excellente idée, qui est à la base du futur système de fichier de Windows et aussi d'autres.

Cependant si la base de donnée est relationelle, ça va être dur de représenter des données hiérarchiques (c'est un problème vieux comme l'informatique et sans "bonne" solution, XML n'est pas la solution à ce problème caar XML ne sait faire que du hiérarchique. XML n'est qu'un retour aux vieilles bases hiérarchiques d'avant le relationnel). Vous pouvez utiliser pour ça des bases de données sémantiques (à base de RDF) comme http://fr.wikipedia.org/wiki/SPARQL , mais là on est à la pointe de la recherche.

PulkoMandy a écrit :

Il pourrait être intéressant de stocker l'arborescence des fichiers dans une base de données. C'est un moyen original de contourner les limites du fat16

Autre propal, j'ai commencé un driver Reactos Fat+ (FAT32 sans limitation à 2G pour la taille des fichiers).

Je peux le fournir à qui voudra le convertir en driver Freedos/Ludos. Il a un gros inconvénient l'heure de création du fichier n'est plus enregistrée ni la date de dernier accès en lecture.

On peut penser que l'heure de création et l'heure de dernière modif sont similaires et que la date de dernier accès en lecture n'a aucune importance.

Mon idée c'était de continuer à le modifier dans le sens du système de fichier BSD (ffs) pour répartir la FAT sur le disque de façon à:
- Améliorer les temps d'accès
- Diminuer la taille mémoire nécessaire (pour des disques modernes il faut des dizaines de méga-octets de RAM rien que pour la FAT ou l'équivalent en inodes)
Mais on peut l'utiliser comme ça

/* version classique FAT32 */
struct _FATDirEntry
{
unsigned char Filename[8], Ext[3];
unsigned char Attrib;
unsigned char lCase;
unsigned char CreationTimeMs;
unsigned short CreationTime,CreationDate,AccessDate;
unsigned short FirstClusterHigh; // higher
unsigned short UpdateTime; //time create/update
unsigned short UpdateDate; //date create/update
unsigned short FirstCluster;
unsigned long FileSize;
} __attribute__((packed));

/* version FAT+ */
struct _FATDirEntry
{
unsigned char Filename[8], Ext[3];
unsigned char Attrib;
unsigned char lCase;
unsigned char CreationTimeMs;
unsigned short CreationDate;
unsigned short FirstClusterHigh; // higher
unsigned short UpdateTime; //time create/update
unsigned short UpdateDate; //date create/update
unsigned short FirstCluster;
unsigned long long FileSize;
} __attribute__((packed));

Le problème c'est de gérer la compatibilité avec dos ...

PulkoMandy a écrit :

Le problème c'est de gérer la compatibilité avec dos ...

Ben t'es foutu de toute façon si tu fais référence à ton poste + haut.

PulkoMandy a écrit :

Il pourrait être intéressant de stocker l'arborescence des fichiers dans une base de données. C'est un moyen original de contourner les limites du fat16

Tu pourras mettre des noms longs, tu auras un mécanisme d'autorisation sophistiqué à souhait, il n'y aura plus de fragmentation, mais tu ne dépassera pas la limite maxi de FAT16 pour la taille du fichier de la BD soit 2Go dans le meilleur des cas.

Les performances d'une base de donnée sur FAT16 vont être risibles, car avec le système des FAT il faut parcourir toute une entrée de FAT pour savoir où crèche un cluster (en général entre 1 et 20 clusters) et là il y aura une seule entrée de FAT qui contiendra des dizaines, des centaines de milliers voire des millions de clusters, suivant la taille du disque!

De plus il te faudra créer un driver spécifique qui va convertir les ordres destinés au système de fichier en ordres "base de donnée".


----
Publié: dimanche 14 octobre 2007 22:52

Une façon compatible d'étendre FAT32 en taille maximale c'est d'utiliser l'entête suivant en faisant de l'arithmétique 48 bits dans le code du driver. Ca impose de chercher tous les endroits où sont référencés "FileSize" et de tenir compte du champ "higher_part_of_file_size" pour la lecture, la mise à jour de la taille et toute arithmétique sur la taille du fichier.
C'est fastidieux mais pas compliqué et compatible avec FAT32

struct _FATDirEntry
{
unsigned char Filename[8], Ext[3];
unsigned char Attrib;
unsigned char lCase;
unsigned char CreationTimeMs;
unsigned short CreationTime,CreationDate ;
unsigned short higher_part_of_file_size ;
unsigned short FirstClusterHigh; // higher
unsigned short UpdateTime; //time create/update
unsigned short UpdateDate; //date create/update
unsigned short FirstCluster;
unsigned long FileSize;
} __attribute__((packed));

Salut,

J'aimerais savoir où en était ce projet.
J'ai essayé de le téléchargé sur internet mais j'ai rien trouvé de même pour les sources.
Donc voilà si quelqu'un pouvait me répondre.

En vous remerciant.

Bonjour,
les sources sont hébergées sur un serveur subversion. Toutes les infos sont sur la page projet sur google: http://code.google.com/p/ludos
Actuellement, je suis étudiant en DUT informatique, j'ai d'autres truc à faire que d'avancer sur ludos
En plus, j'hésite à passer sur le compilateur Open Watcom, car celui de Borland que l'on utilise actuellement n'est plus développé ...
Le problème c'est que ça va en faire raler certains, nottament au niveau des programmes écrits en assembleur.

Enfin, tout ceci reste à étudier... Si quelqu'un est motivé et a plus de temps que moi pour s'occuper du projet, je veux bien passer la main, car c'est dommage que ce projet n'avance plus...