2009-05-15 16 views
37

Ho sentito sull'architettura Windows x64, per supportare l'esecuzione di entrambe le applicazioni x86 e x64, esistono due distinti/diversi set di registro di Windows: uno per l'applicazione x86 per accedere e l'altro per l'applicazione x64 per accesso? Ad esempio, se una COM registra CLSID nella serie x86 di registro, l'applicazione x64 non sarà mai in grado di accedere al componente COM da CLSID, poiché x86/x64 ha set di registri diversi?Registro di sistema Windows a 64 bit v.s. Registro di 32 bit

Quindi, la mia domanda è se la mia comprensione del campione sopra è corretta? Voglio anche avere più documenti per imparare questo argomento, sui due diversi set di registro su architettura x64. (Ho fatto qualche ricerca, ma non ho trovato alcuna informazione di valore.)

grazie in anticipo, George

risposta

52

Mi sono imbattuto in questo problema non molto tempo fa. La risposta breve è che se si esegue un'applicazione a 32 bit su un computer a 64 bit, le sue chiavi di registro si trovano sotto un Wow6432Node.

Per esempio, diciamo che dispone di un'applicazione che memorizza le informazioni di Registro di sistema:

HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX 

Se si compila l'applicazione come un 64 bit binari e si esegue su una macchina a 64 bit quindi le chiavi di registro sono nella posizione sopra. Tuttavia, se si compila l'applicazione come un 32 bit binari e si esegue su una macchina a 64 bit quindi le informazioni di Registro di sistema si trova ora qui:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX 

Questo significa che se si esegue entrambe le versioni a 32 bit e 64 bit della tua applicazione sulla stessa macchina, allora ognuno di loro guarderà un diverso set di chiavi di registro.

+2

Una domanda veloce, se sto usando regsvr32 per registrare un componente COM, come facevamo a sapere se ci registriamo sotto il registro x86 o x64? La mia ocnfusion è, se registrata sotto il registro x86, l'applicazione x64 non sarà in grado di accedere al componente COM? – George2

+7

Esistono due versioni di regsrv32 su una macchina a 64 bit. Uno registra binari a 64 bit e uno registra binari a 32 bit nel nodo Wow6432. Questo articolo di Microsoft KB potrebbe essere utile per te: http://support.microsoft.com/kb/282747 –

+0

1. quando registriamo un nuovo componente COM utilizzando regsvr32 a 32 bit, il componente COM deve essere compilato per x86 (quando registrare un nuovo componente COM usando regsvr32 a 64 bit, il componente COM deve essere costruito per x64) - significa che non possiamo usare regsvr32 a 32 bit per registrare componenti COM a 64 bit (o usare regsvr32 a 64 bit per registrare 32 bit Componente COM), corretto? 2. Il processo a 64 bit potrebbe solo accedere al registro x64 per COM CLSID e il processo a 32 bit potrebbe accedere solo al registro x86 per COM CLISD, senza accesso incrociato. La mia comprensione è corretta? – George2

1

Ecco l'articolo di Wikipedia sul registro WOW64 che potrebbe dare alcune delle informazioni che state cercando:

http://en.wikipedia.org/wiki/WOW64

+0

Supponiamo di avere un'applicazione .Net creata per qualsiasi CPU ed eseguirla su x64, quindi dovrebbe essere JIT per accedere alla versione x64 del registro, cioè i CLSID di COM registrati nel registro x64, e se registro un 32- componente COM bit, l'applicazione .Net non sarà in grado di trovarlo? La mia comprensione è corretta? – George2

6

La tua comprensione è corretta. Non ci sarebbe bisogno di un'app x64 per accedere ai CLSID x86 poiché non potrebbe mai caricare quei componenti e viceversa.

Se si desidera creare un componente da utilizzare sia per x86 che per x64, è necessario creare una coppia di DLL una creata per x86 e l'altra per x64 e registrarle entrambe nelle parti appropriate del registro. Regsrv32.exe nella cartella System32 registrerà perversamente il componente x64 e regsrv32.exe nella cartella SysWOW64 registrerà il componente x86.

In alternativa, creare un assembly .NET per qualsiasi CPU che può essere utilizzato dall'architettura della CPU.

+0

@AnthonyWJones, sono interessato a .Net Qualsiasi esempio di CPU che hai menzionato. Supponiamo di avere un'applicazione .Net creata per qualsiasi CPU ed eseguirla su x64, quindi dovrebbe essere JIT per accedere alla versione x64 del registro - cioè CLSID di COM registrati nel registro x64? La mia comprensione è corretta? – George2

+1

In questo scenario non è JIT o .NET che decide quale parte del registro cercare i CLSID è il fatto che il processo in cui il codice è in esecuzione è 64 bit che determina quale set userà per cercare i CLSID. Questo è qualcosa che accade automaticamente all'interno delle librerie di supporto COM installate in Windows. – AnthonyWJones

+0

1. quando registriamo un nuovo componente COM usando regsvr32, lo registriamo sotto il registro x86 o sotto il registro x64 o sotto entrambi? 2. La mia comprensione è che il processo a 64 bit potrebbe solo accedere al registro x64 per COM CLSID e il processo a 32 bit potrebbe accedere solo al registro x86 per COM CLISD, senza accesso incrociato. La mia comprensione è corretta? – George2

4

Non sono registri separati: uno è un nodo secondario dell'altro e il sistema operativo esegue la virtualizzazione per assicurarsi che le app a 32 bit ottengano le chiavi e le app a 64 bit che ottengono le chiavi.

+0

Qualche lettura consigliata per un principiante di questo argomento? – George2

+1

L'articolo MSND pubblicato sopra è probabilmente il miglior punto di partenza. http://msdn.microsoft.com/en-us/library/ms724072.aspx –

+0

Una domanda veloce, se sto usando regsvr32 per registrare un componente COM, come facevamo a sapere se registriamo il componente COM sotto x86 o x64 registro di sistema? La mia confusione è, se registrato sotto il registro x86, l'applicazione x64 non sarà in grado di accedere al componente COM? – George2

1

Come registrare .NET assembly da utilizzare come COM in pura applicazione a 64 bit?

Problema: Per impostazione predefinita, se si attiva "Registra per interoperabilità COM" in impostazioni di generazione, non registra libreria di tipo per 64-bit.

Soluzione: Per registrare l'assembly, che non è in GAC su una macchina a 64 bit, finestra aperta cmd e fare:

cd c:\windows\microsoft.net\framework64\v2.x.xxxxx 
regasm /codebase "path to your compiled assembly dll" 

Ciò elimina "Classe non registrata di errore" quando si utilizza nativo C++ per installare .NET assembly come oggetto COM.

+0

Questo è esattamente ciò che causa il fallimento della mia applicazione in modalità mista a 64 bit: gli assembly sono stati registrati a 32 bit da Visual Studio 2010. Quindi, invece di Register per l'interoperabilità COM, ho inserito gli eventi post build al regasm come sopra (con/TLB generazione nel mio caso). C'è un articolo MSDN relativo a questo comportamento? – DaBozUK

Problemi correlati