Che cosa fa il linker flag / tsaware fare per l'eseguibile PE?
-
12-09-2019 - |
Domanda
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?
Soluzione
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
Altri suggerimenti
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.