API de Windows

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar
El conjunto básico de interfaces de programación de aplicaciones de Microsoft en Windows

La API de Windows, informalmente WinAPI, es el conjunto básico de interfaces de programación de aplicaciones (API) de Microsoft disponible en los sistemas operativos Microsoft Windows. El nombre API de Windows se refiere colectivamente a varias implementaciones de plataformas diferentes a las que a menudo se hace referencia por sus propios nombres (por ejemplo, API Win32); ver la sección de versiones. Casi todos los programas de Windows interactúan con la API de Windows. En la línea de sistemas operativos de Windows NT, un pequeño número (como los programas que se iniciaron temprano en el proceso de inicio de Windows) utilizan la API nativa.

La asistencia para desarrolladores está disponible en forma de un kit de desarrollo de software, Microsoft Windows SDK, que proporciona la documentación y las herramientas necesarias para crear software basado en la API de Windows y las interfaces de Windows asociadas.

La API de Windows (Win32) se centra principalmente en el lenguaje de programación C en el que sus funciones y estructuras de datos expuestas se describen en ese lenguaje en versiones recientes de su documentación. Sin embargo, la API puede ser utilizada por cualquier compilador o ensamblador de lenguaje de programación capaz de manejar estructuras de datos de bajo nivel (bien definidas) junto con las convenciones de llamada prescritas para llamadas y devoluciones de llamada. De igual forma, la implementación interna de la función de la API se ha desarrollado en varios lenguajes, históricamente. A pesar de que C no es un lenguaje de programación orientado a objetos, tanto la API de Windows como Windows se han descrito históricamente como orientados a objetos. También ha habido muchas clases contenedoras y extensiones (de Microsoft y otros) para lenguajes orientados a objetos que hacen que esta estructura orientada a objetos sea más explícita (Microsoft Foundation Class Library (MFC), Visual Component Library (VCL), GDI+, etc.). Por ejemplo, Windows 8 proporciona la API de Windows y la API de WinRT, que se implementa en C++ y está orientada a objetos por diseño.

Resumen

El subsistema Win32 se muestra junto al subsistema POSIX y OS/2 en la arquitectura de Windows NT

Las funciones proporcionadas por la API de Windows se pueden agrupar en ocho categorías:

Servicios de base
Proporcionar acceso a los recursos básicos disponibles para un sistema Windows. Incluye cosas como sistemas de archivos, dispositivos, procesos, hilos y manejo de errores. Estas funciones residen en kernel.exe, krnl286.exe o krnl386.exe archivos en Windows de 16 bits, y kernel32.dll y KernelBase.dll en 32 y 64 bit Windows. Estos archivos residen en la carpeta WindowsSystem32 en todas las versiones de Windows.
Servicios avanzados
Proporcionar acceso a funciones más allá del núcleo. Incluido son cosas como el registro de Windows, apagado / reiniciar el sistema (o abortar), iniciar / detener / crear un servicio de Windows, gestionar cuentas de usuario. Estas funciones residen en advapi32.dll y advapires32.dll en 32-bit Windows.
Interfaz de dispositivo gráfico
Proporciona funciones para producir contenido gráfico para monitores, impresoras y otros dispositivos de salida. reside en gdi.exe en Windows de 16 bits, y gdi32.dll en Windows de 32 bits en modo de usuario. El soporte GDI de moda de kernel es proporcionado por win32k.sys que se comunica directamente con el controlador gráfico.
Interfaz de usuario
Proporciona las funciones para crear y gestionar ventanas de pantalla y controles más básicos, como botones y barras de desplazamiento, recibir entrada de ratón y teclado, y otras funciones asociadas con la interfaz gráfica de usuario (GUI) parte de Windows. Esta unidad funcional reside en user.exe en Windows de 16 bits, y user32.dll en 32-bit Windows. Desde las versiones de Windows XP, los controles básicos residen en comctl32.dll, junto con los controles comunes (Biblioteca de Control Comunitario).
Biblioteca del cuadro de diálogo común
Proporciona aplicaciones los cuadros de diálogo estándar para abrir y guardar archivos, elegir color y fuente, etc. La biblioteca reside en un archivo llamado commdlg.dll en Windows de 16 bits, y comdlg32.dll en 32-bit Windows. Está agrupado bajo el Interfaz de usuario categoría de la API.
Biblioteca Común de Control
Proporciona acceso a aplicaciones a algunos controles avanzados proporcionados por el sistema operativo. Estas incluyen cosas como barras de estado, barras de progreso, barras de herramientas y pestañas. La biblioteca reside en un archivo dinámico de la biblioteca (DLL) llamado commctrl.dll en Windows de 16 bits, y comctl32.dll en 32-bit Windows. Está agrupado bajo el Interfaz de usuario categoría de la API.
Windows Shell
Componente de la API de Windows permite a las aplicaciones acceder a las funciones proporcionadas por la shell del sistema operativo, y cambiar y mejorarlo. El componente reside en shell.dll en Windows de 16 bits, y shell32.dll en 32-bit Windows. Las funciones de Utilidad ligera Shell están en shlwapi.dll. Está agrupado bajo el Interfaz de usuario categoría de la API.
Servicios de red
Dar acceso a las diversas capacidades de networking del sistema operativo. Sus subcomponentes incluyen NetBIOS, Winsock, NetDDE, llamada de procedimiento remoto (RPC) y muchos más. Este componente reside en netapi32.dll en 32-bit Windows.

