VB3 decompiler?

Someone I used to work for emailed me out of the blue and said they want me to update开发者_运维问答 a VB3 (!!!) program I wrote for them because customers are reporting having problems running it under Windows 7. They have lost the source code (natch). Is there a decompiler for VB3?

For decompiling VB "DoDi VB3 decompiler" is the best tool available. The results are pretty good.

However the original is anno 1997. VB3 is 16 bit code only + still some bugs + no source code. These makes that tool hard to get running on windows beyond Windows XP and limits it's use.

DoDi's VBDIS3 it self is also written in VB3 - so about 10 years later just for fun I cracked it to make the decompiler to decompile it self. ... and ported it to VB6! So now you've the source code !!! :D

... and it's 32 Bit code + some bugfixes and improvements to the original:

DoDi's Visual Basic 3 Decompiler [Reloaded]:

http://vbdis4.angelfire.com

Screenshoot:

in case that website get lost Google for
'VBDIS3.67e_Reloaded_Rev3_DoDi_s_VB3Decompiler.7z'
or try the internet archive

http://web.archive.org/web/20090301170633/http://vbdis4.angelfire.com

I remember looking for Visual Basic decompilers/disassemblers a long time ago to no avail. There may be things out there now though. The most I could come up with was PE Explorer: http://www.heaventools.com/overview.htm

Have you suggested running your application under Windows Compatibility mode: http://www.sevenforums.com/tutorials/316-compatibility-mode.html

Edit: Further Googling: http://www.w7forums.com/visual-basic-3-0-compatible-64-bit-version-t5146.html

I maintain legacy 16-bit VB3 software that is compatible with Windows 7 and have done a lot of research in this area.

16-bit applications will not natively run in Windows 7 64-bit full stop. This is because when a 64-bit capable CPU is started in 64-bit mode, it cannot change into 'real mode' (the mode used by 16-bit applications) without a hard reset. If a processor is in 32-bit mode, it can swap between real mode and protected mode at will.

The only workaround here is a virtual machine- Windows 7 comes with a free version of Windows XP which is usable inside a custom version of Microsoft Virtual PC. Google for "Windows 7 Virtual XP Mode". Once your copy of Windows 7 has been validated as authentic, it will allow you to download Virtual PC and the XP Image.

It's definitely not a pretty solution, but the only option for my customers who have gone ahead and bought a 64-bit OS without checking to see if their installed software is 64-bit compatible.

Unlike the later versions which used native code and are generally not reliably decompilable, VB3 (and, I think, VB4) could be usually decompiled to almost original code. The keywords you need to search for are "DoDi VB3 decompiler" or "vb3dis". Here's a page that seems to have a copy.

Really? VB3, if it runs fine in XP, should be okay in the Windows compatibility box.

What I would do is to say that you couldn't find anything suitable (which is almost certainly true) but that you may be able to fix their problem for a moderate fee. Then, hopefully it's just a matter of setting a flag on the application (you may want to check this first to ensure it won't be too much work).

Money for Jam.

The other option is that you can offer to rewrite it for them in a more modern setting, using your vast knowledge of the application.

However, I'm surprised you don't have a copy lying around. I keep just about every piece of software I've ever written just in case (with permission for work-for-hire stuff of course), even down to the Fortran assignments I did at Uni back in the early 80s.

That's a good habit to get into, although I'm starting to wonder whether I should perhaps free up some space by ditching the Fortran :-)

There are a number of things you can do to help them without the source code. You could apply an external manifest if the application will only work when it is elevated. You could advise them to install the application somewhere other than Program Files (generally an awful idea, but might work in this case.) You could apply a compatibility setting or teach them how to install it into "XP mode" so it runs in an XP virtual machine.

Failing all of those, you could offer to rewrite it in VB.NET so they would get a more modern ui, Windows 7 features (not just capabilities) and would actually own the source code for their app. That might have value for them.

And yes, you should have kept the code. I have CDs burned from my old projects going back to the dawn of time (at some point I copied things from 3.5" backups to CDs while I still had some machines that could do both) and I have made more than one previous client happy by sending them the CD. It is a really cheap marketing investment, really.

It sounds like this is an application that is sold to customers, and is having trouble or doesn't work under Windows 7.

Consider advising the customer that the application should be:

• modernized, thereby easing the ability to add features/maintained
• otherwise run in XP Compatibility mode for their Windows 7 customers. Surely that number will only grow, and would become a support issue. Goto previous bullet.

Seriously though; your customer should realize that their software needs to be modernized. Hopefully you can persuade them of that long term goal; perhaps they already know that.