La API de Windows , conocida informalmente como WinAPI , es la interfaz de programación de aplicaciones (API) fundamental que permite que un programa informático acceda a las funciones del sistema operativo Microsoft Windows en el que se ejecuta el programa. Los programas acceden a la funcionalidad de la API a través de la tecnología de biblioteca de vínculos dinámicos (DLL).
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.
En esta sección se enumeran los servicios destacados que ofrece la API de Windows. [1]
Los servicios básicos incluyen funciones como el sistema de archivos , los dispositivos , los procesos , los subprocesos y el manejo de errores . Estas funciones residen enkernel.exe,krnl286.exeokrnl386.exearchivos en Windows de 16 bits ykernel32.dll y KernelBase.dllen Windows de 32 y 64 bits. Estos archivos se encuentran en la carpeta\Windows\Sistema32en todas las versiones de Windows. [2]
Los servicios avanzados incluyen funciones que van más allá del núcleo, como el registro de Windows , apagar/reiniciar el sistema (o anularlo), iniciar/detener/crear un servicio de Windows y administrar cuentas de usuario. Estas funciones residen enadvapi32.dllyadvapires32.dllen Windows de 32 bits.
El componente Interfaz de dispositivo gráfico (GDI) proporciona funciones para enviar contenido gráfico a monitores , impresoras y otros dispositivos de salida . Se encuentra engdi.exeen Windows de 16 bits, ygdi32.dllEn Windows de 32 bits en modo de usuario. Se proporciona compatibilidad con GDI en modo kernel mediante win32k.sysel cual se comunica directamente con el controlador de gráficos. [3] [4]
El componente Interfaz de usuario proporciona funciones para crear y administrar ventanas de pantalla y la mayoría de los controles básicos, como botones y barras de desplazamiento , recibir entradas del mouse y del teclado y otras funciones asociadas con la parte de la interfaz gráfica de usuario (GUI) de Windows. Esta unidad funcional reside enusuario.exeen Windows de 16 bits, yusuario32.dllEn Windows de 32 bits. Desde las versiones de Windows XP , los controles básicos residen encomctl32.dll, junto con los controles comunes (Biblioteca de Control Común). [5]
La biblioteca de cuadros de diálogo comunes proporciona cuadros de diálogo estándar para abrir y guardar archivos, elegir color y fuente, etc. La biblioteca reside en un archivo llamadocommdlg.dllen Windows de 16 bits, ycomdlg32.dllen Windows de 32 bits. Se agrupa en la categoría Interfaz de usuario de la API. [6]
La biblioteca de controles comunes proporciona acceso a controles avanzados de interfaz de usuario que incluyen elementos como barras de estado , barras de progreso , barras de herramientas y pestañas . La biblioteca reside en un archivo DLL llamadocommctrl.dllen Windows de 16 bits, ycomctl32.dllen Windows de 32 bits. Se agrupa en la categoría Interfaz de usuario de la API. [7]
El componente Shell de Windows proporciona acceso al shell del sistema operativo . El componente reside enshell.dllen Windows de 16 bits, yshell32.dllen Windows de 32 bits. Las funciones de utilidad liviana de Shell están enshlwapi.dllSe agrupa bajo la categoría Interfaz de usuario de la API. [8] [9]
Los servicios de red proporcionan acceso a las distintas capacidades de red del sistema operativo. Sus subcomponentes incluyen NetBIOS , Winsock , NetDDE , llamada a procedimiento remoto (RPC) y muchos más. Este componente reside ennetapi32.dllen Windows de 32 bits. [10]
El navegador web Internet Explorer (IE) expone API y, como tal, podría considerarse parte de la API de Windows. IE ha estado incluido en el sistema operativo desde Windows 95 OSR2 y ha proporcionado servicios relacionados con la web a las aplicaciones desde Windows 98. [ 11]
La API de Windows es una API basada en lenguaje C. [12] Las funciones y estructuras de datos se pueden consumir a través de la sintaxis C incluyendo windows.h , pero la API se puede consumir 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 de funciones 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 Delphi que expone las características de la API de Windows: el equivalente Pascal de windows.h . [14]
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, las siguientes 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 no proporcionan ni exponen 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. [24]
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. [28]
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.