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?
+4
A:
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.
abrereton
2010-10-21 01:51:28
+1 for Windows Compat
p.campbell
2010-10-21 01:52:52
It may work in Windows Compatibility mode, but I'm guessing that would hurt sales
JoelFan
2010-10-21 01:54:47
@JoelFan: How so?
casablanca
2010-10-21 01:56:58
@JoelFan, why would that hurt sales? My understanding is that compatibility mode is relatively seamless.
paxdiablo
2010-10-21 01:57:25
@JoelFan: You're still selling 20 year old software?
Travis Gockel
2010-10-21 02:04:04
@JoelFan, why would it hurt sales? Are you kidding? Customer buys product. Customer installs product. Product does not work. Customer returns product. Sales go boom.
JoelFan
2010-10-21 02:12:53
@Travis, I'm not selling it... my former employer is.
JoelFan
2010-10-21 02:13:26
@JoelFan, your little timeline above has an assumption ('Product does not work') - I think what the answers were getting at was that hopefully, with the Compatibility box, the product _would_ work. That may not be the case now, seeing abrereton's update.
paxdiablo
2010-10-21 02:32:33
@paxdiablo, the customer is not going to know about compatibility mode or even if they do, they are not going to think it's worth it. This is not a business-critical app, it's a consumer app sold in shrink-wrapped boxes. It doesn't take much to generate a return in that market.
JoelFan
2010-10-21 02:39:54
@JoelFan, this sort of thing is well established. I've had (older) games that I've bought that needed something downloaded from the internet to get them to work. Better, this is something that the installer should do. In other words, the company should either get someone to redo the installer to flag the executable as requires-compat-mode or, at a minimum, add a flash device or something with a little exe that does that for the customer. Put that device with instructions (or just instructions on how to get the updates from the web, if the company is a tightwad) into the new packages.
paxdiablo
2010-10-21 02:44:47
But there's no point discussing those options if the thing won't even run in compat mode. I agree that asking the customers to run Virtual PC is probably too much. Maybe the company should just ensure the doco says supported platforms stop at XP. Then, if they want more customers, they have to invest in upgrading the software. You can only milk a dead cow for so long :-)
paxdiablo
2010-10-21 02:46:38
+2
A:
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 :-)
paxdiablo
2010-10-21 01:53:03
Yeah I am kind of disappointed in myself for that, but keep in mind that this was in the floppy-disk era. Also I've moved countries since then :)
JoelFan
2010-10-21 02:23:46
A:
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.
p.campbell
2010-10-21 02:00:22
@p.campbell , there's a reason I moved on back then :) I had a hard time convincing them to move from DOS to Windows.
JoelFan
2010-10-21 02:26:51
+2
A:
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.
Igor Skochinsky
2010-10-21 09:58:37
+1
A:
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.
Kate Gregory
2010-10-21 13:53:39
Manifests don't apply to 16-bit apps. And the access rights are not the issue anyway; the issue is that Win7 x64 doesn't support 16-bit applications at all, be they DOS or Win16.
Igor Skochinsky
2010-10-21 16:18:59