Internet

El navegador web Internet Explorer (IE) también expone muchas API que las aplicaciones suelen utilizar y, como tales, podrían considerarse parte de la API de Windows. IE se ha incluido con el sistema operativo desde Windows 95 OSR2 y ha proporcionado servicios relacionados con la web a las aplicaciones desde Windows 98. Específicamente, se utiliza para proporcionar:

  • Un control incrustable del navegador web, contenido en shdocvw.dll y mshtml.dll.
  • El servicio de control URL, celebrado en urlmon.dll, que proporciona objetos COM a aplicaciones para resolver URLs. Las aplicaciones también pueden proporcionar sus propios controladores de URL para que otros usen.
  • Una biblioteca de clientes HTTP que también tiene en cuenta los ajustes Proxy de todo el sistema (wininet.dll); sin embargo, Microsoft ha añadido otra biblioteca de clientes HTTP llamada winhttp.dll que es más pequeña y más adecuada para algunas aplicaciones.
  • Una biblioteca para ayudar en varios idiomas y soporte de texto internacional (mlang.dll).
  • DirectX Transforms, un conjunto de componentes de filtro de imagen.
  • Soporte XML (los componentes MSXML, mantenidos en msxml*.dll).
  • Acceso a los Libros de Dirección de Windows.

Multimedia

La clásica API de Windows Multimedia se encuentra en winmm.dll y contiene funciones para reproducir archivos de sonido, enviar y recibir mensajes MIDI, acceder a los joysticks y facilitar todas las demás características del llamado MCI subsistema de Windows, que tiene su origen en las Multimedia Extensions disponibles para Windows 3.0 por separado y como parte integral del sistema operativo desde Windows 3.1, momento en el que se encontraban en mmsystem.dll.

Además, como parte de cada versión de Windows desde Windows 95 OSR2, Microsoft ha proporcionado las API de DirectX, un conjunto de servicios de gráficos y juegos vagamente relacionado, que incluye:

  • Direct2D para gráficos vectoriales 2D acelerados por hardware.
  • Direct3D para gráficos 3D acelerados por hardware.
  • DirectSound para acceso a tarjetas de sonido aceleradas por hardware de bajo nivel.
  • DirectInput for communication with input devices such as joysticks and gamepads.
  • DirectPlay como una infraestructura de juegos multijugador. Este componente ha sido deprecado como de DirectX 9, y Microsoft ya no recomienda su uso para el desarrollo del juego.
  • DirectDraw para gráficos 2D en anteriores Direct X versiones, ahora deprecatadas y reemplazadas por Direct2D.
  • WinG para gráficos 2D en juegos de 16 bits escritos para versiones de Windows 3.x. Deprecated with Windows 95 release.

