tags:

views:

74

answers:

2

We have a client who wants to convert a bunch of VB6 projects in to VC++ native code. I would like to know if there are any tools available for such conversion.

We tried http://vbto.net/, which converts, but generates tons of compile errors. The tool creates all cpp projects as "exe", while many of the source VB6 projects are "activex dll".

How does a VB6 project map to a VC++ project? For e.g., does a "activex dll" map to vc++ ATL project? What are the things we should look out for? If you can share your experience, we will greatly appreciate it.

(yes, our first response was to suggest conversion to VB.NET/C#, but the program needs to run on machines that won't have .NET framework installed, and also invokes methods in kernel32.dll)

A: 

you can't. maybe you can convert vb6 code to vb.net. then you can easyly convert it to c# or managed c++ (all .net langs compiles to msil so can be tranformed to another .net lang easyly with reflector, etc..)

sirmak
converting to managed code (vb.net, c# or managed c++ or any other) is not an option, .net framework is not available on the target machines.
Shankar
try http://www.tangiblesoftwaresolutions.com/Product_Details/VB_to_CPlusPlus_Converter_Details.html
sirmak
@sirmak: your link takes me to a VB.NET to C++ converter. I'm looking for VB6 to VC++ converter.
Shankar
you're right. they say upgrade vb6 to vb.net with their migration tool and then use vb.net to c++ tool. I think the only possibilty left is full rewrite.
sirmak
A: 

You might consider using a migration tool that is capable of handling the complete conversion. See http://stackoverflow.com/questions/3455456/how-to-translate-between-programming-languages/3460977#3460977.

The DMS engine involved has full parsers for VB6 and Visual C++, and can apply transformation rules that map VB6 surface syntax to Visual C++ surface syntax.

Somebody has to write the translation rules, and there's a lot of them to write; you need one for each langauge construct and context in which it can occur. This means in your case that you'd need special rules to produce a translation as a DLL rather than .exe, if that's a real requirement. Writing such rules is harder than it it looks mostly becuase of the number you need to write, usually on the order a 1000-2000; this isn't for the faint of heart. But it can produce very reliable translators (read the answer at the link for more details).

You didn't say what "a bunch of code" was. At smaller scales, you can use more ad hoc approaches (hand translation, patching the output of a bad translator [e.g., the one you discussed], etc). At sufficient scale the automated conversion is an effective approach.

Ira Baxter