http://www.eweek.com/article2/0,1759,1774642,00.asp

Hi Jim,

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/

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

Show quoteHide quote

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.

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

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.

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

It won't be impossible today, but it will get much harder.

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.

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


Show quoteHide quote

Stephany,

Re-read my post:

"It won't be impossible today, but it will get much harder."

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.

There is a viable upgrade path, at least for VB4-32 applications and large
parts of VB4-16 applications.

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.

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?

This is way too stupid.

Show quoteHide quote

There are missing arguments in your post...

You've hit the nail on the head here Herfried!

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

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

Show quoteHide quote

Stephany,

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.

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.

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!

1.500 signatories disagree with you :-)

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.


Show quoteHide quote

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


Show quoteHide quote

Mitchell,

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.

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 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>
<URL:http://msmvps.com/bill/archive/2005/03/13/38319.aspx>

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.

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.

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.

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

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

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

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.

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

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.

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

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

Show quoteHide quote

Mitchell,

Just to make one thing clear:  I think that VB.NET is a very powerful
programming language and I am happy that this programming language exists.
VB.NET and Classic VB are my favourite programming languages.  I don't think
that the compatibility issues are really a problem as long as Microsoft
doesn't tell VB6 users that VB.NET is VB6's successor, which is definitely
not true.  <URL:http://vb.mvps.org/tips/stability.asp> describes pretty well
what language stabilty means and why it is broken with the VB6 -> VB.NET
transition.

That's all your personal preference.  Other people had and still have other
preferences.

I can understand this point of view; however, I am expecting solidarity in
the whole developer community.  There is no guarantee that the same incident
that happed for VB6 (a product used and requested by a large number of
customers is discontinued without providing a viable upgrade path) will
happen again for VB.NET in a few years.  That's my fear and that's why I
think that it's important that people sign the petition.  The higher the
number of signatories the more noticeable is the sign shown to Microsoft
that the approach taken for VB6 (and which will likely be taken for VB.NET
too) is not accepted by the customers.

On the one hand, SP6 introduces a few new bugs that didn't exist in previous
versions/SPs of Visual Basic.  On the other hand, there are certain "bugs"
or non-compliant behavior when running VB6 applications on Windows XP and
other newer versions of Windows.  There is the runtime update problem too,
which Bill McCarthy describes (I posted the link in one of the previous
posts).

What you are ignoring is that there is a large number of
companies/developers who would pay for the product and support included with
this product.  Microsoft could easily make a survey to check how many
licenses of VS including VB.COM they could sell.

Well, the whole discussion is not about adding another J# that rarely
anybody uses.  It's about adding a language which is strongly requested by a
large number of customers, a language that already existed and that was a
bestseller.

Nobody is requesting VB.COM to be available for free.  I am confident that
many of the people who signed the petition would even buy a full VS license
if VS includes VB.COM.  This would mean that Microsoft could sell some
millions of additional VS licenses.

Surveys are showing that there are currently more people using Classic VB
than VB.NET.  Wouldn't the logical impliciation be removing VB.NET and
enhancing and extending VB6?  I don't like any of the two ways of
discontinuing either Classic VB or VB.NET.  Both programming languages are
requested and used by a large number of constomers, so they should be kept
alive.

Well, "successor" is quite subjective.  To me, it would be more accurate to
call VB.NET the successor to VB6 than the next "version" of Visual Basic.
"Successor" has the vague kind of meaning that could include the
next-in-line, even if it is a radical and revolutionary departure from its
predecessor.  "Version" to me would imply language stability as described at
the link you provided.  But that's all just terminology; what's important
are the underlying ideas.

Incidentally, I haven't run across any instances where Microsoft stated that
there was "language stability" between VB6 and VB.NET.  Because of the beta
period for .NET and from all that I read at the time, I knew full well that
VB.NET was such a drastic change from VB6 that it was all but a new
language, albeit one with similar syntax and keywords.  I get the impression
that you would have preferred that there was language stability between VB6
to VB.NET, but I don't ever recall this being Microsoft's position.

Hmmm.  Are you saying that you don't have a personal preference between
using VB.NET or VB6?  Perhaps this warrants another thread, but I find it
inconceivable that an experienced programmer would actually choose, all
other things being equal, to use VB6 instead of VB.NET.

You know, to be consistent with my opinion, I would say that if the
situation you describe happens, I would be OK with it.  For example, let's
say that in a couple of years or so, Microsoft comes out with a
revolutionary new programming language that uses a BASIC-like syntax.
(Let's hope that if this happens, they'd come up with a better, less
confusion-causing name than .NET.)  Who knows, perhaps there will be some
new style of programming that would require this kind of radical break from
the past.  If I tried this new language out and thought its improvements
were worth the break in language stability, I'd switch over to it, make it
my personal language-of-choice, and seek out employers that used it.  If I
didn't, I'd stick with VB.NET and hope for the best.

The point is that I think it is perfectly natural for programming languages
to go through a long phase of incremental change (which can support language
stability) followed by an instance of revolutionary change (which obviously
would not support language stability.)  I think this is what happened with
VB6 and VB.NET and I personally think that it is inevitable that it will
happen to VB.NET.  In my personal opinion, programming languages
periodically need to make changes that exist on such a fundamental level
that language stability cannot be maintained.  The alternative is
stagnation.  Perhaps not a complete stagnation, but the kind that would only
allow for incremental changes rather than the revolutionary changes that are
required to implement revolutionary programming techniques.

Perhaps you are correct that people would be willing to pay for it.  Again,
maybe it's my literal reading of the petition, but I certainly didn't get
the impression that it was asking for a new product for which people would
have to pay.  I wonder how the reaction to the petition would change if
people knew they had to pay for VB.COM.

No, it certainly is not the logical implication.  One cannot just look at
the existing usage numbers to justify future development and support
efforts.  Not to get too far off the subject, but a good example is
religion.  There are billions of people who believe in a set of mutually
exclusive religions.  By the definition of each respective holy books, only
one of these religions can be right, which means that the remaining billions
are wrong.  So, sheer numbers doesn't make something right.  If this logic
were applied to VB.NET, then it would never have been developed because 100%
of the developers at the time were using VB6.  You have to, of course, look
at the relative merits of each individual language, not merely how many
people are currently using the language.

In my opinion, VB6 is an awful language.  In the name of language stability,
it was patched and kludged together in such a way that it ended up as a heap
of chicken wire, duct tape, and band-aids.  With VB.NET, Microsoft was able
to make a clean break with the past and incorporate object oriented design
principles into the language at a fundamental level.  I think the reason
that there are more people using VB6 than VB.NET has more to do with the
inertia of an existing system than any distinct merit of the language
itself.

In general I would agree with you, but I think the difference in opinion is
based on the definition of "kept alive".  To me, keeping VB6 alive means VB6
should be kept on life support i.e. we should not "pull the plug".
Specifically, I think this means that Microsoft owes it to the licensees of
VB6 to ensure that it is bug free on the generation of Windows that was out
at the time.  It necessarily follows that Microsoft should allow those
companies to run those legacy versions of Windows without being strong-armed
into upgrading to a version which might break the VB6 app.  But once again,
I don't think that it's Microsoft's responsibility to extend and enhance VB6
in the way described by the petition.

On a more practical note, I think there is a very significant reason, based
not on technology, but instead on human nature, that VB.COM will never get
developed.  Simply put, what Microsoft employee would want to work on
VB.COM?  Not to sound too harsh, but I think any developer at Microsoft
would consider it an insult to be assigned to a project to enhance a product
as old as VB6.  It my experience, the best and brightest programmers would
naturally gravitate towards newer products like VS.NET.

I don't believe that Microsoft is ignoring the number of people who are
currently using VB6.  I just happen to think that Microsoft taking more than
just current developers into account in the decision on where to spend its
finite resources.  Specifically, I think that on one side of the scale are
all of the current VB6 developers and on the other side of the scale are all
of the current VB.NET developers and every single *future* VB.NET developer.
Sure, VB6 developers may outnumber existing VB.NET developers, but current
programmers will pale in comparison to all of the new developers who will
come along and, in all likelihood, choose VB.NET over VB6.

Therein lies the heart of this debate.  I think this petition is not
forward-thinking.  It admits a shackling to the past.  Microsoft approach is
properly accounting for the overwhelming number of future developers, albeit
at the expense of current developers.  I know you are looking for solidarity
among the VB community, but I honestly don't think you are going to get it.
I believe there are just too many people that would view the kind of effort
the petition implies, even if it were paid for, as a waste of effort.  I
would agree.

- Mitchell S. Honnert

Show quoteHide quote

Mitchell,

Show quoteHide quoteI am not a native English speaker, so please excuse my occasional
inappropriate choice of words.

VB.NET is VB 7.0, which means that it is a newer version of Visual Basic.
However, that's not the case.  A name like B# version 1.0 would have been
more appropriate and would have caused much less confusion.

A version of real VB7 exists that was demonstrated at the BASTA conference
in Munich, Germany in 1999.  However, this version has never been published.
So, Microsoft originally wanted to release a "real" VB7 which is a newer
version of the Visual Basic programming language.  Later, development of
this version was stopped and instead VB.NET was marketed as the "new Visual
Basic".

Definitely no.  Do you have a preference between Assembler and Visual Basic
..NET?  Both serve different purposes and are used by different people.
That's the reason why /you/ don't agree with the VB.COM position.  You seem
to work in a different area and thus don't see where Classic VB is still
more appropriate than VB.NET.  Nevertheless, that's not the point of the
petition.  The petition is not about "is VB.NET better than Classic VB or
vice versa".

There are situations without the possibility to choose, for example, when
maintaining existing code.  I would prefer VB.NET in most cases for
developing /new/ applications, but my choice is limited to VB6 when editing
VB6 code.  A rewrite of the code is not an option.

