Discussion :

[ff76620]

bonjour j'aimerais juste savoir quand pourra t on lancer une fichier .exe qui a une interface graphique Windows comme rocketdock ou autre

[LeoBeutel]

Bonjour.

Je crois bien que cela n'arrivera surement pas, a moins que Sébastien veuille faire un dérivé de Windows. Le kernel de Windows (Win NT il me semble) est pas mal complexe, donc pouvoir afficher un .exe Windows Graphique serait plus que très compliqué, étant donné que CPCDOS ne possède pas encore tout les "modules" ou plutôt fonctionnalité de Windows.

D'un côté, ça serait un avantage oui, mais d'un autre non car CPCDOS doit pour moi être indépendant de tout autre kernel et doit avoir son propre système de fichier et d’exécution. A la base, Cpcdos est crée pour concevoir des OS, pas pour les copiés.

[cpcdos]

Salut, Angels74 a tout compris

Il nous faudrait un certain temps pour mettre en place la lecture d'un stub MZ format PE ou NE, récupérer la data, les ressources, ça peut se faire mais les dépendances sont fourbes!
Un exécutable GUI du type "winform" du kernel NT utilise la bibliothèque de liaison dynamique de GDI32, qui lui aura besoin celui de Kernel32, qui lui aura besoin des routines dans ntoskrnl pour blitter(); sur le pointeur vidéo.. et ça en finit pas! Faut aussi imaginer si l'application est sous framework, alors là c'est le parcours du combattant! Il aurait tellement besoins de beaucoup d'indépendances Microsoft que l'image du Cpcdos (Créer Pour Concevoir Des OS) qui est censé être autonome va être détruite...

La seule chose que je peux te dire, c'est que Cpcdos va être ouvert au développement C/C++ en LLVM ou directement natif dans le noyau. Si une personne a beaucoup de patience pour réécrire un module de lecture d'entête MZ PE/NE + relier les fonctions "windows" que l'exe a besoin, à celui de Cpcdos, ça pourrai être reparlé

Cordialement.

[ff76620]

merci de vos reponse

Angels74 tu dis que le kernel cpcdos doit être dépendant de tout kernel je suis d'accord avec toi la dessus donc j'ai plus qu'a essayer de crée un logiciel qui fera comme rocket dock lol en cpc bien sure mais faudra quand même que le kernel et l'os puisse lancer des exécutable tel que pain vlc et autre logiciels qui ne sont compatible qu'avec windows

[cpcdos]

En CpcdosC+ v4 (Celle de 2017) pourrai être l'idéale pour faire un rocketdocs animé + zoom etc.. En CpcdosC+ v3 (Celle que tu as) les animations risquerons d'être ... caca

Les autres logiciels pourront être développés par la communauté! Des personnes peuvent coder des plugins/modules en C++ sur Cpcdos afin de les utiliser en CpcdosC+ par exemple!

Pour un lecteur vidéo, par exemple nous aurions besoin un décodeur MPEG2. Et ce décodeur peut être écrit en C++ sur Cpcdos. Et par suite, il sera possible d'utiliser ce décodeur en CpcdosC+ dans une fenêtre graphique par exemple. Un peut le même principe de créer des fichier DLL. Ce dernier va apporter des fonctionnalités en plus qui ne sont pas inclus dans cpcdos, mais crée par la communauté

[ff76620]

j'avoue que ton kernel me plaie beaucoup il a beaucoup de potentiel mais pourquoi avoir choisis DOS pour le faire ??

[cpcdos]

Merci

Pourquoi DOS (FreeDos), je l'ai beaucoup expliqué, c'est juste une plateforme de boot/drivers temporaire. Il me sert seulement pour booter, gérer clavier, souris, écran FAT32 et les drivers réseaux NDIS2.0. Seulement ceci sont nécessaire. Je prévois la séparation de ce DOS d'ici plusieurs années. Ceci ne va rien changer en terme de performances, mais seulement enlever le terme du "basé temporairement sur FreeDos". C'est simplement pour commencer le projet.

