Bonjour (oui il est 1h16 du mat'
)
Je me permet de faire un rappel sur le principe de developpement de Mantrix ERS car j'ai reçu plusieurs messages du style : Pourquoi des MDI sur les sessions ? Pourquoi un tel niveau de complexité de scripts entre les sessions ?Je répond donc : avez-vous déjà examiner de A à Z l'interieur même d'un OS Unix ou Windows (ou NT ReactOS et son Kernel ?) Si oui alors vous n'avez pas poser ce genre de question.
Si c'est
non voici les explications
:
Pourquoi des MDI comme Sessions sous Mantrix ?- Pour la simple et bonne raison qu'une MDI en temps que session permet de stocker des milliers de fenêtres Child (appelé Enfant en Français) sans augmenter la mémoire avec un taux fixe de +3% toutes les 5 fenêtres ! Il faudrait donc plus de 600 fenêtres ouvertes en même temps pour faire planter un PC avec 4 Go de RAM réel (avec 3Go de libre environ).
Avec une Session qui ne serait pas MDI vous pourriez en ouvrir... 150
De plus les MDI permettent de gérer des processus PID écrite en mémoire OU/ET sauver à court terme sur la mémoire RAM : ce qui produit un empêchement de débordement de mémoire et aussi un débordement de l'écran qui, en natif, ne doit JAMAIS être dépassé sans quoi... BUG (Crash Kernel) !
Si
Mantrix n'avais pas de MDI comme base il serait impossible de le lancer semi-nativement ou nativement un jour (du moins si on réussi à le rendre natif).
Ouai d'accord... Mais ça empêche de faire plein de chose cool !- Oui en effet c'est un sacrifice (en VB.NET du moins) à faire ! En effet avec une MDi impossible de créer des fenêtres stylés avec l'effet de transparence ou d'animation 2D/3D des fenêtres. Il est également impossible d'importer des Classes propres à WIndows qui aurait pus animer les menus ou animées les fenêtres d'inter-session (rappel ; inter-session signifie le court laps de temps entre 2 fenêtres, genre LoginScreen et Session ou Session et ShutdownScreen, l'inter-session est bourrée de calcul ESSENTIEL qui détermine le comportement complet du système et de son utilisateur qui se connecterais). Alors oui en VB.NET une MDI empêche de faire des animations "stylés" mais... est ce vraiment utile ? On en vois partout, c'est trop classique et sa bouffe de la mémoire et en plus ça prend du temps !! Oui oui... Une fenêtre qui se ferme en fondu prend une demi-seconde. Une fenêtre SANS animation (tel que
Mantrix) ne prend quoi...0,1 à 0,2 sec ?
Dans un OS, surtout si on veux qu'il soit performant rapide simple et ORIGINAL, on préferera donc la simplicité à la qualité (en tout cas sur les animations !). Et contrairement à ce que l'on pense une MDI permet très bien de gérer des vidéos, des animations Flash ou même... des executables intégrés externes DANS la MDI ! Donc vous pourriez même, grâce à la MDI, lancer nativement un jeu 3D genre "GTA" (désolé pour la pub x) ) en plein écran mais dépendant de la MDI au niveau de son processus ce qui produira un anti-débordement automatique car lié à la MDI
! Moui moui c'est pas pour rien que tout les OS du monde utilise les MDI
Et merci à M. Microsoft d'avoir donné la possibilité de faire ça au dev de tout langage :p
Les icones bureautique dans Mantrix sont pas très beau voir laid...- Encore une fois on ne peut pas tout faire avec une MDI : on ne peut pas lister une ListView en arrière plan avec fond d'écran qui listerai en icone et texte les fichiers/dossiers qui serait placés dans un dossier perso dans
Mantrix... Sans MDI c'est possible mais là pareil : impossible de lié les liens spéciaux d'un OS et son Kernel avec reconnaissance des fichiers si la session n'est pas une MDI.
Donc oui nos icones sont recréer de zéro avec des idées piochés partout mais ça marche :p le seul soucis c'est la transparence
Mais rappelez vous que le but de Mantrix c'est d'être un OS ORIGINAL (oui y'en a peut >< !) et du coups le bannissement volontaire des icones (remplacer par l'IrisBar et la RacFiles à gauche dans une Session) est donc un moyen de se démarquer des autres OS ! Mais chacun sont choix : si vous préférez les icones pas de soucis : basculez sur l'interface icones et temps pis pour votre transparence
C'est plus laids c'est sûr mais ça fonctionne et on peut liés nos icones à des liens symboliques externes et même en créer de zéro à l'infini en générant des icones mini-Child sans augmenter la mémoire
! Et ça c'est une nouveauté (que vous découvrirez plus tard
c'est pas prévue dans la 1.2.1.685 pour l'instant mais on boss déjà dessus).
Le développement est long...... pfff.....- Mesdames messieurs voyons ! Un OS ne se résume pas à un LoginScreen animé, un Boot Screen et une Session ! Derrière tout les paramètres, logiciels, etc ce cache des milliers d'heures de travails ! Avec mon équipe cela fait en 2 ans plus de 4000 heures de développements... Il faut que vous sachiez que derrière le moindre clique, etc ce cache des centaines de milliers de lignes de codes simples ou complexes allant du simple importation de paramètres perso jusqu'à la prise en compte de scripts complexes liés au registre, au curseur, à la mémoire ou encore au système tout entier !
Je veux pas en effrayer certains mais... regardez ce bout de code :
- Code:
ASSERT (MmUnusedSegmentList.Flink == &MmUnusedSegmentList);
MiZeroingDisabled = TRUE;
if (MmUnloadedDrivers != NULL) {
Entry = &MmUnloadedDrivers[0];
for (i = 0; i < MI_UNLOADED_DRIVERS; i += 1) {
if (Entry->Name.Buffer != NULL) {
RtlFreeUnicodeString (&Entry->Name);
}
Entry += 1;
}
ExFreePool (MmUnloadedDrivers);
}
NextEntry = MmLoadedUserImageList.Flink;
while (NextEntry != &MmLoadedUserImageList) {
DataTableEntry = CONTAINING_RECORD (NextEntry,
KLDR_DATA_TABLE_ENTRY,
InLoadOrderLinks);
NextEntry = NextEntry->Flink;
ExFreePool ((PVOID)DataTableEntry);
}
NextEntry = PsLoadedModuleList.Flink;
while (NextEntry != &PsLoadedModuleList) {
DataTableEntry = CONTAINING_RECORD (NextEntry,
KLDR_DATA_TABLE_ENTRY,
InLoadOrderLinks);
ImportList = (PLOAD_IMPORTS)DataTableEntry->LoadedImports;
if ((ImportList != (PVOID)LOADED_AT_BOOT) &&
(ImportList != (PVOID)NO_IMPORTS_USED) &&
(!SINGLE_ENTRY(ImportList))) {
ExFreePool (ImportList);
}
if (DataTableEntry->FullDllName.Buffer != NULL) {
ASSERT (DataTableEntry->FullDllName.Buffer == DataTableEntry->BaseDllName.Buffer);
}
NextEntry = NextEntry->Flink;
ExFreePool ((PVOID)DataTableEntry);
}
ExFreePool (MmPhysicalMemoryBlock);
ExFreePool (MiPfnBitMap.Buffer);
if (MmSession.SystemSpaceViewTable != NULL) {
ExFreePool (MmSession.SystemSpaceViewTable);
}
if (MmSession.SystemSpaceBitMap != NULL) {
ExFreePool (MmSession.SystemSpaceBitMap);
}
for (i = 0; i < MmNumberOfPagingFiles; i += 1) {
ASSERT (MmPagingFile[i]->PageFileName.Buffer == NULL);
for (j = 0; j < MM_PAGING_FILE_MDLS; j += 1) {
ExFreePool (MmPagingFile[i]->Entry[j]);
}
ExFreePool (MmPagingFile[i]->Bitmap);
ExFreePool (MmPagingFile[i]);
}
ASSERT (MmNumberOfMappedMdlsInUse == 0);
i = 0;
while (IsListEmpty (&MmMappedFileHeader.ListHead) != 0) {
ModWriterEntry = (PMMMOD_WRITER_MDL_ENTRY)RemoveHeadList (
&MmMappedFileHeader.ListHead);
ExFreePool (ModWriterEntry);
i += 1;
}
ASSERT (i == MmNumberOfMappedMdls);
ExFreePool (MmPagedPoolInfo.PagedPoolAllocationMap);
ExFreePool (MmPagedPoolInfo.EndOfPagedPoolBitmap);
if (VerifierLargePagedPoolMap != NULL) {
ExFreePool (VerifierLargePagedPoolMap);
}
while (ExQueryDepthSList (&MmInPageSupportSListHead) != 0) {
SingleListEntry = InterlockedPopEntrySList (&MmInPageSupportSListHead);
if (SingleListEntry != NULL) {
Support = CONTAINING_RECORD (SingleListEntry,
MMINPAGE_SUPPORT,
ListEntry);
ASSERT (Support->u1.e1.PrefetchMdlHighBits == 0);
ExFreePool (Support);
}
}
while (ExQueryDepthSList (&MmEventCountSListHead) != 0) {
EventSupport = (PEVENT_COUNTER) InterlockedPopEntrySList (&MmEventCountSListHead);
if (EventSupport != NULL) {
ExFreePool (EventSupport);
}
}
NextEntry = MiVerifierDriverAddedThunkListHead.Flink;
if (NextEntry != NULL) {
while (NextEntry != &MiVerifierDriverAddedThunkListHead) {
ThunkTableBase = CONTAINING_RECORD (NextEntry,
DRIVER_SPECIFIED_VERIFIER_THUNKS,
ListEntry );
NextEntry = NextEntry->Flink;
ExFreePool (ThunkTableBase);
}
}
NextEntry = MiSuspectDriverList.Flink;
while (NextEntry != &MiSuspectDriverList) {
Verifier = CONTAINING_RECORD(NextEntry,
MI_VERIFIER_DRIVER_ENTRY,
Links);
NextEntry = NextEntry->Flink;
ExFreePool (Verifier);
}
}
C'est un simple bout de code qui relie NT Kernel à MandrevCore pour ordonner l'arrêt de l'ordinateur en semi-natif ou natif en sauvant les paramètres actuels sur une bibliothèque écrite sur le HDD qui sera relue à chaque démarrage. Ce code en C++ natif on y passe déjà beaucoup de temps et :
1 - C'est très chaud je vais être honnête
2 - C'est long...OMG que c'est long !
3 - Ca demande du temps et de la patience !
Alors je veux bien comprendre que ce soit long... et que pour l'instant
Mantrix offre peut de choix à un utilisateur lambda mais il fait déjà plus de 30.000 lignes de codes (juste pour l'IUG) et grâce au VB.NET sachez qu'on gagne notre temps ! Développer tout ce qu'on a déjà fait en C++ nous aurais pris 20000 heures et non 4000 heures et on serait déjà dans les millions de lignes de codes ! Et sous SZ ça va encore plus vite ! Pour arriver à notre stade il faudrait sous Visual Studio environ 1,5 fois le temps de dev (on serait à 5000 heures de dev au lieu de 4000 heures xD).
C'est simple avec SZ ça va déjà vite
alors faut juste laisser le temps de le rendre un minimum stable avant de bosser vraiment sur les applis qu'on pourrais mettre
Et puis la fin de la Beta approche à grand pas ! Peut être fin 2014 ou mi-2015
!Alors bon
la patience c'est toujours ce qui a de mieux
!
Je vous remercie de votre attention et j’espère (y'en a plusieurs) que certains comprendront l'effort qu'on fait sachant que nous n'avons AUCUNES rémunération, qu'on payent certains logiciels de notre poche et que malgré tout ça
Mantrix ERS à sa sortie "finale" sera GRATUIT à vie...
Que demandez de mieux
Donc merci juste de faire attention à certains de vos commentaires
Ce serait gentil de ne pas écraser
Mantrix sous des jet de pierre
Sur ceux après ce grand roman je vous souhaite une bonne journée (oui il est 1h49 maintenant
)
A bientôt !