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

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

      • VB6 Programming commented  ·   ·  Flag as inappropriate

        Had Microsoft provided an upgrade path from VB6 to VB.Net we would probably have gone that route. Now we feel fortunate that they didn't. We still maintain and develop our legacy applications in VB6. We also use JavaScript.

        We did use VB.Net for a few years too, but this has virtually stopped now. Ironically it now looks as though the applications that will be migrated/re-written will be the .Net ones.

        We'd still like a commitment from Microsoft to ensure classic VB's future.
        One question we are now getting asked is if we have a 64bit version of our software. Though we point out that 32bit software will probably run faster on a 64bit O/S than 64bit software, I can see this question being asked more and more.

        An updated VB6 (from Microsoft,. Open Source or elsewhere) is what we need - are you listening Microsoft ?

      • eric au commented  ·   ·  Flag as inappropriate

        I think I can conclude a little something after all the discussions here : Only non professional programmers will think VB6 is not a professional tool, and one of the most influential people in this group, unluckily, is Steve Ballmer, who decided to get rid of the "toy" tool.

        I think I know how to debate when I meet this type of people again :)

        Back to the purpose, MS please give the life back to VB6.

        I have a VB6 program with 24k lines of codes. It started as a consultant project 15 years ago, and is now becoming a commercial software and is launching right now.

      • rchutch commented  ·   ·  Flag as inappropriate

        Hmm. I thought I was the only one. Back in the VB6 days, we would spend 90% of our time solving the business problem, because all the display stuff that should have been simple was really simple and it only took a few seconds to complete. The programs were amazingly small and fast.

        We've now converted everything to .NET and Silverlight. We now spend 75% of our time making the pages look reasonable (25% of our time solving the business problem), the resulting product works about 60% as fast as the VB6 product worked. It now requires an enormous installer and a person to maintain the installer.

        Yes, the Silverlight page is deliverable over the web and looks nice on all browsers (big advantages), but did we need to lose all of the ease of programming stuff when we went to .NET?

        It was the same thing when they got rid of PhotoDraw. PD did 100% of everything I needed to do to create the pictures I needed. When they got rid of it, I was told that I should use Photoshop. Sure you can do it that way, I will get the same picture, but it will take me days instead of minutes, it will look no better and it will cost me a thousand times more.

        When they went to .NET, it appears that "solving the problem" must have been very low on the list of priorities. Creating a "cool technology" must have been high, because those of us who had work to do (and weren't overly impressed by whatever was released, just because it was new) were left wondering why.

        I'm still wondering when someone at Microsoft will consider the needs of "those who just need to get our work done." And our work IS NOT make sure all the boxes line up nicely when the window is resized and all the other nonsense that should be automatic.

      • Dw commented  ·   ·  Flag as inappropriate

        I concur. Having been programming since 1968 (with punchcards), DOS since 1981 (started with Edlin) , a multitude of different languages (Fortran, COBOL, ALGOL, PLI, Assembly, etc), when VB Classic (VB3) came out i jumped on it and never looked backed. Coupled with the API, VB Classic can do almost anything you can do in C or C++, in less than half the time. I know only great programmers using C++ (hogwash1). I personally do NOT want to learn another way of doing things especially when I can write a program which compiles to about 3MB in VB and 60 MB in NET.

        Microsoft (Steve Ballmer), if your listening, it was a bad corporate decision to drop VB Classic.
        I

      • Anonymous commented  ·   ·  Flag as inappropriate

        If you are really such a huge fan of VB6, then please stop uttering such misinforming nonsense.
        Again:
        The VB6-environment is not only an IDE, it also hosts two different compilers - one for PCode-Binaries and Debugging-purposes (that's perhaps the part you refer to as "scripting") -
        and then there is a true native compiler integrated, which (in two stages) produces binaries with an adapted VC++6-compiler, which is shipped with VB6 and included as C2.exe.

        If you'd feel better about it, and in case you want to show-off before your friends - you can of course also program with VB6 "the hard way" -
        using e.g. Notepad++ - and then configuring it, to start the VB6-compiler with appropriate commandline-params, to produce your binaries "like real men do", directly from a simple Text-Editor. ;-)

      • Anonymous commented  ·   ·  Flag as inappropriate

        Come on!! What you call "programming language" is nothing but an internal scripting language which was written using C++!! and don't misunderstand me I'm a huge fan of VB6 and there is no need to insult me as I already gave this 3 votes and I'm inviting whoever I can to vote for this too. but let's face it VB6 is just a Software which uses an scripting language written In C++ based on BASIC language to rapidly develop windows applications. if it was an independent language then it wasn't rad at all. I mean "RAD language!!" how often do you hear that?!!!!!!

      • Anonymous commented  ·   ·  Flag as inappropriate

        Not surprising that people hide behind anonimity to utter such moronic statements.
        I dare Mr. Anonymous to mention one single principle of whatever programming theory or paradigm that can not be implemented using VB6.
        An architect can produce beautiful and complete designs using paper, pencil, a ruler and a protractor. A photographer can produce breathtaking pictures with a pinhole camera. And thousands of programmers have produced top quality software using VB6.
        Most of us, professional programmers relying on VB6, have a deep knowledge of other languages as well, probably including VB.Net.
        A good system has a life cycle of several years. Mine is about to become 14, and I am currently working in a thorough redesign of the UI and expansion of its functionality in order to improve its market value so that I can rely on it until my retirement, which is a few years ahead. A little over 2000 business depend on it, and about 150 persons, including dealers and support staff make their living out from it.
        And this system is only one of several thousands of perfectly written VB6 applications that depend on VB6 in order to continue existing and providing functionality for their users.
        The point, and it is irritating to have to insist on this over and over, is not the relative quality of VB6 compared to any other language, but the survival of a few millions of people which are on stake beause some idiot took the wrong decission.
        As for the rest, your opinion is worth ****!

      • Anonymous commented  ·   ·  Flag as inappropriate

        @the previous commenter (July 17, 2013 1:56 p.m.)
        You just wrote a whole lot of nonsense and are not a developer (you'll never be I think) - no need to say much more <still shaking my head>...

        @the comment (July 16, 2013 3:01 p.m.)
        When you say: "The reality is that many business rely on VB6 applications...",
        you're quite right of course.

        But let me ask, why everybody seems to be so eager to "migrate somewhere"?
        Why is that...?

        MS currently promotes "WinRT and Metro-experiences" - but is that the stuff one really should "migrate to"?
        Are we sure? For that matter, are *They* sure about it themselves?

        If yes, then also all those .NET-Apps which currently are heavily based on WinForms, would need to be migrated too.
        Congrats all you .NETers - your second complete re-write (after obediently following the MS-propaganda, being herded and "migrated away from VB6") is on the horizon.
        Yes, you're in for a surprise - the WPF/XAML-paradigm differs quite a lot from what you invested into your WinForms-driven Apps.

        But if WPF/XAML really is the new way to approach things, "to migrate to" for all the willing followers,
        why on earth did they deprecated Silverlight already, which was using this technology heavily?
        ... just to give you another thing to ponder, whilst trying to make sense of MS' "long term dev-tool-strategy"
        (if there is any such thing in this regards at all at MS)...

        So, suddenly the arguments which were used, to lure VB6-Devs away:
        - better type-safety at compile-time, "no Variants", "COM is outdated technology"
        are funnywise now somehow "reversed again"... suddenly it is "modern" to:
        - program in languages which have no typesafety at all (JavaScript)
        - and COM is suddenly the workhorse again for "modern experiences"...
        - accompanied by "reduced to the max" screen-designs which resemble Win 3.1 again

        Why do they get away with all that, why can they afford to force millions of developers into constant "migrations" of their code-investments...?
        Well, because of "us" of course - it's "us" who will perhaps make the decision, to use MS-tools further "despite of all that".
        It's us who give them the impression, that they can get away with anything...

        <shrug>... and so we all get what we deserve ...

        Of course there *is* some reasonable things one could do...
        as in:
        - switching at least to C++, in case it "has to be an MS-IDE"
        or better:
        - switching to languages, environments and libraries which are *not* owned by a single vendor, which are open and community-driven, and not cluttered with "lurking patents"

        As for VB6:
        I personally will use it further, since there's no real pressing reason on the horizon, which suggests an immediate reaction from my end.
        The VB6-compilers (the PCode-compiler, as well as the native Compiler C2.exe) still produce well-working and valid 32Bit-binaries, which can interact with a whole lot of COM- and other libs on any current target-OS out there.

      • Anonymous commented  ·   ·  Flag as inappropriate

        VB6 despite what most people might think, is not a programming language. it's actually a software. it is reasonable that VB6 is not as powerful as a complete programming language but as a software, it gets the job done. What MS did was turning it into a complete programming language! the changes were so dramatic that when the first time I ran a VB project in visual studio I was like: "Oh baby! what have they done to you!!" Those who work with VB6 (including myself) cannot be named programmers! you can't name yourself and architect just because you can use Autocad! this hurts but it's true so my conclusion is maybe it's best to forget VB6 and move on! I'm currently studying any books and tutorials I can find online about VB.Net and C++ on the side.

      • Anonymous commented  ·   ·  Flag as inappropriate

        The VB6 programmers amongst us could have told that company that it would be slower under .NET - and saved them $300,000.
        But the .NET experts on this site will insist .NET is better.
        The reality is that many business rely on VB6 applications and there is no feasible migration path. We need an updated VB6, whether from Microsoft or elsewhere.

      • Abraham Barry commented  ·   ·  Flag as inappropriate

        I have seen the case of a company that migrated 1,000,000 + lines of code from VB6 to .NET.....At the end the product was miserably slow, sluggish and chompy. After $300,000 dollars spent and months of hard team work, the overall conclusion was: WE WILL KEEP IT ON VB6 NO MATTER WHAT....

      • VB6 Programming commented  ·   ·  Flag as inappropriate

        Microsoft have announced they are restructuring and streamlining.
        Microsoft chief executive Steve Ballmer said Microsoft would be able to react faster to changes in the market.
        Perhaps they will bring out a new release of classic VB if 15 years isn't too short a period for them to react to customer requests.
        I won't hold my breath, though.

      Feedback and Knowledge Base