Discussion :

[Melem]

... je ne vois aucune raison pour que l'API "native" (je fais référence là à Win32) ne sera plus disponible dans le futur (vu qu'elle a toujours été publique jusqu'ici). Bien au contraire, elle s'enrichira avec les différentes versions que le système connaîtra. Win32 sera donc toujours au moins aussi bien maintenu que .NET.

Ce que tu dis est en contradiction avec le message d'origine. Je me demande si cette information est vérifiable. Sinon nous parlons un peu dans le vent.

Ce message qui dit que .NET sera bientôt la seule plateforme supportée ? Evidement, Microsoft n'a jamais dit cela ni même un truc qui ressemble un peu à ça. Certes, Win32 aussi est une encapsulation, mais ce n'est pas la même chose que .NET. Win32 encapsule seulement quelques routines du noyau. On passe donc d'un noyau tout neuf à Win32 en une seconde seulement. Avec .NET, il y a encore tout un tas de trucs à développer au dessus du noyau pour avoir un Framework opérationnel car il cache même le modèle de programmation natif de Windows alors que Win32 utilise ce même modèle. C'est pour ça que j'ai dit que, sauf par mauvaise foi de la part de Microsoft, Win32 existera et s'améliorera tant que Windows existera, ou du moins tant que Windows sera développé avec du code natif. Que .NET sera un jour remplacé par une meilleure technologie, ou tout simplement abandonnée, ça c'est possible (je veux dire faisable, pas probable). En effet, c'est .NET qui a besoin de Windows, pas l'inverse ...

[moldavi]

Bonjour.

La source n'est pas vérifiable, visiblement, d'ailleurs personne ici n'en a donné.

Pour répondre maintenant plus dans le sens ou 100% .net, c'est compromis, le framework n'implémente toujours pas toutes les fonctionnalités de Win32. D'où les pInvoke et autres méthodes pour pouvoir les utiliser. Un 100% .net, ça voudrait dire que la majorité des applications ne tourneraient pas sur Vista.
Et à moins de vouloir se tirer une balle dans le pied...

C'est comme les fabricants de processeur. Ils pourraient sortir des processeurs beaucoup plus performants depuis très longtemps. Mais aucun OS ne tourneraient dessus... Parce qu'il faudrait revoir toute la couche assembleur et un OS trop imbriqué dans cette couche (appel système) demanderait des années de développement.

J'ai l'impression que la source faisait peut-être référence à Microsoft Midori...

[Melem]

Tout d'abord, le débat ici c'est ".NET sera t-elle dans quelques années la seule plateforme supportée sous Windows ?". C'est-à-dire qu'il ne sera plus possible d'exécuter des applications non-managées sous Windows (sauf s'ils vont faire une machine virtuelle managée pour faire tourner les applications non-managées ). Qu'il n'y aura plus d'APIs non-managées. Tout sera en managé (ou pour être plus direct, en C# ).

Concernant les parts de marchés, cela ne vient pas vraiment de Win32 ou de .NET, mais des outils. C# ainsi que les autres langages qui le suivent fournissent généralement un environnement RAD aux programmeurs ce qui permet de développer beaucoup plus vite qu'avec un simple environnement de développement non-RAD comme Visual C++ et son kit de développement pour Windows (je ne parle pas de C++.NET). VB aussi a attiré beaucoup de monde, mais Microsoft continuait quand même de maintenir le PSDK (devenu actuellement le WSDK) et tout le monde sait qu'ils n'ont pas eu tort. Je dis donc que .NET sera le VB du futur (un peu bizarre comme comparaison quand même parce que je compare une plateforme à un langage, mais j'espère que vous me comprenez ...), et attirera beaucoup de programmeurs, mais certainement pas le Win32 du futur.

[randriano]

Il semble que Microsoft veut vraiment que DotNet soit l'unique plate-forme du futur dans le but de faciliter la tache des programmeurs: on aura plus à s'inquiéter des spécificités de la machine, on programmera en haut niveau
Faites une petite recherche sur Midori par ex pour comprendre leur projet
Donc dans le futur, les applications Win32/Win64 seront émulées sur le framework dotnet
Beaucoup de programmeurs VB furent mécontent du fait de l'abandon de Ms de ce langage pour un langage pratiquement différent: le VB.NET
Pour éviter alors un tel mécontentement plus tard, nous qui veulent que les WinXX restent s'engagent dès maintenant pour envoyer des pétitions à Ms (Je crois qu'il y a déjà de nombreux blogs sur ça actuellement)

