So in this discussion I am going to explain why Microsoft wants this bridging between desktop and UWP and we are also going to dive into the process of how it will work. So let's start rolling:
Why Microsoft Wanted this Project ?
Making Windows Store better:
There are a huge number of developers who just learn the C# or Vb.net like me and start developing desktop applications and the number of desktop applications till now are more than 16 million. Now when Microsoft started shifting towards bringing all the technologies onto one platform they just skipped this part of 16 million+ desktop applications and the desktop developers were like Oooooo gooosh!! What we can do to take advantage this universal platform and the features involved in it. Many developers surely thought about learning new technologies and have done some hack or custom logics to creat the live tiles etc. Now here's the main reason. Which developer will not want to have his application running across all the devices Microsoft has created like Hololens , Windows phone etc and more importantly Windows 10 is running on billions of devices and image what would be the impact if we can convert those 16 million+ desktop applications to the Universal Windows Platform yielding a great and bulky Windows Store and a great opportunity for the Windows Form/Desktop Developers to have their Application accessible across those billions of devices. So finally Microsoft designed a technology which is for taking care of the missing part of millions of desktop applications. The project name is Project Centinniel or Desktop Bridge and in the Anniversary update of Windows 10 it will be available for all the developers.
Easy Installation and Un-Installation of Application:
When we bought a new Laptop/ Personal computer, it runs so fast. It boots fast, it opens every file very fast and all of the features are pretty much fast. But with the time, it get slowed and all of the functionality which was very fast, periodically get slow down. Why is the reason for that? You will get this answer shortly.
When you install an application to the desktop through an installer, what the installer does is that it goes to the registries of the Windows and add some new files there and then there is an Application Folder App_Data it includes all the files that the application stores while running and there are some other files which get piled into the memory. Now When we re-install an application, It is impossible to remove all of the files associated with that application and even if you want to remove those let's say we want to remove the registries of that application, the operating system will give you a big dialog showing a dialog box saying like if you delete or modify this registry you will never be able to reboot or blah blah blah your System. So what the system eventually has to do is that when the system reboots it has to load all those registry files and it starts taking time giving you a latency period in the functionalities. For Example Every developer would have installed Visual Studio at any time, this studio saves about 1 million registry files in the system and it's around 30 Megabytes of just registries.
As compared to the Desktop Applications , UWP Applications has nothing to do with all of the above mentioned process and their Un-installation removes the whole application from the system leaving no extra files because the Universal Windows Applications has all of these files in their respective folders , So removing those isn't a big issue. So this is how the Desktop applications when being converted to the Universal Windows Applications are going to be left with no extra files not causing the System to have the latency. I will discuss it later how does it happens.
Solving Performance Issues
Desktop applications don't have an application life cycle events just like the Universal windows Applications have. Like onNavigatedTo and onNavigatedFrom. So let's create a mock Scenario. You have an desktop application running which is doing some heavy CRUD operations using Entity Framework and when you put your computer to sleep, what actually happens is that your desktop application also goes to sleep with the system staying in memory. Now notice that there is not mechanism that tells the application that our system is going to sleep so please release the resources or in this case close out all the connections of the Database. So UWP address this problem. The applications there has an Application Lifecycle which can determine if the application is paused or stop etc and the we can perform the related operations accordingly resulting in the less usage of the resources and giving some extra performance.
Runtime Memory Optimization:
As stated above, in case of Windows Desktop Applications the system when reboots it has to load all the registry files first. In Case of UWA, Applications works all with the registry files when they are started not when the system is started. So UWP offers the runtime optimization as compare to the desktop applications. So this gives Microsoft another strong reason to have this project underway.
Deep Dive Into Working of Desktop Bridge:
I know till now there will be some obvious questions and some strange feelings about how it will fix the registries or how Universal Windows Applications will allow the third party components to get embed into it. All of these questions will be answered when you will understand the working of this project.
Now there are basically three main steps of converting your Application using the Desktop Bridge:
- Convert the Application using the Desktop Bridge
- Test your Converted Application
- Deploy your Application
Sounds pretty much. The first step is solved through some small scripts in the power shell provided by the Desktop Bridge. The third and second steps do not have so much to discuss about. So let's discuss about the first step and reveal the hidden secrets behind it.
Conversion of Application:
The desktop bridge in simple converts the Win32 application into the AppX Package. The AppX package consists of all the files for the deployment of the UWA. Now let's discuss about how the registry stuff yielding the performance upgrade will happen. Keep in mind the App should be signed before the conversion means the App should have digital certificates just for the security purposes.
- The AppX package created by the Converter consists of an file known as Registry.bat. This will be the file which will be responsible for all the handling of the registry files. Now what will happen when the process of registries will come into play. The files in the AppX package are mock files. Understand the work flow now. The registry files will first go into the same place as all the other registries but the developers of this bridge tricked it there and re-direct those registries to the AppX package. The system thinks that the registries are saved in the same place as others but actually it is in the folder. You can just think it of as Virtualization. Same goes for the App_Data folder. Creators tricked this part too and re-direct the system to the same folder resulting in the data at just one place and deletion of data will be only from one place.
- After the conversion process now there are two processes in AppX. One is the primary desktop application and the other is the Universal Windows Application running in the App Container. Now there are two possibilities. Either the Desktop Application can communicate with the Universal Windows Application or the Universal Application can communicate with the Desktop Application. Now How it is going to happen. Actually Microsoft has already a solution for this. So it is already built and the Solution is "App Service". Using the App services , it can result in the bi-directional communication between the two. Now here's your answer coming about how the external Dll's will be used in the UWP and that will be through the App Service resulting in the application. I don't have a demo for this but I will Surely show that demo after the converter will be shipped. If the UWP will be wanting to use any third party application it will ask the desktop application to perform it and UWP can then process the final result.
- Though after the two processes conversion, The windows store will not allow to deploy an application that has further some applications installed in it. So after having the two process we have to create one process. Yet I don't have any clue about how to do it but Microsoft is working on All the API's which are not allowed by the developers to use in the UWA's.
- After this all process, the same Win32 Application can leverage the benefit of background tasks, Cortana,Live Tiles and able to run on billions of devices.
- Every Application that is converted into the UWP will get an App Identity for registration of being able to send push notifications and live tiles. The App Model for the installation and Un-installation of the application.
Minor Disadvantage:
There is just one disadvantage of this Desktop App Converter I have So far pointed out is that the some Win32 Applications are definitely going to use some drivers and going to install those into your system while installing. The Converted UWP Application will just not be able to install the drivers but will be able to use those if those are already installed.
For the Sake of Information Saga2000 was the first desktop Application which was converted using the desktop bridge to the Universal Windows Platform and got the privileges of having the features of UWP.
Its Incredible... Very impressive
ReplyDeleteThanks bro for such an informative blog
ReplyDeleteHelpful and informative...
ReplyDelete