On the lack of sympathy for the VB.Classic crowd...

I’ve gotten a bit of feedback from people saying I should have a some sympathy for people who have all of their business assets tied up in VB6 code. I’ve even been borderline accused of not being a BASIC man at heart… boy, that’s a shocker.

Well, let me clear up a few things.

Microsoft VB6 to VB.NET Upgrade Wizard

OK, this tool could use a lot of work. However, to say that it doesn’t help you migrate your code is a complete lie. Does it get your 95% of the way to .NET? Probably not; however, could just as easily be a “yes, it sure will”. All of this depends on your type of application and how you’ve structured your code. If your application is a business application written in 100% VB6 (no Win32 calls, no 3rd-party controls) and you’ve leveraged using Classes for your business layer, then you will probably achieve very good success in translating the code. As for the Win32 calls, I’ve had excellent luck in converting that using the upgrade wizard as well; with the only real problem that I can remember surrounding using structures containing arrays.

This weekend, I decided to find a VB6 application to convert to VB.NET… one that I would figure would be somewhat complicated… a clone of Pac-Man. This application is using BitBlit like crazy and relies on the Forms 2.0 behaviors (redraw method). I ran this though the conversion tool and sure enough, had a few errors (about 125). In this example, all of the errors were surrounding BitBlit using PictureBox’s hDC and Clear method (which .NET doesn’t have). My first thought was to use the GetDC() API since I could get the PictureBox’s Handle (which is the hWND), but I then had to use ReleaseDC(). So this turned very line of code into 3; one ot get the device context, one to do the BitBlit and the other to release the device context. This worked, but the speed was horrible. (You need to keep in mind that this is not my code, I just picked something off of PlanetSourceCode that looked like it would be difficult to convert… and somewhat fun in the end.) So I looked at the code closer and moved the GetDC and ReleaseDC outside of the loops. I then realized that I could remove the GetDC and ReleaseDC and use methods within the Graphics namespace to get this information. Making these changes, was able to get the performance up to the point that it was the same as the original version. I’m not finished with this as yet, mainly because in order for me to work around the Redraw issue (Forms 2.0 behavior), I had to make the original image visible on the screen… otherwise BitBlit didn’t want to work properly.

What am I going to do next? Well, now that it’s working in VB.NET… all of the game play logic will be kept intact and I’ll be focusing on how the screen is being drawn. In some cases, at least with this code, the display logic and the game logic are intermingled. Probably not the best design, but it worked so can’t really complain about it too much. But the fact is, in this example, the assets translated over to VB.NET with little difficulty and took me about an hour.

Now this example may not be the same as whatever application you are thinking about converting, but I think it shows what might be involved. Some people will run the wizard and because the application doesn’t compile immediately and they see a list of 200 errors, they give up. If they would look closer, they’d find that those errors are probably duplicated several times over. Once you find the solution to one of them, it can be duplicated for the rest. This is where I think the Upgrade Wizard could use some work. If there is a workable solution to something that is pretty simple, even if it may not be considered “correct”, then it should be able to add that. However, I understand that the conversion tool can’t take everything into account and their solutions may not fit with what developers consider correct. So what is the solution?

What I would like to see is take the existing Upgrade Wizard and allow for some capability that would allow us, the developers, to extend the conversion process by allowing us to define certain programming patterns and resulting VB.NET code. Not really sure how to accomplish this, but I would think that it would be possible. This way, you could run the wizard, review the errors, find the solution to some of the major ones, add those to the conversion engine and run the wizard again.

Now some people would say Refactoring is the answer here. That is probably true, but I think that in this case this is so specialized and if it were to be put into the Upgrade Wizard, these patterns could be shared on a website for others to leverage for their upgrade process.

VB6 IsNot VB.NET

(I just couldn’t resist the IsNot keyword.)

This is true. If it were, what would be the point? However, some argue that it’s not an upgrade. Well, I’m here to say that it is. It is every bit an upgrade in the sense that it’s the next generation of BASIC coming out of the walls of Microsoft. In many cases, they’ve done things that should have been done 10 years ago. Sure, there are a lot of changes. Technology changes and so does the tools to leverage that technology. We get paid for a reason folks.

Some say that it’s so drastically different that it should be called something else. Well, lemme see if you can tell what version of BASIC this is written in?

Sub TestMethod
  Dim x As Integer
  Dim a As Integer
  Dim b As Integer
  For x = 1 to 100
    a = a + x
    b = 0
    Do
      Select Case b
        Case 10
          ' Do something special.
        Case 20
          ' Do something else special.
        Case Else
          ' Do nothing at all.
      End Select
      b = b + 1
      If b > a Then
          Exit Do
      End If
    Loop 
  Next
End Sub

The above code (although I wrote it directly in here and haven’t actually tested it) should work in any version of Microsoft BASIC released since QuickBASIC 4.5. Still looks like BASIC to me. Oh, but some would complain that the value of an Integer is different. This is true, but how does this change the code? Also, because the potential numeric sizes of those variables increased, how does that effect your code (written in VB)? The only time it matters is if you are using Win32 and, for that, the new definitions actually make life easier since they match the platform and nearly every other mainstream development language out there.

