Microsoft Corporation

2006 年 7 月

Windows Vista 開發人員故事針對有興趣深入探索 Windows Vista 一些全新和擴充功能的開發人員以及其他技術專家和經理，提供了具體的內容。它將以文章的形式發行至 Windows Vista 開發人員中心，大約每兩個星期發行一篇。這些文章只是 Windows 說明檔的摘要，可於此處下載。

注意   本主題是預先發行的文件，在未來的版本中仍有可能變更。

注意   若要提供有關這些文章的意見回應，請傳送電子郵件至 Vistadev@microsoft.com。

目錄

簡介
三十分鐘的相容性檢查
作業系統版本處理
使用者帳戶控制
使用者帳戶控制 – 應用程式更新指導
Windows 資源保護 (WRP)
Internet Explorer 保護模式
Windows Vista 64 位元
Microsoft 圖形識別與驗證 (GINA)
工作階段 0 孤立
網路：TCP/IP 堆疊和 Windows 篩選平台
網路：核心模式 IP Helper API
網路：IPv6
相容性風險
說明及支援中心
協助平台用戶端
Default Programs
Windows Vista 中的程式相容性協助 (PCA) – 客戶就緒文件
圖形裝置介面 (GDI)
繪製 (WM_PAINT) 行為差異
呈現效能
UIPI (使用者帳戶控制的 GUI 部分)
高 dpi 縮放比例
PNG Icons
命名管道強化
SPAP 過時 (Pstore)
WMI 提供者：預設的安全性裝載模型
磁碟區陰影複製服務
標準使用者分析器
說明引擎支援
請參照

簡介

Microsoft Windows Vista 推出了新一代的作業系統技術和軟體開發平台，可供全球的應用程式開發人員和企業使用。為了增強 Windows Vista 的安全性和使用者經驗，許多新的功能不斷推出，而現有的功能也加以改善。

雖然 Windows Vista 可與針對 Microsoft Windows XP、Microsoft Windows Server 2003 和其服務套件所撰寫的大多數應用程式高度相容，但由於新的創新、安全性和更大的可靠性，因此不可避免地會有某個程度的相容性缺口。整體而言，Windows Vista 的相容性很高，並且 Microsoft 持續努力為 Windows Vista 達成最能與現有應用程式相容的解決方案。

本文件是應用程式開發人員熟悉如何驗證其應用程式相容性的第一步。本文件也提供了 Windows Vista 少數已知的應用程式不相容問題的概觀，並提供詳細的白皮書和其他開發人員指導文件的連結。

還有一些新的功能可讓開發人員疑難排解和因應無法正常運作於 Windows Vista 的應用程式問題，如下列所示：

• [相容性] 索引標籤。

  使用者可以在捷徑或 EXE 上按右鍵，然後套用 Windows XP SP2 相容性模式，以便讓應用程式採用和 Windows XP 一樣的方式來運作。此外，如果應用程式需要系統管理員的權限，並且使用者擁有這些權限，使用者可選擇 [以系統管理員身份執行此程式]。如需詳細資訊，請參閱本文件中的「使用者帳戶控制」小節。

三十分鐘的相容性檢查

本節將指導您如何在 Windows Vista 上測試與評估應用程式的相容性。有兩個主要的案例可測試 Windows Vista 上的相容性，如下所示。

使用 Windows Vista 的全新安裝

1. 在測試機器上安裝 Windows Vista。
2. 在 Windows Vista 上安裝應用程式。如果出現一個提示，要求允許安裝應用程式，請按 [允許]，然後繼續。如果安裝成功，請跳到步驟 6。
3. 如果應用程式安裝失敗，並且沒有顯示安裝允許提示，則在安裝程式 EXE 上按右鍵，然後選擇 [以系統管理員身份執行此程式]，然後重新安裝應用程式。如果安裝成功，請跳到步驟 6。

   注意   如果使用 MSI 來進行安裝，則此步驟並非必要。

4. 若您收到任何錯誤，例如 OS 版本、CLSID 登錄或檔案複製，則在安裝程式 EXE 檔案上按右鍵，選擇 [相容性] 索引標籤，然後選擇 Windows XP SP2 相容性模式。
5. 回到步驟 2。如果您無法安裝應用程式，請至步驟 9。
6. 應用程式現在應可安裝。
7. 啟動應用程式。如果應用程式沒有正確地啟動，或顯示錯誤，則套用 Windows XP SP2 相容性模式到該應用程式 EXE，然後再試一次。
8. 如果應用程式成功地啟動，則執行一般用來在 Windows XP 上測試應用程式的完整測試套件。驗證您的應用程式功能，並確認該應用程式可適當地執行。如果通過了所有主要的功能測試，則跳到步驟 10。
9. 如果應用程式並未安裝、成功啟動、當機、發生錯誤或未通過主要的功能測試，它可能是被 Windows Vista 的變更所影響的少數應用程式之一。使用本文件中的主題來檢查您的應用程式。
10. 您完成了這個案例。

處理從 Windows XP Service Pack 2 升級

1. 在測試機器上安裝 Windows XP SP2，接著安裝應用程式。在進行之前，請先驗證應用程式的所有功能。
2. 將測試機器升級到 Windows Vista。遵循 Windows Vista 的設定與升級指令。一旦升級完成之後，以您在 Windows XP 上的方式來登入。
3. 啟動應用程式。如果應用程式沒有正確地啟動，或顯示錯誤，則套用 Windows XP SP2 相容性模式到該應用程式 EXE，然後再試一次。
4. 如果應用程式成功地啟動，則執行一般用來在 Windows XP 上測試應用程式的完整測試套件。驗證您的應用程式功能，並確認該應用程式可適當地執行。如果通過了所有主要的功能測試，則跳到步驟 6。
5. 如果應用程式並未安裝、成功啟動、當機、發生錯誤或未通過主要的功能測試，它可能是被 Windows Vista 的變更所影響的少數應用程式之一。使用本文件中的主題來檢查您的應用程式。
6. 您完成了這個案例。

如果這兩個案例都已完成，並且應用程式正確地執行，那麼該應用程式就可在 Windows Vista 中正確地運作。如需取得您應用程式憑證的相關資訊，請參閱 Windows Vista 首頁。

連結

• Windows Internet Explorer 7：Beta 2 預覽 IT 專業人員檢查清單
• Windows Vista 首頁

作業系統版本處理

功能影響

高

簡單描述

Windows Vista 的內部版本號碼為 6。GetVersion 功能現在將會在被查詢時，傳回此版本號碼。

注意   這是 Windows XP (5.x 版) 之後的下個主要版本號碼。

表現形式

此版本變更的表現形式和應用程式有很大的關係，如下所示：

• 任何特別檢查 OS 版本的應用程式將會得到較高的版本號碼。
• 應用程式的安裝程式可能避免自己安裝該應用程式，而應用程式可能避免自己啟動。
• 應用程式可能警告使用者，並持續正常地運作。
• 一些應用程式可能會變得不穩定或當機。

遷移

大多數的應用程式都可正常地運作於 Windows Vista 之上，因為 Windows Vista 中的應用程式相容性非常高。然而，對於會檢查 OS 版本的應用程式和安裝程式，Windows Vista 提供一個相容性模式。

使用者可以在捷徑或 EXE 上按右鍵，然後套用 [相容性] 索引標籤中的 Windows XP SP2 相容性模式。在大多數的狀況中，這應可讓應用程式像過去在 Windows XP 上一樣地正常運作，您完全不用對應用程式作任何變更。

補救

• 一般而言，應用程式不應執行 OS 版本檢查，或至少要能接受 OS 6 版或更高的版本。請務必遵守此行為，除非有非常特殊的法律、商業或系統元件上的原因需要進行此版本檢查。
• 應用程式安裝程式不應使用 16 位元的安裝程式，以確保 64 位元的系統相容性。
• 確保應用程式使用的任何驅動程式儘可能都是使用者模式驅動程式，以維持多重平台 (32 位元和 64 位元) 的相容性。

使用者帳戶控制

功能影響

高

簡單描述

增加 Windows 安全性的一個基本步驟是讓互動式使用者以標準的使用者帳戶來執行，讓他們只能存取一組有限的權限和特殊權限。根據預設，Windows Vista 將以標準使用者的身份執行每個應用程式，即使您以系統管理員群組中的成員登入。反之，當使用者嘗試啟動一個已標示成需要系統管理員權限的應用程式時，系統將明確地要求他們確認如此做的用意。只有以系統管理員權限執行的應用程式可修改系統和全域設定與行為。此 Windows Vista 的功能就是使用者帳戶控制 (UAC)。

表現形式

• 自訂安裝程式、解除安裝程式和更新程式可能無法被偵測與提升成以系統管理員的身份來執行。
• 需要系統管理特殊權限來執行其工作的標準使用者應用程式可能會失敗，或無法使得此工作可供標準使用者執行。
• 當應用程式嘗試執行目前的使用者並沒有所需權限的工作，那麼該應用程式可能會失敗。失敗的自我行為將取決於應用程式的寫法。
• 執行系統管理工作並進行全域變更的控制台應用程式可能無法正常運作，也可能會失敗。
• 使用 RunDLL32.EXE 來執行的 DLL 應用程式在執行全域作業時可能無法正常運作。
• 寫入全域位置的標準使用者應用程式將透過虛擬化重新導向到每一使用者的位置。

補救

自訂安裝程式的快速解決方案：

• 使用者可按右鍵以啟動安裝程式或更新程式，然後選取 [以系統管理員身份執行此程式]。
• 套用應用程式相容性修正程式，以指出特定的安裝程式需要提高權限。作法是在捷徑或 EXE 上按右鍵，然後從 [相容性] 索引標籤套用 Windows XP SP2 相容性模式。

針對需要系統管理特殊權限來執行系統修改或寫入特殊權限區域的應用程式，其快速解決方案如下：

• 企業使用者可套用應用程式相容性修正程式，以指出舊版應用程式需要系統管理員權限或特殊權限，才能正確執行。
• 減少某些受限檔案上的存取控制清單之限制 (ACL)，應可協助想要寫入這些檔案的應用程式。
• 檢查虛擬化資料夾或登錄機碼，看看應用程式是否正在存取需要系統管理員特殊權限的一些資料。此資訊可用來移除該應用程式未來版本存取系統管理員所保護位置的需求。如需虛擬化檔案、資料夾和位置的詳細資訊，請參閱「連結」小節。
• 將 "Run DLL as an app" DLL 呼叫包裝到個別的 EXE 內，並為此EXE包含一個資訊清單，以要求提高的特殊權限。

相容性測試：

• 任何安裝、解除安裝或更新案例都應提示使用者，以要求同意或認證。收到使用者的許可之後，動作應該就會成功。
• 嘗試以內建系統管理員的身份重新產生失敗的案例。若此案例現在可通過，代表先前的失敗可能是因為缺少特殊權限。
• 使用應用程式相容性工具組的「相容性系統管理員」的「使用者帳戶控制」預測器工具，找出正在執行系統管理員作業的應用程式區域。

運用 Windows Vista 的能力解決方案：

• Windows Vista 架構的應用程式需要：
  • 遵循 Windows Vista LOGO 計劃和使用者經驗 (UX) 方針文件中的指定方針 (請參閱「連結」小節)。
  • 使用內嵌的資訊清單來指出其特定的 requestedExecutionLevel (前身為 RunLevel)。
  • 將所有的系統管理和非系統管理功能分別放到個別的 EXE。所有需要較高特殊權限的功能都應該放到具有明確執行層級的個別可執行檔 EXE 內，或以系統管理員特殊權限執行的 COM 物件內。只在需要時，才啟動系統管理工作。這一點對於所有的應用程式都適用。
• 針對在本質上不完全是系統管理的應用程式，請修改程式碼來去除系統管理員權限或特殊權限的需求。
• 針對只能由系統管理員使用的應用程式，標記該應用程式，讓它以系統管理員權限或特殊權限來執行。
• 在更新應用程式時，使用個別的更新程式 EXE 來更新目標應用程式。
• 控制台應用程式必須從 .cpl 檔移到 .exe 檔，並為其 EXE 架構的控制台應用程式包含一個資訊清單，指定所需的執行層級。
• 執行於 RunDLL32.EXE 底下、且需要提高權限的 DLL 應該修改成可執行檔 EXE，並在其資訊清單中指出其提高層級。
• 儘可能以唯讀存取權限來開啟檔案和登錄機碼。只在必要時才使用讀寫存取權限，並在操作完成之後，將權限還原成唯讀。

連結

• Windows Vista 安全性
• Windows Vista UAC 首頁
• 以「使用者帳戶」開始使用
• 在最少特殊權限的環境中開發應用程式的開發人員最佳作法和方針
• Windows Vista 使用者經驗
• 檔案和登錄虛擬化詳細資料
• 來自 Microsoft 專業開發人員 2005 年研討會 (PDC) 的投影片；尋找 FUN406
• UACBlog
• 在 Microsoft Forums 的 UAC 相關問題
• Aaron Margosis 的網路部落格；尋找 「Not running as administrator」

使用者帳戶控制 – 應用程式更新指導

功能影響

中

簡單描述

許多現有的應用程式都傾向於將更新功能加到其應用程式內。內嵌更新功能的目的是確保用戶端執行的是 ISV 所能提供的最新二進位檔。