Et un petit clic d’œil sur le système ReactOS qui est bon exemple me concernant. Leurs premières version alpha/prototype sont aussi basé sous DOS simplement pour le boot et quelques autres fonctionnalités et fur et a mesure du développement, ils ont pu écrire leur propre boot implémenté dans leur propre kernel. C'est un exemple flagrant et explicitement ressemblant au projet de Cpcdos. Donc DOS est là simplement pour lancer le projet et après Byebye

[ff76620]

oui j'ai regarder reactOS mais quand je regarde la config de l'iso c'est du windows modifier je m'explique le noyau c'est ntoskrnl et ntkrlmpa au lancement déjà tu vois plus je regarde l'os plus je me dis que c'est un cd windows bidouiller^^ (comme pour personnaliser son windows on modifie le cd et ça installe avec la modif tu vois)

[ff76620]

peux tu me dire comment modifier les drivers car avec le fichier krn_drv .cpc ca ne fais rien

[cpcdos]

Et bien non justement le but du projet ReactOS c'est de réécrire un Windows from scrach, c'est à dire de refaire le travaille de Microsoft mais en open source avec l'aide de la communauté internationale et non privé. Et après les noms des fichiers c'est pas dramatique, au pire ça restera dans les "normes" pour la compatibilité sur les logiciels exécutés.

Si Microsoft avaient découvert ne serais qu'un morceau de 10 lignes de codes protégé (Non publique) je pense qu'il seront déjà en procès pour un genre de vol et diffusion en publique. Et moi même je te garanti qu'il s’agit du code produit par cette communauté (Professeurs, amateurs/passionnés, étudiants etc..)

Pour les drivers,
Tu peux regarder dans le fichier FDCONFIG.SYS

[ff76620]

ils ont une bonne idée la dessus bluffant moi je suis en train de me crée mon os ca va me prendre du temp mdr

[maeiky]

La seule chose que je peux te dire, c'est que Cpcdos va être ouvert au développement C/C++ en LLVM ou directement natif dans le noyau. Si une personne a beaucoup de patience pour réécrire un module de lecture d'entête MZ PE/NE + relier les fonctions "windows" que l'exe a besoin, à celui de Cpcdos, ça pourrai être reparlé

Après avoir implémenté LLVM et le JIT, ça ne me semble pas impossible de faire un Loader d’exécutable. Après réflexion le JIT est un peu lourd, c'est à dire que la conversions et optimisations du IR au code machine prend du temps et beaucoup de Ram.
La fonctionnalité reste très utile, que ce soit pour compiler directement sous CpcDos ou ou faire du JIT partiel. La meilleurs application serait de faire un processus d’installation. C'est à dire, en exemple, à la première utilisation un programme en IR s'installe, il se convertie en code machine de façon optimal, selon le système. Ensuite, on ne lit que le code machine.

Le code machine, étant un .exe sous Windows, mais on est pas plus avancé, comment lire le code machine?

En réalité la différence est subtile, lire le JIT ou un exe

J'ai donc commencé un petit loader exe, compiler avec le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
extern "C" void  test(){
    printf("\n\n -------- YESSSSSSSSSSS --------- - \n\n");
}

Je suis parvenue à l’exécuter à même CpcDos :


Comme la mentionner Angels74 & Seb, les fonctionnalités reste très limité et il reste beaucoup de travail pour lire n'importe quel .exe, et ceci dépend fortement de leur dépendances.
Néanmoins n'importe quel application fait avec le moteur graphique que je développe, GZE, pourra fonctionner sous CpcDos et bien d'autres plateformes

[ff76620]

vraiment intéressant ton lanceur

[New World]

Si tu pouvais incorporer le Visual Basic dans Cpcdos ça serait plus simple à mon avis

[GHOSTnew]

Si tu pouvais incorporer le Visual Basic dans Cpcdos ça serait plus simple à mon avis

euh t'es sérieux ?