VB6, R.I.P.

Over a 100 MVP's have signed an online petition to make Microsoft migrate the behemoth Visual Basic 6 (VB6) to VS.NET and let it live on as an unmanaged language. More information can be found here: http://rblevin.blogspot.com/2005/03/microsoft-mvps-revolt.html

I wrote a fair amount of VB5 and VB6 COM objects for MTS and COM+ utilizing systems, because it was so much easier to write ADO code than it was in C++. At least until I found out that with smart pointers, generated by VS6, ADO code in C++ looked almost the same as VB6 (but then with curly brackets and MTA compatible )

Example (yes, lovely Hungarian Coding, code is from an inport/export tool) (comments added for the people who can't read C++)

// create command object
TESTHR(cmdADO.CreateInstance(__uuidof(Command)));

// fill properties
cmdADO->ActiveConnection=m_ggdInternalData.m_conADO;
cmdADO->CommandText = "sp_pdimport_AddModifyRemove_Users";
cmdADO->CommandType = adCmdStoredProc;

// Add parameters
cmdADO->Parameters->Append(cmdADO->CreateParameter("@sUserID",adVarChar, adParamInput, 10));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@sPassword",adVarChar, adParamInput, 26));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@iLogoID",adInteger, adParamInput, 4));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@iLogoSmallID",adInteger, adParamInput, 4));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@sAction",adChar, adParamInput, 1));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@iErrorCode",adInteger, adParamOutput,4,0));

// execute the procedure
cmdADO->Execute(NULL,NULL,adCmdStoredProc);

// read back output parameter
iErrorCode = (int)cmdADO->Parameters->Item["@iErrorCode"]->Value;
if(iErrorCode)
{
	// error occured.
	throw(_T("Stored Procedure sp_pdimport_AddModifyRemove_Users failed."));
}

It's almost VB6!

Now, I understand that having a huge investment in VB6 code and then knowing support will end for VB6 at the end of this month is not something you truly want. On the other hand, VB6 is over 6 years old. It works, if you could write software in it for 6 years, you can for the coming 6 years as well. So what's the big deal with these guys and gals wanting deliberately to keep VB6?

I don't know. It can't be the horrible syntax of VB6. It can't be the limited view on the world offered by a dated IDE and runtime. It can't be the limiting STA framework and pseudo-COM goo you had to work with. Apparently it's the 'ease of use' to write software for Windows, which is not offered (?) by VB.NET.

I say, it's a fear to change. Of course, software which is written in VB6 will get stale after a while. But so is my C code from 1992 using the CURSUS library for terminals. The tools used to write it will still work, but new stuff will likely be written for a newer platform. I also have a lot of VB6 code still in the sourcecontrol systems here, a complete CMS I worked on for more than a year, with management tools, COM / MTS based middle tier and great ASP 3.0 pages. It still works, we still use it. That doesn't change at the end of the month, the code works for 3 years already, why would it suddenly fall apart?

Every person who has worked with VB5 or 6 knows that when a new OS was released, and you wanted the new features of that OS, you needed COM components, and at the moment the VB runtime library gets pretty dated. With the upcoming managed Avalon layer and Longhorn core, the VB runtime will seriously look like something from the stone age. Microsoft made the decision a long time ago to move every developer to the same platform: no more COM or Win32 or VB or Java, but solely .NET. These kind of decisions are easily made but take years to become reality, and if you want to have something changed by 2006, you have to start perhaps 7 years before that to get things rolling by 2006. The decision to have a VB.NET is therefore a logical one: the VB developers would feel at home with the language and could migrate to the new platform, moving their code to the next platform.

What these 100 or so MVP's want though, is to keep the aged platform around but with new features, so they can use the upcoming platforms like Longhorn will offer us in VB6 like code. To get that accomplished, the VB language has to be adjusted to make use of the new platform features, the IDE has to be adjusted to meet todays (and future) standards, and the runtime has to be made up to par so it can be used for at least 10 years. So if you do all that, what do you get? I think something closely to VB.NET. So I don't see the necessity for the petition. And if you think VB6 is the only real computer language, the only real platform someone should ever write code in (these people really exist), you can also port your code to RealBasic. But while doing that, you'll discover how little VB6 really offers you if you don't have the nice COM objects available to you when you try your realbasic application on Linux.

Despite the fact that I'm a 'lefty', I don't particularly like 'use the next version, it's better'-kind of thinking that much, sometimes what you have is good enough. Though, being the realist that I am, in this case, I can only advice developers around the world: if you're a VB6 developer, don't think about tomorrow, think about next year, or 2 years from now. It will be .NET, .NET and oh, .NET, at least for the Windows/Microsoft developer. Make the change, now, when you have the time to familiar yourself with OOP, .NET, it's massive API and VS.NET, so you can make the transition more easily in the near future when you for example have to work on a .NET project: you then don't have to say 'No' or have to hastly learn all those classes and new VB.NET language elements.

I wonder if these 100 MVP's also still run Windows for Workgroups 3.11 on their Pentium 60 machines...