我們發現一些應用程式在執行其更新功能時，需要比標準使用者來得多的特殊權限。通常，在安裝過程中放到每台機器上的檔案都需要加以維護。針對執行和安裝應用程式的 UAC 模型而言，只有 Admin Approval Mode Admin 中的提高權限系統管理員有足夠的特殊權限來執行這些動作。

Windows Vista 安裝程式偵測啟發學習法可正確地偵測到許多應用程式的更新程式，並且適當地提高更新程式處理程序的權限，以便在提高權限時成功地完成更新。不過，應用程式更新仍無法在一些區域中順利地完成。例如：

• 跨處理程序的更新程式並非在安裝時偵測得到 — 這是無法透過安裝偵測啟發學習法偵測到的更新程式。
• 多用途的可執行檔 / 同處理程序更新 — 執行多個作業的多載可執行檔。例如，二進位檔同時是主應用程式和更新應用程式，或者多用途的可執行檔以應用程式中的執行緒方式執行。

表現形式

應用程式更新功能失敗

補救

跨處理程序的更新程式並非在安裝時偵測得到

• 這是一個可能發生在任何企業內的問題，並可能導致該企業要求某個應用程式以系統管理員的特殊權限來執行。如果應用程式使用非安裝程式可偵測的個別處理程序來自我更新，那麼此個別的處理程序應使用 App Fix 標記成需要系統管理員特殊權限。
• 不以使用者方式運作的更新程式將令企業無法以最小特殊權限來執行。
• 此更新程式應寫成個別的處理程序，並具有要求的系統管理員執行層級。
  • 此處理程序只應基於更新用途，在必要時執行。要檢查程式是否需要更新，應以使用者身份進行。

多用途可執行檔/同處理程序更新

在 Windows Vista 上，並沒有什麼好方法可建立一個執行更新的多用途可執行檔，因為您不能切換可執行檔在什麼狀態下執行。因此，可執行檔一定得以系統管理員身份來執行。取而代之地，應用程式應遵循下列方法之一來執行更新。

1. 運用 MSI 中的修補技術 (最新版的 Windows Installer、InsallShield、Wise 等程式均支援此技術)。
   • MSI 是重要的安裝程式技術，因為它提供了為您管理更新的能力。
   • 使用 MSI 來建立您的初始安裝程式，並在 MsiPatch憑證表中內嵌憑證。
   • 為您的應用程式建立更新，並以先前指定的憑證來簽署它。
   • MSI 將在套用補充程式時，提高應用程式的權限。

   注意   此方法優於其他方法的主要好處在於它適用於標準使用者，並保持此情況的安全。它提供較佳的使用者經驗，因為標準使用者帳戶不需要請求系統管理員去安裝補充程式，或要求永久的系統管理員特殊權限來進行。

2. 使用其他自訂的安裝程式機制。
   • 企業環境中不鼓勵如此做，因為它將令使用者無法以非系統管理員執行。
   • 此更新程式應寫成個別的處理程序，並具有要求的系統管理員執行層級。

     注意   此處理程序只應基於更新用途，在必要時執行。要檢查程式是否需要更新，應以使用者身份進行。

3. 在以「標準使用者」應用程式執行時進行更新。
   • 在使用 ClickOnce 技術時，更新可一個標準使用者進行。同樣地，這是一個允許使用者在其中部署應用程式、並為應用程式撰寫者處理更新的安裝平台。

連結

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/patching_and_upgrades.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/least_privileged_user_account__lua__patching.asp

http://msdn.microsoft.com/msdnmag/issues/04/05/ClickOnce/

Windows 資源保護 (WRP)

功能影響

高 (阻擋應用程式安裝或執行)

簡單描述

作為增加系統穩定性、可預期性和可靠性的創舉，Windows 資源保護 (Windows Resource Protection，WRP) 是設計用來以唯讀狀態保護 Windows 系統。這將會影響特定的檔案、資料夾和登錄機碼。受保護資源的更新只有 OS 所信任的安裝程式可進行，例如 Windows Servicing。這可讓 OS 所隨附的元件和應用程式更不容易受到其他應用程式和系統管理員所影響。

表現形式

應用程式和系統管理員在取代或修改受保護的 OS 資源時，並不會成功，其結果如下：

• 嘗試取代、修改或刪除受 WRP 保護的 OS 檔案和 (或) 登錄機碼的應用程式安裝程式將會失敗，並有一個錯誤訊息指出該資源不能更新。這是因為存取這些資源被拒之故。
• 嘗試將新的登錄機碼或值寫入受保護登錄機碼的應用程式可能會失敗，並有一個錯誤訊息指出由於存取被拒，因此此變更失敗。
• 如果嘗試寫入受保護資源的應用程式倚賴登錄機碼或值，就可能會失敗。

受保護的系統區域範例：

• 大多數 Windows 架構的可執行檔將受 WRP 所保護。根據預設，下列的副檔名代表受 WRP 保護的檔案：
  • .acm, .ade, .adp, .app, .asa, .asp, .aspx, .ax
  • .bas, .bat, .bin
  • .cer, .chm, .clb, .cmd, .cnt, .cnv, .com, .cpl, .cpx, .crt, .csh
  • .dll, .drv, .dtd
  • .exe, .fxp, .grp
  • .h1s, .hlp, .hta
  • .ime, .inf, .ins, .isp, .its
  • .js, .jse, .ksh, .lnk
  • .mad, .maf, .mag, .mam, .man, .maq, .mar, .mas, .mat, .mau, .mav, .maw, .mda, .mdb, .mde, .mdt, .mdw, .mdz, .msc, .msi, .msp, .mst, .mui
  • .nls, .ocx, .ops
  • .pal, .pcd, .pif, .prf, .prg, .pst
  • .reg, .scf, .scr, .sct, .shb, .shs, .sys
  • .tlb, .tsp, .url
  • .vb, .vbe, .vbs, .vsmacros, .vss, .vst, .vsw
  • .ws, .wsc, .wsf, .wsh
  • .xsd, .xsl
• 根據預設，受保護的登錄機碼包括大多數的 COM OS 登錄機碼，例如：
  • HKEY_CLASSES_ROOT\Interface\{GUID}
  • HKEY_CLASSES_ROOT\Interface\{GUID}\NumMethods
  • HKEY_CLASSES_ROOT\Interface\{GUID}\ProxyStubClsid
  • HKEY_CLASSES_ROOT\Interface\{GUID}\ProxyStubClsid32
• 受 WRP 保護的最小資料夾集合。這些包括了專供 OS 資源使用的資料夾，例如一些 inetpub 資料夾，像是：
  • $(runtime.bootDrive)\inetpub\uddi\webroot\details\
  • runtime.bootDrive)\inetpub\uddi\webroot\edit\
  • (runtime.bootDrive)\inetpub\uddi\webroot\controls\
  • $(runtime.bootDrive)\inetpub\uddi\bootstrap\

遷移

重要   若應用程式被識別為 Windows Vista 架構的應用程式，就不會套用下列的安全防護功能。

針對知名的安裝程式，「拒絕存取」錯誤將在在下列狀況中受到抑制：

• 當應用程式安裝程式被偵測為舊版安裝程式時 (也就是，安裝程式並沒有資訊清單)。
• 當拒絕存取錯誤是由於應用程式嘗試建立或修改 WRP 資源而產生的。
• 在某些案例中，當嘗試刪除 WRP 所保護資源的動作時，將自動提供安全防護功能。
• 如果應用程式嘗試在 WRP COM 登錄機碼之下建立新的子機碼或值，它們可能會收到拒絕存取錯誤。

  注意   在此狀況中，將傳回成功，即使未對 WRP 資源套用任何變更。

補救

• 不安裝或更新 Windows Vista 上的系統元件，除非是使用Microsoft 所提供、專為 Windows Vista 設計的可轉散發套件。
• 不安裝Microsoft 所提供、專為 Windows Vista 設計的完整可轉散發套件中的個別元件。
• 使用 SfcIsFileProtected 來偵測受 WRP 保護的檔案。如果檔案是在 WRP 之下，那麼應用程式就不應安裝或修改該檔案。
• 針對受 WRP 保護的登錄機碼，應用程式應妥善地處理由於 WRP 造成的「拒絕存取」訊息。
• 測試與確認倚賴 WRP 安全防護功能的舊版應用程式可透過安裝此應用程式妥善地執行。

連結

• Windows Vista 管理功能

Internet Explorer 保護模式

功能影響

高

簡單描述

在 Windows Vista 中，Microsoft Internet Explorer 7 於受保護模式中執行，這可讓使用者以大為受限的特殊權限來執行 Internet Explorer 處理程序，以協助他們不受到攻擊。受保護模式可大幅降低寫入、改變或破壞使用者機器上資料或安裝惡意程式碼的攻擊能力。它可協助使用者防範惡意程式碼未經授權地自行安裝。這是 Windows Windows Vista 安裝之後的 Internet Explorer 預設模式。

表現形式

• 使用 Internet Explorer 7 的應用程式若是在網際網路或內部網路區域中，將無法直接寫入磁碟內。
• 應用程式可能不知道如何處理新的提示。

受保護模式建立於新的完整性機制上，以限制可取得的物件的寫入存取，這類物件包括了具有較高完整性層級的處理程序、檔案和登錄機碼。當 Internet Explorer於受保護模式執行時，它是低完整性的處理程序；它無法獲得使用者設定檔或系統位置中的檔案寫入權限和登錄機碼。

低完整性處理程序只能寫入已指定低完整性強制標籤的資料夾、檔案和登錄機碼內。因此，Internet Explorer 和其延伸模組將執行於受保護模式內，它們只能寫入低完整性的位置中，例如新的低完整性 Temporary Internet Files 資料夾、History 資料夾、Cookies 資料夾、Favorites 資料夾和 Windows Temporary Files 資料夾。

此外，當 Windows Windows Vista 出貨時，受保護模式處理程序將以低桌面完整性層級來執行，這將限制它無法傳送特定的視窗訊息給更高的完整性處理程序。

透過防止未授權地存取使用者系統的機密區域，受保護模式可限制受破壞之 Internet Explorer 處理程序或惡意軟體可能造成的損壞數量。例如駭客不能悄悄地安裝按鍵記錄器到使用者的 Startup 資料夾內。同樣地，受破壞的處理程序不能透過視窗訊息來處理桌面上的應用程式。

當然囉，這些防禦也限制了較高的完整性位置 (IL) 的合法變更。因此，受保護模式提供一個相容性架構來減少對於現有延伸模組的影響，如下圖所示。

圖 1

一個相容性層處理了許多現有延伸模組的需求。它可攔截寫入至中度完整性資源的嘗試，例如使用者設定檔中的 My Documents 資料夾和 HKEY_CURRENT_USER 登錄區。相容性層使用一般 Windows 相容性修正程式，以自動重新導向這些作業到下列的低完整性位置：

• %userprofile%\LocalSettings\Temporary Internet Files\Virtualized
• HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\InternetRegistry

兩個更高特殊權限的仲介處理程序允許 Internet Explorer 和延伸模組在使用者同意下，執行提高權限的作業。例如，使用者特殊權限仲介 (IEUser.exe) 處理程序提供一組功能，讓使用者儲存檔案到低完整性區域以外的區域。此外，系統管理員特殊權限仲介 (IEInstal.exe) 處理程序允許 Internet Explorer 安裝 ActiveX 控制項。

補救

快速解決方案：

• 加入有問題的網站到受信任的網站清單。
• 關閉受保護模式 (不建議)。

相容性測試：

• 套用快速解決方案，並確保應用程式可執行所依存的功能，如同在 Windows XP SP2 中一樣。

運用 Windows Vista 功能解決方案：

• 變更應用程式來處理受保護模式，包括可能顯示的任何相關提示。

連結

• Internet Explorer 7 中的安全性與相容性
• 瞭解並於受保護模式 Internet Explorer 中運作
• Internet Explorer 開發人員中心
• Internet Explorer 7 Beta 2 預覽的資訊索引

Windows Vista 64 位元

功能影響

高

簡單描述

Windows Vista 可完整支援 AMD 和 Intel 所推出的 64 位元架構處理器。藉著 WOW64 模擬器的協助，Windows Vista 的 64 位元版本可執行所有的 32 位元應用程式。不過，核心並不支援 16 位元應用程式、16 位元安裝程式和 32 位元核心模式驅動程式。

所有的 64 位元驅動程式必須針對 Windows Vista 64 位元版本進行數位簽署。未簽署的驅動程式並不受到支援，並且無法安裝在 64 位元的 Windows Vista 上。數位簽署檢查會在安裝和驅動程式載入時進行。

表現形式

• 使用 16 位元可執行檔、16 位元安裝程式或 32 位元核心驅動程式的應用程式或元件在 Windows Vista 的 64 位元版本上，不是無法啟動，就是無法正常運作。在此狀況中，將出現下列的錯誤訊息：

  由於與 Windows 的 64 位元版本不相容，程式或功能 "[exepath]\[app16bit].exe" 並無法啟動或執行。請聯絡軟體廠商，詢問是否有 64 位元的 Windows 相容版本可供使用。

• 當 16 位元的安裝程式或應用程式啟動之後，將出現下列的錯誤訊息：

  此檔案的版本和您執行的 Windows 版本不相容。請檢查您電腦的系統資訊，查看您是否需要程式的 x86 (32 位元) 或 x64 (64 位元) 版本，接著聯絡軟體的發行者。