Well, I would not be OK with it.  The evolutionary approach chosen in the
past which tried to /extend/ the existing programming language and
/deprecate/ language features that don't make sense any more in the new
environment (for example, direct memory access can be deprecated when the
new platform the program runs on doesn't support that) has one big
advantage:  Almost full preservation of assets, no need for a rewrite.  This
approach has been chosen by Microsoft up to VB6, and for almost all (I don't
know an exception) other programming languages.  In contrast to that there
is the revolutionry approach that typically causes a lost of assets for
those who own code written in the "artificially obsoleted" programming
language.  Notice that the evolutionary approach typically doesn't slow down
the introduction of new technology.  Instead, by providing the direct
ability to reuse existing code with at max. a few changes resources can be
spent on extending the existing code instead of rewriting it.  I already
included the quote of Gartner about migration cost in one of my posts to
this thread.

Innovative new features can be introduced into most programming languages
without actually breaking existing code.  For example, in VB.NET 'Wend' was
changed to 'End While', which doesn't have any rational reason.  Changes
like this one only break existing code and make migration harder without
adding any benefits to the new programming language.  There can be many more
samples found in the VB6 -> VB.NET transition, like changing 'Integer' ->
'Short', etc.

Please give me some samples where existing programming languages were
revolutionarily changed and then marketed as simply "the next version" of
the existing programming language.

I feel sorry, but when asking for a new version of a product, it's obvious
that this new version would not be available for free.

VB.NET now exists for about four years.  I doubt that the number of users
will increase more quickly than it did in the last four years.  The number
of VB6 users decreased, but only for the reason that Microsoft never
released a "real" VB7.

That's not the case.  VB6 is simply an object-based programming language,
you cannot expect a full set of built-in OO features in it, for example.

What's more clean with 'Wend' -> 'End While'?
What's more clean with 'Integer' being a 32-bit data type in VB.NET?
....

There have been so many changes that would not have been necessary and don't
make the language cleaner.

It's late in the night in Austria, that's why I'll not answer the rest of
your test...

BTW:  There is an updated version of the petition's FAQ available:

Classic VB Petition FAQ
<URLhttp://classicvb.org/petition/faq.asp>

Herfried, thanks again for your reply.  This deep into the thread, it's
probably just me and you reading the posts, nonetheless I've enjoyed the
exchange of ideas.  Anyway...

I'm not sure what you mean here.  In point of fact, VB.NET is *not* VB 7.0.
Your argument would make more sense if they called it VB 7.0, which would
imply language stability.  But Microsoft instead chose to give it an name
altogether outside of the standard version number convention.  I personally
think that VB.NET is an extremely silly name, but the fact remains that the
".NET" implies a dramatic departure from its predecessor.

I certainly do have a preference.  Without a doubt, it's VB.NET.  But just
because I have a personal preference, doesn't mean that I'm not aware of
business situations where other languages (assembler, C++, VB6, etc) would
be appropriate.  I understand perfectly the situation where a company has
invested heavily VB6 development, it is not financially viable to convert
over to VB.NET.  But personally, I do my best to avoid those environments
and, if given the choice (for example, if programming an application for my
own benefit), I would choose VB.NET.

I guess we just disagree here. When I heard that VB.NET was going to be
built from the ground up as a new language, my reaction was "Hallelujah!
It's about time!"  I was so sick of all of the little inconsistencies that
had crept into the language over time during its evolutionary enhancement,
that I thought a complete overhaul was long overdue.  I'm not trying to get
into which is better, VB6 or VB.NET, but instead pointing out the reason why
VB.NET is so much better relates to the revolutionary changes in VB.NET.
Microsoft was able to start fresh and design a clean, consistent system that
without all of the baggage from VB6.  Were some of the keyword changes
frivolous? Sure.  But for the most part, I believe the actual improvements
that this approach allowed far outweigh the disadvantage of breaking
language stability.

I'm looking at these improvements from the standpoint of the new programmer,
not the experienced VB6 programmer.  When teaching a new developer how to
program in VB6, I remember having to spend half the time teaching them the
rule and the other time teaching them all of the exceptions to the rule or
the "gotchas" to watch out for.  It was maddening.  But because VB.NET
started fresh, the architecture was so much simpler, that in my opinion,
it's much easier to teach a new programmer VB.NET than VB6.  To a seasoned
VB6 programmer, who is already accustomed to all of the quirks in VB6,
eliminating the quirks seems like a waste of effort.  But from the
perspective of all of the new programmers entering the field, why should
they have to learn all of these weird little peculiarities?  To me, this
single aspect makes the leap to VB.NET worth all of the headaches.

I did not intend to imply the situation you describe above exists, so I do
not have an example.  The example I *do* have, which does relate to what I
was trying to convey, is of course the very topics of this discussion: VB6
and VB.NET.  Specifically, I believe that VB6 had evolved to a point where
it could not be improved in the way that I felt was needed using the
standard evolutionary means.

I've read the FAQ and find much of the logic specious.  I should try and
post my rebuttals in a new thread.  Thanks for the link though.

- Mitchell S. Honnert


Show quoteHide quote

Show quote Hide quote The problem with this is that if they had wanted to make the break
completely, there are many other changes that the could have made (and
probably wanted to make) such as the cast of True to 1 instead of -1 (which
was in Beta 1 and changed for Beta 2.)

If you're going to have a new language, you might as well make it thoroughly
new. And that, more or less, is what they did with C#.

But with VB.NET, they neither made it new enough to be as good as it might
be as a new language nor made it compatible enough to be a reasonable
upgrade and bring the VB6 codebase to .NET. So they were landed with the
worst of all possible worlds. We did try and warn them.

LOL.  It's very ironic that you mention this particular issue, because I
used it as an example in an essay I wrote about how, at the time of the
VS.NET betas, I believed MS was pandering too much to the VB6 developer in
designing VB.NET.  My basic contention was that they were breaking language
stability anyway, so why not go all of the way and eliminate these kinds of
legacy inconsistencies.

(If you're interested, the essay is here
http://home.fuse.net/honnert/imho/SunkCosts.htm.)

But even though I felt I had a "technologically righteous" justification for
my opinion, I begrudgingly admitted to myself that I understood the
reasoning that Microsoft was using.  Personally, I think they knew they
could only stretch the rubber band so far before it broke.  Specifically,
they were already making so many other changes, that they would occasionaly
"throw the dog a bone" by caving on one of these issue in an attempt to
appease the crowd who wanted VB.NET to be VB7.  Microsoft was playing the
political game of trying to make everyone happy.

Another good example (which I used as well) was the change in the
shortcircuiting behavior of the "And" and "Or" operators during the betas.
Instead of putting its foot down and saying, "No, it is wrong to expect that
all of the parts of an expression be evaluated", Microsoft caved and added
the silly OrElse and AndAlso operators.  In fact, this is a perfect example
of why I believe that a fundamental change was required to truly bring a
revolutionary change to Visual Basic, one that broke language stability.  In
my opinion, short-circuiting of logical operators should be the natural
behavior.  But that would have meant that people would not have been able to
port VB6 code straight into VB.NET code; there would have been no way to
tell if you were using VB6's lack of short-circuiting logic.  So, they made
VB.NET more complex than it had to be in order to appease VB6 programmers.

While I admit to disagreeing with some of Microsoft's decisions about how to
best redesign Visual Basic, I wouldn't go so far as to say it's the worst of
all possible worlds.  I believe that no matter what Microsoft did, they
would have had thousdands, if not millions of people who disagreed.  I
personally think they gave too much consideration to the existing (at the
time) langauge, but in general, they did a very good job with the redesign.

- Mitchell S. Honnert


Show quoteHide quote

Hi Mitchell

I think you may need to realise a few things

1. You seem to be making the mistake of assuming that because C/C++ does
things in a particular way, it is necessarily right for all other languages
to do the same.

2. The way Basic has handled this feature has been perfectly consistent
since long before Windows existed. What you were arguing against was not a
"legacy inconsistency" but simply a lack of consistency with the way C++ and
Java programmers are used to doing things. The way this works makes perfect
sense if you realise that the VB boolean operators are bitwise. Take a look
here for a fuller treatment of the issue. http://vb.mvps.org/tips/truth.asp

3. Microsoft made a big mistake in thinking that doing a token reversal of
two or three changes would remove the underlying problems of
incompatibility. The Beta 1 rollbacks were clearly necessary if VB.NET were
going to be made a practical upgrade path, but it was always clear that they
were far from sufficient. Microsoft was told this at the time, but took no
notice, with predictably dire results.

4. It clearly *was* Microsoft's original intention to make VB.NET compatible
with VB6. But something got lost along the way. The following was the
Statement of principles which was included in the Beta 1 documentation for
VB.NET

"The design of Visual Basic 7.0 encompasses the following principles, in
relative order of importance:

- Visual Basic 7.0 is recognizable as the descendent of previous versions of
Visual Basic, and an existing Visual Basic programmer will feel an immediate
familiarity with the language.

- Visual Basic 7.0 syntax and semantics are simple, straightforward and easy
to understand. The language avoids features that cause unexpected behavior.

- Visual Basic 7.0 allows developers to take advantage of the major features
of the NGWS Frameworks and Runtime and is consistent with the its
conventions.

- Visual Basic 7.0 is reasonably "upgradeable" from previous versions of
Visual Basic. That is, it is possible in a significant number of cases to
take existing Visual Basic code and, with a well-defined set of
transformations, produce a working Visual Basic 7.0 program.

- Because the NGWS Runtime is explicitly designed to support multiple
computer languages, Visual Basic 7.0 is designed to work well in a
multi-language environment.

- Visual Basic 7.0 is as compatible with previous versions of Visual Basic
as possible. Whenever practical, Visual Basic 7.0 has the same syntax, the
same semantics and the same runtime behavior as its predecessors."

I think that all of this documentation has been removed from the final
product documentation and from the MSDN website.


But whether or not Microsoft intended breaking compatibility, the fact
remains that they achieved it, leaving many substantial VB6 projects with no
practical migration path to updated development tools. The petitioners are
looking to reverse the damage that has been caused.

By the way, don't assume that means that the petitioners would like to see
VB.NET as it currently stands discontinued. We would not wish you to have to
go through the same experience. But if Microsoft thinks that changing
platform means that they can and should change languages, then that is what
will happen to you when .NET is superseded. If you want to avoid this, I
would suggest you sign the petition.

Hello Jonathan.  You bring up some interesting points.  Please see below for
comments.

I'm not sure how you got this from what I've stated.  I've done some C/C++
coding in my day, but it's been so little that I don't think it's skewed my
concept of what I think is "right" for all programming languages.

I find it ironic that you are emphasizing the concept of consistency so
much, whereas the whole point I was trying to get across (in both my post
and my original essay) is that there are more important issues than being
consistent with the previous generation.  Up to VB.NET, True always
evaluated to -1.  Does that make it right just because "that's the way we've
always done it around here"?  Independent of whether certain languages
handle a certain feature, I believe there are objective rights and wrongs in
language design.  Specifically, in deciding on how a particular language
feature should function, one should take into account what has been done in
the past, but not let it dictate the design.  I'll have to read the article
at that link you provided more carefully, but I still believe that True
evaluating to -1 is wrong.  The point is academic given the proper use of
Booleans, but I still found it extremely inconsistent that one of the most
fundamental principles in the field of computing -- that 1 is True and 0 is
False -- should be not be reflected in VB6.  I understand you have a very
nice explanation about the underlying technical reason that True is -1 in
VB6, but to me it smacks too much of letting the internal operations of the
computer dictate language design.  It's the tail wagging the dog.

This is my personal opinion, but what I think "got lost along the way" was
the albatross around Microsoft's neck of backwards compatibility and
language stability.  Not to get too melodramatic here, but what I think
happened is that during the development of .NET, Microsoft broke the chains
that had enslaved it to the collective kludge known as Visual Basic 6.  I
don't doubt for a minute that Microsoft started out the design of VS.NET
with the statement of principles you listed.  But somewhere along the way,
someone must have said something like, "You know what?  We can't truly take
VB to the next level unless we scrap all of the quirky, eccentric,
inconsistent stuff in VB6.  We have to start fresh."


It's undisputed that Microsoft broke backward compatibility and language
stability between VB6 and VB.NET.  What is at the heart of our disagreement
is whether the costs ("no practical migration path", etc) outweigh the
benefits (the logic, uniformity, and consistency of the .NET framework).  On
that note, I don't think that Microsoft owes the licensees of VB6 a
"practical migration path to updated development tools".  I've mentioned
this in this thread before, but I believe Microsoft does owe VB6 licensees
is bug fixes and the continued ability to develop and run their applications
on the generation of operating systems that was around during its standard
support period.  In other words, I think Microsoft owes it to VB6 users to
fix broken functionality, not add new functionality or development tools.
To me this is the natural cost of the occasional revolutionary change in
development tools.

I certainly don't think that.  On the other, I do believe that the
implementation of VB.COM would require Microsoft to spend so much time and
money to enhance the *previous* generation of VB, that there would be a
substantially reduced ability to enhance the *current* generation of VB.  In
other words, the petitioners may not be stating that they want to
discontinue improving VB.NET, but the implication of what they are
suggesting would be a radical reduction in the continued improvement of
VB.NET.  That is why I will not sign the petition in its current state, nor
do I believe anyone else should.

- Mitchell S. Honnert



We would not wish you to have to
Show quoteHide quote

OK, that might not be where you are coming from, but I assure you it is
where the Visual Studio development team (C++ coders, every one of them)
were coming from.

Show quoteHide quoteThis depends on whether you are creating a new language or extending an
existing one.

If you are creating a new language, sure, jettison everything which gets in
the way of a perfect clean consistent design that can then be made to last
as long as possible.

But if you are creating an extension to an existing language, the only
possible purpose in doing so (rather than making a new language) is to
enable existing projects to make use of the new features you are offering.
As a purely practical necessity, this requires that existing projects can be
made to run in the new version with minimal rewriting. In turn, this
restricts the areas in which you can innovate.

If we accept for the sake of argument that Microsoft's original intention
was to produce an upgrade, then whether is is right or wrong that True casts
to -1 is not the right question. The right question to ask is whether
changing it will break an unreasoable number of existing projects which have
depended on the -1 up to now, given that it has been a documented part of
the language definition all these years. If the answer to this us "yes",
then the change should not be made.


Show quoteHide quoteBut they did start fresh - they wrote C#. I do rather wonder how they came
to the view that what they really, really needed was *two* new languages and
no upgrade path for their most popular language.

Show quoteHide quoteThey owe it to their customers - all their customers, and not just VB6
coders - not to damage the value of their data. By providing no practical
upgrade path, Microsoft has declared that VB6 code (an important and
valuable kind of data) is regarded by them as being disposable and not
having lasting value. Whose data will be next?

Be careful what you ask for! If Microsoft cotinues to develop VB.NET in the
same way it moved from VB6, it won't be all that long before they decide to
modernise the lnmaguage all over again. And you may then find yourself
wishing they had spent a little less resource on it....

I genuinely hope that you never find yourself on the other side of that
equation and spoken to in the same vein by supporters of Microsoft's Next
Big Idea, and who have not made the investment in VB.NET that you are
currently making, or perhaps that your employers are making by paying you to
write VB.NET code.

Jonathan, thanks for your reply.  I have some responses, but I have to start
with your last comment first, as I believe it gets to the very heart of our
difference of opinion, shedding a different light on the other points.

You appear as if you not only don't want there to be another major change to
VB, but are also assuming that other people don't want that change either.
The thing is, I *want* there to be another radical change to VB!  I *want*
to go through all of the turmoil again of transferring to a revolutionary
new programming language based on VB.  Why?  For the simple reason that,
based on the historical precedence of the change from VB6 to VB.NET, the
only time that Microsoft makes these kinds of revolutionary changes to the
programming language is when there is a need to implement a radicaly
different programming approach.  And if Microsoft were coming out with a new
version of VB that broke backward compatability and language stability, it
would mean that there must be some new programming style that would make
VB.NET as much better than VB.NET was over VB6.  I would welcome this kind
of improvement, not dread it.  I'd be the first one to download the demo,
the first one to convert my own programs over to the new language, and (if I
found it to be truly a worthy successor, like I did VB.NET), the first one
to pester my employer to use it for new development.  I don't expect that
object oriented design is going to be replaced any time soon, but if it
were, I'd be right there, ready to give it a shot.

But that's presicely what Microsoft did with VB.NET, create a new language.
That's why they didn't call it VB7, but something different, something that
would imply a dramatic departure from the current version.  Regardless of
what the intent was at the start of development on what would become VB.NET,
it's indisputable that Microsoft ended up with the goal of creating a new
language.

The problem with the term "extension" (and "successor" and "next version",
for that matter) is that it's subjective and open to interpretation.
Regardless of what term you use, you would have to agree that the very point
of contention here is that Microsoft treated the development of VB.NET as if
it were a new language.  We appear to be coming from the problem at
different angles.  I view VB.NET as the successful creation of a completely
new language, albeit one that borrowed a lot from VB6, whereas you appear to
be viewing VB.NET as the failure of the creation of an extension of VB6.  Is
this a fair summary?

The above point illistrates perfectly the affect of the different viewpoint
mentioned above.  I do not accept that the *final* intention of Microsoft
was to produce an upgrade.  (Their original intent is irrelevant given the
end result of what VB.NET became.)  So, in my opinion, whether True casts
to -1 is the best design *is* the right question to ask regardless of how
this will affect legacy code.

I don't think I'm telling you anything you don't already know, but just for
the record, the reason that Microsoft created a .NET version of Visual Basic
was for the simple reason to appeal to Visual Basic developers.  Microsoft
was creating a radically new language and, from a sociological standpoint,
they understood the best approach to gaining adoption was to appeal to
current VB6 developers.  No mystery there.  I, for one, am glad that I
wasn't forced to use C# to get the benefits of VS.NET.  If given the choice
between C# and VB6, I would choose C# in a second, but fortunatelly for me,
Microsoft gave me VB.NET, a completely new language from one standpoint, but
one that was immediatly familiar given the similarity in syntax and
keywords.  (Man, I hate C#'s squigly braces!)

Microsoft is not damaging their "data"; *time* is.  It is unreasonable to
expect that Microsoft continue to give, in perpetuity, the same level of
support to previous generations of product as they do to their current
generation.

This is the point where we have some agreement.  I personally think that
Microsoft made the right decision to make VB.NET into a radical departure
from VB6, even if it meant that simple, automated porting of VB6 code to
VB.NET code was impractical.  Having said this, I would agree that Microsoft
owes orphaned products (which, in effect, VB6 is at this point) more than
just what a previous generation product would get.  Where our disagreement
comes is in exactly what this level of support means.  As I've stated
before, I believe it means making sure that the product can continue to work
as it did at the time of its "primary support period".   In VB6's case, I
think one of the major issues would be to ensure that COM interop really
worked as advertised and to not punish or prevent companies from using
versions of Windows that are known to be compatible with VB6.  But, the
major effort that would be required to create VB.COM?  Sorry, but no.

On a more practical note, if I were in the unfortunate position of being a
VB6 developer these day, I might publicly agree with my employer about how
awful it was the Microsoft was pulling mainstream support, but internally,
I'd be jumping for joy.  In fact, I'd want Microsoft to announce that the
next service pack of Windows would instantly break all versions of VB
previous to VB.NET.  In other words, anything that forced my employer's hand
to make the switch from VB6 to VB.NET would be welcome, even if it was the
"hand of God" in the form of some Microsoft edict.  I will fully admit that
this makes no sense from the employer's standpoint that has to pay the
programmers to make the switch, but if I were living the workday hell of
having to program VB6 once I'd "seen the light" and experienced how much
better it is to program in VB.NET, I wouldn't care how much it cost my
employer.

- Mitchell S. Honnert


Show quoteHide quote

Show quote Hide quote That's great if you want to do the same work over & over again, especially
if you can con somebody into paying for it. Good luck to you! But I think
you may find that those who have long-lasting commercial applications take a
somewhat different view, particularly if they are business oweners trying to
make an honest profit rather than programmers wanting to play with the
latest toys.

It depends entirely on what Microsoft's intentions were. Based on their own
documentation in the beta, it appears that their intention was to make a new
version of VB, essentially the same language but on a new platform. Judging
by that stated intention, we you would agree that they failed.

Whether they succeeded in creating a great new language I will leave to you
to decide. Also, whether or not VB.NET is great, it would be hypocritical of
me to hope that its syntax is changed to break your code, and so I genuinely
hope that you and other VB.NET coders have the opportunity to continue
developing in VB.NET even after the .NET platform is superseded. I'm not all
that sanguine about the chances of it happening through.

Its a strange thing, but quite a lot of Visual Basic developers have
developed Visual Basic code which they are responsble for. Would you like to
explain to me how a radical new language which is incompatible with their
Visual Basic code to is going to appeal to these Visual Basic developers?
I've talked to a great many of them, and this appeal escapes them as
thoroughly as it has escaped me.


It would seem to me that the best approach to gaining adoption would have
been to make a language that could actually be used to extend existing
Visual Basic projects. 4 years after VB.NET was introduced, published
surveys indicate that VB6 is still in more widespread use than VB.NET.

Its strange then that C++ has been most carefully managed such that
Microsoft's own codebase has been protected, to the extent that Microsoft's
C++ compilers have edged very slowly towards full standards compliance. How
would you explain that?

Show quoteHide quoteWell, it might cost your employer and you your job. I think I have you
pegged. You just like playing with new toys, and don't like the day-to-day
responsibility of managing and ongoing project. Well, each to his own, and
if you can make a living at it, good luck to you.

How does making a new programming language available require anyone to do
work "over & over"?  I've stated that I believe that Microsoft owes it to
any orphaned product the ability to continue to run on that generation's
version of Windows.  My reasoning for this is so that business owners don't
*have* to move to the next generation if they don't want to.  If a business
owner wants to stick with what they have, then that's their business.  They
have the right to do so and Microsoft owes them just enough support to keep
them going.  But if they want the best of the latest generation -- what you
refer to as "toys" -- then and only then would they have to expend
additional work.

I honestly don't see why you are focusing so much on what Microsoft's
original intentions were.  Microsoft obviously changed their mind after they
published that documentation in the beta.  You appear to be judging them
based on statements that were pulled off of their web site.  As much as you
may wish that Microsoft would have adhered to the principles listed, the
fact is that they changed their mind.  Microsoft did not fail to create VB7;
they succeeded in creating VB.NET.

It's quite simple really.  If one is accustomed to the general syntax and
keywords of a language, then the transition to the next revolutionary step
in programming languages will be much easier if its language is similar to
your preferred language.  So, VB6 developers were greatly benefited by
VB.NET in so much as they could use the new capabilities and OO features of
..NET without having to learn an entirely new language.  I see it as a
natural thing that a programming language goes through a revolutionary
change after a period of evolutionary change.  Using the previous generation
of language as the foundation from the new makes this periodic transition
easier.

But the intent wasn't to get users to adopt to the just any new version of
Visual Basic.  The main goal was not increased adoption, but increased
adoption of a substantially better product over an entrenched product.

This statistic is meaningless.  Of course VB6 is more widespread than
VB.NET.  I won't even bother to ask if "widespread" is defined by distinct
applications, by users, or by companies, because it doesn't matter.  It's
only obvious that the end-version of a language set that has been around for
years will have more of an established base than a relative newcomer.

To be honest, I don't know enough about C++ to make a judgment.  Perhaps you
can tell me: was C++ so much ahead of its time that it didn't *need* the
radical makeover that VB6 received?  Did this dramatic change already happen
from C to C++?  I honestly don't know.

True enough.  For me personally, however, I have had the luck/luxury of
being able to work at companies that don't require me to work with VB6 any
more.  Don't get me wrong.  At the time, it was a great tool.  But now that
something so much its superior is around, I personally don't want anything
to do with VB6.  I realize, though, that there are plenty of people who
still like working with VB6.  I'm glad they are there, else there'd be more
of a chance that'd I'd have to deal with VB6.

Jonathan, you don't have to insult me.  We obviously have our differences of
opinion, but this kind of attack is uncalled for.  I happen to rather enjoy
the responsibility of managing professional projects on a day-to-day basis.
In fact, as you may have guessed from my dedication to this thread, I'm
rather passionate about technology and the advancement thereof.  I will
admit to a desire to use new technology to its fullest benefit, but then
again, I perfectly understand the conflict between ideology and economics.
In other words, I may personally abhor working with VB6 now, but I
understand the economic constraints which prevents companies from switching
to VB.NET.

- Mitchell S. Honnert


Show quoteHide quote

¤ > Its strange then that C++ has been most carefully managed such that
¤ > Microsoft's own codebase has been protected, to the extent that
¤ > Microsoft's C++ compilers have edged very slowly towards full standards
¤ > compliance. How would you explain that?
¤ To be honest, I don't know enough about C++ to make a judgment.  Perhaps you
¤ can tell me: was C++ so much ahead of its time that it didn't *need* the
¤ radical makeover that VB6 received?  Did this dramatic change already happen
¤ from C to C++?  I honestly don't know.

C++ just had fewer proprietary implementations. But, I think if you talked to some C++ programmers
they would tell you that they have suffered some grief in the past with respect to upgrades. In
addition, C++ *does* have some compatibility issues when using the managed extensions. It isn't the
perfect world that those who don't use the language would lead you to believe, even though they
probably fair much better than Classic Visual Basic developers.


Paul
~~~~
Microsoft MVP (Visual Basic)

Thanks for the extra info, Paul.  As I've said, I'm no expert in C++, but
what you say makes sense on an intuitive level.  To me, it seems only
natural that a language that operates on a level closer to the internal
functioning of the computer (C++) would have to change less with a
change/upgrade of the OS. Visual Basic of course hides much of the internal
workings of the computer, so of course it's more susceptible to OS changes.

I'm guessing that there might be a parallel in the C++ world and the VB
world when a new version of Windows is released.  Specifically that a VB6
developer might have to port their application to VB.NET or find some other
workaround in order for their application to run on the new OS, whereas the
C++ developer would have to rewrite or update one of their customized
libraries in order to account for the changes in the OS.  In both cases,
there could be a significant amount of work, but because it's at the
programming language level with VB6 (instead of the custom library level),
the necessary rework is perceived as more of the "fault" of Microsoft.
Maybe I'm reading too much into the information in your post, but the
scenario I describe sounds plausible.

- Mitchell S. Honnert


Show quoteHide quote

On Tue, 22 Mar 2005 15:31:47 -0500, "Mitchell S. Honnert"
<news@honnert~R~E~M~O~V~E~.com> wrote:

Show quoteHide quoteC++ had an external controlling body setting standards and was a
designed language, VB for all its strengths was a language that had
grown organically and had gone down a number of dead ends.

Perhaps more importantly, Anders Heijlsberg who heads up the .Net
project wanted all four of the mainstream .net languages (c#, C++, VB
and Delphi) to have a basically the same functionality so the common
core would be the same and only the syntax varied.  Also Anders was a
founder of Borland and designer of their Pascal and Delphi languages,
so he didn't have any allegience to VB.

VB had to change the most to acheive this end, for example it has gone
from a language (8K Basic) with no typing and global scope, to a
language with strong typing and very tight scope rules.

Doug Taylor

Show quoteHide quote

Show quote Hide quote That's not really good enough. There is no reason to assume that algorithms
and business logic all have a life lasting only as long as the generation of
Windows in which they were first written. If they have a life exceeding
that, then there is a need to recompile the source code onto a new platform.
If that involves a rewrite, then that is an unnecessary duplication of
effort. if that has to happen every time Microsoft brings out a new
platform, then the work has to be done "again and again".

It's one thing to extend a project to make use of the latest platform
features. It is quite another to have to rewrite it altogether in order to
get it to run at all on a new platform even before any new features are
added. But this is what a language change means. Those who are responsible
for paying programmers or for making a business case for moving to a new
platform may take a much dimmer view of this than you do.

But algorithms and business logic don't exist in a vacuum; they of course
exist in the context of a programming language.  And there is *every* reason
to believe that a programming language, like any application, has a finite
lifetime.  We can discuss where the cutoff point is, but surely you would
agree that Microsoft shouldn't have to support VB6 on *every* future version
of Windows.  I've granted that ideologically, a company may want to move to
VB.NET, but economically may not be able to do so.  Can't you see the
parallel that Microsoft may ideologically want to fully support all previous
programming languages, but has to make an economic decision at some point to
reduce the full level of support?  If they didn't do this, they'd be crushed
under the weight of supporting so many legacy languages that they'd have no
time for any development on new languages.

I believe that your counter to this argument would be that there are so many
more companies who are still using VB6 at this point than expected, that
Microsoft should not only stop, but reverse this "phase out" process.  I
would disagree.  As long as Microsoft doesn't use some kind of strong-arm
licensing scheme to force a company to move to the latest OS (this may be a
different thread altogether), then it doesn't matter how many people are
currently using VB6.  It's ultimately up to them if they want to use it on
the supported OS or gamble on a new and not fully-supported OS.

But a company doesn't *have* to move to the new platform just because
Microsoft makes it available.  It's their choice whether to move to that new
platform.  And one of the major aspects of that decision is whether that
company has mission critical applications written in a language not
supported by the new platform.  You may view this as a Hobson's choice, but
I do not.  If the company wants to move to each new generation of OS, then
they might have to do some work "again and again" to move to the next
generation of application development tool.  But it's their choice.  This
seems obvious and natural to me.

- Mitchell S. Honnert


Show quoteHide quote

If a reasonable migration path were available, there would be no need to.
The migration path is perfectly do-able. It would (for instance) be a
perfectly feasible project to do a language using most of the VB6 syntax
that compiled to .NET itself. It such a product could still have access to
everything in the framework. There really is ver little about the framework
that would necessitate a difference in behavior - the change in object
management from deterministic finalization to garbage collection is about
the only significant issue.

I would accept that, Microsoft does not have an obligation to provide
eternal support for little-used languages. But Visual Basic hardly came into
that category! It was far and away Microsoft's most popular language
product, with estimates of the number of users being between 3 million and 6
million, depending on who you listened to. It was no more aged than the
C/C++ language grouping, and that is being preserved most carefully.

Your key point here seems to be "it doesn't matter how many people are
currently using VB6". In practical terms, that it not true. It is in
Microsoft's own best interest to get the large number of developers still
using VB6 to move to current tools, if only because Microsoft can make money
from selling those tools. If Microsoft had made a better job of the
migration, the petition would never have happened and we wouldn't be having
this conversation.

Show quoteHide quoteI agree that it's their choice. It's also obvious to me that it is in
Microsoft's interest to encourage people to move up. And on this particular
occasion, they have made a hash of it, and raised to the cost of moving on
in a way that is significantly against their own best interest. I hope they
learn from the experience. I hope they now do the right thing and go back
and do what can be done to fix the mess.

And if pigs had wings, they could fly.  At this point in the conversation,
the question isn't *if* there is a "reasonable migration path" as you define
it, but *should* there be one as you define it.  Sure, if VB.COM existed
right now, many people would find it easier to eventually convert over to
VB.NET.  But the question at hand is if Microsoft *should*, either from a
moral or financial standpoint, make VB.COM available

Just because a project is "do-able" and "feasible", doesn't mean that it's
economically justifiable.  Sure, if Microsoft chose to do so, it could
develop VB.COM.  But from the very fact that they haven't done so by this
point clearly indicates that Microsoft doesn't believe that such a project
would be the proper use of its resources.  They *could* develop VB.COM, they
just don't think it's worth it.

I somehow think that the implementation of VB.COM would be more than just a
matter of overcoming a couple of insignificant behavior differences between
VB6 and .NET.  In fact, much of my opposition to VB.COM arises not so much
out of a sense that Microsoft couldn't do more to support VB6 (they could
and *should*), but from the idea that this approach is overkill.  Because
the creation of VB.COM would be such a major undertaking, it would steal
resources away from enhancing the current generation of VB development tool,
VB.NET.

I noticed you added the "little-used" qualifier in there.  Therein lies the
key to our differences on this particular aspect of the argument.  I believe
Microsoft's obligation to support a product, even an application development
tool, is a function purely of time, whereas you apparently believe it should
be a function of usage.

Obviously Microsoft doesn't agree with you; they think it *is* true.

If we're discussing what's in Microsoft's best interest (and no longer about
what they *should* do), then I would still have to disagree.  I think that
in Microsoft's mind, they don't have to do much of anything more than what
they've already done and people will eventually switch over to and buy
VS.NET.  I don't pretend to know that Microsoft's internal motivation is,
but if I had to guess, I'd say that the whole idea of VB.COM would be viewed
as a bad investment.  The expression "Why buy the cow when you can get the
milk for free" comes to mind.  In other words, why would Microsoft undertake
a huge project to help people to convert from VB6 to VB.NET when they'll be
forced to do so anyway?  From a purely capitalistic viewpoint, not paying
for a huge VB.COM project is in Microsoft's best interest.

- Mitchell S. Honnert


Show quoteHide quote

On Tue, 22 Mar 2005 14:07:11 -0500, "Mitchell S. Honnert"
<news@honnert~R~E~M~O~V~E~.com> wrote:

Show quoteHide quoteI've been following this debate at a distance, surely the whole thing
comes down to economics. Microsoft are not selling any more new VB 6
licenses so there is a zero revenue stream.  They have in place a new
tool with a migration path (perhaps not ideal, but it exists)
generating a revenue stream.

A few users want a new migration path, lets do some costing, guesses
only
1) development of new tool 2,000,000
2) testing and QA 500,000
3) marketing 100,000
4) profit 400,000 to make it easy

