Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Compiling Old DOS Program written in C into VB6

Status
Not open for further replies.

Toga

Technical User
Jul 21, 2000
234
0
0
US
We have a software program (Custom) at work that was written in C and runs in a DOS environment. We had purchased the source code from the manufacturer as part of our deal several years ago but is obviously very outdated wrt the OS it runs on.

The program configures the operation of and collects results from a piece of online inspection equipment.

Bottom line is that we would like to have this upgraded to the windows environment and prefer VB6. Can anyone tell me the steps that would be required??? The manufacturer of the inspection equipment could & would do it...but at an enormous price making it very difficult to justify.

Once we get it there, we then can start adding our own options and integrate it with the databases we have.

We don't mind paying to have this done.....we just do not want to be raped as would be the present situation....

 
To convert a DOS based C program into a Windows based VB6 program will essentially require a rewrite of the application. As far as I know, there is no utility that automatically converts Dos based C programs into Windows based VB6 programs. So you will probably have to pay the manufacturer or hire a developer to have the app redone the way you want it.
 
If you had someone that knew C and Visual BASIC, then the program could be translated. Most likely if it's a collection based system, most of the heart of the program in the algorithms. You can change the UI (User Interface) to whatever you want it to look like. If it were Me doing it, I would most likely take a look at the functionality in the C program and put as much of the business rules into a DLL for reusability and ease of implementation. Then I'd build the UI on top of that.

If there's a need for other businesses to have the functionality you could sell the DLL to other manufactures so they could develop their own interfaces with the collection equipment. This might help you offset some of the costs of the conversion. But it would really depend on how marketable the functionality would be to other manufacturers.

If you would like more information, my e-mail address is below. Snaggs
tribesaddict@swbell.net
2 wire mesh butchering gloves:
1 5-finger, 1 3-finger, pair: $15
 
NOt EXACTLY on target, but I have done a lot of conversion to VB - mostly from FORTRAN and older versions of BASIC. My approach for large programs is to write conversion routines. These are generally of the form of reading some portion (snippet) of the source program and writting the equivalent snippet in the target program.

One example which I recently did required about four months to write, and converted a VB 1.0 (DOS) program using a flat file data base to VB6 (Win) using Class modules for the data handling. The "original" program ource code was just over 1 Meg. While not perfect, the target program was up to an 'alpha' level release within about two weeks after the conversion of the source code.

This process can be viewed as a GIANT search and replace exercise. The largest difficulty in this approach is convincing 'management' that anything is being accomplished during the generation of the conversion code.

Translation from C to VB would include a few additional issues, however I do not feel the additional issues would be more than 15 to 20% additional time/effort. The major NEW issue in converting a 'C' program would be the overall program structure, not the conversion of individual procedures or lines of code.

If you are interested in further dialog regarding my approach, please feel free to contact me directly.



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
You could just shell out to it, couldn't you?
 
I have had the same problem, and it worked as the above sayed (mrjts). I compiled on my win95 PC with an old version of C Compiler, making the exe file from C, and then I call it via shell() on my VB application. It works OK.

If you need to know when the execution is over (as far as I know shell() continues execution in VB), you can add at the end of the C program a sentence that writes a token file, and in your VB after calling the exe file, put a loop reading the file until the file exists (however, don't try to delete it until next execution for you can have access problems, matter of miliseconds, when VB sees that the file exists its possible that exe file didn't close the file yet)
 
Thank You everyone for your comments.... I'm thinking that shelling out to it might be my best and most economic option if I can get it to work.

The software is pretty specific to customized inspection equipment so I don't think I'd end up with anything wrt DLL's that would be of any value to anyone else...but I appreciate the idea.

I certainly know I can't justify spending alot of time or money on getting it converted but was hoping (Wishful Thinking if you will) that there might have been be an easy way. Hey....Ya never know if ya never ask!

Thanks Again....Toga

 
NNZZ was correct in saying that the VB code contines to execute. Shelling out another application is asynchronous and the VB code will not wait for the other process to continue. With that in mind, shelling out the C code EXE from VB will work fine (unless you want some sort of interaction with the GUI), but be careful with the looping and checking for a text file since a continuous loop will take up CPU time. At the very least, put a call to the sleep API within the loop and then call a DoEvents to allow the application to process any pending messages. Another option would be to get the Process ID that is generated when you shell out the C code EXE and then monitor the process list. You will know when then C code exe is finished when the Process that was created by the shell command is terminated.
 
Just a quick question here... How would shelling out to it from VB or any other program be any different than just creating a shortcut on the desktop and running it from there? It's still running in a DOS mode and it's still collecting data the way that it always has.

So my question is. Do you really need to convert the program or can you just run it in a DOS shell from Windows? Snaggs
tribesaddict@swbell.net
To define recursion, we must first define recursion.
 
Also, 'shelling out' does not provide the capability of adding 'enhancements' as mentioned in your original post.

[blue]"Once we get it there, we then can start adding our own options and integrate it with the databases we have."[/blue]



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
One more thought on this matter with regards to the DLL idea. If you were to move most of the C code application/business logic into a DLL, then a simple VB GUI could access the current functionality that you already have through export APIs or you could even go as far as to make the DLL a COM DLL and then the old functionality could be access through a COM interface. I know that is was mentioned earlier that a DLL would be good as it would allow for code reuse (which is very true) and you had mentioned that this was a unique application that probably would not be reused, but the DLL idea still might be an easy way reuse your existing application in a VB6 windows app.
Also, Snaggs is correct when he points out that simply shelling out the C code EXE would be no different than simply running the old EXE from a shortcut. You will still be running a DOS program. If that is fine (and you don't need to make your enhancements), then is there really a need to change the program?
 
jmarler,

That's exactly what I was thinking, it just didn't come out that way. The COM DLL is what what I was thinking, I just didn't state it. Thanks.

MicahelRed makes a good point too about integrating it to a database.

If the program writes a binary or text file currently, running it in Windows is going to produce the same results. I also got the feeling that you were wanting to do more with it than what it already does. Such as custom reporting or collect the data in a database.

If you'd like someone to take a look at it, my email address is at the bottom of this post. Snaggs
tribesaddict@swbell.net
To define recursion, we must first define recursion.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top