11 Comments

  • I want somebody to create a "let VB6 die a natural death" petition. I would sign it.

  • I remember a similar petition being passed around years ago when MS announced the end of QuickBasic v4.5 and Basic PDS v7 in favour of VB.DOS. Fortunately, MS ignored the petition.

  • Joseph, me too. Yesterday with a friend I was near to create a dedicated org website.

  • " Microsoft made the decision a long time ago to move every developer to the same platform: no more COM or Win32 or VB or Java, but solely .NET"



    The problem is that that decision costs a bunch of other people money, not Microsoft. If you sunk money into VB code with the expectation of being able to keep it around for a while, and stay relatively current with the platform, that assumption is now wrong.



    My sincere hope is that as many folks as possible that are in this situation either stick with what they have for as long as possible, or switch to somebody else's platform and/or development tools. That's the easiest way to make Microsoft bear the burden of some of these costs.

  • I think MS should offer extended support for VB6. I hate the thing, but hey...



    And, I think most VB devs just feel the pain of shipping the .NET Framework, with its slow WinForms, etc.

  • I'd also sign a petition for putting us out of the misery that is VB6. I don't want 5 minutes of MS time that can be spent on new technology keeping that brain-dead language alive. Everyone has known that this day was coming, and the fact that these fools have misled their clients and companies into believing that MS wouldn't EOL VB6 doesn't change the fact that its life is over. And the clueless whining by some of these "MVPs" is just embarassing.

  • I am not an MVP and I thought these guys were supposed to be at the high end of the developer tree.

    I was one of the VB developers who berated Microsoft for not giving us OO in VB4, 5 and again in 6. In fact I did for a while leave VB because Delphi had what VB did not.

    I started playing with .Net with the first beta and really cheered, everything I really wanted in a development language.



    Then I found C# but that is another story 8¬)



    OK so VB6 will no longer be supported, but so what? I stopped developing my stuff in VB6 a couple of years ago, but I can still write code in it for maintenance purposes - what is still there doesn't need to change, and when it does the new parts will be in .Net - they can work together - until I either retire them or completely migrate them.

    No Microsoft, please concentrate on giving us better tools, rather than supporting old versions.

  • The point doesn´t seem to be clear.



    I am one of 203 MVPs who signed the petition. And have been developing in VB.NET for over one year now. And love it. But it is not VB.



    Besides my current project, I have a couple of huge systems from which I make my living. Both are completely written in VB6.



    I adopted VB 7 years ago, after 13 years programming in C for *nix, Netware and MS-DOS. And I chose VB over Delphi -which is clearly a much better programming language- because of Microsoft´s alleged commitement to the long term stability of the language. Seven years are no long term at all.



    My main concern is the life expectancy of those two systems. The petition requests a rebuild of VB.COM integrated within the Visual Studio IDE. Personally, I find that point kind of too radical. If VB were given all that is needed to make of it a good, sound OO language, it would become VB.NET (if they ever manage to raise VB.NET above its present Beta level of quality).



    The terminantion of mainstream support means that if a Windows updte breks compatibility, nor we developers, nor any of my current users, will have the right to request a free hot fix.



    It means that my applications -which I will not port, because porting doesn´t do any justice to the improved features and capabilities of the new tools, and therefore is a useless excercise- will become enemical to Windows Updates. Until a finish a redesign -and subsequent reconstruction- of those systems, every new update is a potential nightmare.



    Until the products that 6 million professional VB developers get redesigned (or ported) to leverage the many Framework improvements -and it might take several years- a large number of users will be afraid to perform Windows Updates, or install the latest OS version.



    So, it´s not me who doesn´t want to "move on". It´s the sheer weight of a code base that -like your CURSUS interface libraries- doesn´t deserve to be improved, but it doesn´t deserve to be killed by decree either.



    If the outcome of this turmoil were that MS accepted to extend support for VB applications for five more years (I don´t really need any feature added to VB6, and I have learnt to live with its bugs -as with any language that I have previously used). But I expect them to guarantee that my apps will remain alive for -at least- five more years.



    Otherwise I will be forced to completely move to another platform and set of tools.



    It's a matter of trust.



    Salud!

  • Frans, it's you that misses Leonardo's main point, that of "The terminantion of mainstream support means that if a Windows updte breks compatibility, nor we developers, nor any of my current users, will have the right to request a free hot fix."



    That's what a lot of us are worried about. I don't write new code in VB6 anymore either, but I have a lot of existing code that cannot be ported easily to .NET. (Far to much code, far to little budget...)





  • Bob, I understand that concern, but MS' testlabs test a fix against a lot of existing applications and frameworks, including VB6, even VB5. This means that if a fix is released, the fix is regression tested against the VB6 RT.



    The free fixes you're talking about are fixes for the VM and IDE, which are after 6 years a bit unlikely, especially because they released already 6 SP's. I.o.w.: the bugs you'll find now, you'll have to live with them, but you've already done that for 6 years.



    Win32, COM interfaces of windows components used in VB6, these things don't change by definition. This means that if you use them in your VB6 app, they WILL stay the same by definition, which assures your application won't break if you apply a windows fix which for example alters the win32 api.

  • Frans,



    In the web log you quote -- yes, that is at least some good news, I hadn't thought of that angle, but it doesn't cover ongoing maintenance of VB6 code, which is still a problem, and running on something earlier than XP is probably still a problem as well.



    We can't really trust that no customer apps will be broken by fixes in other compnoents as you suggest, and since the devlopment environment is not supported, it may be broken too, so even if the runtime is supported, that doesn't mean we have a running app.



    There's certainly no way even Brad can guarantee that the VB6 runtime will work in Longhorn when it is released.



    As for existing bugs, I'm not worried about that -- I've lived with the bugs, know them and their workaraounds.





Comments have been disabled for this content.