Win3x.Org

Du QB même compiler sera toujours plus lent que du C, le compilateur Qb n'as pas été mis a jour depuis belle lurette contrairement au compilateur GNU qui est mis a jour tout les jour, aujourd'hui il vaut presque mieu programmer en C quand asm pour un programme rapide car le compilateur C ecrit un code asm presque plus propre que si on l'avait fait dés le début ( tout depend de la qualiter du programmeur asm )

Le mieu serai d'écrire un programme qui: traduit le script en C puis le compile. L'operation est longue sur un vieu PC mais le resultat sera trés rapide.

ou:

Un programme qui prend le script et en réecrit un en bat et le lance, plus rapide a lancer mais moin rapide a l'éxecution.

Dans les deux cas on sauvegarde le resultat comme ca la prochaine fois tout est pret et cela devient trés rapide a l'execution et au lancement.

Voila je procederai comme ca. Enfin je procederai pas du tout vu que ce projet n'as pas beaucoup de sens. Les script *nix... ne servirai pas, vu que meme si les commandes sont les mêmes le resultat ne servira pas du tout, un scipt d'installation de driver ou de connection n'as pas ca place dans un environemt ms-dos.

De meme si la base c'est ms-dos ( ou tout autre dos ) vaut mieu garder les commandes de ce systeme qui sont compatible avec les noyau car les commandes que vous aurez réecrite meme si vous avez l'impression qu'elle font le même resultat elle ne procede pas de la même façon est peuve causer des bug bien difficile a trouver.

Citation :

mieu garder les commandes de ce systeme qui sont compatible avec les noyau car les commandes que vous aurez réecrite meme si vous avez l'impression qu'elle font le même resultat elle ne procede pas de la même façon est peuve causer des bug bien difficile a trouver.

En fait perso, je me base plus sur Unix que sur dos. La gestion des multitaches et multiutilisateur me branche bien.

Mais finalement, mon projet n'a rien d'un clone. C'est ni une copie d'unix, ni une copie de dos. C'est un hybride !

le noyau utiliser est le noyau originale de dos ou est-ce une création ???

Pour l'instant on utilise
-Le noyau ms-dos 6 qui a fait ses preuves, dans l'attente de trouver mieux (un truc en 16 bits gérant le multitache.. pas gagné)
-La plupart des composants du système sont en QB: l'interpréteur de scripts, la ligne de commande ...
-Certains sont en C compilés avec un compilateur borland: le gestionnaire de bases de données par exemple.

Tout ceci est très modulaire et facilement modifiable. On peut utiliser n'importe quel langage tant qu'il est possible de lancer des fichiers exe et de récupérer la sortie...

PulkoMandy a écrit :

Pour l'instant on utilise
-Le noyau ms-dos 6 qui a fait ses preuves, dans l'attente de trouver mieux (un truc en 16 bits gérant le multitache.. pas gagné)
-La plupart des composants du système sont en QB: l'interpréteur de scripts, la ligne de commande ...
-Certains sont en C compilés avec un compilateur borland: le gestionnaire de bases de données par exemple.

Tout ceci est très modulaire et facilement modifiable. On peut utiliser n'importe quel langage tant qu'il est possible de lancer des fichiers exe et de récupérer la sortie...

Noyau 16 bits multitâche... ELKS?

Ca va pas coller si il reste sur QB, j'ai pas explorer trop le site mais apparament c'est baser sur Linux.

Ouais ELKS est un linux allégé... moi ça me plarait bien.
Y'a un compilo basic qui fonctionne dessus pour maxoul ?

Je pense que rien ne marche dessus pour le moment à par un shell minimal et des outils... Va falloir programmer

Si vous programmez votre interpréteur en QBASIC, alors rien ne vous empêche de le reprogrammer en C sachant que les composants au dessus ne verront rien

Ce sera toujours plus interessant dans le sens ou vous pourez evoluez dans le sens que vous voulez, en plus vous avez les sources vous pourez en faire ce que vous voulez pour avoir votre noyau donc enfaite votre systeme bien a vous.

edit: Et quitte a faire dans le nouveau, autant lancer 2 projet distinct, un qui consite a programmer un noyau ( en asm et en C ) et un deuxieme a programmer l'interface graphique. Les deux ce completes pour ainsi former un OS. Bien que légerement plus dur ( quoique c'est surtout different y'a bcp de tuto sur le net ) Ca risque d'interesser plus de monde parce qu'une interface graphique pour ms-dos y'a Windows 3.11 qui est excellent.

Ben le projet est déjà séparé en plusieurs petites choses.
L'interface graphique, je pensais à GEM pour les config les plus légère, il est open source mais il faudrait pouvoir afficher quelque chose avec des pixels sous elks, il faudrait une svgalib ou quelque chose comme ça.

Après, il reste un seul problème c'est qu'on perd la compatibilité dos ...