February 25, 2005 15: 04: 01delphi 8 for .NET caused great attention in the Delphi community! People are frequently discussing the .NET infrastructure in the newslets, chat rooms, and small gatherings of users, talk about it with the relationship between the Win32 platform we are familiar with.
One of the hot topics is the VCL for .NET of Delphi8. Most of the arguments seem to focus on this issue: What is the purpose of VCL for .net in this grand plan? It is a short-term transplant bridge or a long-term application framework. Why is Borland to create these things and Microsoft WinForms competition? Really "taste the taste is not easy to say"?
Quiet, there is no need to argue for this problem, really. The reason is as follows.
background
Microsoft. NET framework provides a hardware neutral execution environment and language-independent type system. This is good, but it is not enough to generate a client application based on a Windows operating system. .NET also includes a Windows Form ("WinForms" application framework to create a graphical interface application for Win32 operating systems. Programmers familiar with the Borland VCL application architecture in Delphi or C Builder will find many design modes that have been acquired in the .NET's WinForms framework. This is not very strange: just like Anders Hejlsberg, "Is it a good idea that why not?"
Although there are many similarities between VCL and WinForms, it is very difficult to transplant the existing Win32 VCL application to WinForms due to some key differences. Difficulties means that they are very laborious in adopting new ideas, very restricted ... Just like to sell some tools to bring you as the same labor.
.NET is a new platform. In the software industry, even all new activities are based on .NET, in terms of existing and current WIN32 development, .NET application development is still only a small part. We have earlier that the investigation of the customer's interest in the .NET platform is very clear, many Borland customers have an uncertain interest in .NET is an uncertain interest, they can't afford to give up all the investments of all the investments on the Win32 platform, but complete Start from the new .NET platform. This is still the case today, and this situation will last for many years.
Creating a WinForms in Delphi 8 for .NET is light. Existing Delphi developers tell us: "This is very good, but can we use it for our VCL code? These code is previously created, our business relies on these code."
In order to make our customers more satisfied, and let the .NET platform is more attractive for existing Delphi developers, there are some things to fill the existing Win32 development and the gap between .NET development. It needs to be a pure .NET like the .NET framework itself, it also needs to provide a highly compatibility with the existing Win32 VCL structure. In order to attract existing VCL developers, Delphi for .NET needs a VCL implemented on the .NET platform.
We first consider the VCL on top of the WinForms framework. After some preliminary studies, things have become clear, making it difficult to transplant VCL applications to WinForms, which also make it difficult to build a VCL layer on the WinForms framework, and work according to VCL.
During our evaluation of WinForms, we noticed that WinForms is actually on the Win32 API call. WinForms window class calls createWindow () creates a Wind32 window handle, which hooks Win32's WndProc function to listen for window messages, and trigger the corresponding events in the class, and so on. Their working principle is like a VCL
If the Win32 API call is applied to the Win32 API call in the managed .NET code, it also applies to VCLs. In this way, the process of implementing the VCL on the .NET platform becomes a method of finding how to perform Win32 API calls, which is dependent on the existing VCL architecture, while we can manage the VCL self-code Minimum modification.
VCL for .NET
The VCL architecture is to the Microsoft's WinForms architecture, and VCL for .NET is the continuation and evolution of the VCL architecture. Both WinForms and VCL for .NET are built on the call to the Win32 API, so there is similar platform constraint and similar execution characteristics. For VCL, there is even potential opportunity to run better than WinForms, because VCL achieves a handle, brush, and handle sharing, and WinForms is not. Micro-tuning and exploring these performance opportunities is the continued task of Delphi Development Team, just like the performance of WinfroMs and .NET's performance is the same as Microsoft's continuous task.
VCL has been proven to be adapted to the platform of the platform - from 16-bit Windows to 32-bit WIN95, from NT to the QT-based CLX on Linux. WinForms is tiered tightly with .NET and is largely bundled with Win32.
Description: Although the .NET streamlined frame enables many classes in the WinForms namespace, there are still many things on the CF. There are different or simple deletions. I don't think CF WinForm is compatible with Win32 WinForms in any meaningful extent. Microsoft obviously admits this because they make the .NET CF execution environment and Win32 .NET executable is not compatible on the binary level. The .NET CF system Assembly is a strong named, using different keywords with the Win32 .NET system, so that the win32 .NET executor will load failed on the CF device. The only way to enter the .NET CF is to recompile the source code on the CF and link with the CF's Assembly.
For application code, porting from Win32 VCL to VCL for .NET is quite simple, but for components that are more closely related to Win32 API, it may be necessary to work. This is similar to the case where the transplantation to the CLX is similar. However, Delphi developers will find that efforts required to transplant from Win32 VCL to VCL for .NET are less efforts needed to transplant from Win32 VCL to CLX. VCL for .NET has changed to a large extent, but realizes almost similar message processing, exception handling, and Win32 API support with Win32 VCL. The CLX has to sacrifice the message processing with Win32 API support in order to run on the Linux platform.
The code transplant of VCL for .NET is not one-way. Application code written for VCL for .NET can also be transplanted to Win32 VCL in a reasonable range. Retrait, to maintain the same source code of the cross-platform, those operating code (such as custom controls) that call Win32, which is more difficult than the application business logic written in conventional Delphi syntax. (Routine means to avoid uncertain type conversion and pointer operation.)
Use C # to write an application to let developers completely abandon their existing code and development experience, from the .NET from the beginning. C # puts the developer fully defined on the locked .NET platform. There is no C # implementation on other platforms. (Yes, there is Mono on Linux, but it does not implement Ui / WinForms support, so it is not a completely client application development solution.) VB.NET is almost in the same situation because VB.NET User pain complaining that VB.NET is incompatible with VB even, which makes it possible to take risks in VB.NET and VB. Writing programs for the .NET platform in Delphi language also provides opportunities to transplant the code to other non-.NET platforms (Windows and Linux). Use VCL for .NET to write an application to provide a portable option that is not available in any other .NET language.
VCL for .NET is existing for Delphi programmers
The VCL structure depends on several strong features of the Delphi language, which is generally not available in other .NET language (including C #). However, I don't expect C # or VB programmers to have strong interest in VCL for .NET. C # code can utilize VCL for .NET components, but certain aspects of VCL (such as virtual constructors) will not be significant and difficult to use in C #.
The GUI control implemented with VCl for .NET has only Delphi programmers interested, C # or VB.NET programmers are not more interest.
As long as Delphi developers maintain such an idea, some unique Delphi syntax does not be well understood by C # or other .NET programmers, such as virtual class, virtual constructors, collection, standardized strings, and Class reference, then non-visual components, tool classes, business logic can be implemented with Delphi and is easily used by C # or VB.NET programmers.
WinForms control can be placed on the VCL for .NET form. The VCL for .NET application written by Delphi developers can use the VCL for .NET components and controls at the same time, just like using any WinForms components.
Maybe more important than the actual source code is the development skills of developers. Developers who are familiar with VCL can immediately become familiar with VCL for .NET. How do you create an app in Win32 VCL, or create a custom component, or create a custom message processing, how to create it in VCL for .NET, the way is exactly the same. VCl for .NET allows skilled Delphi developers to immediately become productive on the .NET platform, avoid training developers for a different application framework structure on the .NET platform. .
Delphi language is independent of VCL
VCL for .NET relies on some of the characteristics of the Delphi language, but the Delphi language itself does not require VCL. You can write WinForms applications directly with Delphi syntax without having to drag the VCL for .NET into your application. You can also use the Delphi RTL tool function and classes you are familiar with to write WinForms applications, such as, for example, you don't have to take time to find a function in the .NET and Delphi's intTostr () equivalent.
Each programming language must define how it is binding its language characteristics with the schema available to the lower platform. In .NET, this lower layer architecture includes code such as a core language type. The Delphi language has the concept and semantics that the CLR does not implement, so Delphi requires a little code on language binding to supplement the part of the CLR provided. This language binding may be directly coupled to your Delphi application EXE or Assembly, or you can also join an externally called Borland.Delphi.dll asSembly (PACAGE). Each .NET language has a language binding library. VB.NET's Microsoft.visualBasic.dll size is approximately 300K. JScript's Microsoft.jscript.dll is about 700K. The language binding library size of C # is approximately 3 to 20MB, depending on whether you also take Mscorlib.dll and System.dll, or calculate the minimum installation of all C # needed. Delphi's borland.delphi.dll is less than 64K in size.
Whether it is invested in VCL source code and developer skills (using VCL for .NET), those who are willing to start with heads only on the .NET platform (using WinForms), Delphi for .NET will cause Their interest.
Prepare
On Microsoft's long-term platform / operating system roadmap, there is a significant change in the next primary release version of the Windows operating system. It is clear that the Microsoft operating system of the code "long" will have a major change in the interface with the lower level. The Win32 API will become a compatible layer between the legacy Win32 program and the actual OS representation. Microsoft has established a new application framework for the long-range operating system ("Avalon"). You can read more about the framework on the MSDN.
Many times will cause panic. So I am very happy to learn that WinForms applications can continue to be used on long-range and subsequent versions from Microsoft. Vcl for .NET is based on the same basis as WinForms, so the VCL for .NET application should continue to run on the long and its subsequent versions. VCL has experienced several platform transplants (from Win16 to Win32, from Win32 to Linux, now from Win32 to .NET), this is more than WinForms, so there is reason to think that VCL fot .net is more easily adapted than WinForms. There is a change in the long-range operating system.
All of this adds the VCL for .NET to become a stronger similar system than the WinForms architecture. For existing VCL applications, rewrite this way compared to WinForm, VCL for .NET has a longer available lifetime, rather than as a temporary unidirectional transition program, and more better Investment returns (ROI).
Why rewrite your app? Migrating your existing VCL application to VCL for .NET can obtain the same result at less effort. Even if VCL for .NET is turned off with WinForms, VCL for .NET also means a better return on WinForms.
This is why we build VCL for .NET.
in conclusion
For new applications, Microsoft's .NET platform Windows Form Application Architecture is a reasonable architecture that is intended (by Microsoft - translation), but the cost of using WinForms is expensive because it can't Existing source code transplantation.
Borland's VCL for .NET architecture provides the best two aspects for Delphi developers: it allows you to develop existing source code and development experience in a new, growing .NET platform, simultaneous Minimum time loss to use new tools and re-study. Danny ThorPedelphi Compiler Architect, .NET Team Personal Software Company
