Bring back Classic Visual Basic, an improved version of VB6
The silent majority of VB6 users did not ask for changes that came with .NET
We request Microsoft brings back classic Visual Basic as COM development is back with Windows 8.
David Platt wrote an excellent article about why classic VB still thrives:
We have read all of the comments on this thread and I’d like to thank you for providing your constructive feedback on this issue. Instead of merely repeating our support and migration guidance that has been laid out on http://msdn.com/vbrun, I’d like to address some of your specific comments here.
To play back the feedback themes we’re hearing:
- VB6 is awesome
- VB6 needs to be brought forward and maintained: in a new release or OSS
VB6 was and still is without a doubt awesome. VB6 made developers incredibly productive building a breadth of applications and as a result we have a wealth of applications and passionate developers to this day in 2014. One way I see our mission in developer tools is to empower developers to solve problems. This includes both today’s problems AND the problems of tomorrow. VB6, as you all have stated repeatedly in this thread, is an excellent tool for solving the problems of its day. We also stand behind our decision starting in 2002 to meet the current demands of our developers and the industry with .NET. For the scenarios VB6 set out to do, we see VB6 being “complete”. We feel good about VB6 being able to continue maintaining their applications for the past 15 years. Current needs ranging from distributed applications and services, to web applications and services, to devices, to new architectures and languages, required fundamental changes to the whole stack. We looked at how we could accommodate these needs through incremental changes to VB6 while maintaining its essence, and that was not possible.
To address the modern needs we would need to go far beyond updating the language. We have to remember that VB6 is not just a language. VB6 is a language, a runtime, a platform library, a tool/IDE, and an ecosystem tightly packaged together in a way that made all of them work well together. We’ve worked with many customers on migration from VB6 to .NET and found that while yes, there are language changes, the dominating factor in migration difficulties isn’t the language differences. Even open sourcing the language/runtime wouldn’t solve the fact that VB6 was thought for a different set of problems, and the fact that its strength came from the end-to-end solution provided by all these five pieces working together. Take a change like 64bit, the complete runtime, tools and ecosystem chain would need to be retooled.
So, moving forward what can we do? Where we have been able to help move forward is in our stance around support and interoperability. The VB6 runtime it is still a component of the Windows operating system and is a component shipped in Windows 8.1. It will be supported at least through 2024. This ensures your apps and components continue to run as you incrementally move forward to .NET. The support policy is here: http://msdn.microsoft.com/en-us/vstudio/ms788708. There are numerous interop strategies that we developed and evolved to enable incremental migration as you upgrade your skills, described here: http://msdn.com/vbrun.
In summary, VB6 was awesome. We agree. We don’t expect or demand anyone to throw away their code or rewrite from any of our technologies unless it makes business sense for them to do so. We have to innovate to enable our customers to innovate. It is not a viable option to create a next version of VB6. We stand by our decision to make VB.NET and the .NET Framework. We think they are awesome too. It is not feasible to open source VB6 tools chain and ecosystem. The VB6 runtime was last shipped in Windows 8.1 and will be supported for the lifetime of Windows 8.1. Support and interop are great tools to move forward incrementally.
I hope you feel we’ve listened to your feedback and that I’ve explained things well enough that you understand our decision.
Group Program Manager
Microsoft Visual Studio Cloud Tools
Every now and then, a hype-fed troll storms into this thread flaming against VB6 and "the bad habits" it engenders, atc.
Most of our replies are just reactions to such dumb, ignorance driven attacks.
VB.Net may be a fine language, and its users deserve all respect. But it is not compatible with VB6, nor is there any reliable tool that solves the incompatibility.
And the "internal" incompatibility is just a part of the problem. My systems rely on VBS for user developed extensions. VB.Net 2002 was 100% compatible with VBS (probably because the runtime automatically provided a COM wrapper for objects), but when I tested with 2008, not even classes explicitly requiring COM interoperability worked properly with VBS.
So, even if I "migrated" my systems to VB.Net, there are thousands of customer written extensions that would stop working.
Maybe MS believes they can break their customers applications and get away with it.
@all : I don't understand this topic anymore. Like I mentioned before, I switched from vb6 to vb.net 2012 (first 2010) and now I'm perfectly happy with it. My colleague is an expert in VB6 and he is happy with his tool (and I’m happy he will stay with vb6 as all program-edits for vb6 is going his way ;-)
If vb6 is returning it could be better, faster, easier … and if so I will switch back, be sure. I’m just using a tool to get our customers what they want in a time as short as possible…like I do for almost 40 years now. I find out there is no better language, there is only ‘a right tool’ to get the job done as fast as possible.
So if one uses a claw hammer or a sledge hammer : the customer only wants the nail in the wood, and please, we are all programmers, so don’t yell at another he isn’t capable of doing it right, as it is quite possible he is asking for the right tool to do that specific job…
@Andrew: What bad habits? the only bad habits I see is because of the developer themselves, and I still see the same bad habits in vb.net...
Also vb.net isn't dificult to learn, it just doesn't really add anything to the stuff I need.. I also do projects in vb.net, but I just don't think it's better as VB6.. I'm still using vb6 on a daily basis due to the projects that have been around for 14 years, and still I can add all the needed functionalities to keep it 'modern'..
And any developer who ******* about vb6 and bad habits are just saying they are bad developers themselves as it it you who it doing the bad habits, not the language. But then again, I don't rely that much on the IDE to keep my code nice and tidy, and I see a lot of developers using .NET do.
Just now I see a lot of collegues here using C# and declaring everyting using 'var' which IMHO is almost the same as having 'option explicit' off in vb6 (with one difference, that 'var' in C# compiles to a correct type and v6 just uses variants).. I see stuff like that in even more other languages these days, developers getting lazy (IMHO only use var when it really is necessary)..
One of the only things at the moment I hate about vb6 is the limit on differently named variables in one project (yep, I'm sadly hitting that limit)..
According to the criteria used by TIOBE to distinguish between Classic VB and VB.Net, it is very likely that much activity actually related to VB.Net is being counted under "(Visual) Basic".
Anyway, it is clear that Classic VB is still being widely used, and it will continue to be used until either MS finally removes support for the runtime in some future OS version (which will be doomed to failure) or provides a 100% automatic and reliable migration tool for Classic VB projects (which is even less likely, and way ******, than a revival of Classic VB).
They are still working on VBA, which is a core component of Office. COM is still the standard mechanism for application interoperability.
If they don't bring back Classic VB, which can be gratly enhanced without lots of effort, is either because the are stupid or downright evil.
Cars, in the hands of careless drivers, kill thousands of people every day all over the world. Yet, that is not a reason to ban them.
VB.Net, in the hands of the archaetypal VB6 programmer ("Mort") may be used to produce code as stinky as the stinkiest code ever written in VB6.
All the flaws that you point in VB6 were what many of us had to overcome in order to produce code of such clearness and quality that you probably could not just imagine (considering how prejudice ridden your mind seems to be).
It is not that most of us find VB.Net too difficult to understand (I have used it for some unrelated project; I am also fluent with C, Pascal, Object Pascal, C#, Java, PHP and ECMAScript); the proble is that it is not compatible with a code base of the highest possible quality, with a volume of several hundreds of thousands of line of code, perfectly functional, from which we make our living.
We can't see the practical reason why we should migrate our code. And there are very strong financial reasons to keep our current code base as it is. Our only threat is MS doing their best in order to push us out of the market, for reasons which I just can't understand.
If you don't like VB6, don't use it. But please, be smart enough to show respect for people that clearly deserve it.
Well, the TIOBE Index kind of prooves you wrong. Also - at least for me - it's not about the difficulty of the language and/or framework (I do frequently use .NET) but about coding efficiency and compatiblity across a wide range of windows plattforms. I also fail to see why a newer VB classic version would not be able to prvoide better error handling.
Please let VB6 and the bad habits it engenders die.
For every one of you that wants it to live because VB.NET is too difficult to understand there are dozens that feel the opposite.
I personally prefer VB.NET over C#, but VB6 is rife with inconsistencies and horrendous error handling models. These breed bad habits, and increases costs to maintain the apps.
Mark Anderson commented
Likewise we still use VB6 on a day to day basis. Yes a number of apps are in .Net but the majority are still VB6 and we build new VB6 apps regularly. It is a great platform.
We would love to see this back in vogue as far as MS is concerned because clearly it is still so in the community. Why replace something that isn't broken ?
I still use VB6 daily in 2013!. just released a major project written in VB6.
.Net is over complicated, SLOW, small things that is easy to accomplish in VB6 takes HOURS in .net. .NET was not created for the masses, just a handfull of elite people. What made Microsoft so strong in the 90's was Visual Basic's rapid application development with non-complicated code. To put it in easy words: I want to write code for my app, not create a app that will run a shuttle!
I must also add we have slowly converted our windows apps to php/java over the last few years. Microsoft made it near impossible to write applications at the same speed as VB6. So we are now 90%+ converted to Linux.
Well vb6 was abandoned by M$ over ten years ago, and yet it is stil the 7th most used programing language in the world according to TIOBE Index:
It is within 1.5% of c# and is more used almost 4X over vb.net.
Come on Microsoft can't you see the black and white. Stop trying to be JAVA, just be vb6 and increase profits/usage/market share!
@mjohn: sadly the petition doesn't work (even if I enter every field it still says I didn't enter a required field).
There is a petition website for vb6 here http://classicvb.org/petition/
Copied and pasted the text into a petition: http://www.change.org/petitions/microsoft-bring-back-classic-visual-basic-and-improve-it-for-64-bits
James A Gant commented
I used MS Basic from CP/M to DOS to Windows. The big notable changes were from VB/DOS to Windows VB3, and VB4 32 bit. I used VB3 for 16 bit, and waited for VB5 for 32 bit applications. I looked forward to each version.
I understand the OOP "like" versions 4 to 6 were not as OOP complete as Delphi or C++, but from project idea to deployed, useable applications, always occurs much faster with VB6. My latest database application was installed on a new computer with Windows 7 with no changes and no problems.
The VB6 IDE is a delight to use, simple and fast. Several third party enhancements made it even better. The VbAdvance Add-in allowed the generation of true win32 DLL and Console programs. These are features that Microsoft should have provided.
At first I was excited about the features of VB.Net, but it is not Visual Basic. Whether you use C# or VB.Net, you are a Dot Net programmer, because most of the work is determining which framework Classes to use. The .Net IDE is too slow. MS should provide a light version.
Having a new Visual Basic COM version, with the language enhancements of VB.Net, is probably wishful thinking. But as demonstrated here, MS would sell many copies. I wonder what the stock holders think of MS not taking advantage of a new income stream.
Please bring it back or release to open source.
MIlan Oparnica commented
Back in 90-ies I founded a software company aiming at business market and after thorough consideration it was the VB6 we set as development choice. We knew Pascal (Delphi) and C++ better, but VB6 still overtook them. It was the right tool for that task. It still seems to be.
We built everything on COM/COM+ (later). It works perfectly even now (in WOW64, duh).
After Microsoft announced its end-of-life, we tried to use .Net, even did some migrations, but it was not worth it. New tools look fine and feel great but they didn't bring any benefit that could overvote our main value - debuged business procedures. We are not ready to give that away.
So we went back to VB6/COM. VM's, Wine/Linux, Java/COM all became a part of our work environment where MS was 100% dominating just couple years ago.
It's a huge mistake if you ask me. We became open to other platforms, and its not the development tools only. Now we adopt other applications and services out of MS ecosystem too. And we share it with our clients too. Thanks to their decision we discovered whole new world of tools, applications and services and are not afraid to suggest and sell them in production any more.
I don't expect anything from MS, but it would be nice to have this simple but powerful language updated again. Specially having in mind that WinRT might be closer to native COM than .Net. (if RT has any future at all).
Improving COM+ "as web services" through IIS and SOAP would also be a good idea. It was there until Windows Server 2008 and 2012...
Trying to connect .NET to a modern Oracle database IS A HUGE DEBACLE. H-U-G-E! I am very familiar with the Oracle support tools (and MS support software) at this point. Very familiar with .NET connection methods in 2010 and 2012. Compared to VB6, PHP or even Java; the amount of time required get a client connection\system working and maintained is staggering.
In VB6 it works consistently on all Windows systems and deploying VB6 apps is a breeze.
I am a long time VB developer. VB6 meets the needs of 99% my development. If you would please just update VB6 for current OS versions (64-bit compiler), interface controls and database access and that will do.
Much\most of .NET missed the boat. We don't want to install the .Net (or Java) runtimes all over the place. Just one install suite of .DLLs. Ideally compile to a single .exe! SIMPLE = MATURE.
Thanks for listening and acting on it. If you can't, just release VB6 as open source and we'll take it from there.
Francisco Pifano commented
I stumbbled upon this while looking for some VB6 help on the web, and OMG! I am so very happy to see so much enthusiasm on pressing MS to bring back VB to live! I´ve been a developer for more than 20 years now, and ever since I wrote my first lines on VB I have not used other tool for both front end and back end developments. From pre-Internet times up until now, VB has been incredibly flexible to every single need we have come to meet, and it has always came out strong on delivering all necessary tools to conquer all obstacles. Once I was told I was resisting change, I do not agree. We have changed along with VB all this time, and will continue for many years to come.