« Shades of Green | Main | Microsoft buys Groove »

March 09, 2005

Just plain wrong

There's a lot of hub-bub about the MVP petition to keep VB6 alive, with many links to this post. The problem is, this post contains a number statements that are just plain wrong:

It's "basically" impossible to migrate programs written in earlier versions of Visual Basic to the .NET version. That means any organization with an investment in Visual Basic code -- consultants, ISVs, IT departments, businesses, schools, governments -- are forced to freeze development of their existing VB code base, or reinvest virtually all the time, effort, intellectual property, and expense to rewrite their applications from scratch.

First, as the comments to this post point out, many people have migrated applications over to VB.NET. It is a porting operation (a.k.a. it's not automatic) , but there's nothing remotely impossible about it. Second, organizations are not forced to freeze VB6 development. VB6 doesn't stop working at the end of the month. VB6 still runs, compiles code, and any apps built with VB6 still work. You won't get the same support from PSS, but how many of you are really leveraging VB6 support today? In other words, you're going to find that March 31st is just like any other day. Finally, even if you want to stop doing new development in VB6 and start using .NET, you are not forced to rewrite your VB6 app. It's trivial to extend a VB6 application using VB.NET code. The interoperability works quite well.

Indeed, when it came to preserving its own code assets, Microsoft made certain its mountain of Visual C++ code would move quickly and easily into Visual C++ .NET. Microsoft Windows XP and Server 2003, Microsoft Office, Visual Studio, Microsoft's enterprise business solutions; they're all built in Visual C++ (as is practically everything else the company sells).

This is misleading. This makes it sound like your unmanaged C++ just automatically becomes managed C++. Not the case. Yes, Microsoft does ship a C++ compiler that's more similar to C++ 6.0 than VB.NET is to VB6. But, c++ already supported inheritance, constructors, etc, and didn't need to have those things added to the language. Also, as Microsoft does move things to managed code, they don't seem to be using C++ to do it. They're rewriting it in C#. In other words, moving any code to .NET, whether it's C++ or VB6, it's a significant porting operation.

Worse, Microsoft broke the sacred trust of BASIC developers; something the company carefully cultivated since its founding in 1975 (Microsoft Basic was the company's first product). Forward compatibility was a given until the arrival of .NET. Then, with the arrival of Visual Studio .NET, Microsoft chose to abandon its doctrine of evolutionary change in favor of a revolutionary "clean slate" approach.

Who are you kidding. I remember doing a lot of work to move code from one version of VB to another. Hey, where'd my ActiveX control go? What's this new ADO thing?

.NET is a completely different architecture. I'm not going to bore you with reference counting vs. garbage collection, but once again, moving any code from unmanaged to managed is a porting operation. This isn't unique to VB. Porting a Win32 C++ app to fully managed is a heck of a lot more work.

Also, I'm not trying to be hostile here, but let me make sure I understand this correctly. You're giving this kind of strong advice to developers, and you don't write code any more? I have a word of warning for people: take your advice about coding from people who code day in and day out. Don't take VB.NET advice from someone who only codes in C#. Don't take C# advice from someone who only codes in VB.NET. And please, don't take any advice about what language is best for you from someone who doesn't code. Now I understand why so many of these quotes sound like recycled myths. I suspect that they are the result of regurgitated complaints, not first hand experience.

Thank G-d I'm not dependent on having to program any longer, because with the release of .NET, I'd be farkled, fubar'd, and frazzled. Like many other developers, I don't have the time, energy, or desire to un-learn the substantial skills I've acquired in over 20 years of coding with Microsoft Basics, and re-learn some new thing that's marketed as Visual Basic, but is, in fact, radically different.

Welcome to software development. I've used over 25 languages since I started programming. I full expect that if I'm to stay in this field, I will always be learning new languages, frameworks, object models, you name it.

It's not too late or technically difficult for Microsoft to admit its mistake, and resurrect support and advancement of classic Visual Basic. There's no reason, technical or otherwise, why Visual Basic 6 can't coexist with Visual Basic .NET, just as Microsoft Visual FoxPro coexists with Access, just as Microsoft Visual C++ coexists with Visual C#, and just as Microsoft's Macintosh division coexists with the company's overarching Windows focus.

It does, VB6 coexists just great with VB.NET. You can call into VB6 code from .NET. You can call into .NET from VB6. You can run the VB6 and VS.NET IDEs side-by-side (much like I used to have to run Visual Interdev and VB6 side-by-side).

I'm on-board with what the petitioners want. I want it to, but let's at least stick to the facts and not mislead people about the realities of VB6 and VB.NET development.

Posted on March 9, 2005 at 04:06 PM | Permalink


Interesting post, and good arguments. But elitist. You're forgetting that VB and VBA were the languages that let anyone climb aboard and solve application requirements. You didn't have to be a "professional programmer" to be a BASIC developer. Anyone could code. With VB.NET, you do have to be a deeply educated professional -- because VB.NET is really just C# without the braces. Here's an interesting fact: there are people in this world who DON'T want to be computer science majors, but who can and do program. Classic VB was an ideal platform for them, and created quite a few professional developers in the process, who graduated to other languages, or took VB to new heights. Microsoft USED to be the language vendor who embraced the masses, and encouraged everyone to code. Now they're becoming as stuffy as Sun.

Posted by: RBL | Mar 9, 2005 6:23:16 PM

RBL be specific. How does using Visual Basic .NET require the aforementioned 4-year degree? Be kind, list all the little details that really irk you so that I, I VB6 programmer without a degree in CompSci who made the transition to VB.NET, can systematically shoot them down one-by-one.

Some of these people not only don't want to loose what they've built over the last 20 years, they don't want to grow anymore at all. They desire no future. They would have been happier with no VB7 AT ALL.

Tell me how VB.NET requires production-level abilities.

Posted by: Anthony D. Green | Mar 9, 2005 8:18:21 PM

People are missing the point of his post; yeah, there's the retarded petition, but his complaint goes deeper than just "VB6 must never die": it's about the position of VB in the pantheon of software development. Which has diminished substantially. But don't take my word for it, look at the data!


Posted by: Jeff Atwood | Mar 9, 2005 11:13:33 PM

People simply have to learn not to trust vendor controlled languages and frameworks if they want to avoid these type of nasty surprises.

Posted by: Joe | Mar 10, 2005 2:19:13 AM

Joe, we don't have to learn anything, ever think some of us like these little suprises? Some of us wanted what .NET offers. Some of us want Generics next time around. Some of us don't want to wait for some council of unknowns in a pocket of central europe to democratically adjust to a dynamic market. Some of us are damned happy with the same language vendor that's been vendoring languages for 20+ years. There are enough factions on this topic already without your two cents, go peddle your crap to an audience that CARES.

Posted by: Anthony D. Green | Mar 10, 2005 11:37:40 AM

LOL!! Thanks for the laugh Anthony! Haven't read as amusing a post in awhile. Love the example too. Yes how can any anybody else match MS in only taking 5 years to come out with generics.

Posted by: Joe | Mar 11, 2005 8:22:13 AM

OK, listen up, everyone who doesn't really work with the platform and doesn't really know what they're talking about pay attention because we've already gone over this TWICE.

"...how can any anybody else match MS in only taking 5 years to come out with generics"

.NET was deployed in 2002, it is 2005, it's been running in production for almost 3 years now. Just because it's VS 2005 doesn't mean it's been around since Y2K.

Secondly, in the spirit of VB some companies like Microsoft like to get their products to market before their audience retires. Check the Microsoft Solutions Framework process, it's built in phases.

C++, wonderful language, not vendor controlled. ISO began standardization procedures in 1989 I believe, didn't actually get it published until 1998. Run DateDiff on that and you'll come up with something in that 7-8 year range. Excuse me if I choose to throw my lot in a language vendor that both makes business software and development tools for making business software and specifically development tools meant to produce things in under 8 years.

Lastly, I realize now that you never really had anything large or deep to contribute to this discussion and you really did just want to casually drop in and leave a sly remark of 1 sentence. I apologize for engaging you in actual discussion and I regret it. Please, forget about me and peacefully continue your trolling.

Posted by: Anthony D. Green | Mar 11, 2005 3:15:14 PM


Your definition of "discussion" obviously only involves your rantings and people unconditionally agreeing with you. Your "contributions" only seem to be very badly reworded Microsoft marketing campaigns. Don't worry you will be very easily forgotten.

Posted by: Joe | Mar 14, 2005 5:33:06 AM

perhaps I jumped to some conclusions. After reading your last few posts you haven't made much of a position save "I don't like proprietary languages and you shouldn't either". So either you're here to campaign for C# for it's ECMA standardization or you're trying to influence some of the discouraged VB crowd to some other unnamed language. This post is about VB6, VB.NET and compatability/interoperability between them. If you're not about something in that general area I think there are plenty of other places where your commentary would be more valuable. Perhaps somewhere where people use the term "M$" and "Winblows" a lot.

It's like there is a nationally broadcast debate for the american presidency wherein the two candidates are discussing opposing perspectives on universal healthcare or trickle-down economics and out of nowhere you come up and say "America Sucks", "Don't trust doctors" or some such. A valid opinion just not the greatest forum for it. Would you like me to go find you a blog post about proprietary vs open/standardized programming languages so people can clap for you there? Even when provoked about your statements you don't manage to say more than "Anthony, I read you post" do you have anything at all to say germane to this discussion?

Posted by: Anthony D. Green | Mar 14, 2005 4:28:30 PM

I think my point is right on topic. The fact is there are many VB6 programmers who want support for VB6 to continue.

As this article points out:
Developers slam Microsoft's Visual Basic plan
"More than 100 influential developers using Microsoft products have signed a petition demanding the software company reconsider plans to end support for Visual Basic in its "classic" form."

Sure, VB6 programs can be made to interoperate with VB.NET and some with some effort can be ported but the fact remains that a significant number of developers are not interested in these options. Obviously what they want is the language to be fully supported and development to continue on it but on a VB6 branch.

The only reason this isn't happening is because Microsoft is not interested in this option and not due to a lack of developer interest.

So of course, if you have a major dependency on a vendor's proprietary language, toolkit and tools, you need to evaluate that dependency and risk. As this move shows, Microsoft's interest may not always align with their customers. By simply moving to a non vendor controlled solution, that risk is eliminated.

Perhaps you too should spend some time on those "M$" sites you mention and perhaps you'll learn to think about these issues.

Posted by: Joe | Mar 15, 2005 6:20:24 AM

Excellent post joe, quite meaty.

I'd like to know how much of VB6's current support is still being utilized. At this point it seems like they don't want Microsoft to say they aren't supporting it even if they will never need support again. I'd need some statistics on how many phone calls they get about VB6 these days.

I've been thinking about these issues for as long as I've been having discussions like this. I was happier about .NET because of the free VB.NET compiler and the mono-project, etc, etc. I've always read about the horrors of proprietary everything and I took a gamble and I don't think I've lost more than I've gained. With a non proprietary language either a language won't change (which would be effectively the same as VB6 just existing) or it will (which doesn't mean you'd get anymore say so over the language). I'm just happy that VB.NET is a language now, not a language/tool hybrid.

"But MVPs hope Microsoft will reconsider not just VB6's support options, but will continue to develop the language alongside its newer Visual Basic.Net"

'By providing a new version of a COM-based Visual Basic within the Visual Studio IDE, Microsoft will help maintain the value of its clients' existing code, demonstrate its ongoing commitment to the core Visual Basic language, and greatly simplify the adoption of VB.NET by those that wish to do so,' the petition says. 'The decisions of if, how, and when to migrate code to .NET should lie with the customer.'"

And therein lay the problem. Its not just tech support calls, I've heard it from the mouths of these people. They want a VB6-2. As all the people who haven't migrated code to .NET (including myself) have demonstrated the decisions of if, how, and when to migrate to .NET do currently lay with the customer.

A lot of people point fingers at how they have C# and C++ but they don't get that C++ is there only because it facilitates the rest of .NET. Not only is C++ fundamentally a different beast from VB6 entirely. Managed code is managed by something, the CLR, which is a native executable. Some language has to not compile to IL to facilitate all the other languages. It's a matter of bootstrapping. Furthermore C++ has to exist to allow for the performance critical situations where you need to promote some native concept to a managed API. C# and Basic can call into native code but they can't promote native code to managed code such Managed DirectX 9.0. C# and Basic are using an abstraction. Managed Extentions for C++ .NET is what does the abstracting.

Posted by: Anthony D. Green | Mar 15, 2005 8:28:43 PM

VB.NET Learning curve

When I first saw VB.NET I hated it, I thought it was gonna be horrible to learn, but that's more perceived fear than actual problems. There is a huge learning curve to the language only if you think you're gonna learn the entire .NET library tomorrow.

When you start off with VB.NET you need to know how to instantiate a form, the new FileOpen functions, and how to reference and draw ActiveX controls. If you know that you can be immediately productive in .NET because the old VB6 functions are in the Microsoft.VisualBasic namespace, and they are automatically imported. The forms and code editors work basically the same and only a few keywords were lost. You don't have to learn OOP (though in VB6 you were using it the whole time). You can still do things the VB6 way adding 1 file for every class or module or form. In most cases VB6 developers just -think- they -have- to learn more than they do.

People are approaching the language 100 steps at a time and that's why they're scared and saying "might as well learn C#" and of course the C# coders are saying "yeah learn C# because VB.NET has wierd syntax" - Of course a C# coder is going to say the syntax is wierd. It's like me saying Delphi has wierd syntax (it does, I swear it does!). I don't use Delphi, of course it looks wierd to me.

As you get deeper you wanna know how to do more stuff and you learn as you go roughly one namespace at a time and you learn. VB6 devs should not be sweating falling over themselves to upgrade their code at once. They should be learning VB.NET on the side in small increments. If you just hop into .NET and upgrade a .vbp to a .vbproj you're gonna be screwed. You aren't gonna know anything and you're gonna be frustrated. When you know what's in that huge library you can run anything through the upgrade wizard and it'll be a lot easier. It'll be tedious. You'll think a lot about "I can do this better now". You'll say "what was I thinking when I wrote that? I can refactor this, I can design this better, let me use..." A C++ programmer ain't just gonna fall into it C# or Managed C++ either if they're use to the STL. But once you are in the managed world you can start pulling your stuff from the other side like STL .NET The VB6 devs just gotta stop overleaping themselves and maybe watch some of the VB @ the movies vids or that really cool Modern Software Development webcast.

Just like some people feel "Just switching to [language here] now will be tough but better for you in the long run" Microsoft moving it's agenda to .NET, WinFX and managed code is tough but better for everybody in the long run. Both are tough love to prevent problems down the line.

I'd still like to read about the places where VB6 devs are having trouble instead of "this sucks I can't do anything I hate this language it's like VB Fred nothing works why does Microsoft hate me?"

Maybe some really gifted VB.NET programmer will write a better upgrade wizard.

Posted by: Anthony D. Green | Mar 15, 2005 9:06:24 PM

Tips for upgrading in no particular order.

#7. Upgrade the easy stuff and encapsulate what won't port. If you have printing logic put it in a COM component and use interop to still leverage it.

x.) Realize that the .NET Framework is big and don't expect to own it anytime before you die: One of my first .NET apps was to use reflection (yeah it was painfully easy). It's called Enumerate FxCL.exe. I may have left out some libraries but this is an exerpt its output:

-----------GRAND TOTAL:--------------------
The .NET Framework Class Library contains 8,633 types (Classes, Structures, Interfaces, Enumerations, etc) comprised of:
166,427 methods,
21,018 fields,
36,176 properties,
and 11,908 events.

$. If you can make the jump from integers to User-Defined Types you can make the jump from UDTs to Structures and *Structures (normal people call them classes). If you don't have the time to learn VB.NET while maintaining your code base in VB6 you certainly don't have the time to learn C# or C++ or Java.

Posted by: Anthony D. Green | Mar 15, 2005 9:39:18 PM

I see that some of the comments are recycling all the old myths about VB6, VB.NET and upgrading.

If anybody wants to read some facts about why the petition was set up, visit the FAQ page here: http://classicvb.org/petition/faq.asp

Posted by: Jonathan West | Mar 16, 2005 3:00:44 AM

> VB.NET is really just C# without the braces

RBL: C# is really just VB.NET with braces. :p

Posted by: Jim | Apr 27, 2005 8:35:48 AM

I have been coding in VB, QuickBasic (PDS), QBasic, and Microsoft Basic OS for 25 years, and I don't get it. For decades, Microsoft was the company that "got" upward compatibility. Back a couple of decades ago, I can remember it being a struggle to come to a profound understanding of event driven code and actually letting the operating system have control before my program terminated. However, I soon learned that I could cut-and-paste huge portions of existing code into procedures, and that they would run without modification. I eventually cleaned up this code, taking out the GOTOs and GOSUBs, but I didn't have to! I remember when class modules and user control modules were added to VB. I now have a whole library of my own user controls, such as labels and buttons that have rich-text on them that can be pasted onto the control from WordPad. However, the important point is that I could ignore these new features until I needed the advanced functionality they offered. With VBNET, so much of my library is "broken" that it's too much work to change. I love learning new things, but I HATE being told that I have to.

On the COM vs NET (i.e., managed vs unmanaged code) framework: personally, I couldn't care less about this so long as I can still call DLLs, make API calls, build Access databases, and automate Microsoft Office applications. Furthermore, I can't understand how this dichotomy drives many of the changes made in VBNET. For instance, what's the deal with making all arrays zero bound? This breaks so much of my existing code that it's ridiculous, and what’s this have to do with COM vs NET? Sure, I can write a wrapper for each of my arrays so that they are zero bound, but why should I have to? Why doesn’t Microsoft add an “Option ArraysAnyBound” statement to the language which will allow arrays dimensioned with negative subscripts, or whatever. Wouldn’t it be trivial to push this down into the bowels of VB so the programmer doesn’t have to worry with it?

What’s with changing all arguments to ByVal? Once again, why break everything? Why not have an “Option ArgumentsByRef” statement that fixes legacy code? I have gotten VERY familiar with keeping track of what is passed ByRef and what is passed ByVal. Why break so much existing code? Sure, code translators can attempt to fix this, but why do we need to bother?

The “short circuit logic” also breaks a great deal of code. Once again, I can’t see how this has anything to do with the COM vs NET issue. I have gotten very comfortable with using a “Select Case True” statement when I am testing for several conditions and I want to jump over certain evaluations when an earlier one goes true. However, if I write “If ThisFcn() Or ThatFcn() Then” I expect both ThisFcn() and ThatFcn() to execute. In fact, I may depend on it. Once again, why not have an “Option NoShortCircuitLogic” statement in the language?

This one may be a little more difficult, but why do away with fixed strings? I use them frequently in structures (User Defined Types; UDTs), and I know exactly what to expect, even with the invisible ASCII to UNICODE conversion issues when writing to files? Are the hoards of programmers at Microsoft just too lazy to implement this feature?

Why change the value of “True” from -1 to +1? I know that other languages use 0 and 1 (or +1) as true bit operators to indicate “False” or “True”, but, since the beginning of time, a “True” in basic has been a two-byte integer will all the bits turned on (i.e., -1). This brings up another point. What’s the deal with changing the Logical Operators to pure Boolean Operators. Any VB6 programmer worth his (or her) salt knows that all the Logical Operators are actually bitwise operators in all cases. If you don’t believe me, try “Debug.Print CInt(True Xor 5)”. I’ll let you figure out the results. In VB6, when forced to make a Boolean interpretation, such as “If …”, anything that wasn’t ZERO was True. This is why some novices can’t understand why “If 1 And 2 Then …” evaluates to False. However, I digress. The point is, why “break” all existing code that is based on these understandings? Once again, why not have an “Option LogicalsAreBitwise” statement that allows legacy code to execute unaltered?

Why did Microsoft do away with statements that didn’t seem to do any harm. The LSET is a good example. I frequently deal with motion capture data files that have data stored in old DEC VAX floating point formats. I have routines that use LSET to convert this data to the IEEE floating point format. Sure, I can rewrite this code using the CopyMemory API call, but why am I being forced to? In fact, I have some old accounting applications that store data in the old Microsoft Binary Format (MBF) formats from the old QuickBasic days. Rather than writing data file conversion routines, I simply convert the MBF to IEEE in memory, do the math, and then convert back to MBF before I write it to disk. Why break these procedures? They have served me well for decades.

I could go on, but I will stop. To summarize, why not provide a set of “Option ???” statements that modify VBNET to be as compatible as possible with VB6, hopefully, completely compatible, at least at the level of the core language. I will learn how to use the new features, such as multithreading, polymorphism, and overloading as I need them! I would love to upgrade but, because of my extensive library, I am stuck in VB6, and I will badmouth VBNET to younger programmers at every opportunity until the issues of “upward compatibility” are addressed in a respectful and thorough way.

Posted by: Elroy Sullivan, PhD | Jun 8, 2006 1:52:03 PM

I am doing one Migration from VB6.0 to VB.Net. With he Upgrade Wizard Tool of Visual Studio 2005, I am able to get the .net code. But it includes on namespace as,
Imports VB = Microsoft.VisualBasic

Then there are several statements used in the code like
VB6.ShowForm(myObj, VB6.FormShowConstants.Modal)

I think this use of VB6 functions don't fallunder managed code. Is ity correct? If so, then whether there will be any performance issue?


Posted by: Debjani | Mar 21, 2007 11:56:11 PM

wat ru doing

Posted by: Hannah Sample | Apr 3, 2008 6:50:00 PM

The comments to this entry are closed.