La API de Windows , informalmente WinAPI , es la interfaz de programación de aplicaciones (API) fundamental que permite a un programa de computadora acceder a las características del sistema operativo Microsoft Windows en el que se ejecuta el programa.
Cada versión principal de la API de Windows tiene un nombre distinto que identifica un aspecto de compatibilidad de esa versión. Por ejemplo, Win32 es la versión principal de la API de Windows que se ejecuta en sistemas de 32 bits. El nombre, API de Windows, hace referencia colectivamente a todas las versiones de esta capacidad de Windows.
Microsoft proporciona soporte para desarrolladores a través de un kit de desarrollo de software , Microsoft Windows SDK , que incluye documentación y herramientas para crear software basado en la API de Windows.
Las funciones proporcionadas por la API de Windows se pueden agrupar en ocho categorías: [1]
win32k.sysel cual se comunica directamente con el controlador de gráficos. [3] [4]La API de Windows está definida en el lenguaje de programación C. [ 12] Sus funciones y estructuras de datos están definidas en sintaxis C (consulte windows.h ). Sin embargo, la API puede utilizarse a través de cualquier lenguaje de programación que pueda interoperar con las estructuras de datos de la API y las convenciones de llamada para llamadas de función y devoluciones de llamadas .
Cabe destacar que la implementación interna de las funciones de la API se ha desarrollado en varios lenguajes distintos de C. [a]
A pesar de que C no es un lenguaje de programación orientado a objetos (OOP), la API de Windows está orientada a objetos en cierta medida debido a su uso de identificadores. Varias otras tecnologías de Microsoft y otras empresas hacen que este aspecto orientado a objetos sea más evidente mediante el uso de un lenguaje OOP como C++; consulte Microsoft Foundation Class Library (MFC), Visual Component Library (VCL), GDI+ . Cabe destacar que Windows 8 proporciona la API de Windows y la API de WinRT , que se implementa en C++ [13] y está orientada a objetos por diseño. [13]
Windows.pas es una unidad de Pascal / Delphi que expone las características de la API de Windows. Es el equivalente en Pascal al lenguaje C windows.h . [14]
La API de Windows está pensada principalmente para que un programa acceda a las funciones del sistema operativo . Para la comunicación entre diferentes aplicaciones de Windows, Microsoft ha desarrollado una serie de tecnologías junto con la API de Windows. Esto comenzó con el intercambio dinámico de datos (DDE), que fue reemplazado por la vinculación e incrustación de objetos (OLE) y, más tarde, por el modelo de objetos componentes (COM), los objetos de automatización , los controles ActiveX y .NET Framework . No siempre existe una distinción clara entre estas tecnologías y hay mucha superposición.
La variedad de términos es básicamente el resultado de agrupar los mecanismos de software que se relacionan con un aspecto determinado del desarrollo de software. La automatización se relaciona específicamente con la exportación de la función de una aplicación o componente (como una interfaz de programación de aplicaciones (API)) para que pueda ser controlada por otras aplicaciones en lugar de solo por usuarios humanos. .NET es una metodología y tecnología general autónoma para desarrollar aplicaciones de escritorio y web escritas en una variedad de lenguajes compilados en tiempo real (JIT) .
Muchas tecnologías de Microsoft utilizan la API de Windows, como lo hace la mayoría del software que se ejecuta en Windows. Como middleware entre la API de Windows y una aplicación, estas tecnologías proporcionan cierto acceso a la API de Windows. Algunas tecnologías se describen como si envolvieran la API de Windows, pero esto es discutible ya que ninguna otra tecnología proporciona o expone todas las capacidades de la API de Windows.
Aunque casi todos los programas de Windows utilizan la API de Windows, en la línea de sistemas operativos Windows NT, los programas que se inician temprano en el proceso de inicio de Windows utilizan la API nativa en su lugar. [15]
La API de Windows siempre ha expuesto una gran parte de la estructura subyacente de los sistemas Windows a los programadores. Esto tenía la ventaja de darles mucha flexibilidad y poder sobre sus aplicaciones, pero también crea una gran responsabilidad en la forma en que las aplicaciones manejan varias operaciones de bajo nivel, a veces tediosas, que están asociadas con una interfaz gráfica de usuario .
Por ejemplo, un programador de C principiante a menudo escribirá el sencillo "hola mundo" como su primera tarea. La parte funcional del programa es sólo una única línea printf dentro de la subrutina principal. La sobrecarga para vincularse a la biblioteca de E/S estándar también es sólo una línea:
#incluir <stdio.h> int main ( void ) { printf ( "Hola, mundo! \n " ); } Charles Petzold , que escribió varios libros sobre programación para la API de Windows, dijo: "El programa original de Hola Mundo en el SDK de Windows 1.0 fue un escándalo. HELLO.C tenía unas 150 líneas de longitud, y el script de recursos HELLO.RC tenía otras 20 líneas más o menos. (...) Los programadores veteranos a menudo se quedaban horrorizados o se reían cuando se encontraban con el programa Hola Mundo de Windows". [16] Petzold explica que, si bien fue el primer programa de muestra de Windows que se presentó a los desarrolladores, era bastante "elegante" y más complejo de lo necesario. Cansado de que la gente ridiculizara la longitud de la muestra, finalmente lo redujo a una simple llamada a MessageBox. [17]
A lo largo de los años, se realizaron varios cambios y adiciones a los sistemas Windows, y la API de Windows cambió y creció para reflejar esto. [18] La API de Windows para Windows 1.0 admitía menos de 450 llamadas de función , mientras que las versiones modernas de la API de Windows admiten miles. Sin embargo, en general, la interfaz se mantuvo bastante consistente y una antigua aplicación de Windows 1.0 aún le resultará familiar a un programador que esté acostumbrado a la API moderna de Windows. [19]
Microsoft ha hecho un esfuerzo por mantener la compatibilidad con versiones anteriores . Para lograrlo, al desarrollar nuevas versiones de Windows, Microsoft a veces implementó soluciones alternativas [20] para permitir la compatibilidad con software de terceros que utilizaba la versión anterior de una manera no documentada o incluso desaconsejable. Raymond Chen , un desarrollador de Microsoft que trabaja en la API de Windows, ha dicho: "Probablemente podría escribir durante meses únicamente sobre las cosas malas que hacen las aplicaciones y lo que tuvimos que hacer para que volvieran a funcionar (a menudo a pesar de ellas mismas). Por eso me pongo particularmente furioso cuando la gente acusa a Microsoft de romper aplicaciones maliciosamente durante las actualizaciones del sistema operativo. Si alguna aplicación no se ejecutaba en Windows 95, lo tomaba como un fracaso personal". [21]
Uno de los mayores cambios en la API de Windows fue la transición de Win16 (incluido en Windows 3.1 y versiones anteriores) a Win32 (Windows NT y Windows 95 y versiones posteriores). Aunque Win32 se introdujo originalmente con Windows NT 3.1 y los Win32 permitían el uso de un subconjunto de Win32 antes de Windows 95, no fue hasta Windows 95 cuando se empezó a portar aplicaciones a Win32 de forma generalizada. Para facilitar la transición, en Windows 95, para los desarrolladores de dentro y fuera de Microsoft, se utilizó un complejo esquema de procesadores de API que permitían que el código de 32 bits llamara a código de 16 bits (para la mayoría de las API de Win16) y viceversa. Los procesadores planos permitían que el código de 32 bits llamara a bibliotecas de 16 bits, y el esquema se utilizó ampliamente dentro de las bibliotecas de Windows 95 para evitar portar todo el sistema operativo a Win32 en un solo lote. En Windows NT, el sistema operativo era de 32 bits puros, excepto partes para la compatibilidad con aplicaciones de 16 bits, y solo había procesadores genéricos disponibles para pasar de Win16 a Win32, como en Windows 95. El SDK de la plataforma se entregaba con un compilador que podía producir el código necesario para estos procesadores. Las versiones de Windows de 64 bits también pueden ejecutar aplicaciones de 32 bits a través de WoW64 . La carpeta SysWOW64 ubicada en la carpeta Windows en la unidad del sistema operativo contiene varias herramientas para admitir aplicaciones de 32 bits. [22]
Cada versión de Microsoft Windows contiene una versión de la API de Windows, y casi cada nueva versión de Microsoft Windows ha introducido adiciones y cambios a la API de Windows. [23]
El nombre, API de Windows, se refiere esencialmente a la misma capacidad en cada versión de Windows, pero hay otro nombre para esta capacidad que se basa en los principales aspectos arquitectónicos de la versión de Windows que la contiene. Cuando solo había una versión, se llamaba simplemente API de Windows. Luego, cuando se realizó la primera actualización importante, Microsoft le dio el nombre Win32 y le dio a la primera versión el nombre Win16. El término API de Windows se refiere a ambas versiones y a todas las versiones principales desarrolladas posteriormente. [1]
El proyecto Wine proporciona una capa de compatibilidad de API Win32 para plataformas tipo Unix , entre la API del núcleo Linux y los programas escritos para la API de Windows. ReactOS va un paso más allá y apunta a implementar el sistema operativo Windows completo, trabajando en estrecha colaboración con el proyecto Wine para promover la reutilización y compatibilidad de código. DosWin32 y HX DOS Extender son otros proyectos que emulan la API de Windows para permitir la ejecución de programas simples de Windows desde una línea de comandos DOS . Odin es un proyecto para emular Win32 en OS/2 , reemplazando la emulación original Win-OS/2 que se basaba en código de Microsoft. Otras implementaciones menores incluyen las bibliotecas MEWEL y Zinc que estaban destinadas a implementar un subconjunto de la API Win16 en DOS (consulte la Lista de bibliotecas GUI independientes de la plataforma ).
Windows Interface Source Environment (WISE) era un programa de licencias de Microsoft que permitía a los desarrolladores recompilar y ejecutar aplicaciones basadas en Windows en plataformas Unix y Macintosh . Los SDK de WISE se basaban en un emulador de la API de Windows que podía ejecutarse en esas plataformas. [27]
Los esfuerzos hacia la estandarización incluyeron la Interfaz Pública de Windows (PWI) de Sun para Win16 (ver también: Interfaz binaria de aplicación de Windows de Sun ( Wabi )), la Interfaz de programación de aplicaciones para Windows (APIW) de Willows Software para Win16 y Win32 (ver también: Willows TWIN ) y ECMA-234 , que intentó estandarizar la API de Windows de manera vinculante.
Para desarrollar software que utilice la API de Windows, un compilador debe poder utilizar las DLL específicas de Microsoft mencionadas anteriormente (los objetos COM están fuera de Win32 y asumen un diseño de tabla virtual determinado). El compilador debe manejar los archivos de encabezado que exponen los nombres de las funciones de la API interna o proporcionar dichos archivos.
Para el lenguaje C++, Zortech (posteriormente Symantec , luego Digital Mars ), Watcom y Borland han producido compiladores comerciales muy conocidos que se han utilizado a menudo con Win16, Win32s y Win32. Algunos de ellos suministraban extensores de memoria , lo que permitía que los programas Win32 se ejecutaran en Win16 con la DLL Win32s redistribuible de Microsoft. El compilador Zortech fue probablemente uno de los primeros compiladores de C++ estables y utilizables para la programación en Windows, antes de que Microsoft tuviera un compilador de C++.
Para ciertas clases de aplicaciones, el sistema compilador también debería ser capaz de manejar archivos de lenguaje de descripción de interfaz (IDL). En conjunto, estos requisitos previos (compiladores, herramientas, bibliotecas y encabezados) se conocen como Microsoft Platform SDK . Durante un tiempo, Microsoft Visual Studio y el sistema de desarrollo integrado de Borland eran los únicos entornos de desarrollo integrados (IDE) que podían proporcionar esto (aunque el SDK se puede descargar de forma gratuita por separado de todo el conjunto de IDE, desde Microsoft Windows SDK para Windows 7 y .NET Framework 4).
A partir de 2016 [update], los proyectos MinGW y Cygwin también proporcionan un entorno de este tipo basado en la Colección de compiladores GNU (GCC), utilizando un conjunto de archivos de encabezado independientes, para simplificar la vinculación con las DLL específicas de Win32. LCC-Win32 es un compilador de C mantenido por Jacob Navia, freeware para uso no comercial. Pelles C es un compilador de C freeware mantenido por Pelle Orinius. Free Pascal es un compilador de Object Pascal de software libre que admite la API de Windows. El paquete MASM32 es un proyecto maduro que proporciona soporte para la API de Windows bajo Microsoft Macro Assembler (MASM) mediante el uso de encabezados y bibliotecas personalizados o convertidos del SDK de la plataforma. El ensamblador plano FASM permite crear programas de Windows sin usar un enlazador externo, incluso cuando se ejecuta en Linux.
También se necesita soporte de compiladores específicos de Windows para el Manejo de Excepciones Estructurado (SEH). Este sistema tiene dos propósitos: proporciona un sustrato en el que se puede implementar el manejo de excepciones específico del lenguaje y es la forma en que el núcleo notifica a las aplicaciones de condiciones excepcionales como la desreferenciación de un puntero no válido o un desbordamiento de pila. Los compiladores de C++ de Microsoft/Borland tuvieron la capacidad de usar este sistema tan pronto como se introdujo en Windows 95 y NT, sin embargo, la implementación real no estaba documentada y tuvo que ser revertida para el proyecto Wine y los compiladores libres. SEH se basa en colocar marcos de manejadores de excepciones en la pila y luego agregarlos a una lista enlazada almacenada en el almacenamiento local de subprocesos (el primer campo del bloque de entorno de subprocesos). Cuando se lanza una excepción, el núcleo y las bibliotecas base desenrollan la pila ejecutando manejadores y filtros a medida que se encuentran. Finalmente, cada excepción no manejada por la aplicación será tratada por el manejador de backstop predeterminado, que hace aparecer el diálogo de falla común de Windows.