WinRT: is it really about calling WIN32 (wrapped in COM (exposed as .NET)) via a proprietary extension of C++?
That looks like a lot of wrappers and layers between the developer and the actual functionality. Does anyone trying to go with it stand a chance at profoundly understanding the ecosystem (if his last name isn't "Petzold")?
The short answer is yes, at least sort of.
The longer answer is that the last MS operating system a significant number of programmers understood very well was MS-DOS 6.x. Windows 3.x was fairly understandable as long as you looked at it as a number of pieces (MS-DOS, DOS extender, Windows kernel, Windows UI) but most people didn't really bother.
For better or worse, however, all the implementations of Win32 have been somewhat convoluted. Although they tried to make it less visible, Windows 95 still had a copy of MS-DOS, a DOS extender, and a rather fragmented implementation of Windows itself, split between a heavily modified version of the 16-bit kernel from Windows 3.x, and a new 32-bit interface -- and some fairly significant pieces of 32-bit code too.
Windows NT was a bit more straightforward, but it was originally written as something like a microkernel with three subsystems (Win32, POSIX, OS/2). The Win32 subsystem always enjoyed a special status though, so it had its own rules (or they broke a lot of rules, depending on your viewpoint). In any case, very few people really understood the system well at a truly fundamental level -- and most application programmers had (at most) only a peripheral, vague awareness of there being a "native API" that a few of the true wizards (and here we're talking people like David Solomon and Bryce Cogswell, not Charles Petzold) used to do things that looked (and often were) impossible using only Win32.
.NET added yet another layer -- and rather an "uneven" one at that. That's not to the say the interface visible to the user was uneven, but that its "bottom" side where it interfaced to the system was quite uneven -- some parts talked to Win32, other parts to DirectX, still others to various COM interfaces, etc. In short, a lot of people understood how to use .NET (at least reasonably well) but probably fewer than one in a thousand really understood all its internals very well.
I would say, however, that that's exactly as it should be. One of the basic points of creating abstractions is to avoid everybody having to learn all the ugly internal details of how everything really works. The problem, at least in my opinion, is rarely the existence of one layer after another getting between his code and how things really work. Rather, the problem is primarily with poor abstractions that don't do nearly enough to keep a programmer from needing to know about the underlying details to be able to get the job done.
MFC would be a classic example -- to use it at all well, you pretty much needed to already know how to write Win32 programs without it. In some ways, it made understanding even more difficult by adding a fair number of wrinkles of its own on top of Win32 itself. If you knew enough about MFC itself and about its underpinnings in Win32, it could actually save you quite a lot of work -- but it required a lot of extra study to understand it well enough to get much benefit. It's almost universally reviled, because most people never understood enough to get much (if any) benefit.
It's a bit difficult at this point to figure out exactly where WinRT will land in the great scheme of things. I think it's safe to say that Microsoft has gained a lot of experience in defining and presenting abstractions that seem simple enough, and work consistently enough, that it's fairly easy to use them without really understanding them very deeply -- but the consistency (especially) lets understanding at a relatively superficial level seem like it's much deeper than it really is, because the external appearance of how they work is quite consistent with a fairly simple mental model (at least in most cases).
I suspect WinRT will be pretty much more of the same -- if you insist on trying to figure out all the details of how everything really works, you'll probably never get much of anything done. Microsoft has enough programmers working on it, that they can create (and hide) internal complexity a lot faster than almost any one person can hope to comprehend it. At the same time, if you're accustomed to working with .NET, not much will change -- it'll work consistently enough with a fairly simple model that you'll be able to treat that model as if it was how things really worked (even though it'll usually vary from partially to almost completely incorrect, and there will be a lot more happening behind the scenes than most programmers realize or want to think about).
int 21h services ;) Btw what about Linux/POSIX, isn't really easier to get to know (both conceptually and due to sources availability)?
Its partly what you say - it is a native API that (no doubt) does wrap much of the existing code, and that code will be part win32, part COM. As Microsoft has explicitly said its native, then it won't be wrapping any .NET code, unless that was wrapped native code anyway.
You can access it using a standard C++ system: its called WRL and is like the old ATL templates and smart pointer classes. At least it doesn't use the stupid and non-standard ^ syntax that C++/CX uses.
A selling point of WinRT is that it is a 'clean' API, and that the nasty implementation details will be hidden underneath it - so you don't have to worry about writing part win32, part COM API depending on which MS team wrote which new API. However, MS has a history of changing things, so while its nice and clean today, you should expect Microsoft to complicate it up over time.
Name ends with "tzold"as in "Petzold," the Windows programming guru. He's asking if it will be possible for mere mortals to understand the system with its multiple layers and wrappers.