Windows XP 已經過時但佔有率仍很高，這是否給桌面軟體開發者帶來了一些麻煩？

11-16

桌面軟體開發界有沒有像 web 前端開發界厭惡 IE6 一樣厭惡 Windows XP 的情況？

被 @王成和 @梁海兩位邀請了，怎能不答？

說實話，我幾乎從來都不是一個真正意義上的桌面開發者，因為我負責的東西都是躲在後台的服務，接觸界面不算多。所以只能借自己不算豐富的經驗，大概說一說。

IE 6 是個很大的麻煩，但正版的 Windows XP 並沒有這個問題，因為 IE 的升級早已是默認選項。有問題的那些關閉了自動更新的盜版 XP。可是，站在微軟的角度上看，盜版 XP 並不在支持之列。所以我對此也沒什麼經驗，就不班門弄斧了。

庫的問題，@余天升同學已經說得很全面了。雖然微軟的向後兼容一直都做得很好，但用戶總免不了被要求下載一些額外的函數庫，這怎麼也不算一個好的用戶體驗。

如果排除庫的問題，而且將範圍限定在正版系統開發，那麼我要說：桌面應用開發者一直都有麻煩，不過也許沒有很多人想像得那麼嚴重。向上升級一般都不會有多少問題（好吧，除了那個 UAC 彈出對話框，在 Vista 里那簡直是一場災難。幸虧 Windows 7 改進了不少）。而對那些試圖將 Windows 7 作為主要開發目標，又要保證應用能在 XP 上運行的開發者來說，大部分精力可能要放在對老舊協議和庫的支持上，比如：

64 位開發。事實上 XP 是沒有 64 位系統的。真的。我知道有人會反駁說微軟網站上明明就有，但告訴你一個公開的秘密：64 位 Windows XP 和 Windows Server 2003 SP1 的系統版本號是一樣的。如果你想把你的 64 位程序向下移植，記得要在 Windows Server 2003 上測試。這裡的問題在於，家用版系統的很多默認組件在伺服器版或者默認禁用，或者乾脆就沒有，特別是多媒體支持。小心移植完畢卻發現不能運行，那可就麻煩了。
空格問題。相對 XP 而言，Windows Vista 和 Windows 7 的目錄路徑已經規整很多，至少能保證所有的系統路徑都沒有空格。而 XP 上可不是如此，比如大名鼎鼎的 C:Users and Documents，而且這倒霉路徑在不同語言系統上總是隨著本地語言命名。如果是習慣了 Windows 7 開發的開發者，一定要利用 Shell32 的函數庫而不是自己處理路徑名，免得遇上無數詭異的錯誤。
手寫支持。作為前任手寫組件的維護者，我得聲明：Vista 時代的手寫支持比 XP 時代實在是改進了太多。很多功能都有添加和修正。相比之下 XP 的手寫支持不僅 Windows 和 Office 各做各家，而且質量也很初級。如果你的程序試圖提供基於 Tablet PC Ink Support 的手寫支持，向下移植的時候千萬小心。
Active Directory 服務。作為一個相對老舊的系統，XP 只支持一些老的協議。比如 XP 只能支持到 Active Directory 中的 Windows 2003 functional level。如果你的程序需要伺服器端使用 AD 進行通信，那麼別忘了正確設置伺服器端的 functional level。
驅動開發。XP 不支持 Vista 開始引入的 WDDM，而 Windows 7 支持。對驅動程序員來說，你的驅動可能得多改改才能運行。
BitLocker。XP 不支持這個技術。硬碟驅動和安全開發者們可以放棄了。
[本句錯誤，多謝 @carpenter 指出，請勿混淆] DEP （Data Execution Protection）。同樣，XP 不支持這個技術。如果你的程序必須運行在 XP 上，就得加倍小心檢查你的程序。一旦出現緩衝區溢出，在 XP 上沒人能保護你的用戶。
Address Randomize。XP 不支持這個。這意味著程序一旦出現緩衝區溢出，那麼被攻擊的可能性幾乎達到100％。安全分析師們得小心了，記得得找第三方的支持。
MMC。這個著名的 Windows 系統管理插件架構在 Windows Vista 推出時幾乎被全部重寫，用來支持 C# 的插件。如果你的插件是 C# 寫的，做好準備重寫吧。
自動安裝支持。也是個被完全重寫的東西。IT 自動化開發者們，別太相信你們手上的 wim 鏡像和 imagex.exe，還有 XML 格式的自動安裝腳本。至少在 XP 上它們都會不翼而飛。
基於 HTTP 協議的安全隧道。Vista 和 Windows 7 支持 SSTP，允許通過 HTTPS 通道實現安全通信。而很可惜，XP 還是沒有這個支持。所以安全程序員們最好考慮將舊式的 PPTP 或 L2TP 放進支持之列。如果項目要求必須使用 HTTP 協議，那麼還是用 OpenVPN 作為代替比較靠譜。

本來就想隨便寫寫，沒想到居然列出了這麼多。大家隨便看看吧。

