Please do NOT sign the VB.COM petition

[Mitchell S. Honnert]

[I apologize for the length of this post. It started out as being a summary
of some of my other posts about the petition, but grew into something
larger. Also, this post is not meant to be flamebait. I have an honest

disagreement of opinion in regards to the petition and I felt this was an

appropriate forum to have a reasoned discussion about the issue.

- Mitchell S. Honnert]

In my opinion, people should not sign the the "VB.COM" petition at

http://classicvb.org/petition/, at least not in its current form. The
objectives

listed in the petition are either already being met by the current version
of

VB6 or, when they are valid, could be much more easily resolved with a

far less dramatic solution than the one proposed.

First, let's go through the objectives listed in the petition...

"1. Preservation of assets
Future versions of VB6/VBA should:
Use existing VB6/VBA projects without extensive conversion;
Support the core VB6/VBA Visual Basic language and syntax;
Compile existing projects and produce identical results."

The *current* version of VB6 meets these criteria, so what's the
justification for a "future version"?

"2. Continued support for the Visual Basic language
Microsoft should demonstrate a commitment to the core Visual Basic
language. This core should be enhanced and extended, and changes
should follow a documented deprecation process."

Microsoft should demonstrate a commitment to the core Visual Basic
language. This core should be enhanced and extended

I view the creation of Visual Basic .NET as the best evidence there could
be that MS is committed to the "core Visual Basic language." Microsoft
could have let the Visual Basic language flounder in the form of VB6, but it
instead chose to take the language to the next level. Now *that's*
commitment. Surely the petition authors aren't so arrogant as to view
VB6 as the sole representative of the "core Visual Basic language".

and changes should follow a documented deprecation process.

The deprecation process is that there will be no new enhancement or
extending of VB6. All "extending" and "enhancing" will be to
VB.NET. Simple.

"3. Ease of migration of unmanaged VB/VBA code to VB.NET
The decisions of if, how, and when to migrate code to .NET should lie
with the customer. Some may choose to remain with unmanaged VB,
especially for legacy code bases. Some will use only VB.NET, others
a mix. A future version of VB6/VBA should treat all these options as
valid, while making it easy to move among them."

The decisions of if, how, and when to migrate code to .NET should lie with
the customer.

It already *is* the decision of the customer. One can argue that
Microsoft's suggested upgrade path (a combination of COM interop and
code conversion) is not sufficient given the number of existing VB6 systems,
but to suggest that there is no choice at all is an outright falsehood. If
what the petitioners mean is that they want *more* choice, better
solutions from Microsoft, or more support, why don't they just
say this instead of implying there is *no* choice? This kind of hyperbole
is as needless as it is ineffective. It may be a *difficult* choice for a
company to stay with its existing VB6/Win98 solution or to convert and
upgrade to a VB.NET/WinXP solution, but it *is* a choice.

Some may choose to remain with unmanaged VB,
especially for legacy code bases. Some will use only VB.NET, others
a mix. A future version of VB6/VBA should treat all these options as
valid, while making it easy to move among them.

This sounds like a pretty good description of what we have now. I would
consider the economic decision that companies currently make to stick with
VB6 or move to VB.NET as "valid". If the petitioners believe that COM
interop doesn't work as well as it should or that the code upgrade
wizard does not work as well as it should or that an upgrade which breaks
language stability deserves a longer support period, why don't they just say
so instead of leaping ahead to the conclusion that a "future version" of
VB6 is warranted?

This text appeared before the objectives...

We ask that Microsoft further develop VB6 and VBA, in order to meet these
objectives (in order of perceived importance):

I took this to mean that the petitioners believed some enhancements to VB6
were required to solve the problems that would be detailed in the
Objectives. But what I instead found was a list of objectives that was
short on problems and heavy on solution. Instead of using the Objectives
section to describe the problems that would be overcome by the proposed
solution mentioned later in the petition, the objectives are instead a
description of what the petitioners want in the solution.

Perhaps, to the petition authors, the problems that justify a future version
of VB6 are so self-evident that they aren't worth mentioning explicitly in
the petition itself, but it's not so obvious to me. Instead of the
Objectives section being a foreshadowed specifications list for the
proposed solution, why didn't they actually say what they find deficient
with the current situation? As far as I could tell, none of the objectives
detailed any current problem, so how could they justify any kind of
solution?

Now, let's move onto the suggested solution to the aforementioned
"problems", the creation of "VB.COM".

"SUGGESTED APPROACH
We believe the best way to meet these objectives is for Microsoft to
include an updated version of VB6 inside the Visual Studio IDE. For
brevity we'll call this update "VB.COM".

VB.COM should use the same keywords, syntax and types as VB6, remain
COM-based, and compile to native code. Visual Studio would then support
both unmanaged VB.COM and managed VB.NET, as it now supports both
[unmanaged] C++ and [managed] C#.

With both VBs in the same IDE, it should be possible to extend the
development environment to provide a high degree of interoperation
between them. That will allow the developer to use both in the same
solution, with the interop handled seamlessly by the framework."

From this description, it appears as if the main point of VB.COM would be to
give VB6 developers the benefits of the VS.NET IDE, yet not change the
underlying VB6 language. There is no mention made of functional
deficiencies, so the assumption is that the petitioners want VB6 developers
to have the ease-of-use benefits of using the VS.NET IDE, such as
eliminating the need to ALT-TAB between the VB6 IDE and the VS.NET IDE,
better Intelisense, and auto code indenting.

Is this petition really about IDE enhancements? Is the touchy-feely goal of
"reaching out" to the VB6 developer by gently introducing them to the VS.NET
IDE seen as justifying the huge effort it would take to create VB.COM? If
not...if there are actual functional deficiencies in Microsoft's migration
path (COM interop and code conversion), why don't the petitioners just say
this instead of suggesting a solution that, by all indications in the
petition, is focused on the comparatively small IDE issues? I'm sorry, but
MS doesn't owe VB6 developers the IDE enhancement that come with

VS.NET even if they did do it for C++ and no matter how many people are

currently using VB6.

