Last Updated:

Issues related to the development of Windows-based applications

Windows-based applications

The .NET framework solves many problems that plagued programmers in the past. These include application deployment, version control, memory leaks, and security issues. .NET enables you to develop powerful, language-independent, desktop applications, and scalable (extensible) Web services built on top of the powerful new full-featured .NET Framework class library.


Imagine a symphony orchestra in which groups of stringed bowed and percussion instruments have to perform their parts using different versions of the score. In this case, in order to perform even the simplest musical composition, musicians would have to make heroic efforts. This example illustrates quite well the activities of Windows application developers. In the process of work, a number of questions arise before the developer. Should I use Microsoft Foundation Classes (MFC) classes in my application? In which language to write the application, in Visual Basic or in C++? Which database interface to use in your application: Open Database Connectivity Interface (ODBC) or OLE for Databases, OLEDB? Use the Microsoft Component Object Model (COM) or the C-style application programming interface (API) in your application?

If the choice is made in favor of the Microsoft Component Object Model (COM) interface, which interface to use: IDispatch, dual (dual) interface, or only the interface with a virtual table? What role does the Internet play in all this? Until the advent of the .NET platform, quite often the application design was distorted by the technologies used in the process of its implementation, which at that time were owned by developers. Or the developer had to learn another technology, which was destined to be supplanted by the next one in a couple of years.

Deploying an application can be a difficult and frustrating task. In the process of deploying the application, appropriate entries should be made in the system registry, which is quite fragile, and its restoration is not an easy task. In addition, there is no good strategy for versioning components. New versions of applications can destroy existing programs and at the same time it remains only to guess what actually happened. To avoid problems associated with storing system configuration information in the registry, other technologies use metabases or SQL Server for this purpose.

Another issue in Win32 is security. The current security model is difficult to understand. It is even more difficult to use it in practice. Many developers simply ignore it. Developers who were forced to use the existing security system tried to do their best in this difficult programming model. The increasing importance of security associated with the development of the Internet threatens to change a bad situation into a potential nightmare.

Even where Microsoft tried to make the application development process easier, problems still remained. Many system services had to be developed from the start, essentially creating an application infrastructure that had little to do with business logic. A giant step towards the creation of higher-level services was the Microsoft Transaction Server (MTS) and COM+. However, another application development paradigm was required. Microsoft's Component Object Model (COM) has made true programming using components possible.

However, the application could be created quite simply by using the Visual Basic language. But such applications did not have sufficient flexibility. Significantly more powerful applications could be created using the C++ language, but considerable effort was required. And this is not to mention the fact that in C++ you had to constantly write (constantly recreate) a repeating framework (infrastructure) of the application. If I could get rid of all this, I wouldn't miss ILJnknown.