l zw ThinkBou 我试过很多次，成功的只有19041+（20279-20348）的WFEP（120.27512.10351.0），也包括10X的，可能与都是120.x有关，还有22000+22449的WFEP，成功是因为22449并未包含实际更新的WFEP。 程序包/提取应用都试过，一装上就炸，进度条刚走完就提示 Windows 输入体验 不能启动之类的，程序包由于要重启，甚至会牵连到explorer一起炸。部分替换文件也试过，只有新版文件涉及的功能炸。
何木槿 l zw 22624.1465来力，移了少量功能下来（） 估计23xxx正式roll out悬了，微软我***（友好问候） 毕竟22000.1→22000.41也是321→421，WFEP也跨了100（
l zw 何木槿 不过.1465（22640）还是623。 毕竟23550就是上限了，不太可能进Retail。按照每个工作日Build+1，也只能到九月底。我倒是期待那之后Dev会推什么。 ThinkBou 然而SystemApps不就是随CU更新吗？不然就变成了非系统应用。除非WFEP也通过商店更新。
何木槿 l zw 23550就是上限了 垃圾网络又抽风复读力（悲） 这话我不知道在哪里见过，能否给一下出处？ BTW，那么24xxx这一段基本就等于是被放弃了？远景有人用20277->21277举例，但是20277->21277中间也还是夹着一些Build啊（
l zw 何木槿 23550不是有rs_prerelease的版本吗？按照规律，正式版本一般不会与下一周期早期测试版的版本号重合，比如16299即使重新编译个16299.15，也不会突破16300。24xxx不一定不存在，但不太可能推送。 ThinkBou 某人我也不认识啊。我根本不知道有这事。 psfx CU展开体积翻两倍以上，然而展开后也只是delta，应用delta后应该还要翻三五倍。反向分析，60MB的文件对CU大小的影响并不大。况且WinAppRT有一半的文件平常更新是基本不变的，甚至完全不变。
ThinkBou ThinkBou 对于微软来说，通过服务技术（也就是累积更新）更新WinAppRT.CBS是几乎不可能的，所以会直接推送新版本。 不过微软还是这么做了…… l zw psfx CU展开体积翻两倍以上，然而展开后也只是delta，应用delta后应该还要翻三五倍。反向分析，60MB的文件对CU大小的影响并不大。况且WinAppRT有一半的文件平常更新是基本不变的，甚至完全不变。 嗯，一下子就涨了得有40MB
l zw 新发现：23403有22622/22623相关组件，也就是可以“升级”到22622/22623，但不包括22624。 由此推断，234xx应该是从M2就和Beta分道扬镳了。但231xx又被认为是M3，那就只有两种可能：231xx并不是M3，或者231xx和234xx没有接续关系。 此从有了betaflt分支，好像Retail/Beta/Dev(ni_prerelease)都是平行开发的，完全找不到规律了。
提本狐 l zw 新发现：23403有22622/22623相关组件，也就是可以“升级”到22622/22623，但不包括22624。 实测还真可以 但是全部移除后还是23403 本以为会是22621🤔
何木槿 提本狐 毕竟是经过了重新编译的，卸载完回到23403很正常，“降级”也挺有意思，倒是真的22621装上23403内含的Moment包会咋样 似乎Moment的虚拟版本号还挺瓷实，我在20348上成功了几次，但没弄出成型的产物
