pasBill pasGates a écrit 16062 commentaires

Pour générer son sous-système SUA Posix, windows n'utilise pas l'API win32. Si je n'en dit pas une grosse ( c'est carrément possible), il utilise d'autres api notamment la Native Api. Le problème quand on commence à toucher à ce genre d'api, c'est le manque de documentation… à tort ou à raison, une partie de cette api n'est pas documentée. Je suppose que cette api n'est pas stable avec le changement de version, et c'est cette argument qui est utilisé pour ne pas la documenter entièrement?

Ce qu'il faut comprendre c'est que SUA ne peut pas utiliser Win32. Win32 est un sous-systeme au meme titre que SUA. Les 2 tournent en parrallele, pas l'un dans l'autre. Les APIs que les sous-systemes utilisent sont effectivement les APIs de NT (NTdll.dll) qui ne sont pas grand chose d'autre que des wrappers sur les systemcalls du noyau. Ces APIs ne sont senses etre utilises que par le systeme car ils sont effectivement sujets a changement (et cela arrive). SUA appelle Nt directement tout simplement parce que SUA faisait partie du systeme.

Des soucis de sécurités sont trouvés régulièrement dans windows, comme dans tous projets libres, et dans windows, comme dans certains projets libres, leur façon de les gérer est souvent merdique, lente. Ils sont publiés seulement par la pression des utilisateur qui comparent avec la transparence des façons de faire des autres, sinon tu pourrais toujours de toucher la nouille pour avoir des infos…

Ca serait bien que tu evites de raconter n'importe quoi quand meme… Tu n'as absolument RIEN pour baser cette affirmation.

Et je te suggeres de reflechir a 2 fois a ce que tu reponds, parce que l'equipe qui s'occupe des patchs de securite chez MS, c'est la mienne, tu auras du mal a passer la moindre anerie a travers mon filtre.

Je crois que la reponse est : J'en ai aucune idee :+)

J'ai rien remarque personellement, mais vu la sensibilite de ma vue ca ne veut pas dire grand chose.

À vous d'annoncer vos priorités, c'est vrai qu'écouter ses utilisateurs n'est pas non plus votre fort (alors que l'informatique devrait être au service de tous, ou du maximum possible, suffit d'avoir des gens motivés).

C'est justement tout le contraire, on ecoute nos utilisateurs. L'enorme majorite d'entre eux se fiche totalement du support ext4 / btrfs. Seul 1% de la planete utilise ext4/btrfs, et ces gens la ne sont en bonne partie pas des utilisateurs de Windows.

Moi j'attends que tu m'expliques en quoi le support de ces FS serait plus prioritaire qu'une meilleure duree sur batterie, une securite renforcee, une utilisation simplifiee du browser, etc… pour les utilisateurs Windows. Qu'est ce que ca amene ? Leur permettre de faire un double boot Linux / Windows facilement ? Ca aiderait combien de gens ? Quasiment personne, meme pas 1%.

Interoperabilite avec quoi ? Ce ne sont pas des standards, ce sont juste des formats comme d'autres. On la met ou la barre de ce qu'on supporte ? On devrait supporter les filesystemes Amiga et BSD aussi ? Les formats d'image XBM aussi ?

Faut etre realiste, tu demandes un truc qui ne servirait meme pas a 1% de la population, au niveau des priorites c'est vraiment en bas de l'echelle.

Ben les drivers Hyper-V pour Linux je connais pas trop donc ca me serait difficile d'ecrire un truc correct.
Pour ext4 et btrfs de base, le jour ou ce sera populaire ca se fera surement, mais aujourd'hui ca servirait a qui ? Quasiment personne. Personne ne met des serveurs en double boot, et les desktops avec ext4 / btrfs sont une infime minorite.

Oh je peux imaginer que ce ne soit pas parfait, si on faisait tout tout juste ca se saurait :+)

Euh si ca marche, je viens de le faire sur ma machine pour tester :
- Tu clique droit sur les entetes de colonne, choisis les colonnes supplementaires que tu veux
- Tu vas dans Tools -> Folder Options, tu choisis "apply view to all folders" et ca marche

Pour les "librairies" ca pourrait etre different par contre.

Euh là je ne pige pas bien, pour migrer à chaud entre 2 machines il faut bien que les données soient accessibles sur les 2 machines !

