Compilare un programma C++ con dipendenza solo su kernel32.dll e user32.dll?

Question

Sto lavorando con Visual Studio 2005.

Voglio compilare un semplice programma che funzionerà con qualsiasi versione di Windows 32 bit indipendentemente da quale versione di libreria di runtime C++ installata.

Questo programma chiama le funzioni GetModuleHandle e GetProcAddress senza altre chiamate di funzione e quindi esce quando il codice di uscita è l'indirizzo della funzione.

Come compilare un programma C++ con dipendenza solo da kernel32.dll e user32.dll, senza alcuna libreria di runtime C++?

Answer 1

Impostare /NODEFAULTLIB sotto le opzioni del progetto. Nelle versioni più recenti di Visual C++, devi anche disattivare i controlli di sovraccarico dello stack, poiché questi fanno sì che il compilatore inserisca automaticamente le chiamate alle funzioni della libreria.

MODIFICA: Se si intende realmente "eseguire su QUALSIASI versione di Windows a 32 bit", sarà anche necessario utilizzare editbin per modificare il campo della versione del sottosistema nell'intestazione PE. Altrimenti ci si limita a (IIRC) Windows 2000 e versioni successive quando si costruisce con il linker VC++ 2005, e le versioni più recenti di VC++ sono ancora peggiori (per impostazione predefinita si richiede XP). Windows 2000 è 5.0, è necessario specificare 3.5 o giù di lì per consentire tutte le versioni di NT oltre a Win9x.

Answer 2

Avrai bisogno di definire il proprio punto di ingresso, invece di utilizzare main o WinMain. Il tuo punto di ingresso è una funzione vuota che non accetta argomenti. Devi specificare il nome del linker con /entry:funcName (dove funcName viene sostituito dal nome che hai assegnato alla funzione che desideri utilizzare come punto di ingresso).

Quando si esegue questa operazione, è necessario specificare il sottosistema sul linker, come in /subsystem:console. Si deduce normalmente il sottosistema in base al nome della funzione che trova (vale a dire, main -> Console, WinMain -> Windows), ma quando si utilizza il proprio punto di ingresso, è necessario specificare in modo esplicito. Anche se probabilmente non si vuole, molto spesso, è possibile specificare il sottosistema in modo esplicito anche quando non si specifica il proprio punto di ingresso, in modo (per esempio) è possibile utilizzare main come punto di ingresso per un programma per Windows sottosistema, o WinMain come punto di ingresso per un programma di console.

Answer 3

Controllare le piccole librerie. Anche collegamento statico.

Answer 4

Non sono sicuro del motivo per cui tutti consigliano di non utilizzare la libreria standard . Questo metodo presuppone che tu voglia che il tuo codice sia eseguito su Windows 2000 o successivo e non preoccuparti di perdere il supporto per Win 9x. È comunque possibile utilizzare la libreria standard C/C++ - È possibile utilizzare l'opzione /MT in/pagine C++ Codice generazione, che collegheranno nella libreria standard C statico del progetto.

Tuttavia, due note, la prima da me: l'idea di avere una libreria standard collegato dinamicamente è che tutti i bug nel otterrà patch da Windows Update (in teoria). Se si collega la libreria in modo statico, è necessario ridistribuire l'applicazione per correggere i bug della libreria standard. Quindi non è consigliato.

In secondo luogo, dal l'articolo di MSDN sulla compiler options:

Attenzione Non mescolare statica e versioni dinamiche dei runtime librerie. Avere più di una copia delle librerie di runtime in un processo può causare problemi, perché statici dati in una copia non è condiviso con l'altra copia. Il linker impedisce voi dal collegamento con sia statica che versioni dinamiche all'interno di un file exe, ma è ancora possibile finire con due (o più ) copie dei runtime librerie. Ad esempio, una libreria di collegamento dinamico collegato con le statiche (non-DLL) versioni del runtime librerie possono causare problemi quando viene utilizzato con un file exe che è stato collegato con la dinamica (DLL) versione di le librerie di runtime . (Si dovrebbe anche evitare di mescolare i di debug e non di debug versioni delle librerie in uno processo.)

In breve, facendo questo può causare confusione se si tenta di costruire in altri componenti collegati contro un dinamico libreria standard collegata.

Ovviamente, l'altro lato negativo è che questo renderà anche il tuo eseguibile più grande.

Modifica: il risultato, in depends.exe, è simile a questo: (ovviamente, sto usando Windows a 64 bit, che è disponibile solo per XP e versioni successive ... se vuoi sapere che cosa sembra come nelle finestre a 32 bit, immagina se gli 64 non fossero lì!).

Answer 5

In realtà non è necessario User32.dll sia, gli unici che veramente non può rimuovere sono Kernel32.dll e Ntdll.dll - quelli sono iniettati nel vostro spazio di elaborazione da PsCreateProcess (vale a dire la metà del kernel di come il kernel crea un nuovo processo).