Using Virtualization to Preserve a Visual Basic 6.0 Client-Server Application
Summary: This article provides guidance for companies that want to keep their Microsoft Visual Basic 6.0 assets operational and available indefinitely, while mitigating the risks that are inherent in running legacy technologies in a modern environment. (12 printed pages)
Legacy Visual Basic 6.0 Applications
Challenges of Keeping Legacy Applications
Overview of Virtualization Technologies
Applying Virtualization Technology to a Legacy Application
The Visual Basic 6.0 product line is now more than a decade old, and the majority of Visual Basic 6.0 customers and developers have adopted the .NET Framework and are in the process of, or have already completed, the migration of their key Visual Basic 6.0 assets. Still, many companies retain a valuable portfolio of stable, legacy Visual Basic 6.0 applications that they would like to continue to support in Visual Basic, either for a year or two while other applications are migrated, or for many years.
This article will provide guidance for companies that want to keep some of their Visual Basic 6.0 assets operational and available indefinitely, while simultaneously mitigating the risks that are inherent in running legacy technologies in a modern environment.
This article focuses on how to apply virtualization technologies to client/server applications written in Visual Basic 6.0. A second, more in-depth article compares and contrasts several different types of Visual Basic 6.0 applications, and how different virtualization technologies could be applied.
Prior to the introduction of the .NET Framework, Visual Basic 6.0 was the tool of choice for many organizations that were building line-of-business (LOB) applications, because it provided developers with a highly productive and efficient tool for building "forms over data" applications. Vast numbers of Visual Basic 6.0 applications were built, and these applications remain mission-critical components of IT infrastructure for many businesses.
Maintaining instead of replacing these legacy applications is valid for a variety of business reasons, including:
The applications are currently working properly and meeting existing business needs. A replacement would offer no new business value.
The applications are large and need to migrate gradually, with much of the existing legacy code base remaining in production for many years.
The internal functioning of the application no longer is well-understood. Relearning the internal functioning would be costly, and the odds of misunderstanding the internal operation of the application would be high—making migration risky.
The legacy applications have deployment challenges, namely DLL hell, that are becoming increasingly difficult to manage as other software is upgraded, updated, patched, etc.
The company wants to consolidate its physical servers, but can’t because legacy applications require older, less efficient hardware.
With IT organizations being tasked to enable new business strategies and increase operational efficiency, the migration of working applications might not be the best use of scarce resources. In addition, most IT organizations can relate to the experience of an application rewrite project gone awry: As Bjarne Stroustrup commented, "Legacy code often differs from its suggested alternative, by actually working and scaling." The trend of failed rewrites is so prevalent that it has led to a shift in thinking about legacy applications, and brought about the notion of "legacy modernization" instead of costly and constant wholesale replacement.
The risk that is inherent in maintaining a portfolio of legacy applications is that they might prove incompatible with newer versions of commercial software. In the case of Visual Basic 6.0, while Microsoft is committed to supporting Visual Basic 6.0 applications through the life cycle of Windows Vista and Microsoft Windows Server 2008, many Visual Basic 6.0 applications rely on components and software that are manufactured by third-party technology companies. Some of those third-party components might become (or already are) incompatible with both operating systems, and there is no guarantee that those third-party software vendors will provide newer versions of their components.
In the case that third-party vendors do manufacture newer software, it might not be compatible with a legacy Visual Basic 6.0 application—a situation that could prevent the company from upgrading users to newer software that provides real productivity gains.
While most Visual Basic 6.0 applications should not present this kind of dilemma, when one does, it leaves IT organizations in the position of having to choose between the lesser of two evils. Either the IT organization potentially traps a segment of its users on older software that is required by the legacy application, or the IT organization is forced to rewrite legacy applications—at high risk and cost—not because of any new functionality that is required for the legacy application, but just to remove the legacy application as an obstacle to larger IT strategies.
Example Legacy Application
Beginning from the assumption that the preservation of legacy applications is (and always has been) a completely normal and typical responsibility of IT organizations, this article will walk through concrete tactics that can be used to preserve what is perhaps the most common type of Visual Basic 6.0 application: a client-server application that consists of a desktop application that communicates with a back-end database. Typical examples include order-entry applications, customer relationship management (CRM) systems, resource management, and many other forms of LOB applications.
The example client-server application is a sales-support application that tracks communications between sales representatives and clients. The application is specified as follows:
The client user interface is installed on the computer of each sales representative; there are 30 sales representatives. It is rare for more than five people to use the application concurrently.
The application does not maintain any state—such as registry keys, local files, and so forth—on the host computer. In other words, the application could have multiple instances running on the same computer without a problem.
While the client application itself is compatible with Windows Vista, there are many critical forms that use a complex, third-party ActiveX control that does not run on Windows Vista. The company that built the control is no longer in business, and the control is used so frequently in the application that it is not feasible to remove it.
Each client connects to a back-end Microsoft SQL Server 7.0 database (SQL Server 7.0 is not supported on any operating system after Windows Server 2000). While the company could upgrade to a more recent version of SQL Server, it has decided not to, for the time being.
Figure 1. Example client-server Visual Basic 6.0 application
Applying virtualization technologies to a typical Client/Server Visual Basic 6.0 application like the one in this scenario is relatively simple.
First, the database server, currently running on its own dedicated box, is run as a virtual server on a newer, more powerful server that acts as a back-end for many other applications and services, saving power and IT management time.
Second, the client can be accessed via Terminal Services. This allows the company to move the client application from end-user desktops to a server that hosts a virtualized Windows XP environment. Ideally, that host server runs Windows Server 2008, so that users can access the application via Windowless Terminal Services, which makes it appear like they are running the application on their own desktop computer.
Virtualization has emerged most prominently as a technology for consolidating servers. In its most common form, physical servers are converted to "virtual" servers—allowing multiple virtual servers to coexist on a single physical computer. This alone is transforming data centers and wringing more use out of each costly square foot.
Virtualization is also a way to preserve legacy applications. A notable early use was running Microsoft Windows NT 4.0 servers as virtual machines, allowing Windows NT 4.0 to run on physical hardware for which there are not (and will never be) Windows NT 4.0 drivers. For the purposes of preserving Visual Basic 6.0 applications (and their required back-end servers), virtualization can be used to solve the following specific problems:
Allow users to run legacy applications that are not compatible with current operating system (for example, Windows Vista) of the user.
Allow users to run applications that depend on outdated software.
Eliminate the need to dedicate physical servers to run legacy back-end software.
Virtualization is a broad term that applies to a set of technologies that can abstract one or more layers of the computing stack and ensure that an environment that is compatible with legacy applications is available indefinitely.
Various virtualization technologies address different potential needs of legacy applications. These virtualization technologies can be divided into three broad categories:
Virtualization of the Visual Basic 6.0 application that we consider in this article will require a combination of hardware virtualization and presentation virtualization. Uses for application virtualization are covered in a more in-depth article on this topic that covers less-common Visual Basic 6.0 application types.
Hardware-virtualization technologies allow you to run multiple "virtual machines" on a single physical computer by abstracting the computing hardware—including CPU, memory, mass storage, network interface cards, and so forth.
Figure 2. Multiple virtual machines running simultaneously on a single physical computer
Each virtual machine provides a basic set of virtual hardware that mimics, or passes through, to the physical hardware. Software that is running inside of a virtual machine sees a CPU, memory, disk drives, network adapters, and other hardware—just as software that is running on a physical computer would.
The operating system and software that are running in a virtual machine effectively behave as though they were running on a physical computer. The operating system and software are installed and configured just as they would be on a physical computer. Virtual machines that have SQL Server installed on them appear on the network as any other SQL Server. Legacy applications that are running in virtual machines can connect to databases, Web sites, network shares, or any other resources, without requiring any modification to the legacy application.
If multiple virtual machines are running on a single physical server, they are isolated from each other. Any event that happens inside of one virtual machine (for example, a virtual machine restarts, or its operating system crashes) does not affect other virtual machines or the host computer.
The hard drive for a virtual machine is just a file that has a .vhd extension. To back up the virtual machine, you just make a copy of the file to another disk, or tape. To move the virtual machine, you just copy the file to another computer.
Microsoft Hardware-Virtualization Technologies
Microsoft provides two primary hardware-virtualization products: Microsoft Virtual PC 2007 and Microsoft Virtual Server 2005 R2.
Virtual PC 2007
Virtual PC allows you to run virtual machines on your local desktop. Specifically designed to support older desktop operating systems on newer operating systems and hardware, Virtual PC 2007 is available for Windows XP and Windows Vista host operating systems.
Figure 3. Legacy application running locally on a virtual machine
Figure 3 illustrates how Virtual PC 2007 can keep available a legacy application that depends on Windows XP and Microsoft Office 2007, in an environment in which Windows Vista and Office 2007 are the corporate standard. When the user wants to use the legacy application, they first start a Windows XP virtual machine, and then they run the application within the virtual computer.
Virtual PC 2007 provides good integration between the host and guest operating systems. For example, you can perform copy-and-paste operations between the host and guest computers. You can also drag files from the host computer and drop them into the guest computer. Shared Folders also provide an easy mechanism for moving data into and out of the virtual machine.
Virtual PC 2007 focuses on desktop operating systems, including Windows 98, Windows ME, Windows 2000 Professional, Windows XP Home Edition, Windows XP Professional, Windows Vista Enterprise, Windows Vista Enterprise Business, and Windows Vista Enterprise Ultimate.
Virtual PC 2007 is available free of charge. It can be downloaded from https://www.microsoft.com/downloads/details.aspx?FamilyId=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en.
Virtual Server 2005 R2 Service Pack 1
Where Virtual PC allows you to run virtual machines on your local desktop, Virtual Server allows you to run virtual machines on server-class hardware. Virtual Server 2005 R2 Service Pack 1 is the Microsoft flagship product for server virtualization. It is available for the Windows 2000, Windows Server 2003, and Windows Server 2008 host operating systems, and is designed with scalability in mind.
Typically, Virtual Server is the best choice for preserving legacy-application investment. If you have legacy applications that require a certain operating system, you can configure a server with Windows Server 2003 R2 and Virtual Server 2005 R2. On that server, you then create a virtual machine that has the required operating system.
For example, if your Visual Basic 6.0 application requires Windows 2000 Workstation, or even Windows NT 4.0, you could create a virtual machine with that operating system, and then install your application on that virtual machine. Users could make a remote-desktop connection to the virtual machine and run the application, as shown in Figure 4.
Figure 4. Accessing an application that is running on a remote virtual machine
Microsoft offers Virtual Server 2005 R2 SP1 free of charge. It can be downloaded from http://www.microsoft.com/technet/virtualserver/software/default.mspx.
For quite some time, administrators have used presentation-virtualization technologies such as Remote Desktop to administer servers in distant data centers, and users have utilized Terminal Server to access applications that are installed on remote computers.
If legacy applications are compatible with server operating systems such as Windows Server 2003 or even Windows Server 2000, the legacy application can be installed on the server, and users can use Terminal Server to run the legacy application. The local desktop or laptop of the user might be running an operating system that is incompatible with the application, but this does not prevent its use, because the application is running on the remote server and merely is serving its display to the local computer.
Windows Server 2000 and Windows Server 2003 terminal-server technologies transmit the entire remote desktop, as shown in Figure 5. While this is effective, it does provide a slightly different user experience.
Figure 5. Legacy application running through presentation virtualization
By using Windows Server 2008, you will be able to remote the application windows without the entire desktop, as with earlier versions of Windows Server. This approach is known as a "seamless window," and makes it appear to the user that the application is running locally on their computer (as shown in Figure 6), even though the application actually is running on a remote server and using the resources of that server.
Figure 6. Legacy application running through seamless windows
Often, if you are running a remote application, you might need to access local resources. For example, if the application allows you to export data as an Office Excel spreadsheet, you likely would want to save that spreadsheet to your local file system. If you are printing from the remote application, you might want to print to a local printer. The Remote Desktop Protocol (RDP) supports these kinds of operations—making local resources such as the file system, printers, and clipboard available. This provides an experience that makes the remote application feel as if it were running locally.
If the legacy application is not compatible with the server operating system, the application can be installed on a virtual machine that is running on the server, and accessed remotely by using the same remote-desktop functionality.
Many applications require you to uninstall the previous version before you can install the latest version. Developing an application that supports side-by-side operation with previous versions is challenging; Microsoft Internet Explorer and Microsoft Windows Media Player are examples of such applications. Often, this is also the case with Visual Basic 6.0 applications, as an application might reuse the same registry keys or file-system locations, or might require incompatible versions of COM objects.
Application virtualization allows you to run applications in "virtual layers"—providing isolation between otherwise incompatible applications. Application virtualization is provided through the Microsoft SoftGrid product, which is available only through a support package that is called Software Assurance  and is targeted at large enterprises. If you are a Software Assurance customer, please review the more enterprise-focused Visual Basic 6.0 virtualization paper.
Each legacy application should be analyzed individually. What makes the most sense for one application might not make the most sense for another. Depending on the architecture and dependencies of a Visual Basic 6.0 application, and on the needs of the company, some virtualization technologies are best suited for preserving specific types of legacy applications. Our typical client-server application is used by a sales team and is specified as follows:
The client user interface is installed on the computer of each sales representative, and there are 30 sales representatives. It is rare for more than five people to use the application concurrently.
The application does not maintain any state—such as registry keys, local files, and so forth—on the host computer. In other words, the application could have multiple instances running on the same computer without a problem.
While the client application itself is compatible with Windows Vista, there are many critical forms that use a complex, third-party ActiveX control that does not run on Windows Vista. The company that built the control no longer is in business, and the control is used so frequently in the application that it is not feasible to remove it.
Each client connects to a back-end SQL Server 7.0 database (SQL Server 7.0 is not supported on any operating system after Windows Server 2000). While the company could upgrade to a more recent version of SQL Server, it has decided not to, for the time being.
The virtualization solution here is to virtualize both the client and the server applications, and have them run on a server. Users would connect to the client application by using either Windows 2003 terminal services or the Windows 2008 Seamless Windows terminal-server technology.
The back-end database is SQL Server 7.0.
SQL Server 7.0 is not supported on any operating system after Windows Server 2000.
Windows Server 2000 can be run as a virtual machine using Virtual Server on Windows Server 2003 or Windows Server 2008.
Running the database as virtualized allows the database server to be consolidated on the latest hardware with other servers.
- SQL Server 7.0 is not supported on any operating system after Windows Server 2000.
The client application is not compatible with Windows Vista, and some of the users are running Windows Vista. This leaves two options:
Run the application as virtualized on the local computer.
Run the application remotely.
- Run the application as virtualized on the local computer.
The application is needed by 30 users. Having 30 users run local virtual machines is prohibitive for the following reasons:
Doing so requires each user to have 2 gigabytes (GB) of physical memory, and approximately 10 GB of free disk space. Ensuring this across 30 users might be difficult.
Having each user run the virtual machine locally complicates the configuration of the computer of the user, each of which would need more than the standard IT configuration.
Training new salespeople (who are the users of this application) is more complicated, because they need to understand the basics of Virtual PC 2007.
- Doing so requires each user to have 2 gigabytes (GB) of physical memory, and approximately 10 GB of free disk space. Ensuring this across 30 users might be difficult.
The application could be run remotely.
The application is compatible with Windows XP.
Windows XP virtual machines could be loaded on servers that are running Windows Server 2003 with Virtual Server 2005 R2 SP1.
A Windows XP virtual machine could be provisioned for each user who requires access to the legacy application. The Windows XP virtual machine would contain the application and any application dependencies.
Users could connect to the remote Windows XP virtual machine through RDP.
- The application is compatible with Windows XP.
This analysis leads to the architecture that is shown in Figure 7.
Figure 7. Virtualizing a client-server application
The database will run on a Windows Server 2000 virtual machine, and it can continue to run on this virtual machine indefinitely. Running the database in a Windows Server 2000 virtual machine, which is installed on a Windows Server 2003 (or in the future Windows Server 2008) physical computer, allows the database to benefit from faster processors, faster IO subsystems, hot-swap drives and memory, and other leading-edge technology. It also simplifies the backup and recovery of the database, as the entire virtual machine is just backed up and restored.
The client application is run on a separate virtual machine, hosted on a central server. Based on the preceding analysis, it likely would create too many support requests and require too much hardware for the computer of each user to run the virtual machine on the local system of the user. Running the client application on a server-side virtual machine also allows easier backup, restore, and monitoring by the IT organization. This also keeps the legacy application from being a one-off solution and requiring special configuration of the computer of the user.
In this environment, the user runs most applications on their own local computer. When the user must run the legacy application, the user connects to the virtual machine that is running on the remote server through a remote-desktop connection. The remote desktop opens as a window on the local computer of the user, and the user runs the legacy application in this remote-desktop window.
Figure 8. Users accessing legacy applications on remote virtual machines
Through the combined use of hardware and presentation virtualization, Microsoft delivers a cost-effective virtualization strategy to help customers support their existing legacy applications in the environments of tomorrow.
Virtual Server 2005, Virtual PC 2007, and, soon, Windows Server 2008 Virtualization allow you to access applications on computers that have incompatible operating systems. These technologies allow you, for example, to run an application in a Windows 2000 virtual machine that is running on a Windows Vista desktop or Windows Server 2003 (or Windows 2008) operating system.
Terminal Server provides remote access to mission-critical legacy applications—allowing many users to be serviced by a single server. If the legacy application does not support simultaneous users on the same computer, each user can run the application on their own unique server-side virtual machine. As you have seen in this article, virtualization technologies often are combined to provide the optimum solution.
Virtualization is a key deliverable on the Microsoft Dynamic Systems Initiative (DSI) road map, in line with the continued investment of Microsoft in delivering technologies that help IT organizations manage complexity and achieve agility.