so we have a total aimed minimum return of 3,000,000
I've seen figures of around 1000 people are demanding this so the
minimum price after corporate discounts needs to be 3,000 are people
going to pay this for a migration tool, probably not enough so the
project doesn't go ahead.

Doug Taylor.

Show quote Hide quote Even assuming your figures for the cost of doing it, I suspect that your
figures for the number of people to whom it could be marketed are way on the
low side.

Already, nearly 4000 people have signed the petition.

According to a Visual Expert survey recently
(http://www.visual-expert.com/us/info/survey_vb_2004_results.htm) 80% of VB
developers are still using VB5 or VB6 as their primary version of VB.

Microsoft used to claim that there were 6 million VB developers. Let's
assume for the purpose discussion that 5 million of those are hobbyists who
Microsoft has decided to there is no money to be made out of, and
concentrate on the million writing significant code. According to the
survey, 80% of them are still on VB6, or roughly 800,000 serious developers.
Maybe half of them would pay for and make use of a decent upgrading tool if
one was available. That means there is a market of about 400,000. So, to get
a total return of 3,000,000, Microsoft needs a sales margin per user of
$7.50. I think that is achievable. And in doing so, they would increase the
adoption of modern platforms among the developers and their customers.
Win-win.

Jonathan,

So accoording too your message have 0.007% of the users signed it

Than is that not really much in my opinion.

When it is that important that they want to pay for it, it would have been
probably much more.

Just my thought,

Cor

Cor,

Many VB6 developers are not aware of the petition.  They do their work 10
hours the day, go home, eat something, watch a football match on TV, and
then go to bed.  In other words, they are not active in communities and thus
have not yet heard about the petition.  In addition to that, there are very
few VB6-oriented magazines available in the meantime, so VB6 developers are
"disconnected" from each other.

Herfried,

I know your point of view, however as most developers I like it when
somebody shows "facts" to debate that with other "facts".

From the more than probably 12000 messages we did in this newsgroup together
in the last 12 months you should know that I in my idea.

Cor

In which case they won't notice that MS is no longer supporting VB 6.

Mike Ober.

Show quoteHide quote

LOL,

Good point by the way

Cor

They will notice when they update to SP6, experience its bugs, and want to
obtain a fix.

While I would certainly agree that there are more people out there that want
a VB.COM-like tool than have signed the petition, I still hold to the idea
that it wouldn't be enough to make it an economically worthwhile proposition
to Microsoft.  We can quibble about our cost and profit estimates, but
regardless of what the actual total costs are, it's going to be more than
$0, which is what Microsoft will currently have to spend to get achieve its
target market share for VB.NET without doing *any* more development of VB6.

I know I mentioned this before, but besides the economic issues there is the
issue of the human nature of the average Microsoft employed developer.  Any
programmer assigned to the VB.COM project at Microsoft would view this as a
punishment.  "What did I do to deserve this?  God, why me?"

For so many reasons, VB.COM is just not going to happen.

- Mitchell S. Honnert



Show quoteHide quote

Show quote Hide quote Why don't we do a little experiment?

Why don't we put together an email that you can send to classic VB
developers that you know that tells them about the petition, where to sign
up and asks them to forward the email to friends of theirs who are classic
VB programmers?

This is surely the most efficient method of getting the word out, and should
give us (within a month) a real idea of how many classic VB developers want
a better migration tool and extended support for classic VB.

It should be relatively short and simple.  I'll post a suggested message in
a little while.......

Jim Hubbard

I don't know anyone who still programs in VB6 and even if I did, I certainly
wouldn't want to do anything that would encourage them to sign the VB.COM
petition.  I personally think that the petition is a bad idea.  And even if
I thought it was a good thing, I don't see Microsoft following the
recommendation.

- Mitchell S. Honnert


Show quoteHide quote

Whether Microsoft backs down or not, I think it would be good for us and
Microsoft to get as good a count of the classic VB users that are
disappointed in .Net.  Then we'd know if we are just a vocal few or if
Microsoft really pissed off millions of VB users.

Maybe Microsoft would at least put more effort into a methodology that would
allow VB6 programs to be upgraded to VB.Net.

Microsoft is (much to their credit) already realizing that they screwed up
the whole RAD feel of VB in VB.Net and are trying to bring some of that back
with VB.Net 2005.

I've got the beta of VB.Net 2005, and I like it MUCH more than VB.Net 2003.

As much as it may seem like I am anti-Microsoft, I most certainly am not.
Microsoft has done more right than it has wrong.  It charges too much for
its software and listens to its own developers over its customer base - but
those things can be fixed.

I am very vocal about screw ups - but, isn't that what we're supposed to
do - squeal when we need grease?

I know that (as a business owner myself) I love my customers that point out
where we can be better or where we have changed something that they loved
the way it was...they keep me in line with our customers' needs and wishes.
But, I don't make them scream about it - I actually have a menu item for a
customer to submit a help ticket or to simply submit a "Wish List" of things
they want added to the application.

I am not anti-.Net.  I just want the RAD development environment that we
enjoyed with classic VB back and I want to be able to port my old VB
programs more easily so that I can take advantage of the new features
available in the .Net framework.  Is that too much to ask?

I am impressed with the improvements in Vb.Net 2005.  I can't wait to try
out the full version.

Jim Hubbard

Well, I guess we still disagree.  I think the effort is fruitless.
Microsoft isn't going to go out of its way to find out there is a demand to
do something it doesn't want to do nor thinks would be a bad idea.

Jim, I'll fully admit that this may be a matter of perspective, but I
personally couldn't disagree with you more that Microsoft "screwed up"
anything.  I think the exact opposite, in fact.  I have some pet peeves with
VB.NET, sure, but on the whole I think they did an incredible job at
improving Visual Basic, including RAD.

I'd like to get your impressions of VB.NET 05, specifically what features of
VB6 that VB.NET 05 is "bringing back".  I tried Beta 1 of VB.NET 05 on my
machine for a bit and while I too was quite impressed with the improvements,
I didn't recognize them as being features of VB6 that didn't make it into
VB.NET.  Can you give an example of such a feature?  (I'm not denying they
are they; I just didn't notice any.)

- Mitchell S. Honnert


Show quoteHide quote

Show quote Hide quote Microsoft didn't improve Visual Basic, it created a /new/ programming
language (language stability is broken).  That's what the whole discussions
about VB6/VB.NET are about.

Well, I suppose we could get into a detailed discussion about what the word
"improve" really means, but I think it can be reasonably applied to VB.NET.
"Visual Basic", as distinguished from its implementations in BASIC,
QuickBasic, VB6, or even VB.NET itself, can be defined in terms of a basic
set of keywords or syntax style.  Separating out "Visual Basic" at this
level, VB.NET certainly can be seen as an improvement over VB6.  I don't see
the term "improvement" being at all dependent on principles like language
stability or even easily portable code.  Today's cars are vastly superior to
the Model T and other cars of that general era.  There were evolutionary and
revolutionary changes along the way.  But they're all cars.

- Mitchell S. Honnert



Show quoteHide quote

Mitchel,
A car is forever a car, however therefore is a Gogomobil  not direct a
Ferrari.

With what I don't tell that VBNet is not a VB type language like VBS, VBA
and VB6 are too.

Cor

Err, AFAIK, Basic has never had an agreed standard, not in the same way the
C++ does. Microsoft made it up so I think they are perfectly allowed to
improve it.

I remember a time when there were hundreds of variants of BASIC.

Rob.

That's true, Visual Basic has never been standardized.  However, is this an
excuse for Microsoft to dispose customers' assets?

On 2005-03-26, Herfried K. Wagner [MVP] <hirf-spam-me-here@gmx.at> wrote:
I've never said much on this subject, mainly because I just don't care
very much about it.  It's also a pretty common situation, a company
stops development of a development tool and its customers clamor for an
easy upgrade path.  The more common solutions don't seem to be on the
table, but then VB has a pretty unique place in computing history, as
does Windows and certainly Microsoft.

There's one thing I keep wondering about, though.  Didn't you see this
coming?  I mean, that doesn't invalidate the petition at all, as far as
I'm concerned it's perfectly reasonable for customers to make their
desires publicly known, but in every single requirements meeting I had
back in the 90s the probable limited lifespan of VB was a given.

Sometimes we'd use VB anyway, sometimes we'd do the UI in VB but the
business logic in a more easily ported language, but in every meeting I
was in, in every language comparison I read (ones that weren't from the
MS marketing department at least), the probability that VB code would be
stuck without a migration path at some point in this decade was
mentioned.  It wasn't a certainty that this would happen, but everyone I
knew considered it probable for a number of reasons.

Now I could be reading this wrong, but the tone of the conversation
around this issue today makes it sound like my situation then was much
different than everybody elses.  I often say it's impossible to make
statements about what "everybody knows" when it comes to development. 

Like I said, this wouldn't invalidate the goals of the petition one way
or another, and I personally don't care much about those goals one way
or another.  I'm just curious if this is the case.  Back when you
decided to create all this code in VB6, was the lifetime of the product
a point of discussion at all?



Show quoteHide quote

Show quote Hide quote Back in the late 90s, it was clear that there will be an improved version of
Visual Basic available in the time after VB6.  Many VB customers set their
hope into this VB7.  Microsoft (at least partially) implemented a VB7 which
contained implementation inheritance and many other features.  This version
and its set of features has been presented at the BASTA conference in Munich
in 1999.  However, this version has never been released.  Instead, Microsoft
created a new programming language and marketed it as VB7.  This
discontinuation of a product was not forseeable.

I have to disagree.  Microsoft could have made a code-compatible VB7 based
on .NET.  However, surprisingly Microsoft decided to create a new
programming language which broke compatibility even in cases where a break
was not necessary from a technical point of view and didn't bring benefits
(make the language more consistent, etc.).  Additionally most Classic VB
code was not written directly for VB6.  Instead a lot of code has been
written in previous versions and it was simply upgraded to the new version
of Visual Basic.

Some companies started writing the code they use in Microsoft Basic days or
earlier.  So, at the time when the decision for using Microsoft Basic
(QuickBasic, PDS, GW-BASIC, Visual Basic) was made it was unforseeable that
Microsoft would discontinue the product and stop the evolutionary process
the language followed from early Microsoft Basic days to VB6.

Back in 1998, when VB6 was released, Visual Basic was the result of 22 years
of language evolution.  Would you imagine that an evolution that lasted for
a quarter of a decade would suddently stopped and replaced by revolutionary
change?

On 2005-03-26, Herfried K. Wagner [MVP] <hirf-spam-me-here@gmx.at> wrote:
Show quoteHide quoteOkay.  Like I said, it's impossible to generalize about what "everybody
knows".  It's a big industry, and obviously what was considered a
probability in my corner of the industry was considered extremely
unlikely in your corner.  I'm sure the opposite is true on other topics,
where things I considered to be almost certain to happen never came
about at all.  I was just curious if that's what was going on, and
you've answered that question.

And I don't disagree you have a beef with MS, who certainly implied that
VB had a longer lifetime than they gave it.

Yeah, that's in the FAQ as well, but I don't see it at all.  I never saw
VB as some kind of continuation of MSBasic, and I've seen an extremely
small amount of code ported from one to the other.  Most VB development
I've seen started in VB (or VBA).  Of course, neither one of us has firm
numbers here on the amount of code ported into VB from MSBasic, just
anecdotal evidence, so there's no way we're ever going to resolve that
question here.

Show quote Hide quote That item in the FAQ was to counter the myth that VB and COM are
interdependent and almost synonymous, and to counter the myth that changing
platforms inevitably results in major changes to languages. Versions of
Microsoft Basic have gone from CP/M through MS-DOS, 16-bit Windows to 32-bit
Windows with the language mostly being extended and not changed. It could
have been the same for the move to .NET, but Microsoft didn't do that.

And if Microsoft get into the habit of believing that platform changes mean
big language changes, yours will be among the code which has to be rewritten
next time round.

Dan Barclay (a former VB MVP) has a large amount of commercial code in VB6,
some of which originated in proijects he did in DOS days. I don't doubt
there are many others.

But even if the majority of code has been written in VB4 or later, that
still doesn't change the fact that substantial projects cannot easily be
moved on.

You cannot make that generalization about every 'substantial project'
really. Perhaps that has been your experience with your projects and maybe
even a few other with theirs, but I can't believe that is EVERYONES
experience that has a larger project and decided to make the jump to VB.NET.

Are you are looking to just run the VB6 code through an upgrade wizard and
get 100% useable VB.NET code out the other side without any additional work?
If you are then I am afraid that you are never going to be satisfied.

VB.NET IS NOT VB6.

I would not want my large VB6 project simply migrated over to VB.NET that
way. That amounts to nothing more than a new exe file that has been run
through the new compiler but makes use of barely any of the benefits of the
new platform. Why do it? In fact MS points this out in all their web casts.
While it gets you a new exe it is NOT the same. You can even take older C++
code and simply compile it with the /clr switch and get the same effect.
WHY?

..NET is a NEW platform with advantages that the older VB6 runtime does not
have. To take full effect of the new features you need to rethink some of
hat you did in the past.

If you have customers that are asking you to update your legacy VB6 apps to
add new features then do your self a favor and rewrite the VB6 code into
VB.NET. If your customers are happy with your legacy stuff and the legacy
stuff is still supported by the OS then go for it. At the point the OS stops
supporting your legacy stuff, or the newer OS platforms start causing
problems with your legacy stuff then it is time that you make a decision.
Are you going to keep up or simply refuse to state support for the new
platforms and suffer the consequences that come with that decision.

Show quote Hide quote Point out some that haven't.  EVERY large VB6 project that I have seen try
and make the jump to VB.Net has meant a substantial (most times) complete
rewrite.

Why not?  It is technically possible.  Microsoft simply chose to break
backwards compatability with VB6 while maintaining it with C/C++.  It was a
choice to screw the largest group of developers on the planet.  A very bad
choice.

Isn't that the whole jist of this thread?  Did you just get that?

For 2 reasons.....1) so that your code continues to run on the new platform
(.Net) and you continue to get the benefits of your investment and continue
to be able to access your data the way you always have.......2) So that you
can implement VB.Net capabilities as YOU need and want to......NOT as
Microsoft dictates.

