I write a programming column for Personal Computer World. A reader contacted me with a problem. He had an application which he knew was written in Visual Basic 3, but for which he did not have the source code. He now wanted to adapt it to run on Windows Mobile.
VB 3.0 came out in 1993, a mere 15 years ago but an eternity in Internet time. It was hugely popular, partly because it included the JET database engine, the same one as used by Microsoft Access. Both professionals and keen amateurs used it to create little (and not so little) business apps. VB 3.0 is 16-bit, and although these apps may still run OK on Windows XP or Vista 32-bit, though perhaps with a few cosmetic glitches, they will not run on 64-bit Windows, which has no 16-bit emulation layer.
Not many organizations are moving to 64-bit desktops just yet, though they may well do so in a couple of years, but there is still a problem if you need to adapt or port the code.
I thought this would make a fun case study so I wrote it up in the May 2008 column. I tracked down the VB3 decompiler put out some years back by Hans-Peter Diettrich, also known as Dodi. He gave me a demo version to distribute to readers. The app in question turned out to be very simple, and decompiled easily. I then imported the project into VB 6 (because later versions won’t look at VB3 apps), and finally pulled the VB6 conversion into Visual Studio 2008. Once I’d fixed up the Windows version, I created a new Compact Framework solution into which I copied code from the desktop project. Much of the code made it all the way from the VB3 original to the Compact Framework, and ran fine on my IPAQ Pocket PC.
Working with decompiled code is a bit like solving a crossword puzzle. Variable names are mangled so you have to work out what they are for. It won’t be a quick and easy process except in the simplest of cases.
The incident makes me wonder: how many business-critical apps with lost source are out there? Someone posted a cartoon recently which I can’t now track down, but it was a graveside scene. One mourner says to another, “I’m sorry to ask at a time like this, but did he say anything about source code?”
Its on Jesse Liberty’s blog aswell.
http://silverlight.net/blogs/jesseliberty/archive/2008/03/24/back-up-your-code.aspx
Great stuff.
I once read a similiar article about a system administrator writing a column about programming (don’t ask).
He stated he was asked by a client to rewrite an internal application to support windows because it was a DOS-based application.
The sys admin said he remembered how easy it used to be in Visual FoxPro 9 and tried it.
He did however have to track a local copy of FoxPro 9 of his local ebay, because no store around would sell it. (You’d think that he would rethink his tool set by then)
So he rewrote it, and got it working, and was wondering why oh why Microsoft stopped supporting FoxPro.
His conclusion?
It was working TOO good, so thats why Microsoft pulled the plug.
Well not so much losing code but what do style do devs use when naming variables?
I’m always quite verbose (which makes for lots of typing), but I always remember working alongside a developer who couldn’t be bothered with long variable names and shortened everything to four characters long! Great until he needed to re-visit the code months later and didnt have a clue what variables were for what!
Of course de-compiling interpreted languages is pretty straight-forward and I remember from the dim and distant past using refox as per the other posters reference to foxpro and using it that to decompile a foxpro app.
Gary