
I took about a week off after posting the previous update, and then the better part of the following week trying to figure out whether I could overwrite the GitHub repository for the single document version of WinUIpad somehow. I’m sure that’s possible, but I couldn’t make it work. So I decided to create a new GitHub repository for the multiple document/tab version of WinUIpad instead.
This was my March 2026 focus project, though work remains. As with other focus months, it will continue into the future, albeit at a slower pace. But I don’t want to lose track of what still needs to be done here. Fortunately, I listed most of the bugs and missing features in the previous article, so here I will simply describe what I’ve changed since.
This is difficult to remember, but in 2020 I paused writing my Programming Windows series—which later became the book Windows Everywhere—about halfway through the history because I had arrived at the .NET era and needed to cover that and technology, C#, and frameworks like Windows Forms and Windows Presentation Foundation (WPF). By that point, I had stopped actively developing software, so I wasn’t as familiar with .NET as I had been with previous Microsoft developer efforts. So I took some time—almost two years, as it turns out—to learn as much as I could. I started writing code in .NET, and the result was an app, eventually called .NETpad, that I’m still working to this day: WinUIpad is just the most modern version of that same app.
Even more difficult to remember, the Programming Windows series came about in part because I had had this thought that the central innovation of Visual Basic, and of the latter .NET-based frameworks that followed, was that one could spend most of their time creating a Windows app by constructing the UI—visually in VB, and then using XAML code in the .NET era—while the “glue” code that made it all work, the “code behind,” as Microsoft calls it, would be minimal. This turned out to be false, especially for more involved apps and in the .NET era when visually creating UIs became less feasible. But it fed my desire to create .NETpad (and then WinUIpad), multiple times, using multiple languages and frameworks. And here we are, almost seven years after I started that series and over six years after I created the first (Visual Basic.NET, Windows Forms, and .NET Framework-based) version of .NETpad.
I was pretty happy with my ability to recreate the Notepad of the day, and .NETpad even includes a few features, like theme support, that the original lacked. But there were a few more technical Notepad features I never figured out despite multiple attempts. Key among them are Notepad’s support for multiple line ending types and encoding formats, both of which are tied to interoperability with UNIX and UNIX-like systems and to the evolution of Windows itself. Today, almost anyone using Notepad will simply use the defaults—Windows-style line endings and the UTF-8 encoding format—and so I just gave up on these features. No version of .NETpad or WinUIpad ever supported saving text files with different line endings and encoding formats.
Well, thanks to Clairvoyance, the latest WinUIpad does now support both of these features. When I asked it to create a modern Notepad clone from scratch—it ended up using my codebase for most of that, as I later discovered—I was envisioning a solution to supporting multiple documents and tabs. And while it did provide that, it also came with some extras. Including, go figure, support for different line endings and encoding formats.
As I worked through the current rewrite of WinUIpad, I used my codebase(s) and the one Clairvoyance had made, comparing as I went and trying to choose what I felt was the better approach each time. But for line endings and encoding formats, there’s nothing to compare. There’s just the code that Clairvoyance made. Which I’ve looked over, of course. But I didn’t really change much because I had nothing material to offer here.
In this version of WinUIpad, there are line ending and encoding format buttons (that just look like text boxes) in the status bar, as per Notepad. But you can click them and select an option for each using a pop-up menu.

I also added similar sub-menus for both options under the app’s View menu. (I’m still working through what makes sense for the menus.) And though I considered adding these options to the settings page, too, I realized that these aren’t really app settings, they’re document settings, and there’s no need for that.

Interestingly, the code that supports these features didn’t require a helper source code file of any kind. Instead, all the code appears, somewhat redundantly, in the event handlers for the menu items and, separately, the status bar buttons. In the latter case, you click one of them and that pop-up menu appears so you can make the choice. And none of these things are retained between app runs because the line endings and encoding format are associated with documents, and the app (like Notepad) will always use Windows-style line endings and the UTF-8 encoding format for new documents by default.
There’s so much more to do, mostly minor in nature, and split between bugs and some missing features. But the difficult work, the blocker I faced for a year or more, is in this version of the app: It supports multiple documents and tabs. Finally. Now I just need to clean it up. So I will.
You can find the new WinUIpad on GitHub. I will keep it up-to-date now as I make fixes and add features.
With technology shaping our everyday lives, how could we not dig deeper?
Thurrott Premium delivers an honest and thorough perspective about the technologies we use and rely on everyday. Discover deeper content as a Premium member.