Question

Quelqu'un a-t-il entendu parler du fait que Microsoft [ne] prend pas en charge COM dans les futures versions de Windows?

J'imagine que les ingénieurs de Microsoft sont pris au dépourvu (même s'ils préféreraient uniquement développer et prendre en charge le framework .NET) simplement en raison de l'énorme réaction que leur vaste clientèle aurait à subir. Il doit y avoir littéralement des milliards de lignes de produits basés sur COM dans la nature. Je sais que je suis pas impatient d’être entraîné dans une migration de masse simplement parce qu’un astronaute dépassant les objectifs de smarty-pants doit prouver qu’il est le plus grand… ils prennent juste la boxe?).

Je pense que je suis juste paranoïaque, mais quelqu'un peut-il fournir des liens d'autorité (Google ne trouve pas grand chose)? Idéalement, un livre blanc de Microsoft sur le thème "Les séjours COM à Vienne, ou bien!" réglerait mes nerfs grandement.

Était-ce utile?

La solution

La raison pour laquelle ils l'ont appelé .NET est que COM3 a été pris comme nom de port série .NET est le nouveau COM. De .NET Runtime du langage courant commun libéré :

  

Le nom passe de COM3 à COR à COM + 2.0 ... à NGWS et enfin à .NET.

Si l'assembly principal s'appelle mscorlib, c'est parce qu'il correspond à Bibliothèque d'exécution des objets communs Microsoft .

Autres conseils

COM est toujours LA technologie de communication inter-processus. Regardez comment vous pouvez contrôler Word, Excel, etc. à partir d'une autre application. Il n’est pas possible que .Net puisse remplacer cela.

COM et .Net répondent à des besoins différents. Tant qu'il y aura du code natif, il faudra un standard de composant binaire, c'est-à-dire COM. Même si le système d'exploitation était réécrit à partir de zéro (ce qu'il ne sera pas, il ne devrait pas l'être non plus), il s'agirait principalement de code natif pour des raisons telles que les performances et les versions. Vous auriez rapidement besoin d’inventer quelque chose comme COM, alors pourquoi ne pas garder celui qui a été testé et qui fonctionne?

Je sais qu’il est facile de penser que le monde Microsoft est désormais .NET uniquement, grâce au travail trop excellent que leur service marketing a accompli, mais Microsoft prend toujours en charge leurs anciennes données, ils n’ont pas vraiment le choix.

Regardez MFC, ils ont publié de nouveaux packages, et la RibbonBar ne fonctionne que sur MFC (car office y est développé). Bien sûr, ils commenceront à écrire de plus en plus de code .NET au fil du temps et de moins en moins de choses COM, mais ils le supporteront toujours.

Les fonctionnalités de développement COM dans Visual Studio resteront en place. Lorsqu'elles disparaîtront, vous savez qu'elles ne veulent plus que nous les utilisions.

J'ai lu une entrée de blog du chef de projet de Visual Studio où il a dit qu'ils avaient reçu beaucoup de plaintes de développeurs concernant l'accent mis sur C # récemment. Il a accepté et déclaré que la prochaine version de Visual Studio serait principalement axée sur le développement non géré en C ++.

Il n’existe aucune déclaration officielle selon laquelle la prise en charge de COM est supprimée des futures versions de Windows. il est largement utilisé par les internes du système d'exploitation. À part une réécriture complète du système d’exploitation (ce que je n’envisage pas de si tôt), il est prudent de présumer que COM sera là pendant un certain temps.

Je ne peux pas voir COM disparaître de si tôt car il y a une énorme quantité de code hérité basé sur COM. Pour la même raison, j'espère voir Win32 traîner dans un avenir prévisible. Personne ne se soucie de Windows en tant que telle, mais de son logiciel d’application.

Les codes COBOL sous S / 360, S / 370, S / 390, zSeries et C / unix restent très utilisés pour la même raison.

Donc, pour résumer:

COM restera parce que: 1. Cela fonctionne fondamentalement 2. Il gère la communication interprocessus, distincte de la communication intermachine. 3. .NET a beaucoup hérité de COM, mais pas de tout. 4. Même Microsoft lui-même compte toujours sur lui.

Et je pense qu’il ya encore des milliards de lignes de Fortran et de COBOL dans les systèmes de production d’aujourd’hui ... parce qu’elles fonctionnent fondamentalement.

Merci à tous pour vos réponses ... Mods, n'hésitez pas à nettoyer cette réponse au fil de la conversation, mais (à mon humble avis), ce site ferait bien de permettre aux affiches de remercier publiquement ceux qui prennent le temps de répondre.

Salut à tous. Keith.

scroll top