I agree, another example is the line ‘lots of things had to be done by hand’. I think a more human narrative would be describing the discovery that thing X that we take for granted was missing and tell the story of figuring it out.

Giving them the benefit of the doubt though, perhaps they were aiming for brevity.

I respect your tastes but, as a human, I like the objectivity in the article. I actually couldn't care less about the backstory and I tend to skip articles that wander around without getting to the point. I prefer to read a book when I want that.

In other words, different people sometimes want different things...

Some games that ran on Vista, can run under Wine, but not on Windows 11. The backwards compatibility story has changed in the last few years.

> I had never run into compatibility issues with programs or games built for older Windows version

Try running a real-mode Windows program on a modern version of Windows.

A ton of things broke for me when they restricted writing to the program files directory with XP.

Lots of old games dont work anymore, but you can still run them by compabtibility modes.

16 bit programs dont seem to work at all though - you need wine or dosbox

I've been using otvdm (aka winevdm) and it is very good. It works like the original ntvdm did when running on non-x86 platforms. It emulates the processor and translates 16-bit api calls into 32-bit api calls so things work as you'd expect.

https://github.com/otya128/winevdm

winevdm allows me to run all 3.11 apps on windows :) Its amazing - works even for 32bit era.

It might be stable, but when Vista came around, there was a huge change to how Window Rects worked. Something so basic got a big breaking change.

Before Vista, there were two rects, the Window Rect (which included the title bar, menu bar, and the resize border), and the Client Rect, which includes the work area of the window.

Once Vista came around, Window Rects became completely different. After a window becomes shown, the Window Rect expands outwards (around 8 pixels or so) to include a drop shadow and larger resize area. So it's no longer just Window Rect and Client Rect, now there's a third rect called the DWM Extended Frame Bounds, and that corresponds to what the Window Rect used to be on earlier versions of Windows.

To try to make things more compatible, the Window Rect will behave like older versions of windows before the window is shown, and there is no way to access DWM Extended Frame Bounds before a window is shown. But once a window is shown, your Window Rect is bigger now, and in a different location. Programs that try to move the window will instead move it to a location 8 pixels down-right of the target location. Programs that try to resize the window will instead make it 16 pixels too narrow and short. If a program tried to remember the difference between the Client Rect and Window Rect, suddenly that number changed just because the window got shown.

So newer programs need to ask for the DWM Extended Frame Bounds to get an idea of where their window actually is. And it also happens that DWM Extended Frame Bounds are not DPI adjusted, but the Window Rect and Client Rect are. So you need to DPI adjust it into a coordinate system which matches the Window Rect. Now you finally have your three rects, and can properly place a window somewhere on the screen.

To be fair, the C standard for types is pretty dreadful. How big is an int? A long? Want an integer type that matches the size of a pointer? <stdint.h> did fix a lot of the issues, but people targeting an early C version don't have this header available.

Windows type names have stayed mostly stable since Win32, but some of them are still misleading. DWORD, UINT and ULONG are all 32-bit unsigned integer types. But in C#, "ulong" is a 64-bit type despite having the same name, this leads to making mistakes when transcribing Win32 type names into C# code.

Windows came up with its type names before <stdint.h> existed, so you won't see any uint32_t in there, just DWORD.

Use Windows Implementation Library to clean things up and get some RAII on handle types: https://github.com/microsoft/wil

It's not (reasonably) possible to do so though, because it would break so, so much legacy code. The only thing you can do is to add new functionality (e.g. the difference between A and W APIs - A is ASCII, W is UTF-16) or to shoehorn crap onto existing interfaces (again, A APIs to which you pass UTF-8 and pray for the best), but you cannot delete any publicly exposed API or modify existing types.

Who exactly in the Linux world is supposed to get paid wonderfully to keep mountains of old cruft and technical debt in working order? Not to say I'm insensitive to your point, but when whole UI frameworks are amateurs' passion-projects, the practical burden of maintenance has very real implications. That's essentially the whole story behind the Linux desktop losing Xorg.

Thanks, we (Linux/BSD) users cannot bring up this topic often enough.

I totally understand, that it cannot work unless money is there, which simply is not, in the Linux desktop world. Compatibility is expensive, hard work and not much fun.

I do not think, this will ever change, in the end, the web/Electron has won, desktop operating systems are less important compared to mobile, so who should invest in a stable GUI platform for Linux?

By now, basically all applications I rely on are CLI programs (posix), web or Electron and a few simple GUI tools (PDF viewer, ...) which can easily replaced.

How is the saying: If you want a portable GUI application for Linux, target Win32 and run it via Wine.

OSS is essentially more chaotic as everyone as his/her own ideas. It’s not too different in a corporation but when someone is in control it’s easier to centralize things.

Ah but what about (dun dun dun) “innovation”