• 在 64 位元系統上安裝 32 位元的核心驅動程式將會失敗。如果安裝程式透過編輯登錄，手動地新增驅動程式，那麼系統將不會載入此驅動程式，並且此動作可能令系統失敗。
• 在 64 位元系統上安裝 64 位元的未簽署驅動程式將會失敗。如果安裝程式透過編輯登錄，手動地新增驅動程式，但它還未簽署，那麼系統將不會在載入時載入該驅動程式。

補救

運用 Windows Vista 功能解決方案：

• 所有的 16 位元元件都應從應用程式中移除，並以 32 位元或 64 位元的類似元件來取代。
• 所有的 16 位元安裝程式應轉換成 32 位元或 64 位元的安裝程式。
• 如果應用程式使用了核心模式的驅動程式，那就需要製作 64 位元版本的驅動程式。應用程式應偵測 OS (32 位元或 64 位元) 的平台，接著根據 OS 平台，安裝適當的驅動程式架構。
• 確保所有的 64 位元驅動程式都經過數位簽署。

相容性測試：

• Install and launch the application on a 32 位元 and a 64 位元 Windows Vista machine. 應用程式在兩個架構上都應正常運作。

連結

• 執行 32-bit 應用程式
• 影片
• 在執行 Windows Vista 的 x64 架構系統上的核心模組數位簽署

Microsoft 圖形識別與驗證 (GINA)

功能影響

高 (頻率：低)

簡單描述

在 Windows Vista 之前，若要登入到協力廠商的伺服器或包含協力廠商的裝置，ISV 必須更換 Windows XP 中的「圖形識別與驗證」(Graphical Identification and Authentication，GINA) 動態連結程式庫。這類應用程式也必須取代現有的 UI，並在 Windows XP 上實作智慧卡和遠端桌面功能。

注意   如果應用程式在 Windows XP 中的運作方式不是這樣，那麼此資訊就不適用。

Windows Vista 推出新的驗證模型，讓 LogonUI 和 WinLogon 直接彼此通訊。此模型提供了 GINA 所沒有的簡單、延展性和彈性。不像 GINA 模組，ISV 不再需要取代登入畫面的 UI，因此解除了 ISV 重新為使用者製作使用者介面的負擔。ISV 可製作認證提供者，這是一個插入 LogonUI 的模組，用以描述 UI，並收集認證，然後將它傳給 WinLogon。認證提供者對於 WinLogon 是完全透明的。

認證提供者也是附加的，這代表使用者可安裝多個認證提供者，並挑選他們想要使用的提供者。認證提供者可為使用者所選擇的和 (或) 事件導向。多個認證提供者可以並存於 Windows Vista 之上，並且不僅用於協力廠商。事實上，Windows 會在包裝盒中隨附兩個認證提供者：一個使用者名稱和密碼認證提供者，以及一個智慧卡認證提供者。

此外，認證提供者可重複用於 CredUI。在 LogonUI 上描述和收集認證資訊的同一個物件也可用來在 CredUI 案例中收集完全相同的認證。

Windows XP 和 Windows Server 2003 的 GINA 功能在 Windows Vista 中已經過時及被移除。應用程式的 GINA 模組將無法運作，必須使用 Windows Vista 的新驗證模型重新製作。

表現形式

• 使用者將無法成功地安裝自訂的登入應用程式。
• 使用者將無法在 Windows Vista 中使用自訂的登入應用程式登入 (使用 Windows XP 技術)。這些可能包括：
  • 生物測量裝置。
  • 自訂的登入 UI。
  • 包含自訂登入 UI 的遠端使用者的虛擬私人網路 (VPN) 解決方案。

補救

運用 Windows Vista 功能解決方案：

• 使用 GINA 技術的應用程式或元件必須重新製作，以使用 Windows Vista 的新登入驗證模型。

連結

• 針對所有的認證提供者資訊和問題，傳送電子郵件給 Shell 認證提供者別名： credprov@microsoft.com

工作階段 0 孤立

功能影響

高 (頻率：低)

簡單描述

在 Windows XP、Windows Server 2003 和更早的 Windows 作業系統版本中，所有的服務都和登入到主控台的第一個使用者執行在相同的工作階段內。此工作階段稱為工作階段 0。於工作階段 0 中一同執行服務和使用者應用程式將會產生安全性風險，因為服務會以提高的特殊權限來執行，因此將成為正尋找方法來提高自己特殊權限層級的惡意代理程式的目標。

Microsoft Windows Vista 透過孤立工作階段 0 中的服務，並讓工作階段 0 成為非互動性，來降低此安全性風險。在 Windows Vista 中，只有系統處理程序和服務執行於工作階段 0 內。第一個使用者登入至工作階段 1，接下來的使用者登入至接續的工作階段。這意味著服務永遠不會和使用者的應用程式執行於相同的工作階段內，因此也不會受到來自應用程式碼的攻擊。

一些受影響的驅動程式類別範例包括：

• 由多工緩衝處理程式服務所載入的印表機驅動程式。
• 以使用者模式驅動程式架構 (User Mode Driver Framework，UMDF) 所製作的所有驅動程式，因為這些驅動程式是由工作階段 0 裡面的某個處理程序所裝載。

被此功能影響的應用程式類別：

• 建立 UI 的服務。
• 嘗試使用 SendMessage 和 PostMessage 之類的視窗訊息函數來和應用程式通訊的服務。
• 建立全域命名物件的應用程式。

表現形式

如果屬於某個應用程式的服務擲回一個 UI，該應用程式將等待該服務，並且 UI 不會顯示在使用者工作階段中。

補救

快速解決方案：

• 如果應用程式的服務使用某個 UI，Windows Vista 中的內建安全防護功能可讓使用者在特殊桌面中與工作階段 0 的 UI 互動。這將可提供該應用程式的相關 UI，而非整個工作階段 0 桌面。
• 如果應用程式會建立全域命名的物件，那就使用 Windows XP 相容性模式來確保應用程式將持續與工作階段 0 的服務一起工作。

相容性測試：

• 在終端機伺服器模式或快速使用者切換 (FUS) 模式中測試與驗證 Windows XP 上的應用程式。如果應用程式在這些案例中可正常地運作於 Windows XP 之上，那它就很可能可運作於 Windows Vista 中。
• 驗證在套用了 Windows XP 相容性模式之後，應用程式是否可正常地運作，此模式中包含了一些工作階段 0 問題的安全防護功能。
• 測試 Windows Vista 中的驅動程式，確認它可適當地執行。如果這無法做到，則在啟用 FUS 並有多重使用者登入的 Windows XP 中測試驅動程式。如果該驅動程式對於第二個和接下來的登入使用者都可正確地運作，它就不太可能被 Windows Vista 中的工作階段 0 變更所影響。此測試無法偵測的唯一問題就是在 Windows Vista 的工作階段 0 中沒有視訊驅動程式的狀況。

運用 Windows Vista 功能解決方案：

• 使用用戶端或伺服器機制，例如遠端程序呼叫 (RPC) 或命名管道，在服務和應用程式之間通訊。
• 使用 WTSSendMessage 函數在使用者桌面上建立簡單的訊息方塊。這允許服務提供使用者一個通知，並要求簡單的回應。
• 針對更複雜的 UI，則使用 CreateProcessAsUser 函數在使用者的工作階段中建立一個處理程序。
• 為任何命名物件，例如事件或對應記憶體，明確地選擇服務所提供的 Local\ 或 Global\ 命名空間。

連結

• 工作階段 0 孤立對於 Windows Vista 中的服務和驅動程式的影響
• 服務
• 同步化
• 建立遠端程序呼叫
• 客戶端/伺服器端應用程式
• CreateProcessAsUser
• 以快速使用者切換測試您的應用程式

網路：TCP/IP 堆疊和 Windows 篩選平台

功能影響

高

簡單描述

Windows Vista 網路堆疊已經完全重寫。Windows Vista 摒除了存在於 Windows XP 或 Windows Server 2003 中的雙堆疊模型 (以支援 IPv4 和 IPv6)，而改為實作支援多重 IP 層的單一傳輸和框架層的新架構。有多項新功能和通訊協定的改進功能。新的堆疊非常模組化、彈性和可擴充。雖然已盡力與在不同層中使用堆疊的現有應用程式維持應用程式相容性，但還是有些變更 (通常都是改進功能的副作用) 可能會有應用程式的相容性問題，因此應用程式的開發人員務必仔細評估，以瞭解這些變更對於其應用程式的影響。

Microsoft Windows 篩選平台 (WFP) API 可讓開發人員建立可與篩選互動的程式碼，篩選將發生在 Windows Vista 和 Microsoft Windows Server 程式碼名稱 "Longhorn" 作業系統網路堆疊和整個作業系統的多層之中。WFP 也根據應用程式所使用的通訊端 API，來與驗證通訊和動態防火牆組態等防火牆功能互相整合並提供支援。

注意   WFP 本身並不是防火牆。它是一組讓您實作防火牆的系統服務和 API。

Windows Vista 並不支援下列 TCP/IP 堆疊的項目：

• 防火牆勾點驅動程式功能和篩選勾點驅動程式功能已過時。
• R-series 工具，包括 rexec、rsh、finger 等等。需要的話，這些工具都提供於 Services For Unix 元件之中。
• Internetwork Packet Exchange (IPX) 通訊協定。IPX 已經過時，幾乎已經沒在使用。此變更對於應用程式相容性的影響應該很小，甚至完全沒影響。

表現形式

• 如果針對 Windows XP 所建立的應用程式僅使用公用函數來進行網路用途，其功能應該不會有任何中斷。您應在 Windows Vista 上測試它，以驗證其功能。
• 使用任何防火牆勾點驅動程式或篩選器勾點驅動程式函數的應用程式將無法運作。
• 倚賴從未被 Microsoft 發行的內部結構和函數呼叫的應用程式將會失敗。
• 以核心模式撰寫的傳輸驅動程式介面 (Transport Driver Interface，TDI) 篩選器驅動程式在 OS 升級之後可能無法正常運作。

  注意   TDI 介面在未來的版本中將會被取代。不過，這些驅動程式仍可運作於 Windows Vista 中。

補救

運用 Windows Vista 功能解決方案：

• WFP 公開一組豐富的功能和服務給網路安全性開發人員，並針對可用的功能集提供指導和文件。

  注意   倚賴 Services for Unix 和 R-series 的應用程式和指令碼現在必須先安裝這些工具。

連結

• WFP 內部架構、詳細內容與 (預先發行)
• 交互操作性與遷移中心

網路：核心模式 IP Helper API

功能影響

高

簡單描述

在先前的 Windows 發行中，Winsock 用戶端並沒有 API 集合來存取核心。這在 Windows Vista 中將會變更。此外，Windows Vista 現在根據預設可支援 IPv6。它並不為 IPv4 和 IPv6 提供個別的 API，而是設計新的 Helper API 集合來提供橫跨所有的新技術的常見功能，如下所示：

• Windows Sockets in Kernel (WSK) 用戶端的核心模式功能。
• IPv6 支援。
• IPv4 和 IPv6 位址的單一函數集合。
• 提供一致、可擴充的物件模型。
• 根據網路服務介面提供定義明確的安全性模型。
• 公開新的堆疊功能，例如區間和子介面。

表現形式

使用較舊 Helper API 或未記載的核心函數呼叫的應用程式將無法運作，並且可能變得不穩定。

補救

• 應用程式需要支援和實作新的核心模式 IP Helper API。

連結

• 此時沒有。

網路：IPv6

功能影響

高 (頻率：中)

簡單描述

Windows Vista 中的 TCP/IP 堆疊根據預設將啟用 IPv6。可以的話，最好使用 IPv6 連線。對於已放入 TCP/IP 堆疊內的應用程式，這具有下列的含意：

• IPv6 傳輸流量將被 Windows Vista 堆疊所傳送，不管網路是否支援 IPv6。因此，根據預設將會產生路由器請求和鄰近的搜索訊息。
• 根據預設將提供與開啟 IPv6 位址。可能會有多個 IPv6 位址與連結本機、全域、暫時或轉換技術相關聯，例如 6to4、6over4、ISATAP 或 Teredo。

  注意   根據預設將啟用 Teredo。

• Windows Vista 將允許系統只使用 IPv6 的模式來設定。在此狀況中，將不提供 IPv4 支援。

Windows Vista 中的TCP/IP 堆疊支援一個加強式主機路由模型。這意味著封包不僅根據封包的目標位址、也根據其來源位址，從多重主目錄機器中路由。此變更是必須的，因為在 IPv6 中，每台機器都有多重 IP 位址，並且透過轉換技術，只要是與路由有關係，基本上都會顯示成多重主目錄的機器。為確保適當的連線出現在這些案例中，網路堆疊必須實作一個加強式主機路由模型。

表現形式

使用 Windows XP TCP/IP 堆疊和 (或) 不知道 IPv6 通訊協定的應用程式將無法正常運作，並且可能會當機或產生不穩定的系統。

加強式主機路由模型對於應用程式的意義如下：

• 從非回送位址連接至回送位址將會失敗，反之亦然。
• 網路上的 Windows Vista 機器將不允許傳送來源位址為 127.0.0.0/8 的封包。

補救

應用程式將需要重新製作如下：

• 放入堆疊內的任何應用程式必須可處理 IPv6 流量，最低限度，它在收到 IPv6 流量時不應當機。
• 依賴單一 IPv4 位址的任何應用程式將需要修改，以處理多重 IPv6 位址。此外，挑選第一個位址的任何應用程式必須更仔細地找出欲使用的 IPv6 位址。這是因為 IPv6 連結本機位址並無法路由，因此應用程式可能無法運作。反之，應用程式應使用允許根據名稱來連線的函數，並且自動選擇最適當的位址。
• 應用程式必須處理與支援僅使用 IPv6 的案例。
• 應用程式必須支援與實作加強式主機路由模型。

連結

• Windows Sockets 應用程式的 IPv6 指導

相容性風險

過時元件

較早 Windows 發行版本中的下列元件將不會出現在 Windows Vista 中：

• 核心模式印表機驅動程式支援：所有的印表機驅動程式現在都需要遵循使用者模式驅動程式架構。所有的核心模式印表機驅動程式都被封鎖，無法載入到 Windows Vista 上。如需詳細資訊，請參閱使用者模式驅動程式架構 (UMDF) 網站。
• 針對 Windows Vista，Windows Help 已過時 (WinHelp.exe 和 WinHlp32.exe)。Beta 2 並不支援 Windows Help，而一些 Windows Help 程式碼已經從發行版本移除。要在 Windows Vista 中檢視具有 .HLP 副檔名的說明檔，您需要從 Microsoft 下載中心下載與安裝 Windows Help。Beta 2 或 RC1 將不提供此下載。如需詳細資訊，請參閱「說明引擎支援」。

  注意   HTML Help 和 .CHM 檔將持續為 Windows Vista 所支援。

• Microsoft FrontPage 伺服器擴充功能。Windows SharePoint Services 現在提供增強的功能集給開發人員社群。
• Macintosh 服務。
• D3DRM。DirectX 將是 Windows Vista 唯一支援的圖形套件。
• 網頁發佈精靈。
• NetDDE—基於安全性理由，Windows Vista 並不支援 NetDDE。(NetDDE 在 Windows XP SP 2 和 Windows Server 2003 中的預設狀態為停用。) 一般的 DDE 仍受到支援。NetDDE 是允許使用 DDE 傳輸的應用程式透明地在網路上交換資料的一項技術。其結果將是應用程式無法在網路上交換資料。因應方式是，請使用不同的網路技術，例如 DCOM 或 Windows 通訊基礎。如需更多關於 NetDDE的資訊，請瀏覽：http://support.microsoft.com/default.aspx?scid=kb;en-us;125703。

說明及支援中心

說明及支援中心 (HelpCtr.exe) 是專為 Windows XP 和 Windows Server 2003 所設計的說明應用程式。說明及支援中心可顯示副檔名為 .CHM 的已編譯說明檔。

說明及支援中心並未包含於 Windows Vista 之中，其功能也不被支援。副檔名為 .CHM 的已編譯說明檔將只能顯示在 HTML 說明應用程式中，如上所述。

協助平台用戶端

協助平台 (Assistance Platform) 用戶端 (HelpPane.exe) 是專為 Windows Vista 設計的新說明引擎。它與任何先前的 Windows 版本都不相容。您需要此協助平台用戶端，才能顯示副檔名為 .H1S 的說明檔。

在 Windows Vista 中，協助平台用戶端可在授權合約下，可以由 OEM、系統建造商和企業客戶加以自訂，但不能供協力廠商程式使用。如需自訂協助平台用戶端的詳細資訊，請參閱 Windows SDK。

Windows Vista 顯示驅動程式模型 (VDDM)

Windows Vista 顯示驅動程式模型 (VDDM) 是一個可改善 Windows中顯示驅動程式穩定性的全新顯示驅動程式模型。VDDM 有一些重要的功能，包括：

• DX 應用程式和新的 Desktop Window Manager (DWM) 可有效率地管理視訊記憶體。多個 3-D 應用程式將使用 Windows Vista 中的圖形處理器單位 (GPU)。
• 無須重新開機，即可進行驅動程式升級。
• 無須重新開機，即可動態偵測 GPU 當機和修復。
• 監視器支援熱插拔偵測。
• 使用 DX9L 託管的硬體功能。
• 零缺點的視訊播放。
• 有機會進行極安全的設計。

雖然 Windows 較早版本的大多數應用程式應該都不會受 VDDM 所影響，但仍有一些風險，包括：

• DX Games 相容性，導致 DX 執行階段或 IHV 驅動程式或核心圖形堆疊問題。
• 行動功能，例如快速鍵、複製檢視、亮度和縮放，這是由於較嚴格的 ACPI 需求。
• 協助工具，特別是 Windows XP 所設計的螢幕放大應用程式將無法運作於 Windows Vista 上。

連結

• 以電子郵件寄出圖形意見反應別名：lhgfxfb@microsoft.com

安全例外狀況處理

在較早的 Windows 版本中，IsBadReadPtr 和 IsBadWritePtr 函數被用來驗證參數。Windows Vista 現在禁用這些函數。此外，依賴以這些函數來驗證參數之 Windows 元件的應用程式將發現 Windows 不再使用它們。應用程式不應依賴 Windows 來進行任何參數驗證 (完成檢查 null，如果它是不良指標，應用程式會失敗)。

安全例外狀況處理 (SEH) 也可搭配無執行 (no-execute) 旗標來使用。在例外狀況被發送之前，會檢查例外處理常式是否標示為 page_execute，以及該處理常式是否為有效的程式碼，並且它是在 SEH 表內。

DLLmain 處理程序

處理程序建立過程中的 DLL 載入順序是無法保證的，絕對不要依賴此順序來執行作業。因為新 OS 元件的依存性，DllMain 中的複雜處理可能令應用程式懸置或當機。如需詳細資料，請參閱 MSDN 的下列網頁：

• Dllmain
• "OLE 物件的呼叫不應從 DllMain 進行"
• "PRB：不能在 DLL 啟動時建立 MFC 執行緒"
• "當您在 DLL 的 InitInstance 或 DllMain 函數中使用 ODBC 或 DAO 時，您的應用程式可能會由於「存取違規」錯誤訊息而失敗"
• "當您從 DllMain 呼叫 CoCreateInstance 時，COM 應用程式懸置"

Outlook Express 重新命名

Outlook Express 已經變更與移動，現在稱為 Windows Mail。MAPI 應用程式需要察覺此變更。動態使用 MAPI 預設程式的大多數應用程式應該不會看到任何相容性問題。

Shell：主題和 My Documents 位置

Windows Explorer Shell 為 Windows Vista 推出了新的視覺主題。可在較早的 Windows 版本中處理主題的應用程式應該不會和新的主題有任何相容性問題。

此外，Windows Vista 中的 My Documents 位置和結構已經變更，以提供更好的使用者經驗。使用者資料現在儲存於 \users\%username%\ 資料夾結構內。Pictures、Music、Documents、Desktop 和 Favorites 全都是直接在此結構之下的新資料夾。如果應用程式使用 ShGetFolderPath 函數，並且動態地使用資料夾路徑，它將會自動重新導向到新的路徑和檔案位置。一般而言，應用程式將不會由於這些變更而看到相容性的影響。

快速使用者切換 (FUS)

快速使用者切換 (FUS) 現在提供於 Windows Vista 的所有版本上，包括網域加入的電腦。應用程式和安裝程式需要察覺 FUS，並可處理多重登入使用者工作階段和終端機伺服器案例。如需詳細資訊，請參閱 Microsoft Windows XP 快速使用者切換：建立商務應用程式的設計指引。

CriticalSection 程式碼變更

CriticalSection 程式碼已變更，以增加安全性和穩健性。使用關鍵區段鎖定的應用程式：

• 一定要初始化關鍵區段。
• 不應讀取未記載物件。讀取未記載結構以評估關鍵區段狀態的應用程式很可能會在尋找未初始化和釋出的關鍵區段時中斷。
• 應避免枯等。呼叫 Sleep 同時擁有關鍵區段鎖定的應用程式現在可能導致其他需要該鎖定的執行緒枯等。Sleep 呼叫應在 LeaveCriticalSection 呼叫之後放置。

如需詳細資訊，請參閱 MSDN 中的關鍵區段物件主題。

使用者介面特殊權限孤立 (UIPI)

在 Windows Vista 中，使用者介面特殊權限孤立 (User Interface Privilege Isolation，UIPI) 的預設狀態為啟用。由於此安全性功能，較低完整性層級的處理程序並不能使用 Windows Messaging (SendMessage) 來與較高完整性層級的處理程序通訊。這意味著執行於標準使用者層級下的應用程式不能與其他以提高之系統管理層級執行的應用程式通訊。這也意味著安裝鍵盤或滑鼠勾點的應用程式將需要變更，才能使用資訊清單和要求提高權限。如需相關資訊，請參閱本文件中的「Internet Explorer 受保護模式」小節。

Default Programs

功能影響

中

簡單描述

Default Programs 是用來管理每一使用者檔案和通訊協定關聯的新基礎結構，是針對競爭性應用程式而設計的。應用程式需要登錄，才能使用 Default Programs 的功能。請注意 Default Programs 在 Windows Vista 和以後的版本中將有很大的可見度，並可讓應用程式更容易撰寫與維護某些工作。

在今日的軟體生態中，您很難管理您在 Windows 內的預設行為，因為有這麼多的競爭應用程式在處理一般工作。許多人都有多個軟體程式來處理相同的工作：瀏覽網頁、檢視相片、播放音樂、觀賞影片和管理電子郵件等等。許多人會有很大的困難，因為即使他們決定嘗試一下某個應用程式，但它總是接管其系統和預設行為，例如按兩下的行為。

當我們開始加入多重使用者到同一台電腦時，問題將更加嚴重。當多個使用者開始使用不同的應用程式時，他們會開始取代彼此的預設值。此問題的根源在於，通訊協定和檔案關聯通常是透過寫入登錄中的機碼到 HKLM (HKEY_Local_Machine) 中，而以每一機器為單位來取得或管理。讓此事更為困難的是，登錄中有很多地方必須由應用程式寫入來取得預設值。

這通常會導致一些應用程式寫入登錄中的某個地方，而其他應用程式寫入另一個地方。而令問題雪上加霜的是，當這些應用程式要求重新成為某些行為的預設值時，卻無法做到，因為它們並非寫入其他應用程式所寫入的所有地方。核心問題在於，需要有一個簡單的方式來管理系統上彼此競爭利益的應用程式。

補救

Windows 解決此問題的第一個嘗試為 SPAD (設定程式存取與預設值，Set Program Access and Defaults)。這讓使用者有能力允許應用程式嘗試重新取得以前的預設行為。SPAD 允許應用程式執行一些登錄的程式碼來回復到某個狀態。SPAD 對於整台電腦而言，是一個很大的切換和設定預設值。SPAD 在 Windows Vista 中仍然可用，以便讓系統管理員設定機器的預設值和隱藏存取，但不會成為使用者的主要預設值經驗。

在 Windows Vista 中，我們提供一組新的功能供應用程式運用。這一組新功能稱為 "Default Programs"。Default Programs 旨在協助使用者選擇其預設行為。它的主要理念為 Windows Vista 和以後版本中的預設值主要將以每一使用者層級來控制，而非每一機器層級。這可為多重使用者的電腦環境提供更大的彈性，我們相信這將會成為標準。它的一部份是為使用者加入新的集中式 UI，其他部分則是提供 ISV 所需的工具來協助使用者表達其選擇。Default Programs 提供應用程式：

• 取得預設值的簡化處理程序。
• 每一使用者檔案和通訊協定關聯。
• 程式化的方式來檢查預設值。
• 可重複使用的通用 Windows UI。
• Windows 內的通知區域。

此功能主要是針對競爭性應用程式而設計的，也就是想成為 mp3 和 jpeg 之類檔案類型或 http 和 mailto 之類通訊協定的預設值的應用程式。主要功能在處理自己的通訊協定和檔案關聯的應用程式通常不需要使用此新功能，因為它們不用擔心其他應用程式蓋掉它們的設定。非競爭性應用程式的行為和安裝方式就和在 XP 中一樣。不過，任何應用程式都可運用新的 "Default Programs" 工作。

"Default Programs" 功能被建入到作業系統之中，作為一系列的控制台和開放 API。應用程式要使用控制台或 API，它需要在安裝時登錄，透過寫入特定的架構，成為 Default Programs 的一部份。這將讓應用程式顯示在 Default Programs 控制台內，如此使用者即可在任意時點，還原應用程式的預設檔案關聯和通訊協定。

一旦應用程式以 Default Programs 登錄之後，該應用程式即可運用 API 所提供的新功能。Default Programs 提供 API 來：

• 還原所有登錄的預設值。
• 還原單一登錄的預設值。
• 查詢特定的預設檔案關聯/通訊協定/開始功能表標準的擁有者。
• 啟動特定應用程式的 Defaults UI。
• 清除所有的每一使用者關聯。

Default Programs 工作旨在讓使用者很輕鬆地在安裝之後表達其選擇，並提供應用程式一個簡單的架構來競爭預設值與要求它們。

為何使用 Default Programs

高階的要點如下：

• Default Programs 協助應用程式進行搜索。
• 允許所有系統管理員寫入至 HKLM 的基礎結構已針對 Windows Vista 做了變更。
• Default Programs 可讓應用程式維持 XP 同位檢查處理流程，同時變更很少的程式碼。
• 僅要求機器層級的預設值並不會一直提供您要的結果。

使用 Default Programs 架構的競爭性應用程式有一個明顯的消費者好處，不過應用程式使用 Default Programs 也有一個很大的好處。

