现在一些 Microsoft 商店的软件也可以弹 UAC，之后安装服务和驱动了
在几年前，微软就放开了 Win32 桥。软件除了不污染注册表和系统目录、不能提权以外，和一般的 win32 应用似乎没有多少区别
微软现在弄的 winget，安装的时候就是一般的 exe，还是从官网上下载的。不仅抛弃了 win32 桥，连 appx 等包管理器也抛弃了，导致不仅安装的时候通常会弹出来 GUI，而且安装的软件不能从 winget 卸载
还有就是 Microsoft 商店可以提交 PWA 应用了，但是似乎没有用到什么 UWP 才能用的功能，而且是直接在 Edge 里面跑的，根本没有什么隔离了
This topic created in 1707 days ago, the information mentioned may be changed or developed.
 |
1
geniussoft Oct 4, 2021 via iPhone  1
微软真是典型的决策垃圾。
一把好牌，竟然还打这么烂，真是佩服。 |
 |
2
cjw1115 Oct 4, 2021
是 store 已经不局限于 uwp 应用了，所有类型的应用都可以通过 store 分发了
|
 |
3
hs0000t Oct 4, 2021 via Android
哪怕这样，也没几个上架更新微软商店的了，现在的微信还是 18 年更新的
|
 |
4
microka Oct 4, 2021
所以我对 store 的应用根本不抱任何期望，还是直接安装 win32 exe 应用程序算球。
|
 |
5
dingwen07 Oct 4, 2021 4
Windows 需要的是一个完善的 Win32 应用程序沙盒，目前最有希望的是 Sandboxie，最近应该是在开发文件隔离。我是真的希望微软也能做一个内置在系统里，按照微软的软件实力应该很轻松。
|
 |
6
kindjeff Oct 4, 2021 via Android
wp7 到现在微软已经推了多少种开发范式了，该不会还有公司坚持到现在吧
|
 |
7
ZeoKarl Oct 4, 2021 via iPhone
微软就是狗熊掰棒子，掰一个，扔一个。推出了那么多 ui 框架，也没见有流行的
|
 |
8
ysc3839 Oct 4, 2021 via Android 1
appx 没抛弃，还升级成了 msix，商店应用还是要用 appx 或 msix 。
winget 是对标 homebrew cask 这种“软件管家式”的包管理器，这类包管理器没有统一的包格式，主要是帮你自动安装各种软件。 至于 UWP 基本可以认为死了，因为微软的 Windows App SDK 项目已经在把曾经属于 UWP 的相关库拆分出来给 Win32 应用使用了。 |
|
9
ysc3839 Oct 4, 2021 via Android
@dingwen07 我也希望 Windows 能加入 macOS 那样的沙盒。不过可能是为了保证兼容性吧，微软就一直不加。
以及微软真的要推 UWP 的话，应该学学 macOS 保留传统 POSIX API 那样，保留传统 Win32 API 。 |
|
10
dingwen07 Oct 4, 2021 via iPhone
@ysc3839 #9 macOS 那个还不够得劲儿，我记得是应用商店强制，侧加载自愿。macOS主要是作到了权限控制，但是这个感觉也不像是用沙盒机制来做的。Windows 要做类似的估计会比较难，通过加载驱动可能可以绕过，Win 这边也不太可能去限制加载驱动。不过我感觉微软其实可以让用户选择是否将应用程序安装在沙盒里，毕竟我使用的大多数软件还是受信任的，只需要专门隔离那些不受信任的软件。
|
|
11
ysc3839 Oct 4, 2021 via Android
@nieyujiang 我觉得微软是总想着提升对第三方软件的控制力，但是方法却没用对。
Vista 时期微软推出 WPF，但是 WPF 是跟 .NET 捆绑的，与 Windows 本身独立，大概是怕内置在系统中被别的开发框架使用，想让开发者去用微软自家的 .NET 平台开发。而同时期 macOS 的 Cocoa API 则是内置在系统中的。 后面 WinRT/UWP 虽然内置在了系统中，但是微软却想着把桌面和移动应用统一，让开发者开发桌面应用时“自动”帮 Windows Phone 扩充生态，于是砍掉了传统好用的 Win32 API 。然而微软为了兼容性又不敢把 Win32 应用直接砍掉，于是开发者们就用脚投票，直接不用 UWP 。苹果就明白桌面应用需要那些传统 API，以及触屏和键鼠操作差异较大，于是给桌面和移动平台使用两套不同的 API 。 |
|
12
ysc3839 Oct 4, 2021 via Android
@dingwen07 macOS 现在对于非商店应用也会限制访问桌面、下载等文件夹了，虽然限制不多，但起码还是开了个好头。
macOS 是使用沙盒机制的，因为你下载个第三方的终端应用，然后在 shell 里面访问相关文件夹也会被限制。 至于加载驱动，macOS 在授予管理员权限后也能加载驱动，这并不是问题。 |
|
13
dingwen07 Oct 4, 2021 via iPhone
@ysc3839 #12 macOS 加载驱动（好像叫系统扩展）都没有进入内核，感觉会有比较大的限制。进入内核的属于“内核扩展”，需要将安全性改为“降低安全性”。现在苹果已经不推荐这种方式了。
限制文件访问并不是利用的沙盒机制，权限管理同样。沙盒只在 App Store 下载的应用才强制。 我觉得 Windows 需要一个沙盒只是感觉这可能是限制 Win 32 应用程序权限的唯一手段了，微软不可能学苹果去放弃兼容性。 |
 |
14
systemcall OP 1
@dingwen07 #13
Windows 也有用户模式驱动程序了，但是的确没有限制应用加载内核模式驱动程序。甚至 Win7 、Win10 刚出来的时候驱动都是要重新适配的，Win10 的用户模式驱动程序适配了的也不多 刚进入 AMD64 架构的时候，驱动还要改很多，加载的驱动还要签名，当年都完成了。现在 Windows 的驱动想要有什么修改，应该比较难了 |
|
15
systemcall OP @ysc3839 #12
win32 桥其实是包含文件系统隔离和映射的，注册表也是 可惜微软只挖了个坑，没有去管之后的事情。这个功能要是扩展一下就会很好，再加上 Microsoft 商店的 DRM 和对于商店应用的各种保护，没必要再留后台和加驱动、注册服务了。可惜一手好牌打得稀烂 |
 |
16
agagega Oct 4, 2021 via iPhone
@ysc3839
非 Mac App Store 的软件不强制使用沙盒的。但印象里即使是最简单的 fopen，也会弹出终端申请权限的对话框。 我是觉得兼容性很重要，但不用卡那么死。微软可能想着要兼容那些源码都没了的老软件吧。其实步子迈大点，用户和开发商还不是得接受，难道还能转到 Linux 和 Mac 不成。 |
|
17
ysc3839 Oct 4, 2021 via Android
@systemcall 那个隔离好像不是强制的，并不是真正意义上的沙盒。
|
 |
19
ikas Oct 4, 2021
其实目前 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 |
|
20
ikas Oct 4, 2021
上面说的有点乱..其实主要是微软现在更加开放,不再限制开发者选择什么..
比如以前你要么选择 win32,要么选择基于 winrt 开发 uwp.. 而现在.你几乎可以混用 另外关于权限,所谓"容器化,沙箱"等等 时至今日,你不能再根据 win32 与 uwp 这些简单的形态来看一个 app 是否是受限的是安全的 app 运行在什么形态下,已经交由开发者决定 就好比上面说的,我可以打包一个 uwp,但是配置了 runFullTrust 权限 再比如开发一个 win32 app(基于 windows app ask),但是配置 Partial Trust 权限,当然 Partial Trust 目前还未公开 为什么微软放弃了强制要求呢...限制的严格了..开发者不爽,限制的不严格了,用户不爽..毕竟 pc 不是手机 即便是放到 osx 上,也有大量开发者讨厌强制沙箱 那么作为用户呢..目前只能优先选择开源的,信任的开发者.. |
|
21
ysc3839 Oct 4, 2021 via Android
@ikas 在我看来，UWP 最重要的特征是 Universal，即统一、跨平台。这也是多年前微软硬要把 UWP 和 Win32 割裂开的原因，因为 Win32 不跨平台，跟 UWP 的根本理念相抵触。而随着微软宣布放弃自研移动操作系统，UWP 基本上算死了。至于 Xbox，游戏软件并不是强依赖 UWP 的特性，所以可以忽略这一块。
至于 UWP 背后的各个技术，以微软的技术能力再过个 10 年可能都不会死。 为什么微软不像以前把 UWP 相关技术跟 Win32 割裂开了？因为跨平台已经失败，继续割裂既恶心开发者，对自己也没有好处，不如开放出来方便开发者，自己也能得个好的口碑。 |
 |
