Frans Bouma's blog

Generator.CreateCoolTool();

Syndication

News

    Visit LLBLGen Pro's website

    Follow FransBouma on Twitter

    Add to Technorati Favorites

About me

Fun stuff I created

My work

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

Published Thursday, March 10, 2005 10:14 AM by FransBouma

Comments

# VB6, tanti commenti@ Thursday, March 10, 2005 1:43 AM

TrackBack

# re: VB6, R.I.P.@ Thursday, March 10, 2005 5:09 AM

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

JosephCooney

# re: VB6, R.I.P.@ Thursday, March 10, 2005 7:23 AM

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.

Len Weaver

# re: VB6, R.I.P.@ Thursday, March 10, 2005 7:32 AM

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

Marco Russo

# re: VB6, R.I.P.@ Thursday, March 10, 2005 9:54 AM

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

mschaef

# re: VB6, R.I.P.@ Thursday, March 10, 2005 10:42 AM

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.

Michael Giagnocavo

# re: VB6, R.I.P.@ Thursday, March 10, 2005 11:17 AM

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.

Mickey Williams

# re: VB6, R.I.P.@ Friday, March 11, 2005 4:00 AM

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.

Alan Bell

# VB.NET vs @ Friday, March 11, 2005 10:01 AM

TrackBack

# re: VB6, R.I.P.@ Friday, March 11, 2005 7:03 PM

Alan wrote:
"I am not an MVP and I thought these guys were supposed to be at the high end of the developer tree"

Sad to say that that is not always the case. For every excellent forward thinking MVP like Frans Bouma there is somebody stuck in the past. I often wonder what these MVP's are thinking. There are still Windows 98 MVP's believe it or not. How long is that going to last?

For those wanting a petition to sign, I was going to put one up, but then saw this post over on AddressOf.com:
http://addressof.com/blog/archive/2005/03/10/1430.aspx?Pending=true

That's good enough for me. It's just not worth the effort as the lunatic fringe seldom succeed anyways.

Be well.

Dave - C# MVP (former VB6 coder)

David Totzke

# re: VB6, R.I.P.@ Friday, March 11, 2005 9:02 PM

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!

Leonardo Azpurua

# re: VB6, R.I.P.@ Saturday, March 12, 2005 5:02 AM

Leonardo: you miss the point. In the history of VB, porting of code was one of the things you had to deal with (16bit vbx to 32bit com, dos to windows etc.). But... ONLY if you wanted to use the new platform's features. If you didn't want to, you can perfectly run the older ide and use that one. When I have to do maintenance to my old VB6 stuff, I run VB6, do the maintenance and I'm done, and that's not going to change April 1st.

Please also read Paul Vick's reply to this petition. He has some very insightful remarks. What I also found a good posting was the AddressOf.com posting, already linked in the reply above you. Paul Vick's reply: http://www.panopticoncentral.net/archive/2005/03/10/7951.aspx

Frans Bouma

# re: VB6, R.I.P.@ Saturday, March 12, 2005 8:17 PM

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 Comer

# re: VB6, R.I.P.@ Sunday, March 13, 2005 4:49 AM

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 Bouma

# re: VB6, R.I.P.@ Sunday, March 13, 2005 6:09 AM

Bob: from the horse's mouth:
http://blogs.msdn.com/Brad_McCabe/archive/2005/03/12/394658.aspx

Frans Bouma

# re: VB6, R.I.P.@ Sunday, March 13, 2005 7:53 AM

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.


Bob Comer

# re: VB6, R.I.P.@ Sunday, March 13, 2005 12:28 PM

"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."
Is this really a high risk? I mean: you're dealing with COM components. This means that there is interface versioning. This also means that newer versions of a COM component will have a different interface ID (CLSID) and thus your VB app will use the old(er) ones.

So existing code will IMHO keep on working, what's indeed a problem, but nowhere is this MS concern, is that 3rd party vendors stop supporting COM versions of their controls. Though, the market for COM controls is still far bigger than for .NET controls, so the first few years this is not a problem by far.

After a few years from now (say 3) it might be a bit of a problem, to find good 3rd party controls which support newer features (i.e. xp theming and the like), but that's not really an area 'maintenance' work will have to deal with. (IMHO)

Frans Bouma

# re: VB6, R.I.P.@ Sunday, March 13, 2005 11:14 PM

"Is this really a high risk? I mean: you're dealing with COM components. This means that there is interface versioning. This also means that newer versions of a COM component will have a different interface ID (CLSID) and thus your VB app will use the old(er) ones."

I can't really answer that, but past track record isn't exactly wonderful. More can break than COM compnents as well.

"So existing code will IMHO keep on working, what's indeed a problem,"

No guarantee of that as I said.

"but nowhere is this MS concern, is that 3rd party vendors stop supporting COM versions of their controls."

Darn right it's Microsoft's concern when the code base is so large, you don't want to alienate that many customers. Since we have to rewrite our VB6 code anyway, we can rewrite it for any platform, even non-Windows, so Microsoft ends up losing on new revenues. (of course not everyone will, but some will and any erosion is less money.

"Though, the market for COM controls is still far bigger than for .NET controls, so the first few years this is not a problem by far."

Like I said, it may not get rewritten for .NET...

I might also add that I don't sell my code, I'm an emplyee of a corp and I only write in-house stuff, so my needs don't relate to a software house type situation.

"After a few years from now (say 3) it might be a bit of a problem, to find good 3rd party controls which support newer features (i.e. xp theming and the like), but that's not really an area 'maintenance' work will have to deal with. (IMHO) "

I'm not concerned with that at all, I am concerned with VB6 code being able to continue running. I usually program to LCD feature anyway because of the number of OS's my code has to run on. The VB6 runtime being supported until XP goes off support helps because the timeframe is longer, but i'm still worried that code can be obsoleted like that. That's not what happens on bigger enterprise level OS's.

IMHO, of course...

Bob Comer

# Transitioning to... VB6?!@ Friday, March 18, 2005 6:28 PM

TrackBack