API do Windows - Windows API

A API do Windows , informalmente WinAPI , é o conjunto principal de interfaces de programação de aplicativos (APIs) da Microsoft disponíveis nos sistemas operacionais Microsoft Windows . O nome API do Windows refere-se coletivamente a várias implementações de plataforma diferentes que costumam ser chamadas por seus próprios nomes (por exemplo, API do Win32 ); veja a seção de versões . Quase todos os programas do Windows interagem com a API do Windows. Na linha de sistemas operacionais Windows NT, um pequeno número (como programas iniciados no início do processo de inicialização do Windows ) usa a API nativa .

O suporte ao desenvolvedor está disponível na forma de um kit de desenvolvimento de software , Microsoft Windows SDK , fornecendo documentação e ferramentas necessárias para construir software baseado na API do Windows e interfaces do Windows associadas.

A API do Windows (Win32) é focada principalmente na linguagem de programação C em que suas funções expostas e estruturas de dados são descritas nessa linguagem em versões recentes de sua documentação. No entanto, a API pode ser usada por qualquer compilador ou montador de linguagem de programação capaz de lidar com as estruturas de dados de baixo nível (bem definidas) junto com as convenções de chamada prescritas para chamadas e retornos de chamada . Da mesma forma, a implementação interna da função da API vem sendo desenvolvida em diversas linguagens, historicamente. Apesar de C não ser uma linguagem de programação orientada a objetos , a API do Windows e o Windows foram historicamente descritos como orientados a objetos. Também existem muitas classes e extensões de wrapper (da Microsoft e outros) para linguagens orientadas a objetos que tornam esta estrutura orientada a objetos mais explícita ( Microsoft Foundation Class Library (MFC), Visual Component Library (VCL), GDI + , etc.) . Por exemplo, o Windows 8 fornece a API do Windows e a API do WinRT , que é implementada em C ++ e é orientada a objetos por design.

Visão geral

As funções fornecidas pela API do Windows podem ser agrupadas em oito categorias:

Serviços de Base
Fornece acesso aos recursos básicos disponíveis para um sistema Windows. Estão incluídos itens como sistemas de arquivos , dispositivos , processos , threads e tratamento de erros . Essas funções residem emkernel.exe, krnl286.exe ou krnl386.exe arquivos no Windows de 16 bits e kernel32.dll e KernelBase.dllem Windows de 32 e 64 bits. Esses arquivos residem na pasta\ Windows \ System32 em todas as versões do Windows.
Serviços Avançados
Fornece acesso a funções além do kernel. Estão incluídos itens como o registro do Windows , desligar / reiniciar o sistema (ou abortar), iniciar / parar / criar um serviço do Windows , gerenciar contas de usuário. Essas funções residem emadvapi32.dll e advapires32.dll no Windows de 32 bits.
Interface de dispositivo gráfico
Oferece funções de saída de conteúdo gráfico para monitores , impressoras e outros dispositivos de saída . Reside emgdi.exe no Windows de 16 bits e gdi32.dllno Windows de 32 bits no modo de usuário. O suporte GDI do modo kernel é fornecido pelo win32k.sysqual se comunica diretamente com o driver gráfico.
Interface de usuário
Fornece as funções para criar e gerenciar janelas de tela e a maioria dos controles básicos, como botões e barras de rolagem , receber entrada de mouse e teclado e outras funções associadas à interface gráfica do usuário (GUI) parte do Windows. Esta unidade funcional reside emuser.exe no Windows de 16 bits e user32.dllno Windows de 32 bits. Desde as versões do Windows XP , os controles básicos residem emcomctl32.dll, junto com os controles comuns (Biblioteca de controle comum).
Biblioteca de caixa de diálogo comum
Fornece aos aplicativos as caixas de diálogo padrão para abrir e salvar arquivos, escolher cor e fonte, etc. A biblioteca reside em um arquivo chamadocommdlg.dll no Windows de 16 bits e comdlg32.dllno Windows de 32 bits. Ele é agrupado na categoria Interface do usuário da API.
Biblioteca de controle comum
Fornece aos aplicativos acesso a alguns controles avançados fornecidos pelo sistema operacional. Isso inclui coisas como barras de status , barras de progresso , barras de ferramentas e guias . A biblioteca reside em um arquivo de biblioteca de vínculo dinâmico (DLL) chamadocommctrl.dll no Windows de 16 bits e comctl32.dllno Windows de 32 bits. Ele é agrupado na categoria Interface do usuário da API.
Shell do Windows
O componente da API do Windows permite que os aplicativos acessem funções fornecidas pelo shell do sistema operacional e as alterem e aprimorem. O componente reside emshell.dll no Windows de 16 bits e shell32.dllno Windows de 32 bits. As funções do utilitário Shell Lightweight estão emshlwapi.dll. Ele é agrupado na categoria Interface do usuário da API.
Serviços de rede
Fornece acesso aos vários recursos de rede do sistema operacional. Seus subcomponentes incluem NetBIOS , Winsock , NetDDE , chamada de procedimento remoto (RPC) e muitos mais. Este componente reside emnetapi32.dll no Windows de 32 bits.

Rede

O navegador Internet Explorer (IE) também expõe muitas APIs que são frequentemente usadas por aplicativos e, como tal, podem ser consideradas parte da API do Windows. O IE foi incluído no sistema operacional desde o Windows 95 OSR2 e fornece serviços relacionados à web para aplicativos desde o Windows 98 . Especificamente, é usado para fornecer:

  • Um controle de navegador da web incorporável, contido em shdocvw.dll e mshtml.dll.
  • O serviço de moniker de URL, mantido em urlmon.dll, que fornece objetos COM a aplicativos para resolução de URLs. Os aplicativos também podem fornecer seus próprios manipuladores de URL para outros usarem.
  • Uma biblioteca de cliente HTTP que também leva em consideração as configurações de proxy de todo o sistema (wininet.dll); no entanto, a Microsoft adicionou outra biblioteca de cliente HTTP chamada winhttp.dll, que é menor e mais adequada para alguns aplicativos.
  • Uma biblioteca para auxiliar no suporte de texto multilíngue e internacional (mlang.dll).
  • Transformações DirectX, um conjunto de componentes de filtro de imagem.
  • Suporte a XML (os componentes MSXML, mantidos em msxml * .dll)
  • Acesso aos catálogos de endereços do Windows.

Multimídia

O clássico Windows Multimedia API é colocado em winmm.dll e contém funções para reproduzir arquivos de som, para enviar e receber mensagens MIDI, para acessar joysticks e para facilitar todos os outros recursos do chamado subsistema MCI do Windows, que se origina do Extensões de multimídia disponíveis para Windows 3.0 separadamente e como parte integrante do sistema operacional desde o Windows 3.1, quando estavam localizadas em mmsystem.dll.

Além disso, como parte de todas as versões do Windows desde o Windows 95 OSR2, a Microsoft forneceu as APIs DirectX - um conjunto vagamente relacionado de serviços gráficos e de jogos, que inclui:

  • Direct2D para gráficos vetoriais 2D acelerados por hardware.
  • Direct3D para gráficos 3D acelerados por hardware.
  • DirectSound para acesso à placa de som acelerado por hardware de baixo nível.
  • DirectInput para comunicação com dispositivos de entrada, como joysticks e gamepads.
  • DirectPlay como uma infraestrutura de jogos multijogador. Este componente foi preterido a partir do DirectX 9 e a Microsoft não recomenda mais seu uso para o desenvolvimento de jogos.
  • DirectDraw para gráficos 2D em versões anteriores do DirectX, agora obsoleto e substituído pelo Direct2D.
  • WinG para gráficos 2D em jogos de 16 bits escritos para versões do Windows 3.x. Obsoleto com a versão do Windows 95.

A Microsoft também fornece várias APIs para codificação e reprodução de mídia:

  • DirectShow , que cria e executa pipelines multimídia genéricos. É comparável à estrutura do GStreamer e freqüentemente usado para renderizar vídeos de jogos e construir reprodutores de mídia (o Windows Media Player é baseado nele). DirectShow não é mais recomendado para desenvolvimento de jogos.
  • Media Foundation , uma API de mídia digital mais recente destinada a substituir o DirectShow.

Interação do programa

A API do Windows é projetada principalmente para a interação entre o sistema operacional e um aplicativo. Para a comunicação entre diferentes aplicativos do Windows, a Microsoft desenvolveu uma série de tecnologias junto com a API principal do Windows. Isso começou com o Dynamic Data Exchange (DDE), que foi substituído pelo Object Linking and Embedding (OLE) e posteriormente pelo Component Object Model (COM), objetos de automação , controles ActiveX e .NET Framework . Nem sempre há uma distinção clara entre essas tecnologias e há muita sobreposição.

A variedade de termos é basicamente o resultado do agrupamento de mecanismos de software que se relacionam a um determinado aspecto do desenvolvimento de software. A automação está especificamente relacionada à exportação da função de um aplicativo ou componente (como uma interface de programação de aplicativo (API)) para que possa ser controlado por outros aplicativos em vez de apenas por usuários humanos. .NET é uma tecnologia e metodologia geral independente para desenvolver aplicativos de desktop e da Web escritos em uma variedade de linguagens compiladas just-in-time (JIT) .

Windows.pas é uma unidade Pascal / Delphi que contém as declarações de API específicas do Windows . É o Pascal equivalente a windows.h , usado em C.

Bibliotecas Wrapper

Vários wrappers foram desenvolvidos pela Microsoft que assumiram algumas das funções de nível mais baixo da API do Windows e permitiram que os aplicativos interagissem com a API de uma maneira mais abstrata. A Microsoft Foundation Class Library (MFC) empacotou a funcionalidade da API do Windows em classes C ++ e, portanto, permite uma maneira mais orientada a objetos de interagir com a API. A Active Template Library (ATL) é um wrapper orientado a modelos para COM. A Windows Template Library (WTL) foi desenvolvida como uma extensão da ATL e pretende ser uma alternativa menor ao MFC.

A maioria das estruturas de aplicativos para Windows (pelo menos parcialmente) envolvem a API do Windows. Portanto, o .NET Framework e o Java , assim como quaisquer outras linguagens de programação no Windows, são (ou contêm) bibliotecas de wrapper.

História

A API do Windows sempre expôs uma grande parte da estrutura subjacente dos sistemas Windows aos programadores. Isso tinha a vantagem de dar a eles muita flexibilidade e poder sobre seus aplicativos, mas também cria uma grande responsabilidade em como os aplicativos lidam com várias operações de baixo nível, às vezes tediosas, associadas a uma interface gráfica de usuário .

Por exemplo, um programador C iniciante geralmente escreverá o simples "hello world" como sua primeira atribuição. A parte funcional do programa é apenas uma única linha printf dentro da sub-rotina principal. A sobrecarga para vincular à biblioteca de E / S padrão também é apenas uma linha: 

#include <stdio.h>

int main(void) {
    printf("Hello, World!\n");
}

A versão do Windows ainda era apenas uma linha de código funcional, mas exigia muito, muito mais linhas de sobrecarga. Charles Petzold , que escreveu vários livros sobre programação para a API do Windows, disse: "O programa hello world original no SDK do Windows 1.0 foi um pouco um escândalo. HELLO.C tinha cerca de 150 linhas e o script de recurso HELLO.RC tinha outras 20 ou mais linhas. (...) Os programadores veteranos muitas vezes se encolhiam de terror ou riam ao encontrar o programa hello-world do Windows. "

Ao longo dos anos, várias alterações e adições foram feitas aos sistemas Windows, e a API do Windows mudou e cresceu para refletir isso. A API do Windows para Windows 1.0 oferece suporte a menos de 450 chamadas de função , enquanto as versões modernas da API do Windows oferecem suporte a milhares. No entanto, em geral, a interface permaneceu bastante consistente e um aplicativo antigo do Windows 1.0 ainda parecerá familiar para um programador que está acostumado com a API do Windows moderna.

A Microsoft fez um esforço para manter a compatibilidade com versões anteriores . Para conseguir isso, ao desenvolver novas versões do Windows, a Microsoft às vezes implementava soluções alternativas para permitir a compatibilidade com software de terceiros que usava a versão anterior de forma não documentada ou mesmo desaconselhável. Raymond Chen , um desenvolvedor da Microsoft que trabalha na API do Windows, disse: "Provavelmente, poderia escrever durante meses apenas sobre coisas ruins que os aplicativos fazem e o que tínhamos que fazer para fazê-los funcionar novamente (muitas vezes apesar de si mesmos). É por isso que fico particularmente furioso quando as pessoas acusam a Microsoft de quebrar aplicativos maliciosamente durante as atualizações do sistema operacional. Se algum aplicativo falhou ao rodar no Windows 95, considerei isso uma falha pessoal. "

Uma das maiores mudanças na API do Windows foi a transição do Win16 (distribuído no Windows 3.1 e anterior) para o Win32 (Windows NT e Windows 95 e superior). Embora o Win32 tenha sido originalmente introduzido com o Windows NT 3.1 e o Win32s permitisse o uso de um subconjunto do Win32 antes do Windows 95, não foi até o Windows 95 que a transferência generalizada de aplicativos para o Win32 começou. Para facilitar a transição, no Windows 95, para desenvolvedores fora e dentro da Microsoft, um esquema complexo de thunks de API foi usado que poderia permitir que o código de 32 bits chame o código de 16 bits (para a maioria das APIs do Win16) e vice-versa. Os flat thunks permitiam que o código de 32 bits chamasse bibliotecas de 16 bits, e o esquema foi usado extensivamente nas bibliotecas do Windows 95 para evitar a portabilidade de todo o sistema operacional para o Win32 em um lote. No Windows NT, o sistema operacional era puro de 32 bits, exceto partes para compatibilidade com aplicativos de 16 bits, e apenas thunks genéricos estavam disponíveis para conversão de Win16 para Win32, como no Windows 95. O SDK da plataforma fornecido com um compilador que poderia produzir o código necessário para esses thunks. As versões do Windows de 64 bits também podem executar aplicativos de 32 bits via WoW64 . A pasta SysWOW64 localizada na pasta Windows na unidade do sistema operacional contém várias ferramentas para oferecer suporte a aplicativos de 32 bits.

Versões

Quase todas as novas versões do Microsoft Windows apresentam suas próprias adições e alterações à API do Windows. O nome da API, no entanto, permaneceu consistente entre as diferentes versões do Windows, e as alterações de nome foram mantidas limitadas às principais alterações arquitetônicas e de plataforma do Windows. A Microsoft acabou mudando o nome da família de APIs do Win32 para Windows API e o transformou em um termo genérico para as versões anteriores e futuras da API.

  • Win16 é a API para as primeiras versões de 16 bits do Microsoft Windows . Inicialmente, eles foram chamados simplesmente de API do Windows , mas posteriormente foram renomeados para Win16 em um esforço para diferenciá-los da versão mais recente de 32 bits da API do Windows. As funções da API Win16 residem principalmente nos arquivos principais do sistema operacional: kernel.exe (ou krnl286.exe ou krnl386.exe ), user.exe e gdi.exe . Apesar da extensão do arquivo deExe, essas são, na verdade, bibliotecas de vínculo dinâmico .
  • Win32 é a interface de programação de aplicativo (API) de 32 bits para versões do Windows de 95 em diante. A API consiste em funções implementadas, como no Win16, em DLLs de sistema. As DLLs principais do Win32 são kernel32.dll , user32.dll e gdi32.dll . O Win32 foi introduzido com o Windows NT . A versão do Win32 fornecida com o Windows 95 foi inicialmente referida como Win32c, com c significando compatibilidade . Este termo foi posteriormente abandonado pela Microsoft em favor do Win32.
  • Win32s é uma extensão dafamília Windows 3.1x do Microsoft Windows que implementou um subconjunto da API do Win32 para esses sistemas. O "s" significa "subconjunto".
  • Win64 é a variante da API implementada em plataformas de 64 bits da arquitetura Windows (a partir de 2021 x86-64 e AArch64 ). As versões de 32 e 64 bits de um aplicativo ainda podem ser compiladas de uma base de código , embora algumas APIs mais antigas tenham sido substituídas e algumas das APIs que já eram obsoletas no Win32 tenham sido removidas. Todos os ponteiros de memória são de 64 bits por padrão (o modelo LLP64 ), portanto, o código-fonte deve ser verificado para compatibilidade com a aritmética de ponteiro de 64 bits e reescrito conforme necessário.
  • WinCE é a implementação da API do Windows para o sistema operacional Windows CE .

Outras implementações

O projeto Wine fornece uma camada de compatibilidade da API Win32 para plataformas do tipo Unix , entre a API do kernel do Linux e programas escritos para a API do Windows. O ReactOS vai um passo além e visa implementar o sistema operacional Windows completo, trabalhando em estreita colaboração com o projeto Wine para promover a reutilização e compatibilidade do código. DosWin32 e HX DOS Extender são outros projetos que emulam a API do Windows para permitir a execução de programas simples do Windows a partir de uma linha de comando do DOS . Odin é um projeto para emular o Win32 no OS / 2 , substituindo a emulação original do Win-OS / 2 que era baseada no código da Microsoft. Outras implementações menores incluem as bibliotecas MEWEL e Zinc, que pretendiam implementar um subconjunto da API Win16 no DOS (consulte Lista de bibliotecas de GUI independentes de plataforma ).

O Windows Interface Source Environment (WISE) era um programa de licenciamento da Microsoft que permitia aos desenvolvedores recompilar e executar aplicativos baseados no Windows em plataformas Unix e Macintosh . Os SDKs WISE foram baseados em um emulador da API do Windows que podia ser executado nessas plataformas.

Os esforços para a padronização incluíram a Interface Pública do Windows da Sun (PWI) para Win16 (consulte também: Interface Binária do Aplicativo Sun Windows ( Wabi )), a Interface de Programação de Aplicativos do Willows Software para Windows (APIW) para Win16 e Win32 (consulte também: Willows TWIN ), e ECMA-234 , que tentou padronizar a API do Windows de forma vinculativa.

Suporte a compilador

Para desenvolver software que usa a API do Windows, um compilador deve ser capaz de usar as DLLs específicas da Microsoft listadas acima (os objetos COM estão fora do Win32 e assumem um determinado layout vtable). O compilador deve manipular os arquivos de cabeçalho que expõem os nomes das funções internas da API ou fornecer esses arquivos.

Para a linguagem C ++, Zortech (mais tarde Symantec , então Digital Mars ), Watcom e Borland produziram compiladores comerciais bem conhecidos que têm sido usados ​​frequentemente com Win16, Win32s e Win32. Alguns deles forneciam extensores de memória , permitindo que programas Win32 rodassem em Win16 com a DLL Win32s redistribuível da Microsoft. O compilador Zortech foi provavelmente um dos primeiros compiladores C ++ estáveis ​​e utilizáveis ​​para a programação do Windows, antes que a Microsoft tivesse um compilador C ++.

Para certas classes de aplicativos, o sistema compilador também deve ser capaz de lidar com arquivos de linguagem de descrição de interface (IDL). Coletivamente, esses pré-requisitos (compiladores, ferramentas, bibliotecas e cabeçalhos) são conhecidos como Microsoft Platform SDK . Por um tempo, o Microsoft Visual Studio e o sistema de desenvolvimento integrado da Borland eram os únicos ambientes de desenvolvimento integrado (IDEs) que podiam fornecer isso (embora o SDK possa ser baixado gratuitamente separadamente de todo o pacote IDE, no SDK do Microsoft Windows para Windows 7 e .NET Framework 4 ).

A partir de 2016, os projetos MinGW e Cygwin também fornecem um ambiente baseado no GNU Compiler Collection (GCC), usando um conjunto de arquivos de cabeçalho autônomo, para tornar simples a vinculação com DLLs específicas do Win32. LCC-Win32 é um compilador C mantido por Jacob Navia, freeware para uso não comercial. Pelles C é um compilador C freeware mantido por Pelle Orinius. Free Pascal é um compilador Object Pascal de software livre que suporta a API do Windows. O pacote MASM32 é um projeto maduro que fornece suporte para a API do Windows no Microsoft Macro Assembler (MASM) usando cabeçalhos personalizados ou convertidos e bibliotecas do SDK da plataforma. Flat assembler FASM permite construir programas Windows sem usar um linker externo, mesmo quando rodando em Linux.

O suporte do compilador específico do Windows também é necessário para o Structured Exception Handling (SEH). Esse sistema tem dois propósitos: fornece um substrato no qual o tratamento de exceções específico da linguagem pode ser implementado e é como o kernel notifica os aplicativos sobre condições excepcionais, como desreferenciar um ponteiro inválido ou estouro de pilha. Os compiladores Microsoft / Borland C ++ tinham a capacidade de usar este sistema assim que ele foi introduzido no Windows 95 e NT, no entanto, a implementação real não estava documentada e teve que sofrer engenharia reversa para o projeto Wine e compiladores gratuitos. SEH é baseado em enviar quadros de manipulador de exceção para a pilha e, em seguida, adicioná-los a uma lista vinculada armazenada no armazenamento local de thread (o primeiro campo do bloco de ambiente de thread). Quando uma exceção é lançada, o kernel e as bibliotecas base desenrolam os manipuladores e filtros em execução da pilha à medida que são encontrados. Eventualmente, cada exceção não tratada pelo aplicativo será tratada pelo manipulador de backstop padrão, que abre a caixa de diálogo de travamento comum do Windows.

Veja também

Notas

links externos