Ha ancora senso imparare la programmazione WinAPI di basso livello?[Chiuso]

https://stackoverflow.com/questions/5507

08-06-2019
|

Domanda

Ha senso, avendo tutta la felicità gestita da C#, tornare a Windows di programmazione di Petzold e provare a produrre codice con WinAPI puro?

Cosa si può imparare da ciò?Non è semplicemente troppo obsoleto per essere utile?

Soluzione

Questa domanda è al limite del religioso :) Ma darò comunque il mio pensiero.

Vedo valore nell'apprendimento dell'API Win32.La maggior parte, se non tutte, le librerie GUI (gestite o non gestite) generano chiamate all'API Win32.Anche le librerie più complete non coprono il 100% dell'API e quindi ci sono sempre delle lacune che devono essere colmate tramite chiamate API dirette o P/invoking.Alcuni dei nomi dei wrapper attorno alle chiamate API hanno nomi simili alle chiamate API sottostanti, ma tali nomi non sono esattamente autodocumentanti.Pertanto, comprendere l'API sottostante e la terminologia utilizzata in essa aiuterà a comprendere le API wrapper e cosa fanno effettivamente.

Inoltre, se comprendi la natura delle API sottostanti utilizzate dai framework, farai scelte migliori riguardo a quale funzionalità della libreria utilizzare in un determinato scenario.

Saluti!

Altri suggerimenti

Ho mantenuto lo standard C/C++ per anni prima di apprendere l'API Win32 e, per essere sincero, la parte "apprendimento dell'API Win32" non è la migliore esperienza tecnica della mia vita.

Da un lato l'API Win32 è piuttosto interessante.È come un'estensione dell'API standard C (chi ha bisogno fopen quando puoi avere CreateFile.Ma immagino che UNIX/Linux/Qualunque sistema operativo abbiano le stesse funzioni gizmo.Ad ogni modo, in Unix/Linux hanno la frase "Tutto è un file".In Windows, hanno il messaggio "Tutto è un...Finestra" (non sto scherzando!Vedere CreateWindow!).

D'altra parte, questa è un'API legacy.Avrai a che fare con il C grezzo e la follia del C grezzo.

Come dire alla propria struttura la propria dimensione da attraversare a void * puntatore ad alcune funzioni Win32.
Anche la messaggistica può creare confusione:La combinazione di oggetti C++ con finestre Win32 porta a esempi molto interessanti di Pollo o Uovo problema (momenti divertenti in cui scrivi una specie di delete this ; in un metodo di classe).
Dover creare una sottoclasse di WinProc quando hai più familiarità con l'ereditarietà degli oggetti è sconvolgente e tutt'altro che ottimale.
E, naturalmente, c'è la gioia di "Perché in questo mondo del fracking hanno fatto questa cosa in questo modo?" momenti in cui colpisci la tastiera con la testa una volta di troppo e torni a casa con i tasti incisi in fronte, solo perché qualcuno ha pensato che fosse più logico scrivere un'API per abilitare il cambio del colore di una "Finestra", non da cambiando una delle sue proprietà, ma chiedendolo alla sua finestra genitore.
eccetera.

Nell'ultima mano (tre mani???), considera che alcune persone che lavorano con API legacy utilizzano essi stessi stili di codice legacy.Nel momento in cui senti "const è per i manichini" O "Non utilizzo gli spazi dei nomi perché riducono la velocità di runtime", o meglio ancora"Ehi, chi ha bisogno del C++?Codifico nel mio marchio C orientato agli oggetti!!!" (Non sto scherzando...In un ambiente professionale, e il risultato è stato davvero uno spettacolo...), proverai quel tipo di terrore che provano solo i condannati di fronte al ghigliottina.

COSÌ...Tutto sommato, è un interessante esperienza.

Modificare

Dopo aver riletto questo post, vedo che potrebbe essere visto come eccessivamente negativo.Non è.

A volte è interessante (oltre che frustrante) sapere come funzionano le cose dietro il cofano.Capirai che, nonostante enormi (impossibili?) vincoli, il team dell'API Win32 ha fatto un lavoro meraviglioso per essere sicuro che tutto, dal tuo "vecchio programma Win16" alla tua "ultima applicazione Win64 over-the-top", possa funzionare insieme, nel passato, ora e nel futuro.

La domanda è:Lo vuoi davvero?

Perché passare settimane a fare cose che potrebbero essere fatte (e fatte meglio) in altre API di livello più alto e/o orientate agli oggetti può essere abbastanza demotivante (esperienza di vita reale:3 settimane per Win API, contro 4 ore in altre tre lingue e/o librerie).

