473,549 Members | 2,556 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Microsoft MVPs Say They Want Old VB Back

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


Rules of Conduct
<URL:http://www.microsoft.c om/communities/conduct/default.mspx#EC AA>

Demonstrate that you are able to learn from your mistakes.

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

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


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


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


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


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


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

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

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

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

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

Patient: Doctor, it hurts when I do this.

Doctor: Well don't do that.

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

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

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

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

Stephany

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

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


Re-read my post:

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


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


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


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


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

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

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

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

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

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


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

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

Nov 21 '05 #34
Stephany,

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

These are problems with Windows XP - not with VB6!


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


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


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


1.500 signatories disagree with you :-)

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

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


There are missing arguments in your post...

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

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

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

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

"Ray Cassick (Home)" <rc************ @enterprocity.c om> wrote in message
news:eU******** *****@TK2MSFTNG P15.phx.gbl...
UGH!

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

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

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

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

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

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

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

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

For those who are interested in signing the petition:

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

http://classicvb.org/

List of signatures:

http://classicvb.org/petition/

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



Nov 21 '05 #37
"news" <ne**@ms.com> schrieb:
The ones who aren't willing to change. VB6 will be gone when VS2005 is out
this summer, period.


I don't see any indications for that.

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

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


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

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

Nov 21 '05 #39

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

<snip...>

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

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

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

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

Nov 21 '05 #40

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
2248
by: Jim Hubbard | last post by:
http://www.eweek.com/article2/0,1759,1774642,00.asp
4
1453
by: clintonG | last post by:
To all Microsoft partners and customers who have been unable to download recently or access ASP.NET documentation from the msdn2 website and for all of those customers who have been lied to and misled by some of the sleazy MVPs and the lying cockroaches that Microsoft has working for the company... Microsoft has serious problems with their...
0
7526
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7965
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7483
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
7817
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6051
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5375
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5092
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
1
1063
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
771
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.