[Mat.M]

Voilà qui devrait ,en théorie, couper court aux spéculations:

Microsoft is making a major commitment to make parallel
development accessible to a wide range of developers, whether
they are using native code or the .NET Framework. With Visual
Studio 2010 we are delivering:
• Visual Studio IDE support for Parallel development
• Native C++ libraries and compiler support
for Parallel applications
...
C++ Development
Visual Studio 2010 marks a major renovation of our C++ IDE
so that it not only supports emerging trends like parallel
computing, cloud and web services, but also provides a
first-class C++ development experience through an IDE that
scales to the large size of code bases that are typical of C++
sources. We’re also adding a significant focus on building great
experiences for navigating and understanding complex C++
source bases to enable developers to figure out the best places
to make source changes in their complex systems.
In Visual Studio 2010, the C++ project system has been converted
to MSBuild based system that enables developers to take
their existing C++ solutions that are currently sectioned to be
manageable and bring them into a single solution that provides
full IDE support for all the assets in the solution. With a full
compiler backing IntelliSense, and a true database-based symbol
system, this enables developers to work with large solutions,
thousands of files, and up to 4gB of symbol information.
Visual Studio 2010 provides a C++ IDE experience that includes
the return of the MFC Class Wizard, the ability to view large
source files through Source Outline, integrated quick searching
to find information without the confusion of the current “Find
In Files” method and an easily extensible IDE model through
the new Managed Extensibility Framework (MEF).
....
Windows 7 Development
In Visual Studio 2010, we’ve invested heavily in C++ to make
developing native Windows applications easier and more
productive. We are adding tools to assist developers in
building new Windows 7 applications and in making existing
native applications take advantage of new Windows features.
We’re including full library and header support for Windows 7,
significant updates to MFC to support Windows 7 UI elements
like the ribbon, live icons, search access and even support for
multi-touch enabled interfaces.

http://www.microsoft.com/visualstudi...0/default.mspx

J'ai été fort médisant enver VS2008 mais j'avoue développement parallèle c'est très séduisant

[Silverstone]

Donc dans le futur, les applications Win32/Win64 seront émulées sur le framework dotnet

Oui mais quel intérêt ? Ca ralentirait la rapidité d'exécution et ça serait compliqué à faire (à mon avis) ^^

En plus les Microsoft Softwares (logiciels de microsoft) ne sont pas programmer en .Net ^^

[Invité]

En plus les Microsoft Softwares (logiciels de microsoft) ne sont pas programmer en .Net ^^

SQL Server 2005 et 2008, si... Du moins en grande partie.

[Melem]

Il semble que Microsoft veut vraiment que DotNet soit l'unique plate-forme du futur ...

Références svp ...

Faites une petite recherche sur Midori par ex pour comprendre leur projet

Je ne sais pas quand toi tu as fait tes recherches mais Midori est tout sauf un projet de dernière date. Ses développements ont même commencé bien avant la sortie de Windows XP. De plus, Midori n'a jamais été annoncé par Microsoft (je m'en moque complètement de ce que les autres pensent) comme un projet de système d'exploitation qui va remplacer Windows, mais seulement un projet de recherche (on peut facilement vérifier ce que j'ai dit, sur des sites officiels, mais je n'ai pas le temps de les vérifier moi-même (désolé) ...). Son but est donc de permettre aux développeurs de MS de faire des recherches (expériences, etc.) sur les possibilités de la plateforme .NET afin de la faire, entre autres, mieux cohabiter avec Windows (et aussi pour fournir un meilleur framework, qui ne change pas toutes les semaines, etc.), pas pour remplacer ce dernier.

SQL Server 2005 et 2008, si... Du moins en grande partie.

Mais il faut avouer que seulement très peu de logiciels Microsoft sont programmés en .NET. Office, Visual Studio, Internet Explorer, etc. sont, au moins pour leur grande partie, écrits en C++ (non-managé).

[Mat.M]

SQL Server 2005 et 2008, si... Du moins en grande partie.

oui mais j'ai posé une question bien précise pourquoi Vista n'est pas 100% NET ?
Personne n'a répondu...

