Soit c'est un bytecode, soit c'est du x86/x86-64/ppc/arm/mips...
Puisque je me tue à expliquer qu'on peut compiler du code C# en x86, c'est bien que la différence est ailleur.
dans machine virtuelle, il y a virtuel. Que concrêtement le support de déploiement soit du bytecode, même si ca suppose un certain niveau d'abstraction, c'est un autre problème.
Certes, int n'est pas garanti à 32 bits, il peut faire 64 bits sur une machine 64 bits et 32 sur une machine 32 bits (en pratique : jamais vu).
Suffit d'utiliser les options -m32 et -m64 de GCC pour s'en persuader.
ou plus standard int64_t, qui date de 1999!
Le programmeur n'est pas parfait et ne connais pas tout.
et donc mettre int64_t quand tu joue avec des chiffres qui peuvent faire un débordement
Je suis un programmeur débutant, tu comprends j'ai écrits int dans mon programme et ca marchait très bien jusqu'à ce que je change de machine et que ca déborde.
Si : il utilise les types qui correspondent à son besoin
Personne n'est parfait et sait choisir pertinemment le type dont il a besoin. Si les programmeurs étaient parfaits et prenaient toujours les bonnes décisions, on se poserait pas toutes ces questions.
Tu crois que les développeurs Java ou .NET n'ont pas les moyens de fournir d'information aux développeurs et aux compilateurs ?
Si, et pourtant ils n'utilisent pas ces foutus .h qui sont à baffer.
non, typeid suppose la présence d'information et de code complémentaire à l'exécution.
Ce n'est pas directement mappable sur un sous-ensemble d'instruction machine.
A mon bon monsieur, pourquoi interdire le port d'arme à feu ? C'est vrai, malgré cette loi t'auras toujours un con pour se tuer avec un sac en plastique.
C'est pas parcqu'il est impossible d'atteindre le risque 0 qu'il ne faut pas chercher à réduire les risques d'erreur.
C'est aussi un jeu d'instruction particuliers.
Tout à fait.
throw et typeid sont des instructions C++ qui sont tout ce qu'il y a de plus virtuelles (pas directement mappé sur des instructions machines) et participent ainsi à la définition d'une VM.
Personne n'est un dieu comme toi et ne code sans erreur (d'ailleur tu dois coder en assembleur suis-je bête, tu te fais pas chier avec les services offerts par la syntaxe C qui t'offre des garanties à la compilation).
Les pauvres gens comme moi sommes imparfait tu comprends, on a le droit de travailler quand même où on doit changer de métier parcqu'il y a heuresement beaucoup de dieu comme toi ?
Qu'ils soient différents ou pareil ne devrait rien changer au programme.
T'as pensé au débordement ? Style je code sur une machine 64bits, je déploie sur 32bits après avoir fait bien gaffe à ne pas mélanger pointeur et valeur entière... et là paf erreur de calcul ! pourquoi ? Parcqu'à l'exécution mon algo a vite débordé les 32 bits, limitation que je ne voyais pas sur ma machine 64 bits.
Aucun ingénieur n'est à l'abri d'une erreur comme celle là.
Je ne vois pas pourquoi le fait de rajouter des métadonnées fait d'un code compilé une VM.
Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution.
Il n'y a aucun intermédiaire entre le code et la machine, contrairement à une VM.
GCC passe par une représentation intermédiaire, un truc de même niveau que le bytecode.
Ce que fait un compilateur C : compilation => représentation intermédiaire => code machine exécutable.
Ce que fait un compilateur C# compilation => représentation intermédiaire. Et le runtime : représentation intermédiaire => code machine exécutable.
Sachant qu'il est également possible de faire exactement comme en C, à savoir tout avant l'exécution, il ne faut pas voir dans la compilation la définition de VM.
Après on a peut-être une définition des machines virtuelles un peu différente, vu ton affirmation.
Très certainement.
C'est faux et archi faux. Tu as tous les LISP, tous les *ML, Scade sont compilé et n'ont pas de VM
On a pas la même définition d'une VM c'est tout.
C'est pas parcque tu produis du code natif que tu n'as pas de vu abstraite de la machine du point de vue du programmeur.
est une pure expérience du C.
Une pure expérience du code machine, dont les instructions manipulent des tailles de données différentes sur x86 et sur x64, ce qui conduit un langage qui définit une très faible abstraction comme le C a exposé ces différences dans les types primitifs.
Pour mettre sizeof() et non 4, dans ton code.
Sauf que tu peux mettre 4. Le langage n'offre aucune garantie et le programmeur peut se louper. L'erreur est humaine.
Mais il faut être gonfler pour mettre ce risque sur le même plan que le risque juridique anti-FLOSS venant de MS.
C'est exactement le même type de risque, le même type de protection.
Quand C# est sorti, c'était vraiment je refais un Java purement MS...
Depuis le départ, .NET propose plusieurs langages ce qui en fait une plateforme différente dans l'esprit.
ben non, c'est standardisé aujourd'hui.
Comme C# ca tombe bien.
Cela n'a rien à voir avec une VM qui traduit du bytes code !
Ca c'est ta définition réductrice de VM. Pour moi une VM est tout ce qui constitue une abstraction de la machine. Quand tu proposes un peu d'introspection comme le fait C++, c'est quelque part une VM. Beaucoup plus light qu'une VM de type .NET ou Java parcqu'offrant beaucoup moins de services, on est d'accord.
En plus aujourd'hui, il y a mini 2 coeurs à disposition.
Les perfs sont bien meilleurs avec 2 threads qu'avec 2 processus, à plus forte raison avec 2 vrais coeurs.
M ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.
Tu vois moi aussi je peux le dire : n'importe quoi.
mono me permet de compiler directement en code natif mon code C# comme le fait ton compilateur ADA.
Un compilateur comme OCaml permet de faire également les 2.
compilé et VM sont 2 notions différentes.
C'est évident et Ada pond du code machine ! (essaye gnat)
mono et .NET aussi dit donc.
si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
Il optimise au sein d'une méthode mais il va sûrement pas casser la sémantique des classes/méthodes/héritage, ce qui rendrait toute interopérabilité et l'introspection impossible.
du coup il faut rendre son navigateur autiste et désactiver tout ces plug-ins...
On est d'accord, mais le problème vient plus de la multiplicité de code exposé. Y'a beaucoup trop de code "non fiable" qui se retrouve à tourner dans nos navigateurs.
de la poudre verte.
C'est mon quotidien cette poudre.
les entrées/sorties standard, les pipes et autres named pipe... et des shells, des utilitaires et autres langages de script à foison...
Gni ? Rapport ?
Il utilise une protection hardware parfaitement et totalement étanche
Et surtout totalement propriétaire pour une architecture matérielle donnée. L'OS tout seul ne peut rien faire.
C'est une protection hardware, pas software, l'OS ne fait qu'exposer cette protection.
Une VM peut faire cette protection de manière software indépendamment de l'hardware parcqu'elle propose justement une autre vu que le code machine.
C'est la différence entre une garantie donné par une barrière comme le hardware, et une "gestion" qui est _censé_ être bien faite.
En pratique, les 2 sont complémentaires, et la gestion hardware est beaucoup trop rigide et pas assez précise (granularité : processus).
Et puis quand tu veux faire du portable (style applet), ben t'as pas le choix d'utiliser une abstraction.
Ce que tu décris, cela s'appelle de la gestion de processus
Non, ca s'appel la gestion de processus au niveau OS parcque c'est le seul cloisonnement que l'OS sait offrir.
Ca s'appel pas comme ca au niveau VM parcque ca se gère pas au niveau processus mais au niveau instruction (chaque instruction est contrôlable et contrôlée).
Là est toute la différence.
GTK en fournis il me semble ?
A condition que tu respectes strictement les conventions de codage imposée par glib. A défaut d'avoir un langage qui offre la fonctionnalité, ils fournissent une lib en partant du principe que le programmeur va respecter les conventions que le compilateur est incapable de vérifier car ce n'est pas dans sa sémantique.
Oui et alors ? C++ ne tourne pas sur une VM et dispose de la gestion d'exception en quoi faut-il une VM pour ça ?
Ben si, en définissant les exception et typeid, C++ défini une VM. De base le code machine ne te propose pas ce genre de mécanisme, le compilateur est obligé d'ajouter du code et le langage de fournir une abstraction pour gérer celà, bref une VM.
tout les langages formels.
qui définissent tous une VM.
comme le javascript ?
javascript fourni au développeur un environnement virtuel d'exécution qui n'a rien à voir avec du code machine, bref une VM.
Dans une certaine limite, je crois qu'il avait essayé de faire tourner du Fortran dans .NET et ils ont vite laisser tomber.
Ca existe toujours.
Sinon, les autres langages passe par les API C, mais c'est vrai que c'est lourd.
Et encore, c'est qu'une convention qu'heureusement la plupart respecte... Mais tu retrouves d'autre problème comme le format des bibliothèques qui diffèrent d'un OS à l'autre par exemple.
Non mais en pratique, c'est le cas.
Jor. A quoi sert le sizeof ?
A quoi servent les options -m32 and -m64 de GCC ? Pourquoi quand je change d'option mon sizeof me rend pas la même chose ? 4 et 8 dans l'autre ?
Exacte mais est-ce tellement génant ?
Oui, celà demande beaucoup de ressources supplémentaires :
- des développeurs qui s'assurent que le code est "plateforme agnostic" et "compilateur agnostic"
- des packageurs qui doivent prévoir autant de packages
- de l'espace disque pour stocker toutes ces variantes (regarde Debian)
- des ressources machines pour compiler tout ça.
Sans parler du fait que certains ne 's'enmerde' pas à faire tout ce boulot (pas de temps ou soft pas assez populaire pour qu'un mec le fasse à ta place) et tu te retrouves à devoir faire le travail toi même, parfois t'es un simple utilisateur et t'as autre chose à foutre.
Oui c'est génant je crois.
et que cela ne couvre rien des problèmes de haut niveau comme les "SQL injection", le X-site-scritping, et autre.
Effectivement, ca ne protège pas non plus ta grand mère au carrefour quand elle traverse. Mais ce que tu dis n'est pas faux.
Enfin, tout les langage formels quoi :)
Qui définissent tous une VM :) C'est parcqu'il y a production direct de code machine qu'il n'y a pas de VM. Une VM est une abstraction par nature virtuelle, in fine c'est toujours du code machine qui s'exécute.
qu'elles ne devraient jamais arriver,
D'où leur nom : exception :)
Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
Une nette amélioration par rapport aux ActiveX :)
et il y a, de fait, diverses possibilités d'interopérabilités.
Et à peu prêt autant d'impossibilité.
Je te parle d'interopérabilité outofthebox, de langages qui définissent et échange de la même manière leurs classes pour les rendre utilisables directement.
Quand je code en C# je dois pas me coltiner de bindings pour exposer mes classes aux développeurs VB.NET IronPython, Boo, C++/CLI. Ca marche, point. Une réelle interopérabilité.
Serait il possible qu'un attaquant, a partir de son code "non sur" arrive a phagocyter le code dis "sur" ?
Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
C'est "by design" que du code natif laisse faire tout et n'importe quoi.
C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
L'OS contient surtout une quantité hallucinante de code tournant dans un même espace mémoire. Une VM a un code extrêmement réduit, et la gestion de sécu, là où passe tout le code utilisateur et donc est la seule "véritable" faille de la VM, est une partie insignifiante de ce que représente tout le joli monde que l'on trouve dans le kernel.
De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes.
Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
Suffit de voir des projets de recherche sur les OS comme Singularity qui propose un modèle de sécurité entièrement logiciel, uniquement possible parcque s'appuyant sur une VM qui défini un jeu d'instruction entièrement contrôlable par l'OS. http://en.wikipedia.org/wiki/Singularity_%28operating_system(...)
La plus grosse faille de sécu de ces VM, c'est là où elle appel du code natif. En dehors du coeur (JIT et runtime en soit), la gros trou est au niveau des bindings vers des libs natives (IHM ou autre).
C'est là que la VM n'a plus la main sur le code exécuté, et c'est là que ca peut devenir dangereux.
ça, un paquet de langages compilé natif le font
Les langages qui font ca sont obligés d'insérer des métadonnées dans l'exécutable, bref de définir un modèle d'information de plus haut niveau, une VM. C'est ce que fait C++, c'est ce que fait n'importe quelle VM qui propose l'introspection.
Si tu parles uniquement de code natif pur, la seule introspection possible concerne par définition le jeu d'instruction du processeur.
Si tu veux plus d'information, tu introduis une abstraction virtuelle.
Tous les OSes et les langages, que je connnais, fournissent ça.
Tu vois très bien ce que je veux dire.
les protected de c++ en sont un des nombreux exemples)
\o/ J'espère que tu coderas jamais une application C++ qui expose des données sensibles à l'extérieur.
Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.
Je ne connais pas un seul langage mainstream qui ne fournit pas cette compatibilité.
Quand je te dis compatibilité, c'est la possibilité de définir des classes réutilisables sans se soucier du langage qui va l'utiliser.
La seule convention qui existe, c'est les API plates à la C.
2 compilos C++ sont même pas foutus de se mettre d'accord sur une compatibilité alors tu me fais bien rire avec cette compatibilité entre les langages.
Est-ce que je peux réutiliser en C mes classes C++ sans me coltiner un outil ou une couche de glue avec laquelle je vais devoir faire gaffe ? non.
Est ce que je peux réutiliser en C mes objets ObjectiveC ou Python sans me coltiner une couche intermédiaire ? non.
Est ce que je peux réutiliser mes objets C# en IronPython ou en VB.NET sans me soucier de la façon dont ca va se passer ? oui.
Ada fait abstraction des threads OSes et est pourtant compilé.
ADA propose au sein de son langage une abstraction des threads, il défini une VM.
La question n'est pas de savoir si c'est compilé ou non (c'est un faux débat puisqu'un programme C# peut être compilé en code natif).
La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.
Pas beaucoups plus que pour une machine réelle, les phases d'optimisations sont très rarement réversibles
Non non et non.
Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
En C, tu te retrouves avec un binaire et des instructions machines. Tout ce que tu obtiens à la décompilation, c'est des instructions assembleur. Tu perds toutes tes classes ou autre information de plus haut niveau.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Puisque je me tue à expliquer qu'on peut compiler du code C# en x86, c'est bien que la différence est ailleur.
dans machine virtuelle, il y a virtuel. Que concrêtement le support de déploiement soit du bytecode, même si ca suppose un certain niveau d'abstraction, c'est un autre problème.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
[^] # Re: Drôle
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Suffit d'utiliser les options -m32 et -m64 de GCC pour s'en persuader.
ou plus standard int64_t, qui date de 1999!
Le programmeur n'est pas parfait et ne connais pas tout.
et donc mettre int64_t quand tu joue avec des chiffres qui peuvent faire un débordement
Je suis un programmeur débutant, tu comprends j'ai écrits int dans mon programme et ca marchait très bien jusqu'à ce que je change de machine et que ca déborde.
Si : il utilise les types qui correspondent à son besoin
Personne n'est parfait et sait choisir pertinemment le type dont il a besoin. Si les programmeurs étaient parfaits et prenaient toujours les bonnes décisions, on se poserait pas toutes ces questions.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Si, et pourtant ils n'utilisent pas ces foutus .h qui sont à baffer.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ce n'est pas directement mappable sur un sous-ensemble d'instruction machine.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
C'est pas parcqu'il est impossible d'atteindre le risque 0 qu'il ne faut pas chercher à réduire les risques d'erreur.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Tout à fait.
throw et typeid sont des instructions C++ qui sont tout ce qu'il y a de plus virtuelles (pas directement mappé sur des instructions machines) et participent ainsi à la définition d'une VM.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Les pauvres gens comme moi sommes imparfait tu comprends, on a le droit de travailler quand même où on doit changer de métier parcqu'il y a heuresement beaucoup de dieu comme toi ?
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
T'as pensé au débordement ? Style je code sur une machine 64bits, je déploie sur 32bits après avoir fait bien gaffe à ne pas mélanger pointeur et valeur entière... et là paf erreur de calcul ! pourquoi ? Parcqu'à l'exécution mon algo a vite débordé les 32 bits, limitation que je ne voyais pas sur ma machine 64 bits.
Aucun ingénieur n'est à l'abri d'une erreur comme celle là.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Donc c'est pas ton problème.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution.
Il n'y a aucun intermédiaire entre le code et la machine, contrairement à une VM.
GCC passe par une représentation intermédiaire, un truc de même niveau que le bytecode.
Ce que fait un compilateur C : compilation => représentation intermédiaire => code machine exécutable.
Ce que fait un compilateur C# compilation => représentation intermédiaire. Et le runtime : représentation intermédiaire => code machine exécutable.
Sachant qu'il est également possible de faire exactement comme en C, à savoir tout avant l'exécution, il ne faut pas voir dans la compilation la définition de VM.
Après on a peut-être une définition des machines virtuelles un peu différente, vu ton affirmation.
Très certainement.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
C'est à ça que sert l'introspection, à enterrer 6 pieds sous terre ces foutus .h :)
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
On a pas la même définition d'une VM c'est tout.
C'est pas parcque tu produis du code natif que tu n'as pas de vu abstraite de la machine du point de vue du programmeur.
est une pure expérience du C.
Une pure expérience du code machine, dont les instructions manipulent des tailles de données différentes sur x86 et sur x64, ce qui conduit un langage qui définit une très faible abstraction comme le C a exposé ces différences dans les types primitifs.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Sauf que tu peux mettre 4. Le langage n'offre aucune garantie et le programmeur peut se louper. L'erreur est humaine.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Là est tout le problème. CQFD.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
C'est exactement le même type de risque, le même type de protection.
Quand C# est sorti, c'était vraiment je refais un Java purement MS...
Depuis le départ, .NET propose plusieurs langages ce qui en fait une plateforme différente dans l'esprit.
ben non, c'est standardisé aujourd'hui.
Comme C# ca tombe bien.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Ca c'est ta définition réductrice de VM. Pour moi une VM est tout ce qui constitue une abstraction de la machine. Quand tu proposes un peu d'introspection comme le fait C++, c'est quelque part une VM. Beaucoup plus light qu'une VM de type .NET ou Java parcqu'offrant beaucoup moins de services, on est d'accord.
En plus aujourd'hui, il y a mini 2 coeurs à disposition.
Les perfs sont bien meilleurs avec 2 threads qu'avec 2 processus, à plus forte raison avec 2 vrais coeurs.
M ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.
Tu vois moi aussi je peux le dire : n'importe quoi.
mono me permet de compiler directement en code natif mon code C# comme le fait ton compilateur ADA.
Un compilateur comme OCaml permet de faire également les 2.
compilé et VM sont 2 notions différentes.
C'est évident et Ada pond du code machine ! (essaye gnat)
mono et .NET aussi dit donc.
si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
Il optimise au sein d'une méthode mais il va sûrement pas casser la sémantique des classes/méthodes/héritage, ce qui rendrait toute interopérabilité et l'introspection impossible.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
On est d'accord, mais le problème vient plus de la multiplicité de code exposé. Y'a beaucoup trop de code "non fiable" qui se retrouve à tourner dans nos navigateurs.
de la poudre verte.
C'est mon quotidien cette poudre.
les entrées/sorties standard, les pipes et autres named pipe... et des shells, des utilitaires et autres langages de script à foison...
Gni ? Rapport ?
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Et surtout totalement propriétaire pour une architecture matérielle donnée. L'OS tout seul ne peut rien faire.
C'est une protection hardware, pas software, l'OS ne fait qu'exposer cette protection.
Une VM peut faire cette protection de manière software indépendamment de l'hardware parcqu'elle propose justement une autre vu que le code machine.
C'est la différence entre une garantie donné par une barrière comme le hardware, et une "gestion" qui est _censé_ être bien faite.
En pratique, les 2 sont complémentaires, et la gestion hardware est beaucoup trop rigide et pas assez précise (granularité : processus).
Et puis quand tu veux faire du portable (style applet), ben t'as pas le choix d'utiliser une abstraction.
Ce que tu décris, cela s'appelle de la gestion de processus
Non, ca s'appel la gestion de processus au niveau OS parcque c'est le seul cloisonnement que l'OS sait offrir.
Ca s'appel pas comme ca au niveau VM parcque ca se gère pas au niveau processus mais au niveau instruction (chaque instruction est contrôlable et contrôlée).
Là est toute la différence.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
A condition que tu respectes strictement les conventions de codage imposée par glib. A défaut d'avoir un langage qui offre la fonctionnalité, ils fournissent une lib en partant du principe que le programmeur va respecter les conventions que le compilateur est incapable de vérifier car ce n'est pas dans sa sémantique.
Oui et alors ? C++ ne tourne pas sur une VM et dispose de la gestion d'exception en quoi faut-il une VM pour ça ?
Ben si, en définissant les exception et typeid, C++ défini une VM. De base le code machine ne te propose pas ce genre de mécanisme, le compilateur est obligé d'ajouter du code et le langage de fournir une abstraction pour gérer celà, bref une VM.
tout les langages formels.
qui définissent tous une VM.
comme le javascript ?
javascript fourni au développeur un environnement virtuel d'exécution qui n'a rien à voir avec du code machine, bref une VM.
Dans une certaine limite, je crois qu'il avait essayé de faire tourner du Fortran dans .NET et ils ont vite laisser tomber.
Ca existe toujours.
Sinon, les autres langages passe par les API C, mais c'est vrai que c'est lourd.
Et encore, c'est qu'une convention qu'heureusement la plupart respecte... Mais tu retrouves d'autre problème comme le format des bibliothèques qui diffèrent d'un OS à l'autre par exemple.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Jor. A quoi sert le sizeof ?
A quoi servent les options -m32 and -m64 de GCC ? Pourquoi quand je change d'option mon sizeof me rend pas la même chose ? 4 et 8 dans l'autre ?
Exacte mais est-ce tellement génant ?
Oui, celà demande beaucoup de ressources supplémentaires :
- des développeurs qui s'assurent que le code est "plateforme agnostic" et "compilateur agnostic"
- des packageurs qui doivent prévoir autant de packages
- de l'espace disque pour stocker toutes ces variantes (regarde Debian)
- des ressources machines pour compiler tout ça.
Sans parler du fait que certains ne 's'enmerde' pas à faire tout ce boulot (pas de temps ou soft pas assez populaire pour qu'un mec le fasse à ta place) et tu te retrouves à devoir faire le travail toi même, parfois t'es un simple utilisateur et t'as autre chose à foutre.
Oui c'est génant je crois.
et que cela ne couvre rien des problèmes de haut niveau comme les "SQL injection", le X-site-scritping, et autre.
Effectivement, ca ne protège pas non plus ta grand mère au carrefour quand elle traverse. Mais ce que tu dis n'est pas faux.
Enfin, tout les langage formels quoi :)
Qui définissent tous une VM :) C'est parcqu'il y a production direct de code machine qu'il n'y a pas de VM. Une VM est une abstraction par nature virtuelle, in fine c'est toujours du code machine qui s'exécute.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
D'où leur nom : exception :)
Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
Une nette amélioration par rapport aux ActiveX :)
et il y a, de fait, diverses possibilités d'interopérabilités.
Et à peu prêt autant d'impossibilité.
Je te parle d'interopérabilité outofthebox, de langages qui définissent et échange de la même manière leurs classes pour les rendre utilisables directement.
Quand je code en C# je dois pas me coltiner de bindings pour exposer mes classes aux développeurs VB.NET IronPython, Boo, C++/CLI. Ca marche, point. Une réelle interopérabilité.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
C'est "by design" que du code natif laisse faire tout et n'importe quoi.
C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
L'OS contient surtout une quantité hallucinante de code tournant dans un même espace mémoire. Une VM a un code extrêmement réduit, et la gestion de sécu, là où passe tout le code utilisateur et donc est la seule "véritable" faille de la VM, est une partie insignifiante de ce que représente tout le joli monde que l'on trouve dans le kernel.
De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes.
Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
Suffit de voir des projets de recherche sur les OS comme Singularity qui propose un modèle de sécurité entièrement logiciel, uniquement possible parcque s'appuyant sur une VM qui défini un jeu d'instruction entièrement contrôlable par l'OS.
http://en.wikipedia.org/wiki/Singularity_%28operating_system(...)
La plus grosse faille de sécu de ces VM, c'est là où elle appel du code natif. En dehors du coeur (JIT et runtime en soit), la gros trou est au niveau des bindings vers des libs natives (IHM ou autre).
C'est là que la VM n'a plus la main sur le code exécuté, et c'est là que ca peut devenir dangereux.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Les langages qui font ca sont obligés d'insérer des métadonnées dans l'exécutable, bref de définir un modèle d'information de plus haut niveau, une VM. C'est ce que fait C++, c'est ce que fait n'importe quelle VM qui propose l'introspection.
Si tu parles uniquement de code natif pur, la seule introspection possible concerne par définition le jeu d'instruction du processeur.
Si tu veux plus d'information, tu introduis une abstraction virtuelle.
Tous les OSes et les langages, que je connnais, fournissent ça.
Tu vois très bien ce que je veux dire.
les protected de c++ en sont un des nombreux exemples)
\o/ J'espère que tu coderas jamais une application C++ qui expose des données sensibles à l'extérieur.
Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.
Je ne connais pas un seul langage mainstream qui ne fournit pas cette compatibilité.
Quand je te dis compatibilité, c'est la possibilité de définir des classes réutilisables sans se soucier du langage qui va l'utiliser.
La seule convention qui existe, c'est les API plates à la C.
2 compilos C++ sont même pas foutus de se mettre d'accord sur une compatibilité alors tu me fais bien rire avec cette compatibilité entre les langages.
Est-ce que je peux réutiliser en C mes classes C++ sans me coltiner un outil ou une couche de glue avec laquelle je vais devoir faire gaffe ? non.
Est ce que je peux réutiliser en C mes objets ObjectiveC ou Python sans me coltiner une couche intermédiaire ? non.
Est ce que je peux réutiliser mes objets C# en IronPython ou en VB.NET sans me soucier de la façon dont ca va se passer ? oui.
Ada fait abstraction des threads OSes et est pourtant compilé.
ADA propose au sein de son langage une abstraction des threads, il défini une VM.
La question n'est pas de savoir si c'est compilé ou non (c'est un faux débat puisqu'un programme C# peut être compilé en code natif).
La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.
Pas beaucoups plus que pour une machine réelle, les phases d'optimisations sont très rarement réversibles
Non non et non.
Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
En C, tu te retrouves avec un binaire et des instructions machines. Tout ce que tu obtiens à la décompilation, c'est des instructions assembleur. Tu perds toutes tes classes ou autre information de plus haut niveau.