I suggest you ...

12,081 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

    8754 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • VB6 Programming commented  ·   ·  Flag as inappropriate

        I see the petition at:
        http://classicvb.org/petition
        still isn't working.
        It displays the message "Unable to save your details. Please ensure all required fields are filled in." even when all fields are filled in.

        Does anyone have any contact details for the petition organisers ?

      • VB6 Programming commented  ·   ·  Flag as inappropriate

        @Leonardo. Yes, what many VB.Net programmers don't seem to realise is that we are not arguing for VB6 instead of VB.Net but as well as.
        Let those who want to use VB.Net use it and let those of us who want to use (an updated) VB6 use that.
        As you say, Microsoft shouldn't have removed VB6 without a proper replacement.

      • Anonymous commented  ·   ·  Flag as inappropriate

        VB6 was the most productive language MS created; it’s re-support would send a much needed message that MS cares about productivity and it’s users.(but after Vista, Win8, the ruin of Access’s menus and a hundred other preposterous acts this is clearly a forlorn hope. I’ve since gone on to PHP, MYSQL and Linux for servers; lucky me I had the foresight to see .NET, Silverlight & the rest for the **** they are early on. And I’ll tell you folks that same foresight says MS won’t change it’s ways till they’re in the same spot Blackberry is now. There’s nothing here but wasted time.)

      • Anonymous commented  ·   ·  Flag as inappropriate

        They might argue, and not with a total lack of reason, that in most modern organizations tha ability to adapt to changing conditions is more important than program performance.

        Programmers are most productive in whatever language they know best.

        VB.Net is a finest language, but it is not compatible with VB6, therefore it is not a replacement for VB6. They shouldn't have removed VB6 without providing a proper replacement, i.e. a tool able to receive VB6 projects and produce code at least as correct and efficient as what VB6 compiler produces. And that "migration assistant" is a sad joke.

      • Xavier commented  ·   ·  Flag as inappropriate

        I don't know of any official and independent studies that would back my claim, but, speaking from personal experience among friends who started working with VB6, I'd say 70-75% are extremely pleased having moved to VB.NET.

        The other 30-25% have moved to c#, mainly because of the overwhelming community support that exists for it and, up to some point, they aren't "that different".

        I still believe the problem is a matter of mindset.
        You cannot "move" to VB.NET expecting to work then way you did with VB6.

        The same would apply if you moved to RealBASIC (or whatever name it has now), or PowerBASIC or any other old or modern BASIC-flavored language.

      • Anonymous commented  ·   ·  Flag as inappropriate

        May I jump in here hard on the side of L. Ofaday: VB6 is a fine tool that allows for tremendous productivity; . NET is, to me, a nightmare I long since abandoned. Why MS can’s see this in the number of users who have fled it’s language offerings is odd.

      • VB6 Programming commented  ·   ·  Flag as inappropriate

        @Winston, Yes it's interesting how the move to .Net increased productivity (at least with C#, less successfully with VB.net) but at a reduction in performance. With VB6 we had (& still have) both the productivity of a RAD and the performance of C.

        It is interesting too that Microsoft haven't responded to this thread.

      • axisdj commented  ·   ·  Flag as inappropriate

        @Steve, Great video link, thanks for sharing... I loved how in the video he avoided the period of VB6 success. In essence vb6 ads the speed of development that .net promises and the native compilation and efficiency of c++.

        I hope Microsoft at least gives a reply to this idea SOON, or at least acknowledge the issue and opens a public dialog so we can move forward with this.

      • VB6 Programming commented  ·   ·  Flag as inappropriate

        An interesting video from the excellent Herb Sutter about the importance of performance in programming languages, particularly the move back from C# to C and C++.

        http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

        Herb refers to the 'lost decade' when the importance of application performance was largely forgotten in the move to managed languages. And how this is now being re-discovered with a move back to C and C++.

        Of course VB6 developers never forgot about performance, but it is nice to see others recognising this too.

      • Dean commented  ·   ·  Flag as inappropriate

        @Leonardo

        Yes I think we can both agree VB6 could handle errors "well enough" and error handling is not a reason to downgrade to .Net :D

        In the article linked to in the OP David Platt complains about On Error Resume Next, but actually I find that to be a useful technique in certain circumstances and I don't think it was ever meant to be used in the way he suggested... i.e. if we get a REAL error at runtime just ignore it.

        One use is if you execute something and it fails and it simply doesn't matter if it fails or not you can just carry on and deal with it using one line of code... On error resume next. I like VB6 and I like on error resume next. I don't mind Goto either, with labels... not a problem for me at all... just a JUMP statement isn't it... all this crying about gotos boo hoo...

        someone needs to provide a peer reviewed study, rigourous mathematical proof or comprehensive field reports to persuade me of anything not just some half assed rhetoric "opinion" i.e. hot air BS or the one who gets the last word in wins.

        I never argue... you are either right or wrong, and if no-one can prove it either way it's a waste of time talking

      • VB6 Programming commented  ·   ·  Flag as inappropriate

        I see this vote considers that Microsoft is losing the war for developers.

        http://www.zdnet.com/debate/is-microsoft-winning-or-losing-the-war-for-developers/10122538/

        Not surprising considering how they have treated VB6 and Silverlight developers.

        If Microsoft aren't willing to continue with VB6 and Silverlight they should make them open source.

        It seems Microsoft's strategy is now Javascript and HTML5. But I don't see how they can make money that way.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Hi, Dean

        There's no way to properly nest code in this messages.

        C, in fact, had a worst error handling mechanism: most of the library functions just failed and returned garbage without any warning, so if you don't check and validate the return values, you are lost.

        In VB6, every error, be it an overflow, a division by zero, a missing file, a wrong index, a bad argument, and so on and on, raises an error.

        I use local error checking if there is a chance that the condition might be fixed within the procedure, otherwise, I just let the error bubble up to wherever the error handling might be (or the program breaks with a scary warning, which is a fair punishment for such a careless coding).

        I don't consider myself careless, but if I can use a mechanism that allows me to write code without caring about exceptions (because I know that the segment I am working with is protected by a higher level error handler) then I go for it.

        Any way, let's just agree to disagree. We are on the same team :-)

      • Dean commented  ·   ·  Flag as inappropriate

        @Leonardo

        I think we can agree to disagree, and would recommend anyone who wants to build a robust system use the technique of passing success/fail or error codes back from functions.

        to back this up, one of many quotes from my first programming book, The C Programming Language (Kernighan & Ritchie) section 7.6:

        "any serious program should take care to return sensible, useful status values"

        that's from the guy who wrote the C programming language and co-designed Unix, so I'll take that advice over anyone else

        VB6 allows for robust error handling and that is the important point.

        I don't have any problems with "ugly" nesting, perhaps if you used indentation the code would look less complicated ;)

      • Anonymous commented  ·   ·  Flag as inappropriate

        The only real problem with VB6 error handling are the bad practices recommended by much of the literature about the language. And those bad practices, dressed in the new fashion of Try/Catch/Finally has made its way into VB.Net as well.

        The recommended way to handled errors, niecely summed in Dean's post, just sucks. It requires that the programmer keeps in mind error handling after each function call, and leads to a very ugly nesting of conditionals in long operations (of the type that is usually found in "controller" functions):

        If a() = SUCCESS Then
        If b() = SUCCESS Then
        If c() = SUCCESS Then
        r = SUCCESS
        Else
        ErrC
        End If
        Else
        ErrB
        End If
        Else
        ErrA
        End If

        It is just a simple function, yet it is terribly ugly. If you just let errors pop up to the controller level, you would write:

        On Error GoTo ErrHandler
        A
        B
        C
        r = Success
        ResumePoint:
        theFunction = r
        Exit Function
        ErrHandler:
        restoreEnvironment
        reportError
        r = FAIL
        Resume ResumePoint

        you should only care about providing enough information about the error, and that would be enough for both the user and the programmer having to eventually debug the code.

        Using functions to return execution status, such as has been traditionally recommended by VB literature (and continues to be recommended by VB.Net literature) leads to needlessly complex code. Functions should be used only to return application meaningful values, not status.

      • VB6 Programming commented  ·   ·  Flag as inappropriate

        @David Day
        "Some businesses all ready have vb6 programs"

        Many businesses have VB6 applications. Many of them large scale and business critical. The reason we need classic Visual Basic is to support these applications. And don't forget 'support' includes modifications and additions.

        You say "I see quite a lot of 'business that can't migrate' argument, doesn't this just further prove the outdated support of vb6(and earlier)?"

        The comment on July 14 about a company spending $300,000 to fail to upgrade from VB6 to .Net sums up why migration often isn't possible.

        There is no feasible way of migrating (large scale) VB6 applications to VB.Net.
        And if there was who would pay for it ? Not the customer who would be paying to get a .Net application that was slower and more buggy than it was under VB6.

        @David can you now see why we need VB6 ? Perhaps you should reconsider and hit that vote button.

      • Dean commented  ·   ·  Flag as inappropriate

        @David

        All this rubbish that VB6 doesn't handle errors to a high standard is complete madness.

        Structured error handling in VB6 is easy.

        Always use functions, always return a (for example boolean) value, always test the return value, if something fails write a log then cascade up and display an error. Close the process gracefully and rollback anything ongoing.

        Always put an On Error Goto in every function.

        When an error occurs you can write to a centralised database and have a trigger that will alert the dev team an error has occured.

        They could fix the bug and roll it out before the user has even got round to calling the helpdesk.

        You believed the propaganda it seems.

      • SuperDre commented  ·   ·  Flag as inappropriate

        @David Day:

        1) Easier to convert(look at C#)

        Convert to what? you're still using the same **** framework, converting your code to javascript or C++ or Delphi still takes just as much time as converting directly from vb6, so that's BS.

        2) Lambdas
        Yeah, great for lazy developers, I see developers using it as complete functions, not what it really was meant for.. Sorry, can't give you that one..

        3) Generics
        Again, great for lazy developers.... but it's usefull but not necessary..

        4) Microsoft still supports vb.net
        I must give you that one, but it's not what MS wants, they are pushing everybody to C# or javascript, so if you stick with vb.net you're still screwed (yes I know the next incarnation will just easily convert via copy/past to c# but it still wasted all those time invested in learning vb.net.

        5) 0 based indexes(I suppose that goes with easier to convert)
        Don't see the advantages of that one, I personally even find it more annoying as with a for you always have to do for i = 0 to MyList.Count -1, whereas for i = 1 to MyList.count makes much more sense (without having to do MyList(i-1).MyProperty). So I can't give you that, also array's in bv six are zero based by default..

        6) Structured error handling
        k, I kinda must give you that, BUT! it's also possible with vb6, it just doesn't look as nice..

        7) Fully OO
        Yep, that's one I also must give you..

        Some advantages of using vb6 as opposed to vb.net:

        1) Faster load time
        Not only faster load times, but also faster screenupdates for winforms..

        2) Some businesses all ready have vb6 programs
        SOME businesses??? I really think you have no idea how many commercial applications have been written in VB6 or how many internal applications have been written in it..
        Why do we need to convert all those applications when it's not necessary? .NET doesn't give any real advantages for completely converting your application which is running perfectly and doing what it needs to do.. And just look, after 10 years even MS is abandoning .NET itself and going into a different direction, back to the old ways of COM..
        And the funny part is, whenever i use .net it still bogles my mind how many stuff is still missing from the .NET framework itself which are so common and the quirks/mindwarps the architects have come up with..
        Yes, there are great things about vb.net which are missing from vb6, it would be awkward if it wasn't.. but there isn't really much I want more..
        It would be great to have the following:
        -real OO
        -shortcircuit If statements (so And/Or act like the awkward AndAlso OrElse, I still find it stupid they added those instead of just changing And/Or (or use an 'Option Explicit' like way to enable it).
        -better WINAPI support (so we can actually do the same as you can do with C/C++)

        There isn't really much else I can think of that I need/want.. ****, I don't even need the Visualstudio.NET IDE, I still like the cleanliness of the vb6 IDE, yes it would be great if it got a bit updates so it would be easier to write your own addins..

        And there are also some other advantages to vb6:
        -it run's on any windows (95 to 8)
        -it doesn't need a f-ing big framework to run.

        I still cannot get my head around people like you who don't understand that vb6 still is a very much used development platform.. If it works, why change?

      • David Day commented  ·   ·  Flag as inappropriate

        I see quite a lot of 'business that can't migrate' argument, doesn't this just further prove the outdated support of vb6(and earlier)?

        Some advantages of using visual basic.net over visual basic 6(or earlier):

        1) Easier to convert(look at C#)
        2) Lambdas
        3) Generics
        4) Microsoft still supports vb.net
        5) 0 based indexes(I suppose that goes with easier to convert)
        6) Structured error handling
        7) Fully OO

        Some advantages of using vb6 as opposed to vb.net:

        1) Faster load time
        2) Some businesses all ready have vb6 programs

        I really cannot see the advantage of anybody using vb6 when you can be backed by the full power of the .net framework. That is why this petition will not get my vote, and why other's should reconsider before hitting that vote button.

      Feedback and Knowledge Base