Tout a fait, le truc a comprendre est que les donnees sont migrees a chaud, pendant que la VM tourne et qu'au bout d'un moment la bascule s'opere.

Autre chose, savez vous si windows server intègre l'équivalent de tmem/frontswap/cleancache, car maintenant que c'est officiellement stabilisé dans le noyau 3.6, c'est à mon avis le truc magique : on peut dimensionner ses vm au plus juste en mémoire, et ainsi s'assurer qu'elles tiendront toutes sur un Dom0 en cas de failover, et en fonctionnement normal, elles utilisent toute la mémoire libre de l'hyperviseur, aussi bien pour le pseudo-swap(frontswap) que pour le cache disque(cleancache) !

Hyper-V a "dynamic memory" depuis Server 2008 R2 SP1 qui permet d'allouer plus de RAM que physiquement present, et le systeme s'occupe de bouger la RAM entre les VMs. selon les besoins, c'est de ca que tu parles ?

Au niveau fonctionnel peut-etre, mais au niveau securite on a elimine le probleme.

ReFS supporte la compression et le chiffrement, mais au niveau du volume entier seulement, plutot que fichier par fichier.

NTFS n'est pas pret de disparaitre lui, FAT32 j'en sais rien, pas de tout de suite en tout cas.

Euh si ca a toujours ete possible… juste pas de maniere 'visible' pour le pekin moyen.

Tu passes le nom / chemin du fichier en mode 'canonique' aux API (c'est a dire que tu passes directement a travers toute l'interpretation faite par Win32 en ajoutant \\?\ au debut ) et tu peux acceder a des chemins allant jusqu'a 32768 caracteres, soit le maximum supporte par NTFS.

J'ai l'impression, mais peut être que je me trompe, que le noyau Windows compile sur plusieurs architectures mais que toute la couche utilisateurs est différente alors que sous GNU/Linux, en gros l'idée est de recompiler l'ensemble des mêmes paquets sur les différentes architectures. Bref, de ne pas spécialiser la couche utilisateur à tel ou tel domaine.

Tu te trompes…

1) Je vois pas le probleme des extensions de fichier, c'est quoi ? kournikova.jpg.exe ? Ce probleme a ete elimine il y a deja un petit moment
2) Tu devrais t'assurer que ton Windows est a jour, ca fait un petit moment qu'on a change ce comportement.

Oui bon on se comprend :)

Je sais tres bien qu'approcher quoi que ce soit au sujet de MS au niveau 'politique' va finir en une depeche avec 500 commentaires, tous mes posts a -4, -5, Albert qui va faire une syncope et moi qui vais perdre mon temps, donc bon…

Je sais pertinemment qu'il y a les versions 32 et 64 bits de IE mais lorsque tu le lances, tu as par défaut la version 32bits et je suis persuadé que très peu d'utilisateurs savent qu'ils ont une version 64 bits sur leur PC.

Certainement, mais tu n'amenes pas une techno comme ca quand il y a tout un tas d'elements existants. Si le plugin faisant des bruits de pet a chaque click dans IE ne marche plus car 32bit uniquement, ton petit frere retournera a IE32bit de toute facon. On fait donc cela par etape, et la 1ere etape est de pousser les editeurs a passer leurs plugins en 64bit.

On s'est tous aussi que le développement s'appuie sur les architectures matérielles sous jacente. Cela a été dis dans un autre post ici il me semble. Voir le coup de gueule de Linus concernant le port ARM il y a quelques mois. Certaines fonctionnalité tirent partie des nouvelles instructions les CPU, il y eu il y a longtemps la MMU pour la mémoire (avec un port Linux sans MMU), il y a maintenant tout ce qui concerne la virtualisation qui n'est pas du tout au même niveau sur tous les CPU. N'étant pas spécialiste, je ne sais pas qu'elle est l'influence exacte de ce genre de contrainte dans le design d'un OS.

NT a depuis sa naissance le concept de HAL (Hardware Abstraction Layer) qui se situe comme couche entre le materiel et le noyau pour gerer les differences au niveau du materiel. C'est en tres grosse partie la dedans que le port ARM a eu lieu: ajouter le support pour les SoC differents, timers et controlleurs d'interruption specifiques a la plateforme, etc… et aussi un peu de boulot dans les pieces genre le memory manager.

