Paul Thurrott's SuperSite for Windows
Home > Windows > Windows 8 > WinRT is Replacing Win32

WinRT is Replacing Win32

Sep. 15, 2011 Paul Thurrott | Paul Thurrott's Supersite for Windows

One of the confusing bits about WinRT is, well, everything. But after conferring with others and studying Microsoft's documentation, I can make the following general statement: WinRT (the new Windows Run Time) is not a replacement for Silverlight or .NET, it's a replacement for Win32. And that means that it's the new native runtime for Windows, and not a managed code layer that sits higher on the stack. And that means further than the layers that do sit on top of WinRT--XAML/C# (and other languages), HTML/JavaScript, and DirectX--are far less abstracted from native code than was previously thought.

This has many ramifications. It means that all of these layers--XAML/C# (and other languages), HTML/JavaScript, and DirectX--will have basically identical capabilities. And it means that HTML and JavaScript applications will likely run just as fast, generally speaking, as do C# and XAML apps, something I suspect will be surprising to many people.

Microsoft has an unfortunately inaccurate high-level diagram showing the relation between WinRT and the environments its replacing (which are shown as IE, Win32, and .NET). But the important thing to note is that there's the NT kernel and then, right on top of it (like Win32) is WinRT. This WinRT has an application model and three boxes of capabilities that are expressed by APIs (Communications & Data, Graphics & Media, and Devices & Printing). "Above" WinRT is the two sets of presentation layer/programming language couples: XAML and various high level programming languages (C#, VB, and so on) and HTML/CSS and JavaScript, respectively. (DirectX is left out, but this sits on top of WinRT too.)

WinRT solves many of the problems of Win32, from an apps perspective, though it can't be used for certain things of course (writing NT services, drivers, and the like). Apps created for WinRT are safe, secure, and sandboxed, can't wreck other apps, can't cause "Windows rot," and all install in just 2-3 seconds. They feature isolated storage, single folder installs (as per the Mac), and require user consent to access the general file system. When Microsoft says it "reimagined" every aspect of Windows, this new runtime, or application model, must be included as well. This is part of it, a modern, truly different app platform that is far more different, and far more capable, than many people understand right now.

And in the same vein of blowing past peoples' expectations, virtually no app could not be written as a WinRT app. Many are imagining very simple, HTML-like apps, and while I'm sure there will be plenty of those, you need to reset your expectations up. WinRT is amazingly full-featured and not constrained to goofy utilities and simple games. The next "Call of Duty" could be a WinRT app, complete with support for Edge UIs and Charms.

And here's something interesting: Virtually all of the Microsoft WinRT apps--Mail, Calendar, People, Chat, and so on--are all written in HTML and JavaScript, not C# or another supposedly superior language.

And you laughed when they repeated "Windows reimagined over and over again in Tuesday's keynote. I'm starting to think they didn't push this point enough.

Discuss this Article 28

