As someone who's had to develop windows apps every few years, from Win16 to Windows 8, wow, I don't even know where to begin. Windows has always been a mess, l

As someone who's had to develop windows apps every few years, from Win16 to Windows 8, wow, I don't even know where to begin. Windows has always been a mess, long, long, long before CLR/.Net. The phrase "just work" came from the macintosh world, to contrast the experience you'd get on a mac versus the mess you had in the windows world with even the most trivial hardware devices (plug & pray) or apps (dll hell). I don't know where he got the idea that DOS apps "just worked" on windows -- MS spent a lot of money and effort getting the big apps to work when running on/in windows, but that effort really only helped with the big apps. Lotus 1-2-3 worked, but many apps wouldn't without setting up DOS-box settings. But, let's put all that away. Everyone's guilty of looking at the past through rose-colored lenses. OWL was actually quite nice. MS's response, MFC, was an awful bare-thin wrapper over the windows API -- and that pig needed a lot more lipstick. MS was right to dump it. The problem was, looking from in from the outside, MS had too many cooks in too many kitchens, trying to do everything as fast as possible. In response, documentation was always pretty bad (there was lots of it, but the quality's pretty low), the APIs were rarely clear or straightforward, and you ended up single-stepping your debugger to figure out what the APIs really did. Frankly, I think the APIs were always awful enough to warrant fixing, but they were never organized enough to do the real work in fixing it. It's not something you can grunt through, it requires a cohesive set of patterns, abstractions, mechanisms, and conventions. That kind of agreement just doesn't seem possible over such a large and contentious organization.