Microsoft MVPs Say They Want Old VB Back

[Herfried K. Wagner [MVP]]

Ray,

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

 

[Cor Ligthert]

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

 

[Herfried K. Wagner [MVP]]

Cor,

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

 

[Rob Nicholson]

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.

 

[Rob Nicholson]

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

Hmm...

 

[Rob Nicholson]

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.

 

[Phill. W]

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.

 

[Herfried K. Wagner [MVP]]

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.

 

[Guest]

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.


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

 

[Mitchell S. Honnert]

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

 

[Herfried K. Wagner [MVP]]

Mitchell,

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.

We didn't (publically) set an end date for the petition, so maybe it will
continue to be open for signing after March 31. In addition to that the
petition's topic is not limited to VB6, it includes VBA too. The end of
"mainstream" support was not the main force behind starting the petition.
Issues mentioned in the petition are not new and have been discussed for
some years now.

The petition instead appears to focus on the suggestion that VB6
should be "enhanced and extended" VB6 in order to extend its lifetime.

That's true. What we are currently facing is a difference in the upgrade
approach proposed by Microsoft and the path chosen by companies and people
who are using VB6. This implies that the proposed upgrade path is not
suitable and doesn't work in reality. VB.COM would enable people using VB6
to (1) migrate faster by reducing the gap between VB6 and VB.NET, and to (2)
strongly improve interoperability of VB6 code with VB.NET code, and to (3)
get support for some more years.

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

The answer is yes. But it's not the main reason for the petition. More
information on the support issue can be found here:

<URL:http://msmvps.com/bill/archive/2005/03/13/38347.aspx>

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?

That's a very important reason for the petition. I believe that the
currently suggested migration path is not sufficient. It's still far too
expensive to migrate code, and although the technical infrastructure exists,
tools that make interop easier are missing. VB.COM is the answer to this
issue. By providing the possibility to manage and edit VB.COM projects
side-by-side with .NET projects within the VS IDE, the migration process
would be accelerated. Additionally, by providing further support people
would not be forced to rewrite existing code (which is always a costly
process) and can it without applying changes. The IDE will handle all the
interop for the developer, for example, by automatically generating .NET
wrappers around already existing COM classes.

Or something else?

Yes... Microsoft treats VB differently from its other programming tools.
It treats the VB community in an other way than the VC++, Visual FoxPro,
Visual J++, ... communities by discontinuing a product without providing a
product that evolutionarily extends the existing product without introducing
unneccessary changes which break existing code. VB.NET is a powerful
programming language, but it's not a successor of VB6.

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.