wieda
on Sep 15, 2011
It is a radical turn. But it is not just WinRT. There was a conference on the entity framework, MS object relational data layer, that made it explicit that to use the entity framework to talk to Metro applications, one has to convert the data to Odata, even on a local machine. That means relational data has to be converted to objects, then JSON, to bind in a Metro app. Second, the c++ people are mortified that their language of choice will no longer have an instant performance lead vs managed code or even javascript. Unless writing shaders or 3d programs, c++ on Windows 8 does not make sence (sigh). Finally, the tool revisions for javascript and html make these languages first class citizens, both in tool support and speed. I bet there will be zero difference between JavaScript, c#, c++ in benchmarking against the WinRT. Microsoft is unleashing a revolution, and a lot of devs will be run over.
Waethorn
on Sep 16, 2011
So, basically this is what Palm tried to make of webOS. Except that this is an OS that developers want to target and customers will actually use.
c3141wss
on Sep 16, 2011
WinRT is not replacing Win32. Even Microsoft would not be so stupid as to do that. WinRT is a dumbed down API for a dumbed down interface (Metro). I mean, it doesn't even support basic features like overlapping windows. I'd love to see, say, Adobe for example, try and write a version of Photoshop that has no overlapping windows. Also, I'm skeptical of the notion that somehow WinRT has nothing to do with Win32. I mean, DirectX is based on the Win32 API. So, if you're going to make a WinRT version of "Call of Duty", you'll be calling the Win32 APIs anyways. Just take a look at : http://msdn.microsoft.com/en-us/library/windows/apps/br205757%28v=VS.85%... for what I'm talking about. Basically, if you're app has any modicum of complexity, you're going to be calling Win32.
VinnyH
on Sep 16, 2011
@Brian, It's about time C++ shared its reign over the win32 world with other languages. Yes you can still write to Win32, but you're writing to yesterday's platform. Why would you want to continue writing for WinXP if Win8 is the future? Your customers might demand that interface, since all their other apps have transitioned to the Metro style interface. What is wrong with Adobe re-imagining Photoshop? I am a lead dev for an insurance app (a.k.a. lots of input boxes, overlapping screens etc.) and we're already looking at how we can at least make partial use of this. Once the tools become available (especially templates), I would like to think that we can transition to this new software paradigm. Win32 will be there (as one of the slides was pointing out), because you still need device drivers etc., But it's time to think outside of the Win32 box and start embracing WinRT man... Peace!!
sheldyck1
on Sep 16, 2011
if you copy mspaint and wordpad from the developer preview to a win7 computer, they don't run. 'not a valid win32 application'. OS items designed to run on 7 work on 8, but the reverse is not true. I remember being able to get wordpad from the win95 alpha to run on wfw311/win32s, so I'm thinking that Paul is absolutely correct ... the foundation has been replaced, affecting even non-metro-style.
c3141wss
on Sep 16, 2011
@VinnyH Well, for starters, Photoshop is a cross-platform application. It's already hard enough using Win32 to make cross-platform applications because you have to rewrite the core code. But now, you'll also have to write two separate interfaces with completely different paradigms. That means double the training and double the complexity. I suspect your insurance app won't be Metro-only for a very long time. I don't see many corporate IT departments embracing Metro. And businesses are usually the last to upgrade to a new version of Windows anyways; there are still a number of businesses using NT 4. Really, if I wanted nothing but full-screen apps, I'd go back to using DOS. Windows 8 is regressive, not progressive, at least for the desktop. At some point, Microsoft needs to realize that tablets and PCs are not the same thing. Apple figured that out which is why they have iOS for handheld devices and Mac OS X for PCs (PC meaning Personal Computer, not IBM PC). I'm also distrustful of both the app store requirement and the need for signed code. I'm not really a big believer in the concept of certificate authorities because they provide a single point of failure and single vector of attack for the entire system (e.g Diginotar) and they don't really do anything but collect outrageous fees for spending 5c of energy to generate a certificate. Code signing certificates are too expensive for open source/freeware developers and hobbyists; I've already seen the x64 driver signing requirements put a number of hobbyist projects (like ATITool) out of business because they can't afford the certificate. The app store for me is another problem because of the potential for censorship and the inhibition of free speech. What if I design a game to make a political statement and it's not politically correct? In addition, it feels like a shakedown by the mafia, having to pay Microsoft a percentage of the profits. No, I think I'll pass on WinRT and Metro.
Bozster
on Sep 16, 2011
<i> And it means that HTML and JavaScript applications will likely run just as fast, generally speaking, as do C# and XAML apps, something I suspect will be surprising to many people.</i> Yes.. I think they will be surprised at how stupid idea this was to begin with to use HTML/Javascript to build desktop applications and how awful Javascript/HTML/CSS runs. Javascript a language that's a huge mess. That has no consistency, no writing rules, no real object oriented structure, no inheritance etc etc.. If we consider this moving forward, I think it's time to revaluate the sanity of whoever is running Microsoft.
pthurrott
on Sep 16, 2011
A couple of points here. WinRT is replacing Win32. Sorry, that's a fact. It does not sit on top of anything, architecturally, besides the NT kernel. You may be able to "call" Win32 APIs from WinRT; I don't know. But that doesn't change what I've written. MFC and .NET rely on Win32 and don't sit directly on top of the kernel. WinRT does not rely on Win32 and does sit directly on top of the kernel. Regarding JS/HTML and performance: Microsoft's own apps--Mail, Cal, Bing, and so on--are all written in JS/HTML, not C#/XAML. So we'll see. But the company has told me point blank that the language/design you use as a developer does not matter. HTML/CSS/JS is hardware accelerated in Windows 8 and has access to exactly the same APIs as the other languages/tools. There are charateristics HTML and XAML that make one or the other simpler for certain kinds of apps. But the perf will be very similar. Dont expect a big difference. That's what I've been told.
NevilleBagnall
on Sep 16, 2011
One interesting thing from the developer reference on MSDN: Read 0 The file is read. If a writer to the file occurs during the read, and OpLock break is received by the reader and the read operaton fails. ReadWrite 1 The file supports a single writer and multiple readers and writing is transacted. Use only when just about to write to avoid unnecessary OpLock breaks. ReadWriteUnsafe 2 The file supports a single writer and multiple readers and writing is non-transacted and is in-place. ReadWriteNoCopyOnWrite 3 The file supports a single writer and multiple readers and writing is transacted. Read/write streams are separate and write streams begins empty. That suggests to me that they expect most apps to asynchronously (auto)save files in an NTFS transaction. Through capabilities, I also think they are making it more difficult to save outside the Known Locations:(documentsLibrary, picturesLibrary, videosLibrary, musicLibrary, removableStorage). Any indications that the Known Locations require NTFS? Or that removableStorage has been given a transactional layer?
pthurrott
on Sep 16, 2011
Right, so file system access requires consent, either explicitly from the user or, in the case of the File Picker, implicitly.
Waethorn
on Sep 16, 2011
@Brian Hill: Obviously you've never coded a website before. And you certain damn well can create elements that overlap others on a website. HTML5 makes that even easier too. This ISN'T replacing Win32 outright either. Win32 is still going to be around for the foreseeable future. I can't imagine a lot of professional apps will be converted to Metro-style apps for download on the Windows App Store in the near future. Imagine if you had to download AutoCAD or Photoshop as a Metro touch-based (ahem, touch-first) app - something that is several gigabytes, requires activation (or an activation server), and is no longer offered the precision of mouse input for primary interface.... It'll be a long time before that kind of app sees the Start Screen. BTW: Sinofsky said that "native code" (probably talking about C, C++) would be cross-compilable. I don't know if that means Win32 (and the Desktop environment) will run on ARM, or if they mean that only the WinRT format of C & C++ will work. Note however, that WinRT has it's own application and object model, so I don't know that you can call that "native".
reets
on Sep 16, 2011
Wanted to start by saying fantastic article and loved your BUILD coverage on WW. This does get me excited a little bit as I've always seemed to like how fast an HTML/JS app can go together but always wished there was a way to release it as a "compiled" or at least packaged app so your source code is a little hidden (mainly for proprietary reasons). I was wondering if you have any information, or even a guess, if WinRT will be "ported" (if possible) to Windows 7 so you can at least run the Metro style apps on Windows 7? Or if there will be some other framework/included DLL's that can be installed to make those apps work on non-Windows 8 machines?
c3141wss
on Sep 16, 2011
There's a laundry list of Win32 calls that are supported in Metro here : http://msdn.microsoft.com/en-us/library/windows/apps/br205757%28v=VS.85%... If WinRT applications are going to be making Win32 calls then I fail to see how WinRT can replace it.
dcoder
on Sep 16, 2011
I don't want to be contrary, but WinRT is not REPLACING the Win32 API. The word 'replace' conveys the idea that the thing replaced is gone, and this will not be the case. The Win32 API will still be part of Windows 8. WinRT will run side-by-side, on top of the kernel, as you correctly indicate. But it is an addition to the stack, not a replacement for Win32. I will say that, at some point in the future, Win32 might be phased out, but it will take years -- if not a decade or more -- to do so. Microsoft simply can't introduce an operating system that won't run millions of existing business applications. In my humble opinion, this is the plan: to introduce WinRT as the new cool thing -- and it is -- and over the course of years de-emphasize Win32 programming, so that someday they can introduce an OS without the Win32 API. When that happens, if I'm still around, I'll salute that old beast, and say thanks for the memories. Cheers.
de Silentio
on Sep 16, 2011
"WinRT is amazingly full-featured and not constrained to goofy utilities and simple games. " I hope people start developing games that are more advanced than the ones included in the Developer Preview. Some of them looked like Atari games I played in the 80's.
c3141wss
on Sep 16, 2011
@Waethorn, I have coded websites in the past. Web developing != Web designing. Only Javascript "apps" use HTML5. Other WinRT apps use XAML. Everything that I've read says that there are no overlapping windows in WinRT. It doesn't matter what you can do in HTML if there is no support for it on the programming side of things. See : http://forwardthinking.pcmag.com/none/287736-build-more-details-on-build... I do not think that we will see too many HTML/Javascript apps to begin with. HTML is a document markup language, not an interface design language and Javascript is a scripting language, not an application development language (as in, Javascript is designed to allow users to extend existing applications written in other languages, not to actually code the application itself.). It's like trying to fit a square peg into a round hole. @dcoder I can't see WinRT, in it's current state (as documented on MSDN) ever completely replacing Win32. It's a relatively high level API. If anything, I'd say it's more analogous to MFC than Win32. Look here : http://msdn.microsoft.com/en-us/library/windows/apps/hh464945%28v=VS.85%... And look at all of the things that have no equivalent in WinRT (mostly low level stuff).
hskoglund
on Sep 17, 2011
I've just tried calling a Win32 API (MessageBox) from a Matrostyled C++ app (using the Dev Preview Windows 8 release) and sure, Win32 it's still there lurking underneath. For example, by adding 3 source lines to the HelloWorld C++ sample from one of the keynotes you'll get this picture: http://www.tungware.com/tripleboot/ifeelhappy.gif If you want the gory details see my blogpost http://www.tripleboot.org/#post0
pthurrott
on Sep 17, 2011
*Sigh* You people are classic. :) Win32 is still there. Obviously: Windows 8 includes complete backwards compatibility with all of the applications that run in Windows 7. WinRT does not, however, sit "on top of" Win32. It is directly on the kernel. This isn't my opinion. This is from Microsoft. It's a fact. I'm sure you can call Win32 (and .NET) APIs from WinRT. That doesn't change what's written above. I'm also sure that WinRT v1 (as with .NET before it) is not as full-featured (or "rich") as it will be as it improves and advances. This is the first release. Moving on.
PatriotB6007
on Sep 17, 2011
@Paul Even if it is "from Microsoft", take it with a grain of salt. Fire up Dependency Walker (www.dependencywalker.com; used to be included with Visual Studio years ago); open up some of the WinRT libraries (e.g. windows.ui.xaml.dll and company), and look at what DLLs/APIs they make use of. You'll see they are built on standard Win32 DLLs such as user32.dll, gdi32.dll, shell32.dll, etc. In the couple I've looked at I haven't seen kernel32/kernelbase.dll, but instead you see all the ApiSet DLLs (which are how APIs that have been refactored as part of MinWin are now exposed). The low-level WinRT functions documented at http://msdn.microsoft.com/en-us/library/br205774(v=VS.85).aspx appear to be implemented in combase.dll -- which looks like a MinWin-esque split off of ole32.dll (ala kernel32 and kernelbase). Combase uses many Win32 functions of course. I'm surprised that you and no one else here has compared this to WinFX (prior to its rechristening as .NET 3.0) -- proclaimed at the time (2003) by Microsoft to be the replacement for Win32. Of course, WinFX libraries (WPF/WCF) were built on top of Win32, as is all the rest of .NET. A better way to view WinRT, is that it you should use its API surface rather than the underyling Win32. That way, Microsoft is free to evolve what's underneath -- and perhaps in the future remove its own use of Win32 -- and your app would continue to run. Apps that mixed in Win32 calls would not. Perhaps this will be important when the eventually merge Windows Phone and Windows; or perhaps to develop Metro apps for Xbox.
wieda
on Sep 17, 2011
@ Paul with trepididation, this change is big. Win32 is still there on the stack, and one can wrap win32 calls in a metro style dll and include the new dll in your metro app. But make no mistake, the winRT is totally isolated from Win32. I had a conversation with Visual Studio people because a canned MVVN app was not compiling against Win32 (the new API was missing a reflection call). With the VS2011 Ultimate build, I can run 4.5 client but not the metro style app. OK, how does one include the 4.5 client .Net assemblies in the metro app. Can't be done. OK, if you compile against .Net 4.5 client, can I convert the app to Metro? No. simply put, there is a sandbox between metro apps and standard .net 4.5 apis calling win32. So back to wrapping win32 with a metro dll. Well, only way to distribute metro apps is through the ms store. ms has to approve both the app and the win32 wrapper. what if the wrapper is calling a no-no api? Then again, there is no way win32 api will be ported to ARM. So you got this wrapper that may be killed by the ms store but regardless will not run on Arm or whatever ms ports to, killing half your market. Conclusion: Metro is a mind set change both how it works and to what one develops against. I too loath working with JS/HTML, and actually thank ms they are keeping languages I am comfortable with as an alternative. But understanding the metro interface will take many mood altering sessions to glimpse the panorama of its implications. If ms keeps their "fast and fluid" contract, and now it looks like they can, I can buy in.
xmlguy66
on Sep 17, 2011
Well, technically WinRT *does* site on top of Win32, specifically User32. When you run a Metro app, WinRT creates a single always-on-top Win32-based window, adds a DirectX surface to it, then paints everything through that surface. This ensures Metro apps are hardware accelerated by DirectX, but still able to play alongside existing Win32 windows. For example, if you tell Task Manager to run Always On Top, it is possible to go back to Metro and have Task Manager appear over the Metro window. You couldn't do this if Win32 wasn't in play. That said, MS is clearly de-emphasizing Win32, but it won't ever go away. Just like you can still run 16-bit Windows apps and DOS apps, Win32 will be here for many many years to come. And of course, the biggest apps such as Microsoft Office, Adobe's Creative Suite, etc. will all stay running on Win32 for the foreseeable future. Windows 7 install based only just overtook Windows XP - a 10 year old OS. Also, as a point of comparison, its taken Apple 10 years to get folks off of Carbon and onto Cocoa, and that transition is still far from complete.
smallmountain
on Sep 17, 2011
Hey, Paul - The statement from your article that caught my eye was "virtually no app could not be written as a WinRT app". I was not at BUILD; I'm going on what I've read and what my co-worker who *was* at BUILD has relayed. If your application relies heavily on multiple overlapping Windows, are you saying it could be written as a WinRT app because you could redesign it to not need multiple overlapping Windows? If your application offers a COM Automation interface, how does one achieve that in WinRT? WinRT excites me because it looks like a runtime that will have much lower overhead than .NET. The application I develop is mostly native code, and we managed to bolt WPF on to it, but it was a bit like oil and water. Seeing XAML sitting on top of C++ on top of WinRT with no .NET is intriguing to say the least. But what does that really mean? Is all of the cool data binding of WPF available? And what exactly is the future of desktop applications? Is WinRT going to grow up so much that we'll forget we needed desktop applications? Are the desktop application stacks like WPF going to continue to get material enhancements? Or are they effectively deprecated? As exciting as WinRT is, my big disappointment from BUILD is that companies that have bet heavily on desktop applications received no clarity whatsoever about what the future holds for them. Eric
smallmountain
on Sep 17, 2011
Hey, Paul - The statement from your article that caught my eye was "virtually no app could not be written as a WinRT app". I was not at BUILD; I'm going on what I've read and what my co-worker who *was* at BUILD has relayed. If your application relies heavily on multiple overlapping Windows, are you saying it could be written as a WinRT app because you could redesign it to not need multiple overlapping Windows? If your application offers a COM Automation interface, how does one achieve that in WinRT? WinRT excites me because it looks like a runtime that will have much lower overhead than .NET. The application I develop is mostly native code, and we managed to bolt WPF on to it, but it was a bit like oil and water. Seeing XAML sitting on top of C++ on top of WinRT with no .NET is intriguing to say the least. But what does that really mean? Is all of the cool data binding of WPF available? And what exactly is the future of desktop applications? Is WinRT going to grow up so much that we'll forget we needed desktop applications? Are the desktop application stacks like WPF going to continue to get material enhancements? Or are they effectively deprecated? As exciting as WinRT is, my big disappointment from BUILD is that companies that have bet heavily on desktop applications received no clarity whatsoever about what the future holds for them. Eric
smallmountain
on Sep 17, 2011
Hey, Paul - The statement from your article that caught my eye was "virtually no app could not be written as a WinRT app". I was not at BUILD; I'm going on what I've read and what my co-worker who *was* at BUILD has relayed. If your application relies heavily on multiple overlapping Windows, are you saying it could be written as a WinRT app because you could redesign it to not need multiple overlapping Windows? If your application offers a COM Automation interface, how does one achieve that in WinRT? WinRT excites me because it looks like a runtime that will have much lower overhead than .NET. The application I develop is mostly native code, and we managed to bolt WPF on to it, but it was a bit like oil and water. Seeing XAML sitting on top of C++ on top of WinRT with no .NET is intriguing to say the least. But what does that really mean? Is all of the cool data binding of WPF available? And what exactly is the future of desktop applications? Is WinRT going to grow up so much that we'll forget we needed desktop applications? Are the desktop application stacks like WPF going to continue to get material enhancements? Or are they effectively deprecated? As exciting as WinRT is, my big disappointment from BUILD is that companies that have bet heavily on desktop applications received no clarity whatsoever about what the future holds for them. Eric
pjsercel
on Sep 18, 2011
The .Net experiment is officially a failure then, eh? Wow! An object oriented, native code framework for accessing OS services and building applications. I for one predict that WinRT will not be finished until Windows 10 (aka MS OS X). What will Microsoft photocopy, err, invent next?
pjsercel
on Sep 18, 2011
The .Net experiment is officially a failure then, eh? Wow! An object oriented, native code framework for accessing OS services and building applications. I for one predict that WinRT will not be finished until Windows 10 (aka MS OS X). What will Microsoft photocopy, err, invent next?
Abscissa
on Sep 29, 2011
"Virtually all of the Microsoft WinRT apps--Mail, Calendar, People, Chat, and so on--are all written in HTML and JavaScript" This suggests to me that all the grown-ups have left Microsoft. And the app store, going by what people here are saying about it, just sounds downright insane. Guess what one of the biggest reason's I've never considered getting an iOS device is? That's right, Orwell's App Store. I never agreed with the people who claimed Win95 was too Mac-like, but even I'm finding that ever since Vista, Microsoft has been trying more and more to turn into Apple. At this point, each new step makes me more and more serious about choosing Debian with Trinity (or something along those lines) as my next primary OS after XP. "I bet there will be zero difference between JavaScript, c#, c++ in benchmarking against the WinRT." If that's the case, it can *only* be due to something in Win8 getting in the way of native executables and hampering their speed. Possibly the sandboxing.
nfg (not verified)
on Aug 14, 2012
I don't think it is correct to say that WinRT is a replacement for Win32. Win32 or Windows API as it is called today is the C-based API used by any Windows application to communicate with the Windows OS. This is not changing in Windows 8. I don't doubt that a bunch of new APIs were added to the Windows API, but it is essentially the same old Win32 since Windows NT 3.1 WinRT is a COM-based API that wraps the Windows API in a very similar way as MFC and .NET did. Metro style apps can only use a small subset of the Win32 API and the COM APIs directly. For the majority of the cases a call will be make to of of the WinRT APIs, but this is forwarded to several calls to Win32 APIs, as has always been the case for .NET

Please or Register to post comments.

Related Articles

IT/Dev Connections

Las Vegas
September 30th - October 4th

Paul ThurottYou'll have the opportunity to experience:
• 120 Technical
Sessions
• Networking with Peers
• Expert Speakers


Come See Paul Thurrott & Mary Jo Foley in Person!

Register Now

Office 365 InfoCenter

Get the latest insight and info from Paul

Read Now!

What I Use
Apr. 18, 2013
Article

What I Use: On the Road 21

Every so often, I publish an updated version of my “What I Use” document, which details the technology products and services I actually use day-to-day. Since I’m currently on my third business trip in five weeks, this is perhaps an ideal time to discuss the technology products I rely on when I travel and a few related points....More
Mar. 6, 2013
Article

What I Use: March 2013 33

Lots of changes since November, including a new PC-based home server running Windows 8, several new smart phones, new PCs and tablets, new cloud backup, Office 365 Home Premium and a nice doubling of my Internet speeds courtesy of Verizon FIOS....More
WinSuperSite.com
Related Penton Sites
Copyright © 2013 Penton Media, Inc