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++?