Classic VB Petition FAQ

What do you mean by "Classic VB"?: The term "Classic VB" has been adopted to mean those 32-bit versions of Visual Basic (VB5/VB6) and Visual Basic for Applications (VBA) that are in most common usage today.
What, exactly, are the MVPs demanding from Microsoft?: Nobody is "demanding" anything. Please read the petition carefully. The petition requests that Microsoft alter its strategy to one that should better benefit both Microsoft and its customers. Microsoft recognizes MVPs as being extremely in touch with its customers, and often solicits their feedback based on this very (accurate) assumption. In this case, the feedback being offered is a bit more public than at other times, as private channels have failed to alert Microsoft to the seriousness with which millions of customers view the current situation.
What prompts this petition to Microsoft now?: Microsoft has declared that "mainstream support" VB6 ends on March 31, 2005. From that date forward, millions (the number varies by source, but is widely agreed to most likely exceed six million) developers and application owners will find that their code assets are no longer supported by Microsoft. Future changes to operating systems, or other software shipped by Microsoft, may break today's functioning applications.
Microsoft says the only thing that's changed is you'll no longer get two free phone support incidents - what's the rest of the story?: The end of mainstream support simply provides chimes for the countdown clock towards final abandonment. Microsoft has chosen to focus on this single issue (specifically, loss of two free phone calls) as the one they want people to think is most cared about by petitioners, yet this attempt to obscure has failed miserably in assuaging the true concerns. Foremost to many is the dangerous precedent of Microsoft declaring their customers' data to be disposable. In this regard, Microsoft has been characterized as acting in an "unacceptable", "morally indefensible", "unconscionable" manner that "should be illegal" by (at least) one of their most enthusiastic supporters! As you browse the petition, take particular notice of the wide array of support endeavors the signing MVPs have been recognized for. This should indicate the breadth of concern arising in the community as Microsoft intentionally orphans customer data. For nearly all involved, the question is whether the company that proclaims "Trustworthy Computing" as its mantra is worthy of trust itself?
Can't VB6 code simply be recompiled in VB.NET?: Sadly, no. The changes wrought to what Microsoft now calls Visual Basic really warranted a new name entirely, as the two languages are just that - two distinct languages. Microsoft provided a migration wizard intended to ease the transition from VB6 to VB.NET, true. There is near-universal agreement that using this tool to port code assets is an incomplete solution at best, in that leaves myriad "TODO:"'s scattered throughout the translated code. At worst, the migration wizard is an extremely poor choice in that, unlike a complete rewrite, it doesn't take full advantage of all that the new platform offers.
What's Microsoft's track record at moving data forward?: To the best of our knowledge, Microsoft has always "gone the extra mile" making sure its customer's data were fully transportable forward to, and generally backward from, new application software releases. Source code is, fundamentally, data. Businesses view their investments in source code as highly valuable assets, and most "business logic" is platform agnostic. Throughout the history of Microsoft BASIC (the product Microsoft was founded upon), from 1975 through 2001, code was forward compatible from one version to the next with very few notable exceptions. This all changed with the release of VB.NET, which broke every VB application ever written.
Why not leave functioning code in VB6, and write new code in VB.NET?: That's a fine solution for the problems it fits. Many developers can indeed let existing applications linger in VB6 forever (assuming future OS changes don't break them), and concentrate all their efforts on developing new VB.NET-based applications. For the great majority of VB developers, however, there is continuing need to revisit and revise legacy applications. While Microsoft may no longer want to support VB6, great numbers of VB6 developers still intend to support their customers with ongoing bug fixes and application enhancements.
Why not rewrite in VB.NET and be done with it?: Certainly, a lot of old code is thrown away and not re-used. Certainly, there are times when it is necessary and appropriate to rewrite because the old code is so patched as to be unusable as a base for further development, or because the application needs re-architecting to accommodate an increase in scale. The point though is that these occasions for rewriting are triggered by internal circumstances for individual applications. It is inappropriate that a rewrite be imposed from the outside by Microsoft, irrespective of the current quality of the source code, as the price for using the current version of development tools.
How does VBA fit into this picture?: VBA and VB6 are very much the same language, with only very minor differences (mainly in extensions) between them. Combined VB6/VBA solutions provide an extremely powerful synergy, as code modules are quite often freely exchangeable between the two environments, and VB6 can be used to author easily accessible-from-VBA libraries when source code protection or raw execution speed are priorities.; VBA is still fully supported by Microsoft, both within its Office suite, and for the many hundreds of licensees that include it in their own products. But, no development has occurred on the VBA IDE in over eight years; the team has been abandoned. New versions of Office continue, at this point, to ship with this very old technology. No decisions on replacement of VBA have been forthcoming from Microsoft, and only the vaguest of assurances have been offered as to how long it will be the preferred Office automation solution.; If VBA follows the same course as VB6, many large corporations will be forced to choose whether to continue upgrading their Office installations, or stick with the coded solutions that have made them the success they currently are. This is a huge problem for Microsoft, and one they must address meaningfully.
What good would supporting Classic VB in the Visual Studio IDE do?: Adding support for Classic VB to the Visual Studio.NET integrated development environment would greatly benefit both Microsoft and its long-term customers. Microsoft would gain immediately by the simple gesture of reaching out to the millions of disaffected customers, and ultimately by offering the mechanism by which Classic VB customers may begin experimenting with VB.NET in an environment they'd quickly become familiar with as their new source editor. Rapid, widespread adoption of the .NET platform would have virtually been assured had Classic VB source bases been immediately usable. Bringing VB.COM to the current VS IDE could tip the balance away from the marginal adoption seen today. Developers would gain, obviously, by having their code assets once again fall under the support auspices of Microsoft. They would also have the opportunity to extend their applications more easily through interoperation with the new managed languages.
Why do you want my email address?: After signing the petition, an email is immediately sent to the address you provide. Your signature will not appear on the petition if you do not click the link contained in this email. This is simply an attempt to assure that the person signing can be tracked back to an email address for which they have control. Your email address will never be made available publicly, nor be shared with spammers of any sort, we assure you. We have had over a hundred confirmation emails returned as non-deliverable, most for one of several preventable reasons. Please do not use intentionally non-deliverable addresses, as we don't have the time/energy to de-spam them for you. Please be sure your spam filters have white-listed this domain (@classicvb.org) for delivery.