In my personal opinion (and that's all this post is, after all), I think
that the issues that are alluded to in the petition (but never directly
stated) could be addressed much more appropriately by improving on
Microsoft's current "upgrade path". So, instead of undertaking the
monumental task of integrating VB6 into the VS.NET IDE, Microsoft
could improve on COM interop and, probably more importantly, provide
a better code upgrade wizard. And to give the large number of VB6
users some extra breathing room required from the revolutionary change
from VB6 to VB.NET, Microsoft could extend its mainstream support
period, including the release of bug fixes. But because the perceived
problems are commingled in the petition with the proposed solution of
VB.COM, the reader is guided away from these otherwise obvious
alternative -- and in my opinion far more reasonable -- solutions.

I fully acknowledge that I may be focusing too much on the language of the
petition, rather than the underlying issues. But one of the things that
bothers me so much about the petition is how it treats the need for VB.COM
as a foregone conclusion. From previous threads on this newsgroup and from
the petition's FAQ, I got a sense of the issues the prompted the petition,
but this information wasn't obvious from reading the petition itself. It
would seem to me that the authors of the petition would have served their
purpose much better by being more explicit on *why* they believed that
Microsoft should create VB.COM rather than focusing so much on describing
*what* they want VB.COM to be.

Opponents of the petition have been accused of ignoring the huge number
of companies who still have active VB6 applications. For me, I would
say that I'm not ignoring them, just that I believe there is a solution that
is much more in proportion to the problems. In other words, it's not that
I disagree that there is a problem. (I personally think that Microsoft
should have supplied a much better automatic code conversion tool.) It's
just that I believe the creation of VB.COM would be overkill.

Maybe all the petitioners really want with VB.COM is a better IDE, but from
the language used in the petition and in related posts, it sure sound like a
whole lot more. All the talk of "extending" and "enhancing" gives me the
impression that the authors and signers don't just want VB6 to simply reside
in the .NET IDE, but that they want major new functionality added to VB6.
This is at the heart of my personal disagreement with the petition. I
personally don't feel that it is Microsoft's responsibility to supply the
features of the current generation of an application to the users of the
previous generation. If the problem is that the migration from one
generation to another is too difficult, then the solution should be to make
that migration easier, not to make that previous generation application
*into* the next generation application.

So, why is there such a discrepancy between the problems and the solution?
Are the petitioners using the standard bargaining technique of asking for
way more than you know you'll get, in the hopes that you'll get what you
really wanted in the first place? I don't think so. Here's my theory. I
have noticed that the most vocal proponents of VB.COM just so happen to
hold the opinion that Microsoft made a huge mistake by making VB.NET in
the first place. They either believe the advances in VB.NET were not worth
the cost in the break of language stability or that the advances could have
come without breaking language stability. In other words, they wanted MS

to create Visual Basic 7 instead of VB.NET.

Is this juxtaposition of attitudes a coincidence? Or could it be that the
reason that the petition's proposed solution is such overkill is because the
*unstated* problem is the existence of VB.NET itself and not the migration
path to VB.NET? I'm sure I'll get feedback to the contrary, but this is the
only logical explanation that I can see as to why the petition's proposal
goes so far beyond what would be necessary to resolve the implied migration
and support issues.

- Mitchell S. Honnert

 

[Chris]

vb 6.0 is a crappy development lang. Single Thead applications. BLA.
Everything you could do in vb 6.0 you can do in vb.net
execpt active x. Which there is a new way of doing it

This is a least what I have found.
I would love for them to put true active x in to .net development ide

[I apologize for the length of this post. It started out as being a
summary
of some of my other posts about the petition, but grew into something
larger. Also, this post is not meant to be flamebait. I have an honest

disagreement of opinion in regards to the petition and I felt this was an

appropriate forum to have a reasoned discussion about the issue.

- Mitchell S. Honnert]

In my opinion, people should not sign the the "VB.COM" petition at

http://classicvb.org/petition/, at least not in its current form. The
objectives

listed in the petition are either already being met by the current version
of

VB6 or, when they are valid, could be much more easily resolved with a

far less dramatic solution than the one proposed.

First, let's go through the objectives listed in the petition...

"1. Preservation of assets
Future versions of VB6/VBA should:
Use existing VB6/VBA projects without extensive conversion;
Support the core VB6/VBA Visual Basic language and syntax;
Compile existing projects and produce identical results."

The *current* version of VB6 meets these criteria, so what's the
justification for a "future version"?

"2. Continued support for the Visual Basic language
Microsoft should demonstrate a commitment to the core Visual Basic
language. This core should be enhanced and extended, and changes
should follow a documented deprecation process."

Microsoft should demonstrate a commitment to the core Visual Basic
language. This core should be enhanced and extended

I view the creation of Visual Basic .NET as the best evidence there could
be that MS is committed to the "core Visual Basic language." Microsoft
could have let the Visual Basic language flounder in the form of VB6, but
it
instead chose to take the language to the next level. Now *that's*
commitment. Surely the petition authors aren't so arrogant as to view
VB6 as the sole representative of the "core Visual Basic language".

and changes should follow a documented deprecation process.

The deprecation process is that there will be no new enhancement or
extending of VB6. All "extending" and "enhancing" will be to
VB.NET. Simple.

"3. Ease of migration of unmanaged VB/VBA code to VB.NET
The decisions of if, how, and when to migrate code to .NET should lie
with the customer. Some may choose to remain with unmanaged VB,
especially for legacy code bases. Some will use only VB.NET, others
a mix. A future version of VB6/VBA should treat all these options as
valid, while making it easy to move among them."

The decisions of if, how, and when to migrate code to .NET should lie with
the customer.

It already *is* the decision of the customer. One can argue that
Microsoft's suggested upgrade path (a combination of COM interop and
code conversion) is not sufficient given the number of existing VB6
systems,
but to suggest that there is no choice at all is an outright falsehood.
If
what the petitioners mean is that they want *more* choice, better
solutions from Microsoft, or more support, why don't they just
say this instead of implying there is *no* choice? This kind of hyperbole
is as needless as it is ineffective. It may be a *difficult* choice for a
company to stay with its existing VB6/Win98 solution or to convert and
upgrade to a VB.NET/WinXP solution, but it *is* a choice.

Some may choose to remain with unmanaged VB,
especially for legacy code bases. Some will use only VB.NET, others
a mix. A future version of VB6/VBA should treat all these options as
valid, while making it easy to move among them.

This sounds like a pretty good description of what we have now. I would
consider the economic decision that companies currently make to stick with
VB6 or move to VB.NET as "valid". If the petitioners believe that COM
interop doesn't work as well as it should or that the code upgrade
wizard does not work as well as it should or that an upgrade which breaks
language stability deserves a longer support period, why don't they just
say
so instead of leaping ahead to the conclusion that a "future version" of
VB6 is warranted?

This text appeared before the objectives...

We ask that Microsoft further develop VB6 and VBA, in order to meet these
objectives (in order of perceived importance):

I took this to mean that the petitioners believed some enhancements to VB6
were required to solve the problems that would be detailed in the
Objectives. But what I instead found was a list of objectives that was
short on problems and heavy on solution. Instead of using the Objectives
section to describe the problems that would be overcome by the proposed
solution mentioned later in the petition, the objectives are instead a
description of what the petitioners want in the solution.

Perhaps, to the petition authors, the problems that justify a future
version
of VB6 are so self-evident that they aren't worth mentioning explicitly in
the petition itself, but it's not so obvious to me. Instead of the
Objectives section being a foreshadowed specifications list for the
proposed solution, why didn't they actually say what they find deficient
with the current situation? As far as I could tell, none of the
objectives
detailed any current problem, so how could they justify any kind of
solution?

Now, let's move onto the suggested solution to the aforementioned
"problems", the creation of "VB.COM".

"SUGGESTED APPROACH
We believe the best way to meet these objectives is for Microsoft to
include an updated version of VB6 inside the Visual Studio IDE. For
brevity we'll call this update "VB.COM".

VB.COM should use the same keywords, syntax and types as VB6, remain
COM-based, and compile to native code. Visual Studio would then support
both unmanaged VB.COM and managed VB.NET, as it now supports both
[unmanaged] C++ and [managed] C#.

With both VBs in the same IDE, it should be possible to extend the
development environment to provide a high degree of interoperation
between them. That will allow the developer to use both in the same
solution, with the interop handled seamlessly by the framework."

From this description, it appears as if the main point of VB.COM would be
to
give VB6 developers the benefits of the VS.NET IDE, yet not change the
underlying VB6 language. There is no mention made of functional
deficiencies, so the assumption is that the petitioners want VB6
developers
to have the ease-of-use benefits of using the VS.NET IDE, such as
eliminating the need to ALT-TAB between the VB6 IDE and the VS.NET IDE,
better Intelisense, and auto code indenting.

Is this petition really about IDE enhancements? Is the touchy-feely goal
of
"reaching out" to the VB6 developer by gently introducing them to the
VS.NET
IDE seen as justifying the huge effort it would take to create VB.COM? If
not...if there are actual functional deficiencies in Microsoft's migration
path (COM interop and code conversion), why don't the petitioners just say
this instead of suggesting a solution that, by all indications in the
petition, is focused on the comparatively small IDE issues? I'm sorry,
but
MS doesn't owe VB6 developers the IDE enhancement that come with

VS.NET even if they did do it for C++ and no matter how many people are

currently using VB6.

