Pour résumer les limitations provoqué par ce changement bien précis :
Tu ne peut pas charger un code en language machine dans une variable et l'exécuter directement, tout code faisant ça doit être changé. (Que tu mettre ce code là en toute conaissance de cause ou par la suite d'un buffer overflow)
Or à pars dans un compilateur JustInTime en code Machine ou une exploitation de buffer overflow on ne voit presque jamais ça c'est hyper rare.
Ont de grande chance de l'utiliser : Machine virtuelle .Net ou Mono si elles passent directement du MSIL au code machine (j'en sais rien faudrait voir, a mon avis pas par défaut), Zend PHP Optimiseur si il transforme en code machine au lieu de le transformer en langage intermédiaire (pour garder le coté "managed" je pense qu'il utilise un langage intermediaire), JVM (Même "si" que au dessus), ...
En gros c'est VRAIMENT pas le truc que tu programme pour le plaisir juste comme ça et si oui trouver de la doc est pas vraiment impossible, voir liens de PBPG.
Je ne vois vraiment pas pourquoi il y as un débat aussi fourni sur ce sujet, linux ne laisse pas les compte non-root accéder à tout, ne laisse pas n'importe qui toucher directement au materiel, je trouve que c'est une bonne évolution vers la sécurité et que c'est pas un mal que windows se sécurise.
L'esprit Hacker devrais ammener à ce que en voyant microsoft essayer de sécuriser son OS et avancer dans ce sans on applaudisse et on en profite pour continuer à avoir un haut niveau de sécurité et à s'amméliorer en voyant ça comme de la saine concurence, mais non il vaut mieux crier au loup pour des choix que l'on ne comprends pas et dont on ne comprends pas les conséquences.
Quant aux "autres problèmes" de l'article ils parlaient peut-être du firewall qui il est vrai vas obliger les utilisateurs à peut-être un peu mieux comprendre le réseau et la sécurité si ils veulent l'utiliser.
A ce que j'ai compris le firewall bloqueras aussi les ports DCOM par défaut et donc les programmes qui se servent de DCOM devrons ouvrir ce port au firewall, mais vu l'utilisation très spécifique de ces technologies je pense que ce sont des gens qui lisent les rapports de Service Pack...
[^] # Re: Windows XP SP2 : des problemes de compatibilité dixit Microsoft !!
Posté par Black Fox . En réponse au journal Windows XP SP2 : des problemes de compatibilité dixit Microsoft !!. Évalué à 2.
Tu ne peut pas charger un code en language machine dans une variable et l'exécuter directement, tout code faisant ça doit être changé. (Que tu mettre ce code là en toute conaissance de cause ou par la suite d'un buffer overflow)
Or à pars dans un compilateur JustInTime en code Machine ou une exploitation de buffer overflow on ne voit presque jamais ça c'est hyper rare.
Ont de grande chance de l'utiliser : Machine virtuelle .Net ou Mono si elles passent directement du MSIL au code machine (j'en sais rien faudrait voir, a mon avis pas par défaut), Zend PHP Optimiseur si il transforme en code machine au lieu de le transformer en langage intermédiaire (pour garder le coté "managed" je pense qu'il utilise un langage intermediaire), JVM (Même "si" que au dessus), ...
En gros c'est VRAIMENT pas le truc que tu programme pour le plaisir juste comme ça et si oui trouver de la doc est pas vraiment impossible, voir liens de PBPG.
Je ne vois vraiment pas pourquoi il y as un débat aussi fourni sur ce sujet, linux ne laisse pas les compte non-root accéder à tout, ne laisse pas n'importe qui toucher directement au materiel, je trouve que c'est une bonne évolution vers la sécurité et que c'est pas un mal que windows se sécurise.
L'esprit Hacker devrais ammener à ce que en voyant microsoft essayer de sécuriser son OS et avancer dans ce sans on applaudisse et on en profite pour continuer à avoir un haut niveau de sécurité et à s'amméliorer en voyant ça comme de la saine concurence, mais non il vaut mieux crier au loup pour des choix que l'on ne comprends pas et dont on ne comprends pas les conséquences.
Quant aux "autres problèmes" de l'article ils parlaient peut-être du firewall qui il est vrai vas obliger les utilisateurs à peut-être un peu mieux comprendre le réseau et la sécurité si ils veulent l'utiliser.
A ce que j'ai compris le firewall bloqueras aussi les ports DCOM par défaut et donc les programmes qui se servent de DCOM devrons ouvrir ce port au firewall, mais vu l'utilisation très spécifique de ces technologies je pense que ce sont des gens qui lisent les rapports de Service Pack...