Est-il toujours judicieux d’apprendre la programmation WinAPI de bas niveau ?[fermé]

StackOverflow https://stackoverflow.com/questions/5507

  •  08-06-2019
  •  | 
  •  

Question

Est-il logique, avec tout le bonheur géré par C#, de revenir à Windows de programmation de Petzold et d'essayer de produire du code avec WinAPI pur ?

Que peut-on en tirer ?N'est-il pas trop obsolète pour être utile ?

Était-ce utile?

La solution

Cette question est à la limite religieuse :) Mais je vais quand même donner mon avis.

Je vois l'intérêt d'apprendre l'API Win32.La plupart, sinon la totalité, des bibliothèques GUI (gérées ou non) entraînent des appels à l'API Win32.Même les bibliothèques les plus complètes ne couvrent pas 100 % de l'API, et il y a donc toujours des lacunes qui doivent être comblées par des appels directs à l'API ou par des appels P/P.Certains des noms des wrappers autour des appels d'API ont des noms similaires à ceux des appels d'API sous-jacents, mais ces noms ne sont pas exactement auto-documentés.Ainsi, comprendre l’API sous-jacente et la terminologie utilisée dans celle-ci aidera à comprendre les API wrapper et ce qu’elles font réellement.

De plus, si vous comprenez la nature des API sous-jacentes utilisées par les frameworks, vous ferez de meilleurs choix quant aux fonctionnalités de bibliothèque que vous devez utiliser dans un scénario donné.

Acclamations!

Autres conseils

Je suis resté au standard C/C++ pendant des années avant d'apprendre l'API Win32, et pour être tout à fait direct, la partie "apprentissage de l'API Win32" n'est pas la meilleure expérience technique de ma vie.

