Microsoft MVPs Say They Want Old VB Back

[Herfried K. Wagner [MVP]]

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.

 

[james]

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

 

[Cor Ligthert]

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

 

[Herfried K. Wagner [MVP]]

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.

 

[Herfried K. Wagner [MVP]]

Cor,

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.

 

[news]

This is way too stupid.

 

[news]

You're right about this. These dumb heads don't deserve to be MVP

 

[news]

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.

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

 

[Spiegator]

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.

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.

 

[Herfried K. Wagner [MVP]]

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.

 

[Herfried K. Wagner [MVP]]

This is way too stupid.

There are missing arguments in your post...

 

[james]

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

 

[Stephany Young]

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]]

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>:

---
We’re 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 worker’s 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 I’ve
seen (correct me if I’m 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.

 

[Herfried K. Wagner [MVP]]

Stephany,

'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.

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

 

[news]

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.

 

[news]

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

 

[Herfried K. Wagner [MVP]]

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.

 

[Herfried K. Wagner [MVP]]

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.

 

[Ray Cassick \(Home\)]

Stephany,

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.