Ad ogni modo, troverai il blog di Raymond Chen molto interessante per via del suo punto di vista privilegiato sia su Win API che sulla sua evoluzione nel corso degli anni:

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

Assolutamente.Quando nessuno conosce il livello basso, chi aggiornerà e scriverà i linguaggi di alto livello?Inoltre, quando comprendi le cose di basso livello, puoi scrivere codice più efficiente in un linguaggio di livello superiore e anche eseguire il debug in modo più efficiente.

Le API native sono le API "reali" del sistema operativo.La libreria .NET non è (con poche eccezioni) altro che un elegante involucro che li avvolge.Quindi sì, direi che chiunque sia in grado di comprendere .NET con tutta la sua complessità, può comprendere cose relativamente banali come parlare con l'API senza il beneficio di un intermediario.

Prova semplicemente a eseguire l'iniezione DLL dal codice gestito.Non è possibile farlo.Sarai costretto a scrivere codice nativo per questo, per modifiche alle finestre, per vere e proprie sottoclassi e una dozzina di altre cose.

Quindi sì:dovresti (devi) conoscerli entrambi.

Modificare:anche se prevedi di utilizzare P/Invoke.

Supponendo che tu stia creando app destinate a Windows:

può sicuramente essere informativo comprendere i livelli inferiori del sistema: come funzionano, come il codice interagisce con essi (anche se solo indirettamente) e dove sono disponibili opzioni aggiuntive che non sono disponibili nelle astrazioni di livello superiore
ci sono momenti in cui il tuo codice potrebbe non essere efficiente, performante o sufficientemente preciso per le tue esigenze
Tuttavia, in sempre più casi, persone come noi (che non hanno mai imparato la "codifica non gestita") saranno in grado di portare a termine la programmazione che stiamo cercando di fare senza "imparare" Win32.
Inoltre, ci sono moltissimi siti che forniscono esempi funzionanti, frammenti di codice e persino codice sorgente completamente funzionante che puoi "sfruttare" (prendere in prestito, plagiare, ma controlla di rispettare eventuali licenze di riutilizzo o copyright!) per riempire in eventuali lacune non gestite dalle librerie di classi .NET Framework (o dalle librerie che è possibile scaricare o concedere in licenza).
Se riesci a portare a termine le imprese di cui hai bisogno senza perdere tempo in Win32 e stai facendo un buon lavoro nello sviluppo di codice gestito ben formato e leggibile, allora direi che padroneggiare .NET sarebbe una scelta migliore che sparpagliarti. su due ambienti molto diversi.
Se hai spesso bisogno di sfruttare le funzionalità di Windows che non hanno ricevuto una buona copertura dalla libreria di classi del Framework, acquisisci sicuramente le competenze necessarie.
Personalmente ho passato troppo tempo a preoccuparmi delle "altre aree" della programmazione che sto facendo ipotetico capire per produrre "buoni programmi", ma là fuori ci sono molti masochisti che pensano che i bisogni e i desideri di ognuno siano come i loro.La miseria ama la compagnia.:)

Partendo dal presupposto che stai creando app per il mondo "Web 2.0" o che sarebbero altrettanto utili/benefiche per gli utenti *NIX e MacOS:

Attenersi a linguaggi e compilatori destinati al maggior numero possibile di ambienti multipiattaforma.
.NET puro in Visual Studio è ovviamente migliore di Win32, ma sviluppare con le librerie MONO, magari utilizzando l'IDE Sharp Develop, è probabilmente un approccio ancora migliore.
potresti anche dedicare il tuo tempo ad imparare Java e tali competenze si trasferirebbero molto bene alla programmazione C# (inoltre il codice Java verrebbe teoricamente eseguito su qualsiasi piattaforma con il JRE corrispondente).Ho sentito dire che Java è più simile a "scrivi una volta, esegui il debug ovunque", ma probabilmente è vero quanto (o anche di più) C#.

Analogia:Se costruisci automobili per vivere (programmazione), allora è molto pertinente sapere come funziona il motore (Win32).

Risposta semplice, SI.

Questa è la risposta a qualsiasi domanda del tipo... "ha senso imparare una lingua/api X di basso livello anche quando è presente una lingua/api Y di livello superiore"

SÌ

Puoi avviare il tuo PC Windows (o qualsiasi altro sistema operativo) e porre questa domanda in SO perché un paio di ragazzi di Microsoft hanno scritto codice assembly a 16 bit che carica il tuo sistema operativo.

Il tuo browser funziona perché qualcuno ha scritto un kernel del sistema operativo in C che soddisfa tutte le richieste del tuo browser.

