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
Bzzzzt, wrong. Ctrl.Arrow moves control to the next grid line. WAY too far for fine tuning.
Also, Access has things like Size to Widest, Sze to Tallest etc.
If you don't like datbound controls, don't use them. But millions of others besides you find this useful
Eugênio Pacelli Salgado Canaan commented
SuperDre, Milan Oparnica, Jonathan West
Obrigado pela diversão, alegraram minha tarde chuvosa. KKKKKKKK
Gentlemans, thanks for the fun KKKKKK
Realy, pride... Pride is the real thing.
Nothing else, nothing more.
"Access has superior form editing. For example I can hit Ctrl-Arrow to nudge the controls 1 pixel at a time"
uhh, didn't know that wasn't possible in VB6, I've been doing that for years..
And I'm not particular fond of databound controls, there is always something slow and tacky with them.. Hated them in VB6 and still do in VB.NET.. I'd rather code some extra than needing to rely on databound controls..
MIlan Oparnica commented
Pride could be the only reason for ignoring this thread and overall appeal of VB6 community.
We know, and Visual Studio team knows that improving VB6 is not such a tremendous task after all, but nothing can be as dumb as an over-payed engineer obsessed by pride.
"Sorry seams to be the hardest word."
Jonathan West commented
The mistake Microsoft made was not to realise that a new platform does not require the wholesale replacement of languages which compiled to the old platform.
Just imagine how difficult and expensive it would have been to rewrite Windows itself had Microsoft made the new .NET-compatible version of C++ as incompatible with old code as they did with the VB6 to VB.NET transition.
High-level languages exist in part for the specific purpose of insulating the programmer from changes in platform. This basic fact of computer science was forgotten by Microsoft, perhaps in part because *they* didn't have much code of their own written in VB6.
But you might notice that they avoided compounding their error with regard to VBA. At one point Microsoft seriously contemplated dropping VBA from Office and replacing it with some sort of embedded .NET-based language. At the time I spoke to a person who has heavily involved in the project, and I told him that it was an excellent decision if he wanted to be forever tagged as the person responsible for throwing away a third of Microsoft's revenue.
He didn't get it until I explained in detail what would happen. There's a *lot* of VBA code in use, in a large number of very big companies. Complex Excel workbooks in financial institutions, Access workgroup databases, Access front ends to larger databases, Word templates with VBA code for automation. I pointed out that I, as a single developer had tens of thousands of users dependent on VBA code running the Word, Excel and PowerPoint templates I had created for a number of companies. Multiply that by all the people coding VBA in different companies and their users.
I explained that if VBA goes, then no company will be able to move to a new version of Office that lacks VBA until all their VBA code has been replaced with something that will work on the replacement platform. For most companies, the existing version of Office is "good enough" and they will stick with it rather than spend a lot of money rewriting their code to get back to where they started but with a new version of Office.
And if they don't spend their money on a new version of Office, Microsoft isn't going to make money on a new version of Office. I told him that the person responsible for the decision to drop VBA will be the person blamed for the resulting loss of revenue. I heard the gulp down the telephone line as the the implications of this finally sank in.
VBA is still here. Microsoft made a mistake not making people's existing VB6 code compatible with the new languages, and it has cost them. But they drew back from the even bigger mistake of doing the same with VBA.
The VBA editor hasn't been updated since, so Microsoft's commitment to VBA can hardly be regarded as unstinting, but the platform is still there and has been included in the new 64-bit versions of Office 2010 and Office 2013.
So it wouldn't be all that hard to bring out a standalone version that could offer an upgrade path for VB6 code. I doubt that they will do it though. Too much pride at stake.
Re multi-threading. I do it all the time in VB6
It's true you can't have a multi-threaded VB6 EXE. However you can build a multi-threaded *solution*.
Create another ActiveX EXE server and connect it through callbacks. This gives you another asynchronous thread.
I have many production apps running to this day using this technique
I've been a VBer since day 1. I learned basic in school on the Commodore PET. Been in IT for 25 years and developed for major financial/insurance firms in Toronto.
Here's what MSFT should do - merge VB6 and Office/VBA (especially Access) to produce an ultimate development platform, as an alternative to .NET
-Office products already contain VBA anyway so it wouldn't be a big stretch to do this.
-VB6 doesn't support Unicode for internationalization but Access does. So replace VB forms with Access forms and controls
-Access has superior form editing. For example I can hit Ctrl-Arrow to nudge the controls 1 pixel at a time
-You'd have data-bound controls natively without cumbersome database coding
-Access has a beautiful and powerful report engine to replace Crystal which I never liked anyway
-But allow compiling to standalone EXEs rather than the Access runtime engine
This would be the ultimate, VB6 back in action and improved with the features and functionality already present in Access
You will never learn! Visual Studio team will waste a few more years and after that a smarter Visual Studio team will bring back Visual Basic 6.0.
I do not understand how you can be so blind! Like you intentionally sabotage Microsoft ! For now, Visual Studio team spends money on VB.NET without any results and any feedback from us.
Miquel Matas commented
They can ammend this yet.
Microsoft: make it Open Source or improve it.
Microsoft may be sabotaged through very bad decisions, VB6 case is a good example.
MIlan Oparnica commented
Somebody earlier "joked" about ReactOS. It's still under heavy development, but there is one post I would like to share. It gives a (somewhat) interesting point on MS killing it's developing tools.
"...So the people or group that will likely suffer the greatest long term harm is not the developers that had their tools deprecated, but Microsoft itself..."
You can read the whole thing on http://www.reactos.org/node/638
VB6 Fire commented
It is not so, VB6 = new VB6 :). But thanks for the support :)
XNA 7.0 commented
.Net Native + Basic.NET = VB6.0, i think so, but not sure)
XNA 7.0 commented
.Net Native + Basic.NET = VB6.0, i think so, but not sure)
I've invested 20 years in coding in this language, why would you let me retain my skills?
VB6 was, and is, the BEST! Bring it back! Enhanced, faster and as a standalone EXE generator (much like C).
Happy birthday BASIC!!!
And yes, it's time for Microsoft to celebrate 50 years of BASIC with a new release of Visual Basic 6.0 !
Yesssssssssss! Long live Basic (and especially Visual Basic 6.0 who carried the tradition until today as #1 among all programming languages)
The BASIC programming language is 50 years old this month.
It makes VB6 (a mere 16 year old) look like a young whippersnapper !
It's time for Microsoft to celebrate with a new release of VB6.