I don't think anyone here has said that they don't want to migrate their
apps to VB.Net.  The problem is that there is no way to do that (in most
cases) without rewriting the application.

THERE IS NO VALID UPGRADE PATH!  If you disagree with this (and would sign
an NDA) I would be happy to let you try and update the application that I am
working on.

Sure you do.  But, you should be able to do that on your own time, without
being force-marched into rewriting all of your old VB6 code.  Migrating
languages should be done because of the added benefits of the new
language.....NOT because Microsoft INTENTIONALLY broke backwards
compatability where it was technically possible to embrace it just as they
did with C/C++.

What would've happened if C or C++ had been treated like VB6?

Those languages run Windows.  Therefore, they would never have been treated
that way.  But, why not?  Because Microsoft knows that it could not replace
all of it's millions of lines of code in C# in a timely manner.  It would be
devastating for them to even try to do so.

Companies (both large and small) have millions of lines of VB code MORE than
Microsoft has of C/C++ code.  So, why force them to do something that would
be devastating to your own large, multi-national company?

Because you don't give a damn about them, their MILLIONS and MILLIONS of
lines of code or the developers that helped make you the monopolistic giant
that you are.  Because  you have placed your own goals and plans above those
of your customers.

If Linux had a Visual Basic-esque programming language.......Microsoft would
drop like a rock.  (Clicking my heels and wishing....)

