Monday, April 11, 2016

Microsoft, update or open source VB6 programming

Sometime around the turn of the millennium, Microsoft has decided to cease to develop Visual Basic. The development environment and the VB-Runtime were frozen at the level of VB6 SP6.
The VB6 runtime is bundled with current Windows operating systems. In a "Support Statement" dated November 2012 Microsoft has confirmed the compatibility of Runtime on the latest operating systems. Literally, it means: 
The core Visual Basic 6.0 runtime will be supported for the full lifetime of Windows Vista, Windows Server 2008, Windows 7, and Windows 8, Which is five years of Mainstream Support Followed by five years of Extended Support. 
The VB6 IDE (development environment) is indeed no longer officially supported, but is still installed and functioning under all current Windows operating systems.
VB programs can be compiled to native-Exes. If no additional components are used, these compilations can be run without installation on the current Windows PCs (partly under Linux / Wine). VB programs start quickly, the speed of execution leaves nothing to be desired.
Editor's Note : We would like to point at this point in the fundraising campaign for the development of a free successor to VB6: A Replacement to Visual Basic 6 IDE and compiler 
https://www.indiegogo.com/projects/a-replacement-to-visual-basic-6-ide-and-compiler

Second part...
vbRichClient
The vbRichClient framework http://www.vbrichclient.com/#/en/About/ is made ​​freely available by the author Olaf Schmidt. This component set was developed specifically for VB and offers a modern GUI framework easy access to SQLite DB and other helper classes for the programmer everyday. As such, the RC5 (short for vbRichClient version 5) can be used as a very useful extension for normal VB applications. Behind the RC5 But there is more: The author sees in the medium term be Framework as a transition to a free platform independent VB successor.
A problem of VB.Net, the official successor of VB, the hard cut, the Microsoft demanded the developers. The migration path offered is not practical. Microsoft has thus lost much confidence in its greatest developer community. The RC5 tried a softer way, a way to VB developers can call, without having to abandon their decades of work from the past at this point.
But what makes the vbRichClient different? The framework integrates seamlessly into the VB6 IDE. On the development computer only has to be a registered total of three DLLs. The other two DLLs ( vb_cairo_sqlite.dll and DirectCOM.dll ) must be in the same folder as the registered vbRichClient5.dll. When users who later used the compiled EXE, registration is not necessary, it is sufficient if the three DLLs are in the same folder as the .exe, or in a subfolder such as \ bin \ . It is important that the two "namespace classes" of the framework ( New_c and Cairo ) previously regfree been instantiated (by DirectCOM.dll API call). An installation-free distribution of your application is also possible. If you want to distribute your application, however, using Setup, then tie the DLLs as normal in the setup script. Using the example of Inno Setup, the following three lines would be: 
Source: "C: \ rc5 \ vbRichClient5.dll"; DestDir: "{app}"; 
Source: "C: \ rc5 \ DirectCOM.dll"; DestDir: "{app}"; 
Source: "C: \ rc5 \ vb_cairo_sqlite.dll"; DestDir: "{app}";
What is easily forgotten, a fourth file, the license.txt is. A template for this file is included with the framework. You should include this file in your setup, because here all (in vb_cairo_sqlite.dll statically linked) open source components and their licenses are listed. Mind you, you will not be seen directly because they are integrated into the above RC5 accompanying DLL these components. These include:
- The Cairo graphics library, it provides a vector-based API and is the basis for the GUI framework from RC5. The CairoContext object can also be used in normal VB forms. Its graphics capabilities allow next antialiased vector output on path definitions also varied image-manipulation (eg all types of alpha-transparent blending, rotations u. Scaling), which works with modern image formats, such as Alpha Resource icons, PNGs , SVG, JPG, and to directly generate PDFs is supported. Also worth mentioning are classes for printing and print preview, or the support for QRCode (in read and write direction).
- The SQLite3 engine provides an ADO-like interface to SQLite databases. SQLite DBs manifest in a single file (similar to * .mdb) and have very widespread, the features are roughly comparable to the JET DB engine (for better performance). Even if your application uses a different database, this library is very convenient, because it also InMemory DBs are supported. These are databases that exist only in memory and are accordingly very quickly. Your application benefits when depositing larger and more complex data structures in a InMemory DB by comfortable search options via SQL.
- Various other helper classes provide support for as multimedia, data compression, data encryption, XML; and web technologies are not forgotten, thanks to HTTP request and fast JSON classes. An in-process bootable WebServer class is integrated, which is helpful in App remoting scenarios or the use of JavaScript frameworks in conjunction with internal use browser controls.

Third part...
The migration path
Phase 1
The vbRichClient5 is incorporated by reference in VB projects. Various classes extend so that VBRuntime with performance graphics, data, operating systems and communication functions. An integrated RegFree concept ensures the integration of third-party ActiveX DLLs without registering on the user's computer. In RC5 see an improved collection object, file system functions, timer, support for gesture control, multimedia, a fast string builder, TCP classes, image and data containers and much more. Some of it you can program itself, some might acquire as an additional component of course in VB. However, the use of RC5 offers these features for free in a well-tested framework that you can distribute to your users easily. In this form of RC5 is a powerful extension for your new or existing VB projects.
Phase 2
The modern GUI framework in RC5 is based on the Cairo library and works vector-based. Beneath the surface, neither the Windows GDI / GDI + DirectX still used. Basically, the library is platform-independent and offers now the basis for a platform-independent as VB successor. The new controls are perfectly normal VB classes (CLS) files that the cWidgetBase derived class (VB usual object-based inheritance). The most basic implementation of such controls is: 
Private WithEvents W hat cWidgetBase
Private Sub Class_Initialize () 
Set W = Cairo.WidgetBase 
End Sub
Private Sub W_Paint (CC As cCairoContext, ..., ...) 
CC.DrawText ... 
End Sub
As you can see, the control gets the Paint event context come to be able to distinguish itself can. This context is also an RC5 property offers modern methods of graphic or text output. So that you can look your controls as you want. The of W provided methods and events are comparable (or go significantly beyond) what one of VB or VB Forms User Controls knows already. But do not worry, you do not have to program each text box itself now. On GitHub see vbWidgets , a RC5-based control library incl. source code. The most important controls are included. You can use this DLL in your project use (mind you: also without registration) or you can use the VB-contained classes and adjust them as desired to their own taste. Of course you can also be derived entirely new controls based on existing classes.
Unfortunately, the controls created so do not appear in the toolbox of VB and can not be like the VB-cohorts pulled on a form. A Cairo-Control, in RC5 Lingo widget called to place on a VB form, it takes a VB UserControl as a wrapper. This can be used together on a form VB own controls and Cairo widgets.