D’une part, l’API Win32 est plutôt cool.C'est comme une extension de l'API standard C (qui a besoin fopen quand tu peux avoir CreateFile.Mais je suppose qu'UNIX/Linux/WhateverOS ont les mêmes fonctions de gadget.Quoi qu'il en soit, sous Unix/Linux, ils ont le "Tout est un fichier".Sous Windows, ils ont le message "Tout est un...Fenêtre" (sans blague !Voir CreateWindow!).

D'un autre côté, il s'agit d'une API héritée.Vous aurez affaire à du C brut et à la folie du C brut.

  • C'est comme dire à sa structure sa propre taille pour traverser un void * pointeur vers une fonction Win32.
  • La messagerie peut également être assez déroutante :Le mélange d'objets C++ avec des fenêtres Win32 conduit à des exemples très intéressants de Poulet ou Oeuf problème (des moments drôles où tu écris une sorte de delete this ; dans une méthode de classe).
  • Devoir sous-classer un WinProc lorsque vous êtes plus familier avec l'héritage d'objets est décourageant et loin d'être optimal.
  • Et bien sûr, il y a la joie de "Pourquoi dans ce monde de fracturation hydraulique ont-ils fait cette chose de cette façon ??" des moments où vous frappez une fois de trop votre clavier avec la tête et rentrez chez vous avec des touches gravées sur le front, simplement parce que quelqu'un a trouvé plus logique d'écrire une API pour permettre de changer la couleur d'une "Fenêtre", et non en en changeant une de ses propriétés, mais en la demandant à sa fenêtre parent.
  • etc.

Dans la dernière main (trois mains ???), considérez que certaines personnes travaillant avec des API existantes utilisent elles-mêmes un style de code existant.Au moment où vous entendez "const c'est pour les nuls" ou "Je n'utilise pas d'espaces de noms car ils diminuent la vitesse d'exécution", ou encore mieux "Hé, qui a besoin de C++ ?Je code dans ma propre marque de C orienté objet !!!" (Sans blague...Dans un environnement professionnel, et le résultat est tout un spectacle...), vous ressentirez cette sorte d'effroi que seuls les condamnés ressentent devant le guillotine.

Donc...Dans l'ensemble, c'est un intéressant expérience.

Modifier

Après avoir relu ce post, je vois qu'il pourrait être perçu comme trop négatif.Ce n'est pas.

Il est parfois intéressant (et frustrant) de savoir comment les choses fonctionnent sous le capot.Vous l'aurez compris, malgré d'énormes (impossibles ?) contraintes, l'équipe API Win32 a fait un travail formidable pour être sûr que tout, de votre "ancien programme Win16" à votre "dernière application Win64 over-the-top", puisse fonctionner ensemble, dans le passé, maintenant et dans le futur.

La question est:Le veux-tu vraiment ?

Parce que passer des semaines à faire des choses qui pourraient être faites (et mieux) dans d'autres API de plus haut niveau et/ou orientées objet peut être assez démotivant (expérience réelle :3 semaines pour Win API, contre 4 heures dans trois autres langages et/ou bibliothèques).

Quoi qu'il en soit, vous trouverez le blog de Raymond Chen très intéressant en raison de son point de vue privilégié sur l'API Win et son évolution au fil des années :

https://blogs.msdn.microsoft.com/oldnewthing/

Absolument.Quand personne ne connaît le bas niveau, qui mettra à jour et écrira les langages de haut niveau ?De plus, lorsque vous comprenez les éléments de bas niveau, vous pouvez écrire du code plus efficace dans un langage de niveau supérieur et également déboguer plus efficacement.

Les API natives sont les « vraies » API du système d’exploitation.La bibliothèque .NET n'est (à quelques exceptions près) rien de plus qu'un emballage sophistiqué autour d'eux.Alors oui, je dirais que quiconque peut comprendre .NET dans toute sa complexité peut comprendre des choses relativement banales comme parler à l'API sans l'aide d'un intermédiaire.

Essayez simplement de faire une injection de DLL à partir du code managé.Cela ne peut pas être fait.Vous serez obligé d'écrire du code natif pour cela, pour des ajustements de fenêtrage, pour un véritable sous-classement et une douzaine d'autres choses.

Donc oui:vous devriez (devez) connaître les deux.

Modifier:même si vous prévoyez d'utiliser P/Invoke.

En supposant que vous créez des applications destinées à Windows :

  • il peut certainement être instructif de comprendre les niveaux inférieurs du système - comment ils fonctionnent, comment votre code interagit avec eux (même indirectement) et où vous disposez d'options supplémentaires qui ne sont pas disponibles dans les abstractions de niveau supérieur.
  • il y a des moments où votre code peut ne pas être aussi efficace, performant ou suffisamment précis pour vos besoins
  • Cependant, dans de plus en plus de cas, des gens comme nous (qui n'ont jamais appris le "codage non géré") seront capables de réaliser la programmation que nous essayons de faire sans "apprendre" Win32.
  • De plus, il existe de nombreux sites qui fournissent des exemples de travail, des fragments de code et même du code source entièrement fonctionnel que vous pouvez « exploiter » (emprunter, plagier – mais vérifiez que vous respectez toute licence de réutilisation ou droit d'auteur !) pour remplir dans toutes les lacunes qui ne sont pas gérées par les bibliothèques de classes du framework .NET (ou les bibliothèques que vous pouvez télécharger ou obtenir sous licence).
  • Si vous pouvez réaliser les exploits dont vous avez besoin sans vous embêter dans Win32 et que vous faites du bon travail en développant un code géré bien formé et lisible, alors je dirais que maîtriser .NET serait un meilleur choix que de vous disperser. dans deux environnements très différents.
  • Si vous avez fréquemment besoin d'exploiter les fonctionnalités de Windows qui n'ont pas reçu une bonne couverture de la bibliothèque de classes Framework, alors, par tous les moyens, acquérez les compétences dont vous avez besoin.
  • Personnellement, j'ai passé beaucoup trop de temps à m'inquiéter des "autres domaines" du codage que je travaille. censé comprendre pour produire de « bons programmes », mais il y a beaucoup de masochistes qui pensent que les besoins et les désirs de chacun sont comme les leurs.La misère aime la compagnie.:)

En supposant que vous créez des applications pour le monde « Web 2.0 », ou que cela serait tout aussi utile/bénéfique pour les utilisateurs *NIX et MacOS :

  • Restez fidèle aux langages et aux compilateurs qui ciblent autant d’environnements multiplateformes que possible.
  • Le .NET pur dans Visual Studio est évidemment meilleur que Win32, mais développer avec les bibliothèques MONO, peut-être en utilisant l'EDI Sharp Develop, est probablement une approche encore meilleure.
  • vous pourriez également passer votre temps à apprendre Java, et ces compétences seraient très bien transférées à la programmation C# (de plus, le code Java fonctionnerait théoriquement sur n'importe quelle plate-forme avec le JRE correspondant).J'ai entendu dire que Java ressemble plus à "écrire une fois, déboguer partout", mais c'est probablement aussi vrai (voire plus que) C#.

Analogie:Si vous construisez des voitures pour gagner votre vie (programmation), alors il est très pertinent de savoir comment fonctionne le moteur (Win32).

Réponse simple, OUI.

C'est la réponse à toute question du genre... "est-il logique d'apprendre un langage/api X de bas niveau même lorsqu'un langage/api Y de niveau supérieur est présent"

OUI

Vous pouvez démarrer votre PC Windows (ou tout autre système d'exploitation) et poser cette question dans SO, car quelques gars de Microsoft ont écrit un code assembleur 16 bits qui charge votre système d'exploitation.

Votre navigateur fonctionne parce que quelqu'un a écrit un noyau de système d'exploitation en C qui répond à toutes les requêtes de votre navigateur.

Cela va jusqu'aux langages de script.

Grand ou petit, il y a toujours un marché et une opportunité d'écrire quelque chose à n'importe quel niveau d'abstraction.Il suffit de l'aimer et de s'adapter au bon emploi.

Aucune API/langage, quel que soit le niveau d'abstraction, n'est pas pertinent à moins qu'il y en ait un meilleur en compétition au même niveau.

Une autre façon de voir les choses :Un bon exemple tiré d'un livre de Michael Abrash :Un programmeur C s'est vu confier la tâche d'écrire une fonction pour effacer l'écran.Puisque C était une meilleure abstraction (niveau supérieur) par rapport à l'assemblage et tout, le programmeur ne connaissait que C et le connaissait bien.Il a fait de son mieux - il a déplacé le curseur vers chaque emplacement de l'écran et y a effacé le personnage.Il a optimisé la boucle et s'est assuré qu'elle se déroulait aussi vite que possible.Mais c'était quand même lent...jusqu'à ce qu'un gars vienne et dise qu'il y avait des instructions BIOS/VGA ou quelque chose qui pourrait effacer l'écran instantanément.

Il est toujours utile de savoir sur quoi on marche.

Oui, pour plusieurs raisons :

1) .net encapsule le code Win32..net est généralement un système supérieur contre lequel coder, mais avoir une certaine connaissance de la couche Win32 sous-jacente (oups, WinAPI maintenant qu'il existe également du code 64 bits) renforce votre connaissance de ce qui se passe réellement.

2) dans cette économie, il vaut mieux avoir des avantages sur les autres quand on cherche un emploi.Une certaine expérience de WinAPI peut vous fournir cela.

3) certains aspects du système ne sont pas encore disponibles via le framework .net, et si vous souhaitez accéder à ces fonctionnalités, vous devrez utiliser p/invoke (voir http://www.pinvoke.net pour de l'aide là-bas).Avoir au moins une poignée d'expérience avec WinAPI rendra votre effort de développement p/invoke beaucoup plus efficace.

4) (ajouté) Maintenant que Win8 existe depuis un certain temps, il est toujours construit sur WinAPI.iOS, Android, OS/X et Linux existent tous, mais WinAPI sera toujours disponible pendant de nombreuses années.

L'apprentissage d'un nouveau langage de programmation ou d'une nouvelle technologie s'effectue pour l'une des trois raisons suivantes :
1.Besoin:vous démarrez un projet de création d'application Web et vous ne connaissez rien à ASP.NET
2.Enthousiasme:vous êtes très enthousiasmé par ASP.NET MVC.pourquoi ne pas essayer ça ?
3.Temps libre:mais qui a ça de toute façon.

La meilleure raison d’apprendre quelque chose de nouveau est le besoin.Si vous avez besoin de faire quelque chose que le framework .NET ne peut pas faire (comme les performances par exemple), alors WinAPI est votre solution.En attendant, nous restons occupés à en apprendre davantage sur .NET.

Pour la plupart des besoins sur le bureau, vous n'aurez pas besoin de connaître Win32, mais il y a BEAUCOUP de Win32 qui ne sont pas dans .NET, mais c'est dans les dépenses qui peuvent finir par représenter moins de 1% de votre application.

Prise en charge USB, prise en charge HID, Windows Media Foundation juste au-dessus de ma tête.Il existe de nombreuses API Vista intéressantes uniquement disponibles à partir de Win32.

Vous vous rendrez un grand service en apprenant à faire de l'interopérabilité avec une API Win32, si vous faites de la programmation de bureau, car lorsque vous aurez besoin d'appeler Win32, et vous le ferez, vous ne passerez pas des semaines à vous gratter la tête.

Personnellement, je n'aime pas vraiment l'API Win32, mais il est utile de l'apprendre car l'API permettra plus de contrôle et d'efficacité en utilisant l'interface graphique qu'un langage comme Visual Basic, et je crois que si vous voulez gagner votre vie, écrire un logiciel vous devez connaître l'API même si vous ne l'utilisez pas directement.C'est pour des raisons similaires aux raisons pour lesquelles il est bon d'apprendre le C, comme le fait qu'un strcpy prend plus de temps que la copie d'un entier, ou pourquoi vous devriez utiliser des pointeurs vers des tableaux comme paramètres de fonction au lieu de tableaux par valeur.

Apprendre le C ou un langage de niveau inférieur peut certainement être utile.Cependant, je ne vois aucun avantage évident à utiliser WinAPI non géré.

J'ai vu du code API Windows de bas niveau...ce n'est pas joli...J'aimerais pouvoir le désapprendre.Je pense qu'il est avantageux d'apprendre le bas niveau comme en C, car vous acquérez une meilleure compréhension de l'architecture matérielle et du fonctionnement de tout cela.Apprentissage de l'ancienne API Windows...Je pense que ces choses peuvent être laissées aux gens de Microsoft qui pourraient avoir besoin de les apprendre pour créer des langages et des API de niveau supérieur...ils l'ont construit, laissez-les souffrir avec ;-)

