Comparando as vinculações estática e dinâmica das bibliotecas de tempo de execução do Visual Studio 2005 no Windows CE e no Windows Mobile

Mario Chénier - Microsoft Corporation

Agosto de 2005

Aplica-se a:

  • Microsoft Windows CE

  • Microsoft Visual Studio 2005

  • Dispositivos baseados no Windows Mobile

Resumo: neste artigo, você comparará as vinculações estática e dinâmica das bibliotecas de tempo de execução do Visual Studio 2005 em aplicativos nativos destinados ao sistema operacional Windows CE. (4 páginas impressas).

Nesta página

Introdução
Vinculações dinâmica e estática
Novas bibliotecas de tempo de execução do Visual Studio 2005
Vinculação estática versus vinculação dinâmica no Windows CE
Conclusão

Introdução

O Microsoft Visual Studio 2005 inclui um ambiente de desenvolvimento do C/C++ para dispositivos baseados no Windows Mobile e no Microsoft Windows CE. Ele é o sucessor do Microsoft eMbedded Visual C++ versão 4.0 e permite que os desenvolvedores escrevam aplicativos em C/C++ para plataformas de dispositivos da Microsoft. Como parte do Visual Studio 2005, existe uma versão atualizada da MFC (Microsoft Foundation Classes), da ATL (Active Template Library) e da SCL (Standard C++ Library) para dispositivos, além de um pequeno subconjunto da Secure C Runtime.

Por padrão, os novos aplicativos desenvolvidos com o Visual Studio 2005 destinados às plataformas baseadas no Windows CE são configurados para vincular de forma estática as bibliotecas de tempo de execução, mas poderá haver ocasiões em que você deverá considerar a vinculação dinâmica explícita das bibliotecas de tempo de execução.

Vinculações dinâmica e estática

Uma DLL (biblioteca de vínculo dinâmico) é um arquivo executável que funciona como uma biblioteca compartilhada de funções. A vinculação dinâmica oferece uma forma de um processo chamar uma função que não faz parte do seu código executável. O código executável da função está localizado em uma DLL, que contém uma ou mais funções que são compiladas, vinculadas e armazenadas separadamente dos processos que as utilizam. Apenas as informações necessárias em tempo de execução para localizar o código executável de uma função da DLL estão no módulo executável (um arquivo .dll ou .exe). Essas bibliotecas são "vinculadas dinamicamente" porque são ligadas a um aplicativo quando ele é carregado e executado — e não quando ele é criado.

No caso da vinculação estática, o vinculador obtém todas as funções referenciadas da biblioteca de vínculo estático e a coloca com o código no arquivo executável.

Novas bibliotecas de tempo de execução do Visual Studio 2005

As novas bibliotecas de tempo de execução MFC 8.0, ATL 8.0, SCL 8.0 e CRT 8.0 de dispositivo do Visual Studio 2005 são versões baseadas no computador desktop das bibliotecas de tempo de execução e são subconjuntos baseados em tamanho, desempenho e capacidade da plataforma. Elas não são diferentes para as plataformas do Windows CE, do Pocket PC ou do Smartphone. Sendo assim, você pode sempre contar com as mesmas funcionalidades da biblioteca de tempo de execução. No entanto, as novas bibliotecas de tempo de execução de dispositivo contêm um certo grau de capacidade de reconhecimento da plataforma. A ATL, por exemplo, tem um comportamento diferente nas plataformas DCOM e COM, e também nas plataformas de GUI (interface gráfica do usuário) e sem periféricos. A MFC reconhece o modelo de UI (interface do usuário) e funciona de forma diferente nas plataformas AYGShell e não-AYGShell.

Essas bibliotecas de tempo de execução estão disponíveis tanto como bibliotecas dinâmicas quando estáticas (exceto a SCL, que está disponível apenas como uma biblioteca estática), como mostrado na Tabela 1.

Tabela 1. Bibliotecas de tempo de execução

Biblioteca

Opções de vinculação

Nome da DLL ([d] é a versão de depuração)

"Mini" C de tempo de execução 8.0

Estática e dinâmica

Msvcr80[d].dll

ATL 8.0

Estática e dinâmica

Atl80.dll

MFC 8.0

Estática e dinâmica

Mfc80u[d].dll

SCL 8.0

Somente estática

N/A

Vinculação estática versus vinculação dinâmica no Windows CE

Uma desvantagem em potencial do uso de DLLs é que o aplicativo não é autônomo; ele depende da existência de um módulo de DLL separado, e é responsabilidade do usuário do aplicativo garantir que a DLL dependente esteja disponível na plataforma de destino. Para plataformas do Windows Mobile, a MFC 3.0 está na ROM (memória somente leitura) para fins de compatibilidade com versões anteriores, mas não há garantias da presença da MFC 8.0 no dispositivo. Portanto, os desenvolvedores de aplicativos precisam certificar-se de fornecer a MFC 8.0 de tempo de execução junto com seus aplicativos. Essa abordagem pode fazer com que o produto final completo de aplicativo fique maior do que seria se o aplicativo tivesse sido vinculado de forma estática. Quando você vincula de forma estática as bibliotecas de tempo de execução necessárias no seu aplicativo, o aplicativo torna-se um executável totalmente autônomo. Um executável autônomo pode simplificar o processo de desenvolvimento de um único aplicativo que dê suporte e seja executado em várias plataformas ou em várias versões de um sistema operacional, pois ele reduz a dependência de DLLs adicionais.