Fourth part...
Phase 3
VB Forms are now also by fully Unicode-enabled widget form s replaceable. Like the widgets and these are CairoForm s normal VB classes. The most basic expression of such corresponding encapsulation in a separate (eg as cfTest named) Form class is:
Private WithEvents shape As cWidgetForm
Private Sub Class_Initialize () 
Set the form = Cairo.WidgetForms.Create (vbSizable, "My Cairo window") 
End Sub
Public Sub Show () 
Form.Show 
End Sub
That's it already with regard to the present in the encapsulating class Minimal codes. To such a form (eg with an existing VB form named frmMain bring) for display, it is sufficient in a * .bas module to write: 
Public FTEST As New cfTest 
Sub Main () 
fTest.Show 
End Sub
In order to use in your VB project in addition to the VB-forms also Cairo-forms and possibly migrate existing VB forms gradually. What I meant above with the soft migration path. One applies it, however, be considered: a VB program ends with the unloading of the last form. But what if you only want to use Cairo-Forms in your project? For this purpose, Cairo prepared a separate message pump. At the end of the sub Main procedure of your project then the following statement should be: 
Cairo.WidgetForms.EnterMessageLoop
This MessageLoop ensures that your VB program is only unloaded when the last Cairo-mold is closed. However, you could use a Cairo program which displays several forms, even quite radical via the following end: 
Cairo.WidgetForms.RemoveAll
In such a development or migration stage your project only consists of modules and class modules. You do not need any more additional controls because everything is covered by Cairo. Your finished program only has a Microsoft-dependence, which is the VB runtime. As we read above, Microsoft assured us that this is for the time being continue to be supported. Measured against the lifecycle of Windows 8, this would be 2024. Enough time to prepare the year to phase 4.
Phase 4
What follows from here is the future, but my product is a bit speculative. Olaf Schmidt is planning a compiler that emits from VB code C code. This should then be translated with a free compiler to native machine code. The aim here is 100% code compatibility translate (initially only) * .bas and * .cls modules. So we write our code continues with the VB IDE and can it therefore debug - using our beloved Edit & Continue. Everything as before. If our program is finished, the program is compiled with the new compiler. In this case also the (already only * .bas and * .cls modules existing) recompiled code vbRichClient DLL and even a static part of the Exe. The function of the VB runtime would thus be eliminated - 64Bit compilations are possible and depend only on the C compiler backend being used. Compiled files will be in the initial phase initially only for the win platform; However, since the classes of the new (RC5-based) Runtime abstract from Win-API calls (in the User Code is extremely rare, the use of declared Win APIs necessary) is thus the way open for a platform-independent compilation.
This requires the RC5 internal implementation of the runtime classes - at the points where currently Windows-system-specific API Declares be used - to appropriate calls to the Flat API to be adjusted for the relevant target-OS. Most of the work in porting an abstracting (and GUI support) classes frameworks on different platforms usually make the calls in the graphics subsystem of the respective OS. Since here, however, with Cairo already a abstracting library that is available on all major popular platforms have in principle only the system-specific calls to the file system (eg behind the methods of the class CFSO ) or the calls for response of Socket Layers (behind the TCP and UDP classes be customized).
After (platform-specific) adaptation of RC5 runtime classes, our programs could then be compiled without major intervention for an alternative operating system, such as Linux.


Fifth part...
Summary
Above, I described a way in which (initially) the existing VB6 IDE quasi as host for editing the * .cls and * .bas modules will use (which are simply translated by the new compiler).
If a new VB IDE, however, should have priority, then it were the other way around (or parallel):
The new IDE could also be developed before (or at the same time for) new compiler - normally using VB6, including the RC5-GUI classes and -Controls. To operate the effort once it would be good if the (still VB6-based) code of this IDE project later from the new compiler without any changes (eg in a 64bit version) would be re-compile to a not only code moderately new, but also in binary form new coupling-off of the old VB Runtime development environment translate. And that would be achieved when the new compiler its target (at least * .bas and * .cls to be fully compatible) complies and only found in the new IDE project this code module types use. And the latter is without problems today with the RC5 classes feasible (and is already given RC5 internally).
Until two projects (new IDE + compiler) are fully implemented in the most important parts and are usable, it is certainly a long and difficult road. However, when I look at my alternatives that also make me not much more optimistic. The perspective that we offer Olaf Schmidt with the vbRichClient realistic, especially since the evidence that it can work, is already provided with RC5. Even in its current form, the framework is a remarkable VB extension.
On the Internet there is much good VB code that can be used in the new environment partly unchanged and partly with small adjustments. The same applies to our own code as well as the experience we have gained in our life with VB programmers. VB was and is one of the most popular programming languages, especially among newcomers. I would imagine that this VB-seed new flourishes like a desert flower, when after a long time gets water.

1 comment: