I have not done a thing with Visual Basic 6 for years, but a contact of mine has done a very useful utility in a certain niche (it is the teaching of Contract Bridge though you do not need to know about bridge to follow this post) and his preferred tools are VBA and Visual Basic 6.

Visual Basic 6 is thoroughly obsolete, but apps compiled with it still run fine on Windows 10 and Microsoft probably knows better than to stop them working. The IDE is painful on versions of Windows later than XP but that is what VMs are for. VBA, which uses essentially the same runtime (though updated and also available in 64-bit)  is not really obsolete at all; it is still the macro language of Office though Microsoft would prefer you to use a modern add-in model that works in the cloud.

Specifically, we thought it would be great to use Bo Haglund’s excellent Double Dummy Solver which is an open source library and runs cross-platform. So it was just a matter of doing a VB6 wrapper to call this DLL.

I did not set my sights high, I just wanted to call one function which looks like this:

EXTERN_C DLLEXPORT int STDCALL CalcDDtablePBN(
   struct ddTableDealPBN tableDealPBN,
   struct ddTableResults * tablep);

and the ddTableResults struct looks like this:

struct ddTableResults
{
   int resTable[DDS_STRAINS][DDS_HANDS];
};

I also forked the source and created a Visual C++ project for it for a familiar debugging experience.

So the first problem I ran into (before I compiled the DLL for myself) is that VB6 struggles with passing a struct (user-defined type or UDT in VB) ByVal. Maybe there is a way to do it, but this was when I ran up Visual C++ and decided to modify the source to make it more VB friendly, creating a version of the function that has pointer arguments so that you can pass the UDT ByRef.

A trivial change, but at this point I discovered that there is some mystery about  __declspec(dllexport) in Visual C++ which is meant to export undecorated functions for use in a DLL but does not always do so. The easy solution is to go back to using a DEF file and after fiddling for a bit I did that.

Now the head-scratching started as the code seemed to run fine but I got the wrong results. My C++ code was OK and the unit test worked perfectly. Further, VB6 did not crash or report any error. Just that the values in the ddTableResults.resTable array after the function returned were wrong.

Of course I searched for help but it is somewhat hard to find help with VB6 and calling DLLs especially since Microsoft has broken the links or otherwise removed all the helpful documents and MSDN articles that existed 20 years ago when VB6 was hot.

I actually dug out my old copy of Daniel Appleman’s Visual Basic Programmer’s Guide to the Windows API where he assured me that arrays in UDTs should work OK, especially since it is just an array of integers rather than strings.

Eventually I noticed what was happening. When I passed my two-dimensional array to the DLL it worked fine but in the DLL the indexes were inverted. So all I needed to do was to fix this up in my wrapper. Then it all worked fine. Who knows what convoluted stuff happens under the surface to give this result – yes I know that VB6 uses SAFEARRAYs.

I do not miss VB6 at all and personally I moved on to VB.NET and C# at the earliest opportunity. I do understand however that some people like to stay with what is familiar, and also that legacy software has to be maintained. It would be interesting to know how many VB6 projects are still being actively maintained; my guess is quite a few. Which if you read Bruce McKinney’s well-argued rants here must be somewhat frustrating.