请 windows 开发大佬指点下，我想学习一种微软支持的开发桌面 exe 程序得方式

Windows

程序

微软

桌面

74 条回复 • 2023-10-09 01:49:02 +08:00

1

LLaMA2

2023-10-07 11:28:36 +08:00

2

delphi7

2

jennalcn

2023-10-07 11:46:57 +08:00

有时候不用想那么多，直接开干就好啦。为什么只用微软官方支持的技术？这个有点迷。官方现在主推 MAUI ，但是用过都会无尽吐槽，个人推荐 AvaloniaUI ，但现在的新技术基本都不支持 Win7 ，如果要支持 Win7 的话还是得用 Winform

3

zed1018

2023-10-07 11:58:09 +08:00

react native ，https://microsoft.github.io/react-native-windows/

4

nulIptr

2023-10-07 12:02:53 +08:00 via iPhone

wpf 不就满足要求嘛，其实后面出的 uwp/maui 也都是 xaml 那套东西
说到官方技术支持，就算是富哥们儿钱也不能这么造啊

5

tool2d

2023-10-07 12:18:40 +08:00

昨天刚看到个 windows 界面开发相关的视频，可能和楼主第二条不符，但是思路还是可以借鉴的

https://www.bilibili.com/video/BV1rC4y1L7dX

这人比较罗嗦，我个人总结，就是 GUI 区分为 IM 模式和 RM 模式。

IM 模式指的是即时渲染，也就是可以不需要保存当前控件状态，你需要直接查状态就可以了，因为界面在不断刷新。

RM 模式是传统的 GUI 消息模式，保存了所有控件的状态，比如某个按钮被点击了，会触发回调函数。需要完整 GUI 框架才能运行。

视频推荐了 IM 模式进行开发，对比 RM 有一个好处，就是能极大化简 GUI 相关代码（因为不用管理状态）。

6

chen006

2023-10-07 12:31:16 +08:00 via Android

用.NET 做界面的话，可以在这些中挑下 WinForm, WPF, UWP, WinUI, Xamarin, MAUI, Blazor, Windows Community Toolkit, Uno Platform, Avalonia, Comet, ReactiveUI, Chromely, EdgeSharp, Electron.NET

7

mmdsun

2023-10-07 12:33:19 +08:00 via iPhone

2

这几个都是微软官方推荐的，任选一个：
https://learn.microsoft.com/zh-cn/windows/apps/get-started/?tabs=net-maui%2Ccpp-win32

8

verrickt

2023-10-07 12:33:24 +08:00 via Android

WPF 或者 WIN UI 3 ，UWP 已经半死不活了

9

ysc3839

2023-10-07 12:36:22 +08:00 via Android

如果追求体积小、现代化、微软支持、且排除 C++，那可以看看 React Native for Windows 。不涉及一些底层功能的话，只需要写 js 即可。底层界面框架是 Win10 自带的 WinUI2 ，不需要随程序附带。编译后 exe 印象中只有几百 KB ，React Native 的 dll 大概是 4MB 左右吧，以及你程序的资源文件，看复杂度有大有小。

10

ysc3839

2023-10-07 12:39:59 +08:00 via Android

另外要真正追求“Windows 正统”的话，其实只有 Win32 和 WinUI2 可选，因为只有这两者是 Windows 内置的。其他像 WPF 那些虽然是微软推出的，但是是比较独立于 Windows 本身的，去掉 .NET 部分也不会影响系统大部分功能。

11

qrobot

2023-10-07 13:56:34 +08:00

那当然是 Microsoft DirectX , 楼上都是扯淡, Microsoft DirectX 才是王道 [doge]

12

qrobot

2023-10-07 13:58:38 +08:00

@qrobot 保证正版微软支持, 并且满足以上所有需求. 不和语言绑定

13

elechi

2023-10-07 14:23:43 +08:00

WPF ，要不 webview2

14

hez2010

2023-10-07 14:25:55 +08:00

WinUI 3

