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