In my personal opinion (and that's all this post is, after all), I think
that the issues that are alluded to in the petition (but never directly
stated) could be addressed much more appropriately by improving on
Microsoft's current "upgrade path". So, instead of undertaking the
monumental task of integrating VB6 into the VS.NET IDE, Microsoft
could improve on COM interop and, probably more importantly, provide
a better code upgrade wizard. And to give the large number of VB6
users some extra breathing room required from the revolutionary change
from VB6 to VB.NET, Microsoft could extend its mainstream support
period, including the release of bug fixes. But because the perceived
problems are commingled in the petition with the proposed solution of
VB.COM, the reader is guided away from these otherwise obvious
alternative -- and in my opinion far more reasonable -- solutions.

I fully acknowledge that I may be focusing too much on the language of the
petition, rather than the underlying issues. But one of the things that
bothers me so much about the petition is how it treats the need for VB.COM
as a foregone conclusion. From previous threads on this newsgroup and
from
the petition's FAQ, I got a sense of the issues the prompted the petition,
but this information wasn't obvious from reading the petition itself. It
would seem to me that the authors of the petition would have served their
purpose much better by being more explicit on *why* they believed that
Microsoft should create VB.COM rather than focusing so much on describing
*what* they want VB.COM to be.

Opponents of the petition have been accused of ignoring the huge number
of companies who still have active VB6 applications. For me, I would
say that I'm not ignoring them, just that I believe there is a solution
that
is much more in proportion to the problems. In other words, it's not that
I disagree that there is a problem. (I personally think that Microsoft
should have supplied a much better automatic code conversion tool.) It's
just that I believe the creation of VB.COM would be overkill.

Maybe all the petitioners really want with VB.COM is a better IDE, but
from
the language used in the petition and in related posts, it sure sound like
a
whole lot more. All the talk of "extending" and "enhancing" gives me the
impression that the authors and signers don't just want VB6 to simply
reside
in the .NET IDE, but that they want major new functionality added to VB6.
This is at the heart of my personal disagreement with the petition. I
personally don't feel that it is Microsoft's responsibility to supply the
features of the current generation of an application to the users of the
previous generation. If the problem is that the migration from one
generation to another is too difficult, then the solution should be to
make
that migration easier, not to make that previous generation application
*into* the next generation application.

So, why is there such a discrepancy between the problems and the solution?
Are the petitioners using the standard bargaining technique of asking for
way more than you know you'll get, in the hopes that you'll get what you
really wanted in the first place? I don't think so. Here's my theory. I
have noticed that the most vocal proponents of VB.COM just so happen to
hold the opinion that Microsoft made a huge mistake by making VB.NET in
the first place. They either believe the advances in VB.NET were not worth
the cost in the break of language stability or that the advances could
have
come without breaking language stability. In other words, they wanted MS

to create Visual Basic 7 instead of VB.NET.

Is this juxtaposition of attitudes a coincidence? Or could it be that the
reason that the petition's proposed solution is such overkill is because
the
*unstated* problem is the existence of VB.NET itself and not the migration
path to VB.NET? I'm sure I'll get feedback to the contrary, but this is
the
only logical explanation that I can see as to why the petition's proposal
goes so far beyond what would be necessary to resolve the implied
migration
and support issues.

- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

vb 6.0 is a crappy development lang. Single Thead applications.
BLA.

In most cases, a single thread is sufficient. For the other cases ActiveX
EXEs could be used to archieve multithreading in VB6.

Everything you could do in vb 6.0 you can do in vb.net
execpt active x.

That's not the point of the whole discussion. You can do everything you can
currently do with <insert any programming language> in pure assembler too.
This doesn't make all programming languages except assembler obsolete.

 

[Cor Ligthert]

Chris,

I do not want ActiveX. I would like a new alternative .Net plugin acting
like javaplugins. Not able to do more than screen processing. The
alternative needs to much security settings. The problem (as you probably
know) with ActiveX and EXE's is that nobody will install it anymore.

Cor

 

[Herfried K. Wagner [MVP]]

Cor,

I do not want ActiveX. I would like a new alternative .Net plugin acting
like javaplugins. Not able to do more than screen processing. The
alternative needs to much security settings. The problem (as you probably
know) with ActiveX and EXE's is that nobody will install it anymore.

The same as for ActiveX components and EXE files applies to Java applets
too. There have been some holes in Java's sandbox recently, so using
applets is not save any more in general.

 

[Phill. W]

.. . .

"1. Preservation of assets .. . .
The *current* version of VB6 meets these criteria, so what's the
justification for a "future version"?

As you say; the /current/ version "works" - Today.
A /future/ version would *guarantee* that it would /continue/
to work "Tomorrow".

Since VB "proper" is no longer "supported", it will no longer be
considered in /any/ future deliberations regarding the development
of /anything/ within the Redmond Reality Distortion Zone.

In short, there will no longer be any /reason/ for Our Friends in
Redmond /not/ to break it. And therein lies /my/ concern.

.. . .

In other words, they wanted MS to create Visual Basic 7
instead of VB.NET.

And, as far as /I /understand things, they /did/ write VB7, then
handed it lock, stock and barrel to the ".Net Team", who promptly
tossed it into the bin and created VB.Net anyway.
They /could/ have re-written the VB7 compiler to produce
IL code and fed that into the .Net linker had they /wanted/ to,
thereby allowing the vast amounts of "legacy" VB6 assets to
continue to work, without recoding, atop the .Net Framework
(albeit less efficiently, perhaps). But they chose not to, instead
handing us a new language, based on new paradigms and with no
serious "upgrade" mechanism short of complete rewrites.

Regards,
Phill W.

 

[Dick Grier]

Hi,

I don't agree with all aspects of the petition (perhaps not even most of
them). However, I signed it because of the things with which I DO agree.

I like and use .NET. I will expand my use of .NET as my clients demand, and
where they understand the benefits. However... As of today, 75% of my work
involves VB6.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.

 

[Ray Cassick]

Hi,

I like and use .NET. I will expand my use of .NET as my clients demand, and
where they understand the benefits. However... As of today, 75% of my work
involves VB6.

But that it today... The petition seems to point to the fact that some
poeple never want VB6 to go away. EVER!

 

[Paul Clement]

¤ > vb 6.0 is a crappy development lang. Single Thead applications.
¤ > BLA.
¤
¤ In most cases, a single thread is sufficient. For the other cases ActiveX
¤ EXEs could be used to archieve multithreading in VB6.
¤

Yes, in a rather ugly way. In any event it's a poor man's substitute that cannot be implemented for
in-process DLL components running under environments that support free threading.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Mitchell S. Honnert]

I don't agree with all aspects of the petition (perhaps not even most of

them)

I agree...kind of. One of the points I was trying to get across in my
original post was that, in spite of the fact that I agreed that some of the
problems implied by the petition were substantial issues, the suggested
proposal was a showstopper. In other words, just because I agreed that
there were problems, doesn't mean I was going to sign my name in support of
a solution that so was far out of whack with the problems.

I like and use .NET. I will expand my use of .NET as my clients demand,
and where they understand the benefits. However... As of today, 75% of my
work involves VB6.

OK, so you are what I picture as a large percentage of the VB6 programmers
that the petitioners are using to justify the creation of VB.COM, namely
that you would prefer to use VB.NET if given the choice, but because of the
simple matter that there is so much VB6 code still out there, that's what
you work with. Is this fair? If so, I'm very curious to find out what your
opinion is on the alternative proposal I mentioned in my original post.
Specifically, as a VB6 programmer, I would assume you would *like* to have
all of the cool IDE features of VS.NET when programming VB6, but do you
believe it is Microsoft "proper" responsibility to supply these features?
In other words, if Microsoft improved the migration wizard, addressed any
outstanding COM interop problems, and exended mainstream support, would you
still be motivated to sign a petition in support of VB.COM?

- Mitchell S. Honnert

 

[Mitchell S. Honnert]

As you say; the /current/ version "works" - Today.

A /future/ version would *guarantee* that it would /continue/
to work "Tomorrow".

But there is no reasonable expectation that a software development
company will guarantee that its software will always work "tomorrow".

I think a natural part of programming language's (and any
application, for that matter) is the principle of diminishing support. One
can argue the specifics of how long a particular application should be fully
supported by its developer, but I don't think it's a controversial concept
that a developer should not have to support a product *forever*. It's a
given that over time, a developer has a diminishing support responsibility.

As this relates to VB6, I don't think Microsoft has made a secret out of
its scheduled plans to reduce support for VB6. I take it that a major
gripe of the petitioners is that, in practical terms, there are so many
people still using VB6 that the normal "diminishing support" schedule
does not apply. Perhaps surprising to some, I would agree. Where
the disagreement with the petitioners comes is with the distinction
between "support" and "enhancing and extending". When MS, or
whatever programming language developer, puts out a revolutionary
upgrade to a language (as it did with VB.NET), what it owes its
customers is a reasonable upgrade path and longer-than-normal
support period. In my opinion, "reasonable" doesn't mean as easy as
porting code from VB5 to VB6, but neither does it mean having to
almost start from scratch. What the company does *not* owe its
customers is an unending flow of enhancements and upgrades to the
legacy product. Patches and bug fixes, yes, but not major
enhancements. In my opinion, incorporating VB6 into the VS.NET
would leave the realm of "support" and enter that of "extending
and enhancing".

Since VB "proper" is no longer "supported", it will no longer be
considered in /any/ future deliberations regarding the development
of /anything/ within the Redmond Reality Distortion Zone.

And your point is? If Microsoft had to consider every single version of
its previous applications, it would get so bogged down, that it wouldn't
be able to develop any new software. Without the principle of
diminishing support, a company wouldn't be able to stay in business
and there wouldn't *be* a company to support any legacy applications.

In short, there will no longer be any /reason/ for Our Friends in
Redmond /not/ to break it. And therein lies /my/ concern.

If you don't want to break your VB6 applications, then don't run them on
operating system that don't support VB6. I don't know what Microsoft's
official stance is on which versions of Windows support VB6, but it would
seem perfectly reasonable to me for Microsoft to reduce the amount of
effort it puts into making VB6 compatible with subsequent releases of
Windows.

But this is besides the point of the petition. It wasn't asking
for Microsoft to extend the mainstream support period or improve the
upgrade wizard; it was asking Microsoft to give them what they
wanted all along, VB7.

- Mitchell S. Honnert




- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

But there is no reasonable expectation that a software development
company will guarantee that its software will always work "tomorrow".

I think a natural part of programming language's (and any
application, for that matter) is the principle of diminishing support.

There is nothing wrong with diminishing support if a viable upgrade path is
available. Current usage numbers show that migration does on much slower
than expected, and thus Microsoft should rethink their product strategies.
I don't remember people complaining that Microsoft reduced support for VB5.
This was mainly due to the fact that Microsoft provided a viable upgrade
path with VB5's successor VB6. As long as there is no viable upgrade path
and no almost code-compatible successor of VB6, companies and people using
VB6 will be dissatisfied.

This doesn't necessarily apply to every VB6 company or developer, and maybe
it doesn't apply to you. However, it applies to at least 5,000 people who
signed the petition.

I am just curious what causes you to act against the petition. It seems
that you are doing that only because the concerns don't affect you, which is
IMO a very egoistic point of view. Are you afraid to loose something if
customers get what they want to get?

 

[Mitchell S. Honnert]

There is nothing wrong with diminishing support if a viable upgrade path

is available.

This is where we agree. But as I pointed out in the original post, where I
disagree is what steps Microsoft has to take to provide a "viable" upgrade
path. In my opinion, it is far less than what is being proposed by the
petition.

I am just curious what causes you to act against the petition.

I think I've made it quite clear in my post why I'm against the petition.
To repeat, I believe the petitioners have legitimate concerns, but that
because they didn't agree with Microsoft's decision to make VB.NET (instead
of just a "VB7"), their solution goes way beyond what would be required to
address those concerns.

It seems that you are doing that only because the concerns don't affect
you, which is IMO a very egoistic point of view.

While I will admit that I'm fortunate enough to no longer to have to work
with VB6, this issue still affects me. I would say that I'm "doing this"
because of the disproportion (as I view it) of the petition's implied
problems and its proposed solution. Primarily, I would want to discourage
people from signing the petition and secondarily, I would like to get a
better idea of why the people who have signed it think it's a good idea.

Are you afraid to loose something if customers get what they want to get?

If that means a minority of customers getting what they want at the expense
of the majority of customers, then yes. What I'm afraid of losing,
Herfried, is a better VS.NET at the expense of a new VB.COM. It's not that
I don't want VB6 developers to have the same cool IDE
features that VB.NET developers have. I am not some kind of sadist that
revels in the anguish that a VB6 developer must feel every day knowing that
there is a far superior tool out there s/he could use if only their employer
had enough money to convert their system over to VB.NET. To me it comes
down to the practical matter of resource allocation. Yes, Microsoft is one
of the biggest companies in the world, but they still have a finite amount
of resources. Short of hiring new people to work on VB.COM (which I don't
think they will do), the only thing they can do is to steal resources away
from other projects, most probably VB.NET. I'm sorry, but I personally
don't believe that VS.NET should be delayed by any length of time so that
VB6 developers don't have to use the ALT-TAB key so much or have to continue
to indent their own code.

If the problems that prompted the petition deal with migration and
mainstream support, why does the proposed solution go to the extreme (and
therefore resource-costly) measure of a new IDE?

- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

Mitchell,

This is where we agree. But as I pointed out in the original post, where
I disagree is what steps Microsoft has to take to provide a "viable"
upgrade path. In my opinion, it is far less than what is being proposed
by the petition.

I won't doubt that there is more than one way to solve the problems implied
by the end of VB6. However, I think that the proposed solution is one of
the cheapest possible solutions which will please the VB6 community.

I think I've made it quite clear in my post why I'm against the petition.
To repeat, I believe the petitioners have legitimate concerns, but that
because they didn't agree with Microsoft's decision to make VB.NET
(instead of just a "VB7"), their solution goes way beyond what would be
required to address those concerns.

I am sure that most of them (including me) are not against VB.NET at all,
but instead they are against disposal of a product and customers' assets
without any reason. Sure, there are people who don't understand why
Microsoft made the decision to build VB.NET and dispose VB6 because the
disposal of VB affects their investments. For me, as a VB.NET user, the
concern is about disposing VB6, not about the existance or further
developing VB.NET.

While I will admit that I'm fortunate enough to no longer to have to work
with VB6, this issue still affects me. I would say that I'm "doing this"
because of the disproportion (as I view it) of the petition's implied
problems and its proposed solution. Primarily, I would want to discourage
people from signing the petition and secondarily, I would like to get a
better idea of why the people who have signed it think it's a good idea.

It's interesting that on the one hand you don't seem to be sure /why/ people
signed the petition, but on the other hand want to discourage people from
signing it, even if they have valid reasons to sign (which you obviously
don't see because they don't affect you).

If that means a minority of customers getting what they want at the
expense of the majority of customers, then yes.

I agree with that, but I strongly doubt that this applies to this issue.

How many VFP users are there compared to VB6 users? It's a very low number.
Is this a valid reason to dispose VFP? Are you afraid to loose a better
VS.NET at the expense of a new version of VFP or a new version of <any
Microsoft language/product you don't use or which is used by a small number
of customers>?

Imagine you were one of the VB6 developers who have huge assets in VB6 code
and you see the deconstruction of Classic VB. Wouldn't you be afraid that
you are loosing a better VB6 at the expense of a new programming language
called VB.NET? I don't have the same opinion as people who think this way,
mainly because my assets in VB6 are not that huge, but I can understand
those people's concerns and lack of comprehension about VB.NET.

What I'm afraid of losing, Herfried, is a better VS.NET at the expense of
a new VB.COM. It's not that I don't want VB6 developers to have the same
cool IDE
features that VB.NET developers have.

Personally, I don't expect a VB.COM to provide all the new features of
VS.NET. I cannot speak for all people who signed the petition, but I assume
that lots of them don't expect that too. The tight integration of the
Classic VB language via VB.COM into VS.NET only provides the infrastructure
for a seamless transition.

I am not some kind of sadist that revels in the anguish that a VB6
developer must feel every day knowing that there is a far superior tool
out there s/he could use if only their employer had enough money to
convert their system over to VB.NET.

Compared to VS.NET 2002 and 2003 I treat VB.NET as less-RAD than VB6, and I
liked the VB6 IDE more. VS 2005 may change that, but I don't miss much when
using VB6 today. However, that's my personal opinion and I respect that
other people's opinions differ from mine.

To me it comes

down to the practical matter of resource allocation. Yes, Microsoft is
one of the biggest companies in the world, but they still have a finite
amount of resources. Short of hiring new people to work on VB.COM (which
I don't think they will do), the only thing they can do is to steal
resources away from other projects, most probably VB.NET.

I already told that in one of my previous posts, but I'll repeat it again:
I understand that nobody wants his favorite product to be delayed only
because of a product he doesn't use, but this applies to the users of all
products. As a Classic VB/VB.NET developer I may want to see C# and J# to
be discontinued and all the money put into further development of Classic
VB/VB.NET. Nevertheless, I see that this standpoint is untenable.

If the problems that prompted the petition deal with migration and
mainstream support, why does the proposed solution go to the extreme (and
therefore resource-costly) measure of a new IDE?

In politics everybody requests more than he can finally get ;-).

 

[Mitchell S. Honnert]

Mitchell,



I won't doubt that there is more than one way to solve the problems
implied by the end of VB6. However, I think that the proposed solution is
one of the cheapest possible solutions which will please the VB6
community.

But there are people out there who believe it *is* the only way. Jim
Hubbard, for example. I'll grant that this is open to interpretation, but
in my opinion, it would be far more difficult to incorporate VB6 into VS.NET
as VB.COM than it would be to simply extend mainstream support or improve
the code upgrade wizard.

I am sure that most of them (including me) are not against VB.NET at all,
but instead they are against disposal of a product and customers' assets
without any reason.

It's not that I believe (or stated) that most people who signed the petition
are "against VB.NET"; it's that I theorize that the authors of the petition
disagreed with Microsoft's decision to create VB.NET (instead of VB7) to
such an extent that it might explain why they are asking for so much more
than would be necessary to address the implied problems.

Sure, there are people who don't understand why Microsoft made the
decision to build VB.NET and dispose VB6 because the disposal of VB
affects their investments. For me, as a VB.NET user, the concern is about
disposing VB6, not about the existance or further developing VB.NET.

It's interesting that on the one hand you don't seem to be sure /why/
people signed the petition, but on the other hand want to discourage
people from signing it, even if they have valid reasons to sign (which you
obviously don't see because they don't affect you).

What, I'm not allowed to have an opinion and to simultaneously solicit the
opposing side's viewpoint? I personally hate it when people end their posts
with "...and there's nothing you can ever say that would convince me
otherwise!" To me, this kind of statement is proof positive that the person
has closed their mind to the issue and is refusing to listen to reason. I'm
not saying that I'm absolutelly right. I'm saying that, based on the
argument I've laid out, I *believe* that I am right, but that I am open to
logical arguments to the contrary.

I agree with that, but I strongly doubt that this applies to this issue.

How many VFP users are there compared to VB6 users? It's a very low
number. Is this a valid reason to dispose VFP? Are you afraid to loose a
better VS.NET at the expense of a new version of VFP or a new version of
<any Microsoft language/product you don't use or which is used by a small
number of customers>?

The key distinction between Visual Fox Pro and VB.COM is that there is
already a VFP team in place and producing code. Microsoft doesn't have to
hire any new programmers or shanghai programmers from other teams to create
a new version of VFP. All the have to do is let the existing team alone.
But to create a new VB.COM team, they'd have to do either hire or reallocate
resources. If they hired new programmers, they'd have the additinional
costs of training them. And if they took the programmers from other
departments, what department do you think would be the most likely victim?
Why, VB.NET of course! (And I'm sure that the people who are working on
creating the next version of VB.NET would just *love* to get a tap on the
shoulder one day to be told they getting moved to the VB.COM team. Yay!)

Therein lies the key to our disagreement, I believe that the creation of
VB.COM would be much more costly than you do and I therefore see it as being
a resource drain which would slow down the development of other MS projects,
namely VS.NET.

Imagine you were one of the VB6 developers who have huge assets in VB6
code and you see the deconstruction of Classic VB.

Your use of the word "deconstruction" is specious, at best. There is a vast
difference between letting something "die on the vine" and actively
destroying it.

Wouldn't you be afraid that you are loosing a better VB6 at the expense of
a new programming language called VB.NET? I don't have the same opinion
as people who think this way, mainly because my assets in VB6 are not that
huge, but I can understand those people's concerns and lack of
comprehension about VB.NET.

I'm sure that from the standpoint of the company that made horse-drawn
carriages, any kind of support for "new-fangled" automobiles would be seen
as misplaced. But fortunately, we can look outside the perspectives of the
individual and look at what is reasonable from an external standpoint.

Personally, I don't expect a VB.COM to provide all the new features of
VS.NET. I cannot speak for all people who signed the petition, but I
assume that lots of them don't expect that too. The tight integration of
the Classic VB language via VB.COM into VS.NET only provides the
infrastructure for a seamless transition.


Compared to VS.NET 2002 and 2003 I treat VB.NET as less-RAD than VB6, and
I liked the VB6 IDE more. VS 2005 may change that, but I don't miss much
when using VB6 today. However, that's my personal opinion and I respect
that other people's opinions differ from mine.

OK. So how would imbedding VB6 into VS.NET improve on VB6's RADness? If
anything, I would think that it would reduce it.

To me it comes

I already told that in one of my previous posts, but I'll repeat it again:
I understand that nobody wants his favorite product to be delayed only
because of a product he doesn't use, but this applies to the users of all
products. As a Classic VB/VB.NET developer I may want to see C# and J# to
be discontinued and all the money put into further development of Classic
VB/VB.NET. Nevertheless, I see that this standpoint is untenable.

I agree that the "standpoint is untenable", but this is, in effect, exactly
what the petition is asking Microsoft to do. The petition doesn't specify
what project it believes has less priority than VB.COM, but because it would
have to get the resources from *somewhere*, the implication of VB.COM is
that some other project would have to be scrapped or drastically reduced.
At least if someone came up and petitioned Microsoft to ditch VFP so they'd
have more resources apply to VS.NET, it'd be an honest request. Instead,
what the petition does is make a request that would necessitate some project
get ditched or seriously reduced, but leave it to MS to be the bad guy and
decide who gets the axe.

In politics everybody requests more than he can finally get ;-).

LOL. You're not comparing the petitioners to politicians, are you? I
thought you were defending them and here you go insulting them to the
highest degree. Doh!

- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

Mitchell,

But there are people out there who believe it *is* the only way. Jim
Hubbard, for example.

Jim Hubbard isn't sufficient for extrapolating to the whole number of people
who signed. I know some dozens of people who signed the petition, and only
/very few/ of them believe the suggested way is the only way. BTW: It's a
suggestion, not a request (see petition FAQ).

I'll grant that this is open to interpretation, but in my opinion, it
would be far more difficult to incorporate VB6 into VS.NET as VB.COM than
it would be to simply extend mainstream support or improve the code
upgrade wizard.

If Microsoft would extend mainstream support for VB6, that would be a great
thing. However, I don't think this is a good idea, because it costs
Microsoft money without bringing money back to Microsoft. A new version of
VB6, VB.COM for example, would bring money back which can be used for
further development (SPs, new versions, ...) of VB.COM. People /would/ pay
for VB.COM, but they won't pay for fixes for the flawed SP6, which has never
been fixed in the mainstream support period.

Microsoft's commitment to its VB6 customers has been at best half-hearted
(oh, that's a hyperbole!) since the disposal of VB6. All together,
Microsoft's commitment to those who actually wanted to switch to VB.NET was
half-hearted. The upgrade wizard is flawed and is not eben able to convert
usercontrols in an acceptable manner. Tons of whitepapers don't really help
because they won't take the work away from people "upgrading to" (more
appropriately: "rewriting in the new programming language") VB.NET.

If the code upgrade wizard could be improved to a stage where it is capable
of converting > 95 percent of the VB6 code out there, everything would be
great. Nobody would even think of staying with VB6. However, this is a
pipedream, languages are too different for that to become true, and thus
another solution is required. VB.COM is one of them, and it's one of the
cheaper solutions. It's a proposal, if Microsoft says that it's better to
develop a VB7 in a separate IDE -- well, great. I'd very likely purchase
it, and many other VB6 users too. Again, notice the difference between
proposal and request.

It's not that I believe (or stated) that most people who signed the
petition are "against VB.NET"; it's that I theorize that the authors of
the petition disagreed with Microsoft's decision to create VB.NET (instead
of VB7) to such an extent that it might explain why they are asking for so
much more than would be necessary to address the implied problems.

Would you expect these people (including me) to add something like "Ease of
migration of unmanaged VB/VBA code to VB.NET" to the petition's text?
Re-read the petition. You are not the only one who picks out some parts of
the petition and complains about them without seeing the petition as a
whole, including all its points.

What, I'm not allowed to have an opinion and to simultaneously solicit the
opposing side's viewpoint?

You are allowed to have an opinion, but I believe that acting against other
people's wishes and concerns as an outsider is reprehensible.

I personally hate it when people end their posts with "...and there's
nothing you can ever say that would convince me otherwise!" To me, this
kind of statement is proof positive that the person has closed their mind
to the issue and is refusing to listen to reason. I'm not saying that I'm
absolutelly right. I'm saying that, based on the argument I've laid out,
I *believe* that I am right, but that I am open to logical arguments to
the contrary.

I would not judge about something until I heard all the arguments of the
opposite. Everything else is simply provocation and sarcasm, nothing more.

