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

[systemcall]

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

[geniussoft]

微软真是典型的决策垃圾。

一把好牌，竟然还打这么烂，真是佩服。

[cjw1115]

是 store 已经不局限于 uwp 应用了，所有类型的应用都可以通过 store 分发了

[hs0000t]

哪怕这样，也没几个上架更新微软商店的了，现在的微信还是 18 年更新的

[microka]

所以我对 store 的应用根本不抱任何期望，还是直接安装 win32 exe 应用程序算球。

[dingwen07]

Windows 需要的是一个完善的 Win32 应用程序沙盒，目前最有希望的是 Sandboxie，最近应该是在开发文件隔离。我是真的希望微软也能做一个内置在系统里，按照微软的软件实力应该很轻松。

[kindjeff]

wp7 到现在微软已经推了多少种开发范式了，该不会还有公司坚持到现在吧

[nieyujiang]

微软就是狗熊掰棒子，掰一个，扔一个。推出了那么多 ui 框架，也没见有流行的

[ysc3839]

appx 没抛弃，还升级成了 msix，商店应用还是要用 appx 或 msix 。
winget 是对标 homebrew cask 这种“软件管家式”的包管理器，这类包管理器没有统一的包格式，主要是帮你自动安装各种软件。
至于 UWP 基本可以认为死了，因为微软的 Windows App SDK 项目已经在把曾经属于 UWP 的相关库拆分出来给 Win32 应用使用了。

[ysc3839]

@dingwen07 我也希望 Windows 能加入 macOS 那样的沙盒。不过可能是为了保证兼容性吧，微软就一直不加。
以及微软真的要推 UWP 的话，应该学学 macOS 保留传统 POSIX API 那样，保留传统 Win32 API 。

[dingwen07]

@ysc3839 #9 macOS 那个还不够得劲儿，我记得是应用商店强制，侧加载自愿。macOS主要是作到了权限控制，但是这个感觉也不像是用沙盒机制来做的。Windows 要做类似的估计会比较难，通过加载驱动可能可以绕过，Win 这边也不太可能去限制加载驱动。不过我感觉微软其实可以让用户选择是否将应用程序安装在沙盒里，毕竟我使用的大多数软件还是受信任的，只需要专门隔离那些不受信任的软件。

[ysc3839]

@nieyujiang 我觉得微软是总想着提升对第三方软件的控制力，但是方法却没用对。
Vista 时期微软推出 WPF，但是 WPF 是跟 .NET 捆绑的，与 Windows 本身独立，大概是怕内置在系统中被别的开发框架使用，想让开发者去用微软自家的 .NET 平台开发。而同时期 macOS 的 Cocoa API 则是内置在系统中的。
后面 WinRT/UWP 虽然内置在了系统中，但是微软却想着把桌面和移动应用统一，让开发者开发桌面应用时“自动”帮 Windows Phone 扩充生态，于是砍掉了传统好用的 Win32 API 。然而微软为了兼容性又不敢把 Win32 应用直接砍掉，于是开发者们就用脚投票，直接不用 UWP 。苹果就明白桌面应用需要那些传统 API，以及触屏和键鼠操作差异较大，于是给桌面和移动平台使用两套不同的 API 。

[ysc3839]

@dingwen07 macOS 现在对于非商店应用也会限制访问桌面、下载等文件夹了，虽然限制不多，但起码还是开了个好头。
macOS 是使用沙盒机制的，因为你下载个第三方的终端应用，然后在 shell 里面访问相关文件夹也会被限制。
至于加载驱动，macOS 在授予管理员权限后也能加载驱动，这并不是问题。

[dingwen07]

@ysc3839 #12 macOS 加载驱动（好像叫系统扩展）都没有进入内核，感觉会有比较大的限制。进入内核的属于“内核扩展”，需要将安全性改为“降低安全性”。现在苹果已经不推荐这种方式了。

限制文件访问并不是利用的沙盒机制，权限管理同样。沙盒只在 App Store 下载的应用才强制。

我觉得 Windows 需要一个沙盒只是感觉这可能是限制 Win 32 应用程序权限的唯一手段了，微软不可能学苹果去放弃兼容性。

[systemcall]

@dingwen07 #13
Windows 也有用户模式驱动程序了，但是的确没有限制应用加载内核模式驱动程序。甚至 Win7 、Win10 刚出来的时候驱动都是要重新适配的，Win10 的用户模式驱动程序适配了的也不多
刚进入 AMD64 架构的时候，驱动还要改很多，加载的驱动还要签名，当年都完成了。现在 Windows 的驱动想要有什么修改，应该比较难了

[systemcall]

@ysc3839 #12
win32 桥其实是包含文件系统隔离和映射的，注册表也是
可惜微软只挖了个坑，没有去管之后的事情。这个功能要是扩展一下就会很好，再加上 Microsoft 商店的 DRM 和对于商店应用的各种保护，没必要再留后台和加驱动、注册服务了。可惜一手好牌打得稀烂

[agagega]

@ysc3839
非 Mac App Store 的软件不强制使用沙盒的。但印象里即使是最简单的 fopen，也会弹出终端申请权限的对话框。

我是觉得兼容性很重要，但不用卡那么死。微软可能想着要兼容那些源码都没了的老软件吧。其实步子迈大点，用户和开发商还不是得接受，难道还能转到 Linux 和 Mac 不成。

[ysc3839]

@systemcall 那个隔离好像不是强制的，并不是真正意义上的沙盒。

[Cooky]

@dingwen07 微软家大业大，新项目有各种公司内部斗争，快不了

[ikas]

其实目前 windows 上 app 形态比较多
通常分为 win32 app,uwp app,win32 打包 app(也就是 appx,msix 等)
win32 app 就是传统 app
uwp app 通常在商店上提供,这些 app 具有限制权限,在隔离环境中运行,但是现在同样可以配置为 runFullTrust 权限
win32 打包 app 通常都是直接具有 runFullTrust 权限,这类 app 可以调用 win32 与 winrt api

uwp 是否死了?uwp 目前确实有一些停滞,比如 c#仅仅支持 7,但是 win11 中大量内置 app 依然使用 uwp 这一模型进行开发,比如最新的截图,商店等等,并且 win11 的外观设计规范目前依然只有 uwp 的控件库(windows ui2.6+)提供支持,并且现在你可以在 win32app 中 host uwp 控件,甚至 host 一个完整的 uwp app,比如 win11 最新的画图,资源管理器

目前微软最新的 app 开发方案是基于 windows app sdk,其采用 windows ui3 作为 ui 库,同时支持 win32 与 win rt 这两套 api,你可以随意混用.但是现在 windows app sdk 开发的 app 默认是 runFullTrust 权限,不管是作为打包 app(appx,msix)或者非打包 app

[ikas]

上面说的有点乱..其实主要是微软现在更加开放,不再限制开发者选择什么..
比如以前你要么选择 win32,要么选择基于 winrt 开发 uwp.. 而现在.你几乎可以混用

另外关于权限,所谓"容器化,沙箱"等等
时至今日,你不能再根据 win32 与 uwp 这些简单的形态来看一个 app 是否是受限的是安全的
app 运行在什么形态下,已经交由开发者决定
就好比上面说的,我可以打包一个 uwp,但是配置了 runFullTrust 权限
再比如开发一个 win32 app(基于 windows app ask),但是配置 Partial Trust 权限,当然 Partial Trust 目前还未公开

为什么微软放弃了强制要求呢...限制的严格了..开发者不爽,限制的不严格了,用户不爽..毕竟 pc 不是手机
即便是放到 osx 上,也有大量开发者讨厌强制沙箱

那么作为用户呢..目前只能优先选择开源的,信任的开发者..

[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，性能都很高。