最後推薦一個不錯的列表，來自第三方：
http://www.freetechexams.com/microsoft-windows/windows-7/comparison-between-windows-xp-windows-vista-and-windows-710.html

有啊，而且非常非常討厭，但是又不得不考慮這個問題啊。

比如依賴庫的問題，用戶根本不知道依賴庫是什麼啊！！！於是整天就有不同的用戶抱怨怎麼又沒有什麼什麼dll了，這個到底是什麼東西啊！！！

2001年發布的Windows XP自帶的是vc6的運行庫，並且沒有.NET運行環境，發布的程序就需要考慮到用戶機子上沒有運行庫怎麼辦。雖然一般的做法的是，打包成一個安裝包，安裝的時候檢測，但是，Windows的用戶似乎都比較反感安裝程序，覺得安裝了以後會讓自己的電腦變慢，如果是做一些在學校裡面使用的小型軟體，或者是要在客戶的電腦上使用的軟體，增加安裝這個步驟也是會非常不方便也非常不合適的。

另外，製作安裝包，把依賴庫放進去，就把安裝包變得很大很大了，C++的庫還好，幾M的空間就可以了，.NET 3.5完整離線安裝包將近200M，打進去的話，用戶一定會高度質疑你的內容，而且也不方便下載。用vc6的庫行不行？重大安全隱患不能用啊。

造成的結果就是，微軟在推使用.NET框架開發，並且使用C#+WinForm或者WPF構建界面是一個多快好省的事情。但是如果為了讓程序兼容更多的用戶，我們卻不得不使用C++來進行開發，能夠使用的圖形框架就變成了MFC，開發和測試的難度都增加了。如果使用.NET的話，那麼意味著，可能不得不放棄部分的XP用戶，因為他們不會或者不願意在自己的電腦上安裝所謂的「會把電腦拖慢的庫」。

另外就是API的問題，因為現在開發使用的機器都是Windows 7，為了做XP的兼容性測試必須再拿到XP下測試一次，有時候會因為用了Vista開始特有的API導致失敗，然後就發現為了實現一個API的功能我們是要做許許多多額外的工作，於是又開始痛恨這個還沒有消失的XP。不過比較幸運的一點，MSDN對這些API的描述都比較全面。

IE 6的問題在於現在多了更多更好的選擇，卻無奈的現實要求很多應用必須支持IE6。

但是XP在這個問題上沒那麼嚴重：
1. Win系存在比XP更好的選擇，但是MS家的技術向後兼容性卻很好。例如4年前.Net 3.5預覽版依然可以運作在XP之上。實際上Windows API，比起Web相關介面，相對穩定得多，也成熟得多。
2. 非Win系存在比XP更好的選擇，但是這個鴻溝不是XP造成的。
3. 桌面前端的發展對桌面技術的依賴沒有Web前端技術那麼大。

我一直覺得大家都不兼容之後，越來越不受歡迎的應該是xp才對啊，xp用戶應該被迫換電腦啊。怎麼反過來了呢，變成不受歡迎的是開發者了呢，這是為什麼呢，搞不懂

不會啊。。。。相反，xp應該是開發者最喜歡的一個操作系統版本。

因為xp存在很多年，在這個系統上面被一些人研究出很多比較離奇的技術。比如各種hook和各種dll注入等等吧。

但是在新的系統很多技術是失效的。

後來的操作系統的 api 存在一些變動，有的 api 被去掉了，有的 api 是新增的，但對於xp來說，它已經是足夠成熟的系統，所以這樣的api是有，但不會有很劇烈的影響的。對 xp 的影響沒那麼大。

個人覺得 xp 是最合適做實驗用的操作系統。當然，你也得必須考慮新操作系統。

這種操作系統的差異，有時候會引入很多你預想不到的兼容性問題，所以必須要在真正的環境上測試，才能確保正確。

舉個例子，比如 LoadBitmap 這個函數，在 xp，win7 上它都能返回實際 bpp 的點陣圖。但是在 win server 20XX 上，因為那個界面的關係吧，它就會返回 16 bpp 的點陣圖。結果這導致我的程序後續發生了內存訪問越界，導致程序不聲不響的掛掉。後來我改成 LoadImage 解決掉了這個問題。

還有就是從 win7 開始 ado 中的 ——ConnectionPtr 的 guid 被微軟給默默的變了！結果這造成一個大麻煩，產生的程序依賴於編譯器所在的操作系統，這個程序依賴於操作系統。這個問題產生的後果是：即在 win7 上編譯的程序，無法在 win7 以前的操作系統上正確運行。

微軟沒有預料到會有很多人把他們的過去的源代碼，放在 win7 上編譯（程序員升級了自己的操作系統，這非常正常），然後又把這編譯出來的東西，拿到舊操作系統上去運行（客戶的操作系統還沒有升級，這也太正常）。而事實上，這種情況非常的多，微軟也沒有想出一個非常好的好點子來解決這個問題。所以你只能自己注意了。

這個問題類似於，你修改了二進位配置文件中的一個結構的定義，而你又沒有預留兼容它的空間，導致你升級後所有過去的這種配置文件都會失效。

