Last week, a key event occurred in the history of personal computing. It marks the beginning of the death of the operating system that we recognize today as Microsoft Windows.
This euthanizing of Windows has been planned for at least five years, and Microsoft knows that it is necessary for the company's software business and for the PC industry to evolve and stay healthy.
In order for the Windows brand and Microsoft's software business to live, Windows -- as it exists today -- must die.
It is important we have some historical perspective of what "death" actually means for Windows because it's already happened twice.
The first of Windows' lives occurred in the period between 1985 and 1995. During this time, Windows was a bolt-on application execution environment that ran on top of the 16-bit DOS operating system, which was introduced with the original IBM PC in 1981.
That OS "died" in 1995, when Windows 95 -- the first 32-bit version of the OS -- was released.
From 1989 to 2001, on a separate track, Microsoft also developed Windows NT, a 32-bit, hardware-abstracted, full pre-emptive, protective memory, multi-threaded multitasking OS designed for high-performance RISC and x86 workstations and servers.
The commonality that the consumer version of Windows and Windows NT had was that they shared many of the same APIs, which are collectively known as Win32.
Largely implemented using the C programming language, Win32 became the predominant Windows application programming model for many years. The majority of legacy Windows applications that exist in the wild today still use Win32 in some form. (This is an important takeaway that we will return to shortly.)
In 2001, Windows NT (at that time branded as Windows 2000) and the consumer version of Windows (Windows ME) merged into a single product: Windows XP.
Thus, the second generation of Windows technology descended from Windows 95 "died" at this time.
Shortly after the release of Windows XP, in 2002, Microsoft introduced the .NET Framework, which is an object-oriented development framework that includes the C# programming language.
The .NET Framework was intended to replace the legacy Win32. It has continued to evolve and has been slowly adopted by third-party ISVs and development shops. Over the years, Microsoft has adopted it internally for the development of Office 365, Skype, and other applications.
That was 16 years ago. However, Win32 still is the predominant legacy programming API. More apps out in the wild use it than anything else. And that subsystem remains the most significant vector for malware and security threats because it hosts desktop-based browsers, such as Internet Explorer and Chrome.
A lot has changed in the technology industry in 16 years, especially the internet. Web standards have changed, as have the complexity and sophistication of security threats. More and more applications are now web-based or are hosted as SaaS using web APIs.
Microsoft introduced a new programmatic model with the introduction of the Windows 8 OS. That framework, which is now commonly known as Universal Windows Platform (UWP), is a fully modernized programming environment that takes advantage of all the new security advancements introduced since Windows 8 and that are in the current Windows 10.
While Windows 8 was not well-received in the marketplace because of its unfamiliar full-screen "Metro" UX, the actual programmatic model that it introduced, which was greatly improved for desktop-style windowing in Windows 10, is technically sound and much more secure than Win32 due to its ability to sandbox apps.
In addition to including the latest implementation of.NET, UWP also allows apps to be programmed in C++, C#, Objective-C, VB.NET, and Javascript. It uses XAML as a presentation stack to reduce code complexity.
Microsoft Edge, the completely re-designed browser that was introduced in Windows 10, is a native UWP application with none of the security drawbacks of Internet Explorer. Other native UWP applications include Windows Mail, Skype for Windows 10, and some of the applications in the Windows Store.
DEVELOPER LAZINESS?
WELCOME, WINDOWS 10 CHROME
BROWSER A CASUALTY
LIMITATIONS?
It could be said that the third Windows death, the end of the Win32 API, is long overdue. It has existed in some form or another since at least the late 1980s. But what has been keeping it alive?
Some of it is developer laziness. It's not like they haven't had 15 years to learn and adopt .NET and the past five years to adopt Metro/Modern/UWP.
To be fair, many of them have incorporated certain aspects of .NET into their apps as they kicked the can with their legacy codebase down the road, such as with the use of Windows Presentation Foundation (WPF) in .NET 3.0. But in a lot of cases, fully migrating code bases to UWP from Win32 would mean complete re-implementation.
That takes time and money.
Not all of this is developer laziness; it's also the systemically bad end-user and IT organizational habits of keeping old versions of apps around rather than move into newer licensing models and newer versions of the apps.
These legacy apps, many of which are running long past the expiration of their last service pack and ISV recommendations to decommission them and end-of-life notices, are of course far more likely to be susceptible to security threats.
A lot of ISVs are going the SaaS and web app route, or are providing their legacy apps in hosted desktop environments while they develop modernized web and SaaS apps to replace them.
Win32's persistence and hanging on extended life support puts Microsoft in a bad situation.
So what kind of shape is UWP in today? Is it ready for developers to move to as a complete replacement programming model for Win32?
With Windows 10 and UWP, the company finally has a modernized OS that is ready to host the desktop and mobile application workloads of the 21st century. It's secure and it finally makes good on the company's Trustworthy Computing initiative that it began in 2002.
A lot has changed over the last five years since the original Metro/WinRT programming stack was introduced with Windows 8.
Indeed, many of the API changes have not been rolled out in a developer-friendly fashion and a lot of the applications currently delivered in the Windows Store are based on older API versions and are not "universal" by any stretch.
That being said, the current implementation of UWP is quite good, and anything written to it will run on any architecture that UWP runs on, which includes all the versions of Windows 10, XBOX One, and the Hololens.
There aren't many notable examples of them, but if you have a Windows 10 phone, which uses ARM and Windows 10, which is x86, and if you buy a UWP app on the Windows Store, the developer has the option of offering one that runs on both, using the same code.
My preferred Twitter client, Tweetium, is one of these -- so are the built-in Mail and Calendar apps on Windows 10.
The more web standards that are incorporated into your UWP apps, and the more code that is executed directly on the cloud itself, the more portable, the more lightweight, and more mobile your code is.
Unfortunately, the only problem with Windows 10's advanced security model is when you run legacy apps on it. That's the double-edged sword of backward compatibility.
Microsoft's only choice to move forward is to throw the Win32 baby out with the bathwater. And that brings us to the introduction of Windows 10 S.
Windows 10 S is just like the Windows 10 you use now, but the main difference is it can only run apps that have been whitelisted to run in the Windows Store. That means, by and large, existing Win32-based stuff cannot run in Windows 10 S for security reasons.
To bridge the app gap, Microsoft is allowing certain kinds of desktop apps to be "packaged" for use in the Windows Store through a tooling process known as Desktop Bridge or Project Centennial.
The good news is that with Project Centennial, many Desktop Win32 apps can be re-purposed and packaged to take advantage of Windows 10's improved security. However, there are apps that will inevitably be left behind because they violate the sandboxing rules that are needed to make the technology work in a secure fashion.
One of the key benefits of Centennial apps is that even though they run with normal user privileges, they still take advantage of some OS isolation so they can be seamlessly removed from the device. They are packaged/compartmentalized and are updated directly from the Windows Store (which helps to avoid "Windows rot").
Win32 apps put a tremendous drag on the on the developer ecosystem -- and Centennial is a straightforward and easy step toward removing that drag. For application developers, it also provides some great analytics tools as well for software distribution to various markets.
Centennial is also an acknowledgment on Microsoft's part that Win32 apps are here to stay and developers aren't going to move off of them wholesale. Instead, it gives developers the ability to take baby steps with their application and get them into the Windows Store (which in turn helps Microsoft, because it makes the store ecosystem more relevant to customers).
Some Win32 apps can probably be remediated for Centennial easily, some cannot. The more legacy an app codebase is, the worse shape it is probably in.
A casualty of those sandboxing rules is Google's Chrome browser. For security reasons, Microsoft is not permitting desktop browsers to be ported to the Store. In theory, Google could build its own compatible UWP browser, but it would bear little resemblance to Chrome on the desktop. The default browser, for now, is Microsoft Edge, period.
As it stands, you also can't change the default search engine to Google from Bing either. All of this is done under the auspices of improved security.
Obviously, not everyone is going to be able to run an OS like Windows 10 S overnight. So Microsoft is using the Surface Laptop and other low-cost systems in the $200 to $300 range made by OEMs as a trial balloon to test the waters of the end-user market.
Who is Microsoft targeting? Education and Home users and those who mostly use the browser to do daily tasks and don't use legacy desktop-based line of business applications. That's the exact same demographic that Google is targeting with Chrome OS.
You can accuse Microsoft of many things, but sitting on its laurels and being risk-averse is not one of them. There's a lot of risk in releasing a version of Windows and accompanying systems that cannot run a preponderance of legacy Windows applications out of the box.
However, the reward, if successful, will be tremendous. Not just for Microsoft itself but also for the end-users that will have a much more secure computing experience to show for it.
There is clearly much more work that has to occur to ditch Win32 beyond getting the majority of users on a Windows OS that doesn't run legacy code.
Microsoft needs to build modernized versions of Office in order for enterprises to move, for starters. And we are years out from that becoming the desired deployment model for Office, even if Microsoft wanted the next version of 365 to be UWP-based, which we presume it does.
To realize that endgame, another half of the future Windows OS has to mature that end-users don't see. And that's Azure.
I like to think of this as like the building of a transcontinental tunnel, like the kind they built between England and France. One-half is the modern, security-enhanced version of Windows 10 that runs only UWP and Centennial stuff. The other is the cloud back-end that makes much of it possible.
Like burrowing out the transcontinental tunnel, at some point, the tunneling machines will eventually meet in the middle.
Today, Office 365 is deployed as "Click-to-Run" desktop code. It is a type of application packaging technology that is derived from App-V, which is a virtualization technology that is also referred to as application sequencing.
The Office client applications are also updated every month as part of your Office 365 subscription, so as long as you don't turn updates off you are always running the most current version of Office.
But it still all executes locally on the device. It is not hosted remotely, like Citrix, nor is it a web app.
How does Click-to-Run get around the problem that the installer is Win32? It copies the sequence of files that gets installed, but that doesn't change the fact that the Office code that runs is still Win32.
Third party installer tools developers use can also create Centennial compatible app packages.
All Windows 10 users can still be able to get a lot done out of the box because the web-based Office Online already runs well using Edge. You can be reasonably productive in a business environment using strictly those apps, especially if you need to share and collaborate on Office docs with other people.
There are definitely some limitations but I would say for at least 50 percent of workers who use Office on a day to day basis, the web versions of the Office apps get the job done.
Surface Laptop owners will get a free one-year Office 365 subscription that will work with the Office desktop software pre-loaded onto their devices and updated from the Store. Qualifying educational customers -- who have free licenses of Office 365 for Education --will also be able to use that desktop app with their Office subscription. In fact, anyone with an Office 365 subscription, using any edition of Windows 10, can use that Store app.
Today, the Click-to-Run/App-V software distribution technology is tied largely to the x86 platform because of the way desktop apps are written. But UWP apps don't have this limitation; they can run on Windows 10 Mobile, or in theory, a Windows 10 PC running on an ARM processor.
Those types of ARM-based systems don't exist today. The original Surface RT, which was an early attempt at this, failed. It was also underpowered, which didn't help.
But in a few years, they could return, because Microsoft has done all of the hard work since its Windows 8 mishaps to undergo full platform convergence.
The ARM architectural licensees like Qualcomm, Samsung, TSMC, Nvidia, Huawei, and others now manufacture powerful, 64-bit, multi-core SoCs that have plenty of CPU and RAM headroom as well as fast bus speeds to run an OS like Windows 10 S easily.
As Microsoft's Azure cloud evolves and the 365 Online offerings become more and more sophisticated, more apps using web APIs can be wrapped as UWP. This also goes for third-party web apps, including Google's, if the developers put some minimal effort to optimizing their web apps for the Edge rendering engine.
Just take a look at Kiwi for Gmail, which a single, third-party developer wrote. No Chrome engine or desktop code required. It makes all the Google apps look like modern Windows apps. A company with Google's resources could certainly make UWP apps look very polished indeed. Whether it's actually willing to is another matter altogether, due to its own desire to control its application ecosystem and userbase.
There will be less and less need for legacy desktop apps running on client devices, particularly when legacy code can be isolated in Azure using virtual machines and containers for improved security. That's where stuff like XenApp Essentials and XenDesktop Essentials by Citrix and other third-party desktop hosting technologies like IndependenceIT come in.
It also wouldn't surprise me either to see some type of Windows container technology to be deployed on the client device directly in a future version of Windows 10 S so that UWP and Centennial apps can be totally isolated from each other, a la Bromium.
Windows, as we know it today, based on the legacy Win32 APIs that have been around for decades, will die. That's Microsoft's intention as well as its current mission to improve the overall computing experience for everyone. But Windows as a brand will continue, as a secure operating system optimized for applications that heavily leverage public and private clouds.
However, our definition of personal computing and also the PC will also change with it.
Sources: zdnet
Hey My Readers and Visitirs If You Like Us or Our Web Site Please Share and Link back To My Site ... Take Care .,.,.
.png)
0 comments:
Post a Comment