Don't forget the all-important last step: abruptly killing the product - no matter how popular or praiseworthy it is (or heck: even profitable!) if unnamed Leadership figures say so; vide: killedbygoogle.com
The engine itself isn’t gutted - it’s full of functionality that was never lost. MS just (correctly) reasoned that transparency effects in the UI - introduced in Vista simply to show-off the capabilities of the DWM compositor - ultimately detract from a good UI.
From what I remember it lost the ability to render rounded window corners, because while Windows 8 msstyle themes existed they all had the hideous boxed corners that clashed hard with many looks.
I don’t agree that transparency is always a detractor. Judicious use can be a net positive, but it doesn’t work for all themes and there should be an option to turn it off. Personally I didn’t find the W7 variation of Aero to be bad at all.
> From what I remember it lost the ability to render rounded window corners,
...I'm guessing you haven't used Windows 11?
--------
By "rounded corners" are you referring to rounded-off corners in the nonclient area (such that the hWnd's rect is not clipped at all)? If so, then no: those would be rendered using a 9-grid[1] and have always been supported.
If you're referring to how so many fan/community-made msstyles for Windows 10 retain the sharp corners, I understand that's not a limitation of DWM or msstyles, just more that you need to do a lot of legwork when defining nontrivial corners in an msstyles theme; it can be done (there are plenty of examples online, e.g. look for Windows XP's style ported to Windows 10), it's just that most people don't go that far.
-----
[1] In msstyles, the 9-grid defines how a rectangular bitmap is stretched/scaled/tiled to fill a larger area; it's very similar to how CSS image borders are defined with `border-image-slice`.
I’m speaking specially about Windows 8/8.1. Obviously 11 and the new Fluent design language it brought don’t suffer the same issue.
Whatever the case, rounded corners on the titlebars and window chrome were common in XP/Vista/7 custom msstyles but were nowhere to be seen for 8/8.1 custom msstyles. It was one of the most frustrating aspects of that era of Windows for me.
please recall that 8bit color was the common capability for CRT displays at that time. Simple one bit display was also common. Any smooth transitions in gray or color had to use dithering, or be very clever in the way they chose the palate.
Certainly some historic credit goes to Motif, but, there are "levels to this game" .. Motif did not jump out as "wow that looks good" IMHO. Obviously NeXT was extreme in a different way.. sort of like a symphony orchestra more than an office machine.
It is genuinely entertaining to see people defend the dull and pedestrian UI in Windows 95.
Motif was also 3D, but the actual look of Windows 95/NT 4.0 clearly took some inspiration from NeXTSTEP and OPENSTEP, for example the window decorations.
I accept that's possible - if not likely (and everyone steals from each other!) - but even-so it only amounts to to the gunmetal-grey default colours and use of a 1px bevel/inset effect; because NS and NT3/NT4's UX/UI design and concepts are just so different otherwise.
...but I'm not personally convinced: instead, consider the demonstrable fact that similar engineering teams, working on similar problems, will independently come to substantially similar solutions; my favourite example to point to is how eerily-similar the Eurofighter Typhoon, Saab Gripen, and Dassault Rafale all look - even entirely indistinguishable at an air-show in-person - despite having zero shared pedigree - therefore it's possible that - given the constraints of desktop graphics hardware of the late-1980s/early-1990s - that a user-friendly desktop UI built around the concept of floating application windows - will all be similar in one way or another.
-------
My pet-theory for why that "Windows 95 1px bevel" look is so prevalent is because it suits working with premade UI graphics rasters/bitmaps using indexed-colors: for example, imagine a Windows-style Property Sheet dialog: prior to Windows 95, software would manually draw all of the elements of that dialog directly to the framebuffer (i.e. using unbuffered graphics) which was slow - ugly - and is the cmputer-equivalent of using a lavatory in a cramped bathroom actively undergoing renovations without any drywall/plastering). Even if there was enough vram for double-buffering it's still going to be slow: painting each and every button, checkbox (with the checkmark!) and tab header. So instead, many individual UI graphics elements could be prerendered (at design-time, hopefully by an actual artist), but not as single bitmaps for the entire dialog - but as an indexed color bitmap for each control type, so no slow/expensive draw/painting is required: only a simple blitbit for each checkbox, for example. Using an indexed-color bitmap based on a 4 or 8 colors palette (face, 3D light, 3D dark, transparent/BG; etc) means a single blob only a few hundred bytes in size can represent a chisel-cut bevelled checkbox - while integrating with whatever the user's preferred color scheme is.
----
....of course now we'll just build a UI in Electron, to hell with memory usage or integrating with the user's OS appearance settings. Le sigh.
As mentioned, Windows 95 uses more or less the same window decorations as NeXTSTEP - although with different semantics. What is minimize in NeXTSTEP is maximize in Windows 95 IIRC.
> my favourite example to point to is how eerily-similar the Eurofighter Typhoon, Saab Gripen, and Dassault Rafale all look - even entirely indistinguishable at an air-show in-person - despite having zero shared pedigree
Considering that France/Dassault was initially part of the Eurofighter / European Fighter Aircraft (EFA) project, I'm not sure if that's the best example to make your point.
By your timeline, it means Microsoft only had institutional taste for about 3-4 years. A tiny fraction of the company’s lifetime.
(If it helps, I do agree with you about those years being the most… design-coordinated: when Office felt like part of Windows)
(I like to think that Visual Studio 2026 proves that the company can still do good desktop UI design; but it doesn’t help that every major first-party product is now using their own silo’d UI framework; wither MFC and CommonControls, I guess)
I think there was a period from Windows 3.1 to somewhere during Windows 98 (maybe right up until the release of Office 97?) where both first-party and third-party Windows apps were all expected to be built entirely in terms of the single built-in library of Win32 common controls; and where Windows was expected to supply common controls to suit every need.
This was mostly because we were just starting to see computers supporting large bitmapped screen resolutions at this point; but VRAM was still tiny during this period, and so drawing to off-screen buffers, and then compositing those buffers together, wasn't really a thing computers could afford to do while running at these high resolutions.
Windows GDI + COMCTL32, incl. their control drawing routines, their damage tracking for partial redraw, etc., were collectively optimized by some real x86-assembly wizards to do the absolute minimum amount of computation and blitting possible to overdraw just what had changed each frame, right onto the screen buffer.
On the other hand, what Windows didn't yet support in this era was DirectDraw — i.e. the ability of an app to reserve a part of the screen buffer to draw on itself (or to "run fullscreen" where Windows itself releases its screen-buffer entirely.) Windows apps were windowed apps; and the only way to draw into those windows was to tell Windows GDI to draw for you.
This gave developers of this era three options, if they wanted to create a graphical app or game that did something "fancy":
1. Make it a DOS app. You could do whatever you wanted, but it'd be higher-friction for Windows users (they'd have to essentially exit Windows to run your program), and you'd have to do all that UI-drawing assembly-wizardry yourself.
2. Create your own library of controls, that ultimately draw using GDI, the same way that the Windows common controls do. Or license some other vendor's library of controls. Where that vendor, out of a desire for their controls to be as widely-applicable as possible, probably designed them to blend in with the Windows common controls.
3. Give up and just use the Windows common controls. But be creative about it.
#3 is where games like Minesweeper and Chip's Challenge came from — they're both essentially just Windows built-in grid controls, where each cell contains a Windows built-in button control, where those buttons can be clicked to interact with the game, and where those buttons' image labels are then collectively updated (with icons from the program's own icon resources, I believe?) to display the new game state.
For better or worse, this period was thus when Microsoft was a tastemaker in UI design. Before this period, early Windows just looked like any other early graphical OS; and after this period, computers had become powerful enough to support redrawing arbitrary windowed UI at 60Hz through APIs like DirectDraw. It was only in this short time where compute and memory bottlenecks, plus a hard encapsulation boundary around the ability of apps to draw to the screen, forced basically every Windows app/game to "look like" a Windows app/game.
And so, necessarily, this is the period where all the best examples of what we remember as "Windows-paradigm UI design" come from.
> On the other hand, what Windows didn't yet support in this era was DirectDraw — i.e. the ability of an app to reserve a part of the screen buffer to draw on itself (or to "run fullscreen" where Windows itself releases its screen-buffer entirely.) Windows apps were windowed apps; and the only way to draw into those windows was to tell Windows GDI to draw for you.
> This gave developers of this era three options, if they wanted to create a graphical app or game that did something "fancy":
> 1. Make it a DOS app.
This vaguely reminds me of WinG[0][1] - the precursor to DirectDraw. It existed only briefly ~ 1994-95.
My vague "understanding" of it was to make DOS games easier to port to Windows. They'd do "quick game graphics stuff" on Device Independent Bitmaps, and WinG would take care of the hardware details.
Sometimes the "any clickable area => make it a Windows control/button" works and sometimes it doesn't.
I talked with the programmer for the 16-bit Windows calculator app, calc.exe.
Any naive programmer with a first-reading of Charles Petzold's Programming Windows book would assume each button in the calculator app was an actual Windows button control.
Nope.
All those calculator buttons, back when Windows first shipped, used up too many resources.
Every major first party product has been using their own siloed UI framework since like 2003-ish. Visual Studio has always been one of the worst offenders. Sometimes the new UI components in a VS became the new normal for the rest of the first party stuff, but it was usually right about the time a new VS came out with a new paradigm. That's slowed a bit with the last bunch of VS releases being basically the same UI with different toolchains and default plugins, but it's still quite different from the rest of the OS. It's really pretty silly.
I think you mean US rolling news channels (specifically, Fox, MSNBC/MSNOW, etc)? Because there's plenty of "legacy" news I consume that certainly don't give me that impression (for example, The Economist). I suppose it matters that it's news that I'm paying for, as opposed to being free but ad-supported, and being print vs. TV - so they have different incentives and pressures.
I short the stock of companies whose leadership is wasting time posting to LinkedIn instead of… y’know… leading their org. The more they post the more I short. Similarly, the less-attached-to-reality the post is the more I short.
I wish I could say I’m making bank off this strategy - but pretty-much all the slopposters (and the most insufferable of the AI boosters) are all working for nonpublic firms, oh well.
Maybe not a winning strategy because a lot of public companies have a comms team that manages the CEO’s LinkedIn. Thereby saving the valuable time of the CEO themselves.
I think if an MRI was ever used for airport security screening it would cause more damage and disruption than the terrorist bombs it purports to detect.
Both. 1.5/3 T is standard, >3 T machines (such as 5 T from United Imaging) are becoming more popular (and affordable) and at the same time ultra low field ones keep improving and now they make some things that were impossible before now actually doable such as bed-side MRI (not in clinical practice of course, but there was nice engineering proof of concept with ultra low field MRI machine that could be powered by normal power outlet).
The idea behind the recent boom in low-field stuff is that you'd like to have small/cheap machines that can be everywhere and produce good-enough images through smarts (algorithms, design) rather than brute force.
The attitude on the research side is essentially "por qué no los dos?" Crank up the field strength AND use better algorithms, in the hopes of expanding what you can study.
I know nothing about the "industry" of MRIs, but from the physics side, (everything equal) more Tesla is better - at the end of the day, harder magnetic field gets you a stronger signal
For a $400 laptop?