En plus les Microsoft Softwares (logiciels de microsoft) ne sont pas programmer en .Net ^^

C'est exact; les produits Ms-Office sont développés avec un framework interne

[Invité]

oui mais j'ai posé une question bien précise pourquoi Vista n'est pas 100% NET ?
Personne n'a répondu...

Probablement parce que le code managé n'est pas encore mûr pour développer des kernels. Je crois que le projet Singularity est une tentative d'OS en code managé.

Il y a aussi brokenwire.

[Yannick84]

SQL Server 2005 et 2008, si... Du moins en grande partie.

Source ?

Il me semblait avoir lu un article qui n'allait pas vraiment dans ce sens, expliquant meme que les dev avaient reimplemente un subset de l'API win32 pour obtenir de meilleures performances cote network. Reste a retrouver l'article en question, je vais regarder...

[Invité]

Tout d'abord bonjour et bienvenue sur le forum...

Source ?

L'obligation d'installer le Framework .NET 2.0 pour le faire tourner... La SQLCLR, ADO.NET.

Je suis preneur pour l'article

[Yannick84]

L'obligation d'installer le Framework .NET 2.0 pour le faire tourner... La SQLCLR, ADO.NET.

SQLCLR permet effectivement d'hoster le CLR dans SQL Server et d'executer du managed code mais ca s'arrete la (et cote implementation nous sommes deja dans le monde natif a ce stade). Quant a ADO.NET, il me semble que c'est integre dans la BCL et sans lien direct avec SQL Server, je me trompe ?

Donc de la a en deduire que SQL Server 2005 et 2008 sont en grande partie developpes en .NET comme tu le dis ... le raccourci me semble un peu rapide

Un article tres interessant sur SQLOS : http://blogs.msdn.com/slavao/articles/441058.aspx

Tu trouveras beaucoup d'autres d'articles sur le design de SQL Server sur le blog de l'auteur : http://blogs.msdn.com/slavao/ Tu verras, ca ne cause pas vraiment .NET

[Invité]

Un article tres interessant sur SQLOS : http://blogs.msdn.com/slavao/articles/441058.aspx

Tu trouveras beaucoup d'autres d'articles sur le design de SQL Server sur le blog de l'auteur : http://blogs.msdn.com/slavao/ Tu verras, ca ne cause pas vraiment .NET

Au temps pour moi donc...
Merci pour les liens

[Yannick84]

Pour en revenir au sujet principal, je suis assez rassure par les recentes annonces de Microsoft a l'attention des developpeurs Win32.

Nous avons deja eu droit a une amelioration consequente cote C++ et MFC avec le SP1 de Visual Studio 2008 et cela va continuer avec VS10 - le nouveau 6, dixit Microsoft ! Il y a eu une conference a la PDC sur le sujet dans laquelle Microsoft admet avoir delaisse les developpeurs MFC ces dernieres annees mais confirme sa volonte de desormais poursuivre le developpement (he oui, il y a beaucoup, beaucoup de developpeurs et surtout de code existant reposant sur les MFC).

Concernant l'API, elle continue a evoluer au rythme des nouvelles versions de Windows. C'est effectivement peu mediatise mais un simple coup d'oeil sur MSDN suffit pour voir bon nombre de fonctions modifiees / ajoutees avec Windows Vista. Cela va evidemment continuer avec Windows 7 (l'interface ribbon par exemple, accessible directement en Win32) et meme s'intensifier avec le developpement de nouvelles lib. Je pense en particulier a la lib native pour les Web Services, Direct2D, et tout ce qui est parallelisme (PPL et cie). Ce sont la d'importants developpements.

Bref, l'avenir nous est souriant

Quelques liens de conf interessantes a la PDC sur ces sujets :

Microsoft Visual C++: 10 Is the New 6 : http://channel9.msdn.com/pdc2008/TL13/

Microsoft Visual Studio: Building Applications with MFC : http://channel9.msdn.com/pdc2008/PC26/

Windows 7 Scenic Ribbon: The next generation user experience for presenting commands in Win32 applications. : http://channel9.msdn.com/pdc2008/PC14/

Parallel Programming for C++ Developers in the Next Version of Microsoft Visual Studio : http://channel9.msdn.com/pdc2008/TL25/

