This blog is mainly about the future of Windows and VB6. According to this Microsoft article VB6 is supported up to Windows 8.
What does Microsoft mean by "supported"?
"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.
What exactly is supported?
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.
Is "supported" good enough for an Enterprise application?
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.
What about future releases of Windows?
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.
What would a current VB6 team look like in 10, 20, 30 years from now?
Most people think about the technology as the only resource that will expire. There is more to the equation.
Quoted from Support Search VS6
| Products Released | Lifecycle Start Date | Mainstream Support End Date | Extended Support End Date |
|---|---|---|---|
| Visual Basic 6.0 Enterprise Edition | 1/27/1999 | 3/31/2005 | 4/8/2008 |
| Visual Basic 6.0 Standard Edition | 1/27/1999 | 3/31/2005 | 4/8/2008 |
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.
When to Migrate?
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.
gmBasic
[+] 10.05B1 (patch)
[!] suppress MigrationSupport.UI assembly references when not needed
gmStudio
[+] Retain VirtualRoot in gmProj folder even if Migration Type is VBP
[+] Add logic to log gmProj path repair process in startup log and session log
gmSamples
[+] No more samples installer, just unzip samples and go (thanks to new gmStudio automatic gmProj path repair feature)
This will allow us to add more samples faster and make it easier for users to learn and use advanced features.
Summary
The gmStudio product roadmap is driven by an overriding principle: gmStudio users should enjoy outstanding software re-engineering results, with less effort. We believe that principle is served by three broad qualities: ease of use, flexibility, and accuracy of results. Our roadmap milestones and objectives all support one of more of these broad qualities. Learn more about our plans for gmStudio Product improvements in this article.
I was in a sales demo last week and an architect from the client team asked about the gmStudio roadmap so I felt it was a good topic for a blog entry. A sampling of roadmap objectives are presented below. These are only teaser descriptions: the problems and solutions are in the details and no details are covered here. Each of these these deserves its own blog post and much more.... stay tuned.
Testing Enhancements
Enhance the tool to assist with functional quality verification. Everyone of our customers can use help with testing and there are many things we can do to help: test case generation, test data identification, automating comparison of old and new systems.
New Types of Migrations
Support new target and source languages as well as application architecture changes, the sky's the limit.
- Support for .NET Core conventions, frameworks, and tools
- .NET to .NET – global refactoring
- Desktop to Mobile, Desktop to Web, Desktop to RIA
- Desktop to WPF
- Oracle Form Migration
- VBA Migration (Access to .NET)
- Embedded SQL to stored procs
- Desktop to Web
- ASPclassic to MVC
- Java to .NET
- VB6 to Java
- Application Security auditing and risk mitigation
- Additional COM replacements rules and extensions
More Prescriptive target application architectures and frameworks
In general, we assume that customers want to follow their own standard for architecture and code so we focus on flexibility, but frequently customers want us to prescribe major aspects of the target design for them. Being able to move a legacy application into a comprehensive predefined application architecture would be a compelling offering to many customers. We intend to look for such frameworks (such as Enterprise Library and various open source frameworks) and help customers adopt them as part of the migration.
gmStudio UX Enhancements
We could do a lot to improve user experience and productivity. Some ideas for improving the gmStudio UX are:
- Easier implementation of advanced transformations
- improved Visual Studio integrations
- Custom configuration files editors
- integrating analysis and configuration tasks.
De-Localization
Some of our international customers have international characters in their application symbols (i.e. variable names, function names): they want these removed. This would be a small matter using gmStudio.
Localization
Some of our customers want to rework their codes to work for international markets. There are certain conventions and best practices for writing systems in .NET that facilitate localization and we can generate codes that conform to these conventions and best practices.
Test Planning and Estimation Enhancements
Enhance the tool to integrate code analysis features with test planning and estimation concepts so that extremely large software re-engineering efforts can be completed most efficiently.
Customer Feedback
And last but definitely not least: one of most important items on our roadmap is incorporating improvements that come up in working with customers. These items typically get moved right to the front of the line in terms of our release planning. If you have features you would like to see added to gmStudio, please contact us and reference this blog.
The end is near!!!! Windows XP paid and free support will end next year. It is important to note that all unsupported software has an expiration date. Not only support, but the ability to use that software will end one day. Microsoft is moving farther and farther away from desktop applications. What support will end next? It is important to be ready and know your options.
gmBasic
[+] Upgrade to 10.05B1
[+] gmSL enhanced to support the types of transforms used in RDO sample
MetaLang
[Change] lang\GMSLANG.XML
[Change] lang\OPCODES.XML
[Change] lang\SharedFile.xml
[Change] lang\VBASIC.XML
gmStudio
[+] Add logic to automatically repair gmProj files when project/source folders are moved by the user
[+] Add support for /MakeMetalang switch in the TScript field to rebuild metalang file before running translation
[+] Change Build Order command string to ignore project-specific startup file
[!] Correct active task tracking bug on the main form
gmSamples
[+] Demonstrate SharedFiles consolidation feature in FMStocks DLLs C# sample (See DemoFMSLib_csh.gmproj)
gmBasic
[+] Upgrade to 10.04
[+] Implement major upgrade to gmSL scripting engine
[+] Improved support for stubbing and migrating VB6 intrinsic controls
[+] Introduce autoloaded configuration file Language.<sysid>.xml to allow modified handling of intrinsic VB classes/controls
[+] Add analyzer routine and metalang changes to include the Microsoft.VisualBasic.Compatibility only if needed.
[+] Improve translation of Control.Index with control arrays
[!] Allow explicit use of "VB." namespace (i.e. VB6.OLB) in VB6 codes
MetaLang
[Change] lang\enumerations.xml
[Change] lang\GMSLANG.XML
[Change] lang\OPCODES.XML
[Change] lang\TOOLLANG.XML
[Change] lang\TYPES.XML
[Change] lang\vbcontrols.XML
[Change] lang\vbasic.XML
[Change] lang\VB7LANG.XML
[Change] idf\asplang.xml
[Replace] lang\AspAuthor.xml with AspAuthor.gmsl
[Replace] lang\AUDITVBI.XML with AuditVBI.gmsl
[Replace] lang\IdlAuthor.xml with IdlAuthor.gmsl
[Replace] lang\SharedFile.xml with SharedFile.gmsl
[Replace] lang\textcode.xml with AuthorText.gmsl
[Replace] lang\Utility.xml with Utility.gmsl
[Add] idf\asplang.gmsl
[Add] idf\Language.std.xml -- allows for custom VB controls migrations
gmStudio
[+] update structure report to handle missing source files in a more intuitive manner. PRM-247
[+] correct issue with IDF Generation when using a project-specific startup
[+] include User and Language file searches to include *.gmsl files.
[+] Added support for /startDefault switch in the TScript field to suppress custom gmBasic.xml (DemoScanTool)
[+] Improved error handling for unregistered TLBs during IDF generation
[!] Correct DiffToFileCmd in gmStudio.cfg
gmSamples
[+] Update DemoScantool\usr\GlobalSettings.xml to new gmSL standard
[+] Update DemoScantool\usr\GM.mscomctl.ocx.xml to new gmSL standard
[+] Update to use new runtime support for DirListBox and DriveListBox -- no more VisualBasic.Compatibility
[+] Update FileExplorer samples to demonstrate RichTextbox upgrade
[+] Update to show how to upgrade VB6 intrinsic objects
[+] Include migration dlls in the usr folders as needed
Installer
[+] Remove migration DLLs from gmStudio installer
gmStudioPlugin (beta)
[+] new preview image for VS extension manager dialog
gmStudio
[+] Read install folder from registry rather than assuming default. (corrects PRM-244 Drive Letter confusion looking for license file)
[+] Add Help button to tool bar
[+] Add Tools button to tool bar
[!] Correct Analytics Symbols Report template
Installer
[+] Record install folder in registry
gmStudioPlugIn (beta)
[+] Hide main menu bar when running as VS plugin