Vermeiden des Ausblendens von Informationen
Gelegentlich blenden Programme absichtlich oder versehentlich Informationen aus der RPC-Marshalling-Engine aus. Einige Beispiele:
- Senden einer Datenstruktur als undifferenzierter Byteblock
- Nutzen der Leistung mithilfe eines Nebeneffekts einer Methode, um zusätzliche Daten über das Netzwerk zu kanalieren
- Versuch, einen Handle zu verschleiern, indem es als DWORD oder ULONG übergeben wird
Diese Techniken führen fast garantiert zu Kompatibilitätsproblemen, noch bevor Sie Ihre Anwendung zu 64-Bit-Windows portieren.
Anstatt einen Serverkontext als DWORD in einem Standardmäßigen Remoteprozeduraufruf zu senden, verwenden Sie ein Kontexthandle, um ein undurchsichtiges Handle für einen Serverkontext bereitzustellen, der im Auftrag eines Clients gespeichert wird. Kontexte werden durch GUIDs identifiziert, die durch die RPC-Laufzeit definiert werden, wenn ein Server ein Kontexthandle für einen Client erstellt. Es wird kein Zeiger über das Kabel verwendet, und der Vorgang ist über 32- oder 64-Bit-Grenzen hinweg vollständig transparent. Weitere Informationen zur Verwendung von Kontexthandles finden Sie unter Kontexthandles.
DCOM-Schnittstellen können keine Kontexthandles verwenden, da COM eine eigene Kontextverwaltung bereitstellt. Anstatt ein Kontexthandle zu erstellen, können Sie einen Schnittstellenzeiger an das COM-Objekt übergeben. Anschließend können Sie die Methoden direkt über den Schnittstellenzeiger aufrufen oder den Zeiger in anderen Aufrufen platzieren. Um das Serverobjekt freizugeben, ruft der Client die Release-Methode der Schnittstelle über den Schnittstellenzeiger auf.
Auch hier kann es vorkommen, dass Sie den ursprünglichen Entwurf des Codes, den Sie portieren, nicht ändern können. Wenn es keine Möglichkeit gibt, einen Zeiger als DWORD über die Leitung zu senden, müssen Sie eine Form der serverseitigen Zuordnung zwischen DWORD-Werten und Zeigern implementieren. Eine Möglichkeit besteht darin, die Zeiger in der clientseitigen Anwendung in Zeigergenauigkeitstypen wie ULONG_PTR oder DWORD_PTR zu ändern. Verwenden Sie dann das MIDL [call_as]-Attribut, um die Zeiger als DWORD-Werte auf die Leitung zu setzen. Der clientseitige Wrapper muss nur die Argumente übergeben. Der serverseitige Wrapper verarbeitet die Zuordnung zwischen beiden Typen. Auf ähnliche Weise können Sie entweder das [transmit_as]-Attribut oder das [represent_as]-Attribut verwenden, um Ihre Daten in ein abwärtskompatibles Format für die Drahtdarstellung zu konvertieren.
Wenn die Abwärtsverbindungskompatibilität kein Problem darstellt oder das Handle nicht für Remoteaufrufe verwendet wird und Sie sicher sind, dass Remoteaufrufe zwischen 32- und 64-Bit-Prozessen nie stattfinden, können Sie ein Argument als ULONG64 neu definieren. Bei Bedarf können Sie die 32-Bit-Anwendung so ändern, dass ein DWORD an den Benutzer übergeben wird. Alternativ können Sie separate Stubs aus separaten IDL-Dateien für jede Plattform erstellen, indem Sie ein DWORD unter 32-Bit-Windows und eine ULONG64 unter 64-Bit-Windows verwenden.