Myth-Busting Busting

Posted by Phil Weber on March 17, 2005

The Classic VB petitioners have posted a FAQ page explaining their goals and the motivations behind them. (Hint: Contrary to what you may have read elsewhere, the impending end of mainstream support for VB6 is not the primary issue!) On the lower portion of that page is a section titled, “Myth Busting” which includes a myth of its own:

To take a trivial example, there is no defensible reason why a QuickSort algorithm should need to be rewritten because you have a new compiler for a language targeting a new platform.

Is it true that a VB6 QuickSort algorithm must be rewritten in order to recompile it for .NET? Let’s see…

Here’s a VB6 QuickSort implementation I found on the Web:

Public Sub Quicksort(ByRef list() As Integer, ByVal min As Long, _ 
    ByVal max As Long)

    Dim med_value As Long
    Dim hi As Long
    Dim lo As Long
    Dim I As Long

    ' If min >= max, the list contains 0 or 1 items so it is sorted
    If min >= max Then Exit Sub

    ' Pick the dividing value
    I = Int((max - min + 1) * Rnd() + min)
    med_value = list(I)

    ' Swap it to the front
    list(I) = list(min)

    lo = min
    hi = max
    Do
        ' Look down from hi for a value < med_value
        do while list(hi) >= med_value
            hi = hi - 1
            If hi <="" lo then exit do
        loop
        if hi <="" lo then
            list(lo) ="" med_value
            exit do
        end if

        ' swap the lo and hi values
        list(lo) ="" list(hi)

        ' look up from lo for a value >= med_value
        lo = lo + 1
        Do While list(lo) < med_value
            lo ="" lo + 1
            if lo >= hi Then Exit Do
        Loop
        If lo >= hi Then
            lo = hi
            list(hi) = med_value
            Exit Do
        End If

        ' Swap the lo and hi values
        list(hi) = list(lo)
    Loop

    ' Sort the two sublists
    Call Quicksort(list, min, lo - 1)
    Call Quicksort(list, lo + 1, max)

End Sub

And here’s the same implementation in VB.NET:

Public Sub Quicksort(ByRef list() As Integer, ByVal min As Long, _ 
    ByVal max As Long)

    Dim med_value As Long
    Dim hi As Long
    Dim lo As Long
    Dim i As Long

    ' If min >= max, the list contains 0 or 1 items so it is sorted
    If min >= max Then Exit Sub

    ' Pick the dividing value
    i = Int((max - min + 1) * Rnd() + min)
    med_value = list(i)

    ' Swap it to the front
    list(i) = list(min)

    lo = min
    hi = max
    Do
        ' Look down from hi for a value < med_value
        do while list(hi) >= med_value
            hi = hi - 1
            If hi <="" lo then exit do
        loop
        if hi <="" lo then
            list(lo) ="" med_value
            exit do
        end if

        ' swap the lo and hi values
        list(lo) ="" list(hi)

        ' look up from lo for a value >= med_value
        lo = lo + 1
        Do While list(lo) < med_value
            lo ="" lo + 1
            if lo >= hi Then Exit Do
        Loop
        If lo >= hi Then
            lo = hi
            list(hi) = med_value
            Exit Do
        End If

        ' Swap the lo and hi values
        list(hi) = list(lo)
    Loop

    ' Sort the two sublists
    Call Quicksort(list, min, lo - 1)
    Call Quicksort(list, lo + 1, max)

End Sub

Can you spot the difference? (If you intend to point out that Integers and Longs are different sizes in VB6 and VB.NET, please include an example demonstrating how that difference affects the algorithm’s behavior.)

Here’s another:

Why not leave functioning code in VB6, and write new code in VB.NET?
That's a fine solution for the problems it fits. Many developers can indeed let existing applications linger in VB6 forever (assuming future OS changes don't break them), and concentrate all their efforts on developing new VB.NET-based applications. For the great majority of VB developers, however, there is continuing need to revisit and revise legacy applications. While Microsoft may no longer want to support VB6, great numbers of VB6 developers still intend to support their customers with ongoing bug fixes and application enhancements.

Ahem. What prevents VB6 developers from supporting their customers with bug fixes and application enhancements in VB6? Nothing. That’s exactly how my employer is supporting its customers’ VB6 code.


Comments

Posted by Karl E. Peterson on March 17, 2005:

Good point on the QuickSort. Can you do the same with a CRC32 algorithm?

As to offering ongoing support for deployed VB6 applications, how do you respond to Micrsoft’s demonstrated ability/willingness to break them in the field? http://support.microsoft.com/?kbid=321047 When the obligation of support is gone, what makes you believe they’ll issue OS service packs addressing issues like this?


Posted by Jeff Atwood on March 17, 2005:

Forget the goofy petition


Posted by Phil Weber on March 17, 2005:

Good point on the QuickSort. Can you do the same with a CRC32 algorithm?

Amazingly, yes! I Googled for “vb crc32 algorithm”, and grabbed the first result: http://www.vbaccelerator.com/home/VB/Code/Libraries/CRC32/article.asp . I copied the cCRC32 class from that project and pasted it into a VB.NET project. I had to change Private Sub Class_Initialize() to Public Sub New(), and I replaced calls to Steve’s custom cFileStream class with calls to .NET’s built-in FileStream (which accepts an additional parameter). Frankly, even I was surprised that the VB.NET version produced the same result as the VB6 code!

When the obligation of support is gone, what makes you believe they’ll issue OS service packs addressing issues like this?

You’re right: IF a future update to Windows breaks VB6 apps, and IF MS refuses to issue a patch, and IF it’s not something you can easily work around in your code, THEN you’ll have a problem. The VB6 runtime will be supported on Windows XP, however, until 2013, so we’re talking about potential problems 8 or more years from now.

In addition, there are products available to insulate VB6 apps from changes to shared DLLs: http://www.thinstall.com/help/?visualbasicruntimelinking.htm . With a product like this, the whole “Microsoft might break my app” issue becomes moot.


Posted by Bruno on March 21, 2005:

Rod’s Quicksort: http://www.vb-helper.com/howto_quicksort.html

is a good example demonstrating that translating to .NET is not trivial, but could be confusing - first argument was incorrectly translated to “ByVal list() As Integer” in:

http://www.vb-helper.com/howto_net_quicksort.html


Posted by Rob Abbe on March 21, 2005:

Always the MS suck up.

You’ve greatly over simplified the problem. Try taking a real application that consists of several hundered forms and user controls and make that work as slick as you did your quick sort. Try taking something that does some real database access and replace it. As you well know virutually every VB application consists fo forms, user controls and classes that do real work. The VB migration tool takes all of this and creates a big pile of pasta.

Try convincing third party vendors to continue support for dated products. Try implementing modern OS features like the mouse wheel in VB, when other development tools include support for it in their libraries.

Real life isn’t so black and white. Facts are facts and there is nothing you can do to sugar coat the truth.

Stop being an MS whipping boy.


Leave a comment