uwp 和 win32 桥是不是彻底凉了？

[systemcall]

现在一些 Microsoft 商店的软件也可以弹 UAC，之后安装服务和驱动了
在几年前，微软就放开了 Win32 桥。软件除了不污染注册表和系统目录、不能提权以外，和一般的 win32 应用似乎没有多少区别
微软现在弄的 winget，安装的时候就是一般的 exe，还是从官网上下载的。不仅抛弃了 win32 桥，连 appx 等包管理器也抛弃了，导致不仅安装的时候通常会弹出来 GUI，而且安装的软件不能从 winget 卸载
还有就是 Microsoft 商店可以提交 PWA 应用了，但是似乎没有用到什么 UWP 才能用的功能，而且是直接在 Edge 里面跑的，根本没有什么隔离了

[ysc3839]

@ikas 在我看来，UWP 最重要的特征是 Universal，即统一、跨平台。这也是多年前微软硬要把 UWP 和 Win32 割裂开的原因，因为 Win32 不跨平台，跟 UWP 的根本理念相抵触。而随着微软宣布放弃自研移动操作系统，UWP 基本上算死了。至于 Xbox，游戏软件并不是强依赖 UWP 的特性，所以可以忽略这一块。
至于 UWP 背后的各个技术，以微软的技术能力再过个 10 年可能都不会死。
为什么微软不像以前把 UWP 相关技术跟 Win32 割裂开了？因为跨平台已经失败，继续割裂既恶心开发者，对自己也没有好处，不如开放出来方便开发者，自己也能得个好的口碑。

[Remember]

uwp 最大的问题是慢，而且是数量级程度的慢。那些自带 app，比如看图 app 打开的速度比 irfanview 这些慢十倍。
商店就更不用说了，跟 AppStore 相比，简直是十八世纪的乡村集市对比现代化超市。

30 年来一代一代 Windows 都是一层一层往屎山上糊屎，uwp 这个东西简直是把原来的屎山炸开了，变成几坨屎山，
win8,win10,乃至现在的 win11 都是在漫无目的逮住一坨继续往上糊。

[ikas]

@ysc3839
所谓 uwp 不过是一种应用开发模型的名字罢了,
从 win8 最初开始,微软发了一套新的 api,也就是所谓的 winrt.基于 winrt 开发的 app,最开始只是叫做 windows store app
当 winrt 逐渐完善后,wp 系统也开始引入 winrt,到了 wp8 时,可以选择 winrt 开发 wp app..
然后 winrt 继续发展,这套现代的 api 逐渐扩展到多个平台,这时候微软直接统一了开发模型,也就是所谓的 uwp.
这些本质都是随着 winrt 的发展而带来的影响,就算少了一个手机平台,uwp 还是 uwp,只不过是少了一个平台而已,在 win 端,同样有不少优质的 uwp 继续被开发,至于 xbox 游戏.本身 winrt 重点也不是游戏.要开发 xbox 的 app,winrt api 目前依然也是比较好的选择

winrt 作为一套提供了各种现代功能的 api,现在微软已经对其开放,而不是局限只能开发 uwp..
.比如你可以在 win32 中使用..你可以在 py 脚本中直接调用 winrt ai 相关 api

微软同样开始提供了 win32 与 winrt 相互混用的技术支持,当然这些也是一直在发展,比如从最开始的支持 host uwp 控件,支持调用 winrt api,到现在直接混合使用,然后到一套完整的混用模型,windows app sdk
比如 windows terminal,TranslucentTB 等,如果你去看下源码,就知道这些都是混合的典型 app,再比如 win11 的各种新的 app,比如画图,资源管理器

至于你说的跨平台失败.这些不是技术问题.只不过是政治问题而已

不能只用 uwp 来看 winrt,winrt 从未停滞

[40EaE5uJO3Xt1VVa]

真心希望来个沙盒功能，别的不说，前几天那个 tim 动不动扫内存扫硬盘，哎！

[ikas]

@yanzhiling2001 目前微软内置的沙盒(基于虚拟化),仅仅支持跑 edge,希望以后可以支持任意 app..
目前我是用一个受限用户来跑这些应用

创建一个受限用户,然后将大部分硬盘的权限对其设置为禁止读写...
然后使用 runas 使用这个受限用户来跑它

同时配置本地安全策略,尽可能限制它

[ikas]

比如受限用户 limited,来跑 yy
runas.exe /savecred /user:limited "C:\Program Files\duowan\yy\YY.exe"

当然你不能给管理员权限

[hez2010]

UWP 可以看作是一系列技术的集合：AppContainer （沙箱）、WinUI 、WinRT API 、CoreWindow （现代窗口）、MSIX 打包、应用生命周期和系统事件以及系统推送等等。
现在微软意识到这么做会割裂 Win32 和 UWP 的生态，于是从去年开始就在把 UWP 的技术逐个拆出来开放给 Win32 程序，只不过目前进度还在中间所以这个过渡阶段会显得有些混乱，比如 Win32 能用最新的 WinUI 3 样式反而是旧的，而有最新样式的 WinUI 2.7 反而只有 UWP 能用，典型就是微软自己的程序有的是 UWP （比如各种新的系统程序），有的又是 Win32 + XAML Island 调用 WinUI 2.7 的控件（比如 PowerToys 、Windows Terminal ）。
等这个过程结束（大概今年年底到明年年初），届时 Win32 只需要引入几个拆出来的特性就可以变得和 UWP 一模一样，而 UWP 去掉一些东西也可以变成 Win32 程序，真正做到融合和统一。

[ysc3839]

@ikas 我明白你的意思了，你是把 WinRT API 和 UWP 视作一体了，所以认为 UWP 仍未死亡。

按我的理解，WinRT 是 COM 的升级版，是一套描述 API/ABI 的规范，除了注册表注册以及 RPC 功能，其余部分和操作系统关系不大。
自 Win8 以来，微软在 Windows 中加入了许多基于 WinRT 的 API，这些 API 有的可以被 Win32 应用 (在 Win32 环境下) 使用，有的只有 Metro 应用 (在 Metro 环境下) 才可以使用。
后来微软把 Metro 这个开发平台 /运行环境推广到了别的设备上，取了个名字叫 UWP 。
现在 UWP 失败，微软把以前只能被 UWP 应用 (在 UWP 环境下) 调用的 API 一部分保留在系统中的同时开放给了 Win32 应用使用；一部分从系统中独立出来，做成了 Windows App SDK，给 Win32 应用使用，这个独立的 SDK 也在使用 WinRT 规范来描述它提供的 API 。
按我的理解，WinRT, 基于 WinRT 的 API 和 UWP 一直都是三个不同的东西。我认为 UWP 这个开发平台 /运行环境已经死了，但是 WinRT 本身，以及微软这么多年推出的、基于 WinRT 的、曾经是 UWP 专用的各种组件并没死。

[ysc3839]

@Remember macOS 和 iOS 的绝大部分 API 是基于 Obiective-C 的，理论上 objc 的消息传递机制比 WinRT/COM 的虚函数表更慢，但为什么没人说 macOS 慢呢？ Direct3D 也是基于 COM 的，似乎也没人说慢？

[ikas]

@ysc3839
并不是说将 winrt 独立出来..winrt 还是那个 winrt,只不过放弃了限制而已
其实我想表达的是 uwp 它只不过是 winrt 的一种应用而已..就好比楼上 hez2010 所说
winrt 以前只开放给 uwp 使用不过是一种人为限制

[ikas]

@hez2010 本来期望它的 windows app sdk 会提供支持 AppContainer 的方案..但是目前大概是很难了
这样 uwp 目前来说就有存在的必要性...
我之前在 windows app sdk github 讨论问过,得到 Partial Trust 的方案.然而官方始终闭口
没有 AppContainer 支持,很多人都不满..而 win11 大量使用 win ui2.6+,更是迷.只能说后续还远..

[shayuvpn0001]

实在是不明白，现在还留着 UWP 有什么用，Metro 都是过去式了，不谈了，即使是需要隔离的话，这样一会儿限制权限一会儿又不限制，还不如直接 sandboxie 。

[Remember]

@ysc3839 大概慢的不是消息传递，慢的是 uwp 那套 ui ？

我不是程序员，不懂技术细节，但一路从 win8 到 win11 走来，所谓的 metro，uwp 应用，不管是第一方还是第三方，无一例外的慢。而且同样一个程序，对比 macOS 的或者 win32 的，uwp 版本的慢的不是一星半点，是数量级上的。就不明白
他们是怎么做到的。

Windows 这么老些年折腾来折腾去，折腾出来的结果是 Google，多少程序都去 electron 了。

[bybyte]

Win11 Store 支持安卓了。。

[Kiriya]

微软就是什么好用砍什么

[hez2010]

@ysc3839 COM 并不慢，相反速度很快。UWP 慢的真正原因是做了跨进程 RPC 调用，涉及到鉴权的东西不在进程内处理，而是 RPC 到 Runtime Broker 处理，跨进程调用比进程内调用起码慢了 3 个数量级，所以只要 UWP 不涉及 IO，性能都很高。