Na inicialização do processo, o sistema encerra os processos que estão utilizando a vinculação dinâmica — se uma DLL não encontrada na inicialização do processo for necessária — e exibe uma mensagem de erro para o usuário. Talvez as mensagens de erro não sejam óbvias. Se o arquivo dependente não existir, você obterá uma mensagem de erro do seguinte tipo: Não é possível localizar 'Aplicativo.exe' (ou um de seus componentes). Verifique se o nome e o caminho do arquivo estão corretos e se todas as bibliotecas necessárias estão disponíveis. Se a DLL estiver presente mas não apresentar o mesmo conjunto de recursos, a mensagem de erro será ainda mais imprecisa: 'Aplicativo.exe' não é um aplicativo válido do Pocket PC.

A maioria dos desenvolvedores do Windows tem familiaridade com o conceito de conflitos de versões de DLLs. O conceito refere-se a um dos riscos potenciais de dependência de uma DLL que pode ser atualizada sem o seu controle. Quando outro aplicativo atualiza uma das suas DLLs dependentes, ele pode ser atualizado com uma versão incompatível com aquela que você está utilizando. A DLL pode ser uma versão mais antiga ou mais recente que altera um comportamento do qual você depende explícita ou implicitamente. Em dispositivos baseados no Windows CE, há uma camada extra de complexidade. Na versão para computadores desktop do Win32, você pode proteger-se até um certo ponto certificando-se de que a versão criada e testada é a mesma que foi carregada no sistema operacional. Um método seria colocar a DLL no mesmo diretório do aplicativo, que é o padrão do Visual Studio 2005. No Windows CE, o carregador tem um comportamento diferente e utiliza qualquer ocorrência encontrada na memória com o nome da DLL correspondente. Por exemplo, se o Aplicativo 1 estiver sendo executado e utilizar uma versão da DLL da MFC que esteja no diretório do Aplicativo 1, quando o Aplicativo 2 for iniciado, o sistema operacional usará a DLL carregada pelo Aplicativo 1 e não a versão que faz parte do diretório do Aplicativo 2. De forma semelhante, se o Aplicativo 2 for iniciado primeiro, o Aplicativo 1 usará a versão de DLL do Aplicativo 2. Se as versões não forem compatíveis, o Aplicativo 1 ou o Aplicativo 2 poderá se comportar de forma incorreta, dependendo do aplicativo que for iniciado primeiro.

A vinculação estática pode, em determinadas circunstâncias, fazer com que o aplicativo seja executado mais rápido. Vincular de forma estática o código da biblioteca evita a necessidade de carregar e inicializar a DLL no espaço de memória do aplicativo. O vinculador do Visual Studio 2005 também oferece suporte à geração de código em tempo de vinculação que pode realizar uma otimização que não está disponível com a vinculação dinâmica.

Se o aplicativo tiver sido vinculado de forma dinâmica e a DLL tiver sido carregada na memória por meio de outro processo, vários processos compartilharão uma única cópia da DLL na memória física. Isso economizará memória do sistema. Por outro lado, o sistema operacional Windows deve carregar uma cópia do código consumido da biblioteca na memória para cada aplicativo que esteja vinculado de forma estática.

A vinculação das bibliotecas de tempo de execução de forma dinâmica possibilita que estas bibliotecas sejam atualizadas com correções de bugs ou outras atualizações e que não haja necessidade de recompilação dos aplicativos que as utilizam desde que as APIs de função permaneçam compatíveis. Por outro lado, a vinculação estática requer que todos os aplicativos sejam vinculados novamente para que a atualização possa ser aproveitada.

A vinculação dinâmica na MFC também permite que você crie suas próprias extensões para as classes de bibliotecas da MFC e as coloque em uma DLL de extensão. Não será possível criar DLLs de extensão se você fizer a vinculação estática com as bibliotecas de tempo de execução da MFC.

A vinculação dinâmica pode consumir menos espaço no dispositivo se vários componentes forem vinculados à MFC. Quando vinculado de forma estática, o aplicativo padrão da MFC do Visual Studio 2005 destinado ao Pocket PC baseado no Windows Mobile tem aproximadamente 170 KB a mais em tamanho do que se tivesse sido vinculado de forma dinâmica. Considere que a DLL da MFC ARMV4 tem aproximadamente 650 KB. Se você tiver de três a cinco componentes usando as bibliotecas de tempo de execução do Visual Studio 2005, mais espaço será consumido no dispositivo do que se você estivesse fazendo a vinculação dinâmica.

Conclusão

Há vários pontos a serem considerados ao se decidir pela vinculação estática ou dinâmica das bibliotecas de tempo de execução do Visual Studio 2005. Existem cenários em que a vinculação dinâmica deve ser considerada. Mas a vinculação estática é, normalmente, a mais recomendada; esse é o comportamento padrão dos projetos do Visual Studio 2005. Na maior parte dos dispositivos para o consumidor, apenas poucos aplicativos necessários são instalados; portanto, a vinculação estática provavelmente reduzirá o consumo de memória e aumentará o desempenho do componente. Os benefícios adicionais da vinculação estática, como a capacidade de criar e implantar, com mais facilidade, um único aplicativo em vários dispositivos e várias versões do sistema operacional Windows, ajudarão o desenvolvedor de aplicativos típico.

© .

Mostrar: