I suggest you ...

12,081 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    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

    8370 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • MIlan Oparnica commented  ·   ·  Flag as inappropriate

        And "ignorant" is "every one not thinking like me"... or "using the same tool I do"...

        Nice, and very...advanced.

      • Dean commented  ·   ·  Flag as inappropriate

        i should have said, I prefer the past for some things.... not all

        LIKE VB6

        AND

        LIKE WINDOWS 95, THE BEST OS EVER.

      • Dean commented  ·   ·  Flag as inappropriate

        "I prefer to live in the present. This entire suggestion is built upon the premise that people should not only be able, but accomodated for their desire to live in the past."

        I prefer the past, the music was better for one thing

        http://www.youtube.com/watch?v=qpJ0cyXbMbI

        I also ride a 1996 motorbike, about the time VB5 was around!

        you can keep your C# mate, glad you like it!

      • Anonymous commented  ·   ·  Flag as inappropriate

        I agree bring back Classic Visual Basic and save companies and their developer's a lot of pain..

      • Toto commented  ·   ·  Flag as inappropriate

        Do they (Microsoft) know how many VB6 applications are made in 2014 ?! it looks like at the end of 2014 there will be ~ 3000 - 4000 NEW VB6 OPEN SOURCE PROJECTS ONLINE !

      • Anonymous commented  ·   ·  Flag as inappropriate

        Maybe, just maybe people will come to realize we really do know what were doing and have solid reasons for sticking with vb6. Its simplicity and directness is perfect for a huge swath of tasks, and it integrates so nicely with winapi, com, and c. It has all the benifits of a script like language, but debugging capabilities greater than c or .net and native compile. The whole install is probably smaller than python. Visual studio these days takes GB of space. I think they forgot how to really code.

      • Eugênio Pacelli Salgado Canaan commented  ·   ·  Flag as inappropriate

        Gente que aceita criar código em um interpretador que não compila de verdade.
        Gente que aceita que seu código seja descompilável e ainda diz que isso é irrelevante.
        Gente que aceita que seu código rode *** uma camada desnecessária de abstração.
        Gente que aceita ter que começar do zero tudo de novo como se
        suas linhas de código nada valessem.
        Gente assim, ou não tinha código de valor,
        e não sabe o que é realmente um grande compilador.
        Eu fico me perguntando:
        quem realmente é o idiota aqui ?
        Será que eles sabem, realmente, o quanto deficiente,
        é o produto que estão usando e defendendo ???

        ****

        People who accept create code in an interpreter that does not compile, really.
        People who accept that your code is decompilable, and also says that it is irrelevant.
        People who accept your code to run under an unnecessary layer of abstraction.
        People who accept having to start from scratch all over again, as if
        their lines of code were worth nothing.
        People like that, or was not, code of great value,
        and do not know what is really a great compiler.
        I wonder:
        who really is the fool here?
        Did you know, really, how much, handicapped, is what you are defending?

      • Olaf Schmidt commented  ·   ·  Flag as inappropriate

        @Michael Burgwin

        > Pretty much any Modern Paradigm used in VB6 requires absolutely disgusting hacks ...

        Not true (you apparently learned about OO-patterns, only after you switched from VB6).

        > If you want to actually have any form of multithreading you better be prepared to handled
        > the fact that the Visual Basic Runtime is not re-entrant as well as the fact that if
        > anything goes wrong you bring not only your program crashing to the ground but if you
        > are running in the IDE, the IDE also dies.

        Not true. When you encountered problems with VB6-Multithreading,
        then it was entirely your fault (not using the tool properly).

        > Good example: Create an Enumerator Method. In VB.NET and C# it's dead-simple;
        > return an IEnumerable<T> and use yield return.

        Here a VB.NET example (from here: http://msdn.microsoft.com/de-de/library/dscyy5s0%28v=vs.110%29.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-3

        Sub Main()
        Dim days As New DaysOfTheWeek()
        For Each day As String In days
        Console.Write(day & " ")
        Next
        ' Output: Sun Mon Tue Wed Thu Fri Sat
        Console.ReadKey()
        End Sub
        ----------------------------------
        Private Class DaysOfTheWeek
        Implements IEnumerable

        Public days =
        New String() {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"}

        Public Iterator Function GetEnumerator() As IEnumerator _
        Implements IEnumerable.GetEnumerator

        ' Yield each day of the week.
        For i As Integer = 0 To days.Length - 1
        Yield days(i)
        Next
        End Function
        End Class

        > With Visual Basic 6?

        Well, here we go my friend:

        Sub Main()
        Dim Day, Days As New DaysOfTheWeek
        For Each Day In Days
        Debug.Print Day; " "
        Next
        End Sub
        ----------------------------------
        'into a Class, named DaysOfTheWeek
        Implements IEnumerable

        Private Days As cArrayList

        Private Sub Class_Initialize()
        Set Days = New_c.ArrayList(vbString,"Sun","Mon","Tue","Wed","Thu","Fri","Sat")
        End Sub

        Public Function NewEnum() As IUnknown
        Set NewEnum = New_c.EnumerateOn(Me, Days.Count)
        End Function

        Private Function IEnumerable_NextItem(Idx As Long)
        IEnumerable_NextItem = Days(Idx)
        End Function

        The VB6-version is in now way "less efficient".

        > First, you need to pass the hurdle of actually accessing the Interface.
        > YOu either find a Type Library with it in, or somehow define it yourself,
        > requiring knowledge of IDL to create the Type Library manually.

        You never heard about - or implmented "light-weight-COM-classes" as it seems.

        > Then you realize, Oh, "Next" is a reserved word.

        Not true for a typelib (you're free to define Next there).
        You never used Implements in VB6.

        > And VB6 has no way around that, so you have to actually implement the Next method
        > within a Module, which takes as it's first argument a Long that will be the Pointer
        > to the actual Object being enumerated.

        Wrong again, you never implemented things like that, as it seems.

        > So you need to use Kernel32 API functions to copy that 4 byte pointer into a empty
        > Object Reference before you use it. And of course there is no way to validate it at that
        > point- if the pointer isn't valid VB6 will just crash hard when you try to access it.

        I'm baffled about that uninformed non-sense you apparently gobbled up from "hear-say".

        > Just make sure that you Copy 0 into any Object References you create or the Enumerator Crashes.

        ???

        > Also Next has to be the first function in the module for you to use it to overwrite the
        > Function Call VTable of an existing instance.

        This is all a whole lot of utter bull.
        You have no clue about COM or VB6 Mr., this half-baked babbling is perhaps good enough
        to impress Newbies - but VB6-Professionals will only laugh at you.

        > A lot of stuff you get for free in VB.NET, C#, and other later languages, you have to work
        > on to get working in VB6. ...So why spend hours hacking around in memory pointers with
        > Visual Basic 6 when you can do the same thing, and much safer, with C# or VB.NET?

        Because there is no necessity for "hacking around", as my example above shows.

        > ...the user doesn’t really care that you went to all that trouble to avoid a framework
        > they probably already have installed.

        Yeah, "probably" ... in the same way as in "probably not".
        For VB6 there's a *guarantee*, that the runtime is pre-installed on any current system.

        > If somebody had contacted me 6 years ago you would have had my support, because I was an ignorant fool...

        As I see it, there was no changes at all.

        > There might be some very nice applications made with VB6. that's a testament to
        > their creators, not the capabilities of Visual Basic 6.

        Thank you very much - but no tool has "capabilities" until you use it (properly -
        and from what you wrote above, you never used VB6 properly).

        As you say, it's always the creators, the tool-wielders who make the difference.

      • Michael commented  ·   ·  Flag as inappropriate

        @Michael Burgwin

        You overestimate your importance and especially that of your blog, which is totally insignificant and unknown. From your comment it's like the world MUST know you or your blog by default. Who do you think you are ?!

        Honestly it looks like you did not master VB6 ever!

      • Eugênio Pacelli Salgado Canaan commented  ·   ·  Flag as inappropriate

        Desculpe-me, todos, tento evitar a todo custo
        que esses idolatras do dot net me magoem,
        e evito reagir à provocações descabidas,
        mas já chegou à borda da paciência
        tentar explicar que o que se requer
        é um VB6 melhorado
        justamente
        porque o framework como ele é
        não resolveu NUNCA os problemas
        de migração de milhares de aplicativos
        muito bem feitos, por gente qualificada
        GENTE CAPACITADA
        que por diversos motivos,
        todos eles residindo
        na forma com que o framework foi projetado,
        que impediram a migração segura
        de muita coisa maravilhosamente bem feita
        e que não merece ser enterrada !!!
        E não será, com ou sem a Microsoft.
        Porque quem peticiona não são os piores e medíocres,
        não mesmo !!!
        Queiram-me bem !!!

        ****

        Excuse me, everyone, I try to avoid at all costs
        that these idolaters dot net hurt me,
        and react to avoid unreasonable provocations,
        but has already reached the edge of patience
        try to explain what is required
        is an improved VB6
        precisely
        because the framework as it is
        NEVER did not solve the problems
        Migration of thousands of applications
        very well done by qualified people
        PEOPLE EMPOWERED
        who for various reasons,
        they all reside
        in the way that the framework was designed,
        that prevented safe migration
        plenty of wonderfully made
        and that does not deserve to be buried!
        And will not, with or without Microsoft.
        Because who petitions are not the worst and mediocre
        not even!
        Wish me well!

      • Eugênio Pacelli Salgado Canaan commented  ·   ·  Flag as inappropriate

        Sim, Michael Burgwin, vou tentar te explicar nosso problema:
        a gente quer um compilador, nada de frameworks,
        quem já pilotou um avião sem nenhuma tecnologia mágica em 1998
        tendo que fazer nossas próprias mágicas, e fazemos, até hoje, creia...
        não quer uma carroça com GPS em 2014.
        Ficamos até 2023 com o avião sem GPS e você fica com sua carroça com GPS,
        com OOPS, com o que quiser.
        A carroça continua sendo uma carroça.
        E carroças não voam !!!
        Abraços

        ***

        Yes, Michael Burgwin, you'll try to explain our problem:
        we want a compiler, no frameworks,
        who have flown an aircraft with no magical technology in 1998
        having to make our own magic, and do, today, believe me ...
        do not want a donkey cart with GPS in 2014.
        We stayed with the plane until 2023 without GPS and you with the donkey cart with GPS,
        OOPS, with what you want.
        The donkey cart remains a donkey cart.
        And donkey cart do not fly!
        hugs

      • Michael Burgwin commented  ·   ·  Flag as inappropriate

        Somebody spammed one of my old VB6 blog posts with a link chain that led here.

        @Marius Orion

        If you cannot see the limitations of Visual Basic 6, of the language as well as the Form design and even the IDE, than you are purposely remaining ignorant of the myriad of objectively better alternatives.

        I used Visual Basic from 2001 through to 2011. 10 Years.

        I thought it was the best language ever. I was also annoyed that there was no successor.

        It wasn't until I learned C# that I realized just how much Visual Basic 6 sucked. The language sucked. It's form design sucked. It's underlying Object model sucked. It's so-called Object Orientation sucked.

        It sucked.

        Pretty much any Modern Paradigm used in VB6 requires absolutely disgusting hacks Even those that were around at the time. If you want to actually have any form of multithreading you better be prepared to handled the fact that the Visual Basic Runtime is not re-entrant as well as the fact that if anything goes wrong you bring not only your program crashing to the ground but if you are running in the IDE, the IDE also dies. Good example: Create an Enumerator Method. In VB.NET and C# it's dead-simple; return an IEnumerable<T> and use yield return. With Visual Basic 6? well, the common way is to have an underlying Collection object and just return the Enumerator in NewEnum- naturally you have to assign that method you create the obvious special tag "-4" because nobody would ever expect you to have to do anything else to create one. But if you want to create a custom Enumeration that doesn't require you to have dumped everything into a Collection, you need to Implement IEnumVariant. First, you need to pass the hurdle of actually accessing the Interface. YOu either find a Type Library with it in, or somehow define it yourself, requiring knowledge of IDL to create the Type Library manually. Then you realize, Oh, "Next" is a reserved word. And VB6 has no way around that, so you have to actually implement the Next method within a Module, which takes as it's first argument a Long that will be the Pointer to the actual Object being enumerated. So you need to use Kernel32 API functions to copy that 4 byte pointer into a empty Object Reference before you use it. And of course there is no way to validate it at that point- if the pointer isn't valid VB6 will just crash hard when you try to access it. And don't go hovering over that in the IDE- or it'll crash when you do that, too. (Wow, I can totally see why people think VB6 is so great). Then you can access the object being enumerated. Just make sure that you Copy 0 into any Object References you create or the Enumerator Crashes. Also Next has to be the first function in the module for you to use it to overwrite the Function Call VTable of an existing instance.

        A lot of stuff you get for free in VB.NET, C#, and other later languages, you have to work on to get working in VB6. For some this can be a point of pride, but when you think about it, it doesn’t really matter if you happened to write a program in a certain language and worked around limitations to get it to work a certain way- to the user, they are all programs. So why spend hours hacking around in memory pointers with Visual Basic 6 when you can do the same thing, and much safer, with C# or VB.NET? There is no reason. Unless you want your program to run without the .NET Framework, which seems to be a common goal which seems to forget that the user doesn’t really care that you went to all that trouble to avoid a framework they probably already have installed.

        If somebody had contacted me 6 years ago you would have had my support, because I was an ignorant fool who refused to learn new things, and substantiated that refusal to move on with projection. Now that I've learned C# I see that I was wrong. Oh so wrong, about absolutely everything. When I work in VB6- It's just a constant stream of "Jesus I used to USE this? I used to think this was actually a <good> language?"

        I prefer to live in the present. This entire suggestion is built upon the premise that people should not only be able, but accomodated for their desire to live in the past.

        I like my Generics, proper OO, and Enumerator Methods. Visual Basic 6 has none of these and all you can come up with is excuses. Sure, you can get the same capabilities with a little more work. Yeah. Great. Languages are about reducing your workload, not increasing it. I'm not about to measure my e-peen by the amount of excessive workarounds I've come up with to create basic functionality in a language that has no business being used for new applications. There might be some very nice applications made with VB6. that's a testament to their creators, not the capabilities of Visual Basic 6. If somebody made art out of a ****, nobody would start praising the ****.

      • Anonymous commented  ·   ·  Flag as inappropriate

        YEs we want to continue VB6 please update VB 6 as it is we spent our full life with VB6 and now its too much hard to move on to .net

        Thanks in advance MS

      • Steve Hohensee commented  ·   ·  Flag as inappropriate

        VB6 is like a very comfortable, long-used, favorite overcoat that does a wonderful job of what I need it to do.

      • Eugênio Pacelli Salgado Canaan commented  ·   ·  Flag as inappropriate

        E para quem não sabe o que está acontecendo,
        há uma nova interface que obriga seu programa
        a ser criado em um ambiente que permite descompilação,
        e colocar seus programas em um loja que fica com 30
        por cento do total arrecadado pelas vendas.

        Ou seja, bons programas, ali, não estarão,
        programadores com margens justas de valor,
        não aceitarão essa margem financeira imposta.

        Muitos não praticam essa margem de lucro,
        para deixar algo tão exorbitante controlar seus negócios.

        A ponta do Iceberg nem apareceu direito.
        Novos tempos pela frente.

        Muito diferentes do que já vivemos.

        Provavelmente rodando VB6 em algum Linux em 2023.

        Aguardem.

        ***

        And for those who do not know what is happening,
        There is a new interface that requires your program
        to be created in an environment that allows decompilation
        and put your programs in a store that takes 30
        percent of the total collected by sales.

        Ie, good programs, there will not be,
        programmers with honest value margins,
        not accept this financial margin imposed.

        Many do not practice this profit margin,
        to let something so outrageous control their business.

        The tip of the iceberg or the right appeared.
        New times ahead.

        Very different from what we have already experienced.

        Probably running VB6 on some Linux in 2023.

        Stand by.

      Feedback and Knowledge Base