Che cosa fa il linker flag / tsaware fare per l'eseguibile PE?

Question

Dopo aver aggiunto il flag del linker / tsaware a uno dei miei progetti (Visual Studio 6), sono rimasto sorpreso di trovare una nuova sezione nel file PE (.idata). Se non impostato il flag, le importazioni sono fusi in .rdata.

Per illustrare il "problema" si parte con un semplice programma di console:

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

e compilare con: cl /Og /O1 /GF /WX /c main.c

Poi il collegamento con

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

Mettiamo a confronto l'output 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

Così, per qualche motivo, il linker decide che le importazioni non possono essere unite.

Ma se corriamo editbin /TSAWARE a.exe solo il campo caratteristiche DLL nell'intestazione opzionale PE viene modificato.

Qualcuno può spiegare questo a me? Si tratta di un bug nel linker oppure può l'eseguibile cambiata Editbin finire non funziona su alcuni sistemi?

Answer 1

Solo una supposizione: in un sistema di server terminal, si vuole un'immagine per avere un paio di pagine scritte a più possibile. Se una pagina di memoria che corrisponde all'immagine non viene modificato, una singola pagina di RAM fisica può essere attribuita a sessione eash che utilizza tale immagine. Se una pagina da un'immagine viene modificato, il sistema deve eseguire un'operazione di copia su scrittura per ogni istanza della pagina fra tutte le sessioni e utilizzare un altro blocco di memoria fisica per rappresentare la pagina in ogni sessione.

Dal momento che le importazioni per un'immagine spesso bisogno di essere sistemato, se la DLL che viene importata doveva essere trasferito, le pagine che contengono i importazioni spesso vengono modificati e quindi non può partecipare alla condivisione tra le sessioni. Se il linker unisce le importazioni con altri dati che di solito non è modificata, potrebbe aumentare il numero di pagine copy-on-write inutilmente.

Questa potrebbe essere una sorta di ottimizzazione che aiuta a ridurre il numero di pagine copiate attraverso sessioni.

Come ho detto, però -. Questo è puramente una congettura

Answer 2

Il commento da @WarrenP è corretta. Secondo il MSDN documentazione :

  

L'opzione / tsaware imposta un flag nella IMAGE_OPTIONAL_HEADER   campo DllCharacteristics nell'intestazione facoltativa l'immagine del programma. quando   è impostato questo flag, Terminal Server non farà alcune modifiche al   applicazione.

     

Quando un'applicazione non è a conoscenza di Terminal Server (noto anche come   applicazione legacy), Terminal Server rende alcune modifiche   l'applicazione legacy per farlo funzionare correttamente in un multiutente   ambiente. Ad esempio, Terminal Server creerà un virtual   cartella di Windows, in modo tale che ogni utente riceve una cartella di Windows, invece di   ottenendo directory di Windows del sistema. Questo dà l'accesso agli utenti di   i propri file INI. Inoltre, Terminal Server rende un po '   adeguamenti al Registro di sistema per un'applicazione legacy. Questi   modifiche rallentano il caricamento dell'applicazione legacy su Terminal   Server.

     

Se un'applicazione è a conoscenza di Terminal Server, si deve né si basano su   file INI né scrivere al Registro di sistema HKEY_CURRENT_USER durante l'installazione.

     

Se si utilizza / tsaware e l'applicazione utilizza ancora i file INI, le   i file saranno condivisi da tutti gli utenti del sistema. Se questo è   accettabili, è ancora possibile collegare l'applicazione con / tsaware;   altrimenti è necessario utilizzare / tsaware:. NO

Una cosa solo accennato qui è che le chiavi d'ombra sono abilitati solo per i processi che non sono a conoscenza Ts.