I personally use both, Classic VB and VB.NET. I like both languages and I
believe that both languages should have a future. I believe that every
programming language which is heavily used by customers has its right to
exist. For me, you seem to disagree with that (please correct me if I am
wrong), you are not even ignoring what doesn't affect you, in fact you are
rooting against other people's interests.

The key distinction between Visual Fox Pro and VB.COM is that there is
already a VFP team in place and producing code. Microsoft doesn't have to
hire any new programmers or shanghai programmers from other teams to
create a new version of VFP. All the have to do is let the existing team
alone.

Keeping the VFP team costs money too. Marketing of VFP costs money. This
money could be used for improving VB.NET, for example (note that this is
/not/ my opinion!).

But to create a new VB.COM team, they'd have to do either hire or
reallocate resources. If they hired new programmers, they'd have the
additinional costs of training them.

They reallocated the IE team too, and this was not a problem. Nobody
complained about these additional costs.

And if they took the programmers from other departments, what department
do you think would be the most likely victim? Why, VB.NET of course! (And
I'm sure that the people who are working on creating the next version of
VB.NET would just *love* to get a tap on the shoulder one day to be told
they getting moved to the VB.COM team. Yay!)

If VB.COM was part of the current VS suite, people working in the VB.COM
team would be proud too. I don't think that people choose to work on a
certain project for ideological reasons.

Therein lies the key to our disagreement, I believe that the creation of
VB.COM would be much more costly than you do and I therefore see it as
being a resource drain which would slow down the development of other MS
projects, namely VS.NET.

Well, with the same line of argument you could ask Microsoft to discontinue
all other developer tools than the .NET Framework and VB.NET, and let all
the people currently involved in these teams work in the .NET Framework or
VB.NET teams. All of those other teams are taking lots of resources from
the .NET Framework and VB.NET teams.

Your use of the word "deconstruction" is specious, at best. There is a
vast difference between letting something "die on the vine" and actively
destroying it.

A real VB7 already existed, which has never been released. Classic VB has
been actively destroyed, otherwise it would continue to exist.

I'm sure that from the standpoint of the company that made horse-drawn
carriages, any kind of support for "new-fangled" automobiles would be seen
as misplaced. But fortunately, we can look outside the perspectives of
the individual and look at what is reasonable from an external standpoint.

You are mixing up the manufacturer with the customer. In the case of VB6 ->
VB.NET, customers are requesting a product, but the manufacturer tries hard
to dictate customers to use another product. There is no better expert for
a product than the customer who uses it and for whom it has been created.

OK. So how would imbedding VB6 into VS.NET improve on VB6's RADness? If
anything, I would think that it would reduce it.

It would make the transition from VB6 to VB.NET a rapid and tightly
integrated process. I would not expect RAD improvements for VB6.

I agree that the "standpoint is untenable", but this is, in effect,
exactly what the petition is asking Microsoft to do. The petition doesn't
specify what project it believes has less priority than VB.COM, but
because it would have to get the resources from *somewhere*, the
implication of VB.COM is that some other project would have to be scrapped
or drastically reduced.

If the petitioners would request Microsoft to stop certain products in order
to get the resources for the development of VB.COM, maybe you were the first
one who would complain about the petitioners /requesting/ things. VB.COM is
a suggestion, nothing more. It's a proposal which should reflate the dialog
between Microsoft and its customers. The petition doesn't request features,
and it doesn't attempt to dictate anything.

At least if someone came up and petitioned Microsoft to ditch VFP so
they'd have more resources apply to VS.NET, it'd be an honest request.
Instead, what the petition does is make a request that would necessitate
some project get ditched or seriously reduced, but leave it to MS to be
the bad guy and decide who gets the axe.

I doubt that Microsoft would need to "axe" anybody. VB6 customers already
got the axe, although they paid for VB6 to guarantee for VB6's future.

LOL. You're not comparing the petitioners to politicians, are you? I
thought you were defending them and here you go insulting them to the
highest degree. Doh!

I am one of the petitioners, for the case you didn't yet realize that. Show
me only a single sample where people didn't ask for more than they finally
got...

 

[Mitchell S. Honnert]

Mitchell,



Jim Hubbard isn't sufficient for extrapolating to the whole number of
people who signed. I know some dozens of people who signed the petition,
and only /very few/ of them believe the suggested way is the only way. Understood.

BTW: It's a suggestion, not a request (see petition FAQ).

We can argue the fine points of word meanings, but any "suggestion" in the
context of a petition is something more than a suggestion. When you sign
your name to something, I think it's reasonable to assume that it rises to
the level of a request. What's the difference anyway? Regardless of what
you call it, I don't think there's any doubt that the petitioners want
Microsoft to create VB.COM. "A rose by any other name..."

If Microsoft would extend mainstream support for VB6, that would be a
great thing. However, I don't think this is a good idea, because it costs
Microsoft money without bringing money back to Microsoft. A new version
of VB6, VB.COM for example, would bring money back which can be used for
further development (SPs, new versions, ...) of VB.COM. People /would/
pay for VB.COM, but they won't pay for fixes for the flawed SP6, which has
never been fixed in the mainstream support period.

You make a good point about the potential for VB.COM being a self-sustaining
revenue stream. But instead of Microsoft creating and selling VB.COM being
seen as the company answering the requests of the VB6 community, I
personally believe that it would be seen as a blatant money-grab. The
reaction would be "What? They want to charge me for this? They should be
giving it to me for free for what they did to me!" As I've stated before, I
think the petition would have received a far colder reception if the
petitioners were more clear on their intent that Microsoft would charge for
VB.COM. You may think it's self-evident that MS would have to charge for
VB.COM, but I maintain that a good portion of the signees would have
second-thoughts if they realized it wasn't free.

Microsoft's commitment to its VB6 customers has been at best half-hearted
(oh, that's a hyperbole!) since the disposal of VB6. All together,
Microsoft's commitment to those who actually wanted to switch to VB.NET
was half-hearted. The upgrade wizard is flawed and is not eben able to
convert usercontrols in an acceptable manner. Tons of whitepapers don't
really help because they won't take the work away from people "upgrading
to" (more appropriately: "rewriting in the new programming language")
VB.NET.

If the code upgrade wizard could be improved to a stage where it is
capable of converting > 95 percent of the VB6 code out there, everything
would be great. Nobody would even think of staying with VB6. However,
this is a pipedream, languages are too different for that to become true,
and thus another solution is required. VB.COM is one of them, and it's
one of the cheaper solutions. It's a proposal, if Microsoft says that
it's better to

OK, so 95% automatic code conversion is a pipedream. For the sake of
argument, let's take that as the exact percentage. Now, what does the code
conversion wizard do? 50%? 60%? Whatever it is, it's far less than 95%.
So, isn't there a lot of room for improvement between 60% and 95%. My point
is that while you can't ever automate 100% of the conversion between VB6 and
VB.NET, there is plenty of improvement that could be done with the current
version of the migration wizard. You suggest that incorporating VB6 into the
VS.NET IDE would be a cheaper solution than improving the code migration
wizard, but I just don't see this. When I think of the work involved in
creating VB.COM, I envision a nightmare of reconciling compatibility issues.
Improving the code conversion wizard would deal with some of these issues,
but at least they'd be a one-time process per project.

develop a VB7 in a separate IDE -- well, great. I'd very likely purchase
it, and many other VB6 users too. Again, notice the difference between
proposal and request.

I'm still don't see where you're going with the distinction between
"proposal" and "request".

Would you expect these people (including me) to add something like "Ease
of migration of unmanaged VB/VBA code to VB.NET" to the petition's text?

Why, yes I would. If the resolution to that problem is one of the goals of
the petitioners, I would expect it to be clearly stated in the text of the
petition.

Re-read the petition. You are not the only one who picks out some parts
of the petition and complains about them without seeing the petition as a
whole, including all its points.

If you are going to accuse me of taking statements out of context, could you
be more specific in the details of the accusation? I've read the petition a
few times now, but I don't see how this has anything to do with any of my
statements, especially the one above.

You are allowed to have an opinion, but I believe that acting against
other people's wishes and concerns as an outsider is reprehensible.

But I'm not an outsider. I used to be a VB6 programmer and, because I
believe VB.COM poses a risk to further VS.NET development, it relates to me
directly. You may not agree that is poses this risk, but that is one of the
very points of our discussion. It sounds like what you are saying is that
because I don't agree with you that I'm reprehensible. I'm sorry you feel
this way, but reasoned debate is how an issue is resolved. I don't find
your opposition reprehensible, just incorrect.

I would not judge about something until I heard all the arguments of the
opposite. Everything else is simply provocation and sarcasm, nothing
more.

You lost me here, mate. I believe I laid out my arguments completely (some
would say *too* completely) in the original post. What do you find
provocative or sarcastic about what I've said?

I personally use both, Classic VB and VB.NET. I like both languages and I
believe that both languages should have a future. I believe that every
programming language which is heavily used by customers has its right to
exist. For me, you seem to disagree with that (please correct me if I am
wrong),

No one is saying that VB6 doesn't have a right to exist. This kind of
language is flat out hyperbole. This is one of the most frustrating things
about this whole issue: supporters of the petition act as if Microsoft is
getting ready to flip a switch that will make all VB6 applications disappear
in a puff of smoke. It's been said many times already, but you can use VB6
as long as you want. Nothing is stopping you. Your VB6 apps can "exist" as
long as you want. But that's not the issue, is it? The issue is what MS
can do to make it *easier* to exist.

you are not even ignoring what doesn't affect you, in fact you are rooting
against other people's interests.

I've addressed this point in my original post. I believe the proposal would
affect me, therefore the petition is relevent to me.

Keeping the VFP team costs money too. Marketing of VFP costs money. This
money could be used for improving VB.NET, for example (note that this is
/not/ my opinion!).


They reallocated the IE team too, and this was not a problem. Nobody
complained about these additional costs.

I don't think anyone complained because MS was responding to public demand
to supply a product that would take them into the future, whereas the
petition represents a small percentage of the programming community who are
perceived as wanting to go back to the past. Fair or not, that's the
impression I think most people have when they see the headlines like
"Microsoft MVPs Say They Want Old VB Back"

If VB.COM was part of the current VS suite, people working in the VB.COM
team would be proud too. I don't think that people choose to work on a
certain project for ideological reasons.

I think you're wrong. In my experiance, programmers are some of the most
idealogical people in the professional world. Maybe most accountants have
"holy wars" about abstract FASB rules, but I somehow doubt that it rises to
the level of the programming field. Any beancounters out there? ;-)