Jim Hubbard

Show quote Hide quote Don't misquote or misrepresent me. I didn't say "every" substiantial
project, I said "substantial projects" in the plural.

No, I'm merely expecting that the work is reduced to a reasonable and
technically achievable level, which it has not been up until now.

Quite so. As Karl Peterson said back in 2001, ".NET is cool, its just a pity
they didn't include VB in it"

The answer to why comes largely as a result of your own statements in the
next paragraph.

Making use of new features in .NET is why you would want to start from
making use of existing code so you can then extend it.

In saying you "need to rethink some of what you did in the past", you are
implying that there are some aspects of what was done in the past which
don't need to be rethought. But changing the language and not providing an
upgrade path means that even those parts that dont need to be rethhought end
up having to be rewritten. That's a waste.

On Sat, 26 Mar 2005 18:24:46 +0100, "Herfried K. Wagner [MVP]"
<hirf-spam-me-here@gmx.at> wrote:

I don't think Microsoft are disposing of their customers assets any
more than the fuel supply companies in the UK disposed of their
customer assets, when they were no longer able to supply leaded
petrol.   Many "assets" had to be converted to run using the new
standard, though they provided an upgrade path, this did not cover all
of the assets in the field.

Or the broadcasters will have to continue providing analogue signals
to their customers assets after the switch off date in 2008.

Suppliers only have an economic or contractual duty to their
customers, so HP still supply the HP 1000 E series to the US military
as they have a contractual duty, though they obsoleted it 15 years
ago.  If you want to guarantee supply, right it into your supply
contracts!

Doug Taylor.

Sorry to jump in off-topic, but I couldn't help it after you mentioned the
HP 1000 E-series. I did a lot of my early programming work on that platform,
and to be honest, I still miss it sometimes. Of course, it helped that we
had at the time a tremendously supportive and helpful HP representative who
worked closely with us to make sure we had everything we needed. HP was
quite a company back then.

Thanks again for bringing back some good memories. Maybe I need to join the
military just so I can work on that platform again. :)

Carl Rapson

<snip>
Show quoteHide quote

May not be a long career, if you want to stay close to the hardware,
there is one in each wing of a cruise missile, so you may only last
one flight.  Ah the joys of real time programming.
Show quoteHide quote

Show quote Hide quote Thanks for the information. One in each wing of a cruise missile? That's
interesting. I think I'll do more research on that.

Carl Rapson

Hi Doug,


Its a matter of scale & proportion. Microsoft made the change from VB6 to
VB.NET when it was their most popular programming environment, and without
making it practicable to convert a large proportion of the projects written
using VB6

Had VB6 been little used, or only a small proportion of projects taken a
significant effort to migrate, then your comparisons whould have been valid.

Show quote Hide quote So not many people use cars with leaded fuel, well in the UK it was
around 60% of vehicles were originally supplied to run on leaded fuel,
and around 95% of viewers to terrestial television use analogue, so I
feel it is a very good analogy.

Doug Taylor

Show quote Hide quote A more proper analogy would be making the roads thinner (i.e. OS) so that
your old car would not fit on the new streamlined (thinner) streets, and
adding a cargo bay that only accepts packages wrapped in a new space-aged
polymer.

Neither of these things are a real problem.......unless you do deliveries
for a living.

Jim Hubbard

