Is Universal Windows Platform the replacement of WinRT of Windows 8 and Windows Phone apps?
I mean, there was a WinRT platform to develop metro apps exclusively for Windows 8. Now, that is replaced by UWP, isn't it?
That is correct, UWP is the new platform for ALL Windows devices going forward (Win 10+). However WinRT is not replaced by UWP but is instead an extension on top of it, making UWP a much broader set of APIs that can be used across even more devices. As Microsoft themselves state:
With this evolution, apps that target the UWP can call not only the WinRT APIs that are common to all devices, but also APIs (including Win32 and .NET APIs) that are specific to the device family the app is running on.
The UWP platform supports the "Universal Device Family" class of APIs which is then supported on ALL windows platforms (Xbox, Phone, Desktop etc). There are some extension families that you can use that will limit the apps reach, such as a "Mobile Device Family".
These specific device family APIs can however be checked for and used at runtime gracefully. For example you could show your own position using GPS on a phone, but not enable that functionality on a Xbox.
I hope this answer helps you, if you have any more questions about this I recommend reading this article about the UWP platform:
Source: https://msdn.microsoft.com/library/windows/apps/dn894631.aspx
Have a wonderful day!
This is a bit confusing because in Windows 8.x, "Windows Runtime" was actually used to refer to a few different things:
A new pattern (and supporting code/OS components) for defining and consuming Windows APIs, meant to largely supersede "Win32" (i.e., flat C-style) and classic COM for new APIs in most scenarios. This was/is really about language interop: allowing the Windows team (and potentially others) to create components in C++ that expose APIs that don't depend on GC or a runtime like the CLR, but still feel relatively natural to use from C# or JavaScript without needing manually written wrappers.
The set of Windows APIs that follow the above pattern.
A new platform/environment for building and running a new type of Windows app, which are meant to have some of the characteristics of mobile and web apps in terms of causing fewer potential problems with system security, reliability, performance, battery life, etc. This is what evolved into UWP with Windows 10.
In the Windows 8 days, these apps were called "Metro style apps" during most of 8.0's public preview period, and officially dubbed "Windows Store apps" just before RTM. The platform/environment for these apps ... officially didn't really have a name (other than "platform for Metro style apps"). Unofficially, people (including at Microsoft) sometimes referred to it as "Metro" (a whole can of worms in itself) or ... "WinRT".
So what's the relationship between WinRT "proper" (definitions 1 and 2), and unofficial WinRT definition (3) aka UWP aka the formerly-nameless "platform for Metro style apps"? Well, since WinRT and the new app platform were both introduced in Windows 8, most of the WinRT APIs at that time were specific to the new platform. The app platform (and Store policy) at the time was also much more restrictive about which legacy Win32 APIs were allowed for use in apps - for the most part this was less about any technical limitation and more about the team hoping to use the new apps as an excuse to clean up the bloated Win32 API surface. But technically, WinRT is meant to be the common pattern for new Windows APIs in general, whether used in UWAs or not, and "UWA vs. classic app" and "WinRT vs. Win32" are mostly independent; over time, they've gradually enabled more WinRT APIs for use outside UWAs and also relaxed their policies on using a lot of legacy Win32 APIs in apps (and also continued to introduce new flat C-style APIs for certain use cases).
So to summarize, it's not technically accurate to say that "UWP replaced WinRT", though understandable since this stuff is pretty confusing. UWP replaced the nameless app platform (3); essentially it's just an updated version that's been ported to other device types and integrated with the classic desktop UI. WinRT, in its proper definition (1), continues to be the basis for new Windows APIs for use in UWAs and even outside them.
Windows Universal Platform is the development platform going forward for devices running Windows. Previously, development was separate for Desktops and Tablets vs Phones. With UWP you are now able to target any device running Windows 10, could be phone, desktop, tablet, xbox. The beauty is that you can now use one Binary for all of these platforms and has brought us much closer to a truly to a universal Windows app.
So, to answer your question, yes, UWP is the platform going forward for any device which runs Windows 10
Related
I will refer applications in Windows Store for either Windows 8/8.1 or Windows 10 as UWP applications as Wikipedia does, if I do not mistake it. Windows RT(not WinRT though) is not discussed to avoid confusion.
I wonder what API's no matter public or undocumented that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on, so that they cannot be port to Windows 7, which is NT 6 as Windows 8/8.1/10 do.
If nothing much are there, but only due to M$'s market strategy to promote new technology'd Metro, there might have been some 3rd-party runtime/framework for Windows 7 on which Windows Store will work and UWP applications can run, which will surely spend no more effort and cause no more legal or compatibility trouble than Mono or Wine.
Edit: As How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF? says, it's a layer quite similar to .NET that lies between COM and application, if I didn't misread.
It's not a marketing strategy by the evil M$, and writing things like that makes you look rather juvenile. There's a giant layer of code (arguably an entire operating system within an operating system) that was written to enable Metro/Modern/UWP apps to run in Windows 8, tweaked in 8.1, and further refined in 10. That layer simply isn't there in Windows 7, wasn't backported, isn't going to be backported, and can't reasonably be backported by a third party who lacks access to the undocumented details of the implementation.
There is no conspiracy afoot here. It is a simple matter of new operating systems supporting things that old operating systems don't. The new features that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on is the entire notion of a Windows Store and a UWP application.
The version number ("NT 6", as you point out) doesn't matter. All that tells you is they didn't massively rewrite the kernel. You don't have to rewrite the kernel in order to write a new layer on top of it.
If you want to run Metro/Modern/UWP/Store applications, you need to update to a later version of Windows. Alternatively, you can just write a regular Win32 application, which will run on all versions of Windows, including the latest builds of Windows 10.
AFAIK, only Metro style apps can run on Windows 8 ARM, and Metro style apps can only be written with WinRT APIs.
According to this thread Can we access Windows 8 WinRT API from desktop application and Windows Phone 8 app? If so, are they in different namespaces?
Windows Phone 8 use ARM architecture, too. So if our app is written with WinRT APIs, it can run on both Windows 8 x86, Windows 8 for ARM and WP8, right ?
Not exactly. The situation with WinRT and Windows Phone Runtime is similar to WPF/Silverlight. There is overlap, but not 100% coverage. To address this issue Microsoft encourages using Portable Class Libraries to target multiple platforms (since each platform has its own runtime). More information on PCLs: http://msdn.microsoft.com/en-us/library/gg597391.aspx
Also, even if you manage to have most of your classes working under a Portable Class Library, you'll still have to write separate User Interfaces for each platform (the PCL does not support sharing UI). While this may seem upsetting, it actually is more necessary than you think. Here's a link on what Microsoft suggests in terms of sharing XAML UI.
This shouldn’t be seen as a complete roadblock for sharing between
Windows Phone 8 and Windows 8. The clear guidance is to design and
build your UI separately for each platform, embracing the design
guidelines for each. It is technically possible to circumvent these
obstacles. You could create your UI during page initialization from
code. You could load platform-specific XAML from resources at runtime
and inject it as a string into the page. However, none of these
techniques scale and they make the construction of your core asset—how
your app looks to your user—a tedious and error-prone task. Your code
sharing investment will give you a much larger return further down
your app stack, by trying to share app logic, data models, viewmodels,
etc.
Basically, Microsoft is saying design your user interfaces specifically to the platform, because an application running on the phone (smaller screen) should have a different user interface than one that runs on a tablet/desktop (larger screens).
As far as running WinRT apps on different platforms... Yes, you can. Microsoft has stated that applications written in WinRT can run on Windows 8 and WOA (Windows on ARM). Here's a link from Microsoft talking about this. But, the first portion of my answer still stands... if you want to target different runtimes (WinRT/Windows Phone Runtime)... then use Portable Class Libraries. Selecting "Windows Store" and "Windows Phone 8" will allow your code to run on Windows 8 x86/x64/ARM, and Windows Phone 8.
Windows Phone implements a subset of the Windows 8 WinRT API, dubbed WinPRT (P == Phone). You can find a good overview here with an exact list of support Win(P)RT APIs to be found here.
Word of caution - the XAML on Win8 is similar, but different, to the XAML on WP8 so expect to have to rewrite a lot of your UI for WP. What you really want to do is read this Getting Started guide that steps you through a lot of the considerations and techniques involved in developing apps between these platforms.
As far as I understand, Microsoft wants to allow "having both desktop and modern ui GUIs" only available for web browsers (am I mistaken here ?).
Does that mean common apps will be developped twice ? With e.g Skype being available both as pure desktop app and pure modern ui app ? And if a user installs both, these both instances will share no data ?
I can't imagine them doing a shift towards gesture friendly uis/hybrid ui, and leaving full blown desktop apps (not toy/phone-like/game apps, that can live in one space only) with no integration/entry points inside modern ui. Or maybe they want to participate in that "kill full-blown desktop apps" movement ?
So is there a model for a desktop app developped in whatever GUI toolkit, that wants to have some minimal integration with a small HTML/CSS/JS frontend in modern ui, like for e.g providing a dashboard of favorite or recently accessed files, contacts, etc ?
Your first statement of "only in a browser" is not correct. Desktop applications don't change their current design paradigms. You can have browser-based apps on the desktop, of course. But full clients are still supported and still viable as a real solution to problems.
Your takeaway from that comment should be that desktop applications are not deprecated as people assert. The reality is, desktop applications are still the only solutions to many problems.
Your second question of shared data is not correct. Skype shares lots of data with its app companion. Not because of shared local storage, however; it is because of the services that it shares. My account and contacts are on the server. So, they share a lot.
Your takeaway from that comment should be that Windows 8 apps should not highly leverage local storage but should be built as service-oriented clients. To that end, your desktop applications should have already started to leverage this architecture, too.
Your third question (which is very cryptic) seems to be asking if a desktop application and a companion Windows 8 app can share or integrate with each other. The answer is yes. Not only can they share the same service, but file associates, custom protocols, and some of the non-Store manifest capabilities allow for this explicitly. Line of business applications should have a companion app, if you ask me. The integration points are many - though not every. But there is no other way to leverage the new capabilities of Windows 8 without introducing a companion app - even if that app does very little.
Your takeaway from that comment should be that Windows desktop applications and companion Windows apps are the preferred and anticipated development approach.
Best of luck, thanks for the question.
We are developing a lightswitch app that will have a silverlight plug in controller that will allow for handwriting recognition and translation. we want to use this exclusively on a win8 tablet. we know that it has to be used on the desktop side of the tablet. We also know that the win8rt side has access to different tools that allow of handwriting recognition. (InkManager class) - is there any way to get access to these necessary classes from the desktop side of the win8 tablet.
This post by Scott Hanselman might help you.
Quote:
I was trying to access some of the sensors that are built into this
Intel Ultrabook that runs Windows 8. However, while there's support
for Location Sensors built into the .NET 4 libraries on Windows 7 and
up, I want to access the complete Sensor and Location Platform that is
built into Windows 8 itself. Those APIs are available via COM and I
could call them via COM, but calling them via the WinRT layer is so
much nicer. Plus, this is kind of why WinRT exists.
There's also an example using VB.NET on TheCodeProject
Over internet there are many blogs saying that winrt is a replacement of win32 api. IS this is really true? Even i read that application developed for Metro Application uses winrt. So do i understand correctly, those application which are metro application they has to go through winrt & classic applications has to go through win32 api's. Please someone validate my conclusions.
Disclaimer: I am not involved in any way in the design or implementation of Windows 8, and I have only kept up on the Windows 8 news. I possess no privileged information.
winrt is a replacement of win32 api
Microsoft has made clear that WinRT is not a replacement for Win32, but another way to develop applications. That said, there is no Win32 implementation on ARM (at least that third-party developers can access). Windows on ARM will only support WinRT, and not Win32, as Steve Sinofsky explains here.
those application which are metro application they has to go through winrt & classic applications has to go through win32 api's
Absolutely correct.
Win32 still exists. WinRt wraps them and converts their types to be native for the consuming language. C++ metro application can still access a limited set of Win32 APIs
WinRT is basically a wrapper for Win32 (COM) to be consumed by Metro Stype applications (Projections for Native, CLR, Javascript) which are designed for a sandboxed environment mostly for Touch-Screen aware applications (although one can hack them to work on the desktop). Some APIs for Metro Style applications are still using the classic COM APIs (DirectX for example).
So, how can WinRT replace Win32 if it is built upon it? ;-)