I suggest you ...

12,075 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Eugene shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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.

    Paul Yuknewicz
    Group Program Manager
    Microsoft Visual Studio Cloud Tools

    9538 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Sten2005 - Microsoft support VB6 programming on Windows 10 until at least 2025 commented  ·   ·  Flag as inappropriate

        @SuperDre
        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."

      • SuperDre commented  ·   ·  Flag as inappropriate

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

      • SuperDre commented  ·   ·  Flag as inappropriate

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

      • martin rizal commented  ·   ·  Flag as inappropriate

        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.

      • martin rizal commented  ·   ·  Flag as inappropriate

        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

      • martin rizal commented  ·   ·  Flag as inappropriate

        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.

      • Olaf Schmidt commented  ·   ·  Flag as inappropriate

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

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

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

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

        Olaf Schmidt

      • Peace commented  ·   ·  Flag as inappropriate

        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 ?

      • Anonymous commented  ·   ·  Flag as inappropriate

        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?

      • martin rizal commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base