Discussion :

[Mac LAK]

De toutes façons, il est certes extrêmement probable que Win32 "meure" au profit de Win64, tout comme Win16 a cédé devant Win32, et comme Win64 cèdera un jour devant un Win128... Ce qu'il faut aussi relativiser, car je rappelle qu'on peut encore faire tourner des applications Win16 sur nos machines actuelles. Simplement, et c'est logique, il n'y a plus de support ni d'évolutions de Win16, et ça tourne en plus dans un contexte virtuel... Ce qui n'a pas beaucoup d'importance : vu la différence d'âge et de puissance du matériel entre l'époque Win16 et l'époque Win32, on a quand même des applications Win16 qui tournent, au final, bien plus vite qu'à l'époque sur leur matériel de l'époque.

Mais la mort du natif ??? Impossible : il y aura toujours des domaines où l'on veut la puissance maximale disponible, et ceci malgré le coût supplémentaire engendré par un développement plus pointu. En vrac, il y a les applications massivement basées sur le calcul numérique (type MatLab ou 3DSMax), les jeux vidéos (plus de puissance = plus d'effets = un pain dans la tête du concurrent "moins beau" et/ou avec une moins bonne IA), les drivers (une couche basse mauvaise = un haut niveau mauvais), et j'en passe.

Il ne faut pas oublier que le coût de développement est amorti sur le nombre de ventes, et qu'un surcoût lié à un programme plus long à écrire est souvent assez vite dilué sur les ventes totales... Alors que le coût lié à l'achat d'une machine très nettement plus puissante est répercuté directement sur l'utilisateur, qui forcément est moins enclin à utiliser un logiciel s'il doit se taper une addition de deux ou trois briques pour s'acheter le matériel capable de le faire tourner dans des conditions décentes. Il est par contre nettement moins réticent à payer 10% de plus son logiciel s'il lui offre un confort d'utilisation nettement supérieur à ce qu'il possédait auparavant (ce qui inclus l'amélioration de l'ergonomie comme l'amélioration des performances, bien sûr, les deux coûtant du temps CPU et des ressources).

De plus, le code natif est nécessaire également pour montrer les performances brutes du matériel : si un éditeur comme Microsoft "plante" son fondeur favori (Intel) en l'empêchant de montrer la supériorité de son matériel, il y a fort à parier que des armées d'avocats vont s'enrichir de façon indécente sur les divers procès qui en découleront. MS a tout intérêt à montrer qu'ils peuvent offrir le plein accès à la puissance des machines, et Intel tout intérêt à monter en puissance également pour permettre aux éditeurs comme MS d'améliorer leurs produits. Les deux s'entraînent mutuellement, et provoquent des ventes, donc des bénéfices, et c'est quand même le but final de toute société commerciale.

Pour ceux qui n'auraient pas compris, la sortie de Windows 7 (qui est donc, en substance, un simple Vista optimisé avec des améliorations générales d'ergonomie) devrait bien faire comprendre que la course à la puissance est loin d'être terminée. Les langages managés ont beau avoir fortement amélioré leurs performances, ils restent quand même nettement en dessous des langages natifs en ce qui concerne les perfs brutes. Il n'y a qu'en temps de développement et/ou en portabilité qu'ils gagnent, et ce n'est pas toujours un critère fondamental dans un projet, loin de là.

[Melem]

De toutes façons, il est certes extrêmement probable que Win32 "meure" au profit de Win64, tout comme Win16 a cédé devant Win32, et comme Win64 cèdera un jour devant un Win128... Ce qu'il faut aussi relativiser, car je rappelle qu'on peut encore faire tourner des applications Win16 sur nos machines actuelles. Simplement, et c'est logique, il n'y a plus de support ni d'évolutions de Win16, et ça tourne en plus dans un contexte virtuel... Ce qui n'a pas beaucoup d'importance : vu la différence d'âge et de puissance du matériel entre l'époque Win16 et l'époque Win32, on a quand même des applications Win16 qui tournent, au final, bien plus vite qu'à l'époque sur leur matériel de l'époque.

Oui mais en fait Win32 est le nom officiel de l'actuelle API Windows. Le 32 ne signifie pas que c'est l'API des éditions 32 bits mais : des éditions 32 bits et plus (c'est-à-dires pour les plateformes Win32, Win64, etc.). C'est vrai qu'avoir une API de même nom qu'une plateforme n'est pas très top, mais c'est un peu comme Java qui désigne à la fois un langage de programmation, une plateforme d'exécution et une île de l'Indonésie .

[Mac LAK]

Oui mais en fait Win32 est le nom officiel de l'actuelle API Windows. Le 32 ne signifie pas que c'est l'API des éditions 32 bits mais : des éditions 32 bits et plus (c'est-à-dires pour les plateformes Win32, Win64, etc.). C'est vrai qu'avoir une API de même nom qu'une plateforme n'est pas très top, mais c'est un peu comme Java qui désigne à la fois un langage de programmation, une plateforme d'exécution et une île de l'Indonésie .

Tout à fait, mais le "32" en question est, comme tu le dis, source de confusion... Pour ma part, je considère toujours ça comme "API native Windows, version 32 bits".

Donc, je reformule : si par "mort de Win32" on veut dire "mort de la version 32 bits de l'API", je dis "oui, bien évidemment" au profit de la version 64 bits.
Et je dis aussi que jusqu'à présent, MS a toujours tenté de conserver au maximum possible les anciennes API fonctionnelles, même s'ils ne les font plus évoluer bien sûr. Pas même sur les corrections de bugs "connus", car cela pourrait casser la compatibilité avec des programmes qui se basaient sur ce bug et/ou le contournaient. Il est donc fort probable qu'on l'aie à disposition pendant encore un bon moment.

Si, par contre, on veut dire par là "mort d'une interface native d'accès au système d'exploitation", je dis clairement "c'est pas demain la veille" : il faudrait pour ça des processeurs capables d'interpréter du bytecode, et dans un tel cas, l'interface bytecode devient l'interface native => il existera TOUJOURS une interface native sur l'OS, c'est totalement impossible de faire autrement à moins de faire une usine à gaz à base de co-noyaux... Et même là, il faudra bien une interface native, ne serait-ce que pour les drivers.

[moldavi]

En matière d'évolution c'est déjà fini, maintenant ce qu'on peut redouter c'est la fin de la compatibilité, mais là il y a encore de la marge, sauf si Microsoft veut vraiment se tirer une balle dans les deux genoux.

Le gros problème du développement Windows c'est que Microsoft a droit de vie et de mort sur les technos.

Or, sur un coup de tête suicidaire que je ne m'explique pas, Microsoft a décidé que Win32, sa plus grande réussite commerciale, était à jeter aux oubliettes.

Du coup le code natif sous Windows est condamné à moyen terme.
Et aujourd'hui la plateforme pour le développement natif c'est Linux.

Bonjour.

J'ai demandé des sources à ce sujet et rien.

Par contre, j'ai une source qui date de 2009 et qui explique le contraire (enfin c'est mon interprétation). A vous de commenter...

http://www.microsoft.com/france/visi...4-7529a3267a1b

...

"Le plus gros client en C++ natif de microsoft, c'est... Microsoft (xp, vista, seven, office)."