Si arriva fino ai linguaggi di scripting.

Grande o piccolo, c'è sempre un mercato e un'opportunità per scrivere qualcosa a qualsiasi livello di astrazione.Devi solo piacerti e adattarti al lavoro giusto.

Nessuna API/linguaggio a qualsiasi livello di astrazione è irrilevante a meno che non ce ne sia uno migliore che compete allo stesso livello.

Un altro modo di vederlo:Un buon esempio da uno dei libri di Michael Abrash:A un programmatore C è stato affidato il compito di scrivere una funzione per pulire lo schermo.Poiché C era un'astrazione migliore (di livello superiore) rispetto all'assemblaggio e tutto il resto, il programmatore conosceva solo C e lo conosceva bene.Ha fatto del suo meglio: ha spostato il cursore su ciascuna posizione sullo schermo e ha cancellato il carattere lì.Ha ottimizzato il ciclo e si è assicurato che funzionasse il più velocemente possibile.Ma era comunque lento...finché qualcuno non è entrato e ha detto che c'erano alcune istruzioni BIOS/VGA o qualcosa che poteva pulire lo schermo all'istante.

Aiuta sempre sapere su cosa stai camminando.

Sì, per alcuni motivi:

1) .net avvolge il codice Win32..net è solitamente un sistema superiore su cui codificare, ma avere una certa conoscenza del livello Win32 sottostante (oops, WinAPI ora che esiste anche codice a 64 bit) rafforza la tua conoscenza di ciò che sta realmente accadendo.

2) in questa economia è meglio avere dei vantaggi rispetto agli altri quando si cerca lavoro.Alcune esperienze WinAPI potrebbero fornirti questo.

3) alcuni aspetti del sistema non sono ancora disponibili tramite il framework .net e se desideri accedere a tali funzionalità dovrai utilizzare p/invoke (vedi http://www.pinvoke.net per qualche aiuto lì).Avere almeno un'infarinatura di esperienza con WinAPI renderà il tuo lavoro di sviluppo di p/invoke molto più efficiente.

4) (aggiunto) Ora che Win8 è in circolazione da un po', lo è Ancora costruito sulla base di WinAPI.iOS, Android, OS/X e Linux sono tutti disponibili, ma WinAPI sarà ancora disponibile per molti anni.

Imparare un nuovo linguaggio o tecnologia di programmazione è per uno dei tre motivi:
1.Bisogno:stai avviando un progetto per creare un'applicazione web e non sai nulla di ASP.NET
2.Entusiasmo:sei molto entusiasta di ASP.NET MVC.perché non provarlo?
3.Tempo libero:ma chi ce l'ha comunque?

Il miglior motivo per imparare qualcosa di nuovo è il bisogno.Se hai bisogno di fare qualcosa che il framework .NET non può fare (come ad esempio le prestazioni), allora WinAPI è la tua soluzione.Fino ad allora ci terremo impegnati a conoscere .NET

Per la maggior parte delle esigenze sul desktop non avrai bisogno di conoscere Win32, tuttavia c'è MOLTO Win32 non in .NET, ma è nelle spese che potrebbero finire per essere meno dell'1% della tua applicazione.

Supporto USB, supporto HID, Windows Media Foundation proprio in cima alla mia testa.Ci sono molte interessanti API Vista disponibili solo da Win32.

Ti farai un grande favore imparando come eseguire l'interoperabilità con un'API Win32, se esegui la programmazione desktop, perché quando avrai bisogno di chiamare Win32, e lo farai, non passerai settimane a grattarti la testa.

Personalmente non mi piace molto l'API Win32, ma è utile apprenderla poiché l'API consentirà un maggiore controllo ed efficienza utilizzando la GUI rispetto a un linguaggio come Visual Basic, e credo che se hai intenzione di guadagnarti da vivere scrivendo software dovresti conoscere l'API anche se non la usi direttamente.Questo per ragioni simili a quelle per cui è utile imparare il C, ad esempio perché uno strcpy impiega più tempo che copiare un numero intero o perché dovresti usare i puntatori agli array come parametri di funzione anziché agli array per valore.

Imparare il C o un linguaggio di livello inferiore può sicuramente essere utile.Tuttavia, non vedo alcun vantaggio evidente nell'utilizzo della WinAPI non gestita.

Ho visto il codice API di Windows di basso livello...non è carino...Vorrei poterlo disimparare.Penso che sia vantaggioso apprendere il livello basso come in C, poiché acquisisci una migliore comprensione dell'architettura hardware e di come funzionano tutte queste cose.Apprendimento della vecchia API di Windows...Penso che queste cose possano essere lasciate alle persone di Microsoft che potrebbero aver bisogno di impararle per costruire linguaggi e API di livello superiore...l'hanno costruito, lasciali soffrire con esso ;-)

