다음을 통해 공유

WinRT XAML for Serious Beginners – Where are we? Navigating Win32, MFC, GDI, GDI+, Windows Forms, WPF, Silverlight, Windows Runtime, WinRT and Windows Phone

  • 아티클

Wow, that’s a lot of acronyms and names! Of course, no one would expect people to know all of those. But in case you do know some of them, this post will help you make sense of how they’re related. And then we can move on to the things which are more relevant to us on our way to learning how to build modern Windows / Windows Phone apps.

The next few sections will help you get a better understanding of where these blog posts will take you.

Part 1: Windows Technologies – Yes, there’s a lot of them!

Windows_technologies

As is common with all diagrams that attempt to present a lot of information in a small amount of space, the diagram above is obviously a great simplification of reality, and is bound to be inaccurate if interpreted under the wrong light. It is not the ultimate diagram of Windows technologies. Rather, it is meant as a helpful visual aid to explain what I will be talking about in this and other posts. So don’t try to over-analyze it.

Just note that the red box contains several key technologies: WinRT XAML, the .NET Framework, the Windows Runtime and a portion of Win32. This bigger red box is usually what people are referring to when they say “Modern Windows Apps” (which includes Windows Phone apps as well, by the way). My posts in this blog will touch mostly on the smaller, shaded red box.

Part 2: XAML is used by several Microsoft technologies

xaml_platforms

XAML has been around for many years now, and it is used in many fundamental Microsoft technologies. In this blog, most of my posts will focus exclusively on XAML used with the Windows Runtime to build Windows 8.1 and Windows Phone apps.

Note, however, that if you’re searching online for help with XAML, you might find articles on Silverlight or WPF, which will usually not help you with WinRT XAML.

Part 3: Let’s make it more confusing – Windows RT!

ms_operating_systems

Once upon a time (2001) there was Windows XP. This was a version of the Windows Operating System, just like there had been Windows NT before it, and just like many years later there was Windows 8.1. Similarly, in 2012, Microsoft released Windows RT, which was a special version of Windows (based on Windows 8) that runs on ARM processors. The letters “RT” in this context don’t necessarily mean anything, and instead they simply denote this specific version of Windows.

The technologies used in building modern Windows Apps, however, are the same for all modern Microsoft Operating Systems: Windows 8.1, Windows Phone 8.1 and Windows RT all implement the Windows Runtime, which means that WinRT XAML works for all of them! .

The one thing to remember

If you take anything out of this post, let it be this: Windows Runtime is “a thing”. WinRT can be two things. Here’s what they mean

  • Windows Runtime: This is the modern façade of the Windows API’s which is used by modern apps. Whereas in the past we had Win32 API’s to call, modern apps now use mostly the Windows Runtime API surface to interact with the system. Whether those API’s still use Win32 or not under the surface is irrelevant in most cases.
  • WinRT can be either:
    • An abbreviation for “Windows Runtime”, as above; or
    • Windows RT, a version of Windows 8 optimized for ARM processors which was released in 2012. In this context, you could think that, just like there was “Windows NT” and “Windows XP”, there was “Windows RT”. The letters RT don’t necessarily mean anything in this context, but rather indicate this specific version of Windows (as “XP” and “NT” indicate other versions).

Wrapping up

The main reason to know the terms I mentioned on this topic is that they might show up in online searches as you look for answers to your app-building questions, and knowing how to tell whether the results you see are relevant to you or not is important and can save you hours of grief. As you’ll see, searching “XAML” on either Bing or Google will bring you results for WPF, Silverlight, Windows Runtime, WinRT and Windows Phone Silverlight, and not all of them will be helpful to you. Now you know!

I hope this post helps clear some of the confusion around the myriad of Microsoft technologies available for developers today. If you have any suggestions or feedback, please leave your comments below and I’ll do my best to address them in a timely manner.

In my next post I will provide some tips that have been very useful to me when searching online for answers to my app-building questions.

Going deeper – Some history for the curious among us

Once upon a time, the way to build a program that presented a graphical user interface (GUI) in Windows using Microsoft technologies would have been one of the following:

  • Write a C / C++ program with a WinMain() entry-point, where you call Win32 API’s to register your graphical Window, show it, and then start processing Windows messages that you receive (WM_PAINT, WM_MOUSEMOVE and hundreds / thousands others) and render things using GDI / GDI+.
  • Write a C / C++ program and leverage MFC to make is easier to show and manage dialogs and controls (Edit boxes, Static labels, Buttons, etc.) and also use the abstractions over GDI to render your graphics.
  • Write a .NET (VB.NET / C# / managed C++) program using Windows Forms, which offered a much easier way to have a GUI than using C / C++ and Win32 directly. The .NET framework did a great job of abstracting the complicated parts of Win32 interop for us and offered an easy-to-use layer on top of it. The resulting forms and dialogs, however, were still based on the same old Win32 controls and GDI / GDI+ rendering. If necessary, you could even go low-level and call Win32 API’s directly using P/Invoke and [DllImport] attributes.
  • Write a .NET (VB.NET / C# / managed C++) program using WPF to show visuals on the screen. This is where things first started to depart from the traditional Win32 / WinMain() / GDI paradigms. WPF programs can still use Win32 API’s if they want to, but they have their own way of rendering content to the screen and supports layering, transparency, even animations out of the box. It was a very nice improvement to the old ways, and it uses XAML (although it’s somewhat different than WinRT XAML).
  • Silverlight offered a model very similar to WPF and enabled building and publishing rich Internet applications that could run inside a browser plugin, again using XAML. It offered nice support for animations and eventually made its way to the Windows Phone platform as one of the ways to build Phone apps. This is by and large deprecated now for Phone development, although Silverlight still finds a lot of use in browsers.

And then came the next new shiny piece of technology, the “Windows Runtime”, which enabled many scenarios in new and fundamentally different ways (such as implementing an app in multiple languages (native C++, managed C# / VB.NET, JavaScript – a single app can be composed of a mix of these languages) and seamlessly call from one to the other as long as some general guidelines are followed.

Comments

  • Anonymous
    January 25, 2015
    Serious and RT Dev are mutually exclusive terms.  aRm Tablettech is Dead. RT API is a waste of time, try find a job that requires it!, promoting it as any type of future is wrong. what would you say to people seeing all the WPF jobs that pay 100k to start, and none for RT, let me quess, its still early right, anyone promoting RT is an moron or SHILL!

  • Anonymous
    January 25, 2015
    @Dave, thanks for taking the time to post a comment. Before I can properly reply, though, I'll need some help to understand some of the terms you used. When you say "aRm Tablettech is Dead" are you talking about ARM processors in tablets being dead? That is hardly a fair representation of reality, given that Apple's iPad have ARM CPU's, iPhone's have ARM CPU's and Windows Phones have ARM CPU's. In any case, a discussion about ARM processors is completely unrelated to the topic at hand, because, as I attempted to explain in the article, the Windows Runtime API should not be confused with the ARM version of Windows 8 called Windows RT. It seems like you're confusing these two, and I apologize if the article didn't make that point clearly enough (see the section "The one thing to remember"). Your other point, that "RT API is a waste of time", is of course a more subjective point. While Windows Phone devices so far haven't picked up a significant global market share, I think you'll agree that its larger sibling, the Windows Operating system, is still very much alive. See en.wikipedia.org/.../Usage_share_of_operating_systems for example, according to which, as of December 2014, Windows makes for the vast majority of usage (>50% in both analysis presented there). If you want to build desktop-only apps, WPF is a great choice. And if you want to build modern Windows apps (Windows Store apps), then you'll do it through the Windows Runtime API. In addition, Windows 10 will help bridge the gap between Store apps and Desktop apps by allowing users to run Store apps in windowed (non-fullscreen) mode. With that said, it is my opinion that the RT API is most definitely NOT a waste of time. Much the contrary -- it is most likely going to remain as a core piece of the Microsoft ecosystem. It is unfortunate that the Windows Runtime API and the ARM version of Windows 8 are both referred to as WinRT and I can see why people would confuse the two (I myself had that problem when I was starting). But if you spend some time to familiarize yourself with what the Windows Runtime API really is, I think you'd come to appreciate how elegant its architecture is and how it helps you solve many problems.

  • Anonymous
    January 31, 2015
    "If you want to build desktop-only apps, WPF" , desktop-only apps, Modern is frameless IE base with com+-- wrapper only. WPF is not limited an is superior ModernRTAPIStoreUniversal, the names are endless, I just call it RT, it's not good enough, period. modern web tech is better, to compare it to full .net is a joke, not that most at Microsoft haven't been pushing the misguided messaging that RT is the future, WPF has a learning curve, if you want to be a big boy, learn it, you'd be a fool to waste time on RT/Uni, look in your area for a job doing RT, then look at all the WPF jobs paying top dollar, talk of future doesn't pay the bills, as far as advising others, what is your track record as a prophet? , what will you tell people in the future if it turns out your wrong?

  • Anonymous
    February 04, 2015
    The comment has been removed