Microsoft también proporciona varias API para la codificación y reproducción de medios:

  • DirectShow, que construye y ejecuta tuberías multimedia genéricas. Es comparable al marco de GStreamer y a menudo se utiliza para reproducir videos en el juego y crear reproductores multimedia (Windows Media Player se basa en él). Direct Mostrar ya no es recomendado para el desarrollo del juego.
  • Media Foundation, una nueva API de medios digitales para reemplazar DirectShow.

Interacción del programa

La API de Windows está diseñada principalmente para la interacción entre el sistema operativo y una aplicación. Para la comunicación entre diferentes aplicaciones de Windows, Microsoft ha desarrollado una serie de tecnologías junto con la API principal de Windows. Esto comenzó con Dynamic Data Exchange (DDE), que fue reemplazado por Object Linking and Embedding (OLE) y más tarde por Component Object Model (COM), Objetos de automatización, controles ActiveX y.NET Framework. No siempre hay 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 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).

Windows.pas es una unidad Pascal/Delphi que contiene las declaraciones API específicas de Windows. Es el equivalente en Pascal a windows.h, usado en C.

Bibliotecas contenedoras

Microsoft desarrolló varios contenedores que asumieron algunas de las funciones de nivel más bajo de la API de Windows y permitieron que las aplicaciones interactuaran con la API de una manera más abstracta. Microsoft Foundation Class Library (MFC) envolvió la funcionalidad de la API de Windows en clases de C++ y, por lo tanto, permite una forma más orientada a objetos de interactuar con la API. Active Template Library (ATL) es un contenedor orientado a plantillas para COM. La biblioteca de plantillas de Windows (WTL) se desarrolló como una extensión de ATL y se concibió como una alternativa más pequeña a MFC.

La mayoría de los marcos de aplicación para Windows (al menos en parte) envuelven la API de Windows. Por lo tanto,.NET Framework y Java, al igual que cualquier otro lenguaje de programación bajo Windows, son (o contienen) bibliotecas contenedoras.

Historia

La API de Windows siempre ha expuesto una gran parte de la estructura subyacente de los sistemas de Windows a los programadores. Esto tenía la ventaja de brindarles 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 simple "hola mundo" como su primera tarea. La parte de trabajo del programa es solo una sola línea printf dentro de la subrutina principal. La sobrecarga para vincular a la biblioteca de E/S estándar también es solo una línea:

#include Identificado.hint principal()vacío) {} printf()"¡Hola, Mundo!n");}

La versión de Windows seguía siendo solo una línea de código en funcionamiento, pero requería muchas, muchas más líneas generales. Charles Petzold, quien escribió varios libros sobre programación para la API de Windows, dijo: “El programa original hola mundo en el SDK de Windows 1.0 fue un poco escandaloso. HELLO.C tenía unas 150 líneas y el script de recursos HELLO.RC tenía otras 20 líneas más. (...) Los programadores veteranos a menudo se acurrucaban horrorizados o se reían cuando se encontraban con el programa Windows hello-world."

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. 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 aún le parecerá familiar a un programador que está acostumbrado a la API de Windows moderna.

Microsoft se ha esforzado por mantener la compatibilidad con versiones anteriores. Para lograr esto, al desarrollar nuevas versiones de Windows, Microsoft a veces implementaba soluciones alternativas para permitir la compatibilidad con software de terceros que usaban 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 teníamos que hacer para que funcionaran de nuevo (a menudo a pesar de ellas mismas).). Es por eso que me pongo particularmente furioso cuando las personas acusan a Microsoft de romper aplicaciones maliciosamente durante las actualizaciones del sistema operativo. Si alguna aplicación fallaba al ejecutarse en Windows 95, lo tomaba como una falla personal."

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). 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 thunks 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 la migración de todo el sistema operativo a Win32 en un solo lote. En Windows NT, el sistema operativo era puro de 32 bits, excepto partes por compatibilidad con aplicaciones de 16 bits, y solo había procesadores genéricos disponibles para procesar desde Win16 a Win32, como en Windows 95. Platform SDK se envió 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.

Versiones