Show quote Hide quote Speaking of which......Microsoft now expects us to adopt WinFX and Avalon
(which will only run on Longhorn) while the VAST majority of businesses
haven't even installed SP2 for XP yet.

http://news.com.com/Businesses+slow+to+move+to+SP2/2100-1012_3-5650923.html?tag=nefd.top

Am I the only one that sees a problem with this?

Maybe breaking Microsoft up was the solution to this crap after all.  If
they muck with too many businesses (and the government) we may just see that
solution rear its head again.

Jim Hubbard

¤ Speaking of which......Microsoft now expects us to adopt WinFX and Avalon
¤ (which will only run on Longhorn) while the VAST majority of businesses
¤ haven't even installed SP2 for XP yet.
¤
¤ http://news.com.com/Businesses+slow+to+move+to+SP2/2100-1012_3-5650923.html?tag=nefd.top
¤
¤ Am I the only one that sees a problem with this?
¤

Probably. You're talking about an OS that hasn't even been released yet. In addition WinFX will not
even be ready for the initial release of Longhorn so I'm not sure what you're getting your undies in
a bundle over.


Paul
~~~~
Microsoft MVP (Visual Basic)

Show quote Hide quote This is how innovation works:

1) MS releases a new feature/model that allows developers to do NEW things.
2) Developers (that's you) use these new features to implement new and
amazing applications that take advantage of them.
3) Customers see your cool apps and want to use them so they have to migrate
tot he newer stuff to get the newer features.
4) Repeat

What is wrong with this?

http://news.com.com/Businesses+slow+to+move+to+SP2/2100-1012_3-5650923.html?tag=nefd.top
Yup, just you I am afraid.

Why is 'breaking up Microsoft' always the answer? and what the heck was the
question here?

You don't want WinFS or Avalon?

Settle on your platform, build apps using the tools you want that cam build
apps that run on that platform and stay happy.

If you want to keep developing apps that run on Windows 2000 using VB6 and
have a decent enough of a customer base to make that profitable for you then
fine.

Hell, about 2 years ago I built a new network and office infrastructure for
a guy that had a small company a that was running on a small LAN (coaxial
cable based ethernet) running WFW using a database that had been patched and
modded so many times the screens looked like a ransom note assembled out of
odd magazine clippings.

It worked for him so he kept using it. Some of his machines died and he had
replaced them with PIII systems and 30Gig hard drives and kept running WFW.
I made my money off of him moving him to a newer server based network
(Microsoft Small Business Server) so he had his own email and web server
hosted and he still uses that old DB. I told him that I would get his system
set up and brought into the current decade and get all the new bells and
whistles running but I was not touching that old DB. Why? because HE had
made the business decision to not change it. All I was going to do was give
him the rest of the system and make sure that his old DB was running the day
we cut over. If he wanted to keep running the old DB he was going to have to
get support for it elsewhere, and he was happy with that. Someday it will
die. The company that writes it will no longer exist and he will need to
migrate over to something new, but then he will be under the gun and stuck.

Best to move when you have some latitude I always say. When you wait to the
last minute you end up making your self a buyer in a sellers market and the
sellers smell fear and charge you pretty for it.

Move up or don't move up, the choice is completely yours.

Show quoteHide quote

On 2005-04-04, Jim Hubbard <reply@groups.please> wrote:
Show quoteHide quoteActually, WinFX, Avalon, and Indigo will be available as packages for
Windows XP and 2k3.  WinFS may or may not be available - simply because
it has been pulled from longhorn.

Show quote Hide quote Since when?  Got a link for that?

Jim Hubbard

Show quote Hide quote Nevermind......I found a couple....

Way back in August 2004...... at
http://www.microsoft.com/presspass/press/2004/Aug04/08-27Target2006PR.asp

More recently..... a March 17, 2005 article at
http://www.windowsitpro.com/Windows/Article/ArticleID/45741/Windows_45741.html

And, from Microsoft herself at
http://blogs.msdn.com/johnmont/archive/2004/11/27/271026.aspx ....

-------
Microsoft's roadmap for client UI development has three main phases:



  1.. Today, use Windows Forms v1.1 and observe the Microsoft Patterns and
Practices guidance for maintaining clean separation between UI and other
application logic.
  2.. When Avalon v1.0 releases (scheduled for mid-2006), we recommend that
applications looking to differentiate their user interface such as Web sites
and graphically intensive applications such as complex data visualization
look closely at Avalon. Other applications should continue using Windows
Forms.
  3.. Following the release of Avalon 1.0, the next version of Visual Studio
following Visual Studio 2005 will contain tools and designers to support
Avalon. At this point, customers should start to move their new development
efforts to Avalon and use the Windows Forms/Avalon interoperability
features.
-------

This last one is good in that Microsoft is letting us know the path that
they will be taking far in advance.  But, since Avalon tools won't even be
in the next release of Visual Studio, I can't really see most large
companies putting out production systems anytime soon.

I don't envy Microsoft's position in releasing new details about
not-yet-available stuff.  If they don't say anything until it's ready, they
get bitched at for not giving developers a "heads up".  If they do reveal
their plans, they have early adopters that will bitch about rewriting code
based on an early release.  And, they get pressured to deliver the new tools
quickly and to give deadlines that frequently have to be moved back (causing
further uproars) rather than being able to just release it when its stable.

Cheers for the heads up.....and there even appears to be "Windows
Forms/Avalon interoperability features".   But, after the VB6 "upgrade" tool
fiasco.....I may just wait for the real tools.

Jim Hubbard

¤ >> Whether Microsoft backs down or not, I think it would be good for us and
¤ >> Microsoft to get as good a count of the classic VB users that are
¤ >> disappointed in .Net.
¤ > Well, I guess we still disagree.  I think the effort is fruitless.
¤ > Microsoft isn't going to go out of its way to find out there is a demand
¤ > to do something it doesn't want to do nor thinks would be a bad idea.
¤ >
¤ >> Microsoft is (much to their credit) already realizing that they screwed
¤ >> up the whole RAD feel of VB in VB.Net
¤ > Jim, I'll fully admit that this may be a matter of perspective, but I
¤ > personally couldn't disagree with you more that Microsoft "screwed up"
¤ > anything.  I think the exact opposite, in fact.  I have some pet peeves
¤ > with VB.NET, sure, but on the whole I think they did an incredible job at
¤ > improving Visual Basic, including RAD.
¤
¤ Microsoft didn't improve Visual Basic, it created a /new/ programming
¤ language (language stability is broken).  That's what the whole discussions
¤ about VB6/VB.NET are about.


They most certainly improved it, they just didn't make it very easy to upgrade.


Paul
~~~~
Microsoft MVP (Visual Basic)

Then don't pass it along.  I think we can manage.

It seems that Microsoft noticed the problem, along with us classic VB users.
"...Somasegar gave details of some of the company's efforts to keep existing
customers of older versions of VB6 in the Microsoft fold. With Visual Studio
2005, which is code-named Whidbey, developers will be able to use prewritten
components, called controls, that worked with VB6, he said.

"To be fair, we did lose a little bit of the VB experience when made
transition from VB6 to VB.Net," Somasegar said. "Whidbey Visual Basic is
going to provide the best RAD (rapid application development) experience
that they have ever seen."


It's the RAD experience that was missing.  VB was originally meant to be a
RAD tool....not a challenger to C/C++.  In keeping it a RAD tool Microsoft
could cover the professional developers with C/C++ and everyone else with
Visual Baisc.  By trying to make VB as powerful as C#, they are screwing up
their lineup.

But, back to your question........In VB.Net 2005, you can turn off seeing or
stepping through code that you did not write.  Speaking as a clsssic VB
programmer.... Who really wants to see that code anyway?  I never had to
step through forms or control code before.  For less experienced
programmers, it is simply confusing.  For more experienced cVB programmers,
extra code is simply an aggravation - one more thing I have to contend with
that I don't need.

EDIT AND CONTINUE!  For the love of God.....why did this ever leave?

A simplified IDE.  Why?  Because the goals of most Visual Basic programmers
are simply to solve business or personal problems in the most efficient
manner possible.  Their goals do NOT usually include becoming a programming
guru (although that frequently happens as a side effect of writing so many
applications with a RAD tool).

Just these 3 things get us closer to the RAD feel we enjoyed with classic
VB.  I think that I speak for most classic VB programmers when I say that I
don;t give a rat's * if the language uses a runtime or framework.  I want to
solve my business problems and make my life easier ASAP.  That requires a
RAD-centered design.....not pushing me to become a .Net framework expert.

I haven't played with it as much as I need to.....but I like what I see so
far.  I will let you know more as I continue to test (when I have the time
to).

Jim Hubbard


Show quoteHide quote

Jim,

And when you have done that you will take probably all back what you have
written including the distribution of Net.

Cor

Here here, the VB.NET environment is a big step forwards but most of the
benefits come from the .NET framework which is IMHO a pretty well thought
out set of objects and libraries.

The bits of the language borrowed from C++ like inheretence, overloading and
extended encapsulation (like protected, friend etc) undoubtly make the
language more, err, grown-up.

I recently had to make a slight code change to our major VB6 project and
re-loaded VB6 for the first time in about six months. Boy did it feel clunky
Rob.

Rob,

That's your personal opinion, but there are people who would disagree.

The features were not borrowed from C++.  PIE are theoretical concepts which
were implemented in C++, for example, but in many other programming
languages too.  BTW:  'Friend' was available in VB6 too.

Jim,

I agree that there are lots of customers who fell really pissed off by what
Microsoft did with VB6, but I doubt that most of them are disappointed by
..NET.  .NET has its right to exist, but so does Classic VB.

The FAQ to the petition lists the reason why the MVPs who initiated the
petition did this step into the public instead of talking to Microsoft about
this issue again.

No, that's not too much.  I think it's a customer's right to give the
manufacturer feedback about products and product lifecycles.

Full ACK.  But this doesn't solve the VB6 issue.

Show quote Hide quote I agree.  I should've been more clear in my response.  The dissappointments
in .Net that I see are 3-fold.

1)  .Net is not backwards compatible with my VB6 programs and offers no real
migration tool.  At best, the migration tool supplied simply tells you why
(anything but a VERY simple application ) will not run in VB.Net.  In larger
applications, a complete re-write takes less time than upgrading.

2)  The RAD feel/ability to develop applications is gone.  Edit and continue
was great - and should be back in VB.Net 2005.  Make it simple!  Our jobs
are already hard enough.  We want a tool that helps us make making a living
easier - not a tool that demands we become a .Net framework expert to create
a simple IM application.

3)  The .Net framework distribution.  Do we really have to lug this beast
everywhere we distribute applications?  Thinstall can wrap all needed .Net
framework components into a single exe with no external dependencies - sure
it lareger, but it will never be missing a component or get broken because a
component or portion of .Net was upgraded.  You'd have to make fundamental
changes to the OS to screw Thinstall apps up.  (Not that that couldn't
happen, but it is more unlikely than a change to the .Net framework.)

It should also be the core of the letter I suggested.

True.

Neither does it answer the question of why Microsoft have spent more time
and energy keeping C/C++ backwards compatibility than it has done with
Visual Basic 6.

Microsoft themselves acknowledged Visual Basic as the world's most popular
programming language.  They even realized that the majority of the
programmers in the world (Visual Basic programmers) were "task-oriented
developers" whereas C++ developers are "power-oriented".

Taken from
http://msdn.microsoft.com/vstudio/productinfo/whitepapers/default.aspx .....

---------
For its part, Microsoft offers four programming languages and associated
development environments, each designed to appeal to a particular school of
programmer:

  a.. Visual Basic .NET, the latest version of the world's most popular
development tool and language. Visual Basic .NET delivers unsurpassed
productivity and unique language features for task-oriented developers
building solutions with the .NET Framework.


  b.. Visual C++ .NET, the tool of maximum power and control. With the C++
language, power-oriented developers can bridge platform technologies and
build both native Windows-based and .NET-connected solutions with maximum
performance characteristics and enhanced functionality.


  c.. Visual C# .NET, the modern and innovative programming language and
tool. Introduced in 2001, C# offers a familiar syntax, that is attractive to
C++ and Java developers, along with unique language constructs that offer
code-focused developers a more elegant experience when developing
applications for the .NET Framework.
-------


......it continues.....

-------
Visual Basic .NET
http://msdn.microsoft.com/vbasic

