J'utilise aussi GNU/Linux en client, en ce moment même.
Pour l'utilisation que nous en avons, le fait qu'il ne soit pas objet, ou peut être seulement orienté objet pour une couche proche de la "surface" n'est pas absolument déterminante.
Pour des utilisation en entreprise, ou multimédia, l'approche objet proche du centre, c'est à dire du noyau est indispensable. Dans une application de GED (j'en ai vu), l'approche objet sous windows permet de gérer toutte application gérant un format de fichier comme un objet.
Cela signifie et implique que l'on peut appeler, intrinsèquement au système, tout application comme un objet dans un browser. Il n'est pas nécessaire d'avoir préparé le browser ou l'application subséquente. Le fait qu'elle existe fait qu'elle est considéré comme un objet.
Cela signifie qu'un outil GNU de base tournant avec cygwin est un objet pour le système NT.
Sous NT tout est objet : thread, processus, fichiers, objets de synchro, zone de mémoire, timer. On les appele des ressources.
Lorsque qu'une appli ouvre une ressource, le gestionnaire d'objet détermine l'objet associé.
Sous NT, le gestionnaire d'objet est un élément système de même niveau que la gestion des processus(com' pas shedulling), la gestion des entrées sorties et la gestion de la mémoire virtuelle.
La synchronisation entre processus est en mécanisme objet.
On peut scripter (en vbscript, natif dans le système) l'intégration du framework word ou excell dans une fenêtre web. en allanat chercher une méthode correspondant à une macro, à l'ouverture d'un fichier, etc...
MonObjet = word.openFile(NomFichier)
MaSousFenetreDansMonBrowserEnBasADroite = MonObjet.Show
en gros les possibilités c'est ça.
Sous linux je ne peux pas traiter bzip2, bunzip, vi, emacs comme un objet ?
Je pose la question, hein, on sait jamais...
---
Une section critique, c'est la possibilité pour plusieurs threads d'un processus d'accéder en exclusion mutuelle à des données communes, définies comme telles, à l'ensemble de thread dont on a décidé qu'il partageraient cette zone de données.
Sous NT, c'est un objet.
--
je redonne le lien d'un cours qui t'expliquera ça très bien.
Pour le fait que l'objet n'est qu'une abstraction, ce n'est plus vrai, il existe des langages purement objet, même à l'éxécution, je citerai le langage SELF ou plus récemment LISAAC. Voir sur les sites de l'inria pour plus d'informations.
----
L'API KDE est orienté objet, certes, mais les mécanismes objets sont uniquement présent à la surface et ne sont pas géré au coeur du système.
Je sais ça fait tout drôle, j'ai appris ça il y a très peu de temps.
Voilà...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un peu de tout :)
Posté par Ontologia (site web personnel) . En réponse au journal Un peu de tout :). Évalué à -1.
Pour l'utilisation que nous en avons, le fait qu'il ne soit pas objet, ou peut être seulement orienté objet pour une couche proche de la "surface" n'est pas absolument déterminante.
Pour des utilisation en entreprise, ou multimédia, l'approche objet proche du centre, c'est à dire du noyau est indispensable. Dans une application de GED (j'en ai vu), l'approche objet sous windows permet de gérer toutte application gérant un format de fichier comme un objet.
Cela signifie et implique que l'on peut appeler, intrinsèquement au système, tout application comme un objet dans un browser. Il n'est pas nécessaire d'avoir préparé le browser ou l'application subséquente. Le fait qu'elle existe fait qu'elle est considéré comme un objet.
Cela signifie qu'un outil GNU de base tournant avec cygwin est un objet pour le système NT.
Sous NT tout est objet : thread, processus, fichiers, objets de synchro, zone de mémoire, timer. On les appele des ressources.
Lorsque qu'une appli ouvre une ressource, le gestionnaire d'objet détermine l'objet associé.
Sous NT, le gestionnaire d'objet est un élément système de même niveau que la gestion des processus(com' pas shedulling), la gestion des entrées sorties et la gestion de la mémoire virtuelle.
La synchronisation entre processus est en mécanisme objet.
On peut scripter (en vbscript, natif dans le système) l'intégration du framework word ou excell dans une fenêtre web. en allanat chercher une méthode correspondant à une macro, à l'ouverture d'un fichier, etc...
MonObjet = word.openFile(NomFichier)
MaSousFenetreDansMonBrowserEnBasADroite = MonObjet.Show
en gros les possibilités c'est ça.
Sous linux je ne peux pas traiter bzip2, bunzip, vi, emacs comme un objet ?
Je pose la question, hein, on sait jamais...
---
Une section critique, c'est la possibilité pour plusieurs threads d'un processus d'accéder en exclusion mutuelle à des données communes, définies comme telles, à l'ensemble de thread dont on a décidé qu'il partageraient cette zone de données.
Sous NT, c'est un objet.
--
je redonne le lien d'un cours qui t'expliquera ça très bien.
http://smacchia.chez.tiscali.fr/Res/winnt/NT_Cour.pdf(...)
-----
Pour le fait que l'objet n'est qu'une abstraction, ce n'est plus vrai, il existe des langages purement objet, même à l'éxécution, je citerai le langage SELF ou plus récemment LISAAC. Voir sur les sites de l'inria pour plus d'informations.
----
L'API KDE est orienté objet, certes, mais les mécanismes objets sont uniquement présent à la surface et ne sont pas géré au coeur du système.
Je sais ça fait tout drôle, j'ai appris ça il y a très peu de temps.
Voilà...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker