The terminal library extracted from Ghostty has reached 1.0 with a binary compatibility guarantee. JetBrains adopted it early in its 2026.3 IDEs, improving keyboard input and display behavior, and standalone releases make the engine available to other development tools.
Key points
Release highlights: libghostty-vt 1.0 ships with a C ABI compatibility guarantee and standalone distribution.
IDE changes: JetBrains adopted libghostty early in its 2026.3 release series, improving Shift+Enter handling and support for nearly 50 control sequences.
Windows Latest found a native WinUI 3 version of Registry Editor in Microsoft’s open-source Microsoft.UI.Reactor repository, and I compiled it and ran it on my Windows 11 PC. It actually reads the real Windows Registry and makes regedit.exe look like a relic.
Microsoft has only mentioned “a registry editor” in passing, in an October developer blog post that promised a tour of its sample apps “next month.” The tour hasn’t happened yet, which makes this the first look at the app running on a PC. It’s a developer sample, though, and Microsoft hasn’t announced plans to replace Registry Editor in Windows 11.
Windows 11’s legacy Registry Editor next to Microsoft’s WinUI Registry Editor sample. Credit: Windows Latest
Microsoft’s new WinUI Registry Editor looks nothing like the Windows 95-era original
Registry Editor still uses the two-pane layout it got in Windows 95, with keys on the left and values on the right. Apart from the address bar added in the Windows 10 Creators Update, its yellow folders, cramped menus, and tiny text have barely changed in three decades.
The WinUI version keeps the same layout, and it’s a good idea; power users would not stop criticizing Microsoft for making them relearn regedit, which hasn’t changed for so long.
But what I like is that Menus have more breathing room. The tree drops the yellow folders, but I hope there would be some newer-looking folder icon when or if this WinUI regedit comes to fruition. The address bar is a WinUI text box, and a status bar at the bottom shows the current path, which may be unnecessary. Like I said, this is a developer sample, and things may change a lot.
On my PC running Build 26340.9882, the app opened quickly and felt as fast as regedit. However, expanding HKEY_CLASSES_ROOT showed a brief “Loading…” placeholder before listing keys like .386, .3gp and .7z, and HKEY_LOCAL_MACHINE\SOFTWARE showed the keys and values regedit showed. Menus open with WinUI’s fluid animations, and resizing the window is smooth.
Help > About confirms it’s not a mock-up, as the dialog shows “Registry Editor Reactor WinUI 3 Edition.”
The About dialogs of the legacy Registry Editor and the WinUI sample. Credit: Windows Latest
Microsoft uses WinUI 3 and a React-like C# framework to rebuild Registry Editor
Microsoft calls Reactor “an experimental C# framework that brings the MVU (Model-View-Update) pattern to WinUI desktop apps.” In a developer blog post, Principal Software Developer Engineer Alexandre ZollingerChohfi says the goal is “to find out how far MVU can go on WinUI.”
Reactor is “not a new UI platform,” as Microsoft puts it. Every menu, tree and dialog in the app is a real WinUI control, with no HTML, Electron, or WebView2 involved. The only change is the way developers write the app.
The UI is written in C#, without XAML pages, code-behind or ViewModels.
Apps are built from components, with React-style hooks like UseState and UseEffect. It’s still C#, not JavaScript React.
When state changes, Reactor updates only the controls that changed.
Edit menu in WinUI Regedit sample. Credit: Windows Latest
I appreciate that Microsoft didn’t just wrap regedit.exe in a modern window. In the sample’s source code, a separate RegistryService class reads and writes the Registry using .NET’s Microsoft.Win32 APIs and catches permission errors so a protected key doesn’t crash the app. The window also uses Windows 11’s Mica backdrop, which “only samples the desktop wallpaper once” to keep apps fast.
XAML isn’t going anywhere, as Microsoft says “WinUI is the foundation,” and ideas that prove themselves in Reactor could make it into WinUI too. When we covered Reactor, Microsoft pitched it as an easier way to build native apps, including with AI coding tools.
The Registry Editor sample works, but several features are still unfinished
I didn’t write or change any of Microsoft’s code. I only changed the build settings to bundle .NET and the Windows App SDK, which turned the sample into a portable folder that runs without me having to instal anything.
Registry Editor sample compiled into a self-contained portable folder with ReactorRegedit.exe. Credit: Windows Latest
Microsoft’s code can create, rename and delete keys, add String, Binary, DWORD, QWORD, Multi-String and Expandable String values, and search with Find (Ctrl+F). Since one wrong edit can break Windows, if you’re going to try this, do it in a virtual machine, like I did.
Feature
Status in Microsoft’s code
Favorites
Not saved after you close the app
Import and export
Clipboard only, no .reg file picker
Export All
Exports only HKEY_LOCAL_MACHINE
Permissions
Menu item does nothing
Load Hive and Unload Hive
Placeholders
Network Registry and Print
Empty
A comment in the code says Permissions is “out of scope for initial implementation.”
Microsoft’s WinUI modernization is reaching even the oldest Windows tools
Again, the sample doesn’t mean regedit.exe is getting replaced, but Microsoft is thinking about it. On a podcast in August, Marcus Ash, Microsoft’s CVP of Design and Research for Windows, said “even things like Regedit and some of the tooling, we’ve already started to look at.”
Registry Editor would join a growing list.
File Explorer’s Properties dialog is getting a WinUI 3 version with dark mode.
New UI and old UI of Properties sheet in Windows 11
The WinUI version is the first time Registry Editor has felt like a Windows 11 app. It still needs Permissions, proper .reg files, and plenty of testing, but if Microsoft ever ships a new Registry Editor, I’d be happy if it looked like this. Would you switch?
Flutter has long enabled developers to build Android and iOS applications from a shared codebase while supporting platform-specific interfaces through Material and Cupertino widgets. However, because these design libraries were bundled with the Flutter SDK, even minor framework-provided UI improvements could require a complete SDK upgrade, potentially introducing unrelated changes and additional regression testing.
In August 2026, Flutter 3.47 addressed this limitation by introducing independently versioned material_ui and cupertino_ui packages. Officially announced in September 2026, this architectural change allows Flutter’s design libraries to evolve separately from the core framework, with implications for platform-specific UI updates, custom design systems, and long-term application maintenance.
How Decoupling Changes Cross-Platform UI Development
For developers, the change affects more than package updates. It also influences how platform-specific interfaces evolve, how custom design systems are built, and how UI dependencies are managed across applications.
1. Faster Adoption of Platform-Specific UI Changes
Google’s Material 3 Expressive and Apple’s Liquid Glass introduce new visual treatments and interaction patterns. Flutter’s standalone design libraries let teams implement these evolving design systems without waiting for the next Flutter SDK update.
Applications maintaining separate Android and iOS interfaces can incorporate supported design updates through the relevant package, subject to SDK and dependency compatibility. This gives teams greater control over when to adopt new platform conventions without requiring coordinated changes to both UI libraries.
However, decoupling does not automatically deliver native UI behavior. Material and Cupertino remain Flutter-rendered widget libraries, and developers must still implement appropriate platform conventions and validate accessibility, animations, and interactions.
2. Better Foundations for Custom Design Systems
Flutter’s lower-level widgets library historically lacked certain reusable UI capabilities, forcing custom design system developers to recreate components or rely on design-specific implementations.
Alongside decoupling, the Flutter team is addressing gaps in its style-neutral widgets library to provide more reusable building blocks. As more foundational functionality becomes available, developers may be able to reuse common UI behavior without depending on either design library.
Note: These improvements remain ongoing and are not automatically available through the standalone packages.
3. More Explicit UI Dependency Boundaries
Independent design libraries make it more important to identify where reusable components depend on Material or Cupertino APIs. Shared widget packages that expose design-specific classes through public interfaces can become difficult to maintain when applications and third-party dependencies use incompatible library implementations.
As Material and Cupertino evolve independently, these dependencies become more visible, reinforcing the importance of clear boundaries between shared UI components and platform-specific implementations. This separation can help contain the impact of future design-library changes on the wider application architecture.
What Should Developers Consider Before Migrating to Standalone Packages?
Before migrating to standalone Material and Cupertino packages, Flutter app development teams should evaluate their application’s dependencies, UI architecture, and compatibility requirements. The following checks can help reduce migration risks:
1. Audit Third-Party UI Dependencies
Identify packages that expose Material or Cupertino types through public APIs. Dart treats identically named classes from the bundled and standalone libraries as distinct types because they have different library identities. This can cause compilation errors when third-party APIs expect legacy types. Check whether critical dependencies support the standalone packages, and consider deferring migration where compatible versions are unavailable.
2. Assess Shared Widgets and Design-system Dependencies
Review reusable components, theme configurations, and internal UI packages for direct references to legacy Material or Cupertino types. Coordinate updates across shared libraries to prevent incompatible interfaces.
3. Plan for Mixed-library Compatibility
Where legacy and standalone widgets must coexist, evaluate Flutter’s compatibility bridges for inherited theme and localization context. These bridges cannot resolve Dart type mismatches in public APIs, which require compatible package implementations.
4. Update Localization and Validate UI Behavior
Review localization delegates and test navigation, theming, accessibility, animations, and platform-specific interactions after migration. Include widget, integration, and visual regression tests where applicable.
For applications with compatible dependencies, developers can use Flutter’s automated migration command, dart fix — apply — code=migrate_design_widgets, and ensure the standalone packages are added to the project’s dependencies.
For larger applications, developers should first migrate compatible internal packages and verify whether third-party dependencies expose legacy design-library types. Where mixed-library usage is unavoidable, proceed with migration only across tested compatibility boundaries. Applications dependent on incompatible public APIs may need to defer adoption until those packages are updated.
Ending Note: A More Modular Future for Flutter UI Development
Flutter’s Material and Cupertino decoupling represents a shift toward independently maintained design systems and more flexible cross-platform architectures. While this creates opportunities for faster UI updates and greater customization, it also introduces new considerations around dependency compatibility and long-term maintenance.
For businesses, the immediate priority is to evaluate whether their existing applications are ready for this transition and where architectural changes may be necessary. Whether the migration is handled internally or with support from experienced Flutter developers, the focus should remain on maintaining application stability while preparing for Flutter’s evolving design-system architecture.
LLMs don’t know how to design software that uses LLMs. They’re comfortable writing normal programs, but if you throw an AI-shaped problem at them, they will usually screw it up. Why is that?
Going down the symbolic rabbit hole
For example, this post describes an attempt to vibe-code a memory tool that would flag when one memory contradicted another1. This is a great instance of a task that was virtually impossible five years ago but is now relatively trivial due to LLMs. You can simply task a LLM with scanning for contradictions, either in a big batch or pairwise2.
However, when asked for the “state of the art” approach3, the AI agent in this case did not recommend LLMs. It started building a bewilderingly complex symbolic system to convert the memory items into structured logical atoms, then mechanically compare them with a solver. This, of course, did not and could not work, because there is no analytic way of determining whether any two natural-language sentences express the same proposition.
The LLM knew this was impossible! When the user eventually lost patience and said “hey, why isn’t this working”, Claude immediately explained that this was a known 130-year-old problem with no solution. And yet it happily went around and around for weeks iterating on a dead end.
I’ve run into this myself. When I was building Autodeck (AI-generated spaced repetition cards) my agents would routinely try to categorize cards by regex or keyword search instead of just making another LLM call.
Why can’t LLMs use LLMs correctly?
Why would this be happening? I have two obvious explanations and one deeper one.
The first obvious explanation is that most training code is pre-LLMs. Assuming the labs aren’t feeding the current avalance of slop repositories directly into the models4, the vast majority of the code that models learn from was written before LLMs were an option. So it would make sense that they’d reach for non-LLM approaches, in the same way that they’d reach for jQuery over modern vanilla JS, or Backbone.js over React, right? Wrong, actually! LLMs don’t choose jQuery and Backbone. Whatever part of the training process pushes them towards up-to-date knowledge in other areas isn’t successfully pushing them towards LLMs, so this can’t be the whole story.
The second obvious explanation is that RLVR is not a good environment to write code that calls LLMs. Much of the time LLMs spend training is spent in reinforcement learning environments where an automatic grader determines their performance (for instance, by running some code they wrote and checking the outputs). I don’t know this for a fact, but I would be surprised if these environments contained the credentials and API access for a LLM to call other LLMs5. So even if the pretrained LLM was comfortable writing that kind of code, the reinforcement learning process might discourage6 it from doing so.
The third explanation, which I like the most, is that current AI agents are just not very good at software design. On this explanation, picking a doomed symbolic approach instead of simply calling a LLM is not a weird aberration but a normal instance of AI agents picking the wrong tool for the job. I’ve seen this behavior from LLMs in other contexts too: trying to build complex (and doomed) consensus algorithms instead of tolerating stale data, introducing synchronous checks in event-driven systems, and so on. In the past I’ve chalked theseup toalignment, but I’m open to the idea that they’re just ordinary errors of software design.
Conclusion
One lesson I learn over and over again is that I can’t judge a LLM by the standards of a human. Any human programmer who was capable of implementing a sophisticated symbolic solver would know that it wouldn’t work, and so if they suggested that approach I’d assume7 they had a good reason. Only a LLM could be both smart enough and dumb enough to make this mistake.
Using LLMs well involves extracting value from what they’re good at and avoiding wasting time at what they’re bad at.
This is surprisingly hard, because of the point above. LLMs are good and bad seemingly at random: they will work hard for hours but sometimes be shockingly low-effort, they will draw on inhumanly broad expertise but fail to apply the most basic common-sense, they can successfully rewrite enormously complex programs but will often make very silly errors in design.
If you can predict where they will do well or badly ahead of time, you can get enormous value from LLMs; if you can’t, you will likely waste a lot of time and tokens going down hopeless approaches.
Here’s another example where the user “implied” that Opus 5.5 should use a judge model and it instead constructed a series of regex checks.
In hindsight, this was probably the key mistake, though I don’t know how you’d turn that into advice for non-technical vibe-coders. Never asking the agent about the state of the field is a mistake too. Put one more notch on the LLMs reward expertise belt.
This theory also explains why LLMs are great at prompting other LLMs as subagents, or on training LLMs from scratch: they’re likely directly RL-ed and evaluated on that, unlike on writing code that calls LLMs.
In this missing data page puzzle, two arrangements seem to make the same triangle. Why does the second show a gap?
This picture is a small cousin of the classic missing-square puzzle. It looks like two large right triangles sitting on identical grids. In the lower drawing a white square opens up. No card was stolen from the desk, and the printer did not skip a page.
Look closely at the long diagonal edge in each arrangement. The red wedge rises three grid units over a run of eight. The teal wedge rises two over five. Those are close slopes, but they are not equal. In one arrangement the join bends one way; when the wedges change order, the join bends the other way. The grid makes the bend easy to miss.
Before you scroll, decide what you think the yellow region represents. Is it a third fixed puzzle piece, or is it simply the area left under the apparent diagonal? That question is the key to the trick shown here.
The Missing Data Page Answer
The yellow is remaining area, not a fixed piece. Only the red and teal wedges have been moved. Their slopes are 3/8 and 2/5. In decimals, that is 0.375 and 0.4. Because those numbers differ, the broken diagonal is not one straight line. The two outlines are not the same triangle, even though the grid invites you to read them that way.
The white cell in the lower picture is paid for by a thin change in area along the bent edge. Nothing appears from nowhere. The colours are honest; the quick assumption that both outlines are identical is the part that fails.
I enjoy this one because the error is so small and so persuasive. We often see a straight-looking line, a round-looking number or an almost-matching total and stop checking. A grid does not guarantee that our eye has measured the geometry correctly.
No SQL Server engine is involved in this drawing. The database connection is the habit it teaches: when a count feels impossible, name the assumption and measure it. I would rather discover a tiny slope difference in a Sunday picture than a missing row in a Monday report.
Log in