My point here is that the parts that make up the BASIC language are in VB.NET. How the language inter-operates with the platform, that’s what has changed. What many people are missing is the fact that it is a new platform, just because it runs on Windows XP (or whatever) doesn’t change that fact. It’s every bit as different as moving from Win16 to Win32 (and, as someone pointed out in a previous comment, it’s the move to WinFX).

End of Support for VB6

A few others, that work for Microsoft, have already pointed out that support for VB6 is not technically ending, just one small phase of it is. The support that is ending is mainly the two free incidents that you got when you purchased VB6. (Oh, yeah, that’s headline worthy news. Wait, there goes my sympathy again… back on track now.) Now, let’s look at a reality check here. If you haven’t used your two free incidents in the past, what makes you think your going to? I could use some arbitrary length of time, but I don’t know when you actually purchased your copy of VB6. Personally, I got mine the day it was released and I never used one incident (that’s seven years). But let’s say that you bought your copy just before the release of VB.NET (not sure why that would have happened, but let’s use it as a date to work with), if you haven’t used your incidents in 3 years… what’s the big deal?

Applications written in VB6 potentially failing on future OS / Service Packs

This one is pretty ridiculous, but I’ll dig into it anyway. Just because Microsoft isn’t selling VB6 (or “supporting it”), doesn’t mean your applications written in VB6 will suddenly stop working. However, there is a gotcha here. Microsoft will be sure that applications written in VB6 will continue to work for the foreseeable future, but that doesn’t guarantee that your application will work. Your application could be leveraging features (or security flaws) with current operating systems that may not be available with a future operating system. This means Win32 calls and third party components that are leveraging Win32 API’s. The VB6 runtime and COM aren’t going to disappear anytime soon and will be supported in future service packs and operating systems. (I know I’m kind of repeating myself here, but apparently people aren’t getting it.) I’ve also heard that the VB6 runtime will be shipped with Longhorn (just as it was with Windows XP). And because the runtime is shipped with Windows XP, that draws its support out to another 5-7 years after Windows XP is no longer “supported”.

What does this all mean?

So, Visual Studio .NET 2002 was released three years ago and Visual Studio 2005 (notice the removal of .NET?) will be released toward the later part of this year. That’s three years that the writing has been on the wall. There’s a balance between supporting applications for the OS of today and planning for the future of where the OS will be tomorrow. The writing on the wall (as I stated, since it doesn’t seem to be very obvious) is that .NET is the future. Some people talk about jumping from the Microsoft ship over to some alternative, so I think it’s appropriate for me to burst that bubble. One person that I saw comment to this issue on another blog mentioned that they are tired of VB because Microsoft hasn’t given them the ability to leverage XP Visual Styles in VB6 (although that is not true, you just add a manifest file), they are switching to Java. OK, I want them to try the same thing in Java. ;-) However, leaving that part out, migrating their code to Java… oh, yeah, that’s easier than moving to VB.NET. (Damn, there’s that lack of sympathy thing rearing it’s ugly head again.) Oh, they say they don’t want to be tied to Microsoft because they are just going to do this again in the next 10 years. I can’t argue against that, however, I will say that for the next 10 years, .NET is the way it is. And this isn’t just true of Microsoft, I strongly believe that it’s the future of development on all platforms. Yes, this means Linux, Solaris and Mac OSX. If the open source community has anything to do with it, .NET is the future. This community is moving forward so fast, it’s very hard to keep up with what’s going on.

So if you are tired of Microsoft… .NET is still the answer (technically it *an* answer, but in my opinion, it’s the answer). Go figure. ;-)

The point here is that there’s major change coming in the (very near future) in regards to the platform we are developing on. This was made clear with the changes to the development tools three years ago. In another 2 years, these people clinging onto VB6 are going be wondering why Microsoft didn’t tell them about all of this sooner. Some will resist the move and stick with obsolete tools targeting an obsoleted platform, some will scramble to catchup and lose market share meantime and other will decide to totally jump ship. For all of these people, I don’t have sympathy for. Yes, you read that correctly. I pity them, but that pity is not to be confused with sympathy. The writing is on the wall folks and it’s way past time to realize that the move is coming. Will your applications still run? Yes. Will they leverage the new platform? No. The choice is yours.

So what about the guys that don’t know what to do?

Get off your collective butts and start leveraging available resources. I’m a big fan of saying “don’t just complain about problems unless you have what you believe to be a possible solution”. As such, here are some solutions:

• Find out if there is a .NET Users Group in your area. Go there… not just once… but every meeting.
• Web casts… watch them.
• Install Visual Studio .NET 2003 and bang away at it. If it doesn’t make sense, don’t give up; keep at it and that light will turn on suddenly. When it does, you’ll wonder why it took so long. (If you have the option of running Alpha/Beta software, get the Visual Studio 2005 CTP builds.)
• Newsgroups and Message Boards… sign up and ask questions there (GotDotNet.com is where I hang out).
• Blogs… (well, you probably already know this if your reading this, but if you don’t…) get a blog reader installed and keep up with what people are saying. Even if it’s not relevant to you, you might still learn something.

Conclusion

I know I might be sounding a bit harsh on this subject. Sometimes I can be. However, sometimes people need a good slap across the face in order to clearly see reality in front of them. Without using too much abusive language here, I hope this can serve as a good punch in the nose… once the water clears from the eyes… maybe things will be a bit clearer. ;-)