IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langages de programmation Discussion :

Il n’y a rien de mieux que le langage de programmation C pour le développement de systèmes d’exploitation


Sujet :

Langages de programmation

  1. #21
    Responsable Systèmes


    Homme Profil pro
    Gestion de parcs informatique
    Inscrit en
    Août 2011
    Messages
    17 822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Gestion de parcs informatique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Août 2011
    Messages : 17 822
    Points : 44 114
    Points
    44 114
    Par défaut
    Je voulais juste souligner que prendre un langage plus récent que le C, et sensé moins sensibles aux failles pour faire un OS ne donnera pas forcément un OS avec moins de failles, et ce ne sera donc pas mieux. Ce n'est que mon humble avis, mais aussi celui de Linus, qui je pense sait de quoi il parle. Et pour reprendre les 25 584 633 lignes de codes (estimation trouvé sur un site) dans un autre langage, il faut vraiment que ça en vaille la peine.

    Le fait que Rust dont on parle depuis le début du post possède des failles démontre qu'il n'est pas forcément plus stable que le C. Il peut être moins sensibles aux bugs, mais cela reste à prouver, en tout cas il y est sensible vu qu'on en a découvert. Le C a quasiment 50 ans, il a prouvé ce qu'il valait, en bien comme en mal. Rust a 13 ans donc beaucoup plus jeune, il n'a pas autant fait ses preuves mais peut en contrepartie mûrir aussi.


    Les langages plus récents et plus performants le sont parce qu'ils tournent sur un OS mais sans OS, directement face au processeur, les langages aussi récent soient ils se retrouvent littéralement à poils comme le langage C.

    Je ne sais pas si vous voyez ce que je veux dire ?
    Il s'agit de la question du bootstrap.

    Un compilateur d'un langage digne de ce nom doit être capable de se compiler lui-même.
    Mais pour se compiler, il doit y avoir un compilateur.

    Quand on crée un nouveau langage, on va d'abord créer un compilateur en C par exemple,mais ça peut être un autre langage tant qu'il est capable d'effectuer toutes les phases effectuées par un compilateur (analyse lexicale, syntaxique, sémantique, génération de code machine, édition de liens), les 1er compilateurs étaient écrits en assembleur. GCC et LLVM peuvent compiler différents langages et vers plusieurs cibles. LLVM est d'ailleurs adapté pour créer facilement un nouveau langage.

  2. #22
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par Vincent PETIT Voir le message
    Je ne sais pas si vous voyez ce que je veux dire ?
    J'ai l'impression que tu considères que pour éviter les problèmes cités, il faut forcément du contrôle au runtime, or ce n'est pas le cas, c'est même précisément le principe en Rust (et en fait dans un certain nombre d'autres langages notamment les langages formels). Le système de types te donne des garanties sur le comportement de ton programme et c'est lui t'empêche, lors du typage, d'écrire du code qui risque de faire des dégâts.

    Citation Envoyé par chrtophe Voir le message
    (1) Le fait que Rust dont on parle depuis le début du post possède des failles démontre qu'il n'est pas forcément plus stable que le C. Il peut être moins sensibles aux bugs, (2) mais cela reste à prouver, en tout cas il y est sensible vu qu'on en a découvert. (3) Le C a quasiment 50 ans, il a prouvé ce qu'il valait, en bien comme en mal.
    (1) Non, ça montre qu'on a une base de confiance dans tout langage.

    (2) Ça tombe bien, il y a déjà de telles preuves à propos du système de types : https://plv.mpi-sws.org/rustbelt/popl18/paper.pdf . La question c'est pas tant de savoir si le langage est parfait : il ne l'est pas. La question c'est "c'est quoi les chances que j'écrive un bug qui ne sera pas détecté lors d'une analyse/compilation et qui sera accessible pour faire de gros dégâts ?". C'est très facile en C, compliqué en Rust.

    (3) La vieillesse et l'adoption d'un système n'est pas un argument pour parler de ce qu'il apporte en terme de sécurité. Surtout quand on voit le surcoût imposé pour la sécurité d'un soft écrit en C.

    Citation Envoyé par chrtophe Voir le message
    Ce n'est que mon humble avis, mais aussi celui de Linus, qui je pense sait de quoi il parle. Et pour reprendre les 25 584 633 lignes de codes (estimation trouvé sur un site) dans un autre langage, il faut vraiment que ça en vaille la peine.
    Pour reprendre un autre type vaguement compétent dans le monde de l'informatique : "Il y a deux façons de faire la conception d'un logiciel. Une façon est de le rendre si simple qu'il n'y a selon toute apparence aucun défaut. Et l'autre est de le faire si compliqué qu'il n'y a pas de défaut apparent."

  3. #23
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Consultant en Systèmes Embarqués
    Inscrit en
    Avril 2002
    Messages
    3 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Consultant en Systèmes Embarqués
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Avril 2002
    Messages : 3 211
    Points : 11 721
    Points
    11 721
    Par défaut
    Salut,
    Citation Envoyé par SimonDecoline
    Il est tout à fait possible de faire un OS avec un langage à exception et à garbage collector. Il faut "juste" que ce soit dans le runtime system.
    Citation Envoyé par KsassPeuk Voir le message
    J'ai l'impression que tu considères que pour éviter les problèmes cités, il faut forcément du contrôle au runtime, or ce n'est pas le cas, c'est même précisément le principe en Rust (et en fait dans un certain nombre d'autres langages notamment les langages formels). Le système de types te donne des garanties sur le comportement de ton programme et c'est lui t'empêche, lors du typage, d'écrire du code qui risque de faire des dégâts.
    Je vais m'expliquer autrement mais peut être que mon exemple sur un microcontrôleur n'est pas comparable ici, bien que je ne vois pas pourquoi ?

    Initialement je parlais d'OS de manière générale mais précisons et parlons plutôt du tout premier programme, le runtime. On considère donc que rien n'est implémenté au préalable.

    Si vous êtes sur un microcontrôleur et que vous utilisez un langage plus évolué que le C, disons un langage capable d'attraper des exceptions comme C++ avec try et catch vous ne pourrez pas vous en servir dans un premier temps. Il faudra avant avoir implémenté tout le système de l'exception + sa lecture + sa gestion etc... Sur un microcontrôleur sans OS et avec le runtime par défaut du langage C (initialisation de la pile et config du compteur programme, ça doit être a peu prés tout), lorsque vous faite :

    - déborder un pointeur, il ne se passe rien du tout, il ne faut pas s'attendre à un segment fault.
    - une allocation mémoire dans le tas qui vient écrabouiller la pile, il ne se passe rien. Vous constaterez juste un problème dans le déroulement du programme mais il n'y a aucun stack overflow qui va arriver.
    - ...

    Pour ça il faudra au préalable avoir mis en place dans le runtime ou dans le noyau de l'OS (moi j'avais tendance à inclure le premier dans le second dans mon premier message) tout le système de gestion de la mémoire. Et ce que je voulais dire, à moins que sur un processeur ça soit complètement différent, lors de l'écriture du tout premier programme (runtime, noyau) n'importe quel langage se trouvera à poils comme le C au moins le temps d'implémenter toute ce qui sera utile pour utiliser pleinement les avantages que procure le langage évolué. Je crois, peut être à tord, que beaucoup d'artifices dans les langages évolués ne sont pas utilisables lors de l'écriture du runtime/noyau.

    Exemple d'implémentation pour détecter un segment fault sur un micro pour que le langage évolué puisse faire, ensuite, son try et surtout pour qu'il puisse catch quelque chose.:
    try = Avant de manipuler un pointeur, il faudrait récupérer son adresse, récupérer son type (tableau, variable) afin de connaitre sa longueur et faire une soustraction entre l'adresse à la quelle on veut accéder et l'adresse du pointeur. Si cette soustraction active les bits du CPU ; "overflow" qui est le débordement arithmétique d'une opération et le bit "negative" qui montre le changement de signe d'une variable signée alors suivant leur état on peut capter un problème de débordement. catch = mettre à jour une variable qu'on nommera "Exception", pourquoi pas ?

    Pour faire ce que j'ai écrit juste avant, on peut prendre directement un langage évolué mais je ne vois pas vraiment pourquoi faire ?

    Concernant Rust, je n'ai pas d'avis je ne le connais pas. Mon intervention initiale ne concernait pas Rust d'ailleurs.

    Je ne sais pas si maintenant ce que j'ai écrit est plus clair ? Ou peut être que je me trompe complètement ? Ou que l'exemple du microcontrôleur n'est pas comparable ?
    A+

  4. #24
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 382
    Points : 41 588
    Points
    41 588
    Par défaut
    Le problème, c'est que les exceptions que tu mentionnes n'ont rien à voir avec les exceptions C++; elles y sont complètement orthogonales et le C++ n'a pas vocation à les attraper.
    Un try/catch du C++ n'attrape que les exceptions explicitement lancées avec un throw. C'est purement une question de contrôle de flux d'exécution et gestion des ressources.

    D'un autre côté, c'est aussi un argument contre le C++: Utiliser des classes et destructeurs peut-il vraiment assurer la libération des ressources alors qu'on est à un niveau où l'on doit pouvoir gérer aussi les exceptions venant du hardware?

  5. #25
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Pour compléter ce que dis @Medinoc sur les exceptions hardware, parlons quand même des exceptions software.

    Ce n'est pas parce que tu n'as pas de bibliothèque ou rien au niveau de ton hardware qui te donne accès à ces concepts là que tu ne peux pas écrire un compilateur pour ton langage qui va te garantir le comportement en question. C'est juste que ton compilateur a un peu plus de boulot (bien que pour les exceptions, comparativement au travail d'optimisation, c'est peanuts), mais tu peux complètement écrire un compilateur qui va te placer tout ce qu'il faut pour traiter les exceptions software sans avoir un gros runtime derrière.

    Citation Envoyé par Vincent PETIT Voir le message
    Sur un microcontrôleur sans OS et avec le runtime par défaut du langage C, lorsque vous faite :

    - déborder un pointeur, il ne se passe rien du tout, il ne faut pas s'attendre à un segment fault.
    - une allocation mémoire dans le tas qui vient écrabouiller la pile, il ne se passe rien. Vous constaterez juste un problème dans le déroulement du programme mais il n'y a aucun stack overflow qui va arriver.
    - ...

    Pour ça il faudra au préalable avoir mis en place dans le runtime ou dans le noyau de l'OS tout le système de gestion de la mémoire.
    Pour avoir ces erreurs à runtime, oui, il te faut ça. Mais justement, ce n'est absolument pas une nécessité de le faire à runtime. En tout cas dans un premier temps, et encore plus si tu veux conserver un maximum de performances. Conçois ou prends un langage qui t'interdit purement et simplement de faire des telles opérations grâce au système de types, ça existe. C'est par exemple ce que tu obtiendras au bout du compte si tu développes dans un langage comme F-Star (à noter que lui, utilise C en backend mais la traduction est quasiment one-to-one, ils ont juste un système de types de la mort pour empêcher tout écriture de code pourri).

  6. #26
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Juin 2019
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Congo-Kinshasa

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2019
    Messages : 3
    Points : 8
    Points
    8
    Par défaut
    voilà. bonjour tout le monde. si je peux donner mon avis, ce que la programmation système m'interesse. j'ai eu le temps de faire des recherches sur les langages concurrents tels que le Rust, Go, ou même le D et franchement aucun d'eux ne peut rivaliser C dans ce domaine. mais si j'ai compris, enfin c'est ce que je crois, la question est de savoir si le C a encore de l'avenir. eh bien pour moi, oui. le C évolue avec la technologie. certes y aura des langages plus récents pouvant faire les mêmes tâches, mais C a encore du temps devant lui. on cherchera toujours à le rendre performant. y avait la norme Ansi C, puis C89, C99... et maintenant C18. pourquoi toutes ces réformes alors ? c'est que C ne disparaîtra pas maintenant et il restera ma langue "officielle " de la programmation.

  7. #27
    Membre éclairé Avatar de viper1094
    Homme Profil pro
    Étudiant
    Inscrit en
    Mai 2019
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2019
    Messages : 570
    Points : 853
    Points
    853
    Par défaut
    Citation Envoyé par Médinoc Voir le message
    Le problème, c'est que les exceptions que tu mentionnes n'ont rien à voir avec les exceptions C++; elles y sont complètement orthogonales et le C++ n'a pas vocation à les attraper.
    Un try/catch du C++ n'attrape que les exceptions explicitement lancées avec un throw. C'est purement une question de contrôle de flux d'exécution et gestion des ressources.

    D'un autre côté, c'est aussi un argument contre le C++: Utiliser des classes et destructeurs peut-il vraiment assurer la libération des ressources alors qu'on est à un niveau où l'on doit pouvoir gérer aussi les exceptions venant du hardware?
    Je ne résiste pas a l'envie de voler une citation de Robert Sewell et de l'adapter a la situation :
    "Si le C++ avait un vrai garbage collector, la plupart des programmes se supprimerait eux même lors de l'éxécution"
    Voilà maintenant je retourne a ma recherche d'un foutu langage pr récupérer une touche en arrière plan.
    Bonne journée.

  8. #28
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 382
    Points : 41 588
    Points
    41 588
    Par défaut
    C ou C++ avec RegisterHotKey() ?

  9. #29
    Membre éclairé Avatar de viper1094
    Homme Profil pro
    Étudiant
    Inscrit en
    Mai 2019
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2019
    Messages : 570
    Points : 853
    Points
    853
    Par défaut
    Alors question toute conne parce que c'est pas très clair dans la docu (enfin pas clair parce que mon anglais est correct sans plus), si j'utilise cette fonction, qu'elle récupére une pression de touche, est ce qu'elle va également fonctionner sur la fenêtre en premier plan ? Ou plutôt devrais je dire est il possible de la faire fonctionner en premier plan également.

  10. #30
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 382
    Points : 41 588
    Points
    41 588
    Par défaut
    J'ai fait un petit test: Tant que RegisterHotKey() a réussi, si je presse la touche en question, la fenêtre pour laquelle RegisterHotKey a été utilisé reçoit le message WM_HOTKEY, qu'elle soit au premier plan ou non.

  11. #31
    Membre éclairé Avatar de viper1094
    Homme Profil pro
    Étudiant
    Inscrit en
    Mai 2019
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2019
    Messages : 570
    Points : 853
    Points
    853
    Par défaut
    Serait tu assez gentil pr m'expliquer globalement la syntaxe de la commande parce que moi et mon anglais de kalité on en comprend le tiers et j'aimerais m'épargner les deux heures d'expérimentations x). Enfin si ça te dérange pas hein.

  12. #32
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 382
    Points : 41 588
    Points
    41 588
    Par défaut
    Voici un exemple minimal:
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    #include <windows.h>
    #include <stdlib.h>
    #include <stdio.h>
    #include <tchar.h>
     
    LRESULT CALLBACK ProcFenetre(HWND, UINT, WPARAM, LPARAM);
     
    int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
    {
    	HWND hFenetre;
    	int ret = EXIT_FAILURE;
     
    	/*D'abord on enregistre la "classe de fenêtre"*/
    	{
    		WNDCLASSEX wcx = {0};
    		wcx.cbSize = sizeof(WNDCLASSEX);
    		wcx.hbrBackground = (HBRUSH)(COLOR_WINDOW+1); /*Les fenêtres de cette classe one la même couleur d'arrière-plan que notepad*/
    		wcx.lpfnWndProc = ProcFenetre;
    		wcx.hInstance = hInstance;
    		wcx.lpszClassName = TEXT("MaClasseDeFenetre");
    		wcx.style = CS_HREDRAW|CS_VREDRAW; /*Les fenêtres de cette classe se redessinent si on les redimensionne*/
    		wcx.hCursor = LoadCursor(NULL, IDC_ARROW); /*Les fenêtres de cette classe ont la bonne vieille flèche comme curseur*/
    		if(!RegisterClassEx(&wcx))
    			return EXIT_FAILURE;
    	}
     
    	hFenetre = CreateWindowEx(0, TEXT("MaClasseDeFenetre"), TEXT("Bonjour"), WS_OVERLAPPEDWINDOW|WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, 480, 240, NULL, NULL, hInstance, NULL);
    	if(hFenetre == NULL)
    		return EXIT_FAILURE;
     
    	/*Boucle de messages*/
    	{
    		MSG msg;
    		while(GetMessage(&msg, NULL, 0, 0)>0)
    		{
    			TranslateMessage(&msg);
    			DispatchMessage(&msg); /*Envoie le message à la procédure de fenêtre*/
    		}
    		if(msg.message == WM_QUIT)
    			ret = msg.wParam;
    	}
    	return ret;
    }
     
    /*Procédure qui traite chaque message reçu par la fenêtre*/
    LRESULT CALLBACK ProcFenetre(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
    {
    	const int ID_HOTKEY = 42;
    	LRESULT ret = 0;
     
    	switch(msg)
    	{
    	/*Quand la fenêtre est créée*/
    	case WM_CREATE:
    		/*On enregistre le raccourci clavier global sur Ctrl+Shift+F*/
    		RegisterHotKey(hWnd, ID_HOTKEY, MOD_CONTROL|MOD_SHIFT, 'F');
    		break;
     
    	/*Quand la fenêtre est détruite*/
    	case WM_DESTROY:
    		/*On désenregistre le raccourci clavier global*/
    		UnregisterHotKey(hWnd, ID_HOTKEY);
    		/*Quand la fenêtre est détruite, on signale à la boucle de message de se terminer.*/
    		PostQuitMessage(EXIT_SUCCESS);
    		break;
     
    	/*Quand le raccourci global est pressé*/
    	case WM_HOTKEY:
    		{
    			/*On change le titre de la fenêtre pour indiquer qu'on l'a reçu*/
    			int idHotkey = wParam;
    			WORD modifiers = LOWORD(lParam);
    			WORD vk = HIWORD(lParam);
    			TCHAR buf[80];
    			_sntprintf_s(buf, ARRAYSIZE(buf), _TRUNCATE, _T("Got hotkey! id=%d - modifiers=%04X - vk=%04X"), idHotkey, modifiers, vk);
    			SetWindowText(hWnd, buf);
    		}
    		break;
     
    	/*Quand la fenêtre doit être dessinée*/
    	case WM_PAINT:
    		{
    			PAINTSTRUCT ps;
    			HDC hdc = BeginPaint(hWnd, &ps);
    			// TODO: Add any drawing code here...
    			EndPaint(hWnd, &ps);
    		}
    		break;
     
    	default:
    		ret = DefWindowProc(hWnd, msg, wParam, lParam);
    		break;
    	}
    	return ret;
    }

  13. #33
    Membre éclairé Avatar de viper1094
    Homme Profil pro
    Étudiant
    Inscrit en
    Mai 2019
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2019
    Messages : 570
    Points : 853
    Points
    853
    Par défaut
    Alors j'en ai compris même pas un tiers. Donc je copie colle dans code::blocks, j'enregistre, je finis ce pendu en python, et je me met au décorticage de ce dernier.
    Merci d'avoir pris le temps d'écrire ce p'tit code, et si j'ai une question, je reviens sur ce topic ( ou je te mp si tu es d'accord ).

  14. #34
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 382
    Points : 41 588
    Points
    41 588
    Par défaut
    Ah, c'est vrai que si on ne connaît pas déjà les bases de la programmation d'une appli "fenêtrée" en C sous Windows (classe de fenêtre et boucle de messages), c'est assez incompréhensible.

  15. #35
    Membre éclairé Avatar de viper1094
    Homme Profil pro
    Étudiant
    Inscrit en
    Mai 2019
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2019
    Messages : 570
    Points : 853
    Points
    853
    Par défaut
    Citation Envoyé par Médinoc Voir le message
    Ah, c'est vrai que si on ne connaît pas déjà les bases de la programmation d'une appli "fenêtrée" en C sous Windows (classe de fenêtre et boucle de messages), c'est assez incompréhensible.
    J'me suis finalement démmerder j'ai fait un hook système, en récupérant un code et modifiant un peu. C'est pas parfait comme j'ai pas tout coder moi mais ça reste correct franchement.

  16. #36
    Membre chevronné Avatar de petitours
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    Février 2003
    Messages
    1 997
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2003
    Messages : 1 997
    Points : 2 233
    Points
    2 233
    Par défaut
    Pour moi ça reste vrai en partie.

    Un système d'exploitation a pleins de choses de haut niveau à gérer qui ont sans aucun doute intéret à exploiter la puissance d'autres langages aujourd'hui.
    Mais l'interface avec le matériel a besoin d'être au plus prés du matériel pour être optimisée, sans gérer des ramasses miettes (exemple au pif pas du tout exhaustif) et tout un tas de mécanismes inutiles pour les taches de bases qui aspirent à être hautement spécialisées en fonction des contraintes du hardware.

  17. #37
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Points : 12 462
    Points
    12 462
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Non non. A l'époque de Torvalds (paix à son âme), on faisait marcher un chaton sur le clavier et quand ça compilait on sortait une nouvelle release. https://en.wikipedia.org/wiki/Design_Patterns


    Citation Envoyé par Vincent PETIT Voir le message
    Salut,
    Il y a quelques choses que je ne comprends pas ci après, j'ai l'impression que tout ceci est un faux problème.

    ... Sans OS, pas question de faire des try catch en espérant attraper un événement puisque rien n'est implémenté. Sans OS ça ne "try"era rien, pas plus que ça "catch"era quelque chose. Un langage prenant en charge le garbage collector va se trouver dans de beaux draps si on l'utilise pour faire un OS car lors de l'écriture de celui-ci, le mécanisme sous-jacent n'est pas encore implémenté. Un langage qui a un vrai système de type ne peut pas les mettre en oeuvre pendant l'écriture de l'OS car idem, tout reste à implémenter...
    Tout à fait d'accord ! Mon langage préféré reste encore et sera sans doute toujours le C mais comme tu dis, quelque soit le langage, si c'est pour développer un noyau d'OS, tout ceci ne vaut plus rien, aussi évolué que peut être un langage !

Discussions similaires

  1. [Graphiques] Quoi de mieux que JFreeChart ?
    Par elitost dans le forum Graphisme
    Réponses: 4
    Dernier message: 21/04/2006, 17h20
  2. D7P mieux que D6P ?
    Par David dans le forum EDI
    Réponses: 5
    Dernier message: 16/06/2004, 22h15
  3. [dBase]il y a mieux que la commande sql UPDATE ?
    Par sana72 dans le forum Autres SGBD
    Réponses: 4
    Dernier message: 12/12/2002, 12h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo