Developing for Windows seems to be a bit of a nightmare, at least according to Microsoft, so they’re trying to make the lives of developers easier with a new tool called winapp.

The winapp CLI is specifically tailored for cross-platform frameworks and developers working outside of Visual Studio or MSBuild. Whether you are a web developer building with Electron, a C++ veteran using CMake, or a .NET,  Rust or Dart developer building apps for Windows, the CLI can streamline the complexities of Windows development – from setting up your environment to packaging for distribution. This makes it significantly easier to access modern APIs – including Windows AI APIs, security features and shell integrations – directly from any toolchain.

Windows development often involves managing multiple SDKs, creating and editing multiple manifests, generating certificates and navigating intricate packaging requirements. The goal of this project is to unify these tasks into a single CLI, letting you focus on building great apps rather than fighting with configuration. While the CLI is still in its early days, and there are many Windows development scenarios still in the works, we’re sharing this public preview now to learn from real usage, gather feedback and feature requests, and focus our investments on the areas that matter most to developers.

↫ Nikola Metulev at the Windows Blogs

For instance, run the command winapp init at the root of your project, and winapp will download the proper SDKs, create manifest files, etc., all automatically. You can also generate the correct certificates, easily create MSIX packages, and more. The tool is available through winget and npm (for Electron projects), but is still in preview, with the code available on GitHub.

So Markdown is this Lightweight Markup Language. Everyone (relative; among programmers, writers, and other “power-users”) uses it. LLMs use it. So it’s destined to eat the world. But it doesn’t mean Markdown is good.

↫ Artyom Bologov

We have these crazy fast and complex computers, but I’m still supposed to style text with obscure, arbitrary symbols, like an animal? We invented WYSIWYG decades ago, and our computers should be able to figure out how to properly share styled/unstyled text without us users having to learn markup languages using arcane symbols that require weird claw grips to type.

The widespread use of Markdown is not indicative of its merits; it merely underlines the utter failure of the computing industry to fix basic problems.

If you have any interest in SGI’s IRIX or used IRIX back when it was still current, you’re undoubtedly aware of Nekoware, a collection of freeware for IRIX, maintained and kept up-to-date as much as possible. After stagnating in 2015 and a few failed restarts and some infighting (apparently), the project finally relaunched somewhere last year, and a new quarterly release was pushed out.

Nekoware 2025Q4 is a clean break from previous releases, and requires that users fully remove any traces of previous installations. It contains the kinds of packages these freeware/open source collections for classic UNIX tended to contain: tons of common open source libraries, command-line tools, and more, including a few emulators. You’ll need IRIX 6.5.21 or newer, running on at least a MIPS R5000 processor-equipped SGI machine.

Planning for and work on the next release is already underway, and a brand new Nekoware SDK has been released as well, which provides bootstrap functionality and addresses the problem of having to build Nekoware on unstable IRIX environments. Seeing Nekoware resurrected is great news for the surprisingly active IRIX community.

As a HP-UX user, I feel some envy.

In January 1976, MOS Technologies presented a demonstration computer for their recently developed 6502 processor. MOS, which was acquired by Commodore later that year, needed to show the public what their low-cost processor was able to. The KIM-1 single board computer came fully assembled with an input keypad, a six-digit LED display, and complete documentation. It was intended for developers, but it turned out that at a price of only $249 the computer was the ideal playground for hobbyists, who could now afford a complete computer.

The unforgettable Jim Butterfield described it like this back in 1999:

But suddenly there was the KIM-1. It was fully assembled (although you had to add a power supply). Everybody’s KIM-1 was essentially the same (although the CPU added an extra instruction during the KIM-1’s production life).

And this created something that was never before part of the home computer phenomenon: users could quite happily exchange programs with each other; magazines could publish such programs; and people could talk about a known system.

We knew the 6502 chip was great, but it took quite a while to convince the majority of computer hobbyists. MOS Technology offered this CPU at a price that was a fraction of what the other available chips cost. We faced the attitude that “it must be no good because it’s too cheap,” even though the 6502, with its pipelined architecture, outperformed the 8080 and the 6800.”

↫ Jim Butterfield

Even though there would soon be better equipped and faster home computers (mostly based on the 6502) and the KIM-1 vanished from the collective minds, the home computer revolution started  50 years ago in Jan 1976. Hans Otten keeps the memory alive on his homepage, where you can find a full collection of information about single-board computers and especially the KIM-1.

The 9020 is a fascinating system, exemplary of so many of the challenges and excitement of the birth of the modern computer. On the one hand, a 9020 is a sophisticated, fault-tolerant, high-performance computer system with impressive diagnostic capabilities and remarkably dynamic resource allocation. On the other hand, a 9020 is just six to seven S/360 computers married to each other with a vibe that is more duct tape and bailing wire than aerospace aluminum and titanium.

↫ J. B. Crawford

I was hooked from beginning to end. An absolutely exceptional article.

I totally forgot you could do this, but back in the Windows 9x days, you could hold down shift while clicking restart, and it would perform a sort-of “soft” restart without going through a complete reboot cycle. What’s going on here?

The behavior you’re seeing is the result of passing the EW_RESTART­WINDOWS flag to the old 16-bit Exit­Windows function.

What happens is that the 16-bit Windows kernel shuts down, and then the 32-bit virtual memory manager shuts down, and the CPU is put back into real mode, and control returns to win.com with a special signal that means “Can you start protected mode Windows again for me?”

The code in win.com prints the “Please wait while Windows restarts…” message, and then tries to get the system back into the same state that it was in back when win.com had been freshly-launched.

↫ Raymond Chen

There’s a whole lot more involved behind the curtains, of course, and if conditions aren’t right, the system will still perform a full reboot cycle. Chen further notes that because WIN.COM was written in assembly, getting back to that “freshly-launched” state wasn’t always easy to achieve.

I only vaguely remember you could hold down shift and get a faster “reboot”, but I don’t remember ever really using it. I’ve been digging around in my memories since I saw this story yesterday, and I just can’t think of a scenario where I would’ve realised in time that I could do this.

Have you noticed how it seems like how the “light mode” of your graphical user interface of choice is getting lighter over time? It turns out you’re not crazy, and at least for macOS, light mode has indeed been getting lighter.

You can clearly see that the brightness of the UI has been steadily increasing for the last 16 years. The upper line is the default mode/light mode, the lower line is dark mode. When I started using MacOS in 2012, I was running Snow Leopard, the windows had an average brightness of 71%. Since then they’ve steadily increased so that in MacOS Tahoe, they’re at a full 100%.

↫ Will Richardson

While this particular post only covers macOS, I wouldn’t be surprised to discover similar findings in Windows, GNOME, and KDE. The benefit of using KDE is that it’s at least relatively easy to switch colour schemes or themes, but changing colours in Windows is becoming a hidden feature, and GNOME doesn’t support it out of the box at all, and let’s not even get started about macOS.

I think “light mode” should be “grey mode”, and definitely lament the lack of supported, maintained “grey modes” in both KDE and GNOME. There’s a reason that graphical user interfaces in the era of extensive science-based human-computer interaction research opted for soft, gentle greys (ooh, aah, mmm), and I’m convinced we need to bring it back. The glaring whites we use today are cold and clinical, and feel unpleasant to the point where I turn down the brightness of my monitor in a way that makes other colours feel too muted.

Or perhaps I’m out of touch.

The other day I was asked to update the visual design of radio buttons in a web app at work. I figured it couldn’t be that complicated. It’s just a radio button right?

<input type="radio" name="beverage" value="coffee" />

Boom! Done. Radio buttons are a built-in HTML element. They’ve been around for 30 years. The browser makes it easy. Time for a coffee.

↫ Paul Hebert

If only it was that simple – cue the rollercoaster ride. What an absolutely garish state of affairs lies behind this simple radio button on a website. I’m also well aware OSNews has a certain amount of complexity it might not need, and while I can’t fix that, I am at least working on a potential solution.

There’s cursed computing, and then there’s cursed computing. It turns out that you can render GNOME’s windows with the compositor from Windows 7, dwm.exe. Yes.

tl;dr of how this clusterfuck works: this is effectively just x11 forwarding an x server from windows to linux. the fun part is a) making gnome run with an already existing window manager (namely dwm.exe lol), b) making gnome run over x11 forwarding (it is Not a fan, last time it tried running gnome on windows this is what broke it and made it quit trying), and c) actually ripping out parts of the gnome compositor again to make dwm instead of gnome render window decorations to achieve ✨️aero gnome✨️

↫ ⬡-49016 at Mastodon

This is already one of the most cursed things I’ve ever seen, but then things got so much worse. How about Windows 7’s dwm.exe, but composited by GNOME?

• firefox and vscode are rendered by gnome
• the start menu and gadgets are rendered by dwm, and then composited by gnome
• ghostty, which literally goes above and beyond the gadgets (which you cannot do by just streaming one compositor to the other), is rendered by gnome
• and the cherry on top is gnome-control-center, which exclusively runs in gnome sessions, being managed by gnome, rendered by dwm, and composited by gnome again

this is powered by about 7 layers of duct tape and a couple hundred lines of the worst C the world has ever seen

↫ ⬡-49016 at Mastodon

I need an adult.

Virtualisation is a lot older than you might think, with (one of?) the first implementation(s) being IBM’s VM/CMS, the line of operating systems that would grow to include things like System/370, System/390, all the way up until IBM/Z, which is still being developed and sold today; only recently IBM released the IBM z17 and z/OS 3.2, after all.

The VM series of operating systems is designed exclusively for mainframes, and works by giving every user their own dedicated virtual machine running on top of the Control Program, the hypervisor. Inside this virtual machine the user can run a wide variety of operating systems, from the simple, single-user classics like IBM’s Conversational Monitor System, to more complex systems like Linux or AIX.

