In a recent interview, he confirmed Microsoft's commitment to mobile on first-party hardware and reiterated Microsoft's vision of a phone that could be a desktop via Continuum:
"We make phones today … focus on … this one particular feature that we have called Continuum, which is a phone that can even be a desktop. I'm sure we'll make more phones, but they will not look like phones that are there today.
My ongoing analysis is that Microsoft's anticipated Surface phone will be a telephony-enabled ultramobile PC. Focusing on its strengths, Microsoft is capitalizing on the smartphone's increasing adoption of tasks traditionally relegated to PCs but that also (in the case of iOS and Android) have OSes which cannot fully embrace the dominant Windows desktop environment that consumers and enterprises know.
Those phone-focused OSes and app models, though successful, are reaching their limits. Furthermore, the iterative advancements in these "slabs" is arguably a dead end in Apple's and Google's physical evolution of the smartphone.
These tech giants maintain desktop OSes that have different development platforms and user experiences separate from their mobile OSes. This could be a hindrance to their advancement to the desktop, even in the case of Samsung's Galaxy S8 and DeX dock.
Finally, I anticipate Microsoft's context-sensitive ultimate mobile device will transcend the stagnant decade-old rectangular slab form factor. But to be a real PC it needs to run familiar PC apps, and that's where the Universal Windows Platform (UWP), Project Centennial and Windows S come in.
UWP is foundational to Continuum
Microsoft's UWP strategy is designed to enable app development across all Windows 10 devices and provide a unified user experience.
In the case of a Continuum-enabled ultramobile PC, it also potentially provides a consistent user experience as one device "becomes" many across different personal computing scenarios.
Whether connected via Continuum to a monitor, mouse, and keyboard as a desktop, or held in a user's hand, context-conforming hardware and software with a UI supported by CShell should provide a fluid experience.
Microsoft's ultimate mobile device "will not play by the other guy's smartphone rules," says Nadella. I believe he means it will be a telephony-enabled ultramobile Windows 10 PC with Continuum that Microsoft will position in the mobile, not smartphone, space.
This strategy potentially solves for the impasse Google and Apple have reached where smartphones cannot perform the full range of PC tasks. This will be a PC with full PC and smartphone capabilities and an evolving app ecosystem.
Microsoft's Project Centennial app bridge, which helps bring Win32 apps to UWP, and Windows S are essential to this strategy.
Windows 10 S breathes life into the UWP and paves path for Surface phone
Windows S, which allows only UWP apps and is aimed at the education sector (with hopes of eventual mass adoption), gives developers a reason to use Project Centennial. The hopes for a Continuum-enabled device providing a full and modern PC experience fall apart if developers aren't convinced.
Talking Project Centennial with Microsoft's Stefan Wick
Making Win32 into UWP apps is a process that begins with the Desktop App Convertor and Project Centennial. I explained this four-step process last year.
Microsoft's Project Centennial app bridge makes sense of Win32 apps on phone
To provide greater insight, Stefan Wick, Lead Program Manager for the Windows Developer Platform Team (who also set up the deck for the Centennial Presentation on the first day of Build) was kind enough to answer a few questions.
Jason Ward: Hi Stefan, I'd just like your feedback confirming or correcting [my] understanding that Win32 apps can be made into full UWP apps.
Stefan Wick: Hi Jason, This is exactly the purpose of the Desktop Bridge: provide developers a path to make full UWP apps from their existing Win32/NET investments.
The nice thing about it, is that developers can do so gradually. They start by converting their installer to a Universal Windows app package and get the immediate benefit of modern deployment on Windows 10, through Windows Store or other distribution channels of their choice.
Next, they can now modernize their existing apps with new Win10 APIs and features thanks [to] using UWP. Overtime, they can move all their code to UWP-compliant APIs and become a full UWP.
I've gotten a couple of negative responses challenging what I presented as the purpose of the Convertor and Centennial. Here's one of the comments (edited for length):
Centennial doesn't turn Win32 software into UWP software! ... The UWP API is a programming interface that allows software developers to make use of all the features the platform provides, like the ability to recompose the UI based on screen size, or the ability to deal with touch input in a way that treats it as a first-class citizen (not as an afterthought as it is treated by Win32).Any piece of software that uses the UWP API can legitimately be called UWP software or an UWP app. Software that doesn't use the UWP API is not UWP software! The desktop bridge (Centennial) doesn't change anything about the API software uses. Win32 software will still use the Win32 API after being "converted."It will still not use a single UWP API. Project Centennial, therefore, does NOT make Win32 apps into UWP apps!
The Desktop Bridge is more than just the converter. The converter is the first step. It is correct that it doesn't change the APIs your app is calling, and the converter won't produce a full UWP (app) for you. But it sets you up for the gradual process of modernizing and migration to full UWP (calling only UWP-compliant APIs). In some cases, the full migration can be trivial, for example for Unity games, since all Unity APIs are already supported in UWP.
In other cases where apps have a lot of dependencies on non-compliant APIs, completing the migration is more complex. However, with every update of Windows 10, we are making this process easier for developers as we keep expanding the API surface supported in UWP (both for Win32 and NET APIs).
Right, I did understand that the Converter is the first step and makes the app available in the Store, but the subsequent steps of enhancing (modernizing) and migrating are what make the app a UWP app. So that I understand, in a practical sense the purpose is to bring Win32 apps to full UWP and as of today:
- Some APIs are UWP compliant, and apps that use those can undergo that complete process.
- Some APIs are not yet UWP compliant, and apps that use those APIs cannot yet undergo that complete process.
- If my understanding of No. 2 is correct, how long do you anticipate before UWP will support all APIs?
Regarding No. 2, if your app is calling a non-compliant APIs you can replace them with an equivalent UWP API and still go through the full process. The big example here is HWND-based UI APIs. Those are not supported in UWP, so you have to CoreWindow based UI.
So as of today, the process can be completed for any developer who wants to move his or her app from Win32 to UWP (as Microsoft broadens the base or surface of APIs covered with each update of Windows 10) because non-compliant APIs can be replaced?
Yes. In practice, depending on the app, the full journey can still be a considerable amount of work though. And UWP still has some gaps compared to Win32, where there is no equivalent API yet. With every new update of Windows 10, this will get better and easier though as we expand the API surface. It's a journey. The nice thing about the bridge is that they can start today and their app will be fully functional and shippable in the Store at all times along the way across the bridge, and they can go at their own pace.
There's no plan to support all legacy Win32 APIs in UWP.
There is no plan to support all legacy Win32 APIs in UWP. However, we strive for UWP to enable all relevant app scenarios - with modern, better APIs. Same example: HWND-based UI APIs are not something we will bring forward into UWP.
That's an interesting point. What other APIs will not be supported and what percentage of legacy Win32 APIs does that affect? Also, can you define what you mean by "relevant" app scenarios?
I don't think this can be expressed in percentage. UWP is a new app model; it is not supposed to be a superset of Win32. Win32 was invented in a time you bought software in a box and installed from disks. In today's world, Win32 has a lot of problems in terms of user confidence, privacy, battery life, etc. We don't want to bring those problems into UWP but want to provide the functionality that the user wants - and make sure the user is in control at the same time.
Win32 apps can run code at any point in time at full privileges without the user's intent, drain your battery, read your files, etc. UWP creates a much higher level of user confidence and control. Developers migrating to UWP will have to make changes to their code accordingly, to make their products better for their users.
How do developers find out if their Win32 program is one that will be supported?
Before starting a conversion, we point developers at the preparation guide on MSDN.
One more thing: My view is that Centennial making Win32 apps into UWP apps, (thus) modernizing the desktop experience, is important to Microsoft's vision for Continuum. Without a modern desktop experience, the "phone as desktop" loses its appeal. Any feedback on that?
That's another good aspect, yes.
Regarding Continuum, note that the app will need to do the full conversion in order to do Continuum. Just running the converter won't get you Continuum. This is because it needs to be able to run on the phone device. And then there is Project Rome - different, but somewhat related topic that we'll talk more about at BUILD.
Wrapping up
Microsoft's ultimate mobile device vision is a long-term journey. What Wick reiterated about the multi-step process of bringing Win32 apps to UWP and the current state of unsupported APIs reinforces my assertion.
Is early 2018 to soon for Surface phone?
The fact that Win32 apps must go through the full conversion process to UWP for Continuum to be effective is a critical point. Though Wick stresses it can be done at the developer's own pace, it's a time-consuming process for some apps.
A rumored Surface phone may not motivate developers to convert their Win32 apps to UWP but the launch of Windows 10 S might. Will developers embrace Project Centennial and the full UWP conversion process? If Microsoft's vision of a phone being a desktop is to become a reality, they'll have to.
Must Read