還有非常多的相對古老一些的軟體，因為停止開發的關係。他們幾乎只能裝在 xp 電腦上。這也是xp會有市場的原因。

哦，對了，我之所以說影響不大，是因為我是以c++為主來開發。其實本質上就是windows api 的變化和影響不大。這個相對的比較穩定一些。

而。net程序員來說， xp 是最後一代沒有集成。net 的操作系統。~。不過。net這個東西，我始終搞不懂為什麼它對版本要求的這麼嚴格，a說我要你裝。net3.5，b程序非說我要net2.0。你就不能讓我統一裝一個最新版的一次性了事嗎。

這並不算麻不麻煩的事了，用戶不會因為覺得讓開發人員多工序了而換系統，這也是為什麼那麼多開發者前赴後繼的繼續為哪怕最後一小撮用戶而熬夜搞兼容的動力了。那一句，白天永遠不懂夜的黑...

這個問題可以有多個分析的角度。比如說，如果你懶得升級操作系統，你就連 app 也用舊版好了。我開發出新版的 app，一個用 XP 的用戶也懶得升級。新版的開發無需考慮 XP。

用 Ars Technica 的一個用戶評論來說：Snow Leopard does not suddenly make all PPC Mac not work.

問題是從新人視角看的。

從有經驗的開發者角度看，問題應該是：已經熟練掌握了用戶量眾多的XP下的桌面開發技術，在新版Vista/Win7/8/10下運行是否遇到各種坑？

本身微軟操作系統就是向前兼容的，做一個商業的桌面應用首先要保證程序在XP下的運行。然後再權衡新特性的應用。開發人員不應因為自己的硬體強大，系統新，就忽視對舊版本系統的兼容。在其他領域，比如我們的設計師團隊，都會專門配一台14寸大肚子顯示器。用於看設計圖在低配顯示器下的效果，防止圖做太大（設計師都用大屏幕）、色彩適應性太小（CRT色彩差，有些對比色顯示不出來）等。

桌面開發的技術革新遠遠沒有瀏覽器技術那麼強烈。瀏覽器支持的Html早期是作為文檔格式發明的，現在要做交互應用、多媒體、精細縮放排版等，可謂翻天覆地的變化。在桌面端，升級問題則相對較小，通常都可以通過兼容性測試和修訂程序解決。

微軟不惜巨金免費讓XP不管正版盜版用戶升級WIN10，已經很說明問題了，XP拖了大後腿

迄今覺得所謂的系統升級、硬體升級全都是你們這些IT精英逼出來的；總體上說，沒有帶來體驗上的改進。

從用戶的角度，我需要的是快、穩定；而升級帶來的，只是「好看」，以及變本加厲的硬體需求。

硬體發展了這麼多代，軟體發展了這麼多代，但是打開一個word還是要等半分鐘，不知道對於普通的消費者（普通配置，別說什麼頂級配置；正常使用一段時間的電腦，別說什麼新電腦）而言，什麼時候才能用上真正疾步如飛的個人電腦。

看到這個問題想到我爸，家裡的電腦至今XP就是不換系統，但他年輕時候是個程序員啊，好想問這是什麼心態ˊ_&>ˋ

雖然很多因為工作電腦被迫使用XP，但不得不說XP算是WINDOWS的一個經典，從性能、穩定性方面都不錯，所以才會有這麼多的用戶。

xp我也就忍了，前幾天去一個客戶那裡，有兩台me，三台2000，讓我們一定要兼容，我艹的。

話說不少小朋友不知道啥是me吧

公司開發的辦公系統，.net，C/S+B/S。因為大多數PC都是XP，所以只能用.net4.0（打SP3後最多支持到4.0）。
B/S系統需要最低IE8支持，又將全公司PC的IE升級。
XP下部分界面效果（FORM、WPF）沒有WIN7下好看。
做一些後台操作時不用擔心許可權問題。

這個對於.net最為苦逼，因為xp最多支持net4而4.5隻能是win7。導致於若想兼顧xp就得用老的net。

而且在sdk上，xp和後面又有所不同。這又得苦逼一群win開發者。

有，但是沒有ie6那麼嚴重。
如果一個應用一開始就確定要用在xp上，幾乎不會有更多的工作要做。
至於dll之類的問題，對於一個合格的程序員，不是必須要關心的嗎?

winxp根本沒有過時好不好，比如我只有一台2G內存的機子，要用word，excel等office軟體。必然要裝winxp啊。win7，我也用過，但我感覺這個主要是看在他兼容新遊戲所以採用的。如果只是辦公，沒有理由淘汰xp。

像我用CC++開發支持並不困難，只是一些比較高級的api不能使用，比如鎖只能用臨界區。xp的主要問題在於運行xp的電腦大部分已經非常老了，對客戶端的運行效率要求比較高

windows一直在變"臉",API一直都在.

其實多種瀏覽器不兼容前端html代碼才是蛋疼前端設計蛋疼，測試蛋疼