There's one untruth in that post. Win32 will be updated for Longhorn. Sure, some of the new stuff is managed code only, but there's plenty of Win32 (or Win64, I suppose) stuff too. Microsoft recognizes that there's still quite a lot of people out there
that use plain old C++. Heck, even MS internally still develops a lot of unmanaged code.
Also, I agree Managed C++ is unmanageable (pun intended), but C++/CLI really is a lot better, and also standardised. And you can, using COM Interop, call managed code from unmanaged code as well, although you're somewhat limited when doing that.
Looking at the evolution of Microsoft OS APIs is pretty interesting. It reflects the way people's method of programming has changed.
In the DOS and Windows 3.11 and older days, the API was predominantly interrupt calls. This reflected the fact that most DOS developers of the day programmed in assembly. Windows, especially the Win32 API (designed for NT, later ported to the 9x kernel), was designed in a time when everybody used C. So it's meant for C. Of course, the big drawback of it is the fact that C has no namespaces, so we get CoMarshalInterThreadInterfaceInStream and similar function names. When the OO movement and C++ became more popular, the gap was filled with MFC and ATL. And today, the latest and greatest development in software engineering processes is considered to be Component Based software engineering. This is what .Net is based off.
And as for frameworks, frameworks is just a fancy word for API. You always need some kind of "framework". You say you can write your own frameworks, and I'm not saying you cannot, but you're always building on top of an existing "framework", whether it be the C++ standard library, the POSIX API, the Win32 API, or whatever. The fact that the .Net Framework as an API is more extensive than just a set of operating system services is merely a convenience. It sort of a merge between what's provided by both the C++ Standard Library (and with the coming of generics in Whidbey this to some degree includes the STL) and the Win32 Library. This however doesn't stop me from writing my own linked lists and trees and whatever.
If you write for Windows, you will have to use some API that accesses the Windows system. Whether you use it directly or indirectly (like with MFC) doesn't matter. Whether you use the plain Win32 API or .Net doesn't matter.
If you write for Linux, you will have to use some API that accesses the Linux system. Whether you use POSIX, X, or whatever other APIs are available, it doesn't matter. You will need at least one.
I don't know if Linux maybe has more different APIs for the same thing or not. I'm not that well-versed in Linux.
But I don't believe that fundamentally you're more limited as a programmer in Windows than in Linux. Sure, there's some stuff you can't do in Windows that you can do in Linux, but I'm sure the same is true for the reverse. And which one wins depends entirely on personal preference and the job at hand. There's not a single one "winner" by default.
There's one untruth in that post. Win32 will be updated for Longhorn. Sure, some of the new stuff is managed code only, but there's plenty of Win32 (or Win64, I suppose) stuff too. Microsoft recognizes that there's still quite a lot of people out there that use plain old C++. Heck, even MS internally still develops a lot of unmanaged code.