避免隱藏資訊

有時候，程式會刻意或不小心隱藏 RPC 封送處理引擎的資訊。 部分範例如下：

• 以未區分位元組區塊的形式傳送資料結構
• 透過使用方法的副作用來跨網路通道其他資料，以運用效能
• 嘗試將控制碼傳遞為DWORD或ULONG來偽裝控制碼

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

不要在標準遠端程序呼叫中以 DWORD 的形式傳送伺服器內容，而是使用內容控制碼，為代表用戶端保留的伺服器內容提供不透明控制碼。 當伺服器建立用戶端的內容控制碼時，RPC 執行時間所定義的 GUID 會識別內容。 不會透過網路使用指標，而且作業在 32 位或 64 位界限之間完全透明。 如需使用內容控制碼的詳細資訊，請參閱 內容控制碼。

因為 COM 提供自己的內容管理，所以 DCOM 介面無法使用內容控制碼。 您可以傳遞介面指標至 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 ，針對每個平臺建置個別的 STUB 與個別 IDL 檔案。