Visual Basic 1.0 revolutionized Windows development by lowering the barrier
to entry and making a broad audience of developers more productive than
ever. Building on this rich history, Visual Basic .NET offers task-oriented
programmers a human readable syntax, an intuitive user interface, and tools
and upgrade wizards that speed the development of Microsoft .NET-connected
applications. Visual Basic .NET takes advantage of the ease of development
espoused by its exceedingly popular predecessors, while adding new
capabilities that enable all manner of programmers, from the beginner to the
experienced corporate developer, to build applications for Windows, the Web,
and mobile devices.

Task-Oriented Development
Deadlines are nothing new to the software industry. For a large group of
programmers, deadlines are a daily fact of life. These programmers are often
charged with building opportunistic applications that address a specific
business need and require a modicum of planning and a fast track to
deployment. Sometimes such solutions will be tested rigorously, while other
times the application will be built and immediately deployed, freeing the
programmer for the next assignment. These task-oriented developers are
focused on delivering solutions quickly. Task-oriented development tools,
therefore, must place such a premium on productivity that it is acceptable
to abstract programmers from the nuances of the underlying platform and
empower them to conceive of an application, build it from scratch, and
quickly disseminate it across a business group.

Programmer Constituency
Visual Basic .NET is ideal for the following types of programmers who are
looking to use the .NET Framework to construct the next generation of
applications and services:

  a.. Programmers looking for a fast and productive development tool for the
..NET Framework. Visual Basic .NET offers an easy-to-understand syntax and an
intuitive development environment to help programmers construct applications
quickly. Further, with a large and established community of programmers,
Visual Basic .NET programmers have a wealth of resources at their disposal
to help them get up to speed with Microsoft .NET.


  b.. Programmers with existing Visual Basic skills or code assets. Visual
Basic .NET builds on the keywords, syntax, and nuances of the Visual Basic
language. Its case-insensitivity will be immediately familiar to traditional
Visual Basic developers, as will the human-readable syntax. Programmers with
a significant code investment in earlier versions of Visual Basic can move
their code forward using the built-in upgrade technology. Additionally, most
existing ActiveX® controls can continue to be used with Visual Basic .NET.


  c.. Developers looking for familiar design-time and code editor paradigms.
Many of the principles of designing applications and writing code are
carried forward from the Visual Basic .NET predecessors, including
drag-and-drop design of applications, IntelliSense® for assistance in
writing code, and automatic code formatting for easier readability.


  d.. Programmers looking to build applications with a more intuitive and
accessible language. Visual Basic .NET is designed to be accessible to a
full range of developers, from beginners to experts. Beginners will find
many unique features of the Visual Basic language as useful as the key
productivity enhancements of the Visual Basic environment.
Unique Language Features
Visual Basic .NET contains several unique language features that lend it an
aspect of productivity not found in the other Microsoft-supplied .NET
languages, including:

  a.. Default variable initialization. Visual Basic .NET does not require
variables and members to be initialized prior to use, so beginning
programmers may not be frustrated by seemingly arcane use requirements as
found in other .NET languages.


  b.. Implicit typing and late binding. Visual Basic .NET code need not
specify the type of a variable before it is used, helping programmers write
useful code with a minimum of training.


  c.. Enumeration behavior. Visual Basic .NET offers more intuitive behavior
when using enumerated types.


  d.. Default public access. By default, members of a Visual Basic .NET
class are declared to be public, which offers programmers a more intuitive
syntax.


  e.. Use of shared members. Shared members may be accessed in Visual Basic
..NET through both the class name and an instance variable of the type to
which they belong, helping programmers write intuitive code. For example:
Dim x as new MyClassx.SharedMethod() ' works just as well as...

MyClass.SharedMethod()a.. Optional parameters. Visual Basic .NET supports
optional parameters, affording class designers more flexibility in designing
their libraries and giving programmers the ability to write useful code
without having to learn all the nuances of object-oriented programming.


  b.. Filtered catch blocks. Visual Basic .NET offers flexible structured
exception handling errors. Filtered catch blocks enable developers to filter
errors based on the class of the exception, any conditional expression, or
an explicit error number.


  c.. Parameterized properties. Properties in Visual Basic .NET may contain
parameters, making them more flexible than their C# counterparts.


  d.. Declarative event handlers. Visual Basic .NET event handlers may
declare the events to which they are subscribed using the Handles keyword.


  e.. Interface member redeclaration. Visual Basic .NET enables programmers
to rename a member of an interface when it is implemented in a class.
Unique Environment Features
Visual Basic .NET also includes a number of key environment enhancements
that enable programmers to more productively design and write compelling
applications and services. These enhancements are above and beyond the
Visual Studio® .NET features shared among all .NET languages:

  a.. Background compilation. Background compilation works behind the
scenes, silently compiling your code while you are working. Visual Basic
..NET developers should be able to know immediately if they have errors in
their code.


  b.. Pretty listing. The Visual Basic .NET code editor can (optionally)
automatically format your code as you type, saving you time. Pretty listing
can automatically align your code to the correct tab position, recase
keywords and variables, add a missing then to an if statement, and more.
Performance
A final area of great importance is performance. The Visual Basic .NET
compiler generates Intermediate Language (IL) code that is equal in
performance to the code generated by the C# compiler.

-------

So, what happened?  It sounded like they knew what was needed, but VB.Net
(up to 2003) is a miserable failure at delivering on the requirements
Microsoft mentioned above.  The only thing they needed to think about each
day, before they started work on VB.Net is "My users are task-oriented
developers."  Maybe they should have a morning yoga session in which this is
their mantra.

Whatever it takes.....so far, thorough VS.Net 2003, VB.Net has definitely
NOT lived up to the "task oriented" language that was classic VB.  I hope
that VB.Net will get us closer to that RAD environment that made classic VB
the #1 used development language in the world.

But, I think that Microsoft has severely screwed their chance of having such
a large following in the future.  It's a matter of trust, and Microsoft has
trampled on that trust with no regard for the consequences to it's customer
base.  At the same time, they went out of their way to incorporate VB-like
features and backwards compatibility into the C++, C and C# .Net
implementations.

Why not do the same for VB?  There has still been no legitimate answer to
that question from Microsoft because there is no legitimate answer.

Plainly put.  They spit in our faces.

I think Microsoft began listening to powerVB programmers and not so much to
the everyday (millions of them) VB programmers.  Perhaps more feedback from
everyday programmers and less from (no offense intended) professional
developers, who make up the minority of classic Visual Basic programmers.

Jim Hubbard

True, I was a bit surprised when this disappeared.

Ohh please dont' start that again :-)

Rob.

Just making a point that it can be done.

I'm going to be sacrastic but guys, it's time to move on :-) Come on in, the
water's fine.

We've got a pretty big VB6 application that cost a lot to develop. It's six
years old and reached maturity about two years ago. When it's replaced, we
will effectively be starting again - not only has the market changed in
requirements (we have to be a lot more web friendly) but we've also changed.
We've learnt new ways of doing things - having to start again is probably a
good thing.

Rob.

Rob,

In other words:  "Come on, loose your assets.  Get over it!"  Sorry, but
that's not a viable proposal.

New technologies are typically designed to make people more productive for
/future/ development.  If a new technology requires a rewrite, the
advantages of the new technology are lost.  Remember that .NET will
experience the same fate as COM in some years.

On Sat, 26 Mar 2005 18:33:19 +0100, "Herfried K. Wagner [MVP]"
<hirf-spam-me-here@gmx.at> wrote:

Sorry, but you have to consider that, if your petition fails, which I
strongly suspect it will, you have three choices.

1) Migrate to a .net based language
2) Move to a different platform and language
3) Go out of business
This is somewhat less likely, COM was never adopted outside of the
Microsoft world, whereas the framework is supported by Borland and
other companies are beggining to move and provide other .Net
languages.

In addition there are compatible frameworks for Linux in development,
so you can develop common code for the two OS's, I also bet that
Microsoft as bigger vendor of Apple Apps is considering a framework
for the Apple OS's to reduce their development effort. 

The best parallel is the USCD framework, which lasted at least 20
years.

Doug Taylor.

Doug,

Show quoteHide quoteAll of the three options are not viable -- that's why the petition exists.

Show quoteHide quoteDelphi was tied to Win32/COM too.  Other manufacturers wrote compilers which
could create and consume COM components.  I don't see such a big difference
between COM and .NET from this point of view.

Is that really what /Microsoft/ wants?

<snip>

You'd think not.  By allowing the .Net framework to run anywhere, they make
the OS a commodity.  Then, nobody will have to run a Microsoft OS to run a
..Net application.  Right?

But, don't think this will happen.  Microsoft is too smart for that.  They
build in classes that take advantage of the Microsoft OS Flavor of the Month
and, when you use these classes to make your programming easier, you are
tied to the Microsoft OS with NO PORTABILITY to other OSs - not even to
other Microsoft OSs.

Pity they weren't as smart about the whole software-as-a-service model
(which is the real reason the whole .Net fiasco exists in the first place).
If you make applications run on servers and spit out HTML, you will make the
desktop a commodity - and BAM there goes the Microsoft cash cow that has
made them the giant monopoly that they are!

But, let's take a closer look....  At first, the .Net framework was made to
put out HTML from ASP servers.  Brilliant really....  They got a lot of
people to buy into the whole idea that Microsoft was playing nice and would
let you create web-based apps that would run in any HTML compliant browser.

Now, that they've got their hooks in you, they pull the rug out from under
you by announcing Avalon as the next (and only) gui engine in the .Net
framework.  Not a problem until you realize that Avalon will only be
available on Longhorn systems.  NO BACKWARDS COMPATIBILITY AT ALL.  NO
BROWSER COMPATIBILITY.  And, they've neatly sewn up the world into another
Microsoft only technology.

This time, though, they have done what nobody thought they could pull off.
They have taken over the internet.  They have made it their own, and it's
users their slaves to do with as they please.

Brilliant plan!  I'm happy for them.....really.  I'm just really, really sad
for us.

From www.joelonsoftware.com...
"But here's the thing. If you have a million line code base that's mission
critical, as many companies do, and VB suddenly changes, as it did, you have
a choice: keep using VB 6 or spend a lot of time (=money) upgrading to
VB.NET. If you keep using VB 6, eventually new things will come out that
will not be supported  from VB 6, and you'll be stuck using the yucky old VB
6 IDE until the end of time. Already most of the big component vendors are
doing all the new components as .NET components, not OCXes.
If you spend the money to upgrade to VB.NET, well, you just spent a lot of
money to stand still. And companies don't like to spend a lot of money to
stand still, so while you're spending the money, it probably makes sense to
consider the alternatives that you can port to that won't put you at the
mercy of a single vendor and won't be as likely to change arbitrarily in the
future. So as soon as people with large code bases start hearing that
they're going to have to work to port their apps from VB to VB.NET with
WinForms, and then they start hearing that WinForms isn't really the future,
the future is really this Avalon thing nobody has yet, they start wondering
whether it isn't time to find another development platform."

One more quote from Joel......"

Microsoft Lost the Backwards Compatibility Religion
Inside Microsoft, the MSDN Magazine Camp has won the battle.

The first big win was making Visual Basic.NET not backwards-compatible with
VB 6.0. This was literally the first time in living memory that when you
bought an upgrade to a Microsoft product, your old data (i.e. the code you
had written in VB6) could not be imported perfectly and silently. It was the
first time a Microsoft upgrade did not respect the work that users did using
the previous version of a product.

And the sky didn't seem to fall, not inside Microsoft. VB6 developers were
up in arms, but they were disappearing anyway, because most of them were
corporate developers who were migrating to web development anyway. The real
long term damage was hidden.

With this major victory under their belts, the MSDN Magazine Camp took over.
Suddenly it was OK to change things. IIS 6.0 came out with a different
threading model that broke some old applications. I was shocked to discover
that our customers with Windows Server 2003 were having trouble running
FogBugz. Then .NET 1.1 was not perfectly backwards compatible with 1.0. And
now that the cat was out of the bag, the OS team got into the spirit and
decided that instead of adding features to the Windows API, they were going
to completely replace it. Instead of Win32, we are told, we should now start
getting ready for WinFX: the next generation Windows API. All different.
Based on .NET with managed code. XAML. Avalon. Yes, vastly superior to
Win32, I admit it. But not an upgrade: a break with the past.

Outside developers, who were never particularly happy with the complexity of
Windows development, have defected from the Microsoft platform en-masse and
are now developing for the web. Paul Graham, who created Yahoo! Stores in
the early days of the dotcom boom, summarized it eloquently: "There is all
the more reason for startups to write Web-based software now, because
writing desktop software has become a lot less fun. If you want to write
desktop software now you do it on Microsoft's terms, calling their APIs and
working around their buggy OS. And if you manage to write something that
takes off, you may find that you were merely doing market research for
Microsoft."

