Wednesday, November 14, 2012

Win32, and WinRT, and WPF oh my!

Like any modern operating system, Windows is constantly evolving.  However, it still maintains a high level of backwards compatibility, which is great for many legacy apps that consumers depend on, which in turn is great for developers, consumers, and the framework that your apps are built upon.  With all the jargon floating around it's time to clarify where our Windows framework stands today.

Managed vs. Unmanaged code
Simply put, our Framework is unmanaged code, which means no .NET framework is required to run apps built with Real Studio.

WinForms vs. WPF vs. Win32 controls
These are the presentation layers that Windows supports.  WinForms (or Windows Forms) is part of the .NET framework, and most of its controls are based off of the lower level Win32 controls API.  WPF (or Windows Presentation Foundation) is also part of the .NET framework, it is a newer presentation layer whose controls are built on top of a different rendering engine to take advantage of modern GPUs.  Win32 controls is the unmanged, low level GUI API that has survived the ages.  This is what our Windows framework is built on top of.  There are various pros and cons to each framework, but to understand why our controls behave the way they do it helps to know what presentation layer our framework uses.

WinRT vs. Win32
You may have heard of WinRT as the new Metro-style framework for Windows 8.  This runtime framework includes a new set of controls designed to create Metro-style apps.  Since our framework is built upon the Win32 API, you will not be able to build Metro-style apps in Real Studio yet.  Note: this does not mean you cannot build apps today that run on Windows 8 Desktop.

The nice thing about these frameworks is that most of the functionality is interoperable.  In other words, I can use the WPF controls from an unmanaged framework (i.e. our Win32 framework), and vice versa (with some limitations of course, for example, WinRT's framework has some restrictions between what you can use on Desktop vs. Metro-style apps).  As an example to demonstrate this interoperability, I've built a plugin for Real Studio which embeds a WPF Spell Checking TextArea-like control that can be used in a Real Studio app.  Since I'm using managed code, the .NET framework is now required if I were to distribute this app to users.

Of course this plugin is merely a proof of concept and not ready to be distributed, sorry. :)

1 comment:

Anonymous said...

Thank you for this brief information about the state of windows and its different UI engines. For me it is good deal, that Realstudio doesn't need any of these bloaty Middleware Runtimes like .NET and as long as it doesn't look too alien its fine. But wIth Win8 and Metro the rules have changed a bit. What do you think? Any chance to get Realstudio work with tiles and the new Metro interface on standard x86 PC's somewhen?