15

subframe75361

2023-10-07 14:28:10 +08:00

webview2 是目前主推的吧

16

idealhs

2023-10-07 14:33:21 +08:00

2

小项目直接 winform, 大一点上 WPF,我说的,少看那些微软基于 webview 的东西,会变得不幸,微软后期推的技术都是一股咖喱味并且不太负责任,而 winform 和 WPF 是经典永不过时,大量工业软件都在使用它们,微软需要对这些技术负责,Windows 活一天他们活一天.并且他们的技术并不老旧一直在维护,winform 甚至都可以基于.net8 开发,我也推荐基于最新的.net8 sdk 而不是 framework 去开发.

17

encro

2023-10-07 15:26:36 +08:00

你这几乎指定了就是 WPF 。

WPF 那么好学好用的。

18

flyico

2023-10-07 15:34:13 +08:00

1

winform/wfp: 你直接念我身份证号得了

19

ysc3839

2023-10-07 15:40:52 +08:00 via Android

@idealhs
“经典永不过时,大量工业软件都在使用它们,微软需要对这些技术负责”
MFC 也符合上述说法

“winform 甚至都可以基于.net8 开发”
最新的 VS2023 ，C++20 都能用 MFC

“并且他们的技术并不老旧一直在维护”
WPF 似乎一直只支持 Direct3D9 渲染，那么多年了也没有更新

WinForm 和 WPF 估计已经进入维护模式了，就和 MFC 、IE 一样，微软停止更新后一般也会维护很长一段时间，但这不能代表好坏。

20

haierspi

2023-10-07 15:48:05 +08:00

react native, flutter ,Electron 三个任选吧.. 不过从上手难度来说 react native ,Electron 最低... 毕竟不用再学一门语言直接 JS 就搞定了

21

idealhs

2023-10-07 15:49:23 +08:00

@ysc3839 #19
Winform 和 WPF 将在未来一直支持最新的.NET SDK ，将能够使用所有.NET 的新技术。而开源后的全新.NET 的前景以及微软的支持力度是有目共睹的。MFC 则并非如此，MFC 只是 win32 api 的封装，并且 MFC 的开发难度以及效率，功能完全无法与 Winform 和 WPF 相提并论。
MFC 当然可以基于语言的新版本开发，你不应该将新版本语言的好处与新版本.NET 的好处混淆，至少最基本的 GUI 开发方面，处理异步没有比.NET 更好的方式。
WPF 基于 DX9 渲染我不认为有任何问题，没有人会在 WPF 项目中写 3D ，如果你有图形需求你不应该在 GUI 框架中寻找解决方案。
至于维护模式，第一你不要估计，第二微软会维护很久，就像你热爱的 MFC 一样。

22

webszy

2023-10-07 15:51:19 +08:00

@ye4tar 支持，这个比 wpf 简单多了

23

gbw1992

2023-10-07 15:51:23 +08:00

开发语言使用 c#
开发环境 visual studio
开发体验 wpf > winfrom
控件框架的话 winfrom 我 n 年前使用过 DevExpress(收费) 体验还行,开发前注意对常用控件进行样式封装
wpf 控件框架有一个 HandyControl
还有注意 wpf 和 winfrom 不跨平台
如果有跨平台需求用楼上推荐的 AvaloniaUI

24

ShadowPower

2023-10-07 15:52:55 +08:00

满足这些要求的只能是 WPF+C#了

如果哪天突然想要跨平台了，移植到 AvaloniaUI 也比其他框架方便

25

ysc3839

2023-10-07 16:03:03 +08:00 via Android

@idealhs 我并不热爱 MFC ，请不要给我扣帽子，我讨厌 MFC 。
.NET 的新技术难道不是“新版本语言的好处”吗？
WPF 只支持 D3D9 本身就是问题，即使它使用了新版本的语言，但仍然使用旧的操作系统功能，那就无法获得最佳性能以及最新特性。这和 MFC 类似，MFC 能使用最新的 C++，但仍然只能使用老旧的系统功能。

26

ysc3839

2023-10-07 16:05:03 +08:00 via Android

@idealhs 至于异步问题，个人认为 C++20 的 coroutine 也很好用。我没有详细调查过 C#的异步，不便评价。

27

StubbornHuang

2023-10-07 16:18:09 +08:00

试下 Duilib ？

28

albertofwb

2023-10-07 16:20:58 +08:00

@StubbornHuang Duilib 基于 C++ 的

符合你要求的只有 WinForm
Shadowsocks Nutstore 以及一众餐饮酒店网吧管理软件都是 winform

29

manasheep

2023-10-07 16:21:37 +08:00

就 C# WPF 就行，用最新的.Net 版本

30

dq19871123

2023-10-07 16:21:50 +08:00

目前来看只有 WPF 了

31

di1012

2023-10-07 16:35:40 +08:00

wpf 最新的.net

32

idealhs

2023-10-07 16:39:23 +08:00

@ysc3839 #25 C++版本再高只影响语法，不影响 MFC 调用的 win32 底层实现。同理 C#版本高也不影响任何实现，但是.NET 的升级会直接影响实现增加功能提升性能。至于 Windows GUI 开发不讨论异步，那么还有什么其他更加值得讨论的呢？

33

tyzandhr

2023-10-07 16:43:33 +08:00 via Android

写 Windows 怎么可能不碰 win32 呢？

34

ych8398527

2023-10-07 16:48:11 +08:00

WPF 。一周上手两周精通

35

YassoWithSpeaker

2023-10-07 17:20:12 +08:00

犹豫不决，java 解决，上 swing ，jfx

36

ysc3839

2023-10-07 17:50:55 +08:00 via Android

@idealhs
“.NET 的升级会直接影响实现增加功能提升性能”
提升性能很正常，C++编译器升级也能提升性能。但增加功能是怎么回事？ .NET 升级后 WPF 的功能就自动增多了？
“至于 Windows GUI 开发不讨论异步”
我有说过不讨论吗？我说 C++20 的 coroutine 很好用，但是 C#我没详细调查过，不便评价，这就叫不讨论了？明明我在讨论 C++的异步。

37

ShadowPower

2023-10-07 18:08:16 +08:00

@tyzandhr 大多数情况下可以只碰.net 上的封装，不至于直接接触 Win32 API

38

ikas

2023-10-07 20:33:32 +08:00

现在根本不用考虑其他的,直接使用 windows app sdk 即可
--
微软官方现在只有 winui2 与 winui3 在桌面端是持续维护的
winui2 或者说是内置于系统的 xaml ui 框架,微软已经不再推荐 app 开发直接使用(windows 内置的应用,还有系统界面基本都是 winui2)
windows app sdk 是独立于系统的一套 api,可以无缝使用 winrt,win32,winui3
---

当然现在 winui3 配合 c++是速度最快的,而.net 还不支持原生编译,启动比较慢

以下是基于 winui3 的一些 app
https://github.com/Paving-Base/APK-Installer
https://github.com/files-community/Files
https://github.com/Richasy/Bili.Copilot
...

39

kkwa56188

2023-10-07 20:48:40 +08:00

2

我想学做一道菜, 虽然中餐有很多菜, 比如这个那个的, 我要说下我的目的和要求:
目标是要正统的中餐, 不为学习
不用预制材料
只用中国传统方法
用材简单, 依赖少, 最好只要按菜谱材料, 非中餐地区也直接可以做
不考虑使用刀叉用餐的问题 (当然我知道勺子也可以吃, 但不清楚是否容易)
希望制作方法能一直流传/流行

40

Aloento

2023-10-07 20:55:23 +08:00

@kkwa56188 #39 西红柿炒鸡蛋，水煮白菜，请

41

smilenceX

2023-10-07 20:55:48 +08:00

WPF + C#, 符合你要求列表中的所有条目。

42

zhuangzhuang1988

2023-10-07 21:09:38 +08:00

WPF
工具成熟
AvaloniaUI 工具还是有点问题

43

pppguest3962

2023-10-07 21:22:23 +08:00

以前看过 Win MFC ，在 Win2000 、WinXP 时代，用纯正统 Win32 API 做一个窗体按钮出来，从头开始的话，很有可能是一个程序员半整天的工作量。。。
不知道 MFC 被微软丢进柜子里后，2023 年用什么角色来担当这个事情了，
要小巧，要快，始终还是 Win32 API ，实在是太麻烦了。。。

44

idealhs

2023-10-07 21:36:52 +08:00

@ysc3839 #36 C++编译器升级无法提升 win32 api 的性能，.NET 升级则能提升 WPF 框架性能。增加功能当然是增加.NET API 给你用。当然这些争执是无益的，Windows 下 GUI 开发选择 WPF 早就是标准答案，没有任何其他方式的开发效率，开发体验以及功能效果能够与之媲美。

45

idealhs

2023-10-07 21:39:45 +08:00

@pppguest3962 要小要快一直是 Winform 在做

46

ragnaroks

2023-10-08 00:35:29 +08:00

blazor-desktop ，纯 csharp ，发布到 edge-webview2 ，唯一的问题是新手大概要被 blazor 的一些特性绕几天

47

ragnaroks

2023-10-08 00:37:26 +08:00

对了，如果开发时间宽裕的话，可以用 unity3D 做，挺多人用 unity3D 做跨平台图形界面应用程序的，但是个人账户发布的制品在启动时会显示 unity3D 的标识。

48

ShadowPower

2023-10-08 02:40:48 +08:00

1

@pppguest3962
今天的电脑和 Win2K 时代的电脑相差特别大，消费者的需求也变了。
那个时代 GUI 程序绘图全靠 CPU 处理，当时的主流分辨率还是 640x480 ，而且很多电脑的“显卡”用途真的就只是为了显示画面，没有加速绘图的能力。

MFC 、Win32 API 、GDI+都是那个时代背景下的产物。

而今天很多人都在用 4K 分辨率的显示器，还希望用触摸板滚动界面时能按像素滚动，滚完了还有惯性。软件界面要有丰富且流畅的动画。如今那么多人喜欢 macOS ，有很大一部分因素就是这个。

所以微软不可能做一个全新的 MFC ，它已经不适合这个时代了。这种技术越多，Windows 的用户体验反而越差。

现代的 Windows GUI 应用，绘图的部分都是 Direct2D 、DirectWrite 、Direct3D ，能利用 GPU 加速渲染。还能分担 CPU 的负担。
这样才能实现在超高分辨率下平滑滚动等过去都不敢想象的需求。

MFC 提供的其他与界面无关的功能，后来被.NET 平台完全取代了。
因为这些东西早已成为 Windows 的一部分，所以上层应用同样可以“小巧”。

如果仍然想用 MFC 、Win32 API 开发，其实依然可以用，用起来还是那个味道。但对于大多数应用来说，开发成本高，用户体验差。也许很省内存，但今天的内存十分廉价，甚至不如用这廉价的内存去省下其他更昂贵的东西。怎么想都觉得划不来。

如果只是想做个无比简单的小工具，那么，用 WinForm 随便拖个界面，双击各种按钮填上代码，分分钟就糊出来了……

49

ysc3839

2023-10-08 05:16:20 +08:00 via Android

6

@idealhs
“C++编译器升级无法提升 win32 api 的性能”
这是废话， .NET 升级也无法提升系统 API 的性能。举 MFC 的例子是为了说明“经典永不过时”、“可以使用最新语言特性”这些理由并不能说明一个框架的好坏，Delphi 那套也符合这些，但是也很少人使用了。再者 MFC 许多功能也并非由 Win32 API 提供，比如 MFC 有 Ribbon UI ，是 MFC 自己实现的，而不是 Win7 加入的那套，那升级 C++ 以及编译器显然也可以提升 MFC 本身的性能。

曾经很长一段时间 Windows 下 GUI 开发是没有“标准答案”的，Windows 内置程序少有使用 WPF 的，而是使用 C++以及一个私有的界面库。微软自家的大型软件，似乎只有 Visual Studio 使用了 WPF ，而且还是主界面 WPF+部分界面 MFC 混合，Office 使用的是另一套跨平台的界面库。
.NET 系一直有一些细节问题。比如 Win7 只预装了 .NET 3.5 ，如果想免安装兼容 Win7-Win10 ，就得放弃一些新特性。WinForm 和 WPF 的主题风格和 Windows UxTheme 不一致，有种粗制滥造的感觉，比如 Win32 的 Common Control 基本都有一些过渡动画，WinForm 动画直接没了，WinForm 的菜单风格也与系统菜单不一致，WPF 更是完全没有使用 UxTheme ，而是自己搞了套主题，与系统主题相差较大，Qt 对系统主题的模仿都比 WinForm/WPF 细致得多。当然对于开发者来说开发效率是很高，主题也是要用第三方的，并不是什么问题，但在用户眼里，则是觉得 Windows 从来没有统一的界面风格，也做不到“程序包尽量小，依赖尽量少”。

说个题外话，为什么长期以来 Windows GUI 程序如此割裂？个人认为根本原因是因为微软强推 .NET 。自 21 世纪以来，许多新的操作系统都自带一套丰富的 API 及开发框架，比如 macOS ，以及后来的 iOS 、Android 等，但 Windows XP 仍然只有老旧的 Win32 API 。Vista 发布前夕，有传言称新的系统将要引入 WPF 等全新的开发框架，结果发布后发现 WPF 等是与 .NET 平台捆绑的，而 .NET 则是比较独立于 Windows 的，Windows 本身的 API 及开发框架并没有得到升级，微软也没向 .NET 提供 Win32 API 的 SDK ，想要使用，就得自己写一大堆声明。结果就变成了，旧应用没法渐进式升级，要升级只能重写。开发者想要获得良好的开发体验，就只能使用 .NET ，而使用 .NET 又很难访问底层 Win32 API ，WPF 的界面风格又与 Windows 本身的主题不统一。结果就是开发者要不然用 .NET+第三方界面库，要不然用 C++ Win32 controls ，要不然用其他的一些界面库。反观 macOS ，Objective-C 语言可以直接兼容 C/C++，系统中有内置风格统一、好用的界面库，自然许多开发者会倾向于使用系统提供的而不是第三方的。
多年之后的 Win8 ，微软再一次犯了错误，虽然 Win8 终于在系统中加入了现代化的 API 及开发框架 / 界面库，但是绝大多数仅面向 Modern App(或者说 UWP)，而 UWP 缺少许多经典好用的 Win32 API 。个人认为微软是想通过 UWP 变相强迫开发者为他们的移动平台开发应用，因为如果允许桌面的 UWP 应用使用传统 Win32 API ，那自然很难移植到移动平台上。然而砍掉 Win32 API 这种行为动摇了桌面应用的根基，时至今日 macOS 都不敢砍掉 POSIX API ，因此许多开发者就直接拒绝使用 UWP 。

在微软放弃移动平台之后，终于引入了 Xaml Island ，允许 Win32 应用使用 UWP 的界面库，开发者可以渐进式地把传统 C++ Win32 或者 .NET 应用的部分界面替换成 UWP Xaml 界面(WinUI)，同时微软也在开发 React Native for Windows 以及 .NET MAUI 等跨平台框架，这些框架底层使用系统内置的界面库，能保持界面风格与系统统一，开发者可以使用自己熟悉的语言开发，不需要学习新的语言。因此“没有任何其他方式的开发效率，开发体验以及功能效果能够与之媲美”这话，随着新框架的推出而变得不再准确了。
个人推荐楼主使用 React Native for Windows ，因为背靠 WinUI ，有着与系统统一的风格，且系统内置界面库，不需要庞大的依赖 ( .NET 后续版本不再内置在系统中，需要单独安装或者随程序发布 )，后续也容易移植到其他平台。坏处则是不兼容老系统，应该至少要 Win10 1903 。

