Renewed interest in VB6

I mentioned recently that I was back doing VB6 work, yesterday I was doing VBA and realised that my VB IDE is more productive than my VBA one, just because of the tabbed editing. Seems I’m not the only one still using VB6.
I just tripped over a couple of VB6 resources that have appeared recently.

Karl Peterson who was an VB6 MVP for ever has just (September 07) been asked to write a new column in Visual Studio Magazine focusing exclusively on VB6.

A new website has been setup with a ton of on-line VB6 learning resources.

The content on KPs articles initially will be on getting VB6 stuff working on Vista, which is totally supported, but with many control updates, is unsurprisingly not zero touch.

Its great to see a bit of life in the old dog yet. What is interesting is the one thing many of us wanted to see was the runtimes included as part of the operating system. MS got close to that with the VB6 stuff by including it with all versions of Office since 2k, and I think it is native as part of XP and Vista. Vista also natively includes the .net framework (version 3.0 which is roughly 2.0 plus some UI stuff).

In a few years when(/if?) most people have moved to Vista then in theory that whole framework deployment adoption blocker should be lifted. Well it would be if each version of Visual Studio did not mandate a new version of the framework, and a new VS is being released every 2.5 years. In reality for many people the framework deployment will continue to be an adoption blocker unless IT departments wake up and schedule it as almost a service pack.

Whats ironic is that because VB6 is no longer being actively developed by Microsoft, it, and its runtimes have been stable for years. This makes it a very attractive development option, much more attractive than chasing the tail of the .net runtime in many cases. Having abandonware so attractive compared to flagship products should really wake a few people up at Redmond.

My big concern for VB6 is 64 bit, I am not totally clear on how well that story will pan out. I guess its a few years out yet. Anyone heard any sniffs of a 64 bit VB6 compiler?

Why do I even care about VB6? Mainly as a migration route from VBA, and nothing in .net compares.

Has anyone tried the VB6-VB.net migration wizard on some meaty VBA? Or is the .net/interop cost so high its not worth bothering?

Cheers

Simon

Advertisements

3 Responses to “Renewed interest in VB6”

  1. Rob Bruce Says:

    I finished my last VB.NET project almost a year ago and I don’t expect to be doing another one soon. I miss the IDE, I miss the more powerful WinForms controls, and I /really/ miss (overloaded!) constructors, but otherwise VB6 does the job quickly and (reasonably) efficiently and it doesn’t need any interop rubbish to work perfectly against the Office object models.

    You’re spot on with the stability thing. Trying to keep up with additions and changes to .NET is a full time job even before you actually do any paying work. I sometimes wonder if the only people who are not just plain bored with the .NET juggernaut are MS themselves and fellow traveller journalists and technical authors. Add to that runtimes that are pushing 30 Mb in size and the whole thing feels like a bloated monster.

    I have an Excel/VB6 analysis engine running successfully under 64 bit Windows at a client’s site. I don’t think MS is likely to remove backward support for 32 bit code in its operating systems any time in the next decade.

    As for the migration wizard, don’t bother. If you really want to move code into .NET, take the opportunity to do some proper refactoring.

    Rob

  2. Simon Says:

    Rob parameterised (& overloaded) constructors is the biggie for me too.

  3. Marcus Says:

    I never lost interest in VB6.

    And while refactoring would be nice in a migration, it’s rare to have that luxury.

    I recently migrated some 40K LoC from Excel/Access to a VB6 DLL. The buiness logic could be ported across untouched. It was really only the I/O and data structures which had to be modified. Any references to ranges or tables were redirected to arrays populated by CSV files. The IT dept wouldn’t allow us to connect directly to the SQL Server farm. I don’t think we could have migrated in the timeframne allocated had we gone down the .Net path.

    Cheers – Marcus

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: