共用方式為


Windows 機密處理相容性缺失

Raymond Chen

之前有一個 為 Windows® 3.1 撰寫的程式,它會藉由尋找 [控制台] 視窗、存取 [檔案] 功能表,並且搜尋稱為「印表機」的項目來開啟 [印表機控制台]。在 Windows 95 中,[控制台] 的 [檔案] 下並沒有 [印表機] 選項。因此,在 Windows 95 上執行時,此程式會張貼不需要的命令訊息至 [控制台]。為解決這個問題,Windows 95 建立了虛構的 [控制台] 視窗讓程式尋找。當程式張貼訊息至虛構的視窗時,[印表機] 資料夾就會開啟。

有些人認為,Windows 3.1 應該已偵測到該程式對 [控制台] 做出不當假設並顯示警告。那麼程式的作者就會看見警告,並且在發行產品之前修正問題。但偵測程式碼區塊的意圖需要人工智慧領域的大膽分析。基本上,Windows 3.1 必須偵測到程式正在對 [印表機] 進行 Strcmp、分析此特殊 Strcmp,然後判定是否有害。但這種方法僅適用於前述的「印表機」案例。您希望系統執行多少相容性檢查?又會發生多少次誤報呢?

另一項爭議為,Windows 95 應回應此不當假設並顯示警告對話方塊,指出「程式 XYZ 正在執行不當操作」。但為了讓 [控制台] 得知張貼垃圾訊息的是哪個程式,則必須深入偵測視窗管理員。這樣做會在兩個元件 ([控制台] 和視窗管理員) 之間建立危險的連結。同樣地,這種方法只適用一個案例。您希望視窗管理員與系統中的其他所有元件短暫連接嗎?

提供一般訊息而不指名特定應用程式會較為容易。但是這也不是理想的解決方法。虛構的錯誤訊息與沒有任何錯誤訊息一樣沒有好處。除此之外,使用者很可能會略過此對話方塊,因為它根本沒有提供特定的建議動作。使用者可能會覺得這個對話方塊令人厭煩。這點相當重要。任何錯誤訊息都應該提供因應動作。如果使用者知道如何回應警告,則對話方塊就會變得相當實用。

  

另一個問題是,對話方塊會因為對話方塊迴圈的關係建立重複進入點。這是一項技術問題。非預期的重複進入動作是 UI 程式設計中主要的錯誤來源。此外,[控制台] 本身可能會處於強制回應狀態,而顯示對話方塊會造成強制回應結構瓦解。

對話方塊還會造成新的當地語系化負擔。如果要為所有相容性缺失都寫出一個對話方塊,那麼整個系統內將充斥數以百計的對話方塊。每個對話方塊都會需要翻譯成 33 種語言,因為 Windows 提供這 33 種語言的完整翻譯。

最後,請考慮競爭者的產品產生其中一個對話方塊時的反應。他們可能會說「Microsoft 將自己作業系統發生問題的責任推給其他人」,或是「Microsoft 故意讓我們的程式顯得錯誤百出」。這可不是誇張的說法。之前已經有一些公司向國會抱怨 Microsoft 惡意針對其產品,使這些產品無法正常運作。不過進一步調查發現,是這些公司的程式有問題。坦白說,最好是幫他們修復錯誤,勝過冗長的國會調查。

因此,目前的 Windows 版本只會在程式完全無法與 Windows 相容以致於無法執行,或只能在相當有限的情況下執行時,才會顯示警告對話方塊。而即使在這種情況下,Microsoft 仍會嘗試配合廠商,共同確保不讓客戶陷於困境、孤立無援。畢竟人們購買程式的目的是想在作業系統上執行這些程式。如果程式無法執行,沒有人會在乎是誰的錯,因為他們只想把工作完成。

Raymond Chen 的網站 The Old New Thing (英文),專門討論 Windows 歷程記錄和 Win32 程式設計。他正在寫一本書,書名恰好也是 The Old New Thing (Addison-Wesley, 2007)。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利;未經允許,嚴禁部分或全部複製.