SDK和MFC
SDK —Software Development Kit 軟件開發包
MFC —MicroSoft Foundations Classes 微軟基礎類
API —Application Programming Interface 應用程序接口
SDK 是 Windoews 的API 集合
MFC 是 Windoews API C++ 封裝
SDK是Software Development Kit的縮寫，“軟件開發工具包”：輔助開發某一類軟件的相關文檔、範例和工具的集合都可以叫做“SDK”。具體到我們這個系列教程，我們後面只討論廣義 SDK 的一個子集——即開發 Windows 平臺下的應用程序所使用的 SDK。
其實上面只是說了一個 SDK 大概的概念而已，理解什麼是 SDK，爲了解釋什麼是 SDK 我們不得不引入 API、動態鏈接庫、導入庫等等概念。
首先要接觸的是“API”，也就是 Application Programming Interface，其實就是操作系統留給應用程序的一個調用接口，應用程序通過調用操作系統的 API 而使操作系統去執行應用程序的命令（動作）。其實早在 DOS 時代就有 API 的概念，只不過那個時候的 API 是以中斷調用的形式（INT 21h）提供的，在 DOS 下跑的應用程序都直接或間接的通過中斷調用來使用操作系統功能，比如將 AH 置爲 30h 後調用 INT 21h 就可以得到 DOS 操作系統的版本號。而在 Windows 中，系統 API 是以函數調用的方式提供的。同樣是取得操作系統的版本號，在 Windows 中你所要做的就是調用 GetVersionEx() 函數。可以這麼說，DOS API 是“Thinking in 彙編語言”的，而 Windows API 則是“Thinking in 高級語言”的。DOS API 是系統程序的一部分，他們與系統一同被載入內存並且可以通過中斷矢量表找到他們的入口，那麼 Windows API 呢？要說明白這個問題就不得不引入我們下面要介紹得這個概念——DLL。
DLL（又是一個縮寫，感覺 IT 這個行業裏三字頭縮寫特別多），即 Dynamic Link Library（動態鏈接庫）。我們經常會看到一些 .dll 格式的文件，這些文件就是動態鏈接庫文件，其實也是一種可執行文件格式。跟 .exe 文件不同的是，.dll 文件不能直接執行，他們通常由 .exe 在執行時裝入，內含有一些資源以及可執行代碼等。其實 Windows 的三大模塊就是以 DLL 的形式提供的（Kernel32.dll，User32.dll，GDI32.dll），裏面就含有了 API 函數的執行代碼。爲了使用 DLL 中的 API 函數，我們必須要有 API 函數的聲明（.H）和其導入庫（.LIB），函數的原型聲明不難理解，那麼導入庫又是做什麼用的呢？我們暫時先這樣理解：導入庫是爲了在 DLL 中找到 API 的入口點而使用的。
所以，爲了使用 API 函數，我們就要有跟 API 所對應的 .H 和 .LIB 文件，而 SDK 正是提供了一整套開發 Windows 應用程序所需的相關文件、範例和工具的“工具包”。到此爲止，我們才真正的解釋清楚了 SDK 的含義。
由於 SDK 包含了使用 API 的必需資料，所以人們也常把僅使用 API 來編寫 Windows 應用程序的開發方式叫做“SDK 編程”。而 API 和 SDK 是開發 Windows 應用程序所必需的東西，所以其它編程框架和類庫都是建立在它們之上的，比如 VCL 和 MFC，雖然他們比起“SDK 編程”來有着更高的抽象度，但這絲毫不妨礙它們在需要的時候隨時直接調用 API 函數。
MFC AppWizard(exe) MFC（Microsoft Foundation Class，微軟基礎類庫）是微軟爲了簡化程序員的開發工作所開發的一套C++類的集合，C環境是面向過程的不支持MFC，MFC只封裝在C++裏，MFC無法在C環境中使用，是一套面向對象的函數庫，MFC採用面向對象設計，將大部分的Windows API封裝到C++類中，以類的方式提供給用戶使用。在MFC中，類的命名都以字母“C”開頭，利用這些類，可以有效地幫助程序員完成Windows應用程序的開發。MFC是建立基於MICROSOFT FUNDATION CLASS的工程；一般的MFC的應用程序，可以生成單文檔、多文檔或對話框程序框架；MFC其實是一個框架，裏面包含了200多個類，MFC比較複雜，MFC框架把基本的功能都實現了，你只是需要把你特殊的功能加到MFC裏面，比如你想建一個windows窗口，MFC APPWIZARD下，MFC中自包含了CWnd串口類，但是win32 application，就是要你自己寫一個窗口類，才能用。
對於一個單文檔應用程序（即我們在創建工程時第二步所選的Single document），都有一個CMainFrame類，和一個以“C+工程名+App”爲名字的類、一個以“C+工程名+Doc”爲名字的類、一個以“C+工程名+View”爲名字的類。作爲讀者，在剛接觸MFC的程序時，一定要逐步熟悉MFC AppWizard所生成的這幾個類，以及類中的代碼。這樣才能在閱讀程序時，知道哪些類、哪些代碼是嚮導生成的，哪些類、哪些代碼是我們自己編寫的。
Win32 Console Application WIN32的控制檯應用程序，類似DOS窗口的那個效果。console程序以main()爲入口，不能使用win32 API函數；
API 和 SDK 是開發 Windows 應用程序所必需的東西，所以其它編程框架和類庫都是建立在它們之上的，比如 VCL 和 MFC，雖然他們比起“SDK 編程”來有着更高的抽象度，但這絲毫不妨礙它們在需要的時候隨時直接調用 API 函數。
VC是以C++爲語言基礎的開發工具，而C++是C語言的擴充，故要學好VC最好是先學好C和C++。
儘管MFC比SDK方便，但要深入VC，直接去學MFC卻是不明智的選擇。只有在熟悉了MFC的運行機制的情況下，纔有可能深入下去。所以學VC最好是先學用SDK編寫程序，在此期間掌握Windows操作系統的工作原理和各API函數的應用，然後再深入MFC。
用VC6的IDE(集成開發環境)來編寫SDK程序，啓動VC6後選擇File菜單的New…選項，在出現的New對話框的Projects標籤內選擇Win32 Application，然後在Projects Name指定項目的名字，在Location中指定路徑後按OK按鈕，在出現的對話框中，如果你想要用C語言來寫程序可以選擇An emtpy project，如果你想創建一個帶有WinMain入口函數和普通參數的設定的項目，可以選擇A simple Win32 application，如果您想創建一個簡單典型“Hello World!”Win32SDK application應用程序，可以選擇A typical “Hello World!” application。確定項目類型後按Finish完成。
在VC6環境下，你依然可以使用資源編輯器和ClassWizar等工具完成程序的編寫。用SDK編寫程序關鍵是能夠了解程序的來龍去脈。如果不瞭解，當然那樣效率會很低，不比VB、PB那麼快，任何東西都是有得有失，如你熟悉用SDK寫程序後，對MFC會比較容易上手的，關鍵要熟悉C++的三大特性。
VC: Win32 Application和Win32 Console Application、MFC APPWIZARD區別
見文章：http://apps.hi.baidu.com/share/detail/2037585
mfc既然封裝了api，提供了基本框架，只要填寫自己的關鍵代碼就行了，爲啥還需要要用win32的api來編程
見：http://www.cxzz.net/vc/bcahdcabc.html 論述的很經典
MFC AppWizard VC++深入詳解
見：http://zilan1986.blog.163.com/blog/static/8278126200862010332684/
MFC與SDK
見：http://yujianhuabc.blog.163.com/blog/static/1174183120078231122713/?fromdm&fromSearch&isFromSearchEngine=yes
Windows SDK
見：http://roz1987.blog.163.com/blog/static/11639295820094177551648/?fromdm&fromSearch&isFromSearchEngine=yes
SDK見：http://litaohill.blog.163.com/blog/static/939693622010012112157256/?fromdm&fromSearch&isFromSearchEngine=yes
SDK, API 和 MFC 的區別
http://www.oneie.com/viewthread.php?tid=37478
用VC編寫Windows程序有兩種：1. Windows c方式(SDK)，2. C++方式:即對SDK函數進行包裝，如VC的MFC,BCB的OWL等。SDK編程就是直接調用Windows的API進行編程，平時人們常說”用 SDK寫程序”就是指用Windows的API函數來寫程序，API由上千個API函數組成(Win95的API有兩千多個)。而MFC是API的封閉，結合面向對象程序設計的繼承性和多態性組成一個個的”類”，共由一百多個類組成。儘管MFC比SDK方便，但要深入VC，直接去學MFC卻是不明智的選擇。只有在熟悉了MFC的運行機制的情況下，纔有可能深入下去。所以學VC最好是先學用SDK編寫程序，在此期間掌握Windows操作系統的工作原理和各API函數的應用，然後再深入MFC。
MFC,微軟基礎類(Microsoft Foundation Classes)，同VCL類似，是一種Application Framework，隨微軟Visual C++ 開發工具發佈。該類庫提供一組通用的可重用的類庫供開發人員使用。大部分類均從CObject 直接或間接派生，只有少部分類例外。MFC 應用程序的總體結構通常由開發人員從MFC類派生的幾個類和一個CWinApp類對象（應用程序對象）組成。MFC 提供了MFC AppWizard 自動生成框架。
MFC不只是一個功能單純的界面開發系統,它提供的類絕大部分用來進行界面開發,關聯一個窗口的動作,但它提供的類中有好多類不與一個窗口關聯,即類的作用不是一個界面類,不實現對一個窗口對象的控制(如創建,銷燬),而是一些在WinDOS(用MFC編寫的程序絕大部分都在WinDOS中運行)中實現內部處理的類。
而SDK呢？泛泛的說：輔助開發某一類軟件的相關文檔、範例和工具的集合都可以叫做“SDK”。這裏主要討論一下Windows SDK，微軟每推出一個重要的windows版本，一般都會同時推出一個SDK（Software Development Kit）。SDK包含了開發該windows版本所需的windows函數和常數定義、API函數說明文檔、相關工具和示例。SDK一般使用C語言，但不包括編譯器。高版本VC++包括了SDK所有的頭文件、幫助、示例和工具，不需要再安裝SDK，低版本如VC++5.0則需要安裝SDK。
兩者的區別與聯繫：SDK是基於C語言的，而MFC是基於C++的，這是最根本的區別。MFC主要封裝的是界面、文件、WinInet和線程等函數。MFC除了封裝API，最重要的是它的體系結構，它所使用的Doc/View結構是SDK中沒有的，這種架構是比較特殊的。儘管Doc/View結構不是微軟的發明，但它是MFC的特色。微軟開發Windows時使用的是C語言，所以最初設計SDK時並沒有考慮C++。
Sdk比較低層用C開發！能控制細節！SDK是採用較一般的C語言，但很靈活，是面向過程編程。
MFC是微軟的基本類庫，對很多東西已經進行了封裝，使用簡單、方便。Mfc 把Sdk的功能封裝到了類，是編程大大簡化！用C++開發！一般編寫簡單的程序，使用MFC應該能達到要求。但如果編寫功能強大的程序使用SDK較多，尤其是底層的開發。
Wndows 編程兩種方式：
1.SDK編程:用C語言直接調用Windows API函數.這類API函數有上千個，數目太大，對編程不利;採用一般的C語言，比較低層，能控制細節，很靈活。
2.MFC編程:用類將上述API 封裝起來,用C++來調用.一般只需20 多個windows 類和另外20 多個通用的非windows 類就可”幹活”了.能提高編程效率，但失去了SDK的靈活性。MFC只封裝在C++裏，在C環境中無法使用。C是面向對象的不支持MFC。一般編寫比較簡單的程序，MFC基本能滿足要求，但編寫功能強大的程序使用SDK較多，尤其是底層開發。
SDK主要通過調用raw api（原始api）的方法編程
MFC主要使用Micro Foundamation Classes微軟基礎類庫編寫程序
SDK———《windows程序設計》
MFC———《深入淺出MFC》
打個比方。想使用電腦，那你買了品牌機後操作它就好比你使用MFC，如果你是買的散件自己組裝的電腦後在使用它就包比你使的SDK。
API(Application Programming Interface,應用程序編程接口)是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟件或硬件的以訪問一組例程的能力，而又無需訪問源碼，或理解內部工作機制的細節。
Windows API是一套用來控制Windows的各個部件(從桌面的外觀到爲一個新進程分配的內存)的外觀和行爲的一套預先定義的Windows函數.用戶的每個動作都會引發一個或幾個函數的運行以告訴Windows發生了什麼。API函數包含在Windows系統目錄下的動態連接庫文件中(User32.dll,GDI32.dll,Shell32.dll…).
API是操作系統提供給程序員的接口，SDK原指軟件開發工具，每一套環境都有可能自己的SDK，在Windows這一領域，SDK原是指Microsoft的軟件開發工具，現在凡以Windows raw API寫的程序我們通常稱爲SDK程序（Borland也支持相同的SDK API）
注意C++和VC++的區別:C++是一種程序設計語言,是一種大家都承認的軟件編制的通用規範,而VC++只是一個編譯器,或者說是一種編譯器+源程序編輯器的IDE,WS,PlatForm,這跟Pascal和Delphi的關係一個道理,Pascal是Delphi的語言基礎,Delphi使用Pascal規範來進行Win下應用程序的開發和編譯,卻不同於Basic語言和VB的關係,Basic語言在VB開發出來被應用的年代已經成了Basic語言的新規範,VB新加的Basic語言要素,如面向對象程序設計的要素,是一種性質上的飛躍,使VB既是一個IDE,又成長成一個新的程序設計語言。
MFC是Win API與C++的結合,API,即微軟提供的WinDOS下應用程序的編程語言接口,是一種軟件編程的規範,但不是一種程序開發語言本身,可以允許用戶使用各種各樣的第三方(如我是一方,微軟是一方,Borland就是第三方)的編程語言來進行對WinDOS下應用程序的開發,使這些被開發出來的應用程序能在WinDOS下運行,比如VB,VC++,Java,Dehpi編程語言函數本質上全部源於API,因此用它們開發出來的應用程序都能工作在WinOS的消息機制和繪圖裏,遵守WinDOS作爲一個操作系統的內部實現。
C、C++、API、SDK、IDE、VC++、MSDN、MFC、OWL、VCL、ATL 、BCB
C/C++都是一種編程語言，程序員用它來創作（我喜歡用創作這個詞，讓寫代碼有一些藝術氣息…）各種各樣的程序，簡單如計算閏年，複雜到一個系統地實現。當然， 編寫標準C程序的時候，我們還經常會調用各種庫函數來輔助完成某些功能；初學者使用得最多的C庫函數就是printf了，這些庫函數是由你所使用的編譯器廠商提供的。在Windows平臺下，也有類似的函數可供調用；不同的是，這些函數是由Windows操作系統本身提供的。
Windows操作系統提供了各種各樣的函數，以方便我們開發Windows應用程序。這些函數是Windows操作系統提供給應用程序編程的接口（Application Programming Interface），簡稱爲API函數。我們在編寫Windows程序時所說的API函數，就是指系統提供的函數，所有主要的Windows函數都在Windows.h頭文件中進行了聲明。
使用windows API創建的能在windows上運行的程序統稱爲windows程序。這些API隨着系統的更新升級，他們也是在不斷更新和擴充，但是，其行爲基本保持不變以保證不同平臺對應用程序的兼容性，面對越來越多地API，我們怎麼獲取可靠的幫助呢？最大的幫助就是MSDN，你可以把MSDN理解爲微軟向開發人員提供的一套幫助系統，其中包含大量的開發文檔、技術文章和示例代碼。MSDN包含的信息非常全面，程序員不但可以利用MSDN來輔助開發，還可以利用MSDN來進行學習，從而提高自己。對於初學者來說，學會使用MSDN並從中汲取知識，是必須要掌握的技能。
我們還經常聽人說Win32 SDK開發，那麼什麼是SDK呢。SDK的全稱是Software Development Kit，中文譯爲軟件開發包。假如現在我們要開發呼叫中心，在購買語音卡的同時，廠商就會提供語音卡的SDK開發包，以方便我們對語音卡的編程操作。這個開發包通常都會包含語音卡的API函數庫、幫助文檔、使用手冊、輔助工具等資源。也就是說，SDK實際上就是開發所需資源的一個集合，再具體點說，你知道CreatePorcess這個API,那怎麼使用，你需要有頭文件，當然還需要提供功能的系統DLL庫的引出庫lib，這些都在SDK中。現在讀者應該明白Win32 SDK的含義了吧，即Windows 32位平臺下的軟件開發包，包括了API函數、幫助文檔、微軟提供的一些輔助開發工具。
提示：API和SDK是一種廣泛使用的專業術語，並沒有專指某一種特定的API和SDK，例如，語音卡API、語音卡SDK、Java API、Java SDK等。自己公開的DLL函數也可以叫API！！！
一般來講，狹義上的API指 MS公開的函數。比如MSDN中介紹的函數。廣義的API可以包括所有的函數，你自己的函數也算，未公開的也是，指世界上一切函數。都可以叫API–pplication Programming Interface ；SDK也不僅僅指MS的開發包，你自己的程序如果需要讓別人作2次開發，你就會提供 一些函數接口讓別人編程，你提供的材料也叫SDK.
有了語言(C\C++)，有了開發資源(SDK)、有了幫助文檔(MSDN)，ok,我們可以編寫windows程序了，等等、工具有沒有更好的工具呢，人類之所以進步就在於會使用工具，所以，爲了更加高效的開發程序，一些集成開發環境誕生了，其中， Visual C++就是一個支持C\C++語言開發的集成開發環境（IDE）。記住，Vc++不是什麼新的編程語言，他只是 IDE，只是一個編程的輔助工具，具體來說，Visual C++包含了源程序編輯器、C\C++編譯器、MFC和ATL等，其中、MFC和ATL可以簡單的理解爲再次封裝的Windows的系統接口，原生接口就是API 。
其中，MFC,微軟基礎類(Microsoft Foundation Classes),實際上是微軟提供的,用於在C++環境下編寫應用程序的一個框架和引擎,也可以說，MFC是Win API與C++的結合後的再一次封裝。
OWL（borland公司，其已經逐漸淡處）、VCL（Borland公司–現在已和Inprise合併專–爲DELPHI設計的，其是由OWL演變的）和MFC（ms專爲vc++設計的）是不同公司提供的三大類庫，更確切點說，他們都是應用框架。
DELPHI：也是一種集成開發環境，不過他支持的語言是源至於pascal的Object Pascal.他使用的框架就是VCL.
BCB:就是Inprise公司使用了Delphi的IDE和VCL，再配上C++語言推出的開發環境C++Builder,很多人很念舊，所以冠以Borland C++ Builder之名，簡稱爲BCB。
ATL是全新的COM 開發工具 ：—- ATL 是ActiveX Template Library 的縮寫，它是一套C++模板庫。 使用ATL 能 夠 快速地開發出高效、簡潔的代碼， 同時對COM 組件的開發提供最大限度 的代碼自動生成以及可視化支 持。從Microsoft Visual C++ 5.0 版本開始，Microsoft 把ATL 集成 到Visual C++ 開發環境中。
SDK + C 完全可以進行所有的windows程序開發，當然，你還可以採用MFC + C++，當然，你要用SDK + C++ 也是你的自由，但是MFC + C可是impossible的事情，因爲，MFC就是C++寫的，C可不支持類。
Qt
一、Qt的優勢
1.跨平臺
2.signal-slot機制太漂亮了，與MFC相比，其非窗體類也支持該機制，這點設計者的想法讓人佩服,並且由於其非窗體類也支持該機制，所以其很多用法讓人感覺眼前一亮，如QTimerEvent的使用，不管是不是窗體，都能支持定時器，這一點比MFC要靈活了許多
3.容易上手，很多機制和MFC差不多
4.一定程度上簡化了內存回收機制，這點比MFC強的多，當然採用框架使用MFC也可以做到這一點，但是要自己實現框架
5.開發效率比MFC高得多(MFC 7年老鳥的評價)
6.一個平臺生命力是否旺盛，主要看技術優勢，文檔還有就是使用人數，Qt這三點都具有很大的優勢，如果能提高在嵌入式平臺上的運行效率，那就更完美了。
7.C++終於有可以讓人賞心悅目的GUI庫了
二、Qt的不足
1.編譯起來，時間實在是有點恐怖，目前和VS還是沒有辦法比的，也有可能是我用慣了VS
2.signal-slot 映射機制採用connect的方式，其調用規則爲把調用接口轉換成字符串格式，這個編譯時刻不能檢測出語法錯誤，這一點不太理想
3.運行效率不如MFC，Qt在其文檔上已經明確說了，其界面效果依賴於本地界面引擎，當然我也清楚，依賴於本地引擎，對於Qt來說是非常明智的，但是就嵌入式系統，運行效率往往是致命的，所以個人希望Qt不要越做越大，短小精悍最好
4.國際化方法不是內置支持的，而需要程序員來指定所用的編碼，這點令我感覺到很不習慣，尤其是和MFC比，其國際化方式在UNICODE版本下是內置支持的
5.進程間通訊（IPC），這個問題暫時估計還不會有更好的辦法,尤其是和非Qt應用程序進行通訊。
三、關於跨平臺
1.跨平臺的意義
很多人總愛拿跨平臺說事，其實跨平臺對你有用纔有意義，你開發java應用程序，卻只在windows上跑你的應用程序，跨平臺對你有意義嘛！？你還吐沫腥子亂飛，吹什麼牛啊！
2.Qt的跨平臺與其它語言的不同
無論java還是C#它們跨平臺的特點是一次編譯到處運行，而Qt的跨平臺，恰好是反過來的，一次編寫到處編譯，但是卻充分發揮了C++的效率，呵呵這個優勢不用我說了吧。
3.Qt的出現對嵌入式系統行業的貢獻
現在無論是桌面應用程序開發還是嵌入式系統開發，都面臨着一個非常嚴重的問題，就是沒有一個標準的語言框架，這個無論是java和C#，都解決不了這個問題，而Qt能。
據我所知，Qt現在能在個人電腦上跑，能在嵌入式系統上跑，她能跑得操作系統有,windows ,linux ,solaris ,mac,wince ,vxwork等等，著名的Photoshop Album就是用它編的，只需要重新編譯而已，而java的跨平臺，某些程度上是一個笑話，據我所知以上我所提到的系統,java並不是無縫的。
物聯網和嵌入式系統行業都缺什麼，它需要解決的一個問題就是語言問題，如果大家用不同的語言開發不同的節點，還談什麼融合啊,因爲不能做到技術普及，發展始終受限！
四、學Qt沒錯，肯定不會後悔，而且搞VC的，這個東西很容易上手。
雲風在其《遊戲之旅-我的編程感悟》一書中對MFC的看法：
“我所見到的程序員中，很多把C++/VC/MFC一鍋端，這或許造成了MFC在某一類高手羣體中的壞名聲。而另一方面，在許多初學編程的人羣中，又把MFC看得過於神聖，“會用”MFC，“會用”VC的人變成了高人。還有一些程序員，耐心的學完了C甚至C++，但是卻一直不屑於使用MFC寫程序，認爲微軟的那些東西都是垃圾。MFC的結構複雜度讓他們不肯像學習C++語言那樣細心的學習。
MFC既不是天使，也不是惡魔。MFC是一個框架類庫，它所做的不僅僅是封裝了Windows API而已，而是引導程序員去使用一些設計模式來編寫Windows程序。MFC由於歷史原因，攜帶了許多不那麼現代感的C++代碼，但是它依舊是一個成功的、完全基於C++語言的框架類庫。其設計總的來說是合理的，規模也在容易讓程序員接受的範圍內，沒有仔細研究過MFC的程序員沒有資格評論MFC的好壞。
絕大多數指責MFC的程序員沒有能力完成和MFC相當能力的類庫。無論MFC的優劣，在Windows下用標準C++寫帶有Windows GUI的軟件，除了MFC還真沒有太多的選擇（或許WTL算一個）。”認爲雲風的評價是比較客觀和中肯的，其基本觀點都是建立在深入的實踐瞭解之上的。
MFC的優勢
1.微軟官方出品
2.性能優良、穩定可靠
3.功能齊全，可以“包打天下”
4.產品支持完善
5.累積用戶羣數量龐大，市場接受程度高
6.第3方軟件支持程度高，組件豐富
MFC的不足有幾點：
1.不能跨平臺使用
2.由於設計年代較爲久遠，許多代碼和程序結構不是那麼“現代”和麪向對象
3.學習起來有難度，要花一定的時間不斷積累
4.語法結構不完全符合ANSI C/C++
5.做GUI開發時，週期較長，耗時耗力
6.做非GUI開發時，週期也較長，需要程序員考慮很多東西，手動的控制和調整很多
總之，如果沒有Qt的話，我開發程序的首選是MFC；但是，由於有了Qt，在選擇開發工具時，我真的是很猶豫。有時候，也不猶豫，當有跨平臺需求時，Qt是首選。
