Qualcomm tenait ce soir une conférence pour présenter l’arrivée des premiers appareils sous Windows 10 dotés d’une puce ARM. Deux références ont été annoncées aujourd’hui : Asus NovaGO et HP Envy x2. D’autres devraient être annoncées dès l’année prochaine, et probablement sous le Snapdragon 845 officialisé lui-aussi aujourd’hui. L’arrivée des premiers PC « Always Connected » Après ...
La rigueur qui permet par exemple de ne pas mélanger tous les sujets en permanence au point de ne plus savoir de quoi on parle : il est question au départ de l'émulation des d'un type de CPU (x86) pour tourner sur un autre type de CPU (ARM), ce qui nécessite la traduction à la volée des intructions binaires x86 en instructions binaires ARM. Il ne se passe rien de tel quand un exécutable x86 32 bits tourne dans un Windows x86 64 bits : les CPU x86_64 sont compatibles avec le jeu d'instruction x86 32 bits, donc il n'y a aucune traduction des instructions binaire à faire, et l'émulation 32 bits dans un Windows 64 bits n'a strictement rien à voir avec le type d'émulation dont on parlait auparavant dans cette "discussion".
Car tu vas encore dire que c'est du pinaillage, mais "émulation" ça ne dit pas grand chose tant qu'on ne précise pas de quel type d'émulation on parle : émulation matérielle ? Emulation logicielle ? Emulation d'un matériel ? Emulation d'un environnement logiciel ? Autre ? Tout ça ce n'est pas la même chose.
Je passe sur le reste de tes attaques personnelles, qui constituent les 3/4 de ton post.
"Et non, en aucun cas ce n'est de l'émulation"
On 64-bit Windows, 32-bit programs run in an emulation layer, and if you don’t like that, then don’t use the emulator"
>>> https://blogs.msdn.microsoft.com/oldnewthing/20081222-00/?p=19763
WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows. WOW64 is provided with the operating system and does not have to be explicitly enabled
>>> https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa384249(v=vs.85).aspx
Mais non, c'est pas de l'emulation, dit il...
Microsoft parle juste de la reproduction des fourmis...
T'es carrément incroyable comme gars !
C'est bien simple, pour avoir raison, tu déformes tout, tu prends un mot que tu détournes à ta sauce, tu prends limite une faute de frappe et surtout des fautes de fainéantise (on dit pas x64 mais x86_64, nananère...), c'est pathétique, tu cherches le moindre petit trou de souris pour t'y engouffrer...
On dit pas une bagnole, on dit une caisse, c'est ça ?
3 + 2, ça fait 5
Non, c'est 4 + 1 qui fait 5, tu racontes des conneries
Ok, fin de débat, ... ça tourne en rond et ca frise le ridicule et l’école maternelle !!!
Dans le genre de jouer sur les mots, tu es un cador, un champion du monde, un prince, The king !
Dans le genre de prendre des mots et les tourner à ta sauce, tu es the best...
Ta réputation de pinailleur et de chercheur de petite bête n'est plus à faire sur ce site... tous ici le confirment et même moi en tant que nouveau venu
A t’écouter, à lire tes remarques, tes reprises, tes pinaillerie, tu es médecin, chercheur, informaticien, avocat, ... DIEU
Faudrait que tu te remette un chouille en question l'ami, ici, t'es pas the king, the best, t'es rien, alors inutile de la ramener facon pinaillerie sur chacun des commentaires des utilisateurs du site... Tu fatigues tout le monde et faire croire que la science, c'est toi, il n'y a que toi qui y croit
Au fait, Pinailleur n'est pas une insulte, ni une attaque personnel, hein
Des fois que tu pinaillerais aussi la dessus AUSSI
-----------------------------------------------------
PINAILLEUR, -EUSE, adj. et subst.,
Avoir le souci exagéré des détails, de la précision; argumenter sans cesse de façon souvent mesquine. Synon. chicaner, chinoiser (fam.), chipoter (fam.), ergoter, subtiliser, chercher la petite bête (fam.), couper les cheveux en quatre (fam.)...
----------------------------------------------------------------
"Entre le kernel et les dll systemes, il y a moultes couches logiciels, à commencer par l’émulation x86/arm en elle même, les lib d’émulation, le NTDLL réécrit, etc...etc..."
Pour pouvoir faire tourner des logiciels x86 sans les recompiler, oui, évidemment il faut une couche logicielle supplémentaire d'émulation, ça va de soi. Mais la question de départ ce n'était pas ça. Pour faire tourner un logiciel recompilé pour ARM il n'y a pas besoin de tout ce bazar. (et non NTDLL n'est pas "réécrit", mais simplement recompilé).
"Et non, même sous x86 sans émulation, il n'y a pas "rien" entre les dll system et le kernel,"
Si, bien sûr, il n'y a rien (oui il y a la NTDLL, mais qui est juste une DLL système un peu particulière; là c'est toi qui joue sur les mots).
"Regarde juste le bordel que fait Windows pour émuler le x86/x64 sur la même plateforme, imagine sur une architecture differente...
Ne pinaille pas la dessus aussi, il s'agit aussi d’émulation"
C'est x86_64, pas x64... Et non, en aucun cas ce n'est de l'émulation. Un CPU x86_64 est nativement compatible avec les instructions x86 tout court, il n'y a aucune émulation logicielle à faire (juste à signifier au CPU dans quel mode il faut qu'il se mette).
Oh la la et c'est moi qui mélange tout
Je reprend juste ça, pas le temps de relever le reste
Entre le kernel et les dll systemes, il y a moultes couches logiciels, à commencer par l’émulation x86/arm en elle même, les lib d’émulation, le NTDLL réécrit, etc...etc...
Et non, même sous x86 sans émulation, il n'y a pas "rien" entre les dll system et le kernel, il suffit comme dit plus bas de désassembler une dll pour en être définitivement convaincu
Regarde juste le bordel que fait Windows pour émuler le x86/x64 sur la même plateforme, imagine sur une architecture differente...
Ne pinaille pas la dessus aussi, il s'agit aussi d’émulation
Si ça, c'est rien, effectivement, on peut parler de la reproduction des papillons
Relever, pinailler, relever, pinailler, ...
"Bah des fois c'est pas mal de revenir aux fondamentaux"
mdr
Je n'ai pas dit le contraire, hein... Sauf que la proportion de code spécifique ets en principe assez faible dans les OS actuels (pour le noyau Linux ça doit être de l'ordre de 10%).
"C'est justement entre le Kernel de Windows (couche logiciel la plus basse avant le matériel) et les DLL systèmes X86 qu'il y a réécriture du code et EMULATION..."
??? Je crois que tu mélanges un peu tout, là...
"Le code entre les dll x86 et le kernel de windows n'est pas portable et il ne s'agit absolument pas de petites portions de codes !"
C'est quoi le "code entre le kernel et les DLL" ? Les DLL système sont juste au-dessus du kernel, il n'y a rien entre les deux il me semble. Et de manière générale, au-dessus du kernel tout le code est portable (sauf cas particuliers d'applis en assembleur, évidemment). On n'est plus dans les années 80/90 où les softs attaquaient directement le matériel.
"Oui et alors ?
Il y a eu des version totalement réécrites, c'est totalement différent"
Pas du tout, dans l'ensemble du code Windows (kernel et DLLs système) la proportion de code dépendant du matériel ne doit pas dépasser une poignée de %, et pour passer à une autre architecture il suffit de réécrire cette poignée de %.
"Le portage vers ARM, dont l'essentiel a été fait avant 2012 (Windows RT), a "simplement" consisté à adapter les morceaux de code spécifiques à l'architecture, et à compiler le tout pour la cible ARM."
"Très simpliste ton raccourcis...
Ca marche comment un avion ?
Oh, il y a des ailes et un moteur et ça vole..."
Bah des fois c'est pas mal de revenir aux fondamentaux.
je suis au contraire très courtois et respectueux, tu peux le vérifier sur chacun de mes commentaires et depuis le début de mon inscription sur ce site
Mais je te rappelle que tu a légèrement commencé en répétant souvent que "j’étais à coté de la plaque" alors que l'on ne sait pas bien compris
Je pense au contraire que l'on dit à peu prés la même chose, mais différemment, d’où notre désaccord.. comme souvent sur les forums...
1 + 1, ça fait 2
Et 3 - 1, ça fait 2 aussi... apres confirmation via un croquis
Coluche ne faisait pas mieux niveau blague
"J'ai fait du portage d'OS" MDR-PTDR
A qui tu veux faire croire ça
je pense au contraire que tu ne serais même pas capable de coder une simple fenetre en assembleur x86 et la convertir à la volée en assembleur arm...
Et après, ça vient parler d'assembleur, de compilateur, d'emulation, de noyau... la blague
Meme pas sur que tu saurais coder une simple fenêtre sous windows et en basic et compatible avec tout les os existants
J'attends...
On va faire simple : Le noyau est adapté à la nouvelle architecture (mais pas complètement réécrit) et tout le reste (DLL comprises) est conservé et recompilé pour ARM.
J'ai fait du portage d'OS, porter Linux sur une nouvelle architecture est faisable en quelques jours. Réécrire le noyau prendrait une décennie.
>>>
>>>
"Entre le kernel et les dll systems, il y a réécriture complète du code et émulation"
"C'est justement entre le Kernel de Windows (couche logiciel la plus basse avant le matériel) et les DLL systèmes X86 qu'il y a réécriture du code et EMULATION"
<<<
<<<
Et c'est moi qui raconte des conneries
Tu vois, moi, j'ai pas été obligé d'aller chercher des croquis sur le net pour valider mes réponses, tu le fait à ma place et tu valides mes réponses, merci
Tous ce qu'il y a dans ton croquis, je le dit mot pour mot depuis le début...
Je suis ptdr mort de rire
La question que je me pose, c'est pas quelle pirouette tu va me dire le contraire...
Blague à part, si tu veux causer émulation, compilation, assembleur, x86, arm, commence par désassembler une dll de Windows ou même les premières instructions du kernel pour voir à quoi ça ressemble et après on parle technique
thanks bro !
(comme quoi.., faire simple quand c'est compliqué, c'est plus dur !!!)
On ne parle pas d'émulation au niveau du noyau, l'émulation pour les logiciels x86 est effectuée via un service s'exécutant sur le noyau de Windows (dans les couches au dessus, abstraites du matériel). Il n'y a pas d'émulation dans le noyau Windows en lui-même car il s'exécute nativement sur ARM.
Voilà l'illustration présentée par Microsoft lors de la présentation de Windows 10 pour ARM (disponible en grande ici) :
On voit bien, de bas en haut (en remontant donc dans les couches d'abstraction) :
- Le matériel (hardware)
- Le noyau (kernel) + les pilotes (drivers)
- À gauche, les applications compatibles s'exécutant nativement.
- À droite, les applications x86 s'exécutant sur un émulateur x86->ARM, appelé WoW (Windows on Windows). Cet émulateur est déjà utilisé sur noc PC pour exécuter les applications x86 sur processeur x64.
Il n'y a pas d'émulation au niveau du noyau, tout est en natif.
Et je me répète, il n'y a qu'une toute petite partie du noyau qui est réécrite pour le changement de l'architecture cible pour un OS. C'est le principe de l'abstraction et c'est pour justement ne pas avoir à tout réécrire.
On parle d’émulation de logiciels x86 sur processeur Arm !
On peut parler aussi de la reproduction des papillons si tu y vois un rapport avec le sujet ?
Entre le kernel et les dll systems, il y a réécriture complète du code et émulation
Il n'y a pas de compilateur magique pour faire ça
Le reste est portable, oui, je ne dit pas le contraire
Mais dire qu'il n'y a que des petites portions de code à refaire, finger in the nose, non
C'est un travail énorme et ça a du mobiliser une armée d’ingénieurs de Microsoft et Qualcom
Il y a du code qui n'est pas portable et qui est écrit spécifiquement pour le x86 et heureusement !
C'est justement entre le Kernel de Windows (couche logiciel la plus basse avant le matériel) et les DLL systèmes X86 qu'il y a réécriture du code et EMULATION...
Le code entre les dll x86 et le kernel de windows n'est pas portable et il ne s'agit absolument pas de petites portions de codes !
"Le Windows actuel descend de Windows NT, et dans les années 90 il y a eu des versions pour les CPU DEC Alpha et PowerPC"
Oui et alors ?
Il y a eu des version totalement réécrites, c'est totalement différent
"Le portage vers ARM, dont l'essentiel a été fait avant 2012 (Windows RT), a "simplement" consisté à adapter les morceaux de code spécifiques à l'architecture, et à compiler le tout pour la cible ARM."
Très simpliste ton raccourcis...
Ca marche comment un avion ?
Oh, il y a des ailes et un moteur et ça vole...
Les OS généralistes modernes -dont Windows- sont écrits de façon "portable", c'est à dire dans des langages de haut niveau (C ou autre) en faisant autant que possible abstraction du matériel sous-jacent. Il y a bien sûr quand même des portions de code qui sont spécifiques à l'architecture, qui peuvent être soit en langage de haut niveau, soit en assembleur quand on veut optimiser les performances.
Le Windows actuel descend de Windows NT, et dans les années 90 il y a eu des versions pour les CPU DEC Alpha et PowerPC. Donc non, Windows n'était pas prévu au départ pour ne tourner que sur du x86.
Le portage vers ARM, dont l'essentiel a été fait avant 2012 (Windows RT), a "simplement" consisté à adapter les morceaux de code spécifiques à l'architecture, et à compiler le tout pour la cible ARM.
La difficulté avec ARM c'est que contrairement à la famille x86 qui est très homogène, les différents CPU ARM ne sont pas si compatibles que ça entre eux : un portage pour un Snapdragon S835 ne fonctionnera pas forcément avec un Exynos, un Cortex, etc... D'ailleurs dans le noyau Linux, de mémoire la proportion de code spécifique ARM est de mémoire 5 ou 10 fois plus importante que la proportion de code spécifique x86.
Sinon, comme je l'ai écrit, on ne serait pas prêt de voir arriver Windows pour ARM...
Pour reprendre l'exemple du kernel Linux que j'ai mis en lien plus haut (car c'est un bon exemple), les parties du code source spécifiques à l'architecture du processeur sont regroupées dans le répertoire "arch/". Tout le reste du code source n'est pas dépendant de l'architecture du processeur et n'a donc pas besoin d'être réécrit. Et ça ne serait pas possible de tout réécrire, ça prendrait beaucoup trop de temps !
Voici une petite illustration, il s'agit là de l'arborescence des fichiers sources du kernel Linux :
Le code source spécifique à l'architecture du processeur ne représente qu'une petite partie du code source du noyau de l'OS.
(faut pas confondre logiciels et OS)
Windows étant prévue à la base pour tourner que sur du x86, il colle au plus près du processeur cible(x86) et je parle des couches logiciels "au dessus" des dll
Les couches "en dessous" étant totalement réécrites pour le processeur cible (arm)
Donc, non, il n'y a pas de moulinette capable d'effectuer cette prouesse technique, passer de x86 à Arm sans mettre les mains dans le cambouis
Bah c'est un peu le boulot du compilateur après-tout. Produire du code machine (Assembleur) à partir du code "haut-niveau" (C, C++, ...), pour une architecture cible (que ce soit x86-64, ARM ou autre).
Après, dans le cas du portage d'un OS d'une architecture à une autre, il faut adapter le code bas niveau spécifique au processeur. Mais ils ont clairement pas réécrit tout l'OS pour l'architecture ARM. Si c'était le cas, il ne serait pas prêt d'arriver...
J'ai ajouté quelques liens Wikipédia pour les intéressés. Mais le plus important à retenir c'est ce passage là dans l'article sur le Langage de haut niveau :
Pour les encore plus curieux, vous pouvez trouver les différentes architectures supportées par Linux (à défaut d'avoir accès au code source de Windows) dans le code source de son Kernel sur le site de FreeElectrons. C'est là qu'est regroupé tout le code spécifique à l'architecture du processeur ciblé.
Il existerait un compilateur capable d’effectuer cette prouesse technique
Faut pas confondre compilation, développement et émulation...
Après, pour les programmes tiers, Microsoft n'a pas leur code source, c'est aux développeurs de proposer une version compilée pour ARM.
Si c'est le cas j'aimerais voir des tests pour voir si on garde bien le confort d'un portable traditionnel.
Donc avec un SD808 on sait que non depuis longtemps.
Du côté de l'autonomie annoncée, ça me paraît crédible. À voir les tests côté performances maintenant, si c'est suffisamment fluide à l'utilisation.
Je pense au contraire que c'est clairement l'avenir du PC portable. Je pense que dans 5 ans, on ne trouvera pratiquement plus que des PC portables sous ARM.
Finalement, le seul avantage restant des processeurs x86, c'est la puissance. C'est bien pour un PC de bureau mais pas nécessaire pour un potable.
...
Un appareil avec micro et sortie son
...
Peut-être aussi avec un petit écran tactil intégré
...
On peut même imaginer recevoir des notifications dessus, des sms, ..
Vous croyez que je devrais déposer un brevet pour un tel appareil ? On pourrait l'appeler Smartphone !
(Mauvaise) blague à part, je suis curieux de voir les futurs test de ces PC.
Apres utiliser le meme iso, franchement aucune idée. (on peux supposer que oui)
https://www.boulanger.com/c/pc-hybride?numPage=2&sorting_price=desc
- des pc légers/autonomes plus abordables (lorsque le 835 aura vieilli surement)
- des form factors plus petits (courrier ? compute sticks "mini" ?)
- du haut de gamme hybride ? (arm pour le always on et l'autonomie, du x86 pour la patate)
- dont des machines encore plus modulaires (un nouveau SurfaceBook avec arm dans la tablette et x86 dans la "performance base" ?)
Et on en arrivera à pouvoir vraiment imaginer utiliser son smartphone comme pc, grâce à un dock puissant.
Pour les autres pur players, ils ont obligation de se situer en aval et de proposer les fameux produits de ruptures...
Si le produit correspond à une évolution positive, ergonomique de l'usage et que les mentalités sont prêtes .... alors le produit connaitra un succès .... et l'on changera de form factor ....
L'autonomie bouffée par des OS gourmands en ressources semble en partie résolue, en attendant la prochaine génération de batterie .... voilà déjà un verrou de sauté ... il en reste quelques uns ... mais ça semble cohérent en terme de positionnement de Ms ...
A la sortie de W8 c'était "pas de soucis on aura des app universelles ça va se remplir".
Puis W10 "oui avec les UWP le store mobile va exploser"
Là je doute vraiment que les PWA se démocratisent avant plusieurs années. Et les sites que j'ai vu en AMP jusqu'à présent sont là d'être agréable à l'œil.
Les problèmes restent les mêmes.
Je rajoute que l'autonomie de 20h est là car grosse batterie avec.
Sur un device type phablette je pense que ce ne sera pas la même chose. W10 reste plus gourmand qu'un os mobile.
Tout le monde parle du manque de puissance des processeurs ARM...
1. Quand je vois certaines apps qui tournent sur certains téléphones qui n'ont aucun mal à faire ce fait une app desktop, je me dis au fond, a t'on vraiment besoin de puissance brute pour des usages types : Navigateur, Windows store apps et quelques application desktop au quotidien ??? Ce qui correspondra a l'usage de beaucoup de personnes qui ne n'auront pas besoin de toute la puissance que peut offrir une plateforme x86/x64, d'une recherchent une meilleure autonomie et de la légèreté
2. Qui a déjà testé ce genre de config et sait réellement nous dire que c'est bien, bof ou nul pour le moment?
Oui mais à côté de ça :
- Un bon écran AMOLED comme celui du Galaxy S8 coûte plus cher à produire que les vulgaires écrans IPS de nos PCs portables.
- Les constructeurs de smartphones investissent énormément pour proposer des appareils photos toujours plus performants d'une génération à l'autre. Un bon capteur n'est déjà pas donné, mais c'est le budget R&D derrière qui explose puisqu'il faut bien traiter les images derrière. A capteur équivalent (souvent fourni par Sony), un S8/G6/U11 sortira de bien plus belles photos que le Xperia HDG en concurrence. Ce coût n'existe pas sur PC.
- Plus on miniaturise un appareil, plus les composants sont coûteux (RAM PC moins coûteuse que RAM Smartphone car tout est normé et surtout bien moins miniaturisé) et plus il y a du travail R&D derrière (agencement des composants pour éviter la chauffe etc...).
Et malgré ça, ces constructeurs margent beaucoup. Certains arrivent à proposer des configurations à base de S835 bien moins chers (Oneplus notamment, qui propose son -très bon- smartphone entre 500 et 600€ selon la configuration).
Franchement, 800€, et comme tu le dis on ne connait pas encore les prix Français, c'est bien trop. Une configuration ARM à base de S835/8Go RAM/256Go SSD à 600€ bouleverserait le marché. Mais serait-ce dans l'intérêt de Microsoft et des OEMs de tirer les prix vers le bas ? Pas sûr... Il n'y a qu'à voir les divers Ultrabook HDG ou le Surface Book. Des machines qui margent autant que les Macbook (plus pour le Surface Book...) et qui ne valent pas du tout leur prix. Ils s'en mettent tous plein les poches et ils tireront sur la corde encore quelques temps...
Là tu rêves totalement, il n'y a pas un smartphone dans ces eaux là avec une telle quantité de RAM et de stockage. Ce sont des 2 en 1 avec une connectiques plus étendue que n'importe quel smartphone, un clavier, etc.
L'un dans l'autre, un SD835 avec 4Go de RAM et 64Go de stockage au prix de 600$ est cohérent avec le prix d'un smartphone "équivalent".
Maintenant, si je trouve le prix cohérent, ça ne veut pas dire que je ne trouve pas celui-ci élevé par rapport à un portable classique. Il faudrait voir si les promesses sont respectées et qu'elles apportent la plus-value qui justifierait de choisir l'un de ces appareils plutôt qu'un laptop.
- le PC d'ASUS est le premier du genre et si les concurrents se mettent à investir dans ce secteur, les prix vont diminuer sans aucun doute
- ce type d'appareils n'est pas à voir comme de l'entrée de gamme sous Windows mais plus comme un appareil d'un nouveau genre, très endurant, ultra connecté, tout en proposant des fonctionnalités similaires à un PC.
- beaucoup de smartphones avec processeur ARM proposent beaucoup moins d'espace de stockage et de mémoire vive pour un tarif équivalent
http://www.cnetfrance.fr/produits/lenovo-miix-2-39802105.htm
Je ne pense pas que ce soit très haut de gamme.
Windows a été porté / compilé pour ARM, mais ça existe déjà depuis 2012 avec Windows RT. Et en plus il y a un émulateur x86 pour les applis x86
Operation System
Windows 10 S
(free upgrade to Windows 10 Pro)
Une donnée intéressante pour la comparaison serait celle du ratio puissance par Watt consommée.
Maintenant c est sûr que ce soit le vrai Photoshop ou autocad qui tournera sur un pc en w10 s ?
Mais en veille, cela ne veut pas dire grand chose, quoique je mets toujours mes PCs en veille.
Maintenant en W10 pro est ce que l autonomie sera la même?perso j ai un doute
https://www.asus.com/us/2-in-1-PCs/ASUS-NovaGo-TP370QL/Tech-Specs/
Donc c'est encore un truc trompeur pour appâter le client.
Perso, je voudrais savoir s'il y a une puce gps (réputée gourmande en énergie sur les tablettes Windows). Si la réponse est non, je ne vois absolument pas l'intérêt de ces PC.
C'est combien, abusif ?
Note: Ah si y a ptet une autre raison, c'est qu'il me semble que la license W10S est gratos. Nan ?
Mais pour le coup ça n'est pas une vraie veille au sens PC, où seule la RAM est alimentée. Ici le CPU reste alimenté et continue à faire tourner les tâches de fond.
L'utilisation du cloud est du domaine des applications que l'on utilise. Certaines (très peu) utilisent le cloud, les autres ne l'utilisent pas.
Ce n'est pas en lien avec le type de PC ou son architecture.
Bon si ca peut faire venir dans un premier temps les devs puis diminuer la taille pour en faire un téléphone ce sera bien
Parce que Windows 10 S n'est pas une version spécifique de Windows 10 ?
il y a des batteries qui ont une durée de veille aussi longue ???
J'ai bien compris que l'avantage principal est l'autonomie. Là il n'y a pas photo. Mais cela sert-il vraiment ? Qui va se balader tout le temps avec un PC de plus de 10 pouces ? En voyage, au travail, ok. Mais on dispose de prises où on veut ou bien d'une petite batterie externe.
Et si en plus, c'est Windows S qui semble l'emporter, où est l'intérêt ?
Sans parler du prix évidemment, mais on peut espérer que ça évolue vers le bas.
Et enfin, y a-t-il une puce GPS ? Pour moi, ce serait la principale "avancée" pour un PC. Car aujourd'hui, il est quasi impossible de trouver une tablette ou un hybride avec une puce Gps. Sauf je crois des tablettes Samsung hors de prix.