Casi todas las nuevas versiones de Microsoft Windows han introducido sus propias adiciones y cambios en la API de Windows. Sin embargo, el nombre de la API se mantuvo constante entre las diferentes versiones de Windows, y los cambios de nombre se limitaron a cambios importantes en la arquitectura y la plataforma de Windows. Microsoft finalmente cambió el nombre de la familia de API Win32 actual a API de Windows y lo convirtió en un término general para las versiones de API pasadas y futuras.

  • Win16 es la API para las primeras versiones de 16 bits de Microsoft Windows. These were initially referred to as simply the Windows API, pero luego fueron renombrados a Win16 en un esfuerzo para distinguirlos de la nueva versión de 32 bits de la API de Windows. Las funciones de Win16 API residen principalmente en los archivos básicos del sistema operativo: kernel.exe (o krnl286.exe o krnl386.exe), user.exe y gdi.exe. A pesar de la extensión de archivo exe, en realidad son bibliotecas de enlace dinámico.
  • Win32 es la interfaz de programación de aplicaciones de 32 bits (API) para versiones de 32 bits de Windows (NT, 95 y versiones posteriores). La API consta de funciones implementadas, como con Win16, en el sistema DLLs. Los DLLs centrales de Win32 son kernel32.dll, user32.dll, y gdi32.dll. Win32 fue introducido con Windows NT. La versión de Win32 enviada con Windows 95 fue inicialmente conocida como Win32c, con c significado compatibilidad. Este término fue abandonado posteriormente por Microsoft a favor de Win32.
  • Win32s es una extensión para la familia Windows 3.1x de Microsoft Windows que implementó un subconjunto de la API Win32 para estos sistemas. La "s" significa "subset".
  • Win64 es la variante de la API implementada en plataformas de 64 bits de la arquitectura de Windows (en 2021, x86-64 y AArch64). Tanto las versiones de 32 bits como de 64 bits de una aplicación se pueden compilar de una base de código, aunque algunas API antiguas han sido deprecatadas, y algunas de las API que ya estaban deprecatadas en Win32 fueron eliminadas. Todos los punteros de memoria son de 64 bits por defecto (el modelo LLP64), por lo que el código fuente debe ser revisado para compatibilidad con aritmética puntero de 64 bits y reescrito como sea necesario.
  • WinCE es la implementación de la API de Windows para el sistema operativo Windows CE.

Otras implementaciones

El proyecto Wine proporciona una capa de compatibilidad de API Win32 para plataformas similares a 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 tiene como objetivo implementar el sistema operativo Windows completo, trabajando en estrecha colaboración 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 sencillos 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 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 basaron en un emulador de la API de Windows que podía ejecutarse en esas plataformas.

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.

Soporte del compilador

Para desarrollar software que use la API de Windows, un compilador debe poder usar las DLL específicas de Microsoft enumeradas anteriormente (los objetos COM están fuera de Win32 y asumen un cierto diseño de vtable). 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 usado a menudo con Win16, Win32s y Win32. Algunos de ellos proporcionaron ampliadores de memoria, lo que permitió que los programas Win32 se ejecutaran en Win16 con la DLL Win32s redistribuible de Microsoft. El compilador de 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, 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 Object Pascal de software gratuito que admite la API de Windows. El paquete MASM32 es un proyecto maduro que brinda soporte para la API de Windows bajo Microsoft Macro Assembler (MASM) mediante el uso de encabezados y bibliotecas personalizados o convertidos de Platform SDK. 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 compilador específico de Windows para el manejo estructurado de excepciones (SEH). Este sistema tiene dos propósitos: proporciona un sustrato en el que se puede implementar el manejo de excepciones específico del idioma, y es la forma en que el kernel notifica a las aplicaciones sobre condiciones excepcionales, como la eliminación de referencias de un puntero no válido o el desbordamiento de pila. Los compiladores de Microsoft/Borland C++ tenían 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 realizar ingeniería inversa para el proyecto Wine y los compiladores gratuitos. SEH se basa en insertar marcos del controlador de excepciones en la pila y luego agregarlos a una lista vinculada almacenada en el almacenamiento local de subprocesos (el primer campo del bloque de entorno de subprocesos). Cuando se lanza una excepción, las bibliotecas kernel y base desenredan la pila ejecutando controladores y filtros a medida que se encuentran. Eventualmente, cada excepción no manejada 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.

Contenido relacionado

TAT-1

Konrad Zuse

Heckler & koch

Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save