Cependant, si vous trouvez une situation dans laquelle vous sentez que vous ne pouvez tout simplement pas faire ce que vous devez faire dans une langue de niveau supérieur (rare et espacée), alors commencez peut-être la plongée dangereuse dans ce monde.

Oui.jetez un œil à uTorrent, un logiciel incroyablement efficace.La moitié de sa petite taille est due au fait qu'une grande partie de ses composants principaux ont été réécrits pour ne pas utiliser de bibliothèques gargatuiennes.

Une grande partie de cela ne pourrait pas être réalisée sans comprendre comment ces bibliothèques s'interfacent avec les API de niveau inférieur.

Il est important de savoir ce qui est disponible avec l'API Windows.Je ne pense pas que vous ayez besoin de créer du code avec, mais vous devez savoir comment cela fonctionne.Le .NET Framework contient de nombreuses fonctionnalités, mais il ne fournit pas d'équivalents en code managé pour l'intégralité de l'API Windows.Parfois, il faut se rapprocher un peu du métal, et savoir ce qu'il contient et comment il se comporte vous permettra de mieux comprendre comment l'utiliser.

C'est vraiment la même chose que la question, dois-je apprendre un langage de bas niveau comme le C (ou même l'assembleur).

Le codage est certainement plus lent (bien que le résultat soit bien sûr beaucoup plus rapide), mais son véritable avantage est que vous obtenez un aperçu de ce qui se passe au niveau du système, plutôt que de simplement comprendre la métaphore de quelqu'un d'autre sur ce qui se passe. .