Default Programs 為登錄的應用程式提供豐富的 UI 經驗，讓它可以確實地通知使用者它可以做到的所有絕佳功能。此外，以 URL 數位簽署的應用程式將可顯示該 URL，並讓使用者輕鬆地瀏覽回其首頁，並檢視公司提供的其他應用程式和增強功能。

使用新的 API 集合也可大幅減少新應用程式的開發成本。幾乎所有的競爭性應用程式都會監視或檢查它們自己是不是預設值。運用新的 API 集合，這件事可在單一的 API 呼叫中完成，而不用像在先前的 OS 版本中那樣地毯式地搜尋登錄。

使用新的 API 集合，也可協助應用程式以使用者帳戶控制 (User Account Control，UAC) 正確地運作於新的世界之中。UAC 的實作方式是讓系統看待一個系統管理員就像是標準的使用者一般。這意味著在 Windows Vista 和以後的版本中，系統管理員並不能按慣例寫入 HKLM。如此處理程序就不能在系統管理員不知情的狀況下，以他的名義來運作。安裝程序一般都會提高特殊權限，因為經驗就是這樣，但對於希望能夠在安裝之後要求預設值的應用程式而言，它們需要以每一使用者層級，而非每一機器層級來要求預設值。切換到新的 API 集合可自動做到此事。嘗試在安裝之後要求每一機器預設值的應用程式將會失敗。

應用程式改使用 Default Programs 的其他強烈理由是一致地取得您要的結果。檔案和通訊協定關聯是從登錄中的階層式結構中衍生而得。此結構的一部份指定了每一使用者的預設值一定比每一機器的預設值優先被選到。這意味著如果應用程式決定像在 XP 中一樣，透過寫入至 HKLM，在其程式碼中建立提高權限點，以要求預設值，它不一定可得到想要的結果。只要另一個類似的應用程式一安裝，並使用採用了每一使用者檔案和通訊協定關聯的 Default Programs API，先前的應用程式就不再是預設值，因為每一使用者預設值具有更高的優先順序。

Default Programs UI

Default Programs 具有多個 UI 項目。這些圖片將不會是此經驗在 Windows Vista 正式推出時的最後外觀，不過它們將提供您功能和認知上的一般性瀏覽。

Default Program UI 流程：

Startmenu:

Default Programs 控制台中樞頁面：

設定一個 Default Program 頁面：

只有已經登錄的應用程式會顯示在應用程式清單內。當應用程式登錄一個描述值時，它會顯示在右邊的清單方塊內。登錄時需要一個描述。

[還原預設值] 將重新取得應用程式的所有登錄預設值。[進階] 可讓使用者為應用程式選擇特定的預設值。

注意   為了在 UI 中顯示 URL，應用程式必須內嵌 URL 到其數位簽署的驗證碼憑證中。未簽署的應用程式將無法顯示 URL。

進階

此檢視顯示了應用程式已登錄的所有項目，以及什麼應用程式目前擁有預設值。有一個 Windows 公用 API 可讓應用程式呼叫此視窗，讓應用程式不再需要維護檔案關聯 UI。我們建議使用此 UI，而非建立自訂 UI。

Default Programs 方針和最佳作法：

安裝

安裝到作業系統內的應用程式應維持如同 XP的安裝方式。此外，應用程式需要為預設程式建立其架構。登錄新的架構可讓應用程式運用所有的新功能。採用 XP 之方式安裝的應用程式仍可運作，但是應用程式將需要登錄，才能在安裝後取得預設值。應用程式應在安裝時進行下列步驟：

1. 安裝必要的二進位檔 (如同 XP)。
2. 寫入程式 ID 到 HKLM (如同 XP)。

   注意   應用程式需要為其關聯建立應用程式的特定 ProgID。

3. 要求機器層級的檔案關聯 (如同 XP)。
4. 寫入新的 Default 程式架構 (Windows Vista 的新功能)。

安裝之後

首次執行經驗

應用程式可選擇擁有每一使用者首次執行經驗。這是建議作法。應用程式應在此詢問有關每一使用者選項的問題。應用程式不應擁有每一機器首次執行。首次執行經驗應提供使用者 2 個主要的選擇：

1. 接受預設的應用程式設定 (這應該是預設行為)。
2. 自訂設定。

[接受預設值] 應該會呼叫 Program Defaults API，要求某個應用程式的所有已登錄預設值。這會將預設的檔案關聯從每一機器設定變更為每一使用者設定。

[自訂設定] 應會將使用者帶入檔案關聯 UI 中。應用程式可透過程式方式呼叫特定應用程式的 Windows 檔案關聯 UI。這是建議的作法。

Defaults UI:

選擇顯示 Defaults UI 的應用程式應使用新的 Default Programs API，以開啟檔案關聯的應用程式中心版本。

Litware Media 播放程式的範例：

圖 8

在此檢視中，使用者將看到特定應用程式已登錄的所有預設值。使用者可看到應用程式所擁有的項目、目前的預設值，並將預設值變更為新的應用程式。儲存時，所有更新將被認可，而視窗將會關閉。取消時，視窗將會關閉。提供此 UI 的目的，是讓應用程式不需要花費開發資源來維護檔案關聯 UI，或擔心是否正確地設定關聯。

檢查應用程式是否為預設值：

網頁瀏覽器或電子郵件用戶端之類的許多應用程式都有使用者通常不知道的檔案和通訊協定關聯。這些項目的範例包括 HTTP:\ 和 Mailto:\。這些應用程式一般會在應用程式叫用時檢查看它們是否為預設值。應用程式應透過新的 Default Programs API 集合，檢查看它們是否為預設值。如果應用程式不是預設值，應用程式應提供使用者 UI 來要求使用者：

1. 將每件事保持原狀。
2. 讓此應用程式成為預設值。

應用程式也應包含一個預設為已核取的核取方塊，其內容相當於「當 <應用程式> 不再是預設值時請告訴我」。應用程式不應未詢問使用者，即自動要求預設值。應用程式應透過呼叫 Default Programs API 來實作 #1，以重新取得應用程式已登錄的所有預設值。

使用 Internet Explorer 的範例為：

以 Default Programs 登錄

Default Programs 的運作方式是讓每個應用程式明確地登錄想要視為預設值的檔案關聯和通訊協定。其作法是在 HKLM 中登錄下列架構。請注意 ApplicationDescription 可為字串文字或是字串資源參考。後者允許 MUI'ization。

HKLM\%APPLICATIONCAPABILITYPATH%
   ApplicationDescription = REG_EXPAND_SZ "@path\to\dll.dll,-resourceId"
   ApplicationName = REG_EXPAND "@path\to\dll.dll,-resourceId"
   \FileAssociations
   .file-extension = REG_SZ "file-extension-progid"
   \UrlAssociations
   url-scheme = REG_SZ "url-scheme-progid"
   \MIMEAssociations
      MIME = REG_SZ "mime-progrid"
   \Startmenu  REG_SZ            
   StartmenuInternet ="%app Name%"
          Mail ="%App Name%" 

注意   這些是已在 HKLM\software\clients中登錄成規範的應用程式的指標。其值應為 HKLM\software\clients\StartmenuInternet 或 HKLM\software\clients\Mail 底下的機碼名稱。

HKLM\Software\RegisteredApplications
   unique-app-name = REG_SZ "%APPLICATIONCAPABILITYPATH%"

注意   ApplicationDescription 是必要的。而 ApplicationName 則是選擇性項目，可讓不同類型的應用程式指到相同的 .exe，並顯示成不同名稱。

注意   為了在 UI 中顯示 URL，應用程式必須內嵌 URL 到其數位簽署的憑證中。未簽署的應用程式將無法顯示 URL。

使用 Contoso 網頁瀏覽器的範例如下：

注意   這應該是一個允許當地語系化的 DLL。

HKLM\software\Contoso\WebBrowser\Capabilities
   Description =" The award-winning Web browser is better than ever. 
   Search the internet in second and find anything you want. Use 
   integrated tabs and new phishing detectors to enhance your internet experience."
\FileAssociations
  .htm = ContosoHTML
  .html = ContosoHTML
  .shtml = ContosoHTML
  .xht = ContosoHTML
  .xhtml = ContosoHTML
\UrlAssociations
  http = Contoso.Url.Http
  https = Contoso.Url.Https
  ftp = Contoso.Url.ftp
\Startmenu
  StartmenuInternet = "Contoso.exe"

HKLM\software\RegisteredApplications
  Contoso.WebBrowser.1.06 = software\Contoso\WebBrowser\Capabilities

ProgIds

應用程式需要提供應用程式的特定 ProgId。這應擁有一般寫入預設機碼內的所有資訊。應用程式可進行 progid 到通訊協定/延伸模組的一對一對應，或進行一對多的對應。它是完全隨意的，並且兩個方法的運作方式相同。在以上的範例中，ContosoHTML 指向單一 progid，它擁有 htm、html、shtml、xht 和 xhtml 的 shellexecute 資訊。針對通訊協定，每個通訊協定都定義一個特定的 progid。這可讓每個通訊協定的執行字串都不一樣。

在為 MIME 定義 ProgID 時，prog-id 必須包含 CLSID 子機碼，以及對應應用程式的類別 id。您可在存放於 HKLM 中的 MIME 資料庫內，用它來針對類別 id 進行查閱。

值的定義

Capabilities—特定應用程式的所有 Default Programs 資訊都放在此登錄子機碼底下。capabilities 子機碼一定是放在應用程式登錄機碼底下。

描述—Default Programs 設計來讓使用者做出明智的選擇。我們可讓每個應用程式登錄一個描述字串，以便讓每個應用程式都有方法將其能力通知使用者。此值為 \capabilities 底下的屬性。

注意   這是一個必要的欄位。應用程式必須在此提供一個項目來顯示於 UI 之中。務必將您的字串當地語系化。

ApplicationName—指定將會顯示在 Default Programs UI 中的名稱。如果此欄位未填妥，那麼 Default Programs 會使用與應用程式的第一個登錄 progid 相關聯的 .exe 名稱。應用程式名稱一定需符合 RegisteredApplications 名稱。

FileAssocations—檔案關聯子機碼是應用程式希望要求的特定檔案關聯所放置的位置。每個檔案關聯都儲存成 FileAssocations 子機碼的屬性。每個延伸模組應指向應用程式的特定 progid，而非一般 progid。

UrlAssocaitions—URL 關聯子機碼是應用程式希望要求的特定 URL 關聯所放置的位置。每個 URL 關聯都儲存成 UrlAssocations 子機碼的屬性。每個通訊協定應指向應用程式的特定 progid，而非一般 progid。

MIMEAssocaitions—MIME 關聯子機碼是應用程式希望要求的特定 MIME 關聯所放置的位置。每個 MIME 關聯都儲存成 MIMEAssocations 子機碼的屬性。此名稱應為存放在 MIME 資料庫內的 MIME 名稱的確切名稱，而該值應為其中擁有對應 CLSID 的應用程式特定 progid。

Startmenu—startmenu 子機碼主要用於開始功能表上的網際網路和電子郵件槽。也登錄成為這些點之競爭者的應用程式可連結該功能到其 Default programs 項目。提供指到開始功能表登錄的連結，可讓應用程式在於預設程式中顯示時，展示它也想要對應的電子郵件或網際網路連結。如果提供此資訊，並且使用者將預設值還原成此程式，那它也會取代 startmenu 點。該登錄應該就是 HKLM\software\clients\StartMenuInternet 或 HKLM\software\clients\Mail底下的登錄機碼名稱。在郵件用戶端的狀況中，這也會設定預設的 MAPI 用戶端。

注意   有一個個別的開始功能表登錄。如需詳細資訊，請參閱 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_adv/registeringapps.asp

HKLM\software\RegisteredApplications—RegisteredApplications 是必要的，以便讓 OS 知道每個應用程式的所有相關資訊的存放位置。這應該是應用程式的名稱。

使用 Default Programs API

一旦應用程式已登錄，應用程式就可運用許多 API 來提供更好的使用者經驗。此介面應出現在六月的 CTP 中。Beta2 發行版本中有一個稍微不同的介面，它是基於客戶的意見反應而變更的。

typedef [v1_enum] enum tagASSOCIATIONLEVEL
{
   AL_MACHINE,
   AL_EFFECTIVE,
   AL_USER
} ASSOCIATIONLEVEL;

typedef [v1_enum] enum tagASSOCIATIONTYPE
{
   AT_FILEEXTENSION,
   AT_URLPROTOCOL,
   AT_STARTMENUCLIENT,
   AT_MIMETYPE
} ASSOCIATIONTYPE;

[
   object,
   uuid(4e530b0a-e611-4c77-a3ac-9031d022281b),
   pointer_default(unique),
   helpstring("Application File Extension and URL Protocol Registration")
]

interface IApplicationAssociationRegistration : IUnknown
{
   HRESULT QueryCurrentDefault(
      [in, string] LPCWSTR pszQuery,
      [in] ASSOCIATIONTYPE atQueryType,
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [out, string] LPWSTR* ppszAssociation);

   HRESULT QueryAppIsDefault(
      [in, string] LPCWSTR pszQuery,
      [in] ASSOCIATIONTYPE atQueryType,
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [in, string] LPCWSTR pszAppRegistryName,
      [out] BOOL* pfDefault);

   HRESULT QueryAppIsDefaultAll(
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [in, string] LPCWSTR pszAppRegistryName,
      [out] BOOL* pfDefault);

   HRESULT SetAppAsDefault(
      [in, string] LPCWSTR pszAppRegistryName,
      [in, string] LPCWSTR pszSet,
      [in] ASSOCIATIONTYPE atSetType);

   HRESULT SetAppAsDefaultAll(
      [in, string] LPCWSTR pszAppRegistryName);

   HRESULT ClearUserAssociations();
}
   
interface IApplicationAssociationRegistrationUI : IUnknown
{
   HRESULT LaunchAdvancedAssociationUI([in, string] LPCWSTR pszAppRegName);
}

AssociationLevel

AL_MACHINE—傳回延伸模組的機器預設值。

AL_EFFECTIVE—傳回目前使用者的有效預設值。

注意   這是大多數應用程式應使用的選項。

AL_USER—傳回每一使用者預設值。如果沒有每一使用者預設值，它會傳回失敗碼 0x80070483。

AssociationType

AT_FILEEXTENSION—用來查詢 .htm 或 .mp3 之類的副檔名。

AT_URLPROTOCOL—用來查詢 http:// 或 mailto: 之類的通訊協定。

AT_STARTMENUCLIENT—用來查詢郵件或網際網路連結的 startmenu 用戶端的擁有者。

AT_MIMETYPE—用來查詢 audio/mp3 之類的 MIME 類型。

QueryCurrentDefault

傳入延伸模組的字串 (.mp3、HTTP 等等)、它的延伸模組類型、關聯層級，並且它將傳回目前預設值的 ProgID。一般而言，應用程式應使用 AL_EFFECTIVE 關聯層級，因為這將決定使用者的有效預設值。呼叫者必須 CoTaskMemFree 傳回的 progid 字串。

QueryAppIsDefault

傳入延伸模組的字串 (.mp3、HTTP 等等)、它的延伸模組類型、關聯層級和已登錄的應用程式名稱，並且它將根據該應用程式是否擁有預設值，傳回 BOOL。一般而言，應用程式應使用 AL_EFFECTIVE 關聯層級，因為這將會決定使用者的有效預設值。

QueryAppIsDefaultAll

傳入關聯層級和已登錄的應用程式名稱，並且它將根據該應用程式是否擁有它所有的登錄預設值，傳回 BOOL。一般而言，應用程式應使用 AL_EFFECTIVE 關聯層級，因為這將會決定使用者的有效預設值。

SetAppAsDefault

傳入已登錄應用程式的名稱、延伸模組 (.mp3、HTTP 等等) 和它的延伸模組類型。預設值將會設定成已登錄的應用程式。

SetAppAsDefaultAll

傳入已登錄應用程式的名稱，並且它將設定所有已登錄的預設值給該應用程式。

ClearUserAssociations

刪除目前使用者的所有每一使用者關聯，並將該使用者傳回給每一機器預設值存在的所有地方。目前並沒有任何已定義的合作夥伴或協力廠商案例適合呼叫此功能。不過如果他們想要，應該就可以做到。

LaunchAdvancedAssociationUI

指定的應用程式登錄名稱必須符合登錄於 HKLM\Software\RegisteredApplications 底下的某個值。這將會啟動所指定應用程式的 Set Program Associations 頁面。這是針對想要提供 UX 直接連結給其進階關聯組態的應用程式而設計的。

注意   此 API 集合只能用於 Windows Vista 和以後的版本。支援舊版 OS (XP、Win2K 和 Win98) 的應用程式應使用 sku 檢查來區別 Windows Vista 之前和 Windows Vista 之後的 OS，以便在這些 OS 上使用其現存的預設值程式碼。

程式碼範例

透過 Contoso 網頁瀏覽器的登錄，以下列出了如何使用 API 集合來實作它。

查詢 Contoso 網頁瀏覽器是否擁有它所有的預設值：

HRESULT CheckContosoHasAllDefaults(__out BOOL* pfHasAllDefaults)
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                 (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->QueryAppIsDefaultAll(AL_EFFECTIVE,
                                        L"Contoso.WebBrowser.1.06",
                                        pfHasAllDefaults);

        pAAR->Release();
    }

    return hr;
}

查詢 Contoso 網頁瀏覽器是否擁有 .htm 的預設值：

HRESULT CheckContosoHasDotHTM(__out BOOL* pfHasDotHTM)
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                  (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->QueryAppIsDefault(L".htm",
                                     AT_FILEEXTENSION,
                                     AL_EFFECTIVE,
                                     L"Contoso.WebBrowser.1.06",
                                     pfHasDotHTM);
        pAAR->Release();
    }
    return hr;
}

設定 Contoso 網頁瀏覽器成為 .HTM 的預設值：

HRESULT SetContosoAsDefaultForDotHTM()
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                  (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->SetAppAsDefault(L"Contoso.WebBrowser.1.06",
                                   L".htm",
                                   AT_FILEEXTENSION);

        pAAR->Release();
    }

    return hr;
}

檔案關聯文件

更多關於建立 File Association 的資訊，請參閱 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fileassoc.asp

更多關於建立 Registering Programs with Client Types 的資訊，請參閱 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_adv/registeringapps.asp

更多關於建立 Verbs 和 File Associations 的資訊，請參閱 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_verbs.asp

更多關於建立 File Types 的資訊，請參閱 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_file_types.asp

Windows Vista 中的程式相容性協助 (PCA) – 客戶就緒文件

PCA 簡介

附屬應用程式中的 [程式相容性精靈] 以及檔案屬性中的 [相容性] 索引標籤都是使用者修復 Windows XP 中的程式相容性問題的有用工具。這些工具的主要限制在於其搜索能力，以及使用者需要知道何時該使用這些工具。程式相容性協助 (Program Compatibility Assistant，PCA) 是 Windows Vista 中的全新功能，可讓具有相容性問題的較舊版程式以自動化方式運作得更好。如果 PCA 在使用者執行較舊版程式之後偵測到已知的相容性問題，它會通知該問題的使用者，並在使用者下次執行該程式之前套用解決方案。

注意   PCA 是僅適合用戶端的功能，它並無法用於伺服器上。

下列的章節描述了使用者可能會用到 PCA 的案例、使用者經驗的詳細資料、適用於每一個案例的解決方案、以及日後如何管理 PCA 所做的設定。最後一節說明如何從 PCA 中排除程式。

PCA 案例

偵測安裝失敗

PCA 的一個主要案例是偵測無法安裝於 Windows Vista 之上的安裝程式，並提供套用 Windows XP 相容性模式的解決方案。

最常見的安裝失敗是由於安裝程式將它們所能執行的 Windows OS 版本檢查硬式編碼在程式內。這些安裝程式一般會失敗，並出現一個錯誤訊息說明不支援目前的 Windows 版本，然後終止。為提供有關此失敗的更多詳細資料，程式通常會使用 GetVersion 或 GetVersionEx API 來取得所執行的 Windows OS 版本的相關資訊。在 Windows Vista 中，這些 API 將傳回 6 作為主要版本。如果程式採硬式編碼來尋找 XP 版本 (主要版本為 5)，那它在 Windows Vista 中就會失敗。Windows XP 相容性模式所包含的 XPVersionLie 修復將在它呼叫 GetVersion 或 GetVersionEx API 時，提供程式 OS 的 XP 版本。

下列為來自 Microsoft Intellitype 軟體的鍵盤和滑鼠於 Windows Vista 中失敗的範例錯誤訊息，這是在 Windows 內部的應用程式相容性測試中發現的。

圖 10

PCA 將偵測此案例，並在安裝程式終止之後，顯示一個類似以下的使用者介面。

圖 11

當使用者選取 [使用建議的設定重新安裝] ('Reinstall using recommended settings') 選項時，Windows XP 相容性模式將套用到安裝程式，並且安裝程式將會自動重新啟動。

有關究竟發生何事的更多詳細資料，將透過下列的問題 / 解答來說明：

1. 偵測邏輯為何，以及 PCA 如何知道安裝程式是由於版本問題而失敗？

   PCA 並不會特別去尋找由於版本問題造成的安裝程式失敗。PCA 所使用的邏輯是去偵測安裝程式是否未成功地完成。它會監視被 Windows Vista 偵測為安裝程式的程式，並檢查該程式是否在「新增或移除程式」(ARP) 中登錄一個項目。如果沒有在 ARP 中建立任何項目，那麼 PCA 就會認定該安裝程式沒有成功地完成，並會在顯示 UI 之前等候安裝程式終止。

2. PCA 如何取得有關安裝程式的資訊？

   PCA 依賴 Windows Vista 中的使用者存取控制 (UAC) 功能，來知道某個程式是否為安裝程式。UAC 包含了安裝程式的偵測功能，並將確認偵測到的安裝程式將以提高權限來執行 (作為系統管理員)。這包括了在啟動程式之前從使用者處取得系統管理認證或確認。

3. PCA 的安裝對話方塊中的每個選項用處為何？
   • 使用建議的設定重新安裝

     這將會套用 Windows XP 相容性模式，並重新啟動程式。請參考下面的管理 PCA 設定的章節，取得如何套用相容性模式的更多詳細資料。

   • 'The program installed correctly'

     在某些狀況中，PCA 可能會發現某個安裝程式正確地完成，但並未在 ARP 中建立一個項目。在這些狀況中，使用者可使用此選項。

   • 'Cancel'

     PCA 不會做任何事。

這所有的選項將導致 PCA 對話方塊消失。除非使用者在上一個 PCA 對話方塊中選取 [取消] 選項，否則 PCA 不會針對相同的安裝程式再次出現。

UAC 下偵測程式失敗

第二個 PCA 案例是在於使用者存取控制 (UAC) 下執行時偵測程式失敗。PCA 可偵測到非提高權限的程式在啟動子系執行檔時失敗的特殊案例，因為它被偵測為安裝程式，並需要以提高權限來執行。這通常是程式嘗試啟動 updater.exe 時的狀況。如果同一個 updater.exe 是從檔案總管來執行，它將如預期地提高權限來執行，因為檔案總管知道如何啟動 UAC 同意 UI，並以提高權限來執行程式。

在此狀況中，PCA 將套用 ELEVATECREATEPROCESS 相容性模式，它可讓程式下次成功地以系統管理員的身份啟動子系執行檔。當程式下次嘗試啟動子系執行檔時，使用者將看到 UAC 同意 UI 提供或確認系統管理員的認證。

下列為將顯示在此案例中的 PCA 對話方塊範例，並以測試程式來做說明。

圖 12

此處的測試程式嘗試啟動需提高權限來執行的更新程式，並且失敗。這是由 PCA 所偵測。現在，當程式再次執行，並且嘗試啟動更新程式時，就不會再失敗，並且可成功地提高權限來執行。使用者將看到 UAC 同意 UI，如下所示。

圖 13

有關究竟發生何事的更多詳細資料，將透過下列的問題 / 解答來說明。

1. 偵測邏輯為何，以及 PCA 如何知道程式無法啟動一個需要以系統管理員的身份來執行的子系執行檔？

   此案例的偵測是透過 CreateProcess API 的測試設備完成的，可用來偵測由於子系處理程序需要提高權限來執行，導致啟動失敗的狀況。

2. 為什麼在此 PCA 對話方塊中沒有選項？

   由於此案例中的問題偵測極為可靠，解決方案 (ELEVATECREATEPROCESS 相容性模式) 將會自動套用，而不提供使用者任何選項。

啟動時通知使用者有關已知程式的相容性問題

除了下方所列的兩個執行階段問題偵測案例外，PCA 也包含一個案例，探討已知具有相容性問題的程式清單的程式啟動。此清單將存放在系統應用程式相容性資料庫內。此案例從 Windows XP 即存在，而這些訊息稱為應用程式說明 (Application Help，亦稱為 apphelp) 訊息。

apphelp 訊息有兩類。如果程式已知為不相容，並且若允許該程式可能對系統產生嚴重的影響 (例如，產生停止錯誤，或安裝之後無法開機等等)，那麼下方所示的封鎖訊息就會出現。

注意   Microsoft 會針對封鎖的程式取得 ISV 的核准。

圖 14

另一類型的訊息是一個非封鎖的訊息，類似於下列的訊息。它將用於程式具有已知的相容性問題，但對於系統的影響不太嚴重的狀況。

圖 15

在這兩個狀況中，'Check for solutions' 會傳送 Windows 錯誤報告，以取得 Microsoft 的線上回應。回應將會顯示在用戶端的「問題解決方案」(Solutions to Problems) (wercon.exe) UI 中。一般而言，回應有三種類型：

• 將使用者指向 ISV 針對該程式所提供的更新。
• 將使用者指向有更多資訊的 ISV 網站
• 將使用者指向有更多資訊的 Microsoft 知識庫文章

管理 PCA 所做的設定

相容性模式將透過在下列項目底下設定登錄機碼，來套用到程式

'Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers'，機碼名稱 = '執行檔的完整路徑'，字串值 = '所套用的相容性模式名稱'。

在安裝案例的狀況中：

• 相容性模式的名稱將為套用到安裝程式 .exe 的 ' WINXPSP2'。
• 登錄機碼將設定於 HKEY_LOCAL_MACHINE 底下，以便讓此解決方案對所有的使用者都有效。

在 UAC 案例的狀況中：

• 相容性模式的名稱將為套用到程式 .exe 的 'ELEVATECREATEPROCESS'。登錄機碼將設定於 HKEY_CURRENT_USER 底下，並且解決方案只對目前的使用者有效。
• 這些機碼需要刪除，才能移除 PCA 所套用的相容性模式。

從 PCA 中排除程式

