windows - que - ¿Todavía tiene sentido aprender programación WinAPI de bajo nivel?

winapi que es (22)

Absolutamente. Cuando nadie conoce el nivel bajo, ¿quién actualizará y escribirá los idiomas de alto nivel? Además, cuando comprenda las cosas de bajo nivel, puede escribir un código más eficiente en un lenguaje de nivel superior y también depurar de manera más eficiente.

¿Tiene sentido, tener toda la felicidad administrada por C #, volver a la programación de Windows de Petzold y tratar de producir código w / WinAPI puro?

¿Qué se puede aprender de eso? ¿No es demasiado obsoleto para ser útil?

Además de algunos casos muy especiales cuando necesita acceso directo a las API, yo diría que NO.

Se requiere mucho tiempo y esfuerzo para aprender a implementar las llamadas API nativas correctamente y el valor de retorno simplemente no lo vale. Preferiría pasar el tiempo aprendiendo alguna nueva tecnología o marco que te haga la vida más fácil y la programación menos dolorosa. No hay bibliotecas COM obsoletos de hace décadas que ya nadie usa (lo siento por los usuarios de COM).

Por favor, no me apedreen por esta vista. Sé que muchos ingenieros tienen almas realmente curiosas y que no hay nada de malo en aprender cómo funcionan las cosas. La curiosidad es buena y realmente ayuda a la comprensión. Pero desde un punto de vista gerencial, preferiría pasar una semana aprendiendo cómo desarrollar aplicaciones de Android que cómo llamar OLE o COM.

Analogía: si construyes automóviles para vivir (programación), entonces es muy pertinente saber cómo funciona el motor (Win32).

Aprender C o un lenguaje de nivel inferior definitivamente puede ser útil. Sin embargo, no veo ninguna ventaja obvia al usar WinAPI no administrado.

Aprender un nuevo lenguaje de programación o tecnología es por una de estas tres razones:
1. Necesito: estás comenzando un proyecto para construir una aplicación web y no sabes nada sobre ASP.NET
2. Entusiasmo: estás muy entusiasmado con ASP.NET MVC. ¿Por qué no intentar eso?
3. Tiempo libre: pero quién tiene eso de todos modos.

La mejor razón para aprender algo nuevo es Necesidad. Si necesita hacer algo que el .NET Framework no puede hacer (como el rendimiento, por ejemplo), entonces WinAPI es su solución. Hasta entonces nos mantenemos ocupados aprendiendo sobre .NET

Es importante saber qué hay disponible con la API de Windows. No creo que necesites generar código con él, pero debes saber cómo funciona. .NET Framework contiene mucha funcionalidad, pero no proporciona equivalentes de código administrado para toda la API de Windows. A veces tienes que acercarte un poco al metal, y saber qué hay allí abajo y cómo se comporta te dará una mejor comprensión de cómo usarlo.

Esta es la respuesta a cualquier pregunta que sea ... "¿tiene sentido aprender un lenguaje de nivel bajo / api X incluso cuando hay un lenguaje / api de nivel superior?"

SÍ

Puede iniciar su PC con Windows (o cualquier otro sistema operativo) y hacer esta pregunta en SO porque un par de tipos en Microsoft escribieron un código ensamblador de 16 bits que carga su sistema operativo.

Su navegador funciona porque alguien escribió un núcleo del sistema operativo en C que sirve todas las solicitudes de su navegador.

Va todo el camino hasta los lenguajes de scripting.

Grande o pequeño, siempre hay un mercado y la oportunidad de escribir algo en cualquier nivel de abstracción. Simplemente tiene que gustarle y encajar en el trabajo correcto.

Ninguna API / lenguaje en ningún nivel de abstracción es irrelevante a menos que haya una mejor compitiendo en el mismo nivel .

Otra forma de verlo: un buen ejemplo de uno de los libros de Michael Abrash: al programador de CA se le asignó la tarea de escribir una función para borrar la pantalla. Como C era una abstracción mejor (nivel superior) que el ensamblaje y todo, el programador solo conocía C y lo conocía bien. Hizo lo que pudo: movió el cursor a cada ubicación de la pantalla y borró el personaje allí. Él optimizó el circuito y se aseguró de que funcionara lo más rápido posible. Pero aún así fue lento ... hasta que un tipo entró y dijo que había algunas instrucciones BIOS / VGA o algo que podría borrar la pantalla al instante.