Tuttavia, se ti capita di trovare una situazione in cui ritieni di non poter fare ciò che devi fare in una lingua di livello superiore (poche e rare), allora forse inizia la pericolosa immersione in quel mondo.

SÌ.dai un'occhiata a uTorrent, uno straordinario esempio di efficienza del software.La metà delle sue dimensioni ridotte è dovuta al fatto che gran parte dei suoi componenti principali sono stati riscritti per non utilizzare librerie gigantesche.

Gran parte di ciò non potrebbe essere fatto senza comprendere come queste librerie si interfacciano con le API di livello inferiore

È importante sapere cosa è disponibile con l'API di Windows.Non penso che tu abbia bisogno di scrivere codice con esso, ma dovresti sapere come funziona..NET Framework contiene molte funzionalità, ma non fornisce equivalenti di codice gestito per l'intera API di Windows.A volte devi avvicinarti un po' di più al metallo, e sapere cosa c'è laggiù e come si comporta ti aiuterà a capire meglio come usarlo.

Questa è in realtà la stessa domanda, dovrei imparare un linguaggio di basso livello come C (o anche assembler).

La sua codifica è certamente più lenta (anche se ovviamente il risultato è molto più veloce), ma il suo vero vantaggio è che ottieni una visione di ciò che sta accadendo a livello di sistema, piuttosto che limitarti a comprendere la metafora di qualcun altro per ciò che sta accadendo. .

Può anche essere migliore quando le cose non funzionano bene, o abbastanza velocemente o con il tipo di granularità di cui hai bisogno.(E fai almeno alcune sottoclassi e superclassi.)

La metto in questo modo.Non mi piace programmare con l'API Win32.Può essere una seccatura rispetto al codice gestito.MA sono felice di saperlo perché posso scrivere programmi che altrimenti non sarei in grado di fare.Posso scrivere programmi che gli altri non possono scrivere.Inoltre, ti offre maggiori informazioni su ciò che il tuo codice gestito sta facendo dietro le quinte.

La quantità di valore che ottieni dall'apprendimento dell'API Win32 (a parte il tipo di intuizioni generali che ottieni imparando come i dadi e i bulloni della macchina si incastrano insieme) dipende da ciò che stai cercando di ottenere.Gran parte dell'API Win32 è stata inserita correttamente nelle classi della libreria .NET, ma non tutta.Se, ad esempio, stai cercando di eseguire una programmazione audio seria, quella parte dell'API Win32 sarebbe un eccellente argomento di studio perché solo le operazioni di base sono disponibili dalle classi .NET.L'ultima volta che ho controllato, anche la libreria DirectX DirectSound gestita era orribile.

A rischio di una spudorata autopromozione....

Mi sono appena imbattuto in una situazione in cui l'API Win32 era la mia unica opzione.Voglio avere descrizioni comandi diverse su ciascun elemento in una casella di riepilogo.Ho scritto come l'ho fatto questa domanda.

Anche in linguaggi di altissimo livello si utilizza comunque l'API.Perché?Beh, non tutti gli aspetti dell'API sono stati replicati dalle varie librerie, framework, ecc.Devi apprendere l'API per tutto il tempo in cui ne avrai bisogno per realizzare ciò che stai cercando di fare.(E non più.)

A parte alcuni casi molto particolari in cui è necessario l'accesso diretto alle API, direi NO.

Sono necessari molto tempo e impegno per imparare a implementare correttamente le chiamate API native e il valore restituito non ne vale la pena.Preferirei dedicare il tempo ad apprendere qualche nuova tecnologia o framework che renderà la tua vita più semplice e la programmazione meno dolorosa.Non librerie COM obsolete vecchie di decenni che nessuno usa più (mi dispiace per gli utenti COM).

Per favore, non lapidarmi per questo punto di vista.So che molti ingegneri qui hanno un'anima davvero curiosa e non c'è niente di sbagliato nell'imparare come funzionano le cose.La curiosità fa bene e aiuta davvero a capire.Ma da un punto di vista manageriale, preferirei dedicare una settimana a imparare a sviluppare app Android piuttosto che a chiamare OLE o COM.

Se hai intenzione di sviluppare un'applicazione multipiattaforma, se usi Win32, la tua applicazione potrebbe essere facilmente eseguita su Linux tramite WINE.Ciò si traduce in un'applicazione altamente gestibile.Questo è uno dei vantaggi dell'apprendimento di Win32.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow