2012-04-30 16 views
10

Suppongo che la mia domanda riguardi il caricatore CLR. Voglio capire la meccanica dietro la funzionalità CorFlags.exe/32BIT+.Come funziona CorFlags.exe/32BIT +?

Sappiamo che quando si avvia un assieme compilato con il flag Qualsiasi CPU impostato su Windows a 64 bit, viene avviato come processo a 64 bit. Se si esegue CorFlags /32BIT+ su quell'assieme, verrà avviato come processo a 32 bit. Penso che questa sia una caratteristica affascinante.

Ho tante domande su di esso:

  1. Come si realizza?
  2. È coinvolto il caricatore del sistema operativo?
  3. È possibile creare un'applicazione personalizzata (suppongo che non gestita) che carichi CLR a 32 o 64 bit a un desiderio?

C'è un articolo, un libro, un blog, ecc. Che spiega il funzionamento interno di questa funzione?

risposta

5

Questo non è ben documentato in nessun posto che io conosca, posso solo indicarti un articolo MSDN pertinente. Sì, la tua ipotesi è corretta, il caricatore di Windows XP e versioni successive è a conoscenza degli eseguibili gestiti. Carica automaticamente lo shim del caricatore .NET (c: \ windows \ system32 \ mscoree.dll), il punto di accesso pertinente è _CorValidateImage(). La sezione Osservazioni in questo articolo di MSDN legata descrive il meccanismo che trasforma un file exe a 32 bit in un processo a 64 bit:

In Windows XP e versioni successive, il sistema operativo controlli ribassato in moduli gestiti esaminando il bit della directory descrittore COM nell'intestazione del formato file oggetto comune (COFF). Un bit impostato indica un modulo gestito. Se il caricatore rileva un modulo gestito, esso carica Mscoree.dll e chiede _CorValidateImage, che esegue le seguenti operazioni:

  • conferma che l'immagine è un modulo gestito valido.
  • Modifica il punto di ingresso nell'immagine in un punto di ingresso nel Common Language Runtime (CLR).
  • Per le versioni a 64 bit di Windows, modifica l'immagine che è in memoria trasformandola da PE32 in formato PE32 +.
  • Torna al caricatore quando vengono caricate le immagini del modulo gestito.

Per le immagini eseguibili, il caricatore del sistema operativo richiama la funzione _CorExeMain, indipendentemente dal punto di ingresso specificato nel file eseguibile. Per le immagini dell'assieme DLL, il caricatore chiama la funzione _CorDllMain .

_CorExeMain o _CorDllMain esegue le seguenti operazioni:

  • inizializza il CLR.
  • Individua il punto di ingresso gestito dall'intestazione CLR dell'assembly.
  • Inizia l'esecuzione.

Il caricatore chiama la funzione _CorImageUnloading quando le immagini del modulo gestito vengono scaricate.Tuttavia, questa funzione non esegue alcuna azione ; ritorna solo

+0

Grazie per la risposta rapida. Questo è un buon punto di partenza. Volevo scoprire come Clr si occupa delle sezioni .reloc. Ho scavato in sscli, principalmente in pedecoder.h/pewriter.cpp e ho trovato le mie risposte. Ancora ci sono molte domande (ad esempio cosa succede su Windows 2000 x64) ma credo che troverò le risposte in sscli. –

+0

È facile, Windows 2000 x64 è stato visto per l'ultima volta dal grande Yeti bianco. –

+1

Wow. Mi chiedo se ci sia un modo per trarre vantaggio da questa "consapevolezza speciale" per creare file binari corretti (codice nativo) per Windows. – Fowl

2

Per aggiungere la risposta di Hans, esiste anche un codice di modalità kernel di Windows che risponde a tale flag. Ogni eseguibile caricato ha una struttura del kernel, SECTION_IMAGE_INFORMATION, associata ad esso. Ecco le sue informazioni simbolo:

0: kd> dt nt!_SECTION_IMAGE_INFORMATION 
      +0x000 TransferAddress   : Ptr64 Void 
      +0x008 ZeroBits     : Uint4B 
      +0x010 MaximumStackSize   : Uint8B 
      +0x018 CommittedStackSize  : Uint8B 
      +0x020 SubSystemType    : Uint4B 
      +0x024 SubSystemMinorVersion  : Uint2B 
      +0x026 SubSystemMajorVersion  : Uint2B 
      +0x024 SubSystemVersion   : Uint4B 
      +0x028 GpValue     : Uint4B 
      +0x02c ImageCharacteristics  : Uint2B 
      +0x02e DllCharacteristics  : Uint2B 
      +0x030 Machine     : Uint2B 
      +0x032 ImageContainsCode   : UChar 
      +0x033 ImageFlags    : UChar 
      +0x033 ComPlusNativeReady  : Pos 0, 1 Bit 
      +0x033 ComPlusILOnly    : Pos 1, 1 Bit 
      +0x033 ImageDynamicallyRelocated : Pos 2, 1 Bit 
      +0x033 ImageMappedFlat   : Pos 3, 1 Bit 
      +0x033 BaseBelow4gb    : Pos 4, 1 Bit 
      +0x033 Reserved     : Pos 5, 3 Bits 

Le bandiere ComPlusILOnly e ComPlusNativeReady sono legati a .NET, ComPlusILOnly dice semplicemente se l'assemblaggio è CIL solo (non mista o nativa - nel qual caso il montaggio è già specifica architettura), e ComPlusNativeReady è 1 solo se/32BIT + non è impostato (32BITREQ or 32BITPREF in newer CorFlags version). Questi flag vengono controllati durante il nt!PspAllocateProcess e in base a questi viene creato un processo 32-bit o 64-bit.

I wrote about it con alcuni dettagli.

+0

Mille grazie !!! Mi sono confuso nel calcolo di alcuni offset di campi di questa struttura utilizzando informazioni obsolete nel riferimento Native API di Windows NT/2000. –