在 Windows 上不用 Win32 API 可以繪製出一個窗口么？

01-15

mfc 這樣對 win32 api 進行封裝的不算。
qt 貌似沒有用 win32 api？它是如何做到的？

CreateWindow無論如何都是要用的，你覺得qt沒用只是你還沒找到。

看你怎麼定義Win32 API了

廣義的Win32API是指所有Windows提供的API，數以萬計。

狹義的Win32API是指從Win95時代就有的那幾個主要DLL導出的API，包括 Kernel32 GDI32 USER32 SHELL32等

廣義的Win32API是躲不掉的，必須要用，無論你做什麼。

狹義的Win32API也很難全規避掉，但是繪製窗口可以不用它們。

比如可以用 openGL API或者 DirectX API直接繪製到屏幕上，只要讓你繪製的圖形長得像個窗口就好了。

另外 Qt也是用了大量Win32API的，Windows相關的代碼在 QPA plugin裡面，QPA是Qt的平台抽象層，從Qt4.8開始平台相關的代碼都放到QPA裡面了，跨平台移植就變得簡單了，增加一個新平台就寫個QPA plugin就行了。

能啊，不用win32api可以用uwp api嘛。

至於你說的qt沒用win32api，那肯定是錯誤的。

誰說沒用，開源的庫，自己翻下QWidget和QWindow的源碼不行么？再不濟，全文搜索下HWND不行么？

不用系統api，不可能畫出東西的。要麼調系統的widget，要麼調gdi之類自行繪製

我記得有幾個 XP 年代的彙編調試器（似乎就是 ollydbg？）是直接操縱顯卡繪圖的，對，直接疊繪在最上方

算不用 WINAPI 了吧

顯然可以。

不但可以，而且挺有意義。

我大學的時候一直在研究這個問題，最後發現

syser這個內核單機調試器做的最完善。

所以我去研究這個調試器的實現，它的繪製部分是在內核里通過hook dx驅動里的api來寫屏，這個兼容性最好，可以兼容win7以上，以及各種顯卡。我大學時候想過用hw相關api來寫屏，但兼容性比較差。鍵盤滑鼠消息也有很多方法，簡單點可以掛過濾驅動，複雜點可以hook中斷。

能寫屏能獲取消息，剩下就是擼一套界面庫的事情了，我還試過把ucgui這個小嵌入式界面庫擼進內核里，實現完全不依賴win的界面。另外還有幾個開源的內核調試器也實現了，只是很粗糙，只畫了個字元界面。這方面syser實現的最完善，作者擼完後就去追逐人生其他理想了，讓人羨慕…

另外聽說冰刃作者後來也擼了套屌炸天的東西，可以在win里跑起另外套內核，還能和win同時共存，不知最近咋樣了。

謝邀。

Win32窗口機制，是windows一系列圖形界面的基石。無論你是MFC一層薄薄的封裝，還是QT等第三方工具，都是基於對Win32一系列 API的調用。

CreateWindow之後，一個基於HWND句柄的空白窗口出現你眼前。雖然此時你什麼也不做，但Win32窗口依然不間斷的收到各種類型的窗口消息。在這一系列消息中，WM_PAINT消息至關重要，它決定了你程序的最終UI界面。PANIT消息是一個數據結構，提供了繪圖關鍵的HDC設備上下文介面。

回到提問者的問題。此時，UI界面的繪製，已經不是win32 API的事了。

你可以有以下的選擇：

1、直接使用GDI/GDI+。在更高版本的windows中，可以使用Direct2D的高級介面。

2、使用第三方的繪圖引擎；

3、使用以1或2為核心的第三方UI工具包，

話題再展開就是一個龐大話題，但就回答問題本身來說，已經足夠了。

在這裡丫在這裡。。。

(ps: 也可以用depends查看導入表, 但是還是動態查看比較有力)

實在不想CreateWindow也行，你可以創建個resource，然後開篇直接DialogBox。

然而DialogBox仍然是Win32API

然而DialogBox裡面應該也是調用CreateWindow實現的

在別人的地盤上是逃不出這個魔爪的。

不用win32 api，用nt api(native api)不行么……

按說lxss也是具備直接繪製圖形的能力的啊

win32 api說的是kernel32和user32等dll導出的，用於win32 subsystem的api啊……

既然要討論窗口，我們就看看窗口這個概念是怎麼產生的

在麥金塔和LISA之前，窗口這個概念只存在於PARC研究所的科研機之中

