检测到论坛CSS可能没有正确加载,如出现排版混乱请刷新重试。

We detected that the CSS might not be loaded correctly. If the website displays abnormally, Please refresh and try again.

对本次Windows桌面客户端版本预览通道变更看法:

先放上预览通道变化的情况:

  • 原有Dev通道变为Canary通道,当前版本区段25000+;
  • 重新规划Dev通道,当前版本区段23000+;
  • Beta和RP通道保持不变。

自从2020年废了Skip Ahead通道以来,特别是2020年调整了预览通道为Dev、Beta、RP以来,Windows桌面客户端缺少一个像之前Fast通道的通道。这个通道剑指下一次功能更新,Windows桌面客户端团队可以很好实现对下一次功能更新的开发和收集反馈的掌控。因此,在SV开发期间,WDX直接提了216xx和221xx版本区间做功能开发;而后来SV2Moment开发,WDX直接划了22800+-23000+版本区间做功能开发。
但是这样仅限于功能开发,依旧无法实现对收集反馈的掌控,使反馈作为功能测试的替代,更好服务开发工作。同时,Windows+Devices部门规划了Next Valley,Windows桌面客户端团队也需要管理NV的开发和收集反馈的工作。于是在今天,Windows预览体验计划迈出了下一步。

  • Canary通道用于让Windows桌面客户端的测试版本保持与最新的Windows平台同步,同时
    掌控NV的开发和收集反馈的工作。Canary通道的版本还包括对Windows内核的重大更改、新的API等。
  • Dev是为了实现对Windows 11持续创新功能的开发和收集反馈的更好掌控。Dev版本的OS底层现在将更加稳定,因为它不会与Windows 11有太大偏差,都是ni周期的版本。预期分支ni_prerelease
  • Beta是即将完成的Windows 11功能。
  • RP是下一个Windows 11功能更新。

ThinkBou 鉴于此,对于之前Cu跳Zn的推测做一些修正:

  1. 跳周期意义不明,不知道是为了Server还是Client。但是NV大概率会在Ga周期完成,这是目前可以预测的。
  2. 基本来说,当初CU直接跳到2505x,是考虑到了WDX的开发安排。
  3. 23xxx目前依旧无法与11 23H2绑定,11 23H2的更新应该还是服务技术交付。不过无论如何,Windows 11的故事在Ni周期结束了。

    Famous ThinkBou

    今日我们迎来外部测试通道变更后的第一次更新推送。
    Canary → 25314.1000.rs_prerelease
    Dev → 23403.1001.ni_prerelease
    此外,之前在Beta通道里开启Moment包的部分预览用户被强制切换至新Dev通道,预计待22624(Moment 3)测试结束后,Beta通道将不会再启用类似于22622/22623/22624等的启用包。疑似微软在为Insider成员切换通道时失误所致。

    关于Win移动版的一些探讨
    前段时间,有人说从内部人员得到的消息
    1.Windows 10移动版16212往后的版本,不支持XAP应用,并不是因为要砍了,而是单纯的还没做完
    2.仙女座和wcos都和10m没关系,是从desktop模块化以后整出来的东西
    3.10m当时是从WP8.1fork出来的,cherry-pick了一些win10 tp/TH/RS的内容,并不是直接从Windows桌面版衍生出来的

      Claris 仙女座和wcos都和10m没关系,是从desktop模块化以后整出来的东西

      我很好奇这点……以及Win10M(含CShell版本)和WCOS之间的关系。如果说Win10M和WCOS完全没有关系,所以实在想不明白到底是什么没做完导致xap支持没做完。

      其实Zac在20年的文章里写到,“由于WCOS直到2017年年中才完全准备好自托管,因此早期的CShell工作是在Windows 10 Mobile之上进行的”,但是感觉还是很模糊

        Claris Andromeda是WCOS的一种,WCOS有很多Mobile的特点。比如程序包的mum里会有Mobile之类的东西、组装方法、分区结构之类的。
        比如这样的:
        <package identifier="Microsoft-WindowsCore-TestComponents" releaseType="Feature Pack" targetPartition="mainos" binaryPartition="false">
        <mum2:customInformation xmlns:mum2="urn:schemas-microsoft-com:asm.v3">
        <mum2:phoneInformation phoneRelease="Production" phoneOwner="Microsoft" phoneOwnerType="Microsoft" phoneComponent="WindowsCore.TestComponents" phoneSubComponent="" phoneGroupingKey="" />
        gailium119 abbodi1406不至于跑路吧

          ThinkBou 根据那边的说法,Phoenix是一次中期重构,xap单纯就是没来得及搞就砍了(但系统组件一直都有)
          WCOS在16299以前就有了,和Phoenix并行搞了一段时间


          本回复来自 Flarum Lite 1.3.0.0

          l zw mainos不一定是mobile,其它没有完整桌面环境的版本也是这个分区结构


          本回复来自 Flarum Lite 1.3.0.0

          • l zw 回复了此帖

            何木槿 看来只有搞到17110/17686才能彻底搞明白


            本回复来自 Flarum Lite 1.3.0.0

              Claris 我不是在说mainos,保留上面那一行是为了说明包名,底下才是WP“遗迹”。
              mainos当然常见,OEM预装的系统,C:也是MainOS。

              ThinkBou 那么“Core OS”可以解释了(Windows 8时期出现了非常多的Base Build),看起来WCOS和WP大概是有一个共同的基础,但演化成了两个分支

              Claris 17110真的看起来就像是WP Plus,不过也不排除只是搬运UI的情况

              Claris 我觉得可能是Core OS剥离法形成了一种通用方法,这样就可以剥后面的Build,不过10X 20279里面还有WP7的东西,就又有点扑朔迷离力

                何木槿 但是W10M除了内核和桌面版共用以外还是WP8的底子(相当于是WP8上面Cherry-Pick了Win10的东西并与之同步)
                WCOS应该是Win10 RS时代直接从桌面版把shell彻底剥离出来

                  Claris 其实我还是比较好奇。
                  因为龚敏敏之前说WP8的时候还只是内核相同,WP10的时候就是一个OS不同的SKU了……

                  还记得你之前提到过的“版本号欺骗”吗

                  从Windows 8.1开始,微软已经有方法欺骗了,比如某些方法返回版本恒定为6.2.9200,这为Windows 10修改内核版本为NT10奠定了技术基础

                  在Endermanch的win11和xp融合的视频 同样也出现了这个现象
                  (其实我也不知道放这个帖子讨论会不会跑题)

                  15 天 后

                  10.0.25267.1001.rs_wdatp_edr.221212-0900完整泄露,自从SV开始开发以来唯一一个得到了完整泄露的内部分支版本


                  泄露版25267新发现

                    ThinkBou ThinkBou

                    想刷新是可以刷新的,但是为什么就是不刷新完全呢……(注意控件左右间距和圆角)

                      © 2025 wvbCommunity 管理团队

                      删封申诉 | 知乎专栏 | 状态监控 | 用户协议(EULA) | 隐私政策

                      本站文章除其作者特殊声明外,一律采用CC BY-NC-SA 4.0许可协议进行授权,进行转载或二次创作时务必以相同协议进行共享,严禁用于商业用途。