Windows 8 for developers: a dream renaissance? (1/2)
Earlier this month, Microsoft was somewhat shocked by Windows developers: the .NET platform, which the company had been promoting over the past decade as the main developer, would not be used to build applications for the new Windows 8 interface . Instead, developers should use HTML5 and JavaScript.
Many of them, naturally, wondered who had not yet received an answer: “How can I use my experience to develop new applications?” Microsoft is silent and does not plan to report anything before the BUILD conference (former PDC) in September.
But, probably, not everything is as gloomy as many think. The early builds of Windows 8 leaked to the Internet, and significant efforts were made to understand how they work. Well, it looks like the development of applications for Windows 8 is not only not terrible, but it will finally be able to save developers from many annoying obstacles in their way. If Microsoft manages to implement everything planned, the next version of Windows will become just as important a release as the release of Windows Longhorn should have been.
To understand what's what, you should spend some historical excursion.
Before the .NET platform was introduced, Windows applications were developed in two ways. “Large” applications, such as Office, Photoshop or Netscape Navigator, were written using the Win32 API and C ++. The Win32 API is a large set of functions that provide low-level access to such things as displaying graphics and user interface, transferring data over the network, access to the file system, as well as many other less obvious ones, such as security management.
')
The Win32 API solved many tasks, but many of them are not the best way, and some of them are not at all. So, despite the availability of functions for accessing databases, developing an application that actively uses them was very inconvenient. But a much more urgent problem was that the Win32 API has only a basic set of tools for building a user interface, and it lacked any means to control markup. Each button, each field and toolbar had to be manually positioned by the developer. If the developer wanted the position of the elements to change with the resizing of the window, no problem - he just had to re-arrange them with each change. Of course, over time, many libraries appeared that served as a layer between programmers and the operating system, simplifying the drawing of interfaces (including the Microsoft MFC library), but the need to dive into the Win32 jungle to make everything work the way you need has not disappeared .
Another way to develop applications for Windows was Visual Basic. Thanks to him, some tasks were solved really simply - in particular, access to the database and the creation of user interfaces - which made Visual Basic the king in the world of enterprise applications, which required not much more than taking information from the database, showing it to the user and displaying the form to make new data in the database. With all this, Visual Basic handled flawlessly. With everything else, he had problems, because Visual Basic could not use many of the features of Win32. Also, Visual Basic did not support the rather popular OOP paradigm.
And then the .NET platform appeared and changed everything. .NET made it easy for developers to use Visual Basic, but without its unpleasant flaws. Similar to Visual Basic, .NET provided convenient tools for building user interfaces and interacting with databases, that is, it was highly suitable for developing enterprise applications. But, unlike Visual Basic, .NET also made accessing Win32 easy, embarrassing to say, one of its functions. The platform quickly gained momentum in the corporate environment, and many new commercial projects were based on it.
Windows XP, released a year before .NET, of course, did not use this technology. But, at the PDC in October 2003, Microsoft promised to fix it by releasing Windows Longhorn. This version of Windows was supposed to have .NET FX (it was called .NET inside the company) as part of the operating system kernel, and .NET FX, in turn, gave way to the new WinFX platform - the Windows Framework. Among other things, WinFX included a completely new way to develop scalable vector hardware-accelerated user interfaces, called Avalon. Windows itself had to be written using WinFX in its own applications, such as explorer, calculator, and so on, and .NET became the main tool for creating applications for Windows. Win32 would be left for backward compatibility, but frozen and forgotten.
Longhorn had to bury the old ways of writing programs and begin a new era of modern development, not burdened with architectural solutions ten to fifteen years old.
As we all know, Longhorn never saw the light. The project has grown into something huge and unmanageable. At the same time, Windows XP, on which Longhorn was based, began to be attacked by intruders, and Microsoft directed its efforts at enhancing the security of Windows XP and Windows Server 2003, which resulted in Windows XP Service Pack 2 and Windows Sever 2003 Service Pack 1, and then engaged in the development of the next operating system, based on old principles and now known as Windows Vista.
One of the main victims of the change in the course of developing Windows has become .NET. Windows Vista, although it did have some radical changes, left the whole concept behind WinFX overboard. Avalon (named Windows Presentation Framework - WPF) was included in the system, but was not part of the kernel. Media Center is the only significant carrier of .NET code in Windows Vista and Windows 7 (and even it does not use WPF). All the rest is the good old Win32, with the updated and advanced. Numerous low-level functions were added to it, as well as support for changes in the graphics system, such as thumbnails of running applications on the taskbar or Aero Glass themes. None of these changes worked fine with WPF.
There were several reasons for this, for example, the lack of the necessary amount of time to rewrite everything using .NET. But perhaps the most significant reason was the internal division of Microsoft into groups.
Windows was developed in the Windows Division (WinDiv) group, and .NET - in the Developer Division (DevDiv) group, which in turn was part of the Server and Tools business group. And although it is logical to assume that these two groups acted in concert, this was not the case. Not by someone's malicious intent - they just had different priorities.
Some of these priorities had a definite meaning at one time. So, WPF could only be used by .NET programs written in C # or Visual Basic .NET. Its entire API was inaccessible to programs written in C ++, which was a significant impediment for porting existing applications to WPF. This made sense if all the new programs were to be developed using the .NET platform, but when the plans changed and Win32 regained the title of the main development tool, it became a big problem. Microsoft could not use WPF to create elegant vector scalable hardware-accelerated interfaces in its core applications.
Other priorities were the result of a trivial discrepancy between the WinDiv and DevDiv activities. The goal of DevDiv was to make .NET the most convenient platform for developers by adding new functionality and creating libraries and tools like Silverlight. For WinDiv, it was important to maintain the aforementioned backward compatibility, reliability, and also to fix existing technical problems. Both that and another, certainly, was important, but DevDiv did not submit to WinDiv and did not give it due attention. As a result, WinDiv was not comfortable working with .NET, and it was convenient to work without it.
Subsequent updates of .NET have improved the situation, but the damage has already been done. WinDiv, unhappy with the work of DevDiv, ignored their work, and Windows 7, like its predecessor, uses .NET only for Media Center. All of the new Windows 7 APIs are classic Win32 APIs and do not have direct access to .NET programs, and ordinary Win32 applications have not received a great framework for building user interfaces.
Windows 8 will put an end to all this.
Ps. This was the first part of the translation, and published at the request of andrewpey . Thank you Tutufa for an invite.
Update.
The second part of the translation is here.
From the translator: it should be understood that all the above information is only speculation of a non-Microsoft author, and is presented here solely for understanding the problems facing Windows.
Many of them, naturally, wondered who had not yet received an answer: “How can I use my experience to develop new applications?” Microsoft is silent and does not plan to report anything before the BUILD conference (former PDC) in September.
But, probably, not everything is as gloomy as many think. The early builds of Windows 8 leaked to the Internet, and significant efforts were made to understand how they work. Well, it looks like the development of applications for Windows 8 is not only not terrible, but it will finally be able to save developers from many annoying obstacles in their way. If Microsoft manages to implement everything planned, the next version of Windows will become just as important a release as the release of Windows Longhorn should have been.
A bit of history
To understand what's what, you should spend some historical excursion.
Before the .NET platform was introduced, Windows applications were developed in two ways. “Large” applications, such as Office, Photoshop or Netscape Navigator, were written using the Win32 API and C ++. The Win32 API is a large set of functions that provide low-level access to such things as displaying graphics and user interface, transferring data over the network, access to the file system, as well as many other less obvious ones, such as security management.
')
The Win32 API solved many tasks, but many of them are not the best way, and some of them are not at all. So, despite the availability of functions for accessing databases, developing an application that actively uses them was very inconvenient. But a much more urgent problem was that the Win32 API has only a basic set of tools for building a user interface, and it lacked any means to control markup. Each button, each field and toolbar had to be manually positioned by the developer. If the developer wanted the position of the elements to change with the resizing of the window, no problem - he just had to re-arrange them with each change. Of course, over time, many libraries appeared that served as a layer between programmers and the operating system, simplifying the drawing of interfaces (including the Microsoft MFC library), but the need to dive into the Win32 jungle to make everything work the way you need has not disappeared .
Another way to develop applications for Windows was Visual Basic. Thanks to him, some tasks were solved really simply - in particular, access to the database and the creation of user interfaces - which made Visual Basic the king in the world of enterprise applications, which required not much more than taking information from the database, showing it to the user and displaying the form to make new data in the database. With all this, Visual Basic handled flawlessly. With everything else, he had problems, because Visual Basic could not use many of the features of Win32. Also, Visual Basic did not support the rather popular OOP paradigm.
And then the .NET platform appeared and changed everything. .NET made it easy for developers to use Visual Basic, but without its unpleasant flaws. Similar to Visual Basic, .NET provided convenient tools for building user interfaces and interacting with databases, that is, it was highly suitable for developing enterprise applications. But, unlike Visual Basic, .NET also made accessing Win32 easy, embarrassing to say, one of its functions. The platform quickly gained momentum in the corporate environment, and many new commercial projects were based on it.
A dream called Longhorn
Windows XP, released a year before .NET, of course, did not use this technology. But, at the PDC in October 2003, Microsoft promised to fix it by releasing Windows Longhorn. This version of Windows was supposed to have .NET FX (it was called .NET inside the company) as part of the operating system kernel, and .NET FX, in turn, gave way to the new WinFX platform - the Windows Framework. Among other things, WinFX included a completely new way to develop scalable vector hardware-accelerated user interfaces, called Avalon. Windows itself had to be written using WinFX in its own applications, such as explorer, calculator, and so on, and .NET became the main tool for creating applications for Windows. Win32 would be left for backward compatibility, but frozen and forgotten.
Longhorn had to bury the old ways of writing programs and begin a new era of modern development, not burdened with architectural solutions ten to fifteen years old.
As we all know, Longhorn never saw the light. The project has grown into something huge and unmanageable. At the same time, Windows XP, on which Longhorn was based, began to be attacked by intruders, and Microsoft directed its efforts at enhancing the security of Windows XP and Windows Server 2003, which resulted in Windows XP Service Pack 2 and Windows Sever 2003 Service Pack 1, and then engaged in the development of the next operating system, based on old principles and now known as Windows Vista.
One of the main victims of the change in the course of developing Windows has become .NET. Windows Vista, although it did have some radical changes, left the whole concept behind WinFX overboard. Avalon (named Windows Presentation Framework - WPF) was included in the system, but was not part of the kernel. Media Center is the only significant carrier of .NET code in Windows Vista and Windows 7 (and even it does not use WPF). All the rest is the good old Win32, with the updated and advanced. Numerous low-level functions were added to it, as well as support for changes in the graphics system, such as thumbnails of running applications on the taskbar or Aero Glass themes. None of these changes worked fine with WPF.
There were several reasons for this, for example, the lack of the necessary amount of time to rewrite everything using .NET. But perhaps the most significant reason was the internal division of Microsoft into groups.
Windows was developed in the Windows Division (WinDiv) group, and .NET - in the Developer Division (DevDiv) group, which in turn was part of the Server and Tools business group. And although it is logical to assume that these two groups acted in concert, this was not the case. Not by someone's malicious intent - they just had different priorities.
Voltage point
Some of these priorities had a definite meaning at one time. So, WPF could only be used by .NET programs written in C # or Visual Basic .NET. Its entire API was inaccessible to programs written in C ++, which was a significant impediment for porting existing applications to WPF. This made sense if all the new programs were to be developed using the .NET platform, but when the plans changed and Win32 regained the title of the main development tool, it became a big problem. Microsoft could not use WPF to create elegant vector scalable hardware-accelerated interfaces in its core applications.
Other priorities were the result of a trivial discrepancy between the WinDiv and DevDiv activities. The goal of DevDiv was to make .NET the most convenient platform for developers by adding new functionality and creating libraries and tools like Silverlight. For WinDiv, it was important to maintain the aforementioned backward compatibility, reliability, and also to fix existing technical problems. Both that and another, certainly, was important, but DevDiv did not submit to WinDiv and did not give it due attention. As a result, WinDiv was not comfortable working with .NET, and it was convenient to work without it.
Subsequent updates of .NET have improved the situation, but the damage has already been done. WinDiv, unhappy with the work of DevDiv, ignored their work, and Windows 7, like its predecessor, uses .NET only for Media Center. All of the new Windows 7 APIs are classic Win32 APIs and do not have direct access to .NET programs, and ordinary Win32 applications have not received a great framework for building user interfaces.
Windows 8 will put an end to all this.
Ps. This was the first part of the translation, and published at the request of andrewpey . Thank you Tutufa for an invite.
Update.
The second part of the translation is here.
From the translator: it should be understood that all the above information is only speculation of a non-Microsoft author, and is presented here solely for understanding the problems facing Windows.
Source: https://habr.com/ru/post/122684/
All Articles