From my diary

It’s been an interesting couple of days.

I was working on the Passio of St Valentine, and I really felt that I could do with some help.  So I started browsing grammars.

This caused me to realise that many of the “rules” embedded in them were things that you’d like to have pop-up, sort of as an informational message, when you were looking at the sentence in a translation tool.

This in turn reminded me that my own morphologising tool, QuickLatin, was available and a natural candidate for such a thing.

This is written in Visual Basic 6.  I wrote most of it, actually, in Visual Basic for Applications, inside a MS Access database, during 1999.  (The language choice was dictated by the machine that I had available at the time, which had no development tools on it).  I then ported it to Visual Basic 6.  Microsoft then kindly abandoned VB6, without even a migration path, some time in the early 2000s.  This left me, and many others, stuck.  It is not a trivial task to rewrite 24,000 lines of code.

So where was my development environment?  I pulled out the last four laptops that I have used; I have them, because I keep all my old machines.  I found it on my Windows XP machine.  The machine started up OK!  In fact the batteries on the Dell laptops all started to charge, unlike a Sony Vaio which had Windows 7 on it.

The Windows XP machine had a tiny screen and was very old.  Could I perhaps install VB6 on Windows 10 instead?  The answer swiftly proved to  be a resounding “no”.  But I gathered a large number of tips from the web while doing so.

Then I tried installing VB onto my travelling laptop, which has Windows 7 on it, using all the info that I had.  The installation failed; but the software seemed to be installed anyway!

Then I tried doing it again on Windows 10.  This time I had a sneaky extra bit of information – to set the SETUP.EXE to run in Windows XP compatibility mode.  And … again it failed; but as with Windows 7, I could in fact still run it!

The process was so fraught that I knew that I’d never remember all the fixes and tips.  So I compiled all the bits together, hastily, into a reference guide on How to Install Visual Basic 6 on Windows 10, for my own use in days to come.

After two days of constant pain, I was at last in a position to work on the code!

But I wasn’t done yet.  I really would rather not work with VB6 any more.  Not that I dislike it; but it is emphatically a dead toolset.  My attempts to convert my code to VB.Net all failed.

But since I last looked, more tools have become available.  My eye was drawn to a commercial product, which Microsoft themselves recommended, by a firm called Mobilize.net.  The tool was VBUC.  You could get a free version which would convert 10,000 lines.  Surely, I naively thought, that would be enough for me?

Anyway I downloaded VBUC, and ran it, and discovered to my horror that I had nearly 30,000 lines of code!  But I set up a tiny test project, with half-a-dozen files borrowed from my main source project, and converted that.  The process of extracting a few files drew my attention to what spaghetti the codebase has become.  It was not trivial to just take a few.  This in turn made me alter the extracted VB code a bit, so that I could use it.

Converting the extract worked, but required some manual fixing.  However it did work in the end.

I was quite impressed with some of the conversions.  One of the StackOverflow pages had indicated that the firm were charging a couple of hundred dollars for the tool, back in 2010.  So I emailed to ask what they were charging now.

Mobilize.net then got a bit funny on me.  Instead of telling me, they asked me to tell them what I wanted it for.  I replied, briefly.  Then they wanted me to run an analyser tool on my code and send it in.  I did.  Then they wanted more details of what it did.  Quite a few emails to and fro.

By this stage I was getting fed up, and I pushed a bit.  They finally came back with a price, based on lines of code, of around $4,500!  That was ridiculous, and our exchange naturally went no further.

However I had not wasted my time, for the most part.  I could now see what the tool might do.  My code may be elderly, but some of the bits that were converted are basically the same throughout.  It is quite possible that I could write my own tool to do the limited subset of changes that I need.

One problem that was not handled well; QuickLatin loads its dictionaries as binaries, created by another tool of my own.  I found that VB.Net would not handle these, whatever I did.  The dictionaries would need to be regenerated in some other format.

So I spent some time experimenting with an XML format.  I quickly found how slow the VB6 file i/o was.  Reading a 20 mb file using VB native methods took 4 seconds.  Using MSXML to load the file and parse it into a linked list took 1.7!  I didn’t want the linkedlist method; but it was clear that the VB native methods were hideously inefficient.

I soon discovered complaints online that the VB.Net i/o did not support the methods used by VB6 and was even slower!  I’ve encountered problems of this sort before, which I got around by dropping into C++ and accessing the files through bare metal.  Clearly I would have to do so again.

Another problem that VBUC showed me was that VB6 fixed length strings were not really supported by VB.Net.  There was some sort of path, but it was horrible.  However there was, in fact, no reason to go that way; the file i/o, for which they were used, will have to change anyway.

I placed my code base under code control, using GIT.  Then I started cautiously making changes, checking that “amas” was giving sensible results – for unit tests were unknown in the days of VB6 – and committing regularly.  This proved wise; several times I had to go back to the last commit.

I spent quite a bit of time removing superfluous fixed strings from the code.  This was not trivial, but I made headway.

Something else I did, once I realised that coding lay ahead, was to rig up an external monitor, keyboard and mouse to my laptop.  I would have rigged up two, but there was no way to turn off the laptop screen – when you close the lid, the machine goes to sleep and that’s that.  On a commercial laptop, I’d set it to turn off the laptop screen and stay running.  Most graphics cards will support two monitors; the home laptops won’t support three.  Oh well.  But it was still better for serious work than using the laptop screen and keyboard alone.

Finally I started creating dictionary loading routines that would convert to VB.NET.  They are much slower; but I can optimise them when I get the code into VB.NET.  They have to change, come what may.  The key thing is to keep the program running and working at all times.  Take it slow.  Little by little If I take it apart into a million pieces, it will never get back together again.  Indeed this mistake I have made before.

Back in the 90s, automated unit tests, continuous integration, test-driven development and dependency injection were all  unheard of.  I have really missed having a set of tests that I can run to check that the code has not broken in some subtle way.  This again is a reason to migrate to VB.Net, where such is possible.  I did write test stubs in the original VBA, but there was no way to run them within VB6.  At least I have them still, and they can form the basis for unit tests.

So … it’s been a very busy few days indeed.  Nothing to show for it, to many eyes; but I feel optimistic.

The next challenges will be to change the other dictionaries over to the slow-but-safe method, and then remove all the stuff that supported the other approach.  This should simplify the code mightily.  Once this is done, then it will be time to attempt to convert the code.  Somehow.  All I need is time, and with luck I shall have some of that this week.

It is remarkable how far down the rabbit-hole one must go, just to get a bit of online help!