避免隱藏資訊

有時候，程式會刻意或無意地將資訊隱藏起來不讓 RPC 封送處理引擎得知。 一些範例如下所示：

• 將資料結構以無差異的位元組區塊傳送
• 利用方法的副作用來提升效能，以經由網路傳輸額外的數據
• 嘗試將 handle 偽裝並傳遞為 DWORD 或 ULONG

即使您將應用程式移植到 64 位 Windows 之前，這些技術也幾乎保證會引入相容性問題。

在標準遠端過程調用中，不要將伺服器上下文當做 DWORD 傳送，而是使用上下文句柄，為客戶端保留的伺服器上下文提供一個不透明的句柄。 當伺服器為用戶端建立內容句柄時，RPC 運行時間所定義的 GUID 會識別內容。 在傳輸過程中不使用指標，且在 32 位或 64 位邊界間的作業完全透明。 如需使用內容句柄的詳細資訊，請參閱 內容句柄。

DCOM 介面無法使用內容句柄，因為 COM 提供自己的內容管理。 您可以傳遞介面指標給 COM 物件，而不是建立內容句柄。 然後，您可以直接透過介面指標呼叫方法，或將指標放在其他呼叫內。 若要釋放伺服器物件，用戶端會透過介面指標呼叫介面的 Release 方法。

同樣地，有時候您無法變更您要移植的程式代碼原始設計。 如果無法避免將指標以 DWORD的形式傳送到線路上，您必須在 DWORD 值和指標之間實作某種形式的伺服器端對應。 若要這樣做，其中一個方法是將用戶端應用程式中的指標變更為指標精確度類型，例如 ULONG_PTR 或 DWORD_PTR。 然後使用 MIDL [call_as] 屬性，將指標放在電線上做為 DWORD 值。 客戶端的包裝函式只需要傳遞參數。 伺服器端包裝函式會處理這兩種類型之間的對應。 同樣地，您可以使用 [transmit_as] 屬性或 [represent_as] 屬性，將數據轉換成回溯相容的格式，以便在傳輸時表示。

如果回溯線路相容性不是問題，或句柄未用於遠端呼叫，而且您確定 32 到 64 位進程之間的遠端呼叫永遠不會發生，您可以將自變數重新定義為 ULONG64。 如有必要，您可以修改 32 位應用程式，將 DWORD 傳遞給使用者。 或者，您可以使用 32 位 Windows 上的 DWORD，以及 64 位 Windows 上的 ULONG64，為每個平台建置個別的存根與個別 IDL 檔案。