現代的商業化GUI概念最先是由蘋果公司創立的，甚至滑鼠都是蘋果公司發明的

在往前捯，市面上的計算機大部分都是使用字元界面的蘋果2和IBM兼容機（用的是微軟的DOS系統）

後來微軟在和蘋果合作中，接觸了GUI概念，於是跟蘋果做了一個協議，開發自己的視窗操作系統，也就是1985年的win1.0

喬布斯當年根本不把這個醜陋的東西放在眼裡

而微軟公司第一次開發能夠在計算機上繪製窗口的API就是由此而起

後續的api都是當年這個API的繼承和發展

如果可以不用這些API就繪製出窗口。。。那微軟費那勁幹啥呢？

何況後來微軟還因為windows被蘋果告上了法庭。。。

PS：在dos系統里，你是可以繪製類似於窗口的東西的，但是嚴格來說，那只是看上去像窗口的東西

一旦進入了windows系統，你的一切所作所為都要經過操作系統，你如果繞過windowapi直接寫顯存在屏幕上畫出一個類似於窗口的東西，是可能的，但是那個東西不會被系統所識別，嚴格意義也並不能算是一個窗口，而只是看上去像窗口罷了

而在遊戲引擎里，以unity為例，ngui和ugui繪製的窗口不知道有沒有調用winapi，但是你完全可以不依靠這些api繪製窗口，這些窗口也不被windows系統識別，它們是沒有窗口句柄的，只不過是一個看上去像窗口的一個圖片甚至三維體罷了

你可以用Direct2D的介面來自己實現一個繪製窗口. 這部分介面是CreateWindow 之外的. 雖然窗口是你實現的, 但是你顯示這個窗口的窗口還是要用CreateWindow.

你認為操作系統是幹什麼的。。。

如果經歷過WinXP時期，那麼你可能還記得「啟動前殺毒」。

它們是典型的Native mode應用程序：

這要看你在什麼層面畫窗口。

在現有SDK框架下做事情，CreateWindow是必須的，既然你也知道有封裝庫，那你該問的是這些庫怎樣封裝了CreateWindow和其他API，而不是你用的時候沒看見就以為沒有；

Vista之後的，如果你有能力hook DWM的話，那麼理論上你可以讓DWM composite任何東西來；

如果你能拿到on-screen surface physical address，比如GPU kernel mode driver，那你直接往指定地址上寫東西就好了，但要注意tiling mode和flip的時機；

在Windows可以直接調video bios的時代，你還可以用 INT 10h直接在屏幕上操作某個像素；

再說到現在的UEFI，如果你能寫個module放進去，OS里再調個private ACPI call，也有辦法畫個像UEFI Shell的東西出來。

除了第一條，99%的人還是洗洗睡吧。

這個問題讓我想起當年分析星際1，這貨根本沒用API，就是直接map了Surface把內容直接CPU copy上去的，所以星際1在安全模式下也跑得很high。但是WIN32 API它依然是用了的，不然怎麼set 640*480 fullscreen mode.

這是不可能的

你要得到一個窗口，要麼系統幫你畫個窗口，要麼自己寫代碼畫。

前者必然調用WinAPI，我就不說了。

後者就要求你自己操縱顯示設備，說白了就是往video_buffer里寫數據。但是這麼做是在直接操縱硬體，普通用戶態的程序是做不到的，必須內核態的才行，然而這就已經是驅動程序了，你要Windows載入你寫的驅動怎麼著也得要api吧？

你寫個驅動，可以接管整個屏幕，然後你就想畫什麼畫什麼了，別說窗口，畫個門也行。

繪製窗口的目的是什麼？可視化交互。

輸入-鍵盤滑鼠等。

輸出-屏幕。

而驅動這些硬體就是Windows在做的，如果你不想用win32 api就只能自己去驅動。

盜一張WPF的架構圖，處理輸入輸出的部分就在User 32里

如SDL就是對各平台底層api的封裝。

圖形部分簡單分為IMGUI和RMGUI兩種。

所以，用SDL做事件交互，圖形部分自己寫一個軟體渲染器，這樣就可以寫一個自己覺得很厲害但根本沒人用的跨平台GUI了。

最後，弱勢鄙視一下apple。

可以計算機底層是如何訪問顯卡的？ http://www.zhihu.com/question/20722310?utm_source=qqutm_medium=social （分享自知乎網）

如果你要追求奇淫巧技，可以嘗試在DeskTopWindow上繪製一個窗口（或者說類似一個窗口的東西），然後不停刷新，當然，我覺得這樣做毫無意義。