La API de Windows , informalmente 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.
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, se refiere colectivamente a todas las versiones de esta capacidad de Windows.
Microsoft proporciona soporte a los 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.sys
que 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 la sintaxis C (ver windows.h ). Sin embargo, 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 a funciones y devoluciones de llamadas .
Es de destacar que la implementación interna de las 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 (POO), la API de Windows está algo orientada a objetos debido al uso de identificadores. Varias otras tecnologías de Microsoft y otros 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+ . Es de 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 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á destinada principalmente a 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 existe mucha superposición.
La variedad de términos es básicamente el resultado de agrupar 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 web y de escritorio escritas en una variedad de lenguajes compilados justo a tiempo (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 envolturas de 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 . [15]
La API de Windows siempre ha expuesto a los programadores una gran parte de la estructura subyacente de los sistemas Windows. 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 diversas operaciones de bajo nivel, a veces tediosas, asociadas con una interfaz gráfica de usuario .
Por ejemplo, un programador principiante en C a menudo escribirá el simple "hola mundo" como su primera tarea. La parte funcional del programa es solo una línea printf dentro de la subrutina principal. La sobrecarga para vincular a la biblioteca de E/S estándar también es de una sola 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 hello world original en el SDK de Windows 1.0 fue un poco escandaloso. HELLO.C tenía aproximadamente 150 líneas y el script de recursos HELLO.RC tenía otras 20 líneas más (...) Los programadores veteranos a menudo se encogían de horror o de risa cuando se encontraban con el programa Hello-World de Windows." [16] Petzold explica que si bien fue el primer programa de muestra de Windows que conocieron los desarrolladores, era bastante "elegante" y más complejo de lo necesario. Cansado de que la gente ridiculizara la longitud de la muestra, finalmente la 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 a funciones , mientras que las versiones modernas de la API de Windows admiten miles. Sin embargo, en general, la interfaz se mantuvo bastante consistente y una aplicación antigua de Windows 1.0 todavía le resultará familiar a un programador 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 en ocasiones implementaba soluciones alternativas [20] para permitir la compatibilidad con software de terceros que utilizaban la versión anterior de forma 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 sí mismas). Es por eso que me enojo particularmente cuando la gente acusa a Microsoft de dañar maliciosamente aplicaciones durante las actualizaciones del sistema operativo. Si alguna aplicación no se ejecutaba en Windows 95, lo tomaba como un error personal". [21]
Uno de los cambios más importantes 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). Si bien Win32 se introdujo originalmente con Windows NT 3.1 y Win32s permitía el uso de un subconjunto de Win32 antes de Windows 95, no fue hasta Windows 95 que comenzó la migración generalizada de aplicaciones a Win32. Para facilitar la transición, en Windows 95, para los desarrolladores fuera y dentro de Microsoft, se utilizó un esquema complejo de procesadores API que podía permitir que el código de 32 bits llamara al código de 16 bits (para la mayoría de las API de Win16) y viceversa. Los procesadores planos permitieron que el código de 32 bits llamara a bibliotecas de 16 bits, y el esquema se usó 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 puro de 32 bits, excepto partes para la compatibilidad con aplicaciones de 16 bits, y sólo había procesadores genéricos disponibles para procesar de Win16 a Win32, como en Windows 95. El SDK de 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 de 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 todas las versiones nuevas de Microsoft Windows han 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, simplemente se llamaba 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 API Win32 para plataformas tipo Unix , entre la API del kernel de Linux y los programas escritos para la API de Windows. ReactOS va un paso más allá y pretende implementar el sistema operativo Windows completo, trabajando estrechamente con el proyecto Wine para promover la reutilización y la compatibilidad del código. DosWin32 y HX DOS Extender son otros proyectos que emulan la API de Windows para permitir ejecutar programas simples de Windows desde una línea de comandos de DOS . Odin es un proyecto para emular Win32 en OS/2 , reemplazando la emulación original de Win-OS/2 que se basaba en el 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 licencia 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 aplicaciones de Sun Windows ( Wabi )), la Interfaz de programación de aplicaciones de Willows Software para Windows (APIW) para Win16 y Win32 (ver también: Willows TWIN ), y ECMA-234 , que intentó estandarizar la API de Windows de forma vinculante.
Para desarrollar software que utilice la API de Windows, un compilador debe poder utilizar las DLL específicas de Microsoft enumeradas anteriormente (los objetos COM están fuera de Win32 y asumen un determinado diseño de tabla virtual). El compilador debe manejar los archivos de encabezado que exponen los nombres de las funciones internas de la API o proporcionar dichos archivos.
Para el lenguaje C++, Zortech (más tarde Symantec , luego Digital Mars ), Watcom y Borland han producido compiladores comerciales bien conocidos que se han utilizado a menudo con Win16, Win32s y Win32. Algunos de ellos proporcionaron extensores de memoria , lo que permitió que los programas Win32 se ejecutaran en Win16 con la DLL redistribuible de Win32s de Microsoft. El compilador Zortech fue probablemente uno de los primeros compiladores de C++ estables y utilizables para la programación de Windows, antes de que Microsoft tuviera un compilador de C++.
Para ciertas clases de aplicaciones, el sistema compilador también debería poder 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 fueron los únicos entornos de desarrollo integrados (IDE) que podían proporcionar esto (aunque el SDK se puede descargar de forma gratuita por separado de toda la suite IDE, desde Microsoft Windows SDK para Windows). 7 y .NET Framework 4).
A partir de 2016 [actualizar], los proyectos MinGW y Cygwin también proporcionan un entorno de este tipo basado en GNU Compiler Collection (GCC), utilizando un conjunto de archivos de encabezado independiente, para simplificar la vinculación con las DLL específicas de Win32. LCC-Win32 es un compilador de C mantenido por Jacob Navia, software gratuito para uso no comercial. Pelles C es un compilador de C gratuito mantenido por Pelle Orinius. Free Pascal es un compilador de software gratuito Object Pascal que admite la API de Windows. El paquete MASM32 es un proyecto maduro que brinda soporte para la API de Windows en Microsoft Macro Assembler (MASM) mediante el uso de encabezados y bibliotecas personalizados o convertidos desde Platform SDK. El ensamblador plano FASM permite crear programas de Windows sin utilizar un enlazador externo, incluso cuando se ejecuta en Linux.
También se necesita compatibilidad con el compilador específico de Windows para el manejo estructurado de excepciones (SEH). Este sistema tiene dos propósitos: proporciona un sustrato sobre el cual se puede implementar el manejo de excepciones específico del lenguaje y es la forma en que el kernel notifica a las aplicaciones sobre condiciones excepcionales, como la desreferenciación de un puntero no válido o un desbordamiento de pila. Los compiladores de Microsoft/Borland C++ tenían la capacidad de utilizar este sistema tan pronto como se introdujo en Windows 95 y NT, sin embargo, la implementación real no estaba documentada y tuvo que someterse a ingeniería inversa para el proyecto Wine y los compiladores libres. SEH se basa en insertar marcos de controlador de excepciones en la pila y luego agregarlos a una lista vinculada almacenada en el almacenamiento local del subproceso (el primer campo del bloque de entorno del subproceso). Cuando se produce una excepción, el kernel y las bibliotecas base desenrollan la pila que ejecuta los controladores y filtros a medida que se encuentran. Con el tiempo, cada excepción no controlada por la aplicación será tratada por el controlador de respaldo predeterminado, que muestra el cuadro de diálogo de bloqueo común de Windows.