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
================== Microsoft officially adopts 'Crazy' ==================
April 2014:- "It's crazy to abandon what you built and crazy to not let what you build work on other platforms" (Satya Nadella, Build 2014)
June 2014:- "Declined" (Paul Yuknewicz, Microsoft UserVoice site)
I do not expect this answer from MS despite of the demand and the ratings come from the user of VB6 so sad, you are loosing thousands of user for this PL.
Sure, there are problems with open source too. That's why this call was for Microsoft to upgrade VB6. (As an aside, it is laughable that Paul Yuknewicz puts forward his weak reasons why VB6 can't be upgraded).
The point about open source is that it gives the possibility of a way forward. By refusing that, Microsoft just ensure that the campaign for an updated VB6 continues, whilst simultaneously reducing what little trust remains in Microsoft among developers.
But when any large software developer decides not to continue with a development tool (VB6, Silverlight, XNA, whatever - or VB.Net tomorrow) what should happen ?
A smaller organisation may sell that tool to another developer, a large organisation probably wouldn't consider it worth the paperwork.
A reputable organisation may move the software to open source to safeguard the investment of it's customers, a large bureaucratic organisation may not even consider that.
In reality, of course, the position today is no different to what it was yesterday. The VB6 programming language is supported until 'at least' 2024. That is likely to be extended. And as long as Windows uses the Windows api VB6 is likely to keep going.
With this decision, Microsoft has sent a clear message to developers throughout the world "Do not use Microsoft developer tools. You simply cannot trust Microsoft to protect your investment."
@Sten2005: the article is actually bogus, as there is no way you can really test proprietary software compared to opensource.. Let's not forget who wrote the article...
And just as you cannot trust MS to keep supporting your favorite development tool, there certainly isn't any other company you CAN trust or any opensource project you can trust..
@Martin rizal: that's total BS, open source isn't any better than closed source.. Especially the forking can be a big problem, and A LOT of open source projects just die... It's great if a project is open source because there is a possibility you can continue development yourself, BUT most businesses don't have the capacity nor the knowhow to continue development on their own (yes it's great if you want to fix a bug or two, but adding completely new functionalities like 64bit compilers requires a special knowledge).
And as I said yes it's great you can fork, but the problem is that you have to be carefull to 'follow' that fork and what's to say that fork doesn't die like soooo many forks have before..
Opensource is great for an 'amateur' project, but not for big businesses..
And saying to a developer to stop updating your system/toolkit and forget MS technologies is stupid ofcourse, you clearly aren't a professional developer who has a lot of clients..
And at the moment there also isn't any real 'opensource' development framework that is really future proof.. There is no opensource framework/runtime I've heard of that actually runs on about any Windows (from 95 and up) or any version of linux (from an old early version up till the latest), one of the only runtimes that actually works an most windows IS the vb6 runtime, **** even .NET requires newer versions (1.0 isn't even supported anymore)..
And for MS opensourcing VB6, I think the problem is really with opensourcing it, but with the technology being used which propably has been licensed or patented, which makes it a bit harder to just opensource it..
By the way these the Microsoft biggest mistakes:
* Dropping Visual Basic 6.0
* Increasing system requirements
* Removing Start Menu
There is no question why PC industry is falling. Microsoft was blame for this situation.
You are experiencing the effect of using the closed-source software or technologies.
If the VB6 is open source then the developers will fork to continue the existence. For example, when the KDE migrated version 4 from version 3, the group of developers fork the KDE 3 and the Trinity Desktop is born.
Since VB6 is closed-sourced, its now fading to end unlike open-source that the support and maintenance will continue until no longer use or becoming obsolete.
Its now time to swiitch to open source. Time for a change
All VB6 Developers, Leave Microsoft now. Stop any updating your systems and toolkits. Forgot Microsoft technologies. Time to leave to now and build our future of computing for your companies and your career.
Though Paul Yuknewicz has probably taken this decision himself, the implications of the decision are far above his pay grade.
The message to developers throughout the world is now clear - do not use Microsoft developer tools. You simply cannot trust Microsoft to protect your investment.
Why open source development is getting more secure:
Thank you for finally declining this stupid idea.
VB6 Fire commented
Paul Yuknewicz, have you no shame ?
This decision on VB6 doesn't give much hope to those wanting further development of XNA or Silverlight.
Thank you Olaf, a good critique of Paul Yuknewicz's attempt to excuse his half-witted decision.
He still seems to think that VB6 developers will "incrementally move forward to .Net". Does he not realize that if we haven't done it over the last 12 years we won't be doing it now.
Miquel Matas commented
Please, Google "Paul Yuknewicz" to see who's that.
Olaf Schmidt commented
Well, didn't expect anything else and am not surprised. What leaves a sour
taste, is the smoke-grenades and evasive maneuvers we got as an "explanation".
So whilst reading my comments to Paul Yuknewicz, keep in mind that the VB6-sources
are written in C++ and its functionality a subset of C++ goodies - but in an easier
to use manner, hiding the gory details of COM.
So, VB6 is basically a high-level-layer "on top of C++ in COM-Mode" - and COM is
state-of-the-art-tech again (with the new WinRT-libs, which are COM-based too).
C++ is *the* 1st-class citizen in this new unmanaged WinRT/COM-world - and
no .NET assemblies are needed at all, to write the so called "modern Apps"
with C++, WinRT and XAML.
So, unmanaged C++ is the top-consumer for the new MS-tech - the "WinRT-projection"
(the library-binding to the new Windows-Runtime) for C++ is ready - and could easily
be re-used by *any* language which emits C++ code in its intermediate compile-step.
And VB6 is such a language! The *native* VB6-compiler emits intermediate C++ code,
which gets finally compiled to machine-instructions by C2.exe, a somewhat leaner
derivate of the (version 6) MS-C++ compiler.
So, what would have to be done technically, to "lift up" the already C++ emitting
VB6-sources to the current tech-level is a WinRT-binding, along with an integration
into the latest VS-C++ IDE (basically an AddIn, which shows VB6-sources in the Editor
and triggers the existing VB6-C++ emitter... Not exactly rocket-science if you ask me.
Ok, that said, I can keep my direct comments pretty short:
> Current needs ranging from distributed applications and services,
Perfectly possible with VB6 even today - and COM+ is still a #1-citizen in the
> to web applications and services,
*Writing* Web-Apps (serverside code) was never a domain of C++, please see VB6
as the thin convenience-layer atop of C++ as it always was...
*Accessing* WebApps (WebServices) is handled over http-, XML- and JSON-libs -
perfectly possible (and often used) by C++ and VB6 as well...
>... We looked at how we could accommodate these needs through incremental changes
> to VB6 while maintaining its essence, and that was not possible.
Not true. C++ is still a first class citizen - and VB6 always was only a
convenience-layer on top of it, using the same unmanaged compiler in the end.
> To address the modern needs we would need to go far beyond updating the language.
Sorry, but no larger language-updates would be needed - and as for your "far beyond",
I think that I made already clear, that a completely satisfying result could have
been provided, by simply offering for VB6, what was offered for C++:
A WinRT/XAML projection (re-using the already existing C++ bindings for that).
VB6(C2.exe) emits C++ code and produces COM-ABI compatible Class-assemblies.
> Take a change like 64bit, the complete runtime, tools and ecosystem chain would
> need to be retooled.
Now you're really kidding us, because a recompile of existing C++ sources to 64Bit-
targets is not rocket-science at all.
The vbRuntime is pretty small - and very portable - there was even a 64Bit version
for the 64Bit-DEC-Alpha-CPU (WinNT-era).
And "the ecosystem" of VB6 is COM - so there's nothing which requires a "retooling".
> So, moving forward what can we do?
As already stated - you could just have offered the compilation of VB6 sources over
an Addin for the C++ IDE - the original VB6-C++ codebase offers the C++ emitter
already - the VB6-runtime-lib exists as portable C++ source - the VBA-based runtime-
parts as well.
> In summary, VB6 was awesome. We agree.
Yep - it still is.
> It is not a viable option to create a next version of VB6.
That much is clear and I have no real problem with that decision - my replies only
try to underline, that the alleged "obstacles" you brought so far, aren't the real
reasons - it's clearly a political decision that's made, to not cannibalize the
> It is not feasible to open source VB6 tools chain and ecosystem.
Sure, because after the opening, a 64Bit compile would have popped up only a few
weeks later - followed a few months later by a plugin for the C++ IDE, re-using
the C++ WinRT-binding... and the newest C++/Cx compiler to translate the emitted
> I hope you feel we’ve listened to your feedback and that I’ve explained things
> well enough that you understand our decision.
Thanks for your feedback - although it came very late. The decision is exactly as
expected, no disappointment here - though your explanations for the reasons were
lacking some logic, not considering that we always just wanted a "somewhat easier
to use C++", unmanaged native compilation, no Garbage-Collector - instead we wanted
good old RefCounting and the easy COM-access/COM-lib-generation, along with easy
access to the COM-ABI providing system-libs.
Paul, this scandal will reflect badly on your name. Please put this idea on review, it will make many many people happy! We can provide active development for the new VB6 compiler for FREEEEEEEEEEE, what do you want more than that ?
Isn't open-sourcing something the same as washing your hands of it?
If something is worthless as Microsoft are implying vb6 is how can it be 'not feasible' to open source it?
In MS VB6 last only until 2024, in React OS or Open Source Community, VB6 last forever. Lets help the ReactOS developers to make VB6 run smoothly and flawlessly on that OS. Push this app >>> http://community.reactos.org
If you dont want to switch OS or Reversed Engineer the VB6. Help the author of GAMBAS (a VB6 clone, http://gambas.sourceforge.net/en/main.html) to add support on windows (GAMBAS is currently run on Linux but there is also an attempt to run it windows).
Its now time to leave MS, Windows, and the Visual Studio. Just like the symbian developers did to nokia.They walked out from their office after the announcement that nokia was dropped symbian OS.
Lets move and help the open source community especially the React OS, GAMBAS, WINE, and other VB6-clones and attempts.
Its now time to choose our destiny.