Cela peut également être meilleur lorsque les choses ne fonctionnent pas bien, ou assez rapidement ou avec le type de granularité dont vous avez besoin.(Et faites au moins quelques sous-classements et superclassements.)

Je vais le dire de cette façon.Je n'aime pas programmer avec l'API Win32.Cela peut être pénible par rapport au code managé.MAIS, je suis content de le savoir parce que je peux écrire des programmes que je ne pourrais pas autrement.Je peux écrire des programmes que d'autres ne peuvent pas.De plus, cela vous donne plus d’informations sur ce que fait votre code managé en coulisses.

La valeur que vous retirez de l'apprentissage de l'API Win32 (mis à part les types d'informations générales que vous obtenez en apprenant comment les écrous et les boulons de la machine s'emboîtent) dépend de ce que vous essayez d'accomplir.Une grande partie de l'API Win32 a été bien intégrée dans les classes de la bibliothèque .NET, mais pas la totalité.Si, par exemple, vous cherchez à faire de la programmation audio sérieuse, cette partie de l'API Win32 serait un excellent sujet d'étude car seules les opérations les plus élémentaires sont disponibles dans les classes .NET.La dernière fois que j'ai vérifié, même la bibliothèque gérée DirectX DirectSound était horrible.


Au risque d’une auto-promotion éhontée....

Je viens de tomber sur une situation où l'API Win32 était ma seule option.Je souhaite avoir des info-bulles différentes sur chaque élément d'une zone de liste.J'ai écrit comment je l'ai fait cette question.

Même dans les langages de très très haut niveau, vous utilisez toujours l'API.Pourquoi?Eh bien, tous les aspects de l'API n'ont pas été répliqués par les différentes bibliothèques, frameworks, etc.Vous devez apprendre l'API aussi longtemps que vous en aurez besoin pour accomplir ce que vous essayez de faire.(Et plus maintenant.)

Hormis quelques cas très particuliers où l’on a besoin d’un accès direct aux API, je dirais NON.

Il faut beaucoup de temps et d'efforts pour apprendre à implémenter correctement les appels d'API natifs et la valeur renvoyée n'en vaut tout simplement pas la peine.Je préfère passer du temps à apprendre une nouvelle technologie ou un nouveau framework qui vous rendra la vie plus facile et la programmation moins pénible.Pas de bibliothèques COM obsolètes vieilles de plusieurs décennies que personne n'utilise vraiment (désolé pour les utilisateurs COM).

S'il vous plaît, ne me lapidez pas pour cette vue.Je sais que beaucoup d’ingénieurs ici ont une âme vraiment curieuse et il n’y a rien de mal à apprendre comment les choses fonctionnent.La curiosité a du bon et aide vraiment à comprendre.Mais d'un point de vue managérial, je préfère passer une semaine à apprendre à développer des applications Android plutôt qu'à appeler des OLE ou des COM.

Si vous envisagez de développer une application multiplateforme, si vous utilisez win32, votre application pourrait facilement fonctionner sous Linux via WINE.Il en résulte une application hautement maintenable.C'est l'un des avantages de l'apprentissage de win32.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top