port vb3 app to 32 bit with no source code — chances of success?

Question

I have a potential client who sells a VB3 app, for which he lost the source code. It does not run on Windows 7 64-bit because the app is 16-bit. Only 32- and 64-bit programs will run on 64-bit Windows. (Well the 16-bit app would run in XP mode, but the end users will not accept that)

In order to accomplish this I would have to:

1. Find a copy of Visual 3.0 (full) (perhaps from http://www.emsps.com/oldtools/msvb.htm#vb3)
2. Find a USB floppy drive so I can install it
3. Use the so-called Visual Basic v3.0 Decompiler - from DoDi from http://www.woodmann.com/crackz/Tools.htm to decompile it, with no guarantee of success, with the result being code that would be very difficult to modify in any way
4. Find a copy of Visual Basic 4.0 (full or upgrade) (perhaps from http://www.emsps.com/oldtools/msvb.htm#vb4)
5. Upgrade the (mostly non-understandable) code
6. Compile it in 32-bit mode
7. Make an installer
8. Profit!! :)

I see this as a project with significant risk of failure, with step 3 being especially high risk. What do you think my chances of success? Should I turn it down or go for it? If it's a go, what precautions should I take?

EDIT: GrandmasterB (below) brings up a huge "monkey wrench". Indeed the app uses several .VBX's. Although this doesn't make the project impossible per se... perhaps I would be able to track down 32-bit upgraded versions of these extensions (.OCX's?)... but this issue, combined with the fact that I would have to get it working with decompiled source code just seems like too much of an uphill battle.

Answer 1

Wouldnt it make more sense to simply re-write the application? If this is a VB3 app who's developer 'lost the source code', I'm going to go out on a limb here and speculate that its probably not a groundbreaking piece of software that cant be re-developed by a programmer of reasonable skill simply by using the existing feature set as a guide.

The de-compiling thing is no guarantee. VB3 was 16bit... if this application is using third party 16bit .vbx's (the precursor to ActiveX's), source code or not, its not going to recompile.

Answer 2

I would only do it if the client is willing to task the risk. That is, I'd bill the client hourly for my attempts to get the app running while making it clear ahead of time that there is a high likelihood nothing will come of it. It is not your job to take on the risk of such a task.

Answer 3

I think your chances of success are minimal. If you were an experienced VB3/VB4 developer who really knew this stuff I'd say maybe 25%. If you're not, less than 10% and you could sink a lot of effort into failing. To put it in context I spent 10 years working with VBs 3 through 6 and I'm not sure I'd bother.

Given these chances I wouldn't agree to do it for the client on a payment on success basis (maybe unless you propose to charge him 10 times what your time would be worth to cover the probability you'll fail). If it were me it would be strictly time and materials.

If you agree to do it you need to explain this to the client (particularly that it's going to be unsupportable going forward). I'd agree a timebox (say 3 days) during which you'll try but at the end of which if you've not made good progress you'll give up - this limits his cost / risks.

Personally I'd look at running it on a Windows XP VM and set about rewriting it, I think it's a better use of the time and money.

Answer 4

Tell the client that additional research is needed, and you suggest that doing the "get VB and decompile" step will be necessary to even consider whether this is possible at all.

If you then find it to be feasible, then port it to VB.NET and incorporate all the changes that the client would have liked to happen if he had had the source code.

Answer 5

Sells a VB3 app? To whom ?

What about virtualization for running the application?

How did he manage to "lose" the source code? Can't he "find" it again?

I see this project as a chance of a lifetime if you can swindle it the right way. Imagine, as Winston said; you're porting an app, with no guarantee of results. An hourly pay.
If everything goes right, you'll rewrite the entire application, and get paid. If not, no sweat off your back.

Answer 6

Plenty of good stuff has already been said, but I would like to add that it really depends what kind of application it is. If it is GUI-heavy, then even if you had the source code, you'd probably have to rewrite a lot of it anyway to update it to Winforms or WPF. In this case, I wouldn't sweat much over the lost source code, but I would require very detailed specs (and a working version to play with).

On the other hand, if it had clever or complex algorithms that aren't documented anywhere else, you really do need to be able to decompile.

In any case, you won't lost much from trying the steps you lay out in your question.