50

usauk1998

2023-10-08 05:31:20 +08:00 via Android

用汇编语言

51

ladypxy

2023-10-08 06:34:33 +08:00 via iPhone

你这是点名 c#

52

xingjue

2023-10-08 06:45:59 +08:00

wails golang 写的

53

janus77

2023-10-08 07:19:41 +08:00 via Android

不用 c++ 官方支持依赖尽量少，这三点下来根本不剩几个了。

54

iorilu

OP

2023-10-08 07:54:04 +08:00

感谢各位大佬，经汇总各方面建议，现在基本确定两个方案

- 用标准 c# + WPF ，都是正统微软支持的技术，但唯一问题在于不跨平台
- react native for Windows, 可以跨平台，也算微软支持的方案，可用 web 技术，但不支持老点的系统

我后面可能会做这两个方案各做一个简单图形界面的 demo ，再确定长期使用的方案

很有价值，至少不会没方向了

55

klo424

2023-10-08 08:23:27 +08:00

想想十年前的 WPF 刚问世不久有很多人吐槽，现今的 WPF 已经是.NET 界的扛把子了。

56

buxudashi

2023-10-08 08:24:56 +08:00

aardio 你试试

57

haohaolee

2023-10-08 08:30:04 +08:00 via Android

感谢各位回帖的同学把 Windows 的 W 大写了，强迫性真难受

58

haohaolee

2023-10-08 08:39:03 +08:00 via Android

其它乱七八糟不论，Xaml 确实是好文明

59

macha

2023-10-08 08:41:28 +08:00

楼主还忘记说要支持哪些 Windows 平台了。
这个也非常的关键。

60

iorilu

OP

2023-10-08 08:58:25 +08:00

@macha 主流就行，也没想着非要兼容老的

win10 以上就可以了

毕竟开发方面，兼容老的就意味这软件包更大，开发更复杂，等等问题，往往不划算，就和浏览器一样

61

shijingshijing

2023-10-08 10:08:19 +08:00

生成的 exe 或程序包尽量小，依赖尽量少
--------------------------------------------------------
就这一条已经把范围缩小到只有 Winform+C#，WPF+C#两位选手了。
如果考虑尽可能的兼容老版系统（ XP ，Win 7 ），且性能不能太差，那么只有 Winform
如果 GUI 比较花哨，定制较多，那么只有 WPF+C#

前面说 RN 做的 4M 就算小了，Winform 做的 GUI 几百 K 都能出来不错的界面，因为控件本身都是 win32api 提供的。

62

iorilu

OP

2023-10-08 10:27:55 +08:00

@shijingshijing 大小只是相对而已

主要是如果利用 electron 等方案，哪怕自己写的代码很少，出来都是上百 M ，这肯定不能接受的

我个人的理想目标是，如果自己写一个简单的 form ，有几个按钮文本框等东西，编译出来的软件包总体积在 10M 以下，我认为就算合格了

并没追求极限，毕竟都知道越接近底层，肯定中间东西越少，出来软件包越小，所以上面有人提议 react native 如果出来软件包只有几 M ，我是可以接受的

63

asm

2023-10-08 10:43:46 +08:00

@usauk1998 擦，很久没见有人用 asm 写了，哈哈哈哈。你这建议还不如让他用 c+sdk 搞呢。

上面好多大部分都是 winform ，其实 windows 常见 app 还是躲不过 cxx ，微信刚开始是用 delephi 写的(foxmail 同样，毕竟那个啥吧)，后来改成用 vc 他们自己的库了，我记得国内有个开源的 gui 库，大厂都用。当然写个规模不大的 WinForm 真香。

顺便再吐槽一下，MFC 毁我青春。。。