Migrating from Visual Basic

Classic Visual Basic 6(VB), as opposed to VB.NET, is a good language for developing small applications and modules. It is essentially a single threaded environment and building Graphical User Interfaces (GUI) is very easy. If you want to develop an application that dynamically displays realtime data such as stock prices, then use a Commercial Off-The-Shelf (COTS) graphing tool, and a proper data acquisition tool. Set a timer to poll the real time data and pass on the values to the graphing tool. It is mostly a case of drag and drop and very little manual coding is involved. Similarily developing a form to query and update databases directly or through a middle tier is fairly straightforward. This can be scaled to include a large number of forms in a single application including sophisticated forms like reports that include charts and pictures.

So far so good. Where it fails is that in protecting the developer from the intricacies of the message pump and multi-threading, Visual Basic denies the developer the opportunity to use those features effectively. There are work-arounds but these are tricks that bring Visual Basic into an environment that it is not suited for and requires far more knowledge about Windows OS than most VB programmers have or indeed most application developers have. In addition VB does not support object oriented programming (OOP) in a nice way. It supports interface inheritance but not implementation inheritance. VB programmers could argue that object delegation and interfaces substitute for implementation inheritance. Nevertheless very of few of the well-known design patterns can be implemented neatly.

But still, VB has been used to develop 100KLOC applications. In my last job I was involved with a single 73KLOC VB module. There were other modules written in VB and C++ that this main application made use of. No good software engineer would develop such a large VB application from scratch. In my case, the application began as a simple prototype and as time went on the application took a life of its own growing to such a huge size. In fairness to Microsoft, they realized early on that VB does not scale and, as C++ required more training, the demand for application programmers would fast outstrip supply if nothing was done. They researched some of the existing computer languages, Java especially, and came up with .NET. They have steadfastly refused to upgrade VB 6 and are forcing people to migrate to .NET.

Unfortunately the migration path from VB to VB.NET is not quite as easy as Microsoft would like us to believe. For small GUI applications less than say 10KLOC, using a code converter would be viable. For large applications this is not possible because it takes a long time to fix all the loose threads. Meanwhile the original application is continuing to grow. Obviously you cannot ask the world to stop until you complete the migration.

Another approach that Microsoft encourages is to use the inter-op FormToolKit. This tool kit can be used to develop forms and ActiveX controls that can be used in a VB application. In my experience this is a red herring. It does not reduce the amount of classic VB. It merely prolongs the life of a classic VB application a little longer.

It is better if the app were broken up into many small modules. Then the main GUI can be converted to .NET using the VB modules as ActiveX/COM objects. In other words keep refactoring until you have smaller modules. At that stage migrate module by module even as the application keeps growing. However in most cases it would be better to retire the old application and start afresh. Yet another alternative would be to consider moving to C++. Complex VB applications are complex because they tend to get closer to the underlying operating system. What better language to do so than C++?

Why C++ is still my favourite language

With the advent of .NET the Microsoft camp is also moving away from C++ to a virtual machine driven architecture a la Java. When Java first came out the advantages were supposed to be memomory management and security. Garbage collection helped moved the mundane memory management responsibility away from the application developer to the virtual machine - or so the claim goes. Unfortunately people doing Java/.NET forgot to close files and database connections and had to go back to basics. .NET provided the 'using' feature that reintroduced deterministic destruction in a rather clumsy way. Besides the the try-finally syntax was supposed to take care of relinquishing resources (other than memory) that were not needed.



In C++ we use RAII. If an object encapsulates an database connection class then a database connection is opened in the constructor and closed in the destructor. No messy try-finally clause. Any good C++ programmer knows to take care of memory allocation using RAII. So memory management is less of an issue these days. The second advantage of C++ is the template programming. Generic programming in .NET is a pale shadow of template programming in C++. Here is an example:



template

class TContainer

{

T myObj;

public:

TContainer(T const& obj): myObj(obj){}

~TContainer() { myObj.CloseHandle(); }

};



Notice the 'CloseHandle' call in the destructor. This template demands that the class that T is instantiated with implement 'CloseHandle'. In C# (and Java too I think) a workaround can be provided for this simple case by casting myObj to a particular interface and then using the interface. But that's a runtime feature, and does not scale.



The one advantage of C# is reflection. In C++ we could query the typeid but we cannot traverse the entire set of methods and interfaces an object provides. This feature is used heavily in a number of instances including data binding as used by a GUI programmer. I am not quite sure why C++ does not do it. Even the dependency injection pattern cannot be implemented in C++.



Nevertheless, if you are going to develop algorithms, realtime, or even multimedia C++ is the way to go.