Microsoft got big enough, with too many developers, and they were too
addicted to upgrade revenues, so they suddenly decided that reinventing
everything was not too big a project. Heck, we can do it twice. The old
Microsoft, the Microsoft of Raymond Chen, might have implemented things like
Avalon, the new graphics system, as a series of DLLs that can run on any
version of Windows and which could be bundled with applications that need
them. There's no technical reason not to do this. But Microsoft needs to
give you a reason to buy Longhorn, and what they're trying to pull off is a
sea change, similar to the sea change that occurred when Windows replaced
DOS. The trouble is that Longhorn is not a very big advance over Windows XP;
not nearly as big as Windows was over DOS. It probably won't be compelling
enough to get people to buy all new computers and applications like they did
for Windows. Well, maybe it will, Microsoft certainly needs it to be, but
what I've seen so far is not very convincing. A lot of the bets Microsoft
made are the wrong ones. For example, WinFS, advertised as a way to make
searching work by making the file system be a relational database, ignores
the fact that the real way to make searching work is by making searching
work. Don't make me type metadata for all my files that I can search using a
query language. Just do me a favor and search the damned hard drive,
quickly, for the string I typed, using full-text indexes and other
technologies that were boring in 1973."

Microsoft does not have the best interest of the customers in mind.  Not
that this is a bad thing....for a corporation, it's a good thing.
Corporations are supposed to have their investor's best interests at heart.

But, doesn't putting the customer's goals and ambitions first actually
accomplish the goal of taking care of the investors?  In my experience,
taking care of the customer is the ONLY way to take care of the investors.

Jim Hubbard

On Mon, 28 Mar 2005 02:23:23 +0200, "Herfried K. Wagner [MVP]"
<hirf-spam-me-here@gmx.at> wrote:

Show quoteHide quoteDelphi Win16/32/64 but not tied to COM at all, you could use COM, but
most developers used the Borland Framework, which surprise surprise is
very similar to the .Net framework. Well not really a surprise at it
had the same author.

Also you could port programs to Kylix with about the same difficulty
as porting VB6 to .Net, i.e. it depends on the coding techniques used
in the first place.
Show quoteHide quote

Do you think that developers working on Win32/COM code in Windows and most
other Microsoft products see their work the same way?!

Herfried,

I see no reaction on my answers to you in the other thread. In that thread
are you to my suprise telling that there is no need for any update or extra
support.

Both reactions from me on that have no reaction. May I assume that by giving
no reaction you agree about that.

Cor

Cor,

Mhm...  It seems that I missed some of the responses to my posts.  Can you
post a Google link?

I honestly don't know, but if I had to make a guess, I'd say yes.  In other
words, I'm saying that regardless of what language they are using or if what
they are developing is an application or an application development tool,
there is likely a tendency for MS employees to want to work on the "hot" new
product.  I think this is just human nature.  Because of the stigma of VB
not being for "real programmers", I believe this principle would apply
especially to VB.COM.

- Mitchell S. Honnert


Show quoteHide quote

I'd say no.  .NET was designed for writing user mode applications; it will
/never/ be used in certain low-level parts (kernel, core libraries) of the
operating systems.  In the past few years Microsoft published some clips
showing "Microsofties" at work:  Some of them do not even use Microsoft
tools for development.

The point I was trying to make related to the application the MS employee
was making, not the tools the employee was using to make it.  So, regardless
of whether they were doing their day-to-day work in C++, C#, VB.NET, or some
other non-MS tool, employees would be naturally drawn to projects that were
producing Microsoft's latest "sexy" application.

So, back to the original example, I believe far more programmers at
Microsoft would rather be working on developing Visual Studio .NET 2005 than
Visual Basic .COM.  In fact, I would go so far as to say that a collective
lack of enthusiasm at MS for enhancing what is essentially a dead language
(VB6) will play no small part in the failure of the VB.COM petition to
achieve its goals.

People don't want to work on dead-end projects.  Why would anyone want to
work on a project to revive a dead (from the standpoint of MS, anyway)
product when they could work on a product that is still in its earlier
stages?

- Mitchell S. Honnert

Show quoteHide quote

Mitchell,

It's marketing that declares Classic VB a dead programming tool, and VFP, on
the other hand, a tool which will continue to be alive for forseeable
future; there is absolutely no technical reason to dispose the Visual Basic
/programming language/.  At the time when Microsoft's marketing will stop
trying to sell customers VB.NET as VB7, Classic VB will be rehabilitated and
I am sure that Microsoft will have an enthusiastic and motivated team for a
new version of Classic VB.

Marketing...and the decision to develop VB.NET in the first place.

Who said anything about a technical reason?  I think the majority of reasons
that the VB.COM petition will fail have nothing to do with what is
technically possible, but with what is economically justifiable.

I find your insistence on associating VB.NET with "VB7" perplexing.  In
point of fact, VB.NET is called VB.NET and not VB7.  The only reference to
VB7 that I've ever seen are in the very early stages of development for what
became VB.NET or deep down in some documentation where the marketing weasels
overlooked it.  The only way I can see your point making any sense is if MS
did the exact opposite of what it did i.e. called it VB7 instead of VB.NET.
But they didn't.  They called it VB.NET.  It's a very bad name, but to most
people, the departure from the standard numbered naming convention implied
there is something quite different about VB.NET.

Can you give any examples of MS marketing VB.NET as if it were "VB7"?  From
my perspective, MS did everything it could to announce that VB.NET was not
VB7.  You couldn't open up a programming magazine without seeing some kind
of article that warned you of this.

- Mitchell S. Honnert

Show quoteHide quote

Show quote Hide quote Microsoft discontinued VB6 without providing an upgrade path.  It doesn't
matter which name Microsoft choose, what matters is that there is a serious
break in compatibility and language stability.  If Microsoft would see
VB.NET as a new programming language which is not a "VB7", they would not
have discontinued Classic VB.

Microsoft implicitly marketed VB.NET as a "VB7" by obsoleting VB6 and
marketing VB.NET as "the new version", which is technically unsustainable.

Maybe Java FUD magazines would have "warned" people, but for sure no serious
VB magazine.

You do your argument a disservice by using these types of easily disprovable
statements.  MS may not have provided an upgrade path that was satisfactory
as you define it, but they did provide an upgrade path.

Of course it matters.  It is for the very reason that MS chose to break
compatibility and language stability that they chose a different name.  Even
if someone somehow missed the fact that VB.NET was not going to be just VB7
during the MS media blitz before the VS.NET release, the name would indicate
to any rational person that there were major changes afoot.

This statement makes no sense to me.  MS *does* see VB.NET as a new language
and they *did* discontinue VB6.  Isn't that your gripe, that VB.NET is in
effect a different language because it broke language stability?  How could
MS not see this?  Do you think they created VB.NET and didn't realize they
were breaking language stability?

All I can say is that you and I must have had a very different experience
before the release of VB.NET.  I read books, magazines, online articles,
anything I could get my hands on about VB.NET and every one of them gave the
warning VB.NET was going to be a major departure from VB6.  We were told
again and again how most existing VB6 systems should probably be left in VB6
and that new systems be developed in VB.NET.  In fact, I remember becoming
frustrated with the repetition of this general statement.  I was looking for
new information and all I found was different sources regurgitating this
warning and other similar duplicated information.  I don't know what your
experience was, but I not only knew Microsoft was dumping VB6, I was beaten
over the head with it.

- Mitchell S. Honnert


Show quoteHide quote

Like Enron provided an investment vehicle for seniors.

Dude!   Per Microsoft......"Visual Basic .NET, the latest version of the
world's most popular development tool and language. Visual Basic .NET
delivers unsurpassed productivity and unique language features for
task-oriented developers building solutions with the .NET Framework."
(http://msdn.microsoft.com/vstudio/productinfo/whitepapers/default.aspx)  In
all previous versions, backwards compatability was kept as much as possible
and upgrading your applications meant a day or 2 of coding at most.

With "the latest version of the world's most popular development tool and
language" there was no reason that any "rational person" would conclude that
this "latest version of the world's most popular development tool and
language" would not continue the tradition of Visual Basic's historical
releases.

In fact, Micrsoft leads you to believe that VB.Net would do so by reaching
back into history as far as Visual Basic 1.0 to declare "Visual Basic 1.0
revolutionized Windows development by lowering the barrier to entry and
making a broad audience of developers more productive than ever. Building on
this rich history, Visual Basic .NET offers task-oriented programmers a
human readable syntax, an intuitive user interface, and tools and upgrade
wizards that speed the development of Microsoft .NET-connected applications.
Visual Basic .NET takes advantage of the ease of development espoused by its
exceedingly popular predecessors, while adding new capabilities that enable
all manner of programmers, from the beginner to the experienced corporate
developer, to build applications for Windows, the Web, and mobile devices."

I'm reading that as "this is another version of Visual Basic".  If you
don't, change your medication.

See Microsoft's statements quoted above........

So, you didn't read the Microsoft stuff?

Really?  Any Microsoft links for that?

Links would help here.

Even better, it would help us all if Microsoft cared to send email directly
to it's customer base concerning their products (like Visual Basic) instead
of leaving us to find obscurre web pages or press releases.  Why don't they
do that?  We did register the software.  They have our email addresses.  If
we use it for programming, wouldn't we want to be included in it's
evolution......or at least be notified of it?

Jim Hubbard

Touché!  :-)  I guess the point you are trying to make is that the
Microsoft's suggested "upgrade path" is so unsatisfactory as to not be
considered an upgrade path at all.  *My* point is that there are enough
people who agree that it *is* satisfactory, that one cannot support
categorical statements like the one Herfried made.

You apparently read a whole lot into that word "version".  I take it that
you believed it indicated in absolute terms that VB.NET would have
compatibility and language stability with VB6.  I didn't.  Especially with
all that was being written about VB.NET at the time.

Yes, I read Microsoft's stuff, but I didn't rely on it *exclusively*.  I
don't know what you did, so I can't say if this applies, but anyone who
relied purely on the MS marketing weasels in their business decisions
regarding VB.NET was seriously lacking in the due diligence department.  The
companies I worked for didn't just read MS press releases and wait for MS to
send them e-mails.  They went out and did research to find out what the
industry thought of this new thing called "VB.NET".

I can understand that there are people that are angered that VB.NET breaks
language stability, but I don't see how anyone would have been *surprised*
by this.  When did you discover this?  I'm getting the impression that you
loaded up the release version of VB.NET for the first time and only then
discovered that language stability had been broken.

- Mitchell S. Honnert




Show quoteHide quote

We could go back and forth on this all day.  What we need are hard numbers.

I did.....at least to the extent that VB6 was backwards compatible with VB5
code and to the extent that the VB5 code would upgrade to VB6.

I was too busy listening to Microsoft.  Thought they knew their product and
customers.  My bad.

I jumped on the very first .Net beta.  And, I did look around...plenty.
But, I have to admit that I tend to rely on the details of a new project as
released by the project's team.  In this case, that was the Microsoft .Net
team.

No.  I have been playing with VB.Net since the first beta.  However, I am
still being hired by companies that have tons of VB6 code that will no
longer be supported on the new OS platforms.

Given the VAST amount of code written in (what Microsoft agrees) is the most
prolific programming language in the world, breaking backwards compatability
with classic Visual Basic (with no real upgrade path) is tantamount to
breaking C++ code for Microsoft.  The only reason it didn't happen to C++ is
because the team developing Visual Studio .Net were C++ programmers and
would never stand for breaking all of their own code.

Regardless of the fact that there are more classic Visual Basic programmers
in the world than ANY other language, the C++ developers in charge of Visual
Studio .Net decided to continue the myth/religious code mantra that classic
Visual Basic was not a "real programming language".  Nevermind that it is
the core developing language of your company's largest group of developers.

These "professional" developers did not take classic Visual Basic seriously,
or Microsoft's classic Visual Basic customers.  Combine that with the
internal deadlines that they must have been under, just maybe they chose to
trash classic Visual Basic to save their own hides.

This doesn't take a psychic to figure out.....  Microsoft's Visual Studio
team took care of their own interests above the interests of their largest
developer customer base.  Visual Studio .Net is all about Microsoft.  Not
you.  Not me.  Just them.

In choosing between taking care of the customer and covering their ass and
promoting their own agenda, Microsoft cut the customers loose.

I say, while you're loose......RUN!

Jim Hubbard