O que o sinalizador de vinculador / tsaware fazer para o executável PE?

Question

Depois de adicionar o sinalizador de vinculador / tsaware para um dos meus projetos (Visual Studio 6), fiquei surpreso de encontrar uma nova seção no arquivo PE (.idata). Se eu não definir o sinalizador, as importações são fundidos em .rdata.

Para ilustrar o "problema" começamos com um simples programa de console:

#include <stdio.h>
int main() 
{
    printf("hello world\n");
    return 0;
}

e compilação com: cl /Og /O1 /GF /WX /c main.c

Então ligação com

• link /MACHINE:IX86 /SUBSYSTEM:CONSOLE /RELEASE /OUT:a.exe main.obj
• link /MACHINE:IX86 /SUBSYSTEM:CONSOLE /RELEASE /OUT:b.exe /TSAWARE main.obj

Vamos comparar a saída de dumpbin:

Dump of file a.exe

File Type: EXECUTABLE IMAGE

  Summary

        4000 .data
        1000 .rdata
        5000 .text

Dump of file b.exe

File Type: EXECUTABLE IMAGE

  Summary

        4000 .data
        1000 .idata
        1000 .rdata
        5000 .text

Então, por algum motivo, o vinculador decide que as importações não podem ser mescladas.

Mas se corremos editbin /TSAWARE a.exe apenas o campo características DLL no PE cabeçalho opcional é alterado.

Alguém pode explicar isso para mim? É este um erro no vinculador ou pode o executável alterado por Editbin acabam não funcionando em determinados sistemas?

Answer 1

Apenas um palpite: em um sistema de servidor de terminal, você quer uma imagem de ter algumas páginas escritas à possível. Se uma página de memória que corresponde à imagem não é modificado, uma única página de RAM física pode ser mapeada em EASH sessão que está usando essa imagem. Se uma página a partir de uma imagem é modificado, o sistema tem de realizar uma operação de copy-on-write para cada instância da página entre todas as sessões e usar um bloco diferente de memória física para representar a página em cada sessão.

Uma vez que as importações para uma imagem precisa, muitas vezes a fixar-se se a DLL que está sendo importado tiveram de ser realocados, as páginas que mantêm as importações muitas vezes são modificados e, portanto, não pode participar na partilha entre as sessões. Se o vinculador mescla as importações com outros dados que geralmente não é modificado, pode aumentar o número de páginas copy-on-write desnecessariamente.

Este pode ser um tipo de otimização que ajuda a reduzir o número de páginas copiadas em todo sessões.

Como eu disse embora - isso é puramente uma suposição

.

Answer 2

O comentário de @WarrenP está correto. De acordo com a MSDN documentação :

A opção / tsaware define um sinalizador no IMAGE_OPTIONAL_HEADER campo DllCharacteristics no cabeçalho opcional imagem do programa do. Quando esta bandeira está definido, Terminal Server não vai fazer algumas alterações na aplicação.

Quando um aplicativo não é Terminal Server ciente (também conhecido como um aplicativo herdado), Terminal Server faz certas modificações o aplicativo de legado para que ele funcione corretamente em um multiusuário meio Ambiente. Por exemplo, Terminal Server irá criar um virtual pasta do Windows, de modo que cada usuário recebe uma pasta do Windows em vez de ficando diretório do Windows do sistema. Isso dá aos usuários acesso a seus próprios arquivos INI. Além disso, Terminal Server faz com que alguns ajustes para o registro para um aplicativo herdado. Estes modificações retardar o carregamento da aplicação legado no Terminal Servidor.

Se um aplicativo é Terminal Server ciente, ele deve não contar com arquivos INI nem gravar no registro HKEY_CURRENT_USER durante a instalação.

Se você usar / tsaware e sua aplicação ainda usa arquivos INI, os arquivos serão compartilhados por todos os usuários do sistema. Se for esse aceitável, você ainda pode vincular seu aplicativo a / tsaware; caso contrário, você precisa usar / tsaware: Não.

Uma coisa única sugerido aqui é que as chaves de sombra são habilitadas apenas para processos que não são TS consciência.