VB6 SP6 has shown that Microsoft isn't really interested in supporting the
use of VB6 any more. VB6 opens more issues than it closes and introduces
several problems (see Bill McCarthy's article I referenced above). VB.COM
is only a suggestion, not a recommendation or a demand. Our experience with
other VB6 customers shows us that VB.COM would have the potential to solve
all the discussed problems.

For me, extending the support period for some more years and providing real
support (a /working/ SP7 that addresses several known bugs) is the /minimum/
I expect Microsoft to do. However, even an SP7 would not address the
migration issue.

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.

The message of the petition to Microsoft should be that there needs to be a
change in how Microsoft treats its VB6 customers. It's up to Microsoft to
choose how to address the customer's problems and wishes. The petition
contains a proposed way that represents the best solution we could think of,
which is, giving VB a /future/.

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.

Reality differes from Microsoft's plan and should cause Microsoft to rethink
the way it has chosen to go with VB6.

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.

What would you say if a C# developer wants Microsoft to stop further
development of VB.NET and VFP in order to spend the money on C# development?
I feel sorry, but that's a very egoistic point of view that doesn't take
account of the needs and situation of other developers :-(.

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.

As I said in an earlier post: Imagine Microsoft discontinuing C# and
spending all the money on VB.NET development instead. Great idea? There
could be many more features in VB 2005 than there will be in VB 2005 with
Microsoft spending/"wasting" money on further development of C#. VB.COM
would have its own customers like C#, VB.NET, and VFP. Microsoft might have
a separate VB.COM team with separate resources.

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.

By discontinuing support for future operating systems, customers' assets
will be lost.

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.

This only works as long as the machine doesn't access the internet because
when the Windows version you are relying on isn't supported (which means
that bugs don't get fixed) any more, an upgrade will be mandatory.

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.

Microsoft actually does that for VC++ and Visual FoxPro. There is no reason
not to do that for Visual Basic too.

 

[Buster]

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

Exactly.

And those small businesses made up the majority of the classic Visual Basic
army.

This will go down in history as one of the greatest mistakes by a large
business ever.

The problem is that Microsoft did not (and still does not) know their
user-base. Instead of listening to the end-users - not Microsoft employees,
not Microsoft salesmen, managers or even coders. In fact, (not to denegrate
my friends like Herfried) they should not have even listened to their MVPs.

By listening to professional programmers (or pretending to anyway) they gave
the classic Visual Basic community a whole host of new features that 99% of
them neither asked for nor desired. In doing so, they killed classic Visual
Basic and abandoned the legions of lay-programmers that made Visual Basic
such a popular language to begin with.

This is a blunder on the scale of Windows Me.

To make a mistake (even a large one) is no shame. Every person (including
me) and every business (including mine) does so at some time or other. The
true measure of an organization is whether they can realize that they made a
mistake and whether they make strides to rectify it and retain their
customer base and standing in the IT community.

Let's hope Microsoft gets it right, for our sakes and theirs.

Jim Hubbard

(P.S. Although the MVPs have taken the lead in calling for the continuation
of classic Visual Basic - and I sincerely offer my thanks to each one of
them for that - take a look at the signatures being amassed at
http://classicvb.org/petition/signatories.asp?lang=en and you will see that
the vast majority of the almost 2,000 signatories are not MVPs. *They* are
Microsoft's customer base. Let's hope Microsoft listens.)

 

[Jim Hubbard]

Sorry about the "Buster" moniker above. I was teaching my sister how to use
the newsgroups and didn;t restore my settings.

Jim Hubbard

 

[Jim Hubbard]

From an older article in 2002 -
http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,73332,00.html
---------------------------------------
"Reworking the Code
While the cost of scrapping an existing application and building a new one
is substantial, so is just reworking the old code. The cost of a simple
rewrite of a client/server application in VB 6 to VB .Net, without adding
new features, can run as high as 60% of the original cost of the
application, according to Gartner Inc. in Stamford, Conn.

That's because the changes in VB .Net are far more than skin deep. All .Net
programming languages use a common runtime framework. As a result, simple
Visual Basic operations, such as reading and writing a file, must be
reworked to use C++-like semantics. "

....

"But moving legacy programs to VB .Net isn't trivial, Lazar acknowledges. VB
..Net includes an upgrade wizard, but it's intended to be used as a learning
tool; it's not designed to automatically find and convert incompatible code.
"

---------------------------------------

Sad thing is that not much (if anything) has changed.

60% to convert...... Lot's of small businesses just can't afford to spend
60% of all their classic Visual Basic development to move to VB.Net.

If we are going to be force-fed Fred.Net, we need a better migration tool.

Hell, we just need a migration tool - period. For most business projects,
VB.Net only shows you why it can't upgrade - not how, and certainly it
doens't assist in the migration of a great deal of code.

Jim Hubbard

 

[Jim Hubbard]

Microsoft wasn't just ignoring a small group of programmers when it trashed
classic Visual Basic......

As this May 2003 article
(http://www.builderau.com.au/program/windows/0,39024644,20274274,00.htm)
shows, 52% of all programmers surveyed in North America (600 programmers
were surveyed) used Visual Basic for some development.

Wow! It must be nice to be able to ignore 52% of your programmers and know
there's not a damned thing they can do about it.

Well, we could move to Linux. If we have to learn a whole new language, why
not go ahead and cut the cord completely and learn a new OS while we're at
it?

At least we'd have more control over our future than we have now..... We
could even develop our own RAD tool for Linux and never have to worry about
it being taken away.

Why didn't anyone in the Linux world take advantage of this opportunity?
52% of Windows programmers having the best RAD tool ever taken away and over
4,000,000 Visual Basic developers (using classic VB as the primary
development tool) completely abandoned! WOW! What an opportunity!!

Well, we can dream......

Jim Hubbard

 

[Jim Hubbard]

One more comment......

Bill Gates is a great businessman. I mean it. He has built the largest
company in the world - and it wasn't just dumb luck.

The greatest lesson that Microsoft tools have taught me (beginning with
Windows 1.0) is that users eat up "dumbed down" products.

He dumbed down the DOS command line using Windows and made a freakin'
fortune! Visual Basic came along and dumbed down programming for the masses
and it became the WORLD's most popular programming language.

That's right, more classic Visual Basic programmers than any other langauge
in the world. Nothing else even came close (including C++ and JAVA).

So, why would Microsoft go in the exact opposite direction and increase the
complexity of the most popular langauge in the world in such a massive way
that it cannot be called a true extention of Visual Basic 6?

Let's see.....you have more programmers than any other language in the
world, and you *abandon* them? NOT cater to them - if even only as a means
to feed Microsoft's ever widening wallet.

If this isn't the craziest thing I have ever seen........

To quote my blog.....

"Microsoft has become like the TV and movie "stars" that we are all so
familiar with today. They live so far removed from everyday reality that it
begins to affect their ability to think rationally. They've surrounded
themselves with people whose very livelyhood depends on being liked enough
to be kept around and given a paycheck for agreeing that the star's every
idea is a stoke of genius.

Then they wind up on the front pages of the tabloids....and we all laugh at
the people we worshipped yesterday.

It's true. Microsoft developers have created their very own Neverland."

Jim Hubbard

 

[Rob Nicholson]

By discontinuing support for future operating systems, customers' assets

will be lost.

Playing devil's advocate, this could be a good thing in the long run. In
idle moments, I sometimes dwell on whether there isn't a better way of doing
all of this. Usually when I'm battling with web apps. I'm sure I'm not
alone. But sometimes you have to make a big leap to get there and not small
incremental jumps.

Of course I appreciate the cost of the leap - I work for a small business
after all.

Rob.

 

[Herfried K. Wagner [MVP]]

Jim,

To quote my blog.....

What's the URL of your blog?

 

[Paul Clement]

¤ > The petition instead appears to focus on the suggestion that VB6
¤ > should be "enhanced and extended" VB6 in order to extend its lifetime.
¤
¤ That's true. What we are currently facing is a difference in the upgrade
¤ approach proposed by Microsoft and the path chosen by companies and people
¤ who are using VB6. This implies that the proposed upgrade path is not
¤ suitable and doesn't work in reality. VB.COM would enable people using VB6
¤ to (1) migrate faster by reducing the gap between VB6 and VB.NET, and to (2)
¤ strongly improve interoperability of VB6 code with VB.NET code, and to (3)
¤ get support for some more years.
¤

The only problem is that no one has actually identified how code migration from VB 6.0 to VB.NET
will actually be improved. Both versions of Visual Basic function in distinctly separate
environments that are architecturally different. Any IDE interop mechanism between the environments
would be limited to classes and components, and would not be available to stand alone executables.

The bottom line is that you would still ultimately need to rewrite your code. The petition, and
resulting conversations that have ensued, are suggesting a solution that would require enormous
Microsoft resources, a significant amount of time to implement (several years) with an end result
being a postponement of the inevitable.

The better solution is to have Microsoft continue to work on and improve the code migration process
from VB 6.0 to VB.NET, instead of attempting to marry two versions of a product that are almost
eight years apart in development and architecture.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Mitchell S. Honnert]

Herfried, thank you for your thoughtful reply. I have some further replies,
but first a bit of background on why I (and perhaps others who are critical
of this petition) have the opinions I do. I started programming in BASIC on
a Commodore VIC-20, moved through to QuickBasic, and then onto most versions
of Visual Basic. In short, I have been working with BASIC in one form or
another for a long time and consider it an old friend in many ways. But...I
became so frustrated with the hodgepodge style evolution of VB that I
switched over to Delphi when it became available. The clean OO design that
creating a brand new language allowed appealed to me greatly. But when
VB.NET came out, I immediately switched back to my "old friend". To me,
VB.NET was better than Delphi because it not only had true OO, but also had
all of the familiar syntax and keywords to which I had been accustomed for
so long. I was firmly in the camp of people who applauded Microsoft for the
revolutionary change from VB6 to VB.NET, even if it meant introducing all of
the compatibility issues between the two languages.

Since switching to VB.NET, I've been fortunate enough (for the most part)
not to work at clients or companies that required me to use VB6. (The one
case where I did have to go back to using VB6 was agonizing.) From my
perspective, I had moved onto the next level and didn't want to look back.
I may have been lucky in this way, but it sounds like you are forced to deal
on a regular basis with clients who are still using VB6. I believe that one
of your main points is that Microsoft is not properly accounting for the
high number of programmers who, like you, have to maintain or enhance
systems written in VB6. I can sympathize with that situation, but can you
see that, from the standpoint of someone who doesn't have to use VB6 on a
daily basis, a petition which suggests that Microsoft should spend its
resources on a major upgrade to VB6 is overkill?

If I've read your previous comments correctly, it sounds like the major
issues you have with Microsoft's stance on VB6 is that there won't be any
further service packs to fix existing problems (some of which were
introduced by SP6) and that the COM interop does not work as well as it
should. Personally, I think it is wrong of Microsoft to leave VB6 in a
state where there are known bugs. I'm not familiar with the bugs you allude
to in SP6, but I wouldn't doubt that there still bugs in VB6 even after all
this time. As for the COM interop, I don't have much need to use this
feature, so I'll take your word that it could be improved.

The point is, I believe far more people would be sympathetic to the call for
better support of VB6 if it were focused on the creation of future service
packs and improved .NET COM interop instead of a major overhaul to VB6 that
is implied by the notion of VB.COM. (I know you mentioned that VB.COM was
only a possible solution, but it features so prominently in the petition,
that one can only assume it is more than a suggestion.) No change as big as
what would be required by VB.COM exists in a vacuum. The costs would be
very large. It just doesn't seem like the problems described warrant the
suggested remedy. Yes, Microsoft supports other languages in VS.NET and no,
I wouldn't want VB.NET to be eliminated to that MS could focus on C#, but
this doesn't avoid the simple fact that adding another language to VS.NET
would incur huge additional costs for Microsoft.

In my opinion, the natural reaction of the programmer who uses VB.NET
exclusively to a call for VB.COM is "Why waste the effort enhancing the
previous generation's development tool when we already have the next
generation tool?" Perhaps I am reading too much into the wording of the
petition, but when I see the terms "enhance" and "extend" featured so
prominently, I don't think of service packs and free support calls. What
comes to mind for me is adding new features and capabilities to the
language. I think much of the negative feedback regarding the petition is
that it appears to be calling for a major upgrade to VB6, whereas most
people (especially those who no longer use VB6) would not think that
Microsoft is responsible in any way to enhance and extend such an old
product.

The key distinction for me is the difference between the terms "extend" and
"enhance" and the term "fix". In spite of Microsoft's encouragement, the
reality is that there is still a substantial segment of the market out there
that use VB6. But even so, I don't think this means that Microsoft is
obligated to extend and enhance VB6. In my opinion, Microsoft is
responsible to fix known issues with current functionality, not add new
functionality. Again, this may not be the intent of the petition, but based
on my reading of it and some of the other reactions here and in blogs, it
certainly seems like it is.

- Mitchell S. Honnert