Early versions of VM were released as open source and are now in the public domain, and enthusiasts have continued to build upon it and expand it, with the latest incarnations being the VM/370 Community Edition releases. They contain the Control Program and Conversational Monitor System, augmented by various fixes, improvements, and other additions. You can run VM in an emulator like Hercules, and continue on from there – but what, exactly, can you do with it?

That’s where Fun things to do with your VM/370 machine comes in. This article will give you an introduction to the system, and a number of first and later steps you can take while exploring this probably alien environment. If you’ve always dreamt of using an early IBM mainframe, this is probably the easiest way to do so, because buying one is a really, really bad idea.

This is a book intended to teach someone the Java language, from scratch.

You will find that the content makes heavy use of recently released and, for the moment, preview features. This is intentional as much of the topic ordering doesn’t work without at least Java 21.

↫ Modern Java GitHub page

Some light reading for the weekend. This sure is one hell of a detailed book.

Since Wayland is still quite new to a lot of people, it’s often difficult to figure out which features the Wayland compositor you’re using actually supports. While the Wayland Explorer is a great way to browse through the various protocols and their status in various compositors, there’s now an easier way. The Wayland protocols table makes it very easy to see what your favourite compositor supports, which compositors support the protocol you really want supported before leaving X11 behind, and much more.

Roughly speaking, there’s a set of stable core Wayland protocols, as well as a slew of unstable core Wayland protocols that are still in development, but may already be supported by various compositors. On top of that, compositors themselves also have a ton of protocols they themselves introduced and support, but which aren’t supported by anything else – yet, as they may be picked up by other compositors and eventually become part of Wayland’s core protocols.

Keeping tabs on specific protocols and their support status is mostly only interesting for developers and people with very specific needs, since mature compositors provide a complete set of features most users never have to worry about. Still, that doesn’t mean there aren’t really cool features cooking, nor does it mean that one specific accessibility-related protocol isn’t incredibly important to keep track of. These websites provide an easy way to do so.

Speaking of NixOS’ use of 9P, what if you want to, for whatever inexplicable reason, use macOS, but make it immutable? Immutable Linux distributions are getting a lot of attention lately, and similar concepts are used by Android and iOS, so it makes sense for people stuck on macOS to want similar functionality. Apple doesn’t offer anything to make this happen, but of course, there’s always Nix.

And I literally do mean always. Only try out Nix if you’re willing to first be sucked into a pit of despair and madness before coming out enlightened on the other end – I managed to only narrowly avoid this very thing happening to me last year, so be advised. Nix is no laughing matter.

Anyway, yes, you can use Nix to make macOS immutable.

But managing a good working environment on macOS has long been a game of “hope for the best.” We’ve all been there: a curl | sh here, a manual brew install there, and six months later, you’re staring at a broken PATH and a Python environment that seems to have developed its own consciousness.

I’ve spent a lot of time recently moving my entire workflow into a declarative system using nix. From my zsh setup to my odin toolchain, here is why the transition from the imperative world of Homebrew to the immutable world of nix-darwin has been both a revelation and a fight.

↫ Carette Antonin

Of course it’s been a fight – it’s Nix, after all – but it’s quite impressive and awesome that Nix can be used in this way. I would rather discover what electricity from light sockets tastes like than descend into this particular flavour of Nix madness, but if you’re really sick of macOS being a pile of trash for – among a lot of other things – homebrew and similar bolted-on systems held together by duct tape and spit, this might be a solution for you.

If you’re only even remotely aware of the operating system Plan 9, you’ll most likely know that it takes the UNIX concept of “everything is a file” to the absolute extreme. In order to make sure all these files – and thus the components of Plan 9 – can properly communicate with one another, there’s 9P, or the Plan 9 Filesystem Protocol. Several Plan 9 applications are 9P file servers, for instance, and even things like windows are files. It’s a lot more complicated than this, of course, but that’s not relevant right now.

Since Plan 9 wasn’t exactly a smashing success that took the operating system world by storm, you might not be aware that 9P is actually implemented in a few odd places. My favourite is how Microsoft turned to 9P for a crucial feature of its Windows Subsystem for Linux: accessing files inside a Linux VM running on Windows.

To put it briefly: a 9P protocol file server facilitates file related requests, with Windows acting as the client.

We’ve modified the WSL init daemon to initiate a 9P server. This server contains protocols that support Linux metadata, including permissions. A Windows service and driver that act as the client and talks to the 9P server (which is running inside of a WSL instance). Client and server communicate over AF_UNIX sockets, since WSL allows interop between a Windows application and a Linux application using AF_UNIX as described in this post.

↫ Craig Loewen at Microsoft’s Dev Blogs

This implementation is still around today, so if you’re using Windows Subsystem for Linux, you’re using a little bit of Plan 9 as glue to make it all come together. Similarly, if you’re using QEMU and sharing files between the host and a VM through the VirtFS driver, you’re also using 9P. Both NixOS and GNU Guix use 9P when they build themselves inside a virtual machine, too, and there’s probably a few other places where you can run into 9P.

I don’t know, I thought this was interesting.