Siempre es útil saber en qué andas.

Esta pregunta raya en lo religioso :) Pero daré mis pensamientos de todos modos.

Veo valor en aprender la API Win32. La mayoría, si no todas, las bibliotecas de GUI (administradas o no) resultan en llamadas a la API de Win32. Incluso las bibliotecas más completas no cubren el 100% de la API y, por lo tanto, siempre hay brechas que deben ser conectadas por llamadas API directas o P / invocación. Algunos de los nombres de las envolturas alrededor de las llamadas API tienen nombres similares a las llamadas API subyacentes, pero esos nombres no son exactamente auto-documentables. Por lo tanto, la comprensión de la API subyacente y la terminología utilizada en ella ayudarán a comprender las API de envoltura y lo que realmente hacen.

Además, si comprende la naturaleza de las API subyacentes que utilizan los marcos, tomará mejores decisiones con respecto a la funcionalidad de la biblioteca que debe usar en un escenario determinado.

¡Aclamaciones!

Esto es realmente lo mismo que la pregunta, ¿debería aprender un lenguaje de bajo nivel como C (o incluso ensamblador)?

La codificación es ciertamente más lenta (aunque, por supuesto, el resultado es mucho más rápido), pero su verdadera ventaja es que obtienes una idea de lo que está sucediendo cerca del sistema, en lugar de entender la metáfora de otra persona de lo que está sucediendo. .

También puede ser mejor cuando las cosas no funcionan bien, o lo suficientemente rápido o con el tipo de granularidad que necesita. (Y haz al menos algunas subclases y superclases).

He visto código de Windows API de bajo nivel ... no es bonito ... Desearía poder desaprenderlo. Creo que es beneficioso aprender niveles bajos como en C, a medida que comprendes mejor la arquitectura del hardware y cómo funciona todo eso. Aprendiendo la vieja API de Windows ... Creo que las cosas pueden dejarse en manos de las personas de Microsoft que pueden necesitar aprenderlo para construir lenguajes de alto nivel y API ... lo construyeron, les permiten sufrir con eso ;-)

Sin embargo, si encuentra una situación en la que siente que no puede hacer lo que necesita hacer en un lenguaje de nivel superior (pocos y distantes entre sí), entonces quizás inicie la inmersión peligrosa en ese mundo.

Incluso en lenguajes de muy alto nivel, todavía hace uso de la API. ¿Por qué? Bueno, no todos los aspectos de la API han sido replicados por varias bibliotecas, marcos, etc. Necesitas aprender la API mientras necesites la API para lograr lo que estás tratando de hacer. (Y no más.)

La cantidad de valor que obtienes al aprender la API de Win32 (aparte del tipo de información general que obtienes al aprender cómo encajan los aspectos prácticos de la máquina) depende de lo que estás tratando de lograr. Gran parte de la API de Win32 se ha adaptado muy bien en las clases de biblioteca .NET, pero no en todas. Si, por ejemplo, está buscando hacer una programación de audio seria, esa porción de la API de Win32 sería un excelente tema de estudio porque solo las operaciones más básicas están disponibles en las clases de .NET. La última vez que verifiqué, incluso la biblioteca DirectX DirectSound administrada fue horrible.

A riesgo de una autopromoción desvergonzada ...

Me encontré con una situación en la que la API de Win32 era mi única opción. Quiero tener diferentes información sobre herramientas en cada elemento en un cuadro de lista. Escribí cómo lo hice en esta pregunta .

Las API nativas son las API del sistema operativo "real". La biblioteca de .NET es (con algunas excepciones) nada más que un envoltorio de fantasía a su alrededor. Entonces sí, yo diría que cualquiera que pueda entender .NET con toda su complejidad, puede entender cosas relativamente mundanas como hablar con la API sin el beneficio de un intermediario.

Intente hacer la inyección DLL desde el código administrado. No se puede hacer. Tendrá que escribir código nativo para esto, para ajustes de ventanas, para subclases reales y una docena de cosas más.

Entonces sí: debes (debes) saber ambos.

Editar: incluso si planea usar P / Invoke.

Lo pondré de esta manera. No me gusta programar para la API de Win32. Puede ser un dolor en comparación con el código administrado. PERO, me alegra saberlo porque puedo escribir programas que de otro modo no podría. Puedo escribir programas que otras personas no pueden. Además, le brinda más información sobre lo que su código administrado está haciendo detrás de escena.

