Some thoughts on “Classic VB”

This topic has been in the ‘news’ lately (well, at least in the blogs) and I’ve been considering replying…. but it turns out I don’t have to, because Dave Totzke has done it for me. I don’t really agree with his comment that we’ve kept C++ alive because Office is written in it… it is actually because the managed world doesn’t replace the need to write native code against the underlying hardware and OS. We need to have at least one avenue for folks to write the high-performance graphic software, device drivers, network packet filters, etc…. so we need unmanaged C++ to stay. There isn’t a similar need for new development on VB6.

Yes, it is hard to upgrade complex code bases, but when you install VB.NET it doesn’t uninstall your copy of VB6. It is possible to maintain an existing code base while you write new code in .NET and then interop as necessary between the two worlds. Within MSDN, we have Access applications that pop-up Windows Forms when you click certain buttons… we have VB6-based add-ins for Outlook and Word that are simple wrappers around .NET code and some that are a mix of VB6 code and VB.NET code…

There are some things that were in VB6 and are not available in VB.NET that I feel still need to be available, but I think they could be made available as .NET components, ActiveX components, or add-ins to Visual Studio. Take DDE for example, it just isn’t part of the .NET Framework, so I think it would be nice if we had a small component that allowed me to access DDE from within .NET, fired events when new data arrived, etc… I wish that people would put their effort towards building/requesting these types of components instead of advocating something that just isn’t a good idea. At the very least, push for more effort to be put into the upgrade process, lets get someone to build more than just a wizard, build a tool that does the upgrade and includes a ton of additional libraries to help with transitioning older code. That would be a lot of work, but the end result is still better than just doing incremental development on VB6.

By the way, this is as good of time as any to point out that I do believe that there is something missing in the .NET world right now. We need an Access-like tool for .NET… not what VB6 was, which was really much too complicated for the level of developer I’m thinking of… but something that is a drag-and-drop database form focused application creation tool. Like Access, Filemaker Pro, Hypercard, etc… but producing .NET code behind the scenes so that you can extend simple applications created using this tool with code produced out of VB.NET/C#. I think I’ll call it Access.NET 🙂

Author: Duncan Mackenzie

I'm the Developer Lead for the Channel 9 team, formerly worked on MSDN as a developer, content strategist and author.

12 thoughts on “Some thoughts on “Classic VB””

  1. Dear Paul,

    Please don’t listen to those fools; they are a bunch of losers trying to get by the easy way.

    I know a lot of “Classic VB” developers who are very happy with VB.NET, for instance you can read all the rave (and I know you have) about default instances back at
    That’s a bunch of VB folks saying “Hey we finally have a Powerful, Clean and Object Oriented version of VB, please don’t let us go back to the “toy language” times when C++ and Java dudes called us “programming queers”.

    I know you did a great work on VB 2005 so that the folks that haven’t jump in the .NET wagon yet, can easily migrate, I think trying to relive “Classic VB” it’s a great mistake, please keep all the good work focused on evolving VB.NET

    Thanks Paul!!!

  2. Sorry Duncan!!!!

    The above was a desperate open letter to “Paul Vick”, maybe all the excitement of your post got me confused and I thought I was posting on “his” blog. :$

    I’m sure you can pass him my thoughts……

    Sorry 🙁

  3. Karl, just to be clear, I didn’t say there weren’t people who want VB6 to continue, but it doesn’t fill the same need that C++ does… the need for a native language that can talk to hardware and the OS. VB6 was not a language like that, and while it may be great in many ways it does not provide a unique set of features that would require the language to continue in the way that unmanaged C++ is required.

    Of course, I’m still happy to be awarded any form of prize… so thanks!

  4. Well, Duncan…

    > I didn’t say there weren’t people who want VB6 to continue, but it doesn’t fill the same need that C++ does…

    That’s not what you said, but I’ll give you credit that’s what you meant. What you said was there wasn’t a need for new development with VB6. Either way, (I’m fairly confident you know that <g>) I disagree. Classic VB provided “anyone” the ability to write COM apps. Even Don Box is on record saying COM will be around for a long, long time. I see no reason why this market isn’t being catered to, rather than shunned. It’s huge. VB.NET is dying from within. What’s the point? If ever there was a language that didn’t have a raison d’etat…

  5. Thanks for the kind words. You make a very good point about the need for high-performance graphic software, device drivers, network packet filters and the like. I never really thought of it from that angle. I guess I’m just not as big of a geek as you are 🙂 Although, you have to admit that having your flagship product codebase in a language pretty much seals the deal.

    I am also intrigued by your idea for an Access-like tool that writes managed code in the background. Very interesting concept. I love Access for quick departmental utilities and the like. It would be nice if there was a similar front end for .NET. Hey, isn’t that what VS2005 is? Perhaps a re-branding is in order. <tongue-firmly-in-cheek>

    I am a little disappointed that Karl gave you “The Elitist Badge-of-Honor” this week. I was really hoping to get that one myself.

    Maybe next time.


  6. > We need an Access-like tool for .NET…

    Couldn’t agree more.

    Ideal for prototyping, and then we maybe even get to re-use some of the code that was created using prototyping.

    Also ideal for small business customers.

  7. Unlike most of the developers who expressed their comments on this post, I do believe that a common mistake is to take for granted that the .NET Framework will succeed to the throne of operating systems, currently held by Win32.

    When the COM technology is abandoned by Microsoft, people will have the possibility of thinking about which operating system they should choose. Nowadays, Windows is the only logical choice.

    As a VB6 programmer, what I am afraid of is not whether MS will continue to provide its support (there are so many forums dedicated to VB6 that I couldn’t care less), but whether my present knowledge will be completely useless when the Win32 API disappears.

    Can we be sure MS will not be so stupid as to deny compatibility with Win32 executables in the next versions of its operating system?

    If Bill Gates decides to start a new era abandoning the COM technology, many people could opt for Linux as an alternative to something completely new that has not yet been sufficiently tested. That’s when Microsoft could lose its monopoly on operating systems.

    VB6 is certainly the most widespread programming language in the world but, after the advent of VB.NET, a lot of frustrated VB6 developers have decided to move to alternative languages such as Flash MX 2004 (which also allows you to manage databases), PowerBasic and so on.

    A petition I would very much like to move is one encouraging Microsoft to sell the copyrights for VB6 to other software houses, allowing them to release new (COM based) versions of the product.

    Similarly, if MS decides to abandon the COM technology, it should either sell the rights for Win32 to another software house or release the entire Win32 code base as public domain.

  8. I’m intrigued by your idea of Access.NET. I’ve been thinking myself for quite a while now that a similar tool is needed. What eventialy occurred to me is that this would be an excellent role for SQL Server Express.
    With the whole thing about being able to use an .mdf file as a datasource directly instead of connecting to the server and the fact that you can write functions and stored procedures in .NET code, it would seem like the ideal thing would be to include it in Office.NEXT as an alternative to Access.
    Maybe still using the Access shell to connect to the files/server (similarly to how you currently can with an .adp) but allowing you to write .NET code against the database instead of VBA. Tie that in with SQL Reporting Services and you have a complete Access replacement/alternative that plays very nicely in the managed world. And has all the power of SQL Server. Now wouldn’t that be nice?

  9. I’m always thrilled when M$ apologists write about how superior VB.NET is. It was so superior that of the 3 Classic VB programmers I used to know, 2 jumped onto the Java bandwagon (1 is still happily there, the other has left programming) & the other one switched over to VBA. I guess they just couldn’t handle learning a “superior” language.

Leave a Reply to Kent Sharkey Cancel reply