Myth Busting

The changes in VB.NET were necessary for compatibility with the platform.: Most of the changes were because Microsoft thought it was improving the language. Of the changes that broke existing syntax, as opposed to adding new features, only one (the change from deterministic finalization to garbage collection) was presented with a convincing technical justification from Microsoft. Every other change amounted to language cleansing - cleaning up after decades of evolution to make the language better in the eyes of, well, mainly people who didn't use the language. In the end, some changes were justified as weakly as allowing users of other languages to make comfortable assumptions (such as the number of bits in integer datatypes) without having to read the documentation.
The petitioners are just a bunch of whiners lacking the skills to move forward.: With any group of humans, there will be natural variation that includes members who could be so characterized. As a generalization, however, claims such as this are nothing but baseless (is there any other kind?) elitism. Classic VB users recognize productivity when they find it, and find it they did - by the millions! Nothing is more productive than reusing functional, tested code in new applications. The goal of the petitioners is simply to maintain their proven investments in source code (data).
VB6 still works; there's no reason in the world they can't just keep using it.: This is more subtle, but equally wrong. If VB6 is never updated, newer platforms will acquire progressively more features which are inaccessible to applications written in VB6. Eventually, VB6 will not be able to run on modern platforms. So the evil day of rewriting may be postponed for a while, but it cannot be put off for ever. Also there's no telling when an upgrade to Windows will break a third-party OCX or DLL. Most VB6 projects make use of at least one. It's also been demonstrated that even Microsoft can and does break Classic VB functionality, such as when it changed the method by which rounding occurred in an XP build of OLEAUT32. Without ongoing support, this sort of breakage is certainly inevitable and most likely irremediable.
Platform changes are always accompanied by the need to rewrite applications.: The history of Microsoft BASIC puts the lie to this common myth. One of the very first MVPs, Mark Novisoft, had to change just two lines of code per module, when he moved his codebase from an Apple II running CPM to an IBM PC. Hardly what anyone might classify as a rewrite. This experience was repeated countless times over the following quarter-century. Core logic code was moved seamlessly from DOS to Windows, and again from 16-bit Windows 3.x to 32-bit versions of Windows. With these latter platform shifts, there were certainly disruptions, especially to user-interface design and response, but nothing of the magnitude accompanying the shift to the (so-called) .NET platform. To take a trivial example, there is no defensible reason why a QuickSort algorithm should need to be rewritten because you have a new compiler for a language targeting a new platform.
Classic VB was/is all about COM, and moving from COM meant changing VB/A.: Classic VB was hosted on COM from VB4/32 onwards. Before that, it sat on a different architecture (with VBX add-ins), but had essentially the same syntax. VB1 was an extension of QuickBasic, but still maintained and extended the same overall syntax. There are VB6 applications around that contain business logic code that dates back to before Windows existed. This argument displays nothing but historical ignorance.
There is a practical upgrade path.: It's best to draw a veil over the shortcomings of the migration wizard. In addition, you can't even copy-and-paste pure business logic code because of the syntax changes. Were rote migration tools even reliable, there is universal agreement that in order to take best advantage of what .NET offers, you really must rearchitect and rewrite any substantial application from the ground up. Classic VB code libraries have to be similarly rewritten.
There is no faster form of development than being able to re-use existing working code!: This one isn't a myth, but those who speak against the petition goals sure seem to treat it as such.

###