Mantuve el C / C ++ estándar durante años antes de aprender Win32 API, y para ser franco, la parte de "aprender API Win32" no es la mejor experiencia técnica de mi vida.

En una mano Win32 API es bastante genial. Es como una extensión de la API estándar C (que necesita fopen cuando puede tener CreateFile . Pero supongo que UNIX / Linux / WhateverOS tienen las mismas funciones de gizmo. De todos modos, en Unix / Linux, tienen el "Todo es un archivo". En Windows, tienen la ventana "Todo es una ..." (¡no es broma! ¡Vea CreateWindow !).

Por otro lado, esta es una API heredada. Tendrás que lidiar con C en bruto y con la locura C en bruto.

Como decirle a la estructura de uno que tenga su propio tamaño que pase por un puntero void * a alguna función de Win32.
Los mensajes también pueden ser bastante confusos: mezclar objetos C ++ con Windows Win32 conduce a ejemplos muy interesantes de problemas de Chicken o Egg (momentos graciosos cuando se escribe un tipo de delete this ; en un método de clase).
Tener que subclasificar un WinProc cuando estás más familiarizado con la herencia de objetos es una división de cabezas y menos que óptimo.
Y por supuesto, existe la alegría de " ¿Por qué en este mundo fracking hicieron esto de esta manera? " Momentos en los que golpeas el teclado con la cabeza una vez más y vuelves a casa con las teclas grabadas en la frente, solo porque alguien pensó que era más lógico escribir una API para habilitar el cambio del color de una "Ventana", no cambiando una de sus propiedades, sino pidiéndole su ventana principal.
etc.

En la última mano (¿ tres manos? ), Tenga en cuenta que algunas personas que trabajan con API heredadas están utilizando el estilo de código heredado. En el momento en que escuchas " const es para dummies " o " No uso espacios de nombres porque disminuyen la velocidad del tiempo de ejecución ", o incluso mejor " Oye, ¿quién necesita el código C ++? I en mi propia marca de C orientado a objetos !! ! "(No es broma ... En un entorno profesional, y el resultado fue todo un espectáculo ...), sentirás el tipo de terror que solo se condenó sentir frente a la guillotine .

Entonces ... en general, es una experiencia interesante .

Editar

Después de volver a leer esta publicación, veo que podría verse como algo demasiado negativo. No lo es.

A veces es interesante (y frustrante) saber cómo funcionan las cosas bajo el capó. Comprenderá que, a pesar de las enormes (¿imposibles?) Limitaciones, el equipo de la API de Win32 hizo un trabajo maravilloso para asegurarse de que todo, desde usted, el "antiguo programa Win16" hasta su "última aplicación supercontable Win64", pueda funcionar en conjunto. en el pasado, ahora y en el futuro.

La pregunta es: ¿de verdad quieres?

Porque pasar semanas para hacer cosas que se podrían hacer (y hacer mejor) en otra API de alto nivel y / o orientada a objetos puede ser bastante desmotivador (experiencia real: 3 semanas para Win API, contra 4 horas en tres otros idiomas y / o bibliotecas).

De todos modos, encontrarás que el Blog de Raymond Chen es muy interesante debido a la visión que tiene desde adentro sobre Win API y su evolución a través de los años:

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

Para la mayoría de las necesidades en el escritorio no necesitará conocer el Win32, sin embargo, hay MUCHO Win32 que no está en .NET, pero está en el material de desembolso que puede terminar siendo menos del 1% de su aplicación.

Soporte USB, soporte HID, Windows Media Foundation justo en la parte superior de mi cabeza. Hay muchas API de Vista geniales solo disponibles desde Win32.

Te harás un gran favor al aprender cómo hacer interoperabilidad con una API de Win32, si haces una programación de escritorio, porque cuando necesites llamar a Win32, y lo harás, no pasarás semanas rascándote la cabeza.

Personalmente, realmente no me gusta la API de Win32, pero tiene valor aprenderla, ya que la API permitirá un mayor control y eficacia usando la GUI que un lenguaje como Visual Basic, y creo que si te vas a ganar la vida escribiendo software debes conocer la API incluso si no la usas directamente. Esto se debe a razones similares a las razones por las que es bueno aprender C, por ejemplo, cómo una strcpy toma más tiempo que copiar un número entero, o por qué debería usar punteros a matrices como parámetros de función en lugar de matrices por valor.

Respuesta simple, SÍ.

Sí, por algunas razones:

1) .NET envuelve el código de Win32. .net suele ser un sistema superior para codificar, pero tener algún conocimiento de la capa subyacente de Win32 (¡vaya, WinAPI ahora que también hay código de 64 bits!) refuerza tu conocimiento de lo que realmente está sucediendo.