Well, with the same line of argument you could ask Microsoft to
discontinue all other developer tools than the .NET Framework and VB.NET,
and let all the people currently involved in these teams work in the .NET
Framework or VB.NET teams. All of those other teams are taking lots of
resources from the .NET Framework and VB.NET teams.

Again, the distinction here is that VB.COM would require the addition of a
*new* team. I am not asking for the elimination of any team. (I'm not
asking for anything at all.) It's the petition itself that would require
the creation of a new team or the partial dismantling of an existing team.

A real VB7 already existed, which has never been released. Classic VB has
been actively destroyed, otherwise it would continue to exist.

Even after the multiple times you've brought up the aborted VB7, I still
don't see how it has any bearing whatsoever on the topic at had. You said
that MS is "deconstructing" VB6. I said that MS may not be supporting it as
much as you want, but it's not deconstructing it. You bring up the fact
that at a very early stage in VB.NET's development, it was much closer to
VB6. Huh? Can you say non-sequiter?

You are mixing up the manufacturer with the customer. In the case of
VB6 -> VB.NET, customers are requesting a product, but the manufacturer
tries hard to dictate customers to use another product. There is no
better expert for a product than the customer who uses it and for whom it
has been created.

Again, I had a very different experience than you. VB.NET was viewed by my
co-workers and clients and the answer to their longstanding prayers for a
major overhaul to VB6, not as something that was being forced on them by MS.

It would make the transition from VB6 to VB.NET a rapid and tightly
integrated process. I would not expect RAD improvements for VB6.


If the petitioners would request Microsoft to stop certain products in
order to get the resources for the development of VB.COM, maybe you were
the first one who would complain about the petitioners /requesting/
things. VB.COM is a suggestion, nothing more. It's a proposal which
should reflate the dialog between Microsoft and its customers. The
petition doesn't request features, and it doesn't attempt to dictate
anything.

Doesn't request features? Maybe you should re-read the petition. Every one
of the "objectives" is a feature request.

I doubt that Microsoft would need to "axe" anybody. VB6 customers already
got the axe, although they paid for VB6 to guarantee for VB6's future.


I am one of the petitioners, for the case you didn't yet realize that.
Show me only a single sample where people didn't ask for more than they
finally got...

I don't mean to offend, Herfried, but I don't understand what you are asking
for here. My joke above was meant to lighten the conversation a bit.
That's all. Perhaps you could rephrase and I'll answer.

- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

We can argue the fine points of word meanings, but any "suggestion" in the
context of a petition is something more than a suggestion. When you sign
your name to something, I think it's reasonable to assume that it rises to
the level of a request.

It doesn't, because it's marked as suggestion. I don't understand what's so
hard in understanding the difference.

What's the difference anyway? Regardless of what you call it, I don't
think there's any doubt that the petitioners want Microsoft to create
VB.COM. "A rose by any other name..."

That's your interpretation. I can only speak for myself, but I am open for
/any/ solution that leads to a reduction of the issue.

You make a good point about the potential for VB.COM being a
self-sustaining revenue stream. But instead of Microsoft creating and
selling VB.COM being seen as the company answering the requests of the VB6
community, I personally believe that it would be seen as a blatant
money-grab.

Again, that's your interpretation which stands against common practice. The
petition doesn't /request an SP7/, it /suggests to create a new version/.
Typically, new versions are never available for free, but service packs are.
In addition to that, service packs don't include new features while new
versions do.

OK, so 95% automatic code conversion is a pipedream.

Microsoft somewhere states it converts /up to/ 95 percent of the code, which
actually is true, but is not a great thing. An average number would be more
interesting.

For the sake of argument, let's take that as the exact percentage. Now,
what does the code conversion wizard do? 50%? 60%? Whatever it is, it's
far less than 95%. So, isn't there a lot of room for improvement between
60% and 95%.

It doesn't really matter. There are language features which cannot be
replaced in VB.NET. I remember the upgrade wizard adding dummy items to
arrays in order to archieve 1-based arrays. That's a hack, nothing more.
Those hacks will make code practically unmaintainable and will /reduce the
quality of the code/.

My point is that while you can't ever automate 100% of the conversion
between VB6 and VB.NET, there is plenty of improvement that could be done
with the current version of the migration wizard.

It depends on how much it technically can be improved in the best case. If
the maximum average convertable percentage is smaller than a certain number,
conversion won't be an option at all and the conversion wizard is thus
rather useless.

You suggest that incorporating VB6 into the VS.NET IDE would be a cheaper
solution than improving the code migration wizard, but I just don't see
this. When I think of the work involved in creating VB.COM, I envision a
nightmare of reconciling compatibility issues.

I doubt that implementation of a VB.COM would such a big problem.
Integration of other unmanaged programming languages into VS.NET was
possible too. However, I don't suspect that the migration process will be
finished in shorter time if a VB.COM exists, but I expect it to become
economically feasible.

Improving the code conversion wizard would deal with some of these issues,
but at least they'd be a one-time process per project.

Using the conversion wizard will reduce the code's quality, mainly because
the differences between VB.NET and VB6 are too big. Sure, the conversion
wizard could be extended to emit some more ugly workarounds and hacks, but I
don't think that this is what people are requesting. The optimal solution
would be to keep existing VB6 code in Classic VB for long future, without a
need for a rewrite. This approach has been successfully chosen vor C(++)
and VFP.

Why, yes I would. If the resolution to that problem is one of the goals
of the petitioners, I would expect it to be clearly stated in the text of
the petition.

It actually /is/ clearly stated in the petition.

If you are going to accuse me of taking statements out of context, could
you be more specific in the details of the accusation? I've read the
petition a few times now, but I don't see how this has anything to do with
any of my statements, especially the one above.

You theorized that the authors of the petition are "against VB.NET" because
you missed that one of the petition's main points is about easing the
migration to VB.NET for those who want to migrate.

No one is saying that VB6 doesn't have a right to exist. This kind of
language is flat out hyperbole. This is one of the most frustrating
things about this whole issue: supporters of the petition act as if
Microsoft is getting ready to flip a switch that will make all VB6
applications disappear in a puff of smoke.