22
Remember Oct 4, 2021
uwp 最大的问题是慢，而且是数量级程度的慢。那些自带 app，比如看图 app 打开的速度比 irfanview 这些慢十倍。
商店就更不用说了，跟 AppStore 相比，简直是十八世纪的乡村集市对比现代化超市。 30 年来一代一代 Windows 都是一层一层往屎山上糊屎，uwp 这个东西简直是把原来的屎山炸开了，变成几坨屎山， win8,win10,乃至现在的 win11 都是在漫无目的逮住一坨继续往上糊。 |
|
23
ikas Oct 4, 2021 1
@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 从未停滞 |
 |
24
40EaE5uJO3Xt1VVa Oct 4, 2021
真心希望来个沙盒功能，别的不说，前几天那个 tim 动不动扫内存扫硬盘，哎！
|
|
25
ikas Oct 4, 2021
@yanzhiling2001 目前微软内置的沙盒(基于虚拟化),仅仅支持跑 edge,希望以后可以支持任意 app..
目前我是用一个受限用户来跑这些应用 创建一个受限用户,然后将大部分硬盘的权限对其设置为禁止读写... 然后使用 runas 使用这个受限用户来跑它 同时配置本地安全策略,尽可能限制它 |
|
26
ikas Oct 4, 2021
比如受限用户 limited,来跑 yy
runas.exe /savecred /user:limited "C:\Program Files\duowan\yy\YY.exe" 当然你不能给管理员权限 |
 |
27
hez2010 Oct 4, 2021
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 程序，真正做到融合和统一。 |
|
28
ysc3839 Oct 4, 2021 via Android
@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 专用的各种组件并没死。 |
|
29
ysc3839 Oct 4, 2021 via Android
@Remember macOS 和 iOS 的绝大部分 API 是基于 Obiective-C 的，理论上 objc 的消息传递机制比 WinRT/COM 的虚函数表更慢，但为什么没人说 macOS 慢呢？ Direct3D 也是基于 COM 的，似乎也没人说慢？
|
|
30
ikas Oct 4, 2021
@ysc3839
并不是说将 winrt 独立出来..winrt 还是那个 winrt,只不过放弃了限制而已 其实我想表达的是 uwp 它只不过是 winrt 的一种应用而已..就好比楼上 hez2010 所说 winrt 以前只开放给 uwp 使用不过是一种人为限制 |
|
31
ikas Oct 4, 2021
@hez2010 本来期望它的 windows app sdk 会提供支持 AppContainer 的方案..但是目前大概是很难了
这样 uwp 目前来说就有存在的必要性... 我之前在 windows app sdk github 讨论问过,得到 Partial Trust 的方案.然而官方始终闭口 没有 AppContainer 支持,很多人都不满..而 win11 大量使用 win ui2.6+,更是迷.只能说后续还远.. |
 |
32
shayuvpn0001 Oct 4, 2021
实在是不明白，现在还留着 UWP 有什么用，Metro 都是过去式了，不谈了，即使是需要隔离的话，这样一会儿限制权限一会儿又不限制，还不如直接 sandboxie 。
|
|
33
Remember Oct 4, 2021
@ysc3839 大概慢的不是消息传递，慢的是 uwp 那套 ui ？
我不是程序员，不懂技术细节，但一路从 win8 到 win11 走来，所谓的 metro，uwp 应用，不管是第一方还是第三方，无一例外的慢。而且同样一个程序，对比 macOS 的或者 win32 的，uwp 版本的慢的不是一星半点，是数量级上的。就不明白 他们是怎么做到的。 Windows 这么老些年折腾来折腾去，折腾出来的结果是 Google，多少程序都去 electron 了。 |
 |
34
bybyte Oct 4, 2021
Win11 Store 支持安卓了。。
|
 |
35
Kiriya Oct 4, 2021
微软就是什么好用砍什么
|
Select Language