2009-05-15 10 views
37

Ich hörte auf Windows x64-Architektur, um zu unterstützen, sowohl x86 und x64-Anwendung zu laufen, gibt es zwei separate/verschiedene Sätze von Windows-Registrierung - eine für x86-Anwendung zum Zugriff und die andere für x64-Anwendung zu Zugriff? Beispiel: Wenn ein COM CLSID im x86-Registrierungssatz registriert, kann die x64-Anwendung niemals mit der CLSID auf die COM-Komponente zugreifen, weil x86/x64 über verschiedene Registrierungssätze verfügt.Windows 64-Bit-Registrierung vs. 32-Bit-Registrierung

Also, meine Frage ist, ob mein Verständnis der obigen Probe korrekt ist? Ich möchte auch einige weitere Dokumente zu diesem Thema, über die zwei verschiedenen Sätze von Registrierung auf x64-Architektur zu bekommen. (Ich habe einige Suche, aber keine wertvollen Informationen zu finden.)

Vielen Dank im Voraus, George

Antwort

52

Ich bin vor kurzem auf dieses Problem gestoßen. Die kurze Antwort lautet: Wenn Sie eine 32-Bit-Anwendung auf einer 64-Bit-Maschine ausführen, befinden sich die Registrierungsschlüssel unter einem Wow6432Node.

Zum Beispiel: Angenommen, Sie haben eine Anwendung, die seine Registrierungsinformationen unter speichert:

HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX 

Wenn Sie Ihre Anwendung als 64-Bit-Binär-kompilieren und auf einer 64-Bit-Maschine laufen dann die Registrierungsschlüssel sind an der Stelle oben. Wenn Sie jedoch Ihre Anwendung als 32-Bit-Binär-kompilieren und auf einer 64-Bit-Maschine laufen dann Ihre Registrierungsinformationen jetzt hier befinden:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX 

Das bedeutet, dass, wenn Sie sowohl die 32-Bit- und 64-Bit-Versionen laufen Ihrer Anwendung auf dem gleichen Computer werden sie dann jeweils einen anderen Satz von Registrierungsschlüsseln betrachten.

+2

Eine kurze Frage, wenn ich Regsvr32 verwende, um eine COM-Komponente zu registrieren, woher wussten wir, ob wir unter X86 oder X64 Registrierung registrieren? Meine Überraschung ist, wenn die x64-Anwendung unter der x86-Registrierung registriert ist, nicht auf die COM-Komponente zugreifen kann? – George2

+7

Es gibt zwei Versionen von regsrv32 auf einer 64-Bit-Maschine. In dem Wow6432-Knoten registriert man 64-Bit-Binärdateien und 1 Register 32-Bit-Binärdateien. Dieser Microsoft KB-Artikel könnte für Sie hilfreich sein: http://support.microsoft.com/kb/282747 –

+0

1. Wenn wir eine neue COM-Komponente mit 32-Bit-Regsvr32 registrieren, muss die COM-Komponente für x86 (wenn wir Registrieren Sie eine neue COM-Komponente mit 64-Bit-Regsvr32, die COM-Komponente muss für x64 erstellt werden) - bedeutet, dass wir 32-Bit-Regsvr32 nicht verwenden können, um 64-Bit-COM-Komponente zu registrieren (oder 64-Bit-Regsvr32 zu registrieren 32-Bit) COM-Komponente), richtig? 2. Der 64-Bit-Prozess konnte nur auf die x64-Registrierung für COM CLSID zugreifen, und der 32-Bit-Prozess konnte nur auf die x86-Registrierung für COM CLISD zugreifen, kein Cross-Zugriff. Mein Verständnis richtig? – George2

1

Hier ist der Wikipedia-Artikel auf dem WOW64 Registry, die Sie einige der Informationen geben können Sie suchen:

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

+0

Angenommen, ich habe eine .Net-Anwendung für jede CPU erstellt und es auf x64 ausführen, dann sollte es JITed Zugriff auf x64-Version der Registrierung sein - dh CLSIDs von COM unter x64 Registrierung registriert, und wenn ich eine 32 registrieren Bit COM-Komponente, die. NET-Anwendung wird es nicht finden können? Mein Verständnis richtig? – George2