They already did that by releasing a flawed SP6 and at least one DLL that
changes applications' behavior (see petition's FAQ).

I don't think anyone complained because MS was responding to public demand
to supply a product that would take them into the future, whereas the
petition represents a small percentage of the programming community who
are perceived as wanting to go back to the past.

LOL -- more than 5,000 signatures and counting. Compared to other
development-related petitions that's a very high number. There are still
millions of VB6 users, I posted links to surveys previously.

Fair or not, that's the impression I think most people have when they see
the headlines like "Microsoft MVPs Say They Want Old VB Back"

That's media... We don't have much influence on this.

Even after the multiple times you've brought up the aborted VB7, I still
don't see how it has any bearing whatsoever on the topic at had. You said
that MS is "deconstructing" VB6. I said that MS may not be supporting it
as much as you want, but it's not deconstructing it.

Support gives a guarantee that no deconstruction occurs. Currently one DLL
file changed the behavior of existing applications. There is no guarantee
that, for example, a future version of Office will not introduce new
versions of DLLs which break existing VB6 applications. If VB6 was still
supported, Microsoft would have to take care about such situations.

Again, I had a very different experience than you. VB.NET was viewed by
my co-workers and clients and the answer to their longstanding prayers for
a major overhaul to VB6, not as something that was being forced on them by
MS.

I don't doubt that you had a different experience, but surveys and my
personal experience show me that there are still lots of developers who
continue using VB6. Nobody of us is able to change that, but it's possible
to make Microsoft aware of that in order to take action.

Doesn't request features? Maybe you should re-read the petition. Every
one of the "objectives" is a feature request.

It doesn't request features like DataTips and other stuff which is unique to
VS.NET, that's what I wanted to say.

 

[Mitchell S. Honnert]

It doesn't, because it's marked as suggestion. I don't understand what's
so hard in understanding the difference.

The difference is this: I can walk up and punch you in the face and call it
a "tap", but no matter what I choose to call it, it's still a punch.
Specifically, the objective of any petition, by definition is not a
"suggestion". Here's the Merriem-Webster's definition of "petition"...

1 : an earnest request : ENTREATY
2 a : a formal written request made to an official person or organized body
(as a court) b : a document embodying such a formal written request
3 : something asked or requested

Notice the repetition of the word "request" in the definition? You can
attempt to couch the request in any euphamistic terms you please, but a
petition is by definition a request, not a suggestion.

That's your interpretation.

Huh? The very name of the petition is "A PETITION FOR THE DEVELOPMENT OF
UNMANAGED VISUAL BASIC AND VISUAL BASIC FOR APPLICATIONS". There's not much
interpretation required there. It's an objective truth that the petitioners
want VB.COM.

I can only speak for myself, but I am open for /any/ solution that leads
to a reduction of the issue.

But you *are* speaking for the petitioners. As you pointed out in your
previous post, you are one. In any case, the topic at hand is the
petition's request that Microsoft create VB.COM, not what solutions you are
personally open to. I'll say it again, the crux of my opposition to the
petition is not the problems that are alluded to in the petition, but the
proposed solution.

Again, that's your interpretation which stands against common practice.
The petition doesn't /request an SP7/, it /suggests to create a new
version/. Typically, new versions are never available for free, but
service packs are. In addition to that, service packs don't include new
features while new versions do.


Microsoft somewhere states it converts /up to/ 95 percent of the code,
which actually is true, but is not a great thing. An average number would
be more interesting.


It doesn't really matter. There are language features which cannot be
replaced in VB.NET. I remember the upgrade wizard adding dummy items to
arrays in order to archieve 1-based arrays. That's a hack, nothing more.
Those hacks will make code practically unmaintainable and will /reduce the
quality of the code/.

So, you point to a flaw in the current upgrade wizard as proof that it would
be pointless to improve the upgrade wizard? This doesn't make any sense.
The very point of what I'm saying is that there is room for improvement in
the code upgrade wizard and that this avenue would be a far more cost
effective and, more importantly, attainable solution than VB.COM.

It depends on how much it technically can be improved in the best case.
If the maximum average convertable percentage is smaller than a certain
number, conversion won't be an option at all and the conversion wizard is
thus rather useless.

OK. Are you saying that you believe this is the case, that the upgrade
wizard can't be improved to the point where it's not "rather useless". If
so, it's a bit ironic to read all of the people whinging about all of the
ToDo's the upgrade wizard leaves in the code when those things are
unavoidable.

I doubt that implementation of a VB.COM would such a big problem.
Integration of other unmanaged programming languages into VS.NET was
possible too. However, I don't suspect that the migration process will be
finished in shorter time if a VB.COM exists, but I expect it to become
economically feasible.

You can put the expressions in adjacent sentences, but there's a huge chasm
between the principles of "not a big problem" and "possible". Of course,
it's *possible* to create VB.COM. It's just a matter of how much money you
want to burn to develop it.

Using the conversion wizard will reduce the code's quality, mainly because
the differences between VB.NET and VB6 are too big. Sure, the conversion
wizard could be extended to emit some more ugly workarounds and hacks, but
I don't think that this is what people are requesting. The optimal
solution would be to keep existing VB6 code in Classic VB for long future,
without a need for a rewrite. This approach has been successfully chosen
vor C(++) and VFP.

I'll keep saying this until I get a logical rebuttal: if you want to keep
using VB6, then do so. No one is stopping you. But if you want to convert
your VB6 code to VB.NET, then an improved upgrade wizard would be helpful.

It actually /is/ clearly stated in the petition.

That is the *header* of one of the objectives, but it is contradicted by the
actual *text* of the objective. The objective doesn't say "We want
migration from VB6/VBA to VB.NET to be easier"; it says that if you give us
VB.COM, it will be easy to "move among" VB6/VBA and VB.NET, whatever that
means.

You theorized that the authors of the petition are "against VB.NET"
because you missed that one of the petition's main points is about easing
the migration to VB.NET for those who want to migrate.

I did propose a theory on why I believed the petitioners went so far beyond
what would be reasonably required to resolve the implied issues, but I'm
still don't see what you believe I took out of context.

They already did that by releasing a flawed SP6 and at least one DLL that
changes applications' behavior (see petition's FAQ).

Problem: Microsoft releases a flawed version a VB6 service pack.
Reasonable solution: petition Microsoft to release another service pack to
fix the problems in the previous service pack.
Unreasonable solution that people who never wanted there to be a VB.NET in
the first place can use as a pretext to get VB7 (what they wanted all
along): petition Microsoft for VB.COM

LOL -- more than 5,000 signatures and counting. Compared to other
development-related petitions that's a very high number.

You could have ten times that many signatures and it would still be a small
percentage of the programming community.

There are still millions of VB6 users, I posted links to surveys
previously.

And I previously pointed out the flaw of equating the number of people who
program in VB6 to the number of people want to extend the lifetime of VB6.

That's media... We don't have much influence on this.

True enough.

Support gives a guarantee that no deconstruction occurs. Currently one
DLL file changed the behavior of existing applications. There is no
guarantee that, for example, a future version of Office will not introduce
new versions of DLLs which break existing VB6 applications. If VB6 was
still supported, Microsoft would have to take care about such situations.

I see your point about how lack of mainstream support increases the risk of
breaking specific VB6 functions, but 1) I think this is a far cry from
"deconstruction" 2) I actually agree with you that MS should extend
mainstream support for VB6 (which, BTW, is not a stated objective of the
petition) 3) I still don't see what relevance the aborted VB7 has on this
topic.

I don't doubt that you had a different experience, but surveys and my
personal experience show me that there are still lots of developers who
continue using VB6. Nobody of us is able to change that, but it's
possible to make Microsoft aware of that in order to take action.

You stated that MS was dictating that their customers use another product
(VB.NET). I countered that with my view that many customers *wanted*
VB.NET, not that it was forced on them. Merely because there are "lots" of
people still developing in VB6, doesn't support the fact that those people
*want* to program in VB6 or that they believed that VB.NET was being forced
on them.

It doesn't request features like DataTips and other stuff which is unique
to VS.NET, that's what I wanted to say.

OK.

- Mitchell S. Honnert

 

[Daniel]

lol! nice example with the punch! you could also beat him unconscious and
say that you accidentally bumped into him repeatedly!

--

Daniel
MCSE, MCP+I, MCP in Windows 2000/NT