2) en esta economía, es mejor tener algunas ventajas sobre el otro tipo cuando buscas un trabajo. Alguna experiencia de WinAPI puede proporcionar esto para usted.

3) algunos aspectos del sistema aún no están disponibles a través del framework .net, y si desea acceder a esas funciones, necesitará usar p / invoke (consulte http://www.pinvoke.net para obtener ayuda allí). Tener al menos un poco de experiencia en WinAPI hará que su esfuerzo de desarrollo de p / invoke sea mucho más eficiente.

4) (agregado) Ahora que Win8 ha existido por un tiempo, todavía está construido sobre WinAPI. iOS, Android, OS / X y Linux están todos por ahí, pero el WinAPI seguirá existiendo durante muchos años.

Si planea desarrollar una aplicación multiplataforma, si usa win32, entonces su aplicación podría ejecutarse fácilmente en Linux a través de WINE. Esto resulta en una aplicación altamente sostenible. Esta es una de las ventajas de aprender win32.

Suponiendo que está creando aplicaciones dirigidas a Windows:

puede ser informativo para comprender los niveles más bajos del sistema: cómo funcionan, cómo interactúa el código con ellos (aunque sea de forma indirecta) y dónde tiene opciones adicionales que no están disponibles en las abstracciones de mayor nivel.
hay ocasiones en que su código puede no ser tan eficiente, de alto rendimiento o lo suficientemente preciso para sus necesidades
Sin embargo, en más y más casos, personas como nosotros (que nunca aprendieron la "codificación no administrada") podrán realizar la programación que estamos tratando de hacer sin "aprender" Win32.
Además, hay muchos sitios que ofrecen ejemplos de trabajo, fragmentos de código e incluso código fuente completamente funcional que puede "aprovechar" (pedir prestado, plagiar pero ¡asegúrese de cumplir con cualquier licencia de reutilización o derechos de autor!) Para llenar en cualquier hueco que no maneje las librerías de clases de .NET Framework (o las bibliotecas que puede descargar o licenciar).
Si puede realizar las hazañas que necesita sin perder el tiempo en Win32, y está haciendo un buen trabajo al desarrollar código administrado legible y bien formado, entonces diría que dominar .NET sería una mejor opción que expandirse en dos ambientes muy diferentes.
Si con frecuencia necesita aprovechar las características de Windows que no han recibido una buena cobertura de biblioteca de la clase Framework, entonces aprenda las habilidades que necesita.
Personalmente, me he pasado demasiado tiempo preocupándome por las "otras áreas" de codificación que se supone que debo entender para producir "buenos programas", pero hay muchos masoquistas que piensan que las necesidades y los deseos de todos son como los suyos. La miseria ama la compañía. :)

En el supuesto de que está creando aplicaciones para el mundo "Web 2.0", o que sería tan útil / beneficioso para los usuarios de * NIX y MacOS:

Limítese a los lenguajes y compiladores que se dirigen a tantos entornos multiplataforma como sea posible.
Pure .NET en Visual Studio es mejor que Win32 obviamente, pero desarrollar contra las bibliotecas MONO, quizás usando Sharp Develop IDE, es probablemente un enfoque aún mejor.
también podría pasar su tiempo aprendiendo Java, y esas habilidades se transferirían muy bien a la programación de C # (además, el código de Java se ejecutaría teóricamente en cualquier plataforma con el JRE correspondiente). He oído decir que Java es más como "escribir una vez, depurar en todas partes", pero eso es probablemente tan cierto como (o incluso más que) C #.

sí. eche un vistazo a uTorrent, una sorprendente pieza de eficiencia de software. La mitad de su pequeño tamaño se debe al hecho de que gran parte de sus componentes principales se volvieron a escribir para no utilizar las librerías gargatuianas.

Gran parte de esto no podría hacerse sin entender cómo estas bibliotecas interactúan con las API de nivel inferior