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, …)
[^] # Re: Architecture
Posté par pasBill pasGates . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 4.
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, …)