Le reste du code au dessus c'est a 99% du C et C++ standard avec les APIs deja 'prepares' depuis longtemps pour supporter des tailles de pointeur differentes, etc… Il y a un peu de boulot supplementaire pour certaines parties pour optimiser le code en fonction de l'architecture (ecrire du code de maniere differentes sur des archis differentes peut ameliorer les perfs) et il faut evidemment avoir un compilateur ARM et ecrire les drivers pour le hardware specifique aux systemes ARM mais voila, c'est a peu pres tout.

Au niveau du developpement, vu la taille de la division on a une structure hierarchique :
- Un depot "Main" d'ou sortent les versions 'officielles' de la division Windows pour toutes les plateformes.
- Chaque sous-groupe (networking, shell, hyper-v, …) a sa branche, ou ils font leurs trucs, et quand ca atteint une qualite decente, ils integrent dans "Main"
- Chaque sous-groupe a aussi des sous branches pour leur differentes parties (TCP/IP, firewall, … pour networking par exemple)

Le code dans chacun de ces depots est evidemment le meme pour toutes les plateformes (ARM, x86, amd64) avec les #ifdef et autres trucs qu'il faut et chaque depot sort les 3 plateformes et les 3 OS (phone, server, client), sauf pour les couches tres hautes qui sont differentes entre le phone et le client(genre Explorer.exe, Media Player, …)

Il y a tous ceux qui utiliseront le "modern desktop" de Windows 8, vu que celui-ci interdit les plugins, on l'a mis en 64bit par defaut.

C'est toute la partie 'experience utilisateur' : si les plugins des gens ne marchent plus, ils pesteront et reviendront a la version 32bit de toute facon. Resultat on met la version 64bit, on pousse les editeurs de plugins importants a passer en 64bits, et une fois que la masse critique sera atteinte, on bascule a 64bit par defaut.

Oui mais bon, si moi je fais dans le subjectif, on sait tous comment ca va finir …

Le port ARM etait la depuis Vista, époque ou Xbox etait deja la… : x86, Itanium, amd64, ARM, PPC

Il est tout aussi multi-architecture que Linux, faut juste voir la difference qui est que MS ne sort que ce qui est rentable, tout comme Redhat ne va pas faire une distrib Redhat pour des archis exotiques.

Pour IE, si tu regardes bien, tu as IE 32 ET 64bits, les 2 sont donnes pour la simple raison que plein de plugins sont 32bits uniquement, mais je te recommandes perso d'utiliser la version 64bit qui est plus sure.

Server 2012 abandonne Itanium tout simplement car on etait arrive a un moment ou il y avait quasiment plus de machines Itanium chez MS qu'ailleurs sur la planete, autant dire que le developpement n'en valait plus la peine, l'arret n'a rien de technique.

cmd.exe c'est 32bit et ca va le rester tout simplement car il ne pourrait pas tourner autrement.

Du tout, tu fais tourner dans les navigateurs le resultat d'une compilation par TypeScript.

Et vu que le compilateur est lui-meme ecrit en JavaScript,ben tu sais que tant que ton code final JavaScript a une chance d'etre execute, il peut etre compile, pas de probleme de disponibilite du compilateur.

Une depeche pour 4 produits majeurs du concurrent d'en face, qui ont a peu pres tous un effet sur le monde Linux/libre.

Si tu as du mal a voir le lien entre Windows 8/Server et un impact sur le monde du libre après toutes ces annees de presence sur ce site, tu as un probleme bcp plus serieux que cette depeche…

Technicien de Surface <-> balayer …

Le texte etait pourtant clair :

la longue liste de CPU qui sont, ou ont été, supportés au fil des années

Pour ce qui est du code commun, il y a encore plein de code qui est commun, mais evidemment plein de code qui a change et ete ajoute aussi. Par contre l'architecture a tres peu change elle (stacks de drivers, object/memory/… managers separes, HAL, etc… sont toujours la)

Quand tu regardes WP7, base sur WinCE et ses limitations, c'etait clairement une phase 'transitoire' pour des telephones ressemblant de plus en plus a des ordinateurs. Ca veut pas dire que le systeme marchait pas bien, il marche tres bien, mais pour le future il y avait un plafond.

Pas compris, c'est quoi le probleme ?