Windows 10操作系統中，有時我們會發現一個神秘的進程“dfrgui.exe”。這個程序具體是做什么的？會不會對我們的電腦產生危害？今天，我們就來揭開這個神秘面紗，探究一下這個“dfrgui.exe”程序的真相和作用。
一、發現“dfrgui.exe”
在Windows 10任務管理器中，我們可以看到“dfrgui.exe”是一個獨立的進程，常常被用戶誤認為是病毒或惡意軟件。但實際上，這個程序是Windows系統的一部分，用于執行系統更新和修復任務。
二、深入了解“dfrgui.exe”
“dfrgui.exe”是一個圖形用戶界面應用程序，主要負責執行系統更新和修復操作。當Windows系統檢測到問題或需要更新時，會通過“dfrgui.exe”向用戶顯示相應的提示信息。這個程序在執行修復和更新任務時，會占用一定的系統資源，因此用戶可能會發現其在任務管理器中的占用率有所上升。
三、如何管理和優化“dfrgui.exe”
由于“dfrgui.exe”是系統正常進程，因此無需將其禁用或刪除。如果你發現該程序被阻止運行，可以嘗試以下方法解決：
確保Windows系統更新和修復選項已開啟：打開設置->更新和安全->Windows更新->高級選項，確保“讓我選擇何時更新”的選項已開啟。
清除“阻止可能不需要的應用程序下載和安裝”的限制：打開設置->更新和安全->Windows安全中心，在“防火墻和網絡保護”部分，點擊“高級”，然后取消選中“阻止可能不需要的應用程序下載和安裝”選項。
優化“dfrgui.exe”運行性能：
關閉不必要的通知：在Windows設置中，進入“通知和操作”，選擇“獲取這些發件人的通知”，然后將其設置為“從不”。這可以減少由“dfrgui.exe”觸發的不必要通知。
調整電源選項：將計算機置于“平衡”或“節能”模式，以降低“dfrgui.exe”運行時的功耗。
處理錯誤或問題：
如果你遇到與“dfrgui.exe”相關的錯誤或問題，可以嘗試以下方法進行修復：
重新啟動計算機：有時，簡單的重啟即可解決與“dfrgui.exe”相關的問題。
檢查系統更新：如果系統長時間未更新，可能會導致與“dfrgui.exe”相關的錯誤。請確保你的系統保持最新狀態。
清除臨時文件：打開設置->系統->存儲，點擊“臨時文件”，然后刪除不需要的文件和應用程序。這可以釋放一些空間，并可能解決與“dfrgui.exe”相關的問題。
總之，“dfrgui.exe”是Windows 10系統的一部分，負責執行系統更新和修復任務。雖然有時它的表現可能會引起用戶的注意，但我們可以通過上述方法來管理和優化它的運行，確保其在我們的計算機中發揮出最佳的性能。
近日，開發者 Samuel Tulach 在個人博客上感嘆道，“在 Windows 上編寫 GUI 應用程序真是太難了！”在文中， Samuel Tulach 討論了使用 C++ 編寫 GUI 應用的各種困難。他詳細列舉了幾種流行的庫，但這些庫通常會面臨諸如依賴項管理、應用程序大小以及樣式定制等問題，并沒有完全契合的解決方案。
萬萬沒想到，這個小吐槽引起了不少開發者的共鳴，甚至登上了 HN 熱榜。接下來，我們將通過本文看看難點究竟在哪里？
過去幾天里，來自捷克的程序員 Samuel Tulach，一直在尋找一個能夠讓他用 C++ 編寫帶有 GUI 程序的庫。他給出的要求非常簡單：
所以，Samuel Tulach 開始挑選一些稱手的工具、框架，結果發現并沒有想象中那么簡單。
首先，Samuel Tulach 從專為 Windows 應用程序開發而設計的現代化的用戶界面（UI）框架——WinUI 3 入手。
乍一看，它是個不錯的選擇。它允許你使用現代的 Windows 組件，還可以自定義樣式顏色。設計方面，你可以使用非常容易掌握的 XAML，或者直接使用 Visual Studio 設計器。
WinUI 3 控件庫
問題：使用 WinUI 3 框架開發的應用程序在發布時不能以無包裝（unpacked）的形式進行分發。這意味著無法將應用程序打包為一個單獨的可執行文件（.exe）及其所需的所有依賴項，而是需要依賴于特定的分發方式，如打包為 AppX 包或者通過 Microsoft Store 進行分發。
對于 Samuel Tulach 而言，大多數情況下，當他嘗試將應用程序遷移到虛擬機或不同計算機時，由于缺少一些不明依賴項而無法正常啟動。更糟糕的是，你需要提供一堆處理 WinUI 功能的 .dll 文件，沒有辦法提供一個可移植的 .exe 文件。使用打包形式通常沒有問題，但它們是以 AppX 包的形式安裝的，這本身就會帶來很多問題（尤其是在需要訪問所有 Win32 API 的情況下）。
緊接著，Samuel Tulach 將目光轉移到了 Win32 身上。Win32 是一種應用程序編程接口（API），它是微軟 Windows 操作系統的核心組成部分。它提供了開發者與操作系統交互的一組標準接口和功能，用于創建和管理 Windows 應用程序的各個方面，包括窗口、消息處理、文件操作、網絡通信等。
Samuel Tulach 表示，其需要高度的可移植性，因此使用操作系統的原生渲染是有道理的。這樣的程序可以是一個單一的 .exe 文件（因為我們對 MFC 進行了靜態鏈接），而且體積超小（只有幾千字節）。
同時，Samuel Tulach 稱，還可以使用別人已經編寫好的更簡約的庫，這意味著從概念到可運行應用程序的快速實現將變得非常容易。
基本 Win32 形式
問題：對原生的 Win32 控件進行樣式化處理是一項非常困難的任務。為了改變這些空間的外觀和風格，Samuel Tulach 需要為每一個控件編寫一個專門的自定義繪制函數，這個過程不僅需要詳細了解 Win32 API 的繪制機制，還需要大量的時間和精力投入。
對此，Samuel Tulach 吐槽稱，“有這個時間，我都可以直接去養家糊口了。”
此外，Windows 文件資源管理器（File Explorer）使用的一些原生 Win32 控件具有一個被稱為 “隱藏” 的暗色模式。用戶可以激活這個模式，但它只會對部分控件生效，并且在視覺效果上并不十分理想或完善。
Qt 在 C++ 圖形用戶界面開發中被認為是一個非常優秀的選擇。盡管它相對復雜，但它提供了 Qt 樣式表（Qt Style Sheets），這使得開發者可以輕松地設計和定制界面的外觀和樣式。Qt 樣式表使用一種類似于 CSS 的語言，讓開發者可以用熟悉的方式來定義控件的外觀、布局和交互效果。
OBS studio 使用 Qt 和自定義樣式表
然而，問題在于，當使用動態鏈接方式時，運行 Qt 應用程序需要大量不同的 .dll 文件，這些文件總共的大小超過了 40MB。為了減少文件大小，可以選擇將 Qt 靜態鏈接到應用程序中，這樣未使用的部分會被移除，從而減小應用程序的體積。
不過，Qt 使用的是 LGPL 許可證。根據 LGPL 的條款，如果選擇靜態鏈接 Qt，那么必須遵守 LGPL 的要求之一：要么開源應用程序的源代碼，要么提供用于重新編譯的目標文件。另外，Qt 也提供了商業許可證選項，可以以幾千美元的價格購買，從而免除遵守 LGPL 條款的義務，只是這樣成本又太高了。
wxWidgets（https://www.wxwidgets.org/）是一個相對容易學習的庫，還可以使用 wxFormBuilder。它所遵循的許可證要比 Qt 更寬松，可以靜態鏈接成一個 3MB 的可執行文件。
wxWidgets 啟用了實驗性的 Windows 暗模式選項
問題：wxWidgets 是一個在 Windows 上使用原生的 Win32 組件的庫。然而，與直接使用 Win32 或 MFC 相比，wxWidgets 并沒有提供輕松覆蓋繪制函數的選項，因此在樣式定制方面甚至比直接使用 Win32 或 MFC 更為困難。
盡管 wxWidgets 支持應用 Windows 文件資源管理器的暗模式控件，但實際效果并不理想。
hikogui
hikogui（https://github.com/hikogui/hikogui）是一個相對較新的保留模式 GUI 庫，它使用 Vulkan 作為后端技術。這意味著它利用 Vulkan 的強大功能來進行圖形渲染和顯示。hikogui 內置了暗模式的支持，開發者可以很容易地自行定制和樣式化界面，以適應應用程序的需求和設計風格。
問題：要成功編譯 hikogui，可能需要具備計算機科學博士學位，特別是在編譯器開發方面的專業知識。在體驗過程中，Samuel Tulach 嘗試了超過 30 分鐘去編譯示例，包括嘗試不同的代碼分支和發布標簽，但最終只得到了一個立即在某個 Vulkan 庫內發生訪問沖突的可執行文件，因此他決定放棄嘗試。
不過，盡管 Samuel Tulach 不太喜歡大量使用 STL（標準模板庫），甚至認為有時候并不是必需的，但他認為 hikogui 看起來確實有前景。
Sciter 實際上是一個不錯的 Electron 替代品，允許開發者使用 HTML/CSS 編寫桌面應用程序的 GUI。
SVG 圖標上抗鋸齒效果不佳的示例
問題：你可能認為應用程序大小或稱為一個問題，但實際上，包含所有必需的 .dll 文件的最終應用程序大小大約只有 25MB，這對 Samuel Tulach 來說完全可以接受。
Samuel Tulach 表示，如果 Sciter 能夠完全開源，那將是更好的選擇，因為這樣開發者可以將靜態鏈接版本用于商業用途（與 Qt 的問題相同）。同時，Sciter 的獨立許可證價格相比 Qt 要低不少（目前為 310 美元），Samuel Tulach 也愿意為此支付費用。
然而，現在不選用這個框架的主要原因在于，如上圖所示（看看標題欄圖標），渲染效果不太好。在體驗過程中，Samuel Tulach 透露其遇到了各種字體和圖像的抗鋸齒問題（啟用了高分辨率選項，即使在預編譯的 scapp.exe 中也存在這個問題）。而且，無論你做什么，窗口都會有一個相當厚（2-3 像素）的灰色邊框，完全無法自定義或修改。
如果你在一些論壇上詢問關于在 Windows 上使用 C++ 編寫 GUI 庫的問題，大概率會收到一些“這不是一個好主意”等類似的反饋，甚至論壇上的專家們會直接建議你采用其他技術堆棧來編寫應用程序的前端部分，然后將用 C++ 編寫的功能作為組件或模塊加載進來。
這種做法可以讓你更輕松地定制和風格化界面，并顯著加快開發速度。從技術角度來看，確實可以使用像 WinForms 或 WPF 這樣的工具生成一個體積較小的單獨可執行文件（.exe）。
詳細來看，有兩種方式可以實現：
問題：.NET Framework 在 Windows 10 及更新版本中是預裝的，因此從技術上來說，我們仍然可以滿足無依賴項的標準。然而，如果我們選擇將 C++ 編寫的功能模塊打包為 .dll 文件，我們仍然需要在運行時將這些 .dll 文件從打包的資源中提取到一個臨時位置，并編寫額外的 P/Invoke 代碼來調用這些模塊。
此外，如果使用 C++/CLI 編譯，生成的代碼將轉換為 .NET IL 代碼。換句話說，生成的應用程序可以在調試工具（如 dnSpy）中打開，你可以看到 C++ 代碼被翻譯為等效的 C# 代碼。這種情況下，生成的應用程序并不是純粹的原生代碼應用程序，而是包含了.NET Framework 的中間代碼。
而正如文章伊始所提及的，Samuel Tulach 想要原生的代碼，所以基于 WinForms 或 WPF 得到的代碼并不他真正想要的。
以上是 Samuel Tulach 考慮過的幾個方案。經過長時間嘗試各種不同的庫，甚至一度編寫自己的 MFC 樣式之后，Samuel Tulach 發現對于簡單的應用程序來說，沒有什么比 Dear ImGui 更合適的了。
Dear ImGui 是一個用于 C++ 的輕量級界面開發框架，它的主要目標是提供高效、靈活和易于使用的界面開發工具。Dear ImGui 是一個基于文本的界面開發框架，它使用簡單的文本命令來創建和更新用戶界面。
不過，Dear ImGui 在設計復雜的用戶界面時也有一些缺點，而且它不是保留模式的用戶界面，而是即時模式的用戶界面，因此想要使用，必須運行像 DirectX 這樣的 GPU 渲染器來渲染每秒 60 幀或更多幀的用戶界面。
正如上圖所示，Samuel Tulach 已經寫了一個示例，如何使用內置的多視口功能來制作簡單的圖形用戶界面應用程序。
編譯后的程序大小只有500KB，非常小巧。這個程序不需要安裝任何額外的依賴項，即使是將 MFC（Microsoft Foundation Classes）靜態鏈接到程序中，也不需要安裝 VC++（Visual C++）的運行時庫。這使得部署和使用這個程序變得非常簡便，用戶可以直接執行這個程序而無需擔心缺少運行時組件或依賴項。
對于 Samuel Tulach 這段經歷，不少開發者感同身受。來自 HN 的網友 pshirshov 表示：
我也有過類似痛苦的經歷。我需要一個真正跨平臺（Windows、Linux/Wayland、Mac、iOS、Android）的 GUI 工具包，它要有豐富的控件庫和合理的主題。事實上，唯一不錯的選擇是 QT，而使用 C++ 很難提高效率，因為它仍然缺乏基本功能，如類型解構和帶窮舉檢查的 ADT/GADT。QT 與其他語言的綁定還不夠成熟。
除了 QT 之外，還有漏洞百出的 Avalonia。對 Linux 的支持非常糟糕。
此外還有 Kotlin/Compose Multiplatform。它缺乏良好的文檔和先進的控件，而且仍然充滿 Bug。
我無法找到任何適用于 JS/TS 的優秀控件庫，即使是付費的控件庫（如 Telerik 和其他控件庫）也非常混亂。因此，Electron、Capacitor、React Native——它們都認為即使是一個非常基本的應用程序也需要投入大量精力。
Flutter 給人的感覺極不成熟，尤其是全局單例模式的普及使得在使用 Flutter 時，即使是管理小型代碼庫也變得非常困難。
另一用戶稱：
在 Mac 上我遇到同樣的困擾，我在 Mac 上 SwiftUI 的體驗是，它仍需要大量工作。文檔很差。如果你以直截了當的方式做事，性能可能會很差。支持舊版本的操作系統相當痛苦等等。
至此，你是否體驗過 GUI 開發？有哪些工具推薦？
來源：
https://news.ycombinator.com/item?id=40839208
https://tulach.cc/writing-gui-apps-for-windows-is-painful/