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

    9338 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Eugênio Pacelli Salgado Canaan commented  ·   ·  Flag as inappropriate

        O mais estranho de tudo isso é a grande quantidade de idólatras dot net estar se opondo a atualização de uma linguagem de programação, seja ela qual for... Porque isso, cavalheiros ? Se vocês fizessem uma petição para dot net ter uma rad com edição em modo real durante a execução interpretada, ou que houvesse uma atualização do compilador para atingir outros sistemas operacionais, independente de eu preferir assembler que dot net, eu defenderia o direito de vocês de requerer isto. Não entendo. Não entendo mesmo.

        Strangest of all is the large amount of idolaters dot net be opposing update a programming language, whatever it may be ... Because that, gentlemen? If you do a petition to have a dot net with rad editor in real mode during the interpreted execution, or there was an update of the compiler to target other operating systems, sure I prefer assembler in oposition dot net, but I would defend the right of you require this. I do not understand. I do not understand it.

      • Lofaday - www VB64 com - A new IDE is on its way commented  ·   ·  Flag as inappropriate

        May I say it is not about comparing VB6 to VB.net -- it is about supporting very large VB6 apps, getting RAD and simplicity back. Personally, I'd be happy for it to stay as is (except unbroken) and just be endorsed and sold by Microsoft still.

        Yes, *.Net has it's plus's, but that's not the issue. Leonardo's roundup was brilliant. I too was only interested in using MS and wanted to buy MS OS's in the 100s for simple industrial apps, but MS aren't interested in my needs, and so my industry (UK transport) is off to Linux leaving MS to rue millions in lost OS sales, having felt MS has lost the plot in this and many areas. Crazy belligerent policies, wasting a decade of my experience to boot. Cheers

      • SuperDre commented  ·   ·  Flag as inappropriate

        @rob: You're a moron, plain and simple.. Because YOU don't like VB6 doesn't mean there shouldn't be another new version, or are you afraid the new version will become that much popular that your company would switch over to that?
        You just stick with your .NET (which you have to rebuy every couple of years, just to make sure you keep up with MS latest whims).

      • VB6 Programming commented  ·   ·  Flag as inappropriate

        @Rob

        "Is there anywhere I can vote against it?"

        Sure, just keep buying VisualStudio.Net every couple of years !

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

        MCZ, você teria que sentar-se ao lado de seu cliente, precisando resolver com certa urgência alguma questão técnica e comercial da empresa dele. Aí você entenderá que o que falta no VB6 não é nada perto do que só ele tem. Sem ir para o chão da fábrica ver as urgências, você só tem palavras, e elas estão certas, exceto que na prática, elas estão erradas. Simples assim !!!

        **********

        MCZ, you would have to sit next to his client, needing some urgency to resolve any technical and commercial point of his company. Then you will understand that what is lacking in VB6 is not anything close to what he hath. Without going to the factory floor to see the emergency room, you only have words, and they are right, except that in practice they are wrong. Simple as that!

      • McZ commented  ·   ·  Flag as inappropriate

        "The truth is that regardless of the sins of the idolaters VB6 to dotNET , the dotNET never replaced the VB6 , and there is still a RAD available to replace the VB6 ."

        The real truth is, if MSFT would build a VB6+ with 64bit compilation (btw, how many bytes has an VB6 integer? Wouldn't the appropriate renaming break your code?), Unicode-support (for the visible parts, if you don't already use WinAPI and Common Controls), Mobile (which is pretty much depending on XAML and parallel computing), it wouldn't be VB6 anymore.

        It also would be complete and utter waste of ressources for MSFT, which is pressed hard by being late to the mobile business. Even if there are 10k users underwriting this petition and everyone of them is a to be seen a potential customer, even if MSFT could offer them for $1,000 a copy (which is ridiculous, as the direct VB.NET-equivalent is completely free), it only makes $10m. For this amount, you cannot even deliver the 64bit-parts with all the needed bells-and-whistles.

        The compatibility-argument is ridiculous. When I ported applications betweem VB 4 and 5 and ultimately 6, everthing needed to be redone, including third-party components. If Mr Azpurua would have changed horses early, he could re-compile his .NET 1.0 application in .NET 4.5 withput hassles.

        Then, flexibility... no real windows services, no real debuggable multi-threading, no real web engine (ouch, WebClass!), no closures, ****** error-handling, far-from-RAD tricky console apps, no deployment-by-copy because of those ****** COM-Dlls, no native SQL Server or Oracle driver (ADO and it's various iterations being a beast of it's own), complete absense of networking ... i'm getting tiresome... i'd loved VB6 back in 2000, but today it's only a ramshakle full of functionality gaps. No poll can change this.

        And, at last, performance... apart from faster start-up times for VB6 apps (around 20 ms faster, due to not required to load reflection metadata), there is zero evidence for this. In fact, most examples I've seen were using VB.NET compatibility methods, which are wrappers on the .NET framework. Most of them are utterly slow. Rewritten to plain .NET, each and every solution came out 30pc FASTER in .NET than her VB6 equivalent.

        Maybe MS should really make VB6 OSS, there are always people having too much time. But then, say bye-bye to guaranteed runtime-support. If you're already not building on that guarantee anyways, there is a perfectly viable alternative already in existence, plz search for 'xojo'.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Our thoundands customers are still using POS solution which was written in VB6.

        I hove vb6 still alive with upgrades:
        - Unicode Support
        - Mobile
        - 64 bits support

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

        Amigos:
        Não vamos ver resposta sobre algo tão abrangente,
        do presidente que está saindo.
        Nem vamos ter qualquer apoio do chefe da divisão de compiladores,
        pois ele é o cara que fez o Delphi, concorrente do VB6,
        o que PARA MIM explica completamente o quanto VB6 foi abandonado,
        e os porques de o VB.net ter sido massacrado em incompatibilidades sem fim.

        Aguardemos a nova diretoria, e sua visão de que talvez metade dos
        bons programadores do mundo ( senão muito mais ) estão atentos
        à retirada da MSVBVM60 do windows, em versões futuras,
        para migrarem para Linux e Android, que logo logo
        estará em desktops com um shell...

        É hora de esperar. Pacientemente como sempre fizemos.
        E mudar, se chegar a hora.

        Por hora, a Microsoft tem o meu respeito, pelo simples e verdadeiro
        fato
        de deixar a MSVBVB60 lá dentro do windows, de onde eu acredito,
        nunca deveria sair.

        Abraços

        ***********************************************************

        Friends:

        We will not see the answer about something as comprehensive,
        the president who is leaving.
        Nor will we have any support from the chief of compilers,
        for he is the guy who did Delphi, VB6 competitor,
        which to me completely explain how VB6 was abandoned,
        and whys of the VB.net have been massacred in incompatibilities endless.

        Await the new board, and his view that perhaps half of
        good programmers in the world (if not more) are aware
        the withdrawal of MSVBVM60 windows, in future versions,
        to migrate to Linux and Android, which soon enough
        will be on desktops with a shell ...

        It's time to wait. Patiently as we always have.
        And change, time to arrive.

        For now, Microsoft has my respect for the simple and true
        fact
        MSVBVB60 leaving the inside of the windows, where I believe,
        should never leave.

        Hugs

      • MIlan Oparnica commented  ·   ·  Flag as inappropriate

        @Leonardo Azpurua:

        Excellent clarification. Simplified, but right to the point !

        WHAT DOES IT TAKE FOR SOMEONE TO RESPOND ? HELLO !?

      • Anonymous commented  ·   ·  Flag as inappropriate

        @Sergey:
        Even better than NET is HTML+CSS+JavaScript+PHP. Then your software will run not only on ARM, but on whatever platform supports a standards compliant browser.

        Whatever the weak points of COM might be, it certainly is provenly able to support everything that I have needed so far, including taking pictures, processing streaming video and audio, controling doors, interfacing to biometric devices, controlling fiscal printers and weight scales, interacting with third party applications and allowing my system to become user extensible almost without any limits.

        So, COM was good enough. And whatever wasn't good should have been FIXED. There was no point in getting rid of it.

        I don't expct my software, designed to be used with a full sized keyboard and a screen with not less than 800x600 resolution on a Windows machine, to run on any other device.

        When mobility has been requested I have developed the required functionality using either Android SDK and Java, or little Web pages.

        The kind of application that you need to port to small devices can be easily written "from scratch" for the specific device/platform using specific.

        By separating the database from the application, and delegating most of the logic to the DB manager, you have enugh flexibility to develop new apps with different technologies in a very short time. These have been standard principles for several decades now.

        But I haven't had (nor even felt, lest feared) the need to migrate my 500K+ lines of code system to any other development platform.

        There are "fashionable" applications, and there are full scale systems, whose life cycles are measured in decades. Unless there were a major change in the environment (like moving from text based, sequential input, single threaded OS to a GUI, mouse driven, multitasking platforms) a rewrite might be justified. But the situation is that new devices have appeared ALONGSIDE traditional computers, which will be in place for many years to come. One might adopt the proper technology to implement extensions on the new devices, but there is ABSOLUTELY NO NEED to rewrite the same applications that will continue to run in the same environments.

        The responsibility of the software providers (be them application or OS developers) is to provide compatibility to safeguard their customers investment. Failure to do so is breaking any imaginable ethical principle.

        The demise of VB6 has shattered the image of Microsoft to a point beyond belief. What software provider with a grain of common sense provides an update that renders unusable their users' data?

        If they ever bring back VB6, or however they wish toname a new tool that accepts my current VB6 projects and produces executable code with the proper behaviour, they will certainly recover my interest and have me as a satisfied (albeit cautious) customer.

        Otherwise, I will continue to regard them as just a flock of corporate scammers.

      • Edd. Bole commented  ·   ·  Flag as inappropriate

        Yes bring back an improved version of vb6. I still use it and make some nice programs, as well as many good folks at VB planet source code. I have Net versions of VB, but rarely use them, as vb6 is much more user friendly. I'm not interested in making big programs, but small ones that don't yet exist.

      • N commented  ·   ·  Flag as inappropriate

        A new, updated version of Visual Basic 6.0 would be amazing. I made (and still make) ​​the most impotant projects in VB6.

        Today VB6 is becoming more widely used by the scientific community. And it is a good reason for this, namely for making prototypes.

        I agree with this petition and support it.

      • Sergey commented  ·   ·  Flag as inappropriate

        @Leonardo Azpurua - I understand you in general. I can not understand, COM components and functions to bind dll libraries available in .NET. I would have already rewritten the code on the platform .NET. Then the application would run on the ARM architecture.
        Obsolete not VB6, obsolete COM, because native code - very dead and badly-verifiable.

      • axisdj commented  ·   ·  Flag as inappropriate

        Quote from one of the comments on the vb6 article

        "
        A computer programmer exemplifies Human thought, translating in effect each thought to a computer command. It is therefore ABSOLUTELY necessary that the programming languaged used is as close to Human thought as possible. This is exactly where VB6 scores High. But I do appreciate the need for other languages.

        It is time to re-invent VB6, proving that it does indeed offer an excellent environment for converting thoughts to programs."

        Professor E. J. Yannakoudakis

      • Anonymous commented  ·   ·  Flag as inappropriate

        I have a 70K line VB6 program and just do not have the time to convert it to .net, given the incompatibilities. I would love to see an update that is fully backward compatible. Failing that, please make sure that the V6 apps continue to run in new versions of Windows.

      Feedback and Knowledge Base