Evitare che le informazioni si nascondino
In alcuni casi, i programmi nascondono intenzionalmente o inavvertitamente le informazioni dal motore di marshalling RPC. Di seguito sono riportati alcuni esempi:
- Invio di una struttura di dati come blocco non indifferenziato di byte
- Sfruttare le prestazioni usando un effetto collaterale da un metodo per incanalare dati aggiuntivi attraverso la rete
- Tentativo di mascherare un handle passandolo come DWORD o ULONG
Queste tecniche sono quasi garantite per introdurre problemi di compatibilità anche prima di convertire l'applicazione in Windows a 64 bit.
Invece di inviare un contesto server come DWORD in una chiamata di procedura remota standard, usare un handle di contesto per fornire un handle opaco a un contesto server mantenuto per conto di un client. I contesti sono identificati da GUID definiti dal runtime RPC quando un server crea un handle di contesto per un client. Non viene usato alcun puntatore in rete e l'operazione è completamente trasparente attraverso i limiti a 32 o 64 bit. Per altre informazioni sull'uso degli handle di contesto, vedere Handle di contesto.
Le interfacce DCOM non possono usare handle di contesto perché COM fornisce la propria gestione del contesto. Anziché creare un handle di contesto, è possibile passare un puntatore di interfaccia all'oggetto COM. È quindi possibile chiamare i metodi direttamente tramite il puntatore di interfaccia o posizionare il puntatore all'interno di altre chiamate. Per rilasciare l'oggetto server, il client chiama il metodo Release dell'interfaccia tramite il puntatore di interfaccia.
Anche in questo caso, potrebbero verificarsi momenti in cui non è possibile modificare la progettazione originale del codice che si sta eseguendo la conversione. Se non esiste alcun modo per evitare di inviare un puntatore attraverso la rete come DWORD, sarà necessario implementare una forma di mapping lato server tra i valori DWORD e i puntatori. Un modo per eseguire questa operazione consiste nel modificare i puntatori nell'applicazione lato client in tipi di precisione puntatore, ad esempio ULONG_PTR o DWORD_PTR. Usare quindi l'attributo MIDL [call_as] per inserire i puntatori in rete come valori DWORD . Il wrapper lato client deve passare solo gli argomenti. Il wrapper lato server gestisce il mapping tra entrambi i tipi. In modo analogo, è possibile usare l'attributo [transmit_as] o l'attributo [represent_as] per convertire i dati in un formato compatibile con le versioni precedenti per la rappresentazione in transito.
Se la compatibilità con reti precedenti non è un problema o se l'handle non viene usato per le chiamate remote e si è certi che le chiamate remote tra i processi a 32 e 64 bit non si verificheranno mai, è possibile ridefinire un argomento come ULONG64. Se necessario, è possibile modificare l'applicazione a 32 bit per passare un DWORD all'utente. In alternativa, è possibile creare stub separati da file IDL separati per ogni piattaforma usando un DWORD in Windows a 32 bit e un ULONG64 in Windows a 64 bit.