Much of that code started out as a small RAD application or prototype which grew (more by accretion than design) until it became large, unwieldy, and mission critical.
This whitepaper addresses issues with continuing to use and support VB6 applications and examines alternatives for potentially disposing of them.
Among the many reasons VB6 is no longer a good thing to rely on are:
In the spring of 1964, as Lyndon Johnson was settling into his new-found presidency and the Beatles were stealing the hearts of American teenagers, John Kemeny and Thomas Kurtz released the first implementation of BASIC: the Beginner’s Allpurpose Symbolic Instruction Code. Little did they know that they had created something that would come to be the most popular programming language in the world.
BASIC was simple and approachable and lightweight enough to run on the 8-bit microprocessors that powered the first wave of micro-computing in the 1980s: hobbyist boxes like the Apple II and the TRS-80. When the IBM PC shipped, it contained a version of BASIC built right into the OS.
By the late 1980s microprocessors weren’t just for hobbyists anymore and BASIC had established a firm foothold in the world of programming languages. Microsoft—which passionately wanted its newly minted Windows operating system to be successful— cobbled together the first “visual” way to create Windows programs with BASIC, not C or Assembly, as the underlying programming language.
This was Visual Basic 1.0, released in 1991, and before it was replaced by VB.NET 10 years later it had become the go to way to code for Windows for millions of people around the world.
Visual Basic 6.0*—the final version of “real” Visual Basic before it was replaced by VB.NET (an entirely different language sharing only the basic syntax of Visual Basic)—was wildly popular for three reasons:
As we will see, many of those same reasons that made VB so popular make it increasingly a problem for IT today. We'll look at issues around VB6 and different approaches to mitigate those issues.
The universe of ActiveX (i.e. COM-based components, formerly called OCXs) third-party components used so commonly by VB6 developers is a fundamental threat to the ongoing life of VB6 code. In the 90s component developers flourished. Every copy of Visual Basic included a catalog showcasing hundreds of different vendors and their custom controls for everything from charting to calendar views to data access and visualization. Most of those vendors are merely a memory today and there is no one to support their control libraries for modern Windows versions.
Early adopters of VB who wanted to support older and lower-cost PCs opted for 16-bit executables using 16-bit controls. Those applications are today—in many cases—trapped by their 16-bitness since for some time now no CPUs have been manufactured that can support any sort of 16-bit mode short of running a VM emulating a 16-bit processor. Those applications can be modernized but in doing so will have to abandon those 16-bit components. More about components later.
The component model was based on COM (Microsoft’s Component Object Model)—a deeply complex system for inter-process communication. Today no one would dream of writing anything that relied on COM, instead using something simple like RESTful services or even SOAP/XML web services.
The ability of COM (and any ActiveX or OCX) to take control of any Windows service represents an on-going security vulnerability of unmeasurable risk. Modern OS designs insulate applications from other bits and pieces far more carefully than COM ever can—consider how web browsers run in sandboxes with little access to hardware or low-level services.
In the days of C and C++ developers explicitly carved out chunks of memory to execute threads and lacking careful design and testing can and did bring systems to complete crashes— thus the infamous Blue Screen of Death (BSOD). Windows today is based on .NET which manages everything under the covers— developers using .NET do not address memory directly, instead relying on the .NET Framework to allocate memory, manage instantiated objects, and collect garbage.
This is referred to as “managed code.” COM—like the apps written natively to the Windows API in C++--are “unmanaged code.” While managed and unmanaged code can intermingle— using concepts like COM Interop or PInvoke—moving forward best practices will dictate eliminating unmanaged code entirely as yet another area of potential defects or vulnerabilities.
Before the web, before the internet was ubiquitous, Microsoft created a method to let applications work together so that, for example, a Word document could contain an Excel spreadsheet. This was Object Linking and Embedding (OLE) which later morphed into COM (Component Object Model) and eventually COM+ and DCOM. COM also spawned the interprocess communication methods used in OCX and ActiveX technologies.
Many VB6 applications continue to rely on COM in order to function—a common scenario is a reliance on a shared external library (DLL). What’s wrong with COM?
Short version: COM is bad; .NET is good.
Desktop CPUs have evolved from 8 bits[endnote!!!] (hobby computers in the 80s) to 16 bits (IBM PC) to 32 bits (Compaq 368) and now 64 bits. Address space limitations have typically driven this evolution with the current addressable space of 2^64 or 9,223,372,036,854,775,807 (9 quintillion) is sufficiently large that there is no need to build 128- bit processors (the next generation of computers will probably be quantum computers).
It’s important to note that VB6 as a programming language only understands 16- and 32-bitness; VB6 shipped in 1998 when 32-bit computers were at their peak (having been introduced on the X86 platform a full 13 years earlier) and the first Intel 64-bit processor was still three years away.
Does 32-bitness matter? In some ways, 32-bits is alive and well even in 2017 on Windows 10.
The last Intel 32-bit processor (Pentium 4E) was introduced in February 2004. That same year Intel introduced the Xeon 64-bit CPU. What this means is that any 32-bit laptop or desktop computers are possibly as much as 13 years old (four lifetimes in computerese).
Those physical machines, while it’s possible that they could be running a contemporary OS like Windows 7 to Windows 10, they can still only have 4GB of addressable memory. In reality, they will more likely have something like 512MB of memory and an 80GB hard drive. Sure, they can be upgraded to 4GB of memory and a bigger hard disk, but they will still have serious limitations based on processor speed and addressable memory limits (4 GB).
Visual Basic 6.0 cannot create a 64-bit executable; it can only create a 32-bit executable.
Given that all contemporary hardware is using a 64-bit CPU, how can a 32-bit executable run? The answer is WoW64, which is an emulation layer that Microsoft provides with current 64-bit Windows versions. Running 32-bit apps on a 64-bit processor is [ENDNOTE!!!] a little like buying a 2017 Corvette and disconnecting half the spark plugs; you’re just not getting anything like the full performance available.
And since it’s pretending to be a 32-bt machine when your app is running on WoW64, you’re still stuck with the 2^32 (4.3 billion bytes) limit, with only 2GB for data and applications (the other 2GB are dedicated to the kernel). This will create performance bottlenecks for large data sets, I/O-intensive applications, and so forth. In short: 32-bit apps are slow.
But there’s more: increasingly, 32-bit bits and pieces just won’t work with modern components. As new technologies are rolled out, most of the time they assume they are working in a 64-bit world, so 32-bit compatibility is not a requirement. Moving to 64-bits ensures you can continue to stay current; being stuck in a 32-bt world can limit your future growth.
Why upgrade from VB6 to C# (or VB.NET‡)? There are many reasons. Let’s drill down on a few of the most important:
You know that old smelly sofa that your great uncle Fred had in his living room? That’s what a VB6 application looks like today compared to modern desktop or web applications. And your customers will recognize that your app is old and clunky and perhaps extend that negative impression to your company and value proposition as well. Time to modernize!
Visual Basic was hot 20 years ago; now it’s considered a dead language. It’s not taught in school and no one is writing books about it anymore. It’s not that people can’t learn it, but you have to be pretty dedicated and most younger developers will probably see a VB6 job as a career-limiting move. As a point of comparison, search on Indeed.com for Visual Basic 6.0 jobs and you’ll get 20-30 results.
Search for C# developer and you’ll get closer to 25K results. Visual Basic also continues to plummet in popularity on developer indexes such as TIOBE. Basically, you need elderly developers who learned it back in the day and are still not quite ready to move into the assisted living facility. But those kinds of people are harder and harder to find. And they cost more.
VB6 is BASIC, which is a procedural language graced with subroutines and classes. It’s not an object-oriented programming language (OOP) and you can’t really make it behave like one. To apply modern design patterns on a VB6 app is a real struggle: one where you are constantly trying to work around the limitations of the language.
A little research will show that many “serious” programmers have a litany of beefs about the original Visual Basic language. Some of the elements criticized frequently include On Error GoTo (as opposed to Try/Catch in C languages); variant data type; lack of unsigned number types; confusion between subroutines and functions; overuse of Global variables. All of these make it easy to do RAD (rapid application development) as they streamline things that are harder in C# but which can lead to code that is either buggier (see next bit) or harder to maintain.
The very nature of VB simultaneously appealed to non-professional programmers (engineers, scientists, business people, Excel gurus) while repelling trained developers, who looked down at VB6 as only slightly better than a toy designed to create unmaintainable and buggy code. Among its many faults, VB6 makes it difficult or impossible to follow modern software engineering practices. For example, VB6 invites you to create business logic as part of an event handler on a discrete control, violating the concept of separation of concerns. Variables are created by simply using them—no need to explicitly declare them or their scope. As a result, far too many variables are global in typical VB6 code, creating a petri dish for runtime bugs. And the use of SUB means you can easily create spaghetti code by having subroutines call other subroutines which in turn call other subroutines and so on.
As mentioned above, a key element in the enormous popularity of VB6 was the vast ecosystem of external components that could be added to the toolbox in the IDE and dropped onto VB forms for “instant” functionality. The appeal of these components can’t be underestimated: for a few hundred dollars or less you could drop in a chunk of pre-written, tested and supported code to perform a function you needed. The alternative was to try to write the functionality yourself, or do without. Unfortunately, many of those vendors are no longer in business, so those controls have no counterpart for modern applications and are no longer supported.
Even though Microsoft continues to support the VB6 runtime on Windows 10, component vendors are under no obligation to update their controls. Because of this, you may find that your app no longer functions correctly with no warning and no fix.
Windows 10 is the last version of Windows—from now on Microsoft will push updates out at regular intervals. But Microsoft has made it clear it is moving to deliver Windows “as a service” with upgrade cycles of 18 months or so. And unlike days past, you can’t just stick to a single version of Windows as long as you like. Translation: it’s quite possible you can show up for work one day and at least one legacy app has stopped working due to unforeseen updates. Microsoft has no obligation to ensure the continuity of anything out of support, which VB6 and related old technologies are now.
You don’t have to live with VB6 forever because there are perfectly valid alternatives to remove the risks and costs of having VB6. Here are three popular approaches to remediation with pros and cons:
If you are an ISV and you sell your VB6 app, then obviously your app is custom to your needs. But if it’s an internal (i.e. line of business) application, perhaps you don’t need a custom app to solve the problem. Platforms such as Microsoft Office or Salesforce can be extensively tailored to perform business functions that in the past required writing software.
When developers look at old VB apps, probably the first thought that comes into their minds is “rewrite.”
And certainly this is a perfectly valid outcome for many legacy applications, but not always. As a company that has seen more VB6 legacy applications—large and small, ISV and line of business—we can attest that there are many examples where a rewrite is a terrible idea. Let’s drill down.
Consider that many VB6 apps were built around the concept of “forms over data” with some simple business rules enacted in the code. Those apps have little unique value that couldn’t easily be duplicated. Their primary function is CRUD plus reporting; that is create, read, update, and delete records in a database and present views of that data. Simple business rules like data validation are built into the code behind form objects.
Small apps that follow this model with dreadful code (buggy, tangled, hard to follow) are best rewritten from scratch or replaced with some package that can
do the same work.
What kind of applications should be rewritten? Probably far fewer than most people would expect. The reality is that writing software—any kind of software—is incredibly risky. Numerous studies have shown failure rates of up to 70 percent for new software development, with typical problems including:
Migration using automated tools can be the perfect solution for moving many different kinds of VB6 apps forward. Using automation reduces the time and cost of creating a modern version of a VB6 app by as much as 90 percent, allowing you to get your new app into users’ or customers’ hands quickly and affordably.
Best-in-class migration tools use machine-assisted learning and AI algorithms to analyze code patterns, not just syntax, creating new code that recreates the intention of the original application. In doing so, it preserves business logic, rules, and data structures without introducing new errors.
Not all apps are good candidates for automated migration. Those that benefit the most have the following characteristics:
Here are examples of some VB6 apps that were excellent candidates for automated migration:
National Systems sells call center software that Pizza Hut uses for home-based phone agents to take orders for pickup or delivery. Orders are routed randomly to available agents then directed to the most appropriate restaurant location.
The original app was written in VB6 and, since the user base was not only widely distributed but also constantly changing and non-technical, deployments of new versions and support were expensive and problematic due to factors like varying versions of Windows and “DLL hell.”
The app required “five 9’s” of reliability and needed to be replaced in such a way that the user base would require zero retraining and zero disruption. National Systems selected Mobilize.Net’s WebMAP solution to migrate their VB6 app to a modern web architecture using KendoUI to duplicate the VB6 forms.
Over the years this VB6 app was developed and sold to over 5000 retail outlets dealing in used (consigned) merchandise. The original VB app connected to various hardware devices like a cash drawer, Verifone credit card terminal, bar-code printer, and scanner. The company was successful but saw encroachment on their market position by a SaaS offering that could run in any browser. Given that, the company elected to make the jump from local instances with private databases running VB6 and Windows to a full, modern web architecture using WebMAP. They achieved some major improvements as a result of the migration, including:
CFM Materials recycles serviceable parts from end-of-life jet aircraft engines. Starting with a small VB6 app to keep track of inventory, over two decades the app grew in scope and complexity until it became the ERP system that ran the entire business.
Recognizing that it was getting increasingly difficult to secure technical talent to maintain the application, the company elected to use the Visual Basic Upgrade Companion with Mobilize’s assistance to migrate it to VB.NET and Windows Forms. Once migrated, Mobilize migration engineers worked directly with the technical team at CFM Materials to bring them up to speed on the new code base so they will be able to take ownership and maintain it in the future.
A migration doesn’t do what a rewrite accomplishes, but that’s not necessarily a bad thing.
A rewrite addresses the same business problem as the legacy app, but invariably gets additional requirements from the business owners. A migration, on the other hand, perfectly preserves the existing functionality while moving the code base forward to a
modern language and platform.
A rewrite is “let’s start over.”
A migration is “let’s lift and shift.”
In many ways migrations are superior to rewrites:
Examining a “typical” application lets us understand better the business case for migrating a VB6 app compared to rewriting it.
Let’s assume a hypothetical “medium” sized application of around 200 KLOC§ of VB6 code, including 150 VB forms and 40 separate components (DLLs or OCXs). This application uses a SQL database back end and is used by 3000 people.
What would it cost to rewrite this from scratch to a modern desktop application using C# (or VB.NET) and Windows Forms?
As of this writing, a knowledgeable journeyman-level C# programmer in the US will cost around $150k per year fully burdened (salary, office, benefits, taxes, overhead, and so on). While this can vary widely depending on location (California’s Bay Area compared to Orlando, for example), for the purposes of analysis we’ll just use this number. For your purposes you can use a more representative number, and enter it into our calculator here.
Over the years various academics and analysts have tried to calculate the productivity of software developers based on lines of code written [ENDNOTE]. Counting total finished lines of code divided by total developer time—which includes meetings, creating requirements and specifications, debugging, and surfing the Internet—ranges from 10 to 40 LOC/developer-day, with 10 being “average” corporate developers and 40 being “rock star” commercial ISV developers.
Let’s assume 20 lines of code per developer per day.
If our developers work all year except for 2 weeks (10 work days) then each developer will average 5000 finished lines of code per year, at a cost of $30 per LOC ($150,000 / 5000). Your 200KLOC application will take 40 developer-years to complete. Total cost?
$6,000,000.
Why so expensive?
THIS IS AN END NOTE: 1000 lines of code
¶ This is an enormously controversial topic which you can read
more about here.
For one thing, development—new software development—is much more than coding. Whenever a development team starts with a clean sheet of paper, even to rewrite an existing application, new requirements come out of the woodwork. And even the best programmers write bugs—a lot of bugs. Studies show that for each KLOC of new code, somewhere between 10 and 50 new bugs (defects)will be created, each of which must be identified (which in turn requires writing some kinds of test cases), investigated, fixed, verified, and tracked.
More studies show that all software includes defects not discovered prior to release, and these defects can be the most dangerous of all.
But what if you merely rewrote the existing app in a new language, sticking strictly to the existing set of features and postponing any new ones until after the rewrite was complete?
First of all, no one would ever do this. It’s simply too tempting to take care of existing requests during the project. And that leads to feature creep.
But if they did—if they somehow managed to hold off all the demand for a change here and a change there—how much would it save?
Half. Half is a good number, so the cost per LOC could drop from $30 to $15.
The lure of lower-cost but high-quality software development from far-off locales like India or Ukraine has appealed to many companies who were either short of resources or simply looking to stretch their budgets.
Taking our last scenario (a pure rewrite with no new features) offshore could save another 50 percent**: driving the cost per LOC from $15 to $7.50 and the total project cost from $6M to $1.5M.
Worst case: $6M. Best case: $1.5M.
But wait: there’s more.
The R word. Few endeavors by contemporary humans have a more abysmal success record as software development. In fact, “success” in software development is rarer than failure—”failure” being defined as a project that either fails to meet the specified budget, schedule, or requirements, or is abandoned altogether.
As many as 70% of software development projects fall short of their goals or fail outright. This in spite of years of research into best engineering practices such as waterfall, Agile, team development, and more.
A business knows how much a new truck will cost. They know how much a new server will cost. But a new application? Statistically this is impossible to accurately predict.
As thousands of organizations have learned, the alternative to risky, expensive, time-consuming software rewrites is migration using AI-assisted automation:
Just as robotics can reduce the cost of assembling automobiles or mobile phones to a fraction of the cost of labor, automated migration tools can reduce the cost of modernizing legacy code to a fraction of the cost of using people.
How much can it save?
In most cases, between 80 and 95 percent compared to rewriting. Further, at least half of the total cost is verifying that the migrated application functions identically to the original legacy application.
Our hypothetical 200KLOC VB6 application could be migrated to a C#/.NET version for between $300K to $1.2M without the risk of rewriting.
And using near-shore (Costa Rica) resources—who happen to be the global leaders in this kind of project—companies can get a guaranteed delivery date at a fixed price. Removing all project risk.
A global 1000 enterprise migrated from VB6 to a modern web application—utilizing the Telerik KendoUI Javascript framework to perfectly emulate the look and feel of their VB application, thus no need to retrain thousands of users—for 20 percent of the cost of a rewrite (their original budget).
A vertical-market ISV was able to migrate their VB6 app to a modern web version switching their revenue model from license to subscription) in less than one year, compared with the internal schedule of three years to achieve the same result with captive developers.
A typical migration project can be divided into four major stages:
Organizations with significant portfolios of in-house applications can benefit from an initial Portfolio Analysis, where the following outcomes are achieved:
The portfolio analysis is a scoping project at the department, division, or enterprise level that can provide senior management with invaluable 360-degree view of their in-house application portfolio. This can help set priorities, staffing, and budgets for longer-term planning.
At a more granular level, a Migration Blueprint is a deep dive into a single application’s code to deliver more technical analysis and planning:
Following the analysis and planning phase, the next step is to actually begin modifying code. Using highly-automated tooling (VBUC, WebMAP, etc), a semantic analysis of all the code in the application is performed creating an abstract symbol table (AST) which represents all the interactions and patterns in the application source code. This AST can further be used to identify additional application-specific adaptations that can increase the extent of the automation in the migration process.
A code-generator produces new code from the AST in the target language and platform. Because of the nature of the tooling, business logic is preserved as is and (when desired) the look and feel of the original application. Generated code is completely native with no dependencies on binary runtimes.
Some C# helper classes are provided (in source code form) to ease the transition from the old platform to the new one for your internal development team.
During the code modification phase, some predictable issues must be resolved on virtually all projects:
During a migration project the application owner may want or need to continue to make changes to the legacy application and publish those updates to the user community. Due to the nature of Mobilize.Net’s tooling continuous migration is possible; changes to the original app are diffed compared to the migrated code and new migrated pieces can be integrated into the migration code repository. Specific details and best practices’ recommendations on this level of integration are available at https://www.mobilize.net/continuous-migration.
Now that the legacy code has been replaced with modern code and a modern framework like .NET or HTML with Javascript, the development goals should be to avoid accumulating new technical debt.
Areas of post-migration focus include:
Many organizations lack sufficient internal resources to handle migration projects while still pursuing existing higher-priority development projects. In those cases, companies frequently turn to companies like Mobilize or India-based systems integrators (SIs) for project fulfillment.
The use of off-shore or near-shore resources for software development by US and European companies is a well-established trend that has been extensively discussed and documented. The basic value equation of moving away from on-shore development is exchanging reduced hourly labor rates for increased degrees of complexity and oversight.
Mobilize.Net has one of the largest software engineering centers in Costa Rica. Companies that choose to get their migration project performed by Mobilize.Net get many advantages over projects performed in India or Eastern Europe, including:
If you’ve read this far you know there are real consequences to continuing to rely on VB6 applications. And you know the future continuity of anything built with VB6—and the associated implications of that—is unpredictable and risky to count on.
Why not start today exploring your path to freedom from VB6? Mobilize.Net—the world’s authority on VB6 and how to get off it—is here to help.
Call us today at 1-425-609-8458 or email us at info@mobilize.net