PCA 的設計目的在於偵測較舊版程式的問題，而不是監視針對 Windows Vista 開發的程式。從 PCA 中排除程式的最佳方式是讓程式包含一個 標記 UAC 的執行層級 (可為系統管理員或有限制的使用者) 的應用程式資訊清單。這代表該程式已通過測試，可運作於 UAC (和 Windows Vista) 底下，此資訊清單的 PCA 檢查，並排除該程式。這同時適用於安裝程式和一般程式。如需 UAC 以及如何建立此 UAC 資訊清單的詳細資訊，請參閱 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp。

提供群組原則設定，以便在需要時為所有程式停用 PCA。

原則的名稱為 'Turn Off Program Compatibility Assistant'，並可在群組原則編輯器 (gpedit.msc) 的 'Administrative Templates -> Windows Components -> Application Compatibility' 底下找到。

管理 Apphelp 訊息

企業中的 IT 專家可針對其企業中的程式，使用「相容性系統管理員」工具來停用系統應用程式相容性資料庫中的 apphelp 項目，或新增包含 apphelp 訊息的自訂資料庫。

「相容性系統管理員」工具將當作應用程式相容性工具組的一部份出貨。如需更多關於工具組的資訊，請參閱 http://www.microsoft.com/technet/windowsvista/appcompat/tools.mspx

圖形裝置介面 (GDI)

繪製 (WM_PAINT) 行為差異

功能影響

低

簡單描述

作為「桌面視窗管理員」工作的一部份，Microsoft 對於應用程式繪製到螢幕上的方式做了一些細微但重要的變更。在 Windows Vista 之前，hwnd 會直接繪製到螢幕上，這有某些好處，但卻限制了 Windows 可以顯示與管理最上層視窗的方式。在 Windows Vista 中，所有最上層的視窗將呈現成幕後的點陣圖 (類似於 WS_EX_LAYERED)，並且「桌面視窗管理員」會將影像合併在一起，以繪製桌面。

表現形式

工具提示、快顯功能表、球形文字說明、開頭顯示畫面等項目周圍的黑色區域。

這可能發生於應用程式未繪製整個 hwnd 時，通常是因為應用程式假定背景視窗中的像素已經夠好了。這是 Microsoft 積極處理的一塊區域，因此不用根據目前的程度過度最佳化，但請提供我們您的意見反應。

黑色的閃爍顯示

相關的問題發生於應用程式在不屬於 WM_PAINT 的地方繪製。USER 偵測到應用程式正在繪製，並且重繪桌面，但是當此事發生時，應用程式可能還未畫完 hwnd，因此結果就是背景的點陣圖還包含未初始化的像素 (黑色)。同樣地，Microsoft 正積極地處理此區域，因此請將您認為需要改進的地方送給我們。

應用程式停用半透明效果

這可能發生於應用程式繪製到視窗的非用戶端區域時 (標題列)。

橡皮框、自訂陰影和其他特效

這些通常是使用 GetDC(NULL) 完成的；不過，當應用程式以點陣圖作為背景、而非直接繪製到螢幕時，讀取和寫入到 GetDC(NULL) 常會有問題。讀取和寫入到螢幕遠比 Windows XP 來得慢。此外，並非支援所有的 GDI rasterop(但我們有支援 XOR)。

改善遠東字型

Windows Vista 已針對中文、日文和韓文字型做了許多變更，讓它們更具可讀性；一個副作用是這些新字型中的文字配置可能有些不同，因為字元會有不同的寬度。請考慮測試您的文字在螢幕和印表機上如何配置。亦需考慮測試遠東語言可能與拉丁語言集 (例如英文) 混用的場合。

呈現效能

功能影響

低

簡單描述

大部份的應用程式在 Windows Vista 上的執行速度都一樣快或更快，但有一些變更可能需要監視。

表現形式

整體的 GDI 繪製效能比較慢？

LineTo 和 Rectangle 之類的 GDI 基本指令現在將以軟體呈現，而非以視訊硬體呈現，這將大為簡化顯示驅動程式。我們不認為這會影響許多真實世界的應用程式，但若真是如此，就需要您的意見反應。

較慢的文字呈現？

DrawText 之類的呼叫更妥善地支援國際和東亞的語言，我們不認為這會影響真實世界的應用程式，但若真是如此，就需要您的意見反應。

減少的應用程式位址空間？

最上層視窗的點陣圖是儲存於應用程式的位址空間 (請參閱繪製的小節)，因此可用的位址空間可能會減少幾個 MB。

讀取和寫入 GetDC(NULL)？

此操作比先前的 Windows 版本慢，因為應用程式現在會呈現到幕後的點陣圖，而非直接繪製到螢幕上。可能的話，考慮繪製到以您的 HWND 為背景的 HDC，或建立覆疊視窗。GetDC(NULL) 仍是取得螢幕快照的偏好方式。

UIPI (使用者帳戶控制的 GUI 部分)

功能影響

低

簡單描述

作為抵禦惡意軟體的新增防禦層，Windows Vista 可讓不同的 UI 應用程式以三層不同的 UI 特殊權限來執行。應用程式可以任意地與相同和較低權限的其他應用程式互動，但是不能與較高權限的應用程式進行修改或交談。大部份的應用程式將以中權限來執行，需要系統管理員特殊權限的應用程式會以較高模式來執行，而像是低權限 Internet Explorer 之類的受限處理程序則使用最低特殊權限模式。

更明確地說，較低特殊權限模式中的應用程式一般不能傳送訊息給較高特殊權限的應用程式，除非較高特殊權限的應用程式透過呼叫 ChangeWindowMessageFilter()，明確地允許該訊息。同樣地，較低特殊權限的應用程式可以讀取，但是不能修改較高特殊權限應用程式所擁有的 HWND。基於相容性理由，SendMessage 和其他的 API 將傳回成功，即使 API 因為特殊權限問題而被封鎖。同樣地，在相容性影響高、安全性風險低的地方，有時候低特殊權限的應用程式允許傳送不請自來的訊息給高特殊權限的應用程式。

表現形式

與其他應用程式互動的應用程式將停止如此做。

調整視窗位置、為您鍵入按鍵、加入額外按鈕到視窗等用途的公用程式。

在不同的應用程式之間進行剪貼將會失敗。

它是否可正常運作，並支援您想要的所有不同剪貼簿格式 (RTF、HTML 等等)？

補救

日誌勾點

WH_JOURNALPLAYBACK 和 WH_JOURNALRECORD 具有跨處理程序的特性，因此需要最高的特殊權限層級。SendInput() API 在許多狀況中並不需要完整的 UI 特殊權限，因此您可以改用它，而非使用日誌勾點。

針對您擁有原始程式碼的程式，考慮檢查使用下列 API 的任何程式碼，因為它們通常指出處理程序的本質：

SendInput

RegisterWindowMessage

BroadcastSystemMessageEx

BroadcastSystemMessage

SetWindowsHook

SetWindowsHookEx

CallNextHookEx

CallNextHook

SetWinEventHook

AttachThreadInput

FindWindowEx

FindWindow

CreateDesktop

CreateDesktopEx

OpenDesktop

OpenInputDesktop

EnumDesktops

EnumDesktopWindows

SwitchDesktop

SetThreadDesktop

GetThreadDesktop

CloseDesktop

CreateWindowStation

OpenWindowStation

EnumWindowStations

CloseWindowStation

GetProcessWindowStation

這並非完整的清單，也不保證有任何項目需要變更，不過它可讓您在尋找問題以及將誤判降至最低之間取得絕佳的平衡。您可使用 findstr /s /g:temp.txt *.c *.cpp *.h *.hpp 來搜尋來源檔，此處的 temp.txt 是將以上的 API 清單複製到文字檔內。

高 dpi 縮放比例

功能影響

低

簡單描述

在使用高 dpi 設定的系統中，原本不認得高 dpi 的應用程式將會自動放大。

表現形式

長久以來，像素大小幾乎都是固定的，但是越來越多的 LCD 製造商提供越來越小像素的顯示器，亦稱為高每英吋點 (Dots Per Inch，dpi)。如果應用程式在一個高 dpi 螢幕上使用相同個數的像素，如同它在標準 96 dpi 的螢幕上一樣，那麼應用程式看起來會非常小。Windows Vista 可讓您將針對 96 dpi 螢幕所寫的應用程式加以放大，其作法是以較大的尺寸來呈現應用程式的點陣圖。就和所有的點陣圖縮放比例一樣，這可能會產生一些模糊，但是也會提供正確大小與適當呈現的影像。應用程式也可決定原生地支援高 dpi，以儘量提供最清晰的外觀。目前，應用程式可透過呼叫 SetProcessDPIAware()，關閉縮放比例並宣告它自己為 dpi 感知。目前正在研究以資訊清單型態的方式來宣告此事。如需撰寫原本即支援高 dpi 的應用程式的詳細資訊，請參閱 http://msdn.microsoft.com/library/en-us/dngdi/html/highdpiapp.asp。

本節的其他部分將討論非 DPI 感知的應用程式的潛在問題。應用程式會詢問 Windows 類似「捲軸的寬度為多少像素」的問題，因此當 96 dpi 的應用程式詢問時，Windows Vista 會提供應用程式 96 dpi 的答案。不過，在某些狀況下，Windows 並不會根據應用程式來提供答案，這通常是因為 Windows Vista 還沒有足夠的資訊 (請給我們相關的意見反應)，並且有時候因為「正確」的答案取決於應用程式想要以該答案來做何事。(螢幕座標通常會引起此問題。)

大部份的相容性問題來自於這些不完美的狀況。在測試時需檢視下列事項：

• 文字被裁剪 (局部隱藏)。
• 文字太大。
• 有些項目以錯誤的大小來繪製，或繪製在錯誤的位置。

補救

如需撰寫原生地支援高 dpi 的應用程式的詳細資訊，請參閱 http://msdn.microsoft.com/library/en-us/dngdi/html/highdpiapp.asp。

PNG Icons

功能影響

低

簡單描述

除了較舊的 BMP 型態的圖示外，圖示檔案格式 (*.ico) 現在還支援 PNG 影像；許多 Windows Vista 圖示都使用 PNG 的變化形式。

表現形式

檢視或編輯圖示檔的應用程式可能不瞭解此新格式。

連結

https://blogs.msdn.com/nickkramer/archive/2006/04/24/582365.aspx

此資訊是 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AppComp.asp 的增補資料。

命名管道強化

簡單描述

在 Windows Vista 中，許多服務都執行於較低特殊權限的帳戶底下，像是 NetworkService (NS) 或 LocalService (LS)，而非本機系統下。服務強化是改善服務間分隔的創舉，例如若某個服務受損，它就不能輕易地攻擊系統中的其他服務。Windows Vista 強化了 RPC 伺服器所使用的命名管道，以防止其他處理程序劫持它們。

在 Windows XP 底下，RPC 伺服器建立一個命名管道，並且管道上的 ACL 授與 LocalService 或 NetworkService 完整控制。這包括了建立管道的「伺服器執行個體」的能力，以便讓用戶端可以連接。應該建立管道執行個體的唯一處理程序應該是最初建立管道的處理程序。Microsoft 的 ACL 變更限制了只有最初建立管道的處理程序才能夠建立伺服器執行個體。

表現形式

下列服務會受到影響：當作 LocalService 或 NetworkService 執行的服務、選擇使用服務 Sids 的服務，以及在要求 "default" 命名管道安全性描述元的命名管道上使用 RPC 的服務。

選擇使用服務 Sids 的服務意味著根據預設下沒有協力廠商的服務會受到影響。服務 Sids 是 Windows Vista 中的新功能，您必須在您的服務組態中設定一個 DWORD，才能選擇加入。當開發人員選擇加入時，他們就有機會以新的服務強化行為來進行測試。此變更將為這些行為之一。

服務若在要求 "default" 命名管道安全性描述元的命名管道上使用 RPC，意味著若某個 RPC 伺服器由於特殊需求，指定自訂的安全性描述元，他們將不會看到任何變更。下列為受影響的管道清單：

Epmapper

Eventlog

Dav rpc

Keysvc

Winreg

Tapserv

W32time_alt

Termsvcapi

Ctx_winsta

Hydralspipe

SPAP 過時 (Pstore)

簡單描述

受保護存放區 (PStore) 提供應用程式一個介面來儲存必須妥善保護或不受修改的使用者資料，它在 Windows Vista 中已經變更成唯讀。這意味著嘗試建立新 PStore 資料項目的任何應用程式都會失敗。

補救

將 DPAPI 用於未來的 PStore 程序。

如需現有 PStore 項目和使用 DPAPI 來管理它們的詳細資訊，請參閱 http://msdn.microsoft.com/library/en-us/dnsecure/html/windataprotection-dpapi.asp?frame=true

WMI 提供者：預設的安全性裝載模型

簡單描述

WMI 提供者的預設 HostingModel 已經從 LocalSystem 變更成 NetworkServiceHost。

在之前的 Windows 發行版本 (Pre-Windows Vista Beta 2) 中，如果 WMI 提供者的 HostingModel (__Win32Provider.HostingModel property) 未指定，它將預設成LocalSystem。因為 LocalSystem 是高特殊權限的帳戶，執行於此安全性環境中的 WMI 提供者會根據提供者的程式碼品質和測試，將作業系統暴露於提高特殊權限的風險之中。

針對大部份的狀況，LocalSystem 是沒必要的，而 NetworkServiceHost 環境反而較為合適。這點非常正確，因為大部份的 WMI 提供者必須模擬 (ImpersonationLevel=1) 用戶端的安全性環境，以代表 WMI 用戶端來執行要求的操作。

表現形式

如果 WMI 提供者缺少裝載模型的定義，並且若以它是在LocalSystem 層級底下執行，它將無法適當地執行。

補救

預期的裝載模型必須變更，才能確保 WMI 提供者程式碼可透過模擬 WMI 用戶端，在用戶端安全性環境中執行操作。需要 LocalSystem 安全性環境的狀況非常少。不過，若 LocalSystem 是絕對的需求，可透過提供者 MOF 檔中的HostingModel=LocalSystemHost 陳述式，明確地指定裝載模型。

連結

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/provider_hosting_and_security.asp

磁碟區陰影複製服務

簡單描述

磁碟區陰影複製服務 (VSS) 是 Windows XP 和 Windows Server 2003 推出的新服務。它是一個有助於應用程式、存放子系統和存放管理應用程式 (包括備份應用程式) 間進行通訊的架構。此服務可定義、保持和運用存放資料的時間點複本。

表現形式

與 XP 備份應用程式的相容性

因為 XP 和程式庫並沒有和 Windows Vista 相容，因此多個介面已經變更。最低限度，應用程式將需要使用 VSS SDK 7.2 或是 Windows Vista Beta 2 所發行 Platform SDK 的標頭或程式庫來重新編譯。

與 2K3 SP 1 備份應用程式的相容性

2K3 SP1 的二進位檔可與 Windows Vista 相容。大部份的備份應用程式也需要負責處理收件匣寫入器、檔案與登錄虛擬化、WRP、以及在 %windir%system32 中使用永久連結 (Hard Link) 等變更，這些都讓 WS 2K3 SP1 所提供的備份應用程式很難正常運作。

編譯 Windows Vista 的備份應用程式

使用 Server 2003 所提供介面的應用程式可透過 VSS SDK 7.2 所提供的標頭和程式庫來編譯。若要使用 Windows Vista 特定的新介面，請使用 Platform SDK for Windows Vista 所包含的 VSS 標頭和程式庫來重新編譯。包含 VSS 元件的 SDK 第一個發行版本將隨附於 Beta 2 內。

Windows Vista 中的 VSS 寫入器

登錄寫入器

和先前的 spit 寫入器架構相比，登錄寫入器現在執行登錄的就地備份與還原。登錄寫入器並不會報告使用者登錄區。

COM+ RegDB 寫入器

它會備份 %systemroot%\registration 的內容。COM+ 需依賴所備份的登錄機碼，因此需要以登錄來備份與還原。

MS 搜尋寫入器

它會在建立之後從陰影複製中刪除搜尋索引。

MSDE 寫入器

這是 SQL 2000 和 SQL 2005 資料庫的預設寫入器。

WMI 寫入器

WMI VSS 寫入器可用來在備份操作中備份 WMI 特定狀態和資料。此資料包含了來自 WBEM 儲存機制 (WBEM Repository) 的檔案，並需要登錄備份。

幕後智慧型傳送服務 (Background Intelligent Transfer Service，BITS) 寫入器

它使用 FilesNotToBackup 登錄機碼來排除目錄 %allusersprofile%\application\data\microsoft\network\downloader內的檔案。

自動系統修復 (ASR) 寫入器

ASR 寫入器會將磁碟的組態儲存在系統上。

系統寫入器

在 Windows Vista 中，系統寫入器將使用下列公式來產生檔案清單：

1. 已經安裝的所有靜態檔案。辨識靜態檔案的方式是屬性 writeabletype = "static " 或元件資訊清單中的 writeabletype 為 ""。這將包含所有的 WRP 檔案。此外，可能有一些標示為靜態的檔案並不是 WRP。例如，遊戲為靜態但不是 WRP，如此系統管理員才能變更家長監護。
2. 包含所有資訊清單、選擇性元件和協力廠商 Win32 檔案的 WinSxS 資料夾。
3. 已安裝驅動程式的所有 PnP 檔案 (由 PnP 所擁有)。
4. 所有的使用者模式服務和非 PNP 驅動程式。
5. CryptSvc 所擁有的所有目錄。

%windir%\system32 中的檔案為指向 winsxs 目錄的永久連結。

還原應用程式需負責放入檔案和登錄，並設定 ACL 來配合系統快照。這也必須建立適當的永久連結。

Microsoft 最佳化寫入器

此寫入器會從快照中刪除某些檔案。檔案刪除可將快照維護階段中的 Copy On Write (COW) I/O 降至最低，並且這些檔案一般都是暫存檔，或是未構成使用者或系統狀態的檔案。

連結

http://search.msdn.microsoft.com/search/default.aspx?siteId=0&tab=0&query=Volume+Shadow+Copy+Service

http://search.msdn.microsoft.com/search/default.aspx?__VIEWSTATE=&query=Volume+Shadow+Copy+Service+Vista&siteid=0&tab=0

標準使用者分析器

「標準使用者分析器」("Standard User Analyzer"，前身為 "LUA Analyzer") 是一個可協助獨立軟體廠商 (ISV)、IT 專家和使用者診斷當作標準使用者執行之應用程式可能問題的工具。標準使用者分析器是以「LUA 預測器」技術為基礎，這是 Microsoft 應用程式檢查器 (Microsoft Application Verifier) 的一部份。

安裝必要條件和相容性

作業系統：Windows Vista、Windows XP 和 Windows Server 2003。

注意   目前，只有標準使用者分析器的 32 位元版本可供使用。

安裝必要條件：在啟動標準使用者分析器安裝之前，應先安裝應用程式檢查器。應用程式檢查器是 Microsoft 網站上的免費下載。

安裝

要安裝標準使用者分析器，請執行 SUAnalyzer.msi 檔。所有的標準使用者分析器檔案都安裝到 "Program Files\Standard User Analyzer" 資料夾內。

注意   標準使用者分析器需要您安裝最新的應用程式檢查器。

使用標準使用者分析器來診斷應用程式內的標準使用者相容性問題。

注意   標準使用者分析器應執行於 Windows Vista 電腦上，以妥善地找出應用程式的標準使用者相容性問題。下列程序就是設計來供 Windows Vista 電腦上的標準使用者執行的。

1. 按一下 [開始]，指向 [所有程式]，接著按兩下 [標準使用者分析器]。
2. 在 [應用程式資訊] 索引標籤的 [目標應用程式] 欄位中輸入目標應用程式執行檔的目錄位置，或使用 [瀏覽] 功能。
3. 在 [應用程式資訊] 索引標籤的 [參數] 欄位中輸入可用應用程式的參數。
4. 在 [應用程式資訊] 索引標籤中選取 [啟動提高權限](Launch Elevated) 核取方塊，接著按一下 [啟動] 按鈕。
5. 如果出現 SUAnalyzerSrv.exe 的使用者帳戶控制認證提示，請提供系統管理員的認證，然後按 [送出]。
6. 在目標應用程式的使用者帳戶控制認證提示中，提供系統管理員的認證，然後按 [送出]。

注意   SUAnalyzerSrv.exe 處理程序在執行此程序時可能需要提高權限。此處理程序是後端處理程序，負責管理需要系統管理員存取權杖 的工作，例如變更應用程式檢查器中的設定。

在測試過程中，標準使用者分析器將啟動應用程式、監視其動作、等候應用程式關閉。接著標準使用者分析器會為應用程式產生與解析一個記錄檔，這可能要花一些時間來完成。一旦記錄檔產生與剖析之後，即可按個別的索引標籤來檢視標準使用者分析器所找到的特定問題。

解譯標準使用者分析器測試資料

索引標籤	詳細資料
檔案	列出檔案系統存取問題。例如，應用程式嘗試寫入一般只有系統管理員可存取的檔案。
登錄	列出系統登錄存取問題。例如，應用程式嘗試寫入 HKLM 底下的登錄機碼，此位置通常只有系統管理員可以存取。
INI	列出 WriteProfile API 的問題。WriteProfile API 原本用於 16 位元的 Windows 中，但在一些現代的應用程式中仍然很受歡迎。例如，Windows XP 中的小算盤。如果檢視從「標準型」變成「工程型」，calc.exe 就會呼叫 WriteProfile API 來寫入 windows\win.ini，這是只有系統管理員的使用者可以寫的。
權杖	列出存取權杖的檢查問題。如果應用程式明確地在使用者的存取權杖中檢查 "Builtin\Administrators" 安全性識別元 (SID，該應用程式通常不適用於標準使用者。
特殊權限	列出特殊權限問題。例如，若應用程式明確地啟用 "SeDebugPrivilege"，它將不適用於標準使用者。
命名空間	列出應用程式在受限制的命名空間中建立系統物件時所產生的問題 (例如事件、記憶體對應)。有此錯誤的應用程式將不適用於標準使用者。
其他物件	除了檔案和登錄機碼外，列出存取物件的相關問題。

當您按了任何個別索引標籤中的問題之後，標準使用者分析器的左下角面板就會顯示記錄檔中的所有相關記錄。接著您可以按一下任何記錄，右下角面板將顯示該記錄的詳細資訊，包括格式化訊息、參數和堆疊追蹤。ISV 可使用堆疊追蹤資料在應用程式的原始程式碼中追蹤問題。

標準使用者分析器主功能表

檔案清單

開啟記錄檔案 (Open Log File)：讀取已儲存的紀錄檔案。

輸出記錄檔案 (Export Log File)：儲存現在的紀錄檔案。

檢視原始記錄檔：以原始的 xml 格式開啟目前的記錄檔。(警告：如果檔案很大，它將會花很長的時間開啟。)

離開 (Exit)：離開當前程式。

顯示清單

選擇您想要顯示什麼類型的訊息。通常只需要檢視「錯誤訊息」。

選擇清單

篩選干擾 (Filter Noise)：切換成顯示/隱藏「干擾」項目。

載入干擾篩選檔 (Load Noise Filter File)：載入干擾篩選檔。

輸出干擾篩選檔 (Export Noise Filter File)：儲存干擾篩選檔。

只顯示堆疊追蹤中具有應用程式名稱的記錄：這將會減少干擾；不過，因為標準使用者分析器只會擷取前 32 個堆疊框架；如果某個呼叫堆疊比 32 個框架來得深，此選項可能會篩選掉真正的問題。

記錄 (Logging)：記錄選項。建議您不要勾選 [記錄資訊] 核取方塊，以便讓記錄檔不至於太大。

說明引擎支援

Microsoft 致力於在 Windows 平台中提供說明及支援技術，並將繼續為軟體開發人員研究新的解決方案。本文件將闡明 Windows Vista 對於四個 Microsoft 說明技術的支援：Windows Help、HTML Help 1.x、說明及支援中心、協助平台 (Assistance Platform) 用戶端。

Windows Help (WinHelp.exe & WinHlp32.exe)

Windows Help (WinHelp.exe & WinHlp32.exe) 是從 Windows 3.1 的 Windows 即開始包含的原始說明引擎。系統需要有 Windows Help，才能顯示副檔名為 .HLP 的說明檔。

Windows Vista 已經取代了 Windows Help。Beta 2 並不支援 Windows Help，而一些 Windows Help 程式碼也從發行版本中移除。要在 Windows Vista 中檢視副檔名為 .HLP 的說明檔，您需要從 Microsoft 下載中心下載與安裝 WinHlp32.exe。此下載並不提供於 Beta 2 中。

Microsoft 強烈地建議軟體開發人員不要繼續在 Windows Vista 中使用 Windows Help 應用程式。仍提供依賴 .HLP 檔之程式的軟體開發人員最好將其說明經驗轉換成替代的說明檔案格式，例如 CHM、HTML 或 XML。您也需要將您的呼叫從 WinHelp() API 變更為新的內容來源。多個協力廠商工具可提供以協助作者將內容從一種格式轉換成另一種。

HTML Help 1.x (HH.exe)

Microsoft HTML Help 1.x (HH.exe) 是從 Windows 98 的 Windows 發行版本即開始包含的說明系統。系統需要有 HTML Help，才能顯示副檔名為 .CHM 的編譯說明檔。

HTML Help 將隨附於 Windows Vista 中。不過，只會對引擎進行關鍵更新。在 Windows Vista 或未來的 Windows 發行版本中，HTML Help 引擎將不會加入新的功能或功能改進。

如需 HTML Help 功能以及為 HTML Help 製作檔案的指導之詳細資訊，請參閱 Help 1.4 SDK (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/vsconhh1start.asp) 網站。

說明及支援中心 (HelpCtr.exe)

說明及支援中心 (HelpCtr.exe) 是專為 Windows XP 和 Windows Server 2003 設計的說明應用程式。說明及支援中心可顯示副檔名為 .CHM 的編譯說明檔。

說明及支援中心並未包含於 Windows Vista 之中，也不支援其功能。副檔名為 .CHM 的編譯說明檔只能在 HTML Help 應用程式中顯示，如上所述。

協助平台用戶端 (HelpPane.exe)

協助平台用戶端 (HelpPane.exe) 是專為 Windows Vista 設計的全新說明引擎。它並未與任何先前的 Windows 版本相容。系統需要有協助平台用戶端，才能顯示副檔名為 .H1S 的說明檔。

在 Windows Vista 中，協助平台用戶端可由 OEM、系統建造商和企業客戶在授權合約下自訂，但不能由協力廠商程式所使用。如需自訂協助平台用戶端的詳細資訊，請參閱 Windows SDK。

請參照

互通性與遷移 (英文)

回到頁首