Windows 11 Canary Build 27965: Scrollable Start Menu and Open Source Edit Editor

Microsoft has pushed a meaningful refresh into the Windows Insider Canary Channel with Windows 11 Insider Preview Build 27965 — introducing a redesigned, scrollable Start menu, bundling a new open‑source command‑line editor called Edit, and changing how .NET Framework 3.5 SP1 is delivered to Windows images.

Background​

Microsoft released Build 27965 to Insiders in the Canary Channel on October 8, 2025, marking another step in the long‑running evolution of Windows 11’s UI and platform tooling. The build is being rolled out via staged, server‑side gating, which means not every Canary tester will see every feature immediately.
These changes bundle visible consumer‑facing UX modifications with quieter but operationally significant adjustments for administrators and imaging teams. Taken together, they signal Microsoft’s dual focus: iterating on Start menu ergonomics while tightening packaging and delivery for legacy runtime components.

---

What’s new in Build 27965 — overview​

• A redesigned, scrollable Start menu with a responsive layout, Category and Grid views for installed apps, and a collapsible Phone Link / mobile device panel.
• The inclusion of Edit, a small, modeless, open‑source command‑line text editor that can be invoked from Terminal via edit.
• A packaging change: .NET Framework 3.5 SP1 is no longer shipped as a Windows Feature on Demand (FoD); Microsoft points customers to a standalone .NET 3.5 installer for legacy apps.

Each of these items affects different Windows constituencies: everyday users (Start menu and Phone Link), developers and power users (Edit), and IT/operations teams (.NET packaging). The rest of this feature drills into each change, weighs the implications, and lays out practical steps for admins and power users.

---

Redesigned Start menu: what changed, and why it matters​

A larger, scrollable Start with Category and Grid views​

The Start menu in Build 27965 moves away from the compact, 3‑row pinned layout and introduces a scrollable "All" area with two distinct browsing modes: Category view (default) that groups apps into functional buckets, and Grid view which presents apps alphabetically but uses horizontal real estate for faster scanning. On larger displays the Start menu expands automatically (Microsoft cites up to 8 columns of pinned apps, 6 recommended items, and 4 category columns on large screens).
This is not a radical redesign — it preserves pinned and recommended sections — but it is a practical one: the goal is to reduce clicks, surface frequently used apps, and make Start scale better on high‑DPI or multi‑monitor setups. The design choices follow months of user testing and prior Dev‑Channel previews in June 2025.

Phone Link integration and regional availability​

A small but visible UI element is a mobile device button near the Search box that opens a Phone Link pane inside Start. Microsoft confirms the cross‑device experience (Android and iOS) is generally available in many markets but will not arrive for European Economic Area (EEA) users until later in 2025. That regional gating is likely due to regulatory and privacy considerations.

UX tradeoffs and missing restorations​

The redesign does not restore an old Windows‑10 style Start that many power users still miss. There’s no “classic Start” toggle to reintroduce the pre‑Windows‑11 layout or Live Tiles. That decision reduces complexity from Microsoft’s product perspective but perpetuates the gap for users and organizations that prefer the older mental model. Expect community tools and third‑party utilities to continue filling that niche.

Practical takeaways for power users​

• The new Start is beneficial if you use a large display and want fewer clicks to apps.
• Category view may feel foreign initially but can accelerate access to clusters of related apps for heavy multitaskers.
• If you prefer the lean Windows‑10 Start layout, keep an eye on third‑party Start menu utilities; Microsoft’s update does not provide a one‑click restoration.

---

Edit: Microsoft’s new, open‑source command‑line text editor​

Why Edit exists​

64‑bit Windows had an odd omission: a small, reliable, in‑box command‑line text editor. Historically, 32‑bit Windows included an MS‑DOS Edit, but that didn’t carry forward. Microsoft introduced Edit at Build 2025 as a modeless, text‑user‑interface editor designed to be approachable, lightweight (under ~250KB), and immediately usable from Terminal via edit. It’s open‑source on GitHub under an MIT license.

Key features at a glance​

• Modeless Text UI (no modal modes like vi) — lower barrier to entry.
• Multiple file tabs and simple navigation (Ctrl+P to switch).
• Find & replace with regular expression support, word wrap, mouse mode.
• Small footprint and winget installability for non‑Insider systems.

Why this matters for developers and admins​

Edit is intentionally minimal: it’s not trying to replace VS Code or Vim, but to be the default lightweight editor you can rely on in scripts, containers, and recovery scenarios where GUI editors aren’t practical. For automation and scripting, a predictable in‑box editor reduces the need to bundle third‑party editors into images or recovery ISOs.

How to try Edit today​

• On Insider builds with the update, open Terminal and run edit or edit <filename>.
• On other Windows versions you can install via winget: winget install Microsoft.Edit, or download releases from the GitHub repo.

Caveats and limitations​

Edit is new: expect feature growth and bug fixes. For heavy text editing tasks, existing full editors remain superior. The inclusion of Edit as a built‑in tool is most valuable for quick, reliable edits in constrained environments.

---

The .NET Framework 3.5 SP1 packaging change — what changed and what it means​

The announcement in plain language​

Starting with Build 27965, .NET Framework 3.5 SP1 is no longer offered as a Windows Feature on Demand (FoD) optional component. Microsoft is not declaring end‑of‑support for the runtime with this action; instead it’s changing how the runtime is delivered and acquired. The company points organizations that still rely on legacy applications to a standalone .NET 3.5 installer.

Support status and historical context​

• .NET Framework 3.5 (and 3.5 SP1) dates back to the Windows Vista/Windows Server 2008 era; the runtime itself was first released in November 2007 (3.5) with SP1 following in 2008. Microsoft’s lifecycle documentation lists .NET Framework 3.5 SP1 as supported with an end‑of‑support date of January 9, 2029. That lifecycle status remains unchanged by the packaging update.
• Crucially, beginning with Windows 10 1809 and Windows Server 2019, Microsoft defined .NET 3.5 SP1 as a standalone product with a five‑year mainstream and five‑year extended support window — a technical reason why its lifecycle is tracked separately from the OS.

Operational implications for imaging and provisioning​

Removing 3.5 SP1 as a FoD affects how you build and service offline images:

• Previously you could include .NET 3.5 as a FoD package in images and add it during offline servicing with DISM, or use WSUS/Feature‑on‑Demand management patterns. That pipeline is now unavailable for builds starting with 27965.
• Organizations will now need to:
• Embed the standalone .NET 3.5 installer into images if offline provisioning is required.
• Script the installer into deployment processes (SCCM/MDT/Autopilot provisioning scripts).
• Validate that Windows Update or provisioning processes can access the standalone installer sources in locked‑down networks.

Security, compliance, and compatibility considerations​

• The runtime remains supported until its lifecycle end date, but moving delivery outside FoD means the installer lifecycle, update cadence, and distribution are now distinct from the OS servicing pipeline. Teams must ensure they continue to receive security updates and have a robust distribution path.
• If you rely on third‑party packaging tools or have air‑gapped environments, the change increases the administrative overhead to guarantee that the appropriate .NET 3.5 binaries are present and patched.

Recommended migration posture​

Microsoft is explicit: customers should migrate to modern .NET versions where possible. Practical migration steps include:

• Inventory apps that depend on .NET 3.5 (see checklist below).
• Prioritize migration workstreams by business impact and compatibility risk.
• For legacy or unsupported third‑party apps, prepare to host the .NET 3.5 installer in internal package repositories and automate secure install/patching.

---

Operational checklist for IT, imaging, and security teams​

Immediate (next 7–14 days)​

• Identify which images and deployment streams use .NET 3.5 as a FoD.
• Run a software inventory to find production apps tied to .NET 3.5 (static linking like CLR 2.0/3.5 dependencies).
• Test Build 27965 in a lab (Canary Channel or ISO) to confirm observed behavior and packaging differences.

Short term (30–90 days)​

• If you must keep .NET 3.5: host the Microsoft standalone installer in a secure repository and script its installation in provisioning flows.
• Update imaging documentation: remove FoD steps and add standalone installer steps for offline servicing and OSD.
• Validate update and patch workflows (WSUS, SCCM, Intune) will continue to apply security updates for the runtime.

Medium term (90–365 days)​

• Start migration projects to move apps to supported .NET versions (e.g., .NET 6/8+ or .NET Framework 4.8+ where possible).
• For critical LOB applications with no migration path, establish a continued support plan and isolate them where compensation controls are appropriate.
• Revisit application portfolio and modernize based on business value and risk appetite.

---

Deployment and compatibility scenarios: practical examples​

• Imaging with MDT/SCCM: Instead of DISM enabling a FoD package during image creation, insert an automated step to run the standalone .NET 3.5 installer (with silent switches) and validate the image. Test the installer’s behavior in offline environments.
• Autopilot/Intune: Use Win32 app packaging or PowerShell scripts to deliver the standalone installer during provisioning. Ensure proper detection logic to avoid reinstallation loops.
• Virtual appliances / container scenarios: If you create golden images for VMs or VDI pools, bake the standalone runtime into the golden image and manage updates via your usual image refresh cadence.

---

Risk analysis: strengths and potential pitfalls​

Strengths​

• The Start menu redesign improves discoverability and scales better for large screens, addressing long‑standing usability complaints for power users and modern hardware.
• Edit fills a real gap with a small, first‑party, open‑source editor that reduces the need to bundle third‑party CLI editors in construction and recovery images.
• Repackaging .NET 3.5 as a standalone product clarifies its lifecycle and decouples legacy runtime servicing from OS FoD channels, potentially simplifying long‑term lifecycle management.

Risks and pain points​

• Removing .NET 3.5 as a FoD increases operational friction for teams that relied on the FoD pipeline for offline images and constrained networks; this will require process changes.
• Server‑side gating in Canary means organizations testing features will see inconsistent behavior across devices during evaluation, complicating lab validation.
• The Start menu changes do not address users who want a full return to the pre‑Windows‑11 Start experience; such users will continue to look to third‑party replacements.

---

Developer and power‑user perspective​

For developers and command‑line enthusiasts, Edit is the headline: it is intentionally simple, modeless, and easy to script. Its arrival in the OS image (for Insiders) reduces friction in containerized or headless workflows where you want a guaranteed editor available without adding larger toolchain dependencies. The GitHub repo and open‑source model also let community contributors influence the tool’s trajectory.
From a productivity perspective, the Start menu update reduces friction when launching many apps across large monitors or multi‑display setups. However, power users anchored to older UI metaphors will view the change as incremental rather than restorative.

---

Verification notes and caveats​

• The Windows Insider blog post announcing Build 27965 is the primary authoritative source for the release details (Start redesign, Edit, .NET FoD change). Independent outlets including Pureinfotech, The Verge, The Register, and long‑standing technology news sites have reported and reproduced Microsoft’s claims, and the Edit GitHub repository and Microsoft documentation corroborate feature specifics.
• Lifecycle dates for .NET Framework 3.5 SP1 (including the January 9, 2029 end‑of‑support date) are documented on Microsoft’s lifecycle pages. The packaging change in Build 27965 does not alter the published support end date; it alters delivery.
• Some claims about rollout timing or experience may be gated by server‑side controls and regional regulation. The Windows Insider blog explicitly warns that the Phone Link cross‑device experience will be delayed for EEA users until later in 2025; timelines for full public availability and enterprise rollouts remain subject to change. Treat such timelines as conditional.

---

A concise migration and testing checklist (for immediate use)​

• Inventory: run application dependency scans for .NET 3.5 dependencies (static/dynamic).
• Lab validation: deploy Build 27965 in isolated lab and test imaging, DISM, and provisioning flows.
• Installer hosting: add Microsoft’s standalone .NET 3.5 installer to your internal package repository and test silent install/uninstall/repair.
• App compatibility: prioritize the top 20% of apps by usage for migration work or compensating controls.
• Update policy: confirm WSUS/Intune/SCCM settings will continue to manage .NET runtime updates for machines where the standalone installer is used.
• User communication: inform stakeholders that Start menu behavior will change and document any differences in Start training materials.

---

Conclusion​

Build 27965 is a compact package that combines visible ergonomics with quieter servicing shifts — a design update for users and a packaging pivot for administrators. The redesigned Start menu addresses real usability gaps for larger displays and more app‑centric workflows, while Edit restores a long‑missed, reliable command‑line editing tool to the Windows platform. The change to how .NET Framework 3.5 SP1 is delivered is the most operationally consequential item: it’s not an end‑of‑support declaration, but it does require adjustment from imaging, provisioning, and security teams.
For IT teams, the urgency is pragmatic rather than existential: inventory your .NET dependencies, host the standalone installer if needed, and use this Canary preview to validate your deployment pipelines. For users and developers, the Start menu and Edit offer incremental quality‑of‑life improvements that align with Microsoft’s broader incremental approach to Windows 11.
Expect more iteration: Canary is an experimental channel by design. Admins and power users testing Build 27965 should treat it as a preview environment to validate processes and gather feedback, not as a signal that every detail will ship unchanged to general availability.

---

Source: theregister.com Microsoft's latest Canary build has redesigned Start menu