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
"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
- 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
- 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
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
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)
- 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
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
- 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
- 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
- This one isn't a myth, but those who speak against the petition goals sure
seem to treat it as such.