Microsoft Windows

3 Articles

A Windows Control Panel Retrospective Amidst A Concerning UX Shift

September 3, 2024 by 153 Comments

Once the nerve center of Windows operating systems, the Control Panel and its multitude of applets has its roots in the earliest versions of Windows. From here users could use these configuration applets to control and adjust just about anything in a friendly graphical environment. Despite the lack of any significant criticism from users and with many generations having grown up with its familiar dialogs, it has over the past years been gradually phased out by the monolithic Universal Windows Platform (UWP) based Settings app.

Whereas the Windows control panel features an overview of the various applets – each of which uses Win32 GUI elements like tabs to organize settings – the Settings app is more Web-like, with lots of touch-friendly whitespace, a single navigable menu, kilometers of settings to scroll through and absolutely no way to keep more than one view open at the same time.

Unsurprisingly, this change has not been met with a lot of enthusiasm by the average Windows user, and with Microsoft now officially recommending users migrate over to the Settings app, it seems that before long we may have to say farewell to what used to be an intrinsic part of the Windows operating system since its first iterations. Yet bizarrely, much of the Control Panel functionality doesn’t exist yet in the Settings app, and it remain an open question how much of it can be translated into the Settings app user experience (UX) paradigm at all.

Considering how unusual this kind of control panel used to be beyond quaint touch-centric platforms like Android and iOS, what is Microsoft’s goal here? Have discovered a UX secret that has eluded every other OS developer?

Continue reading “A Windows Control Panel Retrospective Amidst A Concerning UX Shift” →

Hybrid Binaries On Windows For ARM: ARM64EC And ARM64X Explained

March 28, 2024 by 45 Comments

With ARM processors increasingly becoming part of the desktop ecosystem, porting code that was written for x86_64 platforms is both necessary and a massive undertaking. For many codebases a simple recompile may be all it takes, but where this is not straightforward Microsoft’s ARM64EC (for ‘Emulator Compatible’) Application Binary Interface (ABI) provides a transition path. Unlike Apple’s ‘Fat Binaries’, this features hybrid PE executables (ARM64 eXtended, or ARM64X) that run mixed ARM64EC and x86_64 binary code on Windows 11 ARM systems. An in-depth explanation is provided by one of the authors, [Darek Mihocka].

ARM64EC was announced by Microsoft on June 28, 2021 as a new feature in Windows 11 for ARM, with more recently Qualcomm putting it forward during the 2024 Game Developers Conference (GDC) as one reason why high-performance gaming on its Snapdragon SoCs should be much easier than often assumed. Naturally, this assumes that Windows 11 is being used, as it contains the x86_64 emulator with ARM64EC support. The major difference between plain ARMv8 and ARM64EC code is that the latter has changes on an ABI level to e.g. calling conventions that ease interoperability between emulated x86_64 and ARM64 code.

Although technologically impressive, Windows 11’s marketshare is still rather small, even before looking at Windows 11 on ARM. It’ll be interesting to see whether Qualcomm’s bravado comes to fruition, and make ARM64EC more relevant for the average software developer.

WoWMIPS: A MIPS Emulator For Windows Applications

February 17, 2024 by 12 Comments

When Windows NT originally launched it had ports to a wide variety of platforms, ranging from Intel’s x86 and i860 to DEC’s Alpha as well as the MIPS architecture. Running Windows applications written for many of these platforms is a bit tricky these days, which [x86matthew] saw as a good reason to write a MIPS emulator. This isn’t just any old emulator, though. It maps 32-bit Windows applications targeted at the MIPS R4000 CPU to an x86 CPU instead. Since both platforms run in a little-endian, 32-bit mode, this theoretically should be a walk in the park.

The use of the Windows PE executable format is also the same, so the first task was to figure out how to load the MIPS PE binary in a way that made sense for an x86 platform. This involved some reverse-engineering of the MIPS ntdll.dll file to figure out how relocations on that platform were handled. Following this, the mapping of the instructions of the R4000 CPU to the (CISC) x86 ISA was pretty easy. Only Floating Point Unit (FPU) support was left as a future challenge. Memory access was left as direct access, meaning no sandboxing or isolation, for simplicity’s sake.

The final task was mapping the native API calls, which call almost directly into the underlying host Windows OS’s API, with a bit of glue logic. With all of this done, Windows NT applications originally written for 1990s MIPS ran just fine on a modern-day x86_64 PC running Windows — as long as you don’t need an FPU (for now).