Windows 7: Introducing Direct2D and DirectWrite : http://channel9.msdn.com/pdc2008/PC18/

Windows 7: Web Services in Native Code : http://channel9.msdn.com/pdc2008/PC01/

Le blog de la team VC++ pour tout ce qui touche l'IDE et C++ 0x :
http://blogs.msdn.com/vcblog/

[Vincent Rogier]

Définitivement, je n'ai pas l'impression que le compilateur C est aujourd'hui encore un outils stratégique pour Microsoft.

C'est vrai et ca ne risque pas de changer puisque que MS, hormis en interne et pour les drivers, ne veut plus de développement "grand public" et professionnels en C ou meme C++.
Tout est concentré sur .NET et tous les moyens sont bons.

[Précision : ce post est en fait un extrait d'un de mes post dans une autre discussion du forum C qui a été copié ici par un modérateur C. Nulle intention de troll de ma part...]

[Melem]

Pas d'accord. Windows 7 qui est venue avec de nombreuses nouvelles APIs non managées, Managed DX jetée à la poubelle, les nombreuses nouveautés de MFC 2010, etc. sont autant de preuves que contrairement à ceux que la plupart des développeurs pensent, Win32 n'est pas prêt de disparaître. Comme je l'ai souvent répété, ce que nous affirmons au sujet de l'avenir de Win32 et .NET sont la plupart du temps des spéculations, des "paris", rarement de vrais communiqués venant de MS. MS maintient aussi bien Win32 que .NET (qui a d'ailleurs souvent besoin de Win32, voir le nombre P/Invoke qu'on peut trouver dans du code .NET ...). Chacun est libre de programmer pour sa plateforme préférée (sauf dans des cas très particuliers ou l'on est obligé pour une quelconque raison de programmer pour l'une ou pour l'autre). En interne et pour le développement de drivers par contre, c'est strictement réservé, comme tu l'as fait remarqué, au non managé (principalement au C).

[Vincent Rogier]

je n'ai jamais dit que win32 allait disparaitre

Win32/64 ne disparaitra jamais sur les OS Miscrosoft basé sur le noyau NT....

Ce que je disais dans mon post, initialement, dans la discussion originelle, c'est que Microsoft ne pousse plus du tout les gens à utiliser ses outils de déveveloppement non orientés .NET et met à disposition toute les nouveautés win32/64 au sein des technos .NET et prèfère que le commum des mortels des développeurs utilisent les wrappers .net autour de win32/64.

Merci de ne pas déformer mes propos à partir d'une citation tirée de son contexte !

[Melem]

Win32/64 ne disparaitra jamais sur les OS Miscrosoft basé sur le noyau NT....

Y compris sur les "OS" basés sur le noyau CE .

Ce que je disais dans mon post, initialement, dans la discussion originelle, c'est que Microsoft ne pousse plus du tout les gens à utiliser ses outils de déveveloppement non orientés .NET et met à disposition toute les nouveautés win32/64 au sein des technos .NET et prèfère que le commum des mortels des développeurs utilisent les wrappers .net autour de win32/64.

Merci de ne pas déformer mes propos à partir d'une citation tirée de son contexte !

Je n'ai pas déformé mais tu n'as pas aussi bien expliqué dans le post originel qui laisse un peu croire que MS a l'intention de laisser pourrir le "développement grand public et professionnel en C ou même C++" (autrement dit le développement sur Win32, avec ou sans MFC).

[Vincent Rogier]

Y compris sur les "OS" basés sur le noyau CE

Bien évidemment, puisque les spécifications initiales de CE, bien qu'être un OS complétement différent de NT, étaient, en autres, d'implémenter un sous ensemble de Win32, pour des raisons de compatibilité et de portage.

Je n'ai pas cité CE, car il reste plus que minoritaire en termes de plateforme cible comparés à NT.

Ma remarque était plutot de dire que les OS MS existant grand public seront toujours basés sur Win32 à la différences des prochains OS (a long termes) de MS qui seront issus de ses recherches et essais actuels sur les micro noyaux.

Et sinon, pour ceux qui crois bêtement que Win32 est mort que le prochain Windows sera tout .net, la premier tentative de diffusion restreinte d'un premier os non win32 de chez MS ne sera pas dans les bacs avant 10 à 15 ans au plus tot (dixit microsoft france)