6

Ihr Verständnis ist richtig. Eine x64-App müsste nicht auf die x86-CLSIDs zugreifen, da diese Komponenten sowieso niemals geladen werden könnten und umgekehrt.

Wenn Sie eine Komponente für die Verwendung von x86 und x64 erstellen möchten, müssen Sie entweder ein DLL-Paar erstellen, das für x86 und das andere für x64 erstellt wurde, und beide in den entsprechenden Registerteilen registrieren. Die regsrv32.exe im Ordner System32 wird die x64-Komponente pervers registrieren, und die Datei regsrv32.exe im Ordner SysWOW64 registriert die x86-Komponente.

alternativ eine NET-Assembly für irgendeine CPU bauen, die von jeder CPU-Architektur verwendet werden.

+0

@AnthonyWJones, Ich interessiere mich für die .Net Any CPU Probe, die Sie erwähnten. Angenommen, ich habe eine .Net-Anwendung für jede CPU erstellt und auf x64 ausgeführt, dann sollte sie JITed sein, um auf die x64-Version der Registrierung zugreifen zu können - also CLSIDs von COM, die unter x64-Registrierung registriert sind? Mein Verständnis richtig? – George2

+1

In diesem Szenario seine nicht JIT oder .NET, die entscheidet, welcher Teil der Registrierung CLSIDs suchen, ist die Tatsache, dass der Prozess, in dem der Code ausgeführt wird, 64 Bit, die bestimmen, welcher Satz es CLSIDs suchen wird. Dies geschieht automatisch in den COM-Support-Bibliotheken, die in Windows installiert sind. – AnthonyWJones

+0

1. Wenn wir eine neue COM-Komponente mit regsvr32 registrieren, registrieren wir sie unter der x86-Registrierung oder unter der x64-Registrierung oder unter beiden? 2. Mein Verständnis ist, konnte 64-Bit-Prozess nur x64 Registrierung für COM CLSID zugreifen, und 32-Bit-Prozess konnte nur auf x86-Registrierung für COM CLISD zugreifen, kein Cross-Zugriff. Mein Verständnis richtig? – George2

4

Sie sind keine separaten Register - ein ein Unterknoten des anderen ist, und das Betriebssystem macht die Virtualisierung, um sicherzustellen, dass 32-Bit-Anwendungen ihre Schlüssel erhalten und 64-Bit-Anwendungen ihre Schlüssel erhalten.

+0

Empfohlene Empfehlungen für einen Anfänger zu diesem Thema? – George2

+1

Der MSND-Artikel oben ist wahrscheinlich der beste Startpunkt. http://msdn.microsoft.com/en-us/library/ms724072.aspx –

+0

Eine kurze Frage, wenn ich regsvr32 verwende, um eine COM-Komponente zu registrieren, woher wissen wir, ob wir die COM-Komponente unter x86 oder x64 registrieren Registrierung? Meine Verwirrung ist, wenn x64-Registrierung, X64-Anwendung nicht in der Lage sein wird, auf die COM-Komponente zugreifen? – George2

1

Wie .NET-Assembly registrieren, um als COM in der reinen Anwendung 64-Bit verwendet werden?

Problem: standardmäßig, wenn Sie in Build-Einstellungen aktivieren "für COM-Interop registrieren", spielt es keine Typbibliothek für 64-Bit-Register.

Lösung: Ihre Assembly zu registrieren, die auf einem 64-Bit-Computer, öffnen Sie cmd Fenster nicht in GAC ist und zu tun:

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

Dies wird beseitigen "Class Fehler nicht registriert", wenn nativer mit C++, um .NET-Assembly als COM-Objekt zu instanziieren.

+0

Dies ist genau das, was dazu führte, dass meine 64-Bit-Anwendung im gemischten Modus fehlschlug - die Assemblies wurden von Visual Studio 2010 mit 32 Bit registriert. Anstatt also für COM-Interop registrieren zu müssen, setzte ich nachher Build-Ereignisse (mit/TLB) Generation in meinem Fall). Gibt es einen MSDN-Artikel, der sich auf dieses Verhalten bezieht? – DaBozUK