This blog is mainly about the future of Windows and VB6. According to this Microsoft article VB6 is supported up to Windows 8.
“The Visual Basic team is committed to “It Just Works” compatibility for Visual Basic 6.0 …“1 Visual Basic 6.0 IDE has not had extended support since 2008. Support is split into three categories 2. Mainstream Support, Extended Support, and custom support. During the lifecycle of support, the type of support switches over time in phases. Mainstream support includes full support, such as the current release of Visual Studio. When a product switches over to extended support, hotfixes (unless purchased within 90 days of mainstream support ending), No-charge incident support, Warranty claims, Design changes, and feature requests are no longer offered. Extended support is provided for a maximum of 5 years after mainstream support ends. “Microsoft offers custom support relationships that go beyond the Extended Support phase. These custom support relationships may include assisted support and hotfix support, and may extend beyond 10 years from the date a product becomes generally available.”3 Support is basically categorical fixes based on the phase of the product lifecycle.
Certain runtime files are still in extended support. The list of these can be found here as well as a list of known unsupported COM libraries. Runtimes that are not supported by Microsoft are 3rd party components. Over the years software companies have merged, sold, closed doors, moved on, but a handful still support their COM components. Knowing which ones are still supported and maintaining that support can take a lot of effort. The Visual Basic 6.0 IDE has had no mainstream support since 2005 and has not enjoyed mainstream support on a Windows OS since Windows 20004. The Visual Basic 6.0 IDE is the only product that can be used to build VB6 systems. The forms editor and compiler are highly guarded proprietary technologies and if they fail in your environment, your VB6 application maintenance and development work will come to a standstill.
VB6 Enterprise applications are built heavily on COM libraries. When VB6 was booming in the programming industry, COM libraries were the answers to all your needs. Pop in a new COM library and you have a new solution to some problem. Custom controls were easy to find and readily available for use. As a result, we have very large applications tightly coupled with these COM libraries. Should an Enterprise application still rely on COM components that are no longer supported? What if a security hole is found? Since 3rd party COM libraries are not supported by Microsoft, who knows when they will no longer even run in Windows. Microsoft takes a mainstream approach when moving their products. COM libraries are no longer in their path.
Windows 7 was a very nice release of Windows. The Windows XP of its time, it brings a beautiful look to a very stable sub system. Performance and flexibility are in high marks for this version of Windows. Windows 8 however, is a different animal altogether. Microsoft is pushing their interfaces to a more mobile platform. Azure, Silverlight, Cloud Services, WPF, and other web-based technologies are on Microsoft’s forefront. Windows 8 even has a web style coding behind their touch user interface. When Windows 8 was released Microsoft attempted to remove the start button from the taskbar and the desktop interface altogether. As Microsoft moves forward with their OS development we can only see their path leading away from the classic desktop application format. This path spells the end of VB6 desktop applications in the future.
Most people think about the technology as the only resource that will expire. There is more to the equation.
Quoted from Support Search VS6
Based on these dates, the training of new developers would have started to fade out right after 3/31/2005. At the time of this blog that would be over 7 years ago. The most senior VB6 developer would have 14 years of experience (not including VB4 and VB5). Even developers that started on VB6 around 2005 would have more than likely switched over to another language soon after. The point is that if VB6 is able to be ran for 30 more years, a company’s programming team might not be here to use it. A team of VB6 programmers currently would have 7-20 years of VB experience. In 10 years that team would range from 17-30 years of experience. In 20 years that team would range from 27-40 years of experience, and at around 30 years of experience that team would mostly be retired or moved on. Mathematically the team is going to become very small, or non existent within 20 years. Some might think that 20 years is a long time to wait, and that the application will be upgraded by then, but they need to remember a few things. VB6 is now a set pillar in time as technology goes. As OS advancements and coding language/tool advancements take place VB6 teams will become more and more left behind in the newer world of technologies. Consider that the longer they wait, the harder it will be to upgrade their application to today’s technology.
Eventually, either by the natural progression of technology or by developer resources dwindling over time, companies will need to move away from VB6. The typical solutions for moving away from VB6 are to buy an off-the-shelf solution, hand code a new app, or migrate your business code. Whatever the needs are, gmStudio and Great Migrations can assist in merging old and new applications. The migration from VB6 should happen sooner than later, because one day, you will have no choice and no time to migrate. The gmStudio trial can be found here.
