There are all good points, and I tend to agree. But I don't think win32 as such is/was a problem. As you rightfully point out IE (HTML+JS) ran just fine on top

There are all good points, and I tend to agree. But I don't think win32 as such is/was a problem. As you rightfully point out IE (HTML+JS) ran just fine on top of that environment, as did Java (visual J++ anyone?) and most of the other alternative layout/programming/etc environments. So while MFC (which was a terrible wrapper) was trash, that wasn't true of many of the other win32 based wrappers. Like for example visual basic/VBA which they killed to drive adoption of .net, another layer on top. So they killed three hugely popular win32 alternatives (VB6+, Visual J++, and IE) all within just a few years. So I don't think win32 was a problem, in fact to this day it still has one of the best I/O, threading, event blocking, interface that exists as a core OS API. And as a GUI toolkit, its a bit low level, but that's fine too because it was flexible enough to allow things to be layered on top, or even with the Direct* APIs bypassed completely (direct2d anyone?). The GUI toolkits problems were mostly things it inherited from win16 (single event collector, lack of implicit threading support, etc). But while those are listed as problems, what most people fail to mentally merge, is that those same problems exist in the most "modern" environment people are programming in regularly too (aka DOM based javascript, which is basically single threaded, while not looking like it). Just about the entire win32 GUI programming problems can be summarized with a rule known for 30+ years. Don't block the WM_ event handler by doing "work" in it.