By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,131 Members | 1,494 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,131 IT Pros & Developers. It's quick & easy.

Microsoft MVPs Say They Want Old VB Back

Share this Question
Share on Google+
182 Replies


P: n/a
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
http://www.eweek.com/article2/0,1759,1774642,00.asp


For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Nov 21 '05 #2

P: n/a
Soapbox time!!!!!!!!

I cannot understand how, on and after 1 April 2005, I am not going to be
able to do things with VB6(SP6) that I can do on and prior to 31 March 2005.
Just because 'Mainstream' support is withdrawn from that date does not mean
I won't be able to use it.

Objective 1 of the petition talks about 'Preservation of assets'. If you
have an asset then it is in place today. If it works today then it is not
magically going to stop working on 1 April. It is therefore spurious to
argue that a 'Future versions of VB6/VBA' (sic) (which, at this stage, there
won't be) will destroy your asset(s). That's like saying that no matter what
models of automobile may be developed in the future, the manufacturer will
always have to provide support for the particular model that I drive today.
In other words - 'I want to see innovation but I also want everything the
way it has always been'.

In objective 2 it states 'This core should be enhanced and extended, and
changes should follow a documented deprecation process.' Am I the only one
who wonders how one can enhance and extend something and peprecate it at the
same time. To me 'enhance and extend' and 'deprecate' are complete
opposites.

In objective 3 it states '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.' Please excuse my mistake in thinking that this is exactly the
case today and is not going to change on 1 April. Also, don't forget about
the developers who are using a mix of VB6, VB.NET and C#.NET to provide
solutions.

In my personal experience I only encountered 2 'issues' in VB6 which needed
to be addressed by Microsoft and both were addressed in later service packs.
In the meantime a rather unattractive workaround was used to acheive the
desired result. While there was much gnashing of teeth at the time, the pain
soon passed. It does beg the question 'What new things are people attempting
to do with VB6 that are throwing up so many widespread issues that
mainstream support is still required?' I am quickly coming to the view that
some are trying to use VB6 to do something that it is just not designed to
do and then criticising Microsoft when it doesn't do it. If that is the case
then I'm afraid I cannot support that sort of behaviour. I also wonder if
some have been using mainstream support as an alternative to 'Read The
Flaming Manual' or other methods of self-help support - It certainly appears
that many use these newgroups in that manner.

In some of the articles regarding this petition it talks about projects not
being migrated to VB.Net because it is complex. So what. An automobile is
complex compared to a bicycle but that doesn't stop teenagers migrating from
the bike to the car. Complex does not mean difficult!!! Unfortunately there
are those who equate the two words and, in doing so, do nothing more than
make things difficult for themseleves. There are also those who seem
incapable of doing anything unless the entire wherewithall is handed to them
on a plate. Along with these are those who wring their hands and make
themselves sick with worry in case they don't get a particular line of code
right the first time. To all those for whom the cap fits all I can say is,
get of your backsides, learn something for yourselves, be prepared to try
something. You'll be surprised just how much one can get done when one is
not spending ones efforts in waiting for someone else to do it for one or
worrying if one has got it right first time.

To finish, I believe that Microsoft announced the timetable from ending
mainstream support for VB6 some 2 years ago, so I'm also wondering why it
has taken so long for a petition such as this to appear, or is it nothing
more than a knee-jerk reaction to the recent reminder.

Stephany

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ot*************@TK2MSFTNGP15.phx.gbl...
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
http://www.eweek.com/article2/0,1759,1774642,00.asp


For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #3

P: n/a
UGH!

I am a VB developer since the day it was born. I purchased my first copy of
VB version 1 from Babbage's software at the Galleria mall in September of
1991 and have never looked back since.
I have gotten into many religious battles with other developers over the
typical arguments that VB is a real language that can be used to write real
applications by real developers.

I have gotten to know it very well, spending countless hours learning,
studying and making sure that I understood as much of the language as I can.

All that, and even I think it should die a quite death and be replaced by
VB.NET

Support for VB Version 6 ends on 3/31/2005. Let it die with dignity and
respect.

It is a time to mourn the past and grow towards the future.

If you want to read the rest visit my blog at the link below...

http://spaces.msn.com/members/rcassick/Blog/cns!1pXjHq-RqqMSQdLvn5n4gdnw!113.entry
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ot*************@TK2MSFTNGP15.phx.gbl...
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
http://www.eweek.com/article2/0,1759,1774642,00.asp


For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #4

P: n/a
Ok, I was a stupid head here and gave the wrong link to the wrong blog
entry...

http://spaces.msn.com/members/rcassick/Blog/cns!1pXjHq-RqqMSQdLvn5n4gdnw!111.entry

Sheesh... I should have at least checked the link before I posted the
message right?

"Ray Cassick (Home)" <rc************@enterprocity.com> wrote in message
news:eU*************@TK2MSFTNGP15.phx.gbl...
UGH!

I am a VB developer since the day it was born. I purchased my first copy
of VB version 1 from Babbage's software at the Galleria mall in September
of 1991 and have never looked back since.
I have gotten into many religious battles with other developers over the
typical arguments that VB is a real language that can be used to write
real applications by real developers.

I have gotten to know it very well, spending countless hours learning,
studying and making sure that I understood as much of the language as I
can.

All that, and even I think it should die a quite death and be replaced by
VB.NET

Support for VB Version 6 ends on 3/31/2005. Let it die with dignity and
respect.

It is a time to mourn the past and grow towards the future.

If you want to read the rest visit my blog at the link below...

http://spaces.msn.com/members/rcassick/Blog/cns!1pXjHq-RqqMSQdLvn5n4gdnw!113.entry
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ot*************@TK2MSFTNGP15.phx.gbl...
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
http://www.eweek.com/article2/0,1759,1774642,00.asp


For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>


Nov 21 '05 #5

P: n/a
Applause...

Well said.

"Stephany Young" <noone@localhost> wrote in message
news:uh****************@TK2MSFTNGP09.phx.gbl...
Soapbox time!!!!!!!!

I cannot understand how, on and after 1 April 2005, I am not going to be
able to do things with VB6(SP6) that I can do on and prior to 31 March
2005. Just because 'Mainstream' support is withdrawn from that date does
not mean I won't be able to use it.

Objective 1 of the petition talks about 'Preservation of assets'. If you
have an asset then it is in place today. If it works today then it is not
magically going to stop working on 1 April. It is therefore spurious to
argue that a 'Future versions of VB6/VBA' (sic) (which, at this stage,
there won't be) will destroy your asset(s). That's like saying that no
matter what models of automobile may be developed in the future, the
manufacturer will always have to provide support for the particular model
that I drive today. In other words - 'I want to see innovation but I also
want everything the way it has always been'.

In objective 2 it states 'This core should be enhanced and extended, and
changes should follow a documented deprecation process.' Am I the only one
who wonders how one can enhance and extend something and peprecate it at
the same time. To me 'enhance and extend' and 'deprecate' are complete
opposites.

In objective 3 it states '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.' Please excuse my mistake in thinking that this is exactly
the case today and is not going to change on 1 April. Also, don't forget
about the developers who are using a mix of VB6, VB.NET and C#.NET to
provide solutions.

In my personal experience I only encountered 2 'issues' in VB6 which
needed to be addressed by Microsoft and both were addressed in later
service packs. In the meantime a rather unattractive workaround was used
to acheive the desired result. While there was much gnashing of teeth at
the time, the pain soon passed. It does beg the question 'What new things
are people attempting to do with VB6 that are throwing up so many
widespread issues that mainstream support is still required?' I am quickly
coming to the view that some are trying to use VB6 to do something that it
is just not designed to do and then criticising Microsoft when it doesn't
do it. If that is the case then I'm afraid I cannot support that sort of
behaviour. I also wonder if some have been using mainstream support as an
alternative to 'Read The Flaming Manual' or other methods of self-help
support - It certainly appears that many use these newgroups in that
manner.

In some of the articles regarding this petition it talks about projects
not being migrated to VB.Net because it is complex. So what. An automobile
is complex compared to a bicycle but that doesn't stop teenagers migrating
from the bike to the car. Complex does not mean difficult!!! Unfortunately
there are those who equate the two words and, in doing so, do nothing more
than make things difficult for themseleves. There are also those who seem
incapable of doing anything unless the entire wherewithall is handed to
them on a plate. Along with these are those who wring their hands and make
themselves sick with worry in case they don't get a particular line of
code right the first time. To all those for whom the cap fits all I can
say is, get of your backsides, learn something for yourselves, be prepared
to try something. You'll be surprised just how much one can get done when
one is not spending ones efforts in waiting for someone else to do it for
one or worrying if one has got it right first time.

To finish, I believe that Microsoft announced the timetable from ending
mainstream support for VB6 some 2 years ago, so I'm also wondering why it
has taken so long for a petition such as this to appear, or is it nothing
more than a knee-jerk reaction to the recent reminder.

Stephany

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ot*************@TK2MSFTNGP15.phx.gbl...
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
http://www.eweek.com/article2/0,1759,1774642,00.asp


For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>


Nov 21 '05 #6

P: n/a
I can only give answers from the veiwpoint of the classic VB programmers
that I am personally familiar with. I do not speak for everyone on the
petition. My comments only relate the things I have personally experienced
and are by no means the end-all-be-all of those wishing to continue classic
VB.

That being said.....let's get started, shall we?

"Stephany Young" <noone@localhost> wrote in message
news:uh****************@TK2MSFTNGP09.phx.gbl...
Soapbox time!!!!!!!!

I cannot understand how, on and after 1 April 2005, I am not going to be
able to do things with VB6(SP6) that I can do on and prior to 31 March
2005. Just because 'Mainstream' support is withdrawn from that date does
not mean I won't be able to use it.
True. It only means that classic VB will not have the errors that are in
it's runtime addressed (or new security issues addressed) or the runtime
optimized for speed. The classic VB developers that I know want to extend
classic VB, as well as fix it's current problems. To them (and myself)
extending classic VB does not mean or necessitate a completely new language
like VB.Net.

Objective 1 of the petition talks about 'Preservation of assets'. If you
have an asset then it is in place today. If it works today then it is not
magically going to stop working on 1 April. It is therefore spurious to
argue that a 'Future versions of VB6/VBA' (sic) (which, at this stage,
there won't be) will destroy your asset(s). That's like saying that no
matter what models of automobile may be developed in the future, the
manufacturer will always have to provide support for the particular model
that I drive today. In other words - 'I want to see innovation but I also
want everything the way it has always been'.
Actually, they are saying "I want to see innovation, but I don't want to
entirely re-learn programming, expose my code needlessly to others, expand
the runtime from less than 2MB to over 23MB, rewrite tons of code just to be
able to use it in the new programming IDE and I'd like to keep programming
simple. My needs are simple. I'd like to keep my code that way."

One of the things that is hardly ever touched on is that the vast majority
of classic VB "programmers" we are talking about (MVPs not withstanding) are
not "real programmers" (in the purely technical sense).

They are not MIS majors. They do not "write code" for a living. They write
code to make making a living easier. The vast majority do not care to hack
the kernel, directly manipulate memory or even have a purely object oriented
language. They just want to be able to quickly churn out a little
application that makes their job (or their hobby) easier.

They are not interested in competing with J2EE (if they even know what it
is) or with C++ programmers. And, the very few that do want to do direct
memory manipulation, to hook the kernel, to code in an all-object-oriented
environment or develop enterprise-wide applications are more than capable of
learning C/C++/C# to do so.

Rarely have I ever heard a classic VB developer with these aspirations
refuse to move to C++ to accomplish these goals. Quite the
contrary.....they run there.

In objective 2 it states 'This core should be enhanced and extended, and
changes should follow a documented deprecation process.' Am I the only one
who wonders how one can enhance and extend something and peprecate it at
the same time. To me 'enhance and extend' and 'deprecate' are complete
opposites.
Well......you depreciate older features while adding replacement features
that may offer more speed, flexibility or functionality. Like going
depreciating "navigate" in the IE object model and adding "navigate2".

VB.Net is not an extension of classic VB. VB.Net is C# (a JAVA copy) with
superficial classic VB (syntax) thrown in to make it look like they actually
did something with VB besides just scrap it.

In objective 3 it states '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.' Please excuse my mistake in thinking that this is exactly
the case today and is not going to change on 1 April. Also, don't forget
about the developers who are using a mix of VB6, VB.NET and C#.NET to
provide solutions.
Since unmanaged C++ is handled by Visual Studio .Net, why not classic VB?
Since C++ is still being updated (patched), why not classic VB?

I'll tell you why......it was not a concern of the programmers at Microsoft,
the majority of which are C++ programmers. VB was never seen as a serious
programming tool by them (not that it should be considered on the same level
as C++ in terms of capability). Understandable. But, it should have been
taken seriously as a wildly successful Microsoft product that met the needs
of millions of part-time-programmers worldwide and supported a real and
potential revenue stream that any company not Microsoft's size would kill to
have.

In my personal experience I only encountered 2 'issues' in VB6 which
needed to be addressed by Microsoft and both were addressed in later
service packs. In the meantime a rather unattractive workaround was used
to acheive the desired result. While there was much gnashing of teeth at
the time, the pain soon passed. It does beg the question 'What new things
are people attempting to do with VB6 that are throwing up so many
widespread issues that mainstream support is still required?'
Mainly, extending capablities of the runtime to enable easy access (remember
EASY is the thing the accountant/programmer values the most) to web services
and new Windows API functionality as well as handling any security issues
that may arise with the runtime.
I am quickly coming to the view that some are trying to use VB6 to do
something that it is just not designed to do and then criticising Microsoft
when it doesn't do it.
Some do. But, they are such a small (although vocal) minority that they
really are only a bother if you listen to the minority instead of the
majority of classic VB developers.
If that is the case then I'm afraid I cannot support that sort of
behaviour.
I agree....to a point. If you want to do something today that classic VB
can't do, write a DLL or ActiveX control to accomplish it (usually in C++)
or move on to C++ for it's power.
I also wonder if some have been using mainstream support as an alternative
to 'Read The Flaming Manual' or other methods of self-help support - It
certainly appears that many use these newgroups in that manner.
Also true. But, this can be said of any developers - be they classic VB, C,
C++, JAVA or whatever. People are lazy by default. They take the easy way
out. Fortunately, most of use did the same thing and are happy to share our
knowledge because we too asked "easy" questions once upon a time.

In some of the articles regarding this petition it talks about projects
not being migrated to VB.Net because it is complex. So what. An automobile
is complex compared to a bicycle but that doesn't stop teenagers migrating
from the bike to the car. Complex does not mean difficult!!! Unfortunately
there are those who equate the two words and, in doing so, do nothing more
than make things difficult for themseleves.
But, that's where everyone is missing the whole appeal of classic VB, the
power of classic VB and the continuing need of such a product as classic VB.

Classic VB gave accountants, lawyers, students, teachers, fishermen,
electricians and just about any layperson the ability to quickly put
together the solution to a presssing problem. The problem may be temporary
or, it may be just a prototype of a larger production application that is
needed - and, using classic VB, they could design and implement a stop-gap
measure until an enterprise solution was coded.

Complexity kills rapid application development. The more complex, the less
rapid. Bosses loved the rapid way in which most employees could take VB and
put together solutions to company probelms in days or hours instead of weeks
or months for a similar C++ application.

The typical classic VB developer doesn't give a rat's behind if you fancy
him/her a programmer. S/he gets the job done, keeps the boss happy and
makes the company money. And, for them, that's what counts.
There are also those who seem incapable of doing anything unless the entire
wherewithall is handed to them on a plate.
I think this is an unfair assessment of the typical classic VB programmer.
For 99% of them, they never intended to make a living learning programming.
They already have a job. Classic VB made it easy to enhance and simplify
their jobs. The language was easy and RAD.

For the vast majority of programmers that have only known classic VB or have
never programmed - VB.Net is neither RAD nor simple. I know you'll look
down upon this statement, as you seem to be a very intelligent person,
easily capable of learning and excelling in any programming language that
you should choose. But, you are not the typical classic VB programmer. Put
aside your talents for a moment and look at the majority of people that used
and loved classic VB. Try and think of it in terms of why they loved it and
how VB.Net has changed that for them.

Remember, for most of them, they don't get paid to write code.....they get
paid to produce results. Classic VB was a RAD tool that frequently made
that easier. For most of them, VB.Net dosen't.
Along with these are those who wring their hands and make themselves sick
with worry in case they don't get a particular line of code right the first
time. To all those for whom the cap fits all I can say is, get of your
backsides, learn something for yourselves, be prepared to try something.
You'll be surprised just how much one can get done when one is not spending
ones efforts in waiting for someone else to do it for one or worrying if
one has got it right first time.
And, what about those who have to work for a living doing something other
than programming? Classic VB was easy to learn. It was a quick way to
increase productivity. VB.Net is just not that easy.

And, while it is certainly easy to look down your nose at them and shame
them for not learning VB.Net, remember that being a "programmer" (in the
sense that you are) was never their goal. Making their jobs easier with
minimal time and effort diverted from their main task (be it sales or
production of widgets or raising live bait) was their goal, and classic VB
fit that bill. Vb.Net does not.

To finish, I believe that Microsoft announced the timetable from ending
mainstream support for VB6 some 2 years ago, so I'm also wondering why it
has taken so long for a petition such as this to appear, or is it nothing
more than a knee-jerk reaction to the recent reminder.


I think that classic VB developers (at least the ones I know) reserved
judgement for a while to get to know the new product better. They have
played with it, "kicked the tires" and they are not impressed. VB.Net takes
much more time to master, is more difficult to distribute (I'm talking size
restrictions - like for downloads), is less secure (ildasm) and is more
complex - which means more time to code and less RAD productivity.

While, as a professional programmer, I can see your frustration with the
petition, as a long time classic VB programmer, I can also see their
frustration with the demise of VB and no comparable RAD tool to replace it.

While I know that I have spoken largely of the "part-time-programmer" here,
I am quite aware of the real programmers who have taken classic VB and
developed some rather astounding enterprise-level applications. (I have
done this at several companies myself.)

I do not wish to imply that they are not "real programmers", nor do I
dismiss their hard, and often amazing, work. Rather, I stand in awe of a
language such as classic VB that can bring together lay-programmers and
professional programmers to achieve 90% of the needs of any company.

I only wish to point out that here that the majority of the classic VB
programmers are not professionals, and the same things that make classic VB
appealing to lay-programmers also make it a favorite of those of use that do
program for a living.

Jim Hubbard

Nov 21 '05 #7

P: n/a
Herfried,

It says for me something about *those* MVP's.

Unluckily do I find it therefore very strange to see your name as the only
*hard* regular from this newsgroup in that list.

Cor
Nov 21 '05 #8

P: n/a
Thanks for the links Herfried.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ot*************@TK2MSFTNGP15.phx.gbl...
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
http://www.eweek.com/article2/0,1759,1774642,00.asp


For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #9

P: n/a
As you could see from the first line of my earlier post my questions were
rhetorical. That said I welcome your comments.

I have used VB since version 3 for developing applications for commercial
environments. I still use it today for projects where it is the right tool
for the job. Although I can read (to a certain extent) and understand a C++
source listing I have never had any need to code in that language. Prior to
being exposed to VB I was proficient in COBOL, ALGOL and PL/1.

Now, if one was to say that the transition from COBOL to VB was difficult
then I would agree wholeheartedly. Do you want some horror stories from
those days?

I firmly believe that if one has a good grasp of 'Classic' VB from version 4
(32 bit) or later then a transition to VB.NET, allowing for a smattering of
gnashing of teeth and tearing of hair, is reasonably painless. Sure there
are some new things and somethings are a little different but not to the
extent that it can be considered foriegn. I think a good analogy would be
moving from New Zealand to the USA and adapting to the difference in the
style and use the English language. As a comparison moving for
COBOL,ALGOL,PL/1 was like moving to Japan and learning that language, both
spoken and written.

I would be the first to admit that 'Classic' VB was like a pair of comfy
slippers. But, sooner or later those slippers wear out and one has to buy a
new pair and break them in.

I'm afraid that I don't differentiate between 'professional' and 'hobbyist'
programmers no matter what language they use. As far as I'm concerned, if
you're a programmer then you're a programmer. The code for adding 2 integers
together is the same regardless if you get paid for it or not. Therfore any
argument that 'hobbyists' need 'Classic' VB is spurious.

As I said earlir I still use, and will continue to use, 'Classic' VB when it
the right tool for the job. I will use VB.NET when that is the right tool
for the job and I will use C#.NET when that is the right tool for the job.
When I need something written in C++ I will get a colleague to write it for
me.

I still cannot see any need for 'Mainstream' support to continue past it's
use-by date. As I said earlier, we - as a community - have been well aware
of this date for 2 years at least.

Again, 'Classic' VB prorams are not magically going to stop working on 1
April 2005, (except those with April Fools easter eggs of course).

Stephany
"Jim Hubbard" <re***@groups.please> wrote in message
news:ts********************@giganews.com...
I can only give answers from the veiwpoint of the classic VB programmers
that I am personally familiar with. I do not speak for everyone on the
petition. My comments only relate the things I have personally
experienced
and are by no means the end-all-be-all of those wishing to continue
classic
VB.

That being said.....let's get started, shall we?

"Stephany Young" <noone@localhost> wrote in message
news:uh****************@TK2MSFTNGP09.phx.gbl...
Soapbox time!!!!!!!!

I cannot understand how, on and after 1 April 2005, I am not going to be
able to do things with VB6(SP6) that I can do on and prior to 31 March
2005. Just because 'Mainstream' support is withdrawn from that date does
not mean I won't be able to use it.


True. It only means that classic VB will not have the errors that are in
it's runtime addressed (or new security issues addressed) or the runtime
optimized for speed. The classic VB developers that I know want to extend
classic VB, as well as fix it's current problems. To them (and myself)
extending classic VB does not mean or necessitate a completely new
language
like VB.Net.

Objective 1 of the petition talks about 'Preservation of assets'. If you
have an asset then it is in place today. If it works today then it is not
magically going to stop working on 1 April. It is therefore spurious to
argue that a 'Future versions of VB6/VBA' (sic) (which, at this stage,
there won't be) will destroy your asset(s). That's like saying that no
matter what models of automobile may be developed in the future, the
manufacturer will always have to provide support for the particular model
that I drive today. In other words - 'I want to see innovation but I also
want everything the way it has always been'.


Actually, they are saying "I want to see innovation, but I don't want to
entirely re-learn programming, expose my code needlessly to others, expand
the runtime from less than 2MB to over 23MB, rewrite tons of code just to
be
able to use it in the new programming IDE and I'd like to keep programming
simple. My needs are simple. I'd like to keep my code that way."

One of the things that is hardly ever touched on is that the vast majority
of classic VB "programmers" we are talking about (MVPs not withstanding)
are
not "real programmers" (in the purely technical sense).

They are not MIS majors. They do not "write code" for a living. They
write
code to make making a living easier. The vast majority do not care to
hack
the kernel, directly manipulate memory or even have a purely object
oriented
language. They just want to be able to quickly churn out a little
application that makes their job (or their hobby) easier.

They are not interested in competing with J2EE (if they even know what it
is) or with C++ programmers. And, the very few that do want to do direct
memory manipulation, to hook the kernel, to code in an all-object-oriented
environment or develop enterprise-wide applications are more than capable
of
learning C/C++/C# to do so.

Rarely have I ever heard a classic VB developer with these aspirations
refuse to move to C++ to accomplish these goals. Quite the
contrary.....they run there.

In objective 2 it states 'This core should be enhanced and extended, and
changes should follow a documented deprecation process.' Am I the only
one who wonders how one can enhance and extend something and peprecate it
at the same time. To me 'enhance and extend' and 'deprecate' are complete
opposites.


Well......you depreciate older features while adding replacement features
that may offer more speed, flexibility or functionality. Like going
depreciating "navigate" in the IE object model and adding "navigate2".

VB.Net is not an extension of classic VB. VB.Net is C# (a JAVA copy) with
superficial classic VB (syntax) thrown in to make it look like they
actually
did something with VB besides just scrap it.

In objective 3 it states '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.' Please excuse my mistake in thinking that this is
exactly the case today and is not going to change on 1 April. Also, don't
forget about the developers who are using a mix of VB6, VB.NET and C#.NET
to provide solutions.


Since unmanaged C++ is handled by Visual Studio .Net, why not classic VB?
Since C++ is still being updated (patched), why not classic VB?

I'll tell you why......it was not a concern of the programmers at
Microsoft,
the majority of which are C++ programmers. VB was never seen as a serious
programming tool by them (not that it should be considered on the same
level
as C++ in terms of capability). Understandable. But, it should have been
taken seriously as a wildly successful Microsoft product that met the
needs
of millions of part-time-programmers worldwide and supported a real and
potential revenue stream that any company not Microsoft's size would kill
to
have.

In my personal experience I only encountered 2 'issues' in VB6 which
needed to be addressed by Microsoft and both were addressed in later
service packs. In the meantime a rather unattractive workaround was used
to acheive the desired result. While there was much gnashing of teeth at
the time, the pain soon passed. It does beg the question 'What new things
are people attempting to do with VB6 that are throwing up so many
widespread issues that mainstream support is still required?'


Mainly, extending capablities of the runtime to enable easy access
(remember
EASY is the thing the accountant/programmer values the most) to web
services
and new Windows API functionality as well as handling any security issues
that may arise with the runtime.
I am quickly coming to the view that some are trying to use VB6 to do
something that it is just not designed to do and then criticising
Microsoft when it doesn't do it.


Some do. But, they are such a small (although vocal) minority that they
really are only a bother if you listen to the minority instead of the
majority of classic VB developers.
If that is the case then I'm afraid I cannot support that sort of
behaviour.


I agree....to a point. If you want to do something today that classic VB
can't do, write a DLL or ActiveX control to accomplish it (usually in C++)
or move on to C++ for it's power.
I also wonder if some have been using mainstream support as an alternative
to 'Read The Flaming Manual' or other methods of self-help support - It
certainly appears that many use these newgroups in that manner.


Also true. But, this can be said of any developers - be they classic VB,
C,
C++, JAVA or whatever. People are lazy by default. They take the easy
way
out. Fortunately, most of use did the same thing and are happy to share
our
knowledge because we too asked "easy" questions once upon a time.

In some of the articles regarding this petition it talks about projects
not being migrated to VB.Net because it is complex. So what. An
automobile is complex compared to a bicycle but that doesn't stop
teenagers migrating from the bike to the car. Complex does not mean
difficult!!! Unfortunately there are those who equate the two words and,
in doing so, do nothing more than make things difficult for themseleves.


But, that's where everyone is missing the whole appeal of classic VB, the
power of classic VB and the continuing need of such a product as classic
VB.

Classic VB gave accountants, lawyers, students, teachers, fishermen,
electricians and just about any layperson the ability to quickly put
together the solution to a presssing problem. The problem may be
temporary
or, it may be just a prototype of a larger production application that is
needed - and, using classic VB, they could design and implement a stop-gap
measure until an enterprise solution was coded.

Complexity kills rapid application development. The more complex, the
less
rapid. Bosses loved the rapid way in which most employees could take VB
and
put together solutions to company probelms in days or hours instead of
weeks
or months for a similar C++ application.

The typical classic VB developer doesn't give a rat's behind if you fancy
him/her a programmer. S/he gets the job done, keeps the boss happy and
makes the company money. And, for them, that's what counts.
There are also those who seem incapable of doing anything unless the
entire wherewithall is handed to them on a plate.


I think this is an unfair assessment of the typical classic VB programmer.
For 99% of them, they never intended to make a living learning
programming.
They already have a job. Classic VB made it easy to enhance and simplify
their jobs. The language was easy and RAD.

For the vast majority of programmers that have only known classic VB or
have
never programmed - VB.Net is neither RAD nor simple. I know you'll look
down upon this statement, as you seem to be a very intelligent person,
easily capable of learning and excelling in any programming language that
you should choose. But, you are not the typical classic VB programmer.
Put
aside your talents for a moment and look at the majority of people that
used
and loved classic VB. Try and think of it in terms of why they loved it
and
how VB.Net has changed that for them.

Remember, for most of them, they don't get paid to write code.....they get
paid to produce results. Classic VB was a RAD tool that frequently made
that easier. For most of them, VB.Net dosen't.
Along with these are those who wring their hands and make themselves sick
with worry in case they don't get a particular line of code right the
first time. To all those for whom the cap fits all I can say is, get of
your backsides, learn something for yourselves, be prepared to try
something. You'll be surprised just how much one can get done when one is
not spending ones efforts in waiting for someone else to do it for one or
worrying if one has got it right first time.


And, what about those who have to work for a living doing something other
than programming? Classic VB was easy to learn. It was a quick way to
increase productivity. VB.Net is just not that easy.

And, while it is certainly easy to look down your nose at them and shame
them for not learning VB.Net, remember that being a "programmer" (in the
sense that you are) was never their goal. Making their jobs easier with
minimal time and effort diverted from their main task (be it sales or
production of widgets or raising live bait) was their goal, and classic VB
fit that bill. Vb.Net does not.

To finish, I believe that Microsoft announced the timetable from ending
mainstream support for VB6 some 2 years ago, so I'm also wondering why it
has taken so long for a petition such as this to appear, or is it nothing
more than a knee-jerk reaction to the recent reminder.


I think that classic VB developers (at least the ones I know) reserved
judgement for a while to get to know the new product better. They have
played with it, "kicked the tires" and they are not impressed. VB.Net
takes
much more time to master, is more difficult to distribute (I'm talking
size
restrictions - like for downloads), is less secure (ildasm) and is more
complex - which means more time to code and less RAD productivity.

While, as a professional programmer, I can see your frustration with the
petition, as a long time classic VB programmer, I can also see their
frustration with the demise of VB and no comparable RAD tool to replace
it.

While I know that I have spoken largely of the "part-time-programmer"
here,
I am quite aware of the real programmers who have taken classic VB and
developed some rather astounding enterprise-level applications. (I have
done this at several companies myself.)

I do not wish to imply that they are not "real programmers", nor do I
dismiss their hard, and often amazing, work. Rather, I stand in awe of a
language such as classic VB that can bring together lay-programmers and
professional programmers to achieve 90% of the needs of any company.

I only wish to point out that here that the majority of the classic VB
programmers are not professionals, and the same things that make classic
VB
appealing to lay-programmers also make it a favorite of those of use that
do
program for a living.

Jim Hubbard

Nov 21 '05 #10

P: n/a
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:
It says for me something about *those* MVP's.
What does it say to you? Does it say that people who would loose assets
without further support for VB6 are amateurs and idiots?
Unluckily do I find it therefore very strange to see your name as the only
*hard* regular from this newsgroup in that list.


Although I use .NET (VB.NET, C#) and like the features of VB.NET,
preservation of assets (and the other points of the petition) is very (most)
important for me. It doesn't make sense to compare features of Classic VB
with features of VB.NET, or features of COM with features of .NET, in order
to say "X is better than Y". The fact that there is a lot of Classic VB/VBA
code which will not be migrated in forseeable future for oeconomic reasons,
should make people think about Classic VB's future.

I encourage everybody here to sign the petition. Even if it doesn't affect
you, the signatures will help others to preserve their assets, and it will
bring the Classic VB community a large step closer to .NET.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #11

P: n/a
"Ray Cassick (Home)" <rc************@enterprocity.com> schrieb:
Ok, I was a stupid head here and gave the wrong link to the wrong blog
entry...

http://spaces.msn.com/members/rcassick/Blog/cns!1pXjHq-RqqMSQdLvn5n4gdnw!111.entry


"People, people, people, preservation of assets = stagnation"

I have to disagree. Preservation of assets very important, because people
can spend their money on extending existing systems and developing new
systems instead of spending the money for rewriting existing, well tested
code.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #12

P: n/a
"Stephany Young" <noone@localhost> schrieb:
I cannot understand how, on and after 1 April 2005, I am not going to be
able to do things with VB6(SP6) that I can do on and prior to 31 March
2005. Just because 'Mainstream' support is withdrawn from that date does
not mean I won't be able to use it.
Mainstream support is ending, which means that you will have to pay a fee
for fixes, event for critical ones. SP6 brings more problems than it
solves.
Objective 1 of the petition talks about 'Preservation of assets'. If you
have an asset then it is in place today. If it works today then it is not
magically going to stop working on 1 April. It is therefore spurious to
argue that a 'Future versions of VB6/VBA' (sic) (which, at this stage,
there won't be) will destroy your asset(s).
In 2008 the extended support phase will end. From this point, only
companies that have the money to conclude an agreement for further support
with Microsoft will have the chance to get updates. VB6 is used by
1-person-companies a lot, and I doubt that all of them will have the money
to conclude such agreements. Furthermore migration to .NET is often not an
option. The migration path proposed by Microsoft is not suitable in many
cases. Consequently a lof of code won't be migrated at all (/not/ because
people are too lazy to do that, but because people cannot afford the costs
to do that).
In other words - 'I want to see innovation but I also want everything the
way it has always been'.
There is no contradicition between innovation and preserving assets. Many
Microsoft applications are written in C/C++, the code is often many years
old. No need to rewrite the code. That's the best sample for preservation
of assets without delaying innovation. By being able to preserve existing
code and building systems on top of them which are using newer technologies
like .NET, a synergetic effect emerges.
In objective 2 it states 'This core should be enhanced and extended, and
changes should follow a documented deprecation process.' Am I the only one
who wonders how one can enhance and extend something and peprecate it at
the same time. To me 'enhance and extend' and 'deprecate' are complete
opposites.
You can find some samples and information on deprecation of features while
enhancing and extending software at
<URL:http://vb.mvps.org/vfred/deprecation.asp>.
In objective 3 it states '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.' Please excuse my mistake in thinking that this is exactly
the case today and is not going to change on 1 April. Also, don't forget
about the developers who are using a mix of VB6, VB.NET and C#.NET to
provide solutions.
It won't be impossible today, but it will get much harder.
mainstream support is still required?' I am quickly coming to the view
that some are trying to use VB6 to do something that it is just not
designed to do and then criticising Microsoft when it doesn't do it. If
that is the case then I'm afraid I cannot support that sort of behaviour.


Well, such thoughts don't change the status quo. People (and Microsoft)
have to accept the fact that people will loose the assets if there is no
continued support. Blaming people for the current situation doesn't help to
solve the issue.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #13

P: n/a
Herfried,
It says for me something about *those* MVP's.
What does it say to you? Does it say that people who would loose assets
without further support for VB6 are amateurs and idiots?

Why do you think I would say that, this is your iterprettation, you cannot
find one sylabile in these newsgroups where I ever have used the word
"idiot" that is not my style and absolute opposite from the way I think
about people.

My interprettation is that it is not a good attitude when you are helping
others to look back too the past and "helping" is in my opinion what one of
the first goals of a MVP should be.
Unluckily do I find it therefore very strange to see your name as the
only *hard* regular from this newsgroup in that list.


Although I use .NET (VB.NET, C#) and like the features of VB.NET,
preservation of assets (and the other points of the petition) is very
(most) important for me. It doesn't make sense to compare features of
Classic VB with features of VB.NET, or features of COM with features of
.NET, in order to say "X is better than Y". The fact that there is a lot
of Classic VB/VBA code which will not be migrated in forseeable future for
oeconomic reasons, should make people think about Classic VB's future.

I don't see the sense of this related to my message it were only two lines,
can you explain that.
I encourage everybody here to sign the petition. Even if it doesn't
affect you, the signatures will help others to preserve their assets, and
it will bring the Classic VB community a large step closer to .NET.

Again, I don't see the sense from the last sentence, can you explain that as
well.

Cor
Nov 21 '05 #14

P: n/a
It is riduculous to argue that the line of 'Classic' VB that works today
will not work in the future because 'Mainstream' support has been
discontinued.

I cannot understand this doomsaying that because 'Mainstream' support is
being discontinued, a 'bug' that is not apparent today in the 'Classic' VB
IDE/Compiler/Runtime might magically appear on or soon after 1 April 2005
and therefore any 'Classic' VB code written before that date will be
rendered void immediately on it's appearance. I see a lot of Chicken-Little
here racing off to tell the King that the sky is falling.

Support for VB4 ended long ago but there is still an awful lot of software
being written in VB4 without a lot of doomsaying.

For the record, I have yet to encounter a problem caused by SP6 for VS6, so
I am rather surprised by such a wide ranging claim as 'SP6 brings more
problems than it solves.'.

The thing that surprises me the most is that people seem to be heading off
into a state of self-righteous indignation - 'How dare Microsoft change the
support policy on something so dear to my heart' - without having a good
hard look at what it actually means.

I can only reiterate - If your VB6 program stops working next month then it
will be because of a bug in your code or some external factor; It won't be
the fault of VB6.

Stephany
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
"Stephany Young" <noone@localhost> schrieb:
I cannot understand how, on and after 1 April 2005, I am not going to be
able to do things with VB6(SP6) that I can do on and prior to 31 March
2005. Just because 'Mainstream' support is withdrawn from that date does
not mean I won't be able to use it.


Mainstream support is ending, which means that you will have to pay a fee
for fixes, event for critical ones. SP6 brings more problems than it
solves.
Objective 1 of the petition talks about 'Preservation of assets'. If you
have an asset then it is in place today. If it works today then it is not
magically going to stop working on 1 April. It is therefore spurious to
argue that a 'Future versions of VB6/VBA' (sic) (which, at this stage,
there won't be) will destroy your asset(s).


In 2008 the extended support phase will end. From this point, only
companies that have the money to conclude an agreement for further support
with Microsoft will have the chance to get updates. VB6 is used by
1-person-companies a lot, and I doubt that all of them will have the money
to conclude such agreements. Furthermore migration to .NET is often not
an option. The migration path proposed by Microsoft is not suitable in
many cases. Consequently a lof of code won't be migrated at all (/not/
because people are too lazy to do that, but because people cannot afford
the costs to do that).
In other words - 'I want to see innovation but I also want everything the
way it has always been'.


There is no contradicition between innovation and preserving assets. Many
Microsoft applications are written in C/C++, the code is often many years
old. No need to rewrite the code. That's the best sample for
preservation of assets without delaying innovation. By being able to
preserve existing code and building systems on top of them which are using
newer technologies like .NET, a synergetic effect emerges.
In objective 2 it states 'This core should be enhanced and extended, and
changes should follow a documented deprecation process.' Am I the only
one who wonders how one can enhance and extend something and peprecate it
at the same time. To me 'enhance and extend' and 'deprecate' are complete
opposites.


You can find some samples and information on deprecation of features while
enhancing and extending software at
<URL:http://vb.mvps.org/vfred/deprecation.asp>.
In objective 3 it states '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.' Please excuse my mistake in thinking that this is
exactly the case today and is not going to change on 1 April. Also, don't
forget about the developers who are using a mix of VB6, VB.NET and C#.NET
to provide solutions.


It won't be impossible today, but it will get much harder.
mainstream support is still required?' I am quickly coming to the view
that some are trying to use VB6 to do something that it is just not
designed to do and then criticising Microsoft when it doesn't do it. If
that is the case then I'm afraid I cannot support that sort of behaviour.


Well, such thoughts don't change the status quo. People (and Microsoft)
have to accept the fact that people will loose the assets if there is no
continued support. Blaming people for the current situation doesn't help
to solve the issue.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #15

P: n/a
Stephany,

"Stephany Young" <noone@localhost> schrieb:
It is riduculous to argue that the line of 'Classic' VB that works today
will not work in the future because 'Mainstream' support has been
discontinued.
Re-read my post:

"It won't be impossible today, but it will get much harder."
I cannot understand this doomsaying that because 'Mainstream' support is
being discontinued, a 'bug' that is not apparent today in the 'Classic' VB
IDE/Compiler/Runtime might magically appear on or soon after 1 April 2005
There are currently some known, unfixed bugs. For example, in conjunction
with Microsoft Windows XP Visual Styles, there are accessibility problems
because focus rectangles and underlined accelerator keys are missing.
Support for VB4 ended long ago but there is still an awful lot of software
being written in VB4 without a lot of doomsaying.
There is a viable upgrade path, at least for VB4-32 applications and large
parts of VB4-16 applications.
For the record, I have yet to encounter a problem caused by SP6 for VS6,
so I am rather surprised by such a wide ranging claim as 'SP6 brings more
problems than it solves.'.
There is a bug in the listview control of SP6. Applications will crash when
the user tries to reorder columns. For this bug, a hotfix can be ordered by
Microsoft. I know at least one other annoying bug which is currently
unfixed. Microsoft is AFAIK preparing a fix for this bug, but I fear that
this fix won't be available before free support ends. I avoid using SP6 for
these reasons.
I can only reiterate - If your VB6 program stops working next month then
it will be because of a bug in your code or some external factor; It won't
be the fault of VB6.


Currently there are known, unfixed problems with Windows XP. Is there a
guarantee that VB6 applications will run on Longhorn as smoothly as they did
on Windows 2000, for example?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #16

P: n/a
Herfried,

Funny is that my message could be understood wrong. However, you understood
directly (partially) my intention. That makes me lucky.

Maybe I had better written that I was lucky that you where the only one,
what would however given as well not my intention.

Cor
Nov 21 '05 #17

P: n/a
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:
It says for me something about *those* MVP's.
What does it say to you? Does it say that people who would loose assets
without further support for VB6 are amateurs and idiots?

Why do you think I would say that, this is your iterprettation, you cannot
find one sylabile in these newsgroups where I ever have used the word
"idiot" that is not my style and absolute opposite from the way I think
about people.


:-)
My interprettation is that it is not a good attitude when you are helping
others to look back too the past and "helping" is in my opinion what one
of the first goals of a MVP should be.


Helping customers to preserve their assets is providing help too.
Unluckily do I find it therefore very strange to see your name as the
only *hard* regular from this newsgroup in that list.


Although I use .NET (VB.NET, C#) and like the features of VB.NET,
preservation of assets (and the other points of the petition) is very
(most) important for me. It doesn't make sense to compare features of
Classic VB with features of VB.NET, or features of COM with features of
.NET, in order to say "X is better than Y". The fact that there is a lot
of Classic VB/VBA code which will not be migrated in forseeable future
for oeconomic reasons, should make people think about Classic VB's
future.

I don't see the sense of this related to my message it were only two
lines, can you explain that.
I encourage everybody here to sign the petition. Even if it doesn't
affect you, the signatures will help others to preserve their assets, and
it will bring the Classic VB community a large step closer to .NET.

Again, I don't see the sense from the last sentence, can you explain that
as well.


I wanted to make sure that you don't think that I stopped using .NET :-)
because I signed the petition.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #18

P: n/a
Herfried,
Helping customers to preserve their assets is providing help too.
In my opinion is that not the role for a MVP, that can the customer very
good themselves, a MVP has in my opinion no additional (economic) value in
that, he goes with doing that out of his role.
I wanted to make sure that you don't think that I stopped using .NET :-)
because I signed the petition.


That I am not thinking 100-Nanosecond.

I made a longer message where in I explicitly wrote that, however could not
get it in the right way to make my intentions with that clear on paper and
it could be misunderstood.

Therefore I did not sent it.

:-)

Cor
Nov 21 '05 #19

P: n/a
Stephany,

Very well said and thank you. VB.NET is clearly a superior product and I
admire Microsoft's courage to move away from the outdated VB6 framework. I
like your points that Microsoft has informed us of its plan to discontinue
support for years and that VB6 can still be used after support has ended. I
made the conversion to VB.NET as soon as it was released which proved to be
the most valuable development decision to date. All languages become
obsolete at some point and those who lack the judgment to embrace new
technologies are inevitably left behind.

Lance

Nov 21 '05 #20

P: n/a
"ljlevend2" <lj*******@nospam.nospam> schrieb:
VB.NET is clearly a superior product


That doesn't matter at all. If there is no viable upgrade path, the best
product is worthless as target of the migration. The petition is *not*
about "Is Classic VB better than VB.NET or vice versa". Please keep that
outside. It's not topic of the petition.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #21

P: n/a
Herfried, I have to ask, why would people have to spend money rewriting existing, well tested code?
Does not the saying,"if it ain't broke, don't fix it" still apply?
As has already been stated, when Microsoft's support date is reached, applications written with VB6
will not cease to function. It simply means that Microsoft will no longer offer Tech Support for VB6.
(or updates) That is nothing new. No product, programming language, or enviroment has unlimited lifetime support. Everything ,
including development tools, evolve and change. And when some of those
tools no longer fit the latest thing, they are not updated anymore. But, they still work within the context they were originally
designed for.
I remember reading TONS of posts when VB.NET was first introduced. The same things that are listed in the petition were hashed
to death then too. I came to the same conclusion as I do now, use VB6 to maintain those applications I have written with VB6
and build my newer applications with VB.NET. Or whatever it takes to get the job done and provides the best end product.
james

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message news:O0**************@TK2MSFTNGP15.phx.gbl...>
"People, people, people, preservation of assets = stagnation"

I have to disagree. Preservation of assets very important, because people can spend their money on extending existing systems
and developing new systems instead of spending the money for rewriting existing, well tested code.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #22

P: n/a
Herfried,

You should read the replies in the way as the subject is.
Nobody of us know if this is true, however that is where the reaction is
about.

I have seen MVP's in the list (including you and as I direct remember me
Billl Vaughn) who never will state the subject of this message. I have
however seen at least one MVP in this newsgroup (read exactly how I write
it) once in a thread, who could have said this. Needles to tell that I in
more than full respect (because he tells what he thinks) disagree with him.

I don't believe that the majority of the MVP's would agree with the
statement what is the subjects and I know that you are amongst those.
However in the subject is that written and in that way you should in my
opinion see the answers in this thread. Regulars in this newsgroup become
afraid when they read that.

I hope that you understand that as well.

Cor

Nov 21 '05 #23

P: n/a
"james" <jjames700ReMoVeMe at earthlink dot net> schrieb:
Herfried, I have to ask, why would people have to spend money rewriting
existing, well tested code?
Does not the saying,"if it ain't broke, don't fix it" still apply?
When VB6 applications don't run properly on Longhorn or one of the future
versions of Windows (there are currently already problems with VB6
applications running on Windows XP which don't get fixed!) a rewrite will be
necessary. When the Windows version the VB6 application runs on has
bugs/security holes which don't get fixed because support has ended for this
Windows version, one is forced to move the application to a supported
version of the operating system. But what if VB6 applications don't run
properly on this version of Windows?
As has already been stated, when Microsoft's support date is reached,
applications written with VB6
will not cease to function. It simply means that Microsoft will no longer
offer Tech Support for VB6.
That's the exact problem. If bugs don't get fixed any more, existing
applications will cease to function when being moved to newer operating
systems.
(or updates) That is nothing new. No product, programming language, or
enviroment has unlimited lifetime support.
The petition is about a better migration path /to .NET/. The petition
doesn't want to revive VB6 for use in new projects.
Everything , including development tools, evolve and change. And when
some of those
tools no longer fit the latest thing, they are not updated anymore. But,
they still work within the context they were originally designed for.
They only work if they don't contain bugs, which is unrealistic.
I remember reading TONS of posts when VB.NET was first introduced. The
same things that are listed in the petition were hashed to death then too.
I came to the same conclusion as I do now, use VB6 to maintain those
applications I have written with VB6 and build my newer applications with
VB.NET.


The aim of the proposed approach is to make the migration of existing VB6
code easier by reducing the gap between VB6 and VB.NET. VB.COM is intended
as a tool for migration to .NET (where it makes sense) and interoperability
between COM and .NET in cases where migration is not an option.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #24

P: n/a
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb
You should read the replies in the way as the subject is.
Nobody of us know if this is true, however that is where the reaction is
about.
Well, yes -- the subject is a bit misleading.
I don't believe that the majority of the MVP's would agree with the
statement what is the subjects and I know that you are amongst those.
However in the subject is that written and in that way you should in my
opinion see the answers in this thread. Regulars in this newsgroup become
afraid when they read that.


OK, I get it. I didn't put as much value on the subject, but on the
petition's text, which clearly tells the purpose of the requested VB.COM.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #25

P: n/a
This is way too stupid.

"Jim Hubbard" <re***@groups.please> wrote in message
news:O9********************@giganews.com...
http://www.eweek.com/article2/0,1759,1774642,00.asp

Nov 21 '05 #26

P: n/a
You're right about this. These dumb heads don't deserve to be MVP

"Cor Ligthert" <no************@planet.nl> wrote in message
news:OC*************@TK2MSFTNGP09.phx.gbl...
Herfried,

It says for me something about *those* MVP's.

Unluckily do I find it therefore very strange to see your name as the only
*hard* regular from this newsgroup in that list.

Cor

Nov 21 '05 #27

P: n/a
These are the kind of people my company wants to get rid off. These are the
ones always want to stick with the obsolete and don't want to change. Move
on, dumb heads. Give MS the resources to perfect VB.NET and put more needed
features.

"Ray Cassick (Home)" <rc************@enterprocity.com> wrote in message
news:eU*************@TK2MSFTNGP15.phx.gbl...
UGH!

I am a VB developer since the day it was born. I purchased my first copy
of VB version 1 from Babbage's software at the Galleria mall in September
of 1991 and have never looked back since.
I have gotten into many religious battles with other developers over the
typical arguments that VB is a real language that can be used to write
real applications by real developers.

I have gotten to know it very well, spending countless hours learning,
studying and making sure that I understood as much of the language as I
can.

All that, and even I think it should die a quite death and be replaced by
VB.NET

Support for VB Version 6 ends on 3/31/2005. Let it die with dignity and
respect.

It is a time to mourn the past and grow towards the future.

If you want to read the rest visit my blog at the link below...

http://spaces.msn.com/members/rcassick/Blog/cns!1pXjHq-RqqMSQdLvn5n4gdnw!113.entry
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ot*************@TK2MSFTNGP15.phx.gbl...
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
http://www.eweek.com/article2/0,1759,1774642,00.asp


For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>


Nov 21 '05 #28

P: n/a
Well, who are you referring to?
I do not get your point.......
BTW the whole post is here so that everyone can try to tell me the meaning
of your word past the first original post by Ray.
BTW the kind of people my company wants to get rid off are the sentencing
one, discussion is allowed and should be used to get ahead.

"news" <ne**@ms.com> ha scritto nel messaggio
news:%2****************@TK2MSFTNGP12.phx.gbl...
These are the kind of people my company wants to get rid off. These are
the ones always want to stick with the obsolete and don't want to change.
Move on, dumb heads. Give MS the resources to perfect VB.NET and put more
needed features.

"Ray Cassick (Home)" <rc************@enterprocity.com> wrote in message
news:eU*************@TK2MSFTNGP15.phx.gbl...
UGH!

I am a VB developer since the day it was born. I purchased my first copy
of VB version 1 from Babbage's software at the Galleria mall in September
of 1991 and have never looked back since.
I have gotten into many religious battles with other developers over the
typical arguments that VB is a real language that can be used to write
real applications by real developers.

I have gotten to know it very well, spending countless hours learning,
studying and making sure that I understood as much of the language as I
can.

All that, and even I think it should die a quite death and be replaced by
VB.NET

Support for VB Version 6 ends on 3/31/2005. Let it die with dignity and
respect.

It is a time to mourn the past and grow towards the future.

If you want to read the rest visit my blog at the link below...

http://spaces.msn.com/members/rcassick/Blog/cns!1pXjHq-RqqMSQdLvn5n4gdnw!113.entry
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ot*************@TK2MSFTNGP15.phx.gbl...
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
http://www.eweek.com/article2/0,1759,1774642,00.asp

For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>



Nov 21 '05 #29

P: n/a
"news" <ne**@ms.com> schrieb:
This is way too stupid.


There are missing arguments in your post...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Nov 21 '05 #30

P: n/a
"news" <ne**@ms.com> schrieb:
You're right about this. These dumb heads don't deserve to be MVP


Rules of Conduct
<URL:http://www.microsoft.com/communities/conduct/default.mspx#ECAA>

Demonstrate that you are able to learn from your mistakes.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Nov 21 '05 #31

P: n/a
Herfried, I believe I see your point and the point of the petition better. One thing though, I was under the impression that
VB2005 is supposed to have better Migration Tools for VB6 code than previous versions of VB.NET. So, at least we should be able
to move older apps to VB2005 with less difficulty than the Migration Tools that are in VB.NET 2002/2003.
I know that does not fix the existing problems with compatability with WinXP and eventually Longhorn.
But, I would think at some point in time you would reach a place where it would not make sense to just migrate older code but,
to rebuild it to work with a new OS and file system. (like WinFS.......if it ever shows up) One other thing, how long do you
think it will be after Longhorn actually delivers, that companies will start upgrading to the new OS? If the past is anything
to go by, (meaning my experience and that of others I know) it won't happen for several years after Longhorn appears.
So, unless you write applications for the general public, it is unlikely that there will be a major OS change
for quite some time to be worried about. I recently did some network repair for a small company (around 30 computers and a two
servers) and all their systems(desktops) were running Win98!! The only guy there that wrote applications for them is still
using VB5 and just now thinking about moving to VB6.
(he has it , just never uses it)
He told me that the owner of the company wasn't planning to upgrade any of his computers until he absolutely had to. And that
is not an isolated case. WindowsXP is still not being used everywhere.
Anyway, thanks for the interesting responses.
james

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message news:Oz**************@TK2MSFTNGP09.phx.gbl...
"james" <jjames700ReMoVeMe at earthlink dot net> schrieb:
Herfried, I have to ask, why would people have to spend money rewriting existing, well tested code?
Does not the saying,"if it ain't broke, don't fix it" still apply?


When VB6 applications don't run properly on Longhorn or one of the future versions of Windows (there are currently already
problems with VB6 applications running on Windows XP which don't get fixed!) a rewrite will be necessary. When the Windows
version the VB6 application runs on has bugs/security holes which don't get fixed because support has ended for this Windows
version, one is forced to move the application to a supported version of the operating system. But what if VB6 applications
don't run properly on this version of Windows?
As has already been stated, when Microsoft's support date is reached, applications written with VB6
will not cease to function. It simply means that Microsoft will no longer offer Tech Support for VB6.


That's the exact problem. If bugs don't get fixed any more, existing applications will cease to function when being moved to
newer operating systems.
(or updates) That is nothing new. No product, programming language, or enviroment has unlimited lifetime support.


The petition is about a better migration path /to .NET/. The petition doesn't want to revive VB6 for use in new projects.
Everything , including development tools, evolve and change. And when some of those
tools no longer fit the latest thing, they are not updated anymore. But, they still work within the context they were
originally designed for.


They only work if they don't contain bugs, which is unrealistic.
I remember reading TONS of posts when VB.NET was first introduced. The same things that are listed in the petition were
hashed to death then too. I came to the same conclusion as I do now, use VB6 to maintain those applications I have written
with VB6 and build my newer applications with VB.NET.


The aim of the proposed approach is to make the migration of existing VB6 code easier by reducing the gap between VB6 and
VB.NET. VB.COM is intended as a tool for migration to .NET (where it makes sense) and interoperability between COM and .NET
in cases where migration is not an option.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #32

P: n/a
You've hit the nail on the head here Herfried!
Currently there are known, unfixed problems with Windows XP. Is there a
guarantee that VB6 applications will run on Longhorn as smoothly as they
did on Windows 2000, for example?
'Oh dear! My program that ran on Windows 98 does not run on Windows XP -
Microsoft must make changes to VB6 so it does."

These are problems with Windows XP - not with VB6! This is the whole mindset
that needs to be addressed.

I can't help thinking about the age-old joke:

Patient: Doctor, it hurts when I do this.

Doctor: Well don't do that.

The whole thing comes down to my earlier point about horses for courses. XP
Visual Styles weren't even a twinkle in Bill's eye when VB6 was designed so
it is not surprising that they are not compatible and I can't see how
anybody could reasonably expect them to be so.

We, as a species, seem to have no problem in replacing most of our
technological goodies with the latest and greatest (televisions, telephones,
computers, automobiles, etc.) and yet we dig in our toes when it necessary
to replace our comfy slippers.

When it comes to:
There is a viable upgrade path, at least for VB4-32 applications and large
parts of VB4-16 applications.
I will state categorically that there is a viable upgrade path for VB6
applications to VB.NET. I have yet to port an application (and there have
been a number of large and/or complex ones) where I have had to spend more
than a day tidying up the 'bits' that didn't convert cleanly.

Finally, is case anyone is getting the wrong end of the stick, I will
restate that I use VB6 regularly where it the right tool for the job at
hand. I am in no way saying that one is 'better' than the other, but I do
not accept that my VB6 codebase is in any danger of becoming unmaintainable
because 'mainstream' suport is being discontinued.

Stephany

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ei**************@tk2msftngp13.phx.gbl... Stephany,

"Stephany Young" <noone@localhost> schrieb:
It is riduculous to argue that the line of 'Classic' VB that works today
will not work in the future because 'Mainstream' support has been
discontinued.


Re-read my post:

"It won't be impossible today, but it will get much harder."
I cannot understand this doomsaying that because 'Mainstream' support is
being discontinued, a 'bug' that is not apparent today in the 'Classic'
VB IDE/Compiler/Runtime might magically appear on or soon after 1 April
2005


There are currently some known, unfixed bugs. For example, in conjunction
with Microsoft Windows XP Visual Styles, there are accessibility problems
because focus rectangles and underlined accelerator keys are missing.
Support for VB4 ended long ago but there is still an awful lot of
software being written in VB4 without a lot of doomsaying.


There is a viable upgrade path, at least for VB4-32 applications and large
parts of VB4-16 applications.
For the record, I have yet to encounter a problem caused by SP6 for VS6,
so I am rather surprised by such a wide ranging claim as 'SP6 brings more
problems than it solves.'.


There is a bug in the listview control of SP6. Applications will crash
when the user tries to reorder columns. For this bug, a hotfix can be
ordered by Microsoft. I know at least one other annoying bug which is
currently unfixed. Microsoft is AFAIK preparing a fix for this bug, but I
fear that this fix won't be available before free support ends. I avoid
using SP6 for these reasons.
I can only reiterate - If your VB6 program stops working next month then
it will be because of a bug in your code or some external factor; It
won't be the fault of VB6.


Currently there are known, unfixed problems with Windows XP. Is there a
guarantee that VB6 applications will run on Longhorn as smoothly as they
did on Windows 2000, for example?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #33

P: n/a
"james" <jjames700ReMoVeMe at earthlink dot net> schrieb:
Herfried, I believe I see your point and the point of the petition better.
I am glad to hear that :-).
One thing though, I was under the impression that VB2005 is
supposed to have better Migration Tools for VB6 code than previous
versions of VB.NET.
That's true. The migration tool will be improved. However, don't expect
too much. Even the best migration tool won't be able to provide a smooth
transition of every project, without first manipulating the VB6 project.
Maybe the migration tools won't crash as often as they do in VS.NET
2002/2003; maybe they will be faster, and maybe they will be able to convert
more code than the tools included current versions of VS. But it's
impossible to convert an object-based or procedural project to a
semantically correct object oriented project. So, the problem cannot be
solved by migration tools only. Migration tools are one way to ease
migration, but code needs a complete redesign afterwards to follow a clear
object-oriented architecture, which is the preferrable way for .NET.
Otherwise migration doesn't make much sense because it doesn't bring any
benefits.
So, at least we should be able to move older apps to VB2005 with
less difficulty than the Migration Tools that are in VB.NET 2002/2003.
Maybe the difficulty will be reduced a bit, but the core problem remains:
VB.NET is not a technological successor of VB6 (Classic VB). While VB6 was
suitable for small companies, business applications, office applications,
etc., VB.NET has been designed as an application for enterprise development.
..NET (VB.NET/C#) are not suitable tools in many situations:

<URL:http://www.dicks-blog.com/archives/2005/03/09/support-classic-vb/#comment-9262>:

---
Were not a programming shop, but use Excel as a programming tool to get our
jobs done: taking away VBA and replacing it with .NET is sort of like taking
away a construction workers hammer and replacing it with a pneumatically
driven nuclear-powered piledriver. That all we want to do is write
relatively small snippets of code and a few loops to handle daily problems
means that for us VBA is a nicely weighted and balanced hammer: from what Ive
seen (correct me if Im wrong!), .NET is vast overkill for the relatively
small, yet fiercely complex tasks we need it for. And we gotta learn how to
do everything all over again.
---

I think the sample above elaborates the main issue of the VB6/VBA -> .NET
migration very well.
I know that does not fix the existing problems with compatability
with WinXP and eventually Longhorn.
But, I would think at some point in time you would reach a place
where it would not make sense to just migrate older code
In many situation migration doesn't bring any advantages. Imagine a
business layer that has been implemented 8 years ago and has gone through
several development cycles. This piece of code is very stable and complete,
which means that there is no need for changing a lot in the code over the
next time. A typical solution would be to use this BL as a COM component
from a newly implemented .NET presentation layer that provides an Avalon
interface. When considering this situation, there won't be a reason for
migration of the BL at all. Migration simply doesn't make sense, because
the current VB6 implementation has been tested, it's stable and there are no
knwon flaws. By converting/rewriting the existing code in a .NET
programming language, the whole process (implementation, testing, ...) will
start again.
but, to rebuild it to work with a new OS and file system. (like
WinFS.......if it ever shows up)
When you need to access the new file system, you can either use COM
interfaces (if they exist, I think it's likely that there will exist a way
to use these features in unmanaged applications) provided by the operating
system, or implement this part of the application in a .NET class library
that would live together with the existing VB.COM project inside VS :-).
One other thing, how long do you think it will be after Longhorn
actually delivers, that companies will start upgrading to the new
OS?
I don't know. Everything I could say would be speculative.
for quite some time to be worried about. I recently did some network
repair for a small company (around 30 computers and a two servers) and all
their systems(desktops) were running Win98!! The only guy there that
wrote applications for them is still using VB5 and just now thinking about
moving to VB6.
(he has it , just never uses it)


That's a typical situation which can be found in many smaller companies,
especially if they are not IT-related at all. However, newer applications
sometimes require a newer operating system, or the lack of bug fixes forces
to upgrade to a newer version of the operating system because the old one is
not supported any more.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #34

P: n/a
Stephany,

"Stephany Young" <noone@localhost> schrieb:
Currently there are known, unfixed problems with Windows XP. Is there a
guarantee that VB6 applications will run on Longhorn as smoothly as they
did on Windows 2000, for example?
'Oh dear! My program that ran on Windows 98 does not run on Windows XP -
Microsoft must make changes to VB6 so it does."

These are problems with Windows XP - not with VB6!


The problems are still caused by bugs or shortcomings in the implementation
of VB's forms. Applications written in other programming languages using
other form packages or create the forms using the Win32 calls directly don't
suffer from this problem, even if they have been compiled long time before
Windows XP has been released.
The whole thing comes down to my earlier point about horses for courses.
XP Visual Styles weren't even a twinkle in Bill's eye when VB6 was
designed so it is not surprising that they are not compatible and I can't
see how anybody could reasonably expect them to be so.
I agree that VB6 was not designed to work with Visual Styles. However, a
bug/shortcoming in the implementation of VB's forms got visible when Visual
Styles were introduced. If this was not the case, all other applications
which are older than Windows XP would suffer from the same problems. They
don't.
There is a viable upgrade path, at least for VB4-32 applications and
large parts of VB4-16 applications.


I will state categorically that there is a viable upgrade path for VB6
applications to VB.NET. I have yet to port an application (and there have
been a number of large and/or complex ones) where I have had to spend more
than a day tidying up the 'bits' that didn't convert cleanly.


Did you ever attempt to convert projects with, let's say 200 forms, 200
classes and 200 modules that depend on 'VarPtr', embedded assembler code,
subclassing, other API stuff, etc. extensively? Good luck!
Finally, is case anyone is getting the wrong end of the stick, I will
restate that I use VB6 regularly where it the right tool for the job at
hand. I am in no way saying that one is 'better' than the other, but I do
not accept that my VB6 codebase is in any danger of becoming
unmaintainable because 'mainstream' suport is being discontinued.


1.500 signatories disagree with you :-)

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #35

P: n/a
With VS 2002 or 2003, I can see the points of suppporting VB6. But with VS
2005, come on, you need to do better than that. Software releases almost
every year and I don't see any reason for holding back the obsolete
technology. Would you want to run WinNT 3.1 or WinNT 4.0 or even Windows 95,
98 in your network? You need to get another career if you don't want to
change.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ug**************@TK2MSFTNGP12.phx.gbl...
"news" <ne**@ms.com> schrieb:
This is way too stupid.


There are missing arguments in your post...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #36

P: n/a
The ones who aren't willing to change. VB6 will be gone when VS2005 is out
this summer, period. Discussion is always good but petition to keep it
alive. This is way too stupid. Why didn't they do petition to keep WinNT3.1,
4.0 , 95, 98, or Me? This is a bunch of so-called MVPs

"Spiegator" <sp*******@spiegshome.it> wrote in message
news:Xe**********************@news3.tin.it...
Well, who are you referring to?
I do not get your point.......
BTW the whole post is here so that everyone can try to tell me the meaning
of your word past the first original post by Ray.
BTW the kind of people my company wants to get rid off are the sentencing
one, discussion is allowed and should be used to get ahead.

"news" <ne**@ms.com> ha scritto nel messaggio
news:%2****************@TK2MSFTNGP12.phx.gbl...
These are the kind of people my company wants to get rid off. These are
the ones always want to stick with the obsolete and don't want to change.
Move on, dumb heads. Give MS the resources to perfect VB.NET and put more
needed features.

"Ray Cassick (Home)" <rc************@enterprocity.com> wrote in message
news:eU*************@TK2MSFTNGP15.phx.gbl...
UGH!

I am a VB developer since the day it was born. I purchased my first copy
of VB version 1 from Babbage's software at the Galleria mall in
September of 1991 and have never looked back since.
I have gotten into many religious battles with other developers over the
typical arguments that VB is a real language that can be used to write
real applications by real developers.

I have gotten to know it very well, spending countless hours learning,
studying and making sure that I understood as much of the language as I
can.

All that, and even I think it should die a quite death and be replaced
by VB.NET

Support for VB Version 6 ends on 3/31/2005. Let it die with dignity and
respect.

It is a time to mourn the past and grow towards the future.

If you want to read the rest visit my blog at the link below...

http://spaces.msn.com/members/rcassick/Blog/cns!1pXjHq-RqqMSQdLvn5n4gdnw!113.entry
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ot*************@TK2MSFTNGP15.phx.gbl...
Hi Jim,

"Jim Hubbard" <re***@groups.please> schrieb:
> http://www.eweek.com/article2/0,1759,1774642,00.asp

For those who are interested in signing the petition:

General information (press, blog articles, etc.) about the petition:

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>



Nov 21 '05 #37

P: n/a
"news" <ne**@ms.com> schrieb:
The ones who aren't willing to change. VB6 will be gone when VS2005 is out
this summer, period.


I don't see any indications for that.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #38

P: n/a
"news" <ne**@ms.com> schrieb:
With VS 2002 or 2003, I can see the points of suppporting VB6. But with VS
2005, come on, you need to do better than that. Software releases almost
every year and I don't see any reason for holding back the obsolete
technology.


It all depends on how much money and time you have that can be spent for a
migration that doesn't bring any benefit in many cases. Most smaller
companies don't have these resources to migrate. Well, these companies
actually /want/ to migrate, but without a viable upgrade path it's
practically impossible without a high risk.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #39

P: n/a

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ui**************@TK2MSFTNGP14.phx.gbl...
Stephany,
<snip...> Did you ever attempt to convert projects with, let's say 200 forms, 200
classes and 200 modules that depend on 'VarPtr', embedded assembler code,
subclassing, other API stuff, etc. extensively? Good luck!

<snip...>

I hate to tick people off here but if your projects are this complex then I
think they would BENEFIT from a re-write in VB.NET. Most of the time the
reasons for all the hard work put into complicated projects using
subclassing and fancy API stuff was because there were things that could
only be done in VB6 that way, specifically because of shortcomings in the
language.

Clearly VB.NET has provided way for you to do a lot of this stuff right out
of the box, and a lot cleaner than some of the old hacks that you had to use
in VB6.

Again, I too have a large code base of stuff in VB6, but I am not afraid of
the end of support. Yes, there will come a time when, because of changes to
the core OS, some of the tings stop running (ie: COM WILL go away some day -
no matter what any one says, it will) and there will need to be some major
changes to legacy stuff, but this is not a reason to continue to maintain a
code line for ever. Should Ford continue to make parts for the Model 'T'?
No, that would be silly, but there are still people out there that own them
and when they break what do they do then? They figure out a way to get past
the problem as best they can.

Was VB6 a ground breaking bit of developer history? YES it was, but should
it live on forever? No... Things change and we have to change with them. Is
change easy? No, but no one ever promised it was going to be. Did MS ever
promise to keep VB6 alive for ever? Nope. In fact they have actually made it
now very simple to at some point end VB all together. The growing code base
of VB.NET code at some point will be able to be run through a converter and
be moved over into C#. The entire .NET runtime is going to make it possible
to change between languages very easily from now on. Will I like it when
that happens? Nope, but I will have a far simpler time of it now because of
the framework that I would have had without it.

Nov 21 '05 #40

P: n/a
Ray,

"Ray Cassick (Home)" <rc************@enterprocity.com> schrieb:
<snip...>
Did you ever attempt to convert projects with, let's say 200 forms, 200
classes and 200 modules that depend on 'VarPtr', embedded assembler code,
subclassing, other API stuff, etc. extensively? Good luck!
<snip...>

I hate to tick people off here but if your projects are this complex then
I think they would BENEFIT from a re-write in VB.NET.


When the code is perfectly working and there are very few changes made to
the code because it is stable, a rewrite won't bring a benefit. Rewriting
code will bring back the project to a lower level in the beginning, and
increasing its quality will require testing, reviews, documentation, ... In
the end all you have got by migration are high costs but no
functional/technical improvement. Imagine that you could have spent the
time you used for migration (reimplementation, testing, QA, ...) for
implementing other features.
Most of the time the reasons for all the hard work put into complicated
projects using subclassing and fancy API stuff was because there were
things that could only be done in VB6 that way, specifically because of
shortcomings in the language.
That's not a problem when the code works. There is no need for a change.
For the user it doesn't matter /how/ feature X is implement, but it matters
that it works. Every change of something that works will hold the risk of
adding bugs.
Clearly VB.NET has provided way for you to do a lot of this stuff right
out of the box, and a lot cleaner than some of the old hacks that you had
to use in VB6.
The whole discussion is not about "Is Classic VB better than VB.NET or vice
versa". You could do pretty everything that is possible with .NET in VB6,
even if it was not supported in the unified way it is now supported by the
..NET Framework.
Again, I too have a large code base of stuff in VB6, but I am not afraid
of the end of support. Yes, there will come a time when, because of
changes to the core OS, some of the tings stop running (ie: COM WILL go
away some day - no matter what any one says, it will)
I doubt that COM will go away that fast. Windows and many other Microsoft
applications heavily rely on code. Even Microsoft doesn't have enough money
to rewrite working code only to be able to put a "Made with .NET" sticker
onto the product box. Users won't pay more for a Windows or Office package
only because it's implemented in .NET.
and there will need to be some major changes to legacy stuff, but this is
not a reason to continue to maintain a code line for ever.
The petition is asking for an upgrade path. The signatories believe that
VB.COM would help them with migration.
Should Ford continue to make parts for the Model 'T'?
A car cannot be used to generate products that depend on the existance of
the specific car model. On the other hand, a programming language is used
to create /data/ (and thus assets) that will be lost when the programming
environment (OS, libraries, development tools) are not supported any more.
Consider this text by /Microsoft/:

Visual FoxPro 8.0 -- Upgrading from Earlier Versions
<URL:http://msdn.microsoft.com/library/en-us/dv_foxhelp/html/igUpgrading_from_Earlier_Versions.asp>

---
Microsoft Visual FoxPro protects your investment in applications built with
previous versions of FoxPro. In Visual FoxPro, you can run many applications
that were written in earlier versions with little or no conversion. You can
modify and enhance applications using the Visual FoxPro language, knowing
that most extensions to the language do not affect backward compatibility.
---

Backwards compatibility and the ability to reuse written code instead of
rewriting it is a /key factor/ of a RAD system. It's crucial for the
highest possible productivity. Even if migration of a project will only
take five moths (including testing) five months have been spent that could
have been better invested by extending the existing application.
Was VB6 a ground breaking bit of developer history? YES it was, but should
it live on forever?
DOS applications were written more than 10 years ago, and they still work
for obvious reasons, even on Microsoft's newest operating systems. There
are mathematical libraries that contain FORTRAN code which is more than four
decades old. C code written 30 years ago still compiles without going
through a costly migration process.
No... Things change and we have to change with them. Is change easy? No,
but no one ever promised it was going to be. Did MS ever promise to keep
VB6 alive for ever? Nope. In fact they have actually made it now very
simple to at some point end VB all together.
Did Microsoft ever promise to keep .NET (VB.NET, C#) forever? I suppose
that in some years the same that happened to VB6/COM will happen again.

"Fool me once, shame on you
Fool me twice, shame on me!"
The growing code base of VB.NET code at some point will be able to be run
through a converter and be moved over into C#. The entire .NET runtime is
going to make it possible to change between languages very easily from now
on. Will I like it when that happens? Nope, but I will have a far simpler
time of it now because of the framework that I would have had without it.


Do you really believe that the .NET Framework will exist forever? It's
simply a technology like OLE and COM that will be outdated (and marketing
will say that it's /obsolete/) and superceeded by another technology, let's
call it ".NEW".

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #41

P: n/a
Herfried,

My first answers in this thread was based on the subject. This answer is
based on the facts which you write. All your messages in this thread are
easy to answer with one fact, which you in my opinion pass.

Every product has his lifecycle.

In economics you have the technical and economical lifetime for a product.

I don't know if you know it, however it means that even when a product has a
longer technical lifetime, it can better be stopped when its economical
lifetime has come to an end.

You saw in this thread a message for Ray about the Ford T (the best product
Ford ever had). It is (beside the railways who did not change there product)
the best example, although Ford tried to stretch the lifetime, was it almost
his disaster. Because of the fact that you wrote that it was not comparable
(what is not true in my opinion), do I tell it to you below in another way.

Without really to have any knowledge about that fact, can mean that keeping
VB6 up, will cost more with the same or even less results, than when that
money was put in the further development of VBNet.

Another bad point of this is that people who could be used in the
development of the newer and better products are busy to keep the older
products alive.

To give an example. Renewing VB6 can mean that VB2005 will be ready later
and with much less features than was planed.
:-)

Cor


Nov 21 '05 #42

P: n/a
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:
Every product has his lifecycle.

In economics you have the technical and economical lifetime for a product.

I don't know if you know it, however it means that even when a product has
a longer technical lifetime, it can better be stopped when its economical
lifetime has come to an end.
Well, but can you give me the reasons why this doesn't seem to apply to
C/C++/Visual FoxPro the same way it does to VB6? It's pretty clear that
support for VB6 will end after some time when it is superceeded by a VB7.
However, a (code-compatible) VB7 has never been released by Microsoft.
You saw in this thread a message for Ray about the Ford T (the best
product Ford ever had). It is (beside the railways who did not change
there product) the best example, although Ford tried to stretch the
lifetime, was it almost his disaster.
The whole petition sees stretching the lifetime of Classic VB as a viable
way for accelerating the migration process. The petition doesn't claim that
Microsoft should market VB.COM as a tool that should be used for developing
/new/ application. It's simply a migration/interoperability tool which is
better than any migration wizard could be.
Because of the fact that you wrote that it was not comparable (what is not
true in my opinion), do I tell it to you below in another way.
So, please explain how a car can be used to produce data that looses its
value when the car doesn't work any more.
Without really to have any knowledge about that fact, can mean that
keeping VB6 up, will cost more with the same or even less results, than
when that money was put in the further development of VBNet.
With the same arguments a VB.NET developer could say that Microsoft should
stop developing C/C++/C#, VFP and better spend the money on bringing VB.NET
forward. Microsoft has different development tools/languages for different
groups of customers. Currently, the VB6 customer group is left alone by
Microsoft.
Another bad point of this is that people who could be used in the
development of the newer and better products are busy to keep the older
products alive.
COM will be kept alive because Windows and other Microsoft produts depend on
it. It's unrealistic that all of this code will be rewritten in .NET.
That's /impoissible/ within the next 10 years, I think. Huge parts of the
..NET Framework are simply managed wrappers about COM components, VS.NET is a
mix of COM and .NET.
To give an example. Renewing VB6 can mean that VB2005 will be ready later
and with much less features than was planed.


I disagree. Does C# 2.0 cause VB 2005 to be available later with much less
features? Microsoft would have to create a separate team for VB.COM like it
did for VB.NET, C#, and C++.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #43

P: n/a
> You're right about this. These dumb heads don't deserve to be MVP

Hmm...
Nov 21 '05 #44

P: n/a
> alive. This is way too stupid. Why didn't they do petition to keep
WinNT3.1, 4.0 , 95, 98, or Me? This is a bunch of so-called MVPs


They (well somebody) did and to a certain excent succeeded witn NT 4.
Microsoft announced end of support years back but then got hit with a lot of
flak mainly because they didn't realise just how many people are still
running this 10+ year old operating system. And still do...

Rob.
Nov 21 '05 #45

P: n/a
> technology. Would you want to run WinNT 3.1 or WinNT 4.0 or even Windows
95, 98 in your network? You need to get another career if you don't want
to change.


The cold light of day truth is yes... There are some niche markets where DOS
still is used!

Rob.
Nov 21 '05 #46

P: n/a
"Stephany Young" <noone@localhost> wrote in message
news:uh****************@TK2MSFTNGP09.phx.gbl...
I cannot understand how, on and after 1 April 2005, I am not going
to be able to do things with VB6(SP6) that I can do on and prior to
31 March 2005.


And it /almost/ certainly won't be an issue.

What concerns /me/ is that, once VB "Proper" has officially fallen
by the wayside, it will no longer be taking into considerations when
Our Friends in Redmond want to make changes to /anything/.

In short, they will no longer have any reason /not/ to break it.

Consider how powerful the VB run-time library is; I can /easily/
imagine a HotFix coming along that "disables" part of it, well and
truly scr**ing things up.

"Never going to happen" I hear you way?

Only last week, I was bitten by a Service Pack for the .Net
Framework that completely scuppered my .Net web applications
for a couple of days!
And that's supported. :-{

Regards,
Phill W.
Nov 21 '05 #47

P: n/a
"Phill. W" <P.A.Ward@o-p-e-n-.-a-c-.-u-k> schrieb:
Consider how powerful the VB run-time library is; I can /easily/
imagine a HotFix coming along that "disables" part of it, well and
truly scr**ing things up.


The VB runtime library is AFAIK part of Windows several versions and thus
supported as long as the Windows version you use is supported. However,
this doesn't apply for many components used by VB applications which are not
part of Windows.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #48

P: n/a
>
But, that's where everyone is missing the whole appeal of classic VB, the
power of classic VB and the continuing need of such a product as classic VB.

Classic VB gave accountants, lawyers, students, teachers, fishermen,
electricians and just about any layperson the ability to quickly put
together the solution to a presssing problem. The problem may be temporary
or, it may be just a prototype of a larger production application that is
needed - and, using classic VB, they could design and implement a stop-gap
measure until an enterprise solution was coded.

Complexity kills rapid application development. The more complex, the less
rapid. Bosses loved the rapid way in which most employees could take VB and
put together solutions to company probelms in days or hours instead of weeks
or months for a similar C++ application.

The typical classic VB developer doesn't give a rat's behind if you fancy
him/her a programmer. S/he gets the job done, keeps the boss happy and
makes the company money. And, for them, that's what counts.
There are also those who seem incapable of doing anything unless the entire
wherewithall is handed to them on a plate.


I think this is an unfair assessment of the typical classic VB programmer.
For 99% of them, they never intended to make a living learning programming.
They already have a job. Classic VB made it easy to enhance and simplify
their jobs. The language was easy and RAD.

For the vast majority of programmers that have only known classic VB or have
never programmed - VB.Net is neither RAD nor simple. I know you'll look
down upon this statement, as you seem to be a very intelligent person,
easily capable of learning and excelling in any programming language that
you should choose. But, you are not the typical classic VB programmer. Put
aside your talents for a moment and look at the majority of people that used
and loved classic VB. Try and think of it in terms of why they loved it and
how VB.Net has changed that for them.

Remember, for most of them, they don't get paid to write code.....they get
paid to produce results. Classic VB was a RAD tool that frequently made
that easier. For most of them, VB.Net dosen't.


Well, Jim, I must say that you've described the real issue here much better
than I could have. It may be the MVP's who are speaking the loudest, but it
is for sure the "99%" of VB "part-time" programmers who are being left out in
the cold without an easy-to-learn, easy-to-use RAD tool.

VB classic's ability to hide programming complexities on the surface, yet
expose them when needed, made the tool an outstanding choice for a wide range
of users.

In VB.Net help, "What's new in the Visual Basic Language", this is the first
sentence:

"Visual Basic 2005 has many new and improved language features — such as
inheritance, interfaces, overriding, shared members, and overloading — that
make it a powerful object-oriented programming language. As a Visual Basic
developer, you can now create multithreaded, scalable applications using
explicit multithreading. Other new language features in Visual Basic 2005
include loop continuation, guaranteed resource disposal, mixed access
properties, unsigned data types, operator overloading, generic types, and
Common Language Specification (CLS) compliance."

Does this sound like a language that's geared toward RAD? Toward
PRODUCTIVITY? No! This reads like Buzz Word central! Most VBer's DON'T
CARE! We want to get the job DONE, and do it FAST! And if we did care about
these things, we would do as some of the other posters suggested - use one of
the other languages! Remember, computers are supposed to make things EASIER,
not harder!

This .NET future, as I see it, will force most businesses to outsource
simple jobs that were once the mainstay of VB. And the fact that this will
be a boon for the software industry is no coincidence - if MS's gamble pays
off, loss of VB classic and growth in VB.Net will no doubt lead to more $ in
MS pockets and an increase in the IT trend to take more money from the
profits of REAL businesses.

Moral of the story - it's small bussinesses, once again, who are being left
behind and dismissed as insignificant in Microsoft's move toward "progress".
Nov 21 '05 #49

P: n/a
I've read the petition and find it a bit ironic that there was no mention
made of the end of "mainstream" support when this is what presumably
triggered the petition in the first place. The petition instead appears to
focus on the suggestion that VB6 should be "enhanced and extended" VB6 in
order to extend its lifetime.

Herfried, if you are reading this, I have a question as you seem to be the
most vocal supporter of the petition.

In short, what is the underlying reason for the petition? Is it because VB6
currently contains bugs and it's not fair to make people pay for bug fixes?
(I would agree.) Or is it because the signers do not agree that Microsoft's
suggested migration approach (a combination of code conversion and COM
interop) is sufficient given the established VB6 code base? Or something
else?

My personal opinion is that much of the heated opposition to the petition
seems to revolve around the perception that the petition's recommended
solution, VB.COM, is overkill. If there is an outcry over the end of
mainstream support, I would think the focus of the related petition would be
to extend the support period until all of the legitiate outstanding bugs
were addressed. Instead, the reminder that mainstream support is ending has
prompted a call for Microsoft to undergo a significant development process
to create what sounds like new major version of VB6.

I think it would be fair to call for Microsoft to address known bugs in VB6,
but I don't think it is fair to require the company to enhance and extend a
product that has been stated to be obsolete for quite some time now. It's
been mentioned that creating VB.COM would be similar to how Microsoft
currently supports unmanaged C++. The implication is that they've done it
for C++, then why not VB.COM. Well, just because the principals are
similar, doesn't mean the additional costs to implement and support VB.COM
would be the proper use of Microsoft's resources. The principal of
borrowing money to buy a house is the same if I purchase one house or two;
that doesn't mean I can go out and get a second mortgage to buy another
house.

To me, the issue comes down to the decision on how Microsoft wants "spend"
its finite human resouces. Yes, they're Microsoft and they can afford quite
a bit, but at some point, you have make a decision on what's worth it and
what isn't. I happen to agree with the school of thought that enhancing VB6
in the suggested way (VB.COM) is not worth it as it would steal resources
away from further development of VS.NET. I wouldn't put it so bluntly as
others, but I can see where people would think of VB.COM as a move to
appease the camp that do not want to move forward at the expense of those
who do. To put it bluntly, I don't want my new VB.NET features delayed by
even a month even if it means that the lifetime of VB6 will be extended by a
year.

I understand that the reality is that there is still a substantial amount of
VB6 code out there that needs to be supported. I just think that what
Microsoft owes the VB6 licensees is system that is bug-free that runs on the
operating systems that were around at the time. I emphatically disagree
with the notion that Microsoft owes the licensees a system that will be
"enhanced and extended" to be campatible with future version of the Windows.

To give a specific example, if a company has developed a VB6 application
which runs on its standard OS build of Windows 98, I would consider it
perfectly reasonable for that company not to upgrade to Windows XP because
of incompatabilities between their app and WinXP. What is unreasonable, in
my opinion, is for that company to demand that Microsoft continuously add
new features to VB6 and to test it under every new version of Windows that
comes out ad infinitum.

- Mitchell S. Honnert
"Jim Hubbard" <re***@groups.please> wrote in message
news:O9********************@giganews.com...
http://www.eweek.com/article2/0,1759,1774642,00.asp

Nov 21 '05 #50

182 Replies

This discussion thread is closed

Replies have been disabled for this discussion.