Windows 機密文件：為什麼不能我們都只是一起合作？

設計互通性文件的危險之一，就是您可能會發現沒有人想要實作您的規格。

Raymond Chen

幾年前，我和午餐從 Microsoft 內部的另一個專案組的幾個人。這不是計畫的事。這是只和來訪的同事一起吃午飯的自發決定從演化而來的東西。

這些類型的非正式午餐聚會都很有趣。我去瞭解其他人和他們正在的專案。如果我是幸運的我可以收集更多的有幾個故事。

坐在桌子是微軟開發的互通性文檔被控工業集團的代表之一東西-或-其他。實際文檔的重點並不是對我洞察到行業組織試圖發展一個互通性的文檔的陰謀詭計一樣有趣。

他表示，小組成員已經分成兩派。第一個派系的成員想要設計一種互通性文檔，預計所有可能請求和發明了架構來形容他們。 "如果一個用戶端想要微動 frobulator 時流量解調嗎？我們需要有一種方法指定調製例外。"

在第二次派人想要設計一種互通性文檔，所涵蓋的重要的情況。閱讀文檔的人可以實現任何方案與合理的努力。他們將可以讓它儘快進行之前所有的廠商都是煩躁和跑到前頭用他們自己的自訂實現，它們都不會與任何其他相容。

第二個派別認為如果互通性的文檔不能覆蓋所有的可能性將是確定。只要它不排除在將來添加這些排序的功能支援的能力，這是有效的。我的午餐表同事屬於第二個派別。

回應此不可調和的衝突的哲學，工業集團同意開發兩個文檔。第一所涵蓋的重要方案的基本檔。這滿足了第二個派別。也是一種擴展的文檔，擴大基礎檔的功能。這滿足第一個派別。

我懷疑這終止大部分，如果不是所有的參數超過什麼應該去到互通性的文檔。相反，工業組成員爭論是否某一特定功能是基本的特徵或擴展的功能。

第一次派自然會辯稱任何新的功能是基本的功能。第二個派別自然會辯稱任何新的功能是一個擴展的功能。他們可以很可能解決這通過建立在第二次派人"基本特徵分組"，使他們對什麼計為基本特徵的最後仲裁員。

我的午餐表同事是惱火。他說，在擴展的文檔已經成為如此複雜從用戶端請求開始類似于小小的電腦程式。執行這些常式，以確定該請求所需的伺服器。

我半開玩笑地建議他建議向擴展的文檔中添加一個簡單的條款："如果收到請求資料包，其中評價永遠不會產生結果（導致拒絕服務如果伺服器試圖執行它），伺服器必須拒絕該請求，出現錯誤 EWOULDHANG。"換句話說，他會欺騙工業集團要求伺服器停機問題的解決。

我的午餐表同事笑著這個想法。 "我所以忍不住要嘗試的"他說。我不知道是否他真的做了，但事實證明，這是一個無關緊要。

最終批准了該基地的文檔。供應商開始實施的規範。工作持續了數年之後的擴展文檔。最終顯然從淺與供應商他們都不感興趣的實施基礎檔之外的東西。

後發現了這一點，工業集團正式暫停操作。他們要顯示其多年來是工作的大多是工作的完整的文檔，沒有人關心。工業集團失去了客戶的景象。他們工作了多年來設計一個絕不會推行的規範。

Raymond Chen

鍾泰陳 ' s Web 網站、舊的新事物和相類似的標題書 (艾迪生－衛斯理，2007年）處理 Windows 歷史、 Win32 程式設計和無意汽車盜竊。