Fastest way to change a DOS "C" program to a Windows program? 2

[BOBR]

Hi-<br>
<br>
I have a fairly large (800k) DOS program written in MS C v8.0 and I need to convert this program to a 32 bit Windows program. I really don't care to learn or use C++, but since I have MS Visual Studio 6.0, could I use the Visual C++ IDE and plug into it much of my C code without changing it into object oriented code? Or is there a better way to get this job done?<br>
<br>
tia - bobr<br>
<br>

 

[MikeLacey]

I think the answers to both your questions has to be Yes.<br>
<br>
Any real Windows C++ and C programmers -- look away now.<br>
<br>
"Could I plug C code into the C++ IDE?"<br>
Yes, pretty much. C code will run ok in a C++ environment, you're going to have to fiddle with .h file definitions.<br>
<br>
"Is there a better way..?"<br>
Yes... But you will probably be able to get your program running ok in a fairly reasonable time (not accounting for any 16-&gt;32 bit conversion issues you have).<br>
<br>
Assuming your C program is basically a batch program - which is quite an assumption. The easy - and very dirty way to do this would be:<br>
<br>
1) Create a form with a List Box and two Command Buttons, Ok and Cancel.<br>
<br>
2) Paste your code behind the Ok button changing all of the printf statements to List1.AddItem calls to display your output in the List Box.<br>
<br>
If it's not a batch program - but needs to interact with the user - all may not be lost; it would depend on the amount and type of input the user has to do.<br>
<br>
Let us know how you get on.<br>
<br>
Regards<br>
<br>
Mike<br>
---<br>
Mike_Lacey@Cargill.Com<br>

 

[BOBR]

Hi Mike,<br>
<br>
Thanks for the reply. Actually, the program is not<br>
a batch type program, but rather a fairly sophisticated<br>
genetics database program, that has a ton of user<br>
input screens & windows. Forutnately (I think, all<br>
of my C code calls basic library routines that I<br>
wrote for all of the IO (including printing).<br>
<br>
So I would think that my primary task is going to <br>
be to convert my library code into windows function<br>
calls. However, I am not sure of the easiest way to<br>
do this. Should I try top use the MS MFC library, or<br>
use real basic Windows SDK code. I do want the new program to be 32 bit (BTW). <br>
<br>
I'm a very experienced C programmer, but as you can<br>
probably tell, I have not done any programming in<br>
Windows.<br>
<br>
regards... bobr

 

[MikeLacey]

Hi Bob.<br>
<br>
I think that I would be inclined to do this bit by bit. My (rather vague) plan of attack would go something like this.<br>
<br>
1) Use the nicest and most visual development I can.<br>
<br>
1a) Change as little as possible.<br>
<br>
2) Create the screens and then paste code behind buttons and events fixing things up as I go.<br>
<br>
2a) Change as little as possible.<br>
<br>
3) Make as much use as possible of the highest level objects you can. One exception - MFC (IMVHO) should be avoided unless your application closely fits the document model it uses.<br>
<br>
3a) Don't change very much.<br>
<br>
There's a common theme in there somewhere but I can't quite spot it...<br>
<br>
My basic plan would be to change only the user-interface. That's not achievable as soon as you get into the realm of printing but, hopefully, you'll be pleasantly surprised at how high level that can be.<br>
<br>
The other area that might be interesting (difficult) is the database. What are you using?<br>
<br>
When you're porting this kind of thing the game is (I think) to come up with the smallest list of changes that have to be applied that will make the thing work in its new environment. The user-interface is going to be your big area of change but, as I'm sure you know, it's the easiest thing to learn in the visual environments.<br>
<br>
Regards<br>
<br>
Mike<br>
---<br>
Mike_Lacey@Cargill.Com<br>

 

[hrothgar]

I commonly write C programs in Windows, accessing custom-built database, then port them to UNIX servers or IBM Mainframes, or vice versa. <br>
<br>
I think the easiest way to start is to use Borland's (Inprise's) Easywin program, or something similar, that creates the 16 bit Windows headers for you transparently (Standard version &lt;$100). I don't us MS C, but I think an old 16 bit version might do something similar. <br>
<br>
One rule I follow is: change any printf to sprintf(str_var,...) The str_var, a string buffer, can be used in a graphical environment (msgbox), whereas printf is incompatible with windows. A simple header flag (#DEFINE RUNWIN 1) might allow you to change much I/O for Windows environment. You probably don't want to fool with processing key strokes in windows environment. In an event-driven programming model, using the MS classes, or whatever, to change most of the inputs to buttons, checkboxes, etc, then process a bunch of stuff at once. Use the graphical interface builders (C++Builder, or the Visual C equivalent.), if at all possible. <br>
<br>
That is, you need to separate the interface code from the data processing end. Since it is genetics stuff, and you say you're "real experienced", I presume you manipulate your own database. You can run a commandline program (even a DLL if you want better response & control), to handle data base manipulation; just don't ask for anything from the user is the data processing programs, and don't display anything. Make the command line program disk intensive and separate from the interface. It is possible to use return values from DLL's to process data, but I've found it is better just dump output into a status file, and let the interface process it. (You can run a program using the system function, or one of the spawn functions, if you want feedback or control.) Just return something simple to indicate the program is finished, or check the contents of a status file. This is the standard client/server model, applied to a single PC. <br>
<br>
If you want, you can spool output to a file, including printer control commands, then run it as a DOS program or call windows APIs to print a file. Using windows printer controls later on may give you more control.<br>
<br>
In general, you need to use the large memory model, for compatability. If you do lots of address manipulation and/or bit manipulation, you need to make sure that you integers & pointers are correctly sized (DOS has 16 bit integers, Win95/NT 32 bit, some UNIX 64 bit). Be explicit with declaration (short, long, etc.) You can always use sizeof(int) to test for the operating integer size. Try not to fool with memory segments if possible; code in a way that is supportable in a changing environment.<br>
<br>
If you're doing lots of graphical output, you'll have a lot of reworking to do, but you can probably save lots of stuff if you isolate specific parts of your programs (Java compilers run from the command-line, and most Java applications are graphical.)<br>
<br>
Be warned, however, if you want to run DLLs, make sure you understand memory allocation, how DLL's run, calling conventions, etc. There's a reason most software installation programs in windows require you to shut down and restart. Don't create a DLL until all the code is fully debugged.<br>
<br>
If you have any specific questions, feel free to ask.<br>
<br>
I seldom code in C++ except in working with interfaces. While some initializtion features are handy in C++, any long-time C programmer already does most of that stuff automatically. (Polymorphic functions are a real nice feature, but there is overhead involved.) The loss of transportability in using C++ instead of C is too great for my uses, where I'm constantly using compilers on different operating systems. <br>
<br>
Roger<br>
<br>
Roger_Pomeroy@ita.doc.gov

 

[BOBR]

Mike - Thanks for your feedback.<br>
<br>
Roger - <br>
<br>
&lt;&lt; I think the easiest way to start is to use Borland's (Inprise's) Easywin program, or something similar, that creates the 16 bit Windows headers for you transparently (Standard version &lt;$100). I don't us MS C, but I think an old 16 bit version might do something similar.&gt;&gt;<br>
<br>
Perhaps you missed an earlier statement of mine when I said that I wanted the Windows program to be 32 bit. This is not an absolute necessity, however, one of my reasons for this is that the program performs a _lot_ of memory management (running completely in the 1st 640K of mem). It allocates and frees large chunks of memory very often. (I even have my own routines for defragging memory every so often). I had to write the program this way to get it to work in just the lower 640k of memory (actually the MS overlay manager does use extended memory to store overlays read from disk). <br>
<br>
The program also does a fair amount of 32 bit number crunching on large arrays of numbers when it computes coefficients of inbreeding, relationship coefficients, and genetic inheritance probabilities. So it seems to me that in the long run memory management would be less trouble and caculations would be faster in a 32 bit environment (I would guess that 25% of my time programming this application has been spent working on and around memory management problems...{there are a huge number of animals in a 30 generation pedigree} for a variety of reasons I decided to stay away from DOS extenders and from using extended/expanded memory).<br>
<br>
&lt;&lt; One rule I follow is: change any printf to sprintf (str_var,...) The str_var, a string buffer, can be used in a graphical environment (msgbox), whereas printf is incompatible with windows. &gt;&gt; <br>
<br>
I wrote all of my own file and print library functions and none of them use "printf" (I do use "sprintf" quite often though). The program does allow printing to a file, the screen, or an actuall printer. It has its own printer install function that sets up some basic printer control codes that are used when output is sent to the printer and which get translated into color attributes when output is sent to the screen.<br>
<br>
&lt;&lt; A simple header flag (#DEFINE RUNWIN 1) might allow you to change much I/O for Windows environment.&gt;&gt;<br>
<br>
I'm not sure I understand what you mean here. Are you perhaps thinking in terms of a compiler directive that would allow me to compile the program for either DOS or Windows?<br>
<br>
&lt;&lt; You probably don't want to fool with processing key strokes in windows environment. In an event-driven programming model, using the MS classes, or whatever, to change most of the inputs to buttons, checkboxes, etc, then process a bunch of stuff at once. &gt;&gt;<br>
<br>
Not an option. I _must_ be able to process key strokes. The program has a lot of shortcut keys and its own keyboard macro recorder/playback functionality. I have about 6,000 customers using this software and a fair percentage of them (mostly touch typists) really appreciate the fact that they can operate the program (much faster) entirely from the keyboard. BTW, I wrote the program in a very event-driven manner. So for example, when a user is inputting or editing a string or a number and they press a certain function key or key combo, the Edit_Str function is exited and a menu may drop down or some other desired event will happen (after they are asked if they want to save changes to the current record). Almost every one of my libray IO functions return either a status value and/or what I call an "exit" key. <br>
<br>
Speaking of my library functions, I use them almost exclusively for all IO, including writing directly to the screen refresh buffer. The relational database is of my own design and it can maintain multiple multi-field indexes that can be added/changed on the fly by the end user. I do use the stream FILE IO functions in the MS C libray but even those are called via one of my own library functions. I tried to limit my use of MS C libray functions in my main code modules to those that I figured would work with little modification in a windows environment... such as string functions and disk/file IO functions. <br>
<br>
I knew that I would eventually want to be able to compile the program for the windows environment. So the most work, I think, will be to write analogous windows functions for those that I wrote for DOS, and then possibly put those functions into a .dll file, or just link them directly with the windows .exe that I create with the rest of the code. The program is _very_ quick and compact, considering everything that is does, and I would very much like to keep it that way. BTW, you can download a near full working demo copy of it at &lt;

http://www.CompuPed.com&gt;.<br>

<br>
&lt;&lt; Use the graphical interface builders (C++Builder, or the Visual C equivalent.), if at all possible. &gt;&gt;<br>
<br>
I don't have "C++Builder" or "EasyWin", but I do have Visual C++ v5.0 and Visual Studio v6.0 (PRO version). Do you haver an opinion on which of these 2 versions of C++ would be better for me to use. I haven't yet learned how to use the Visual IDE of either of the C++ versions I have from MS since I have been compiling everything from the command line with make files. I suppose if you really think that C++Builder or EasyWin is much easier to use or more powerful, I could purchase and use it instead of the MS products.<br>
<br>
I have to tell you that I have even considered using Visual Basic for the user interface while putting all of my genetics calculations into .dll files. However, since I have been playing with VB a little, it sure seems to me like it produces fat & slow executables ("hello world" is a 65K program &lt;sheesh&gt which is a real turn-off to me. <br>
<br>
Getting the DOS program converted to a Windows interface as quickly as possible (even if only as a 16 bit exe) is my main concern. While I'm sure that the MS Visual C products can produce what I need, at the same time it seems like they are somewhat overkill for what I need (I could easily be wrong about this). I don't really have the time right now to learn a whole lot of stuff that I may never use.<br>
<br>
regards... Bob

 

[ssingh]

No problem at all Dear Friend. Visual C++ is just an IDE to program. You can run your C program. Start VC++ , File-&gt;Open , Then open the C file . It will ask for creating a Project. Let it create. Then just compile and run.<br>
Does it answer your question ?<br>
Thanx<br>
Siddhartha Singh<br>
<A HREF="mailto:ssingh@aztecsoft.com">ssingh@aztecsoft.com</A><br>
<br>

 

[zBuilder]

&lt;&lt; You probably don't want to fool with processing key strokes in windows environment. In an event-driven &gt;&gt;<br>
&lt;&lt;Not an option. I _must_ be able to process key strokes. The program has a lot of shortcut keys and its own keyboard macro recorder/playback<br>
<br>
Yes, you can process keystrokes in Windows. Either use an accelerator function (Gives a Key equiv for menu items) or respond directly to WM_KEYDOWN / WM_KEYUP messages. The important thing to remember is that in windows the keyboard talks to your program without being asked. As opposed to your program polling the keyboard in DOS.<br>
Also, you cannot write directly to the video buffer like you do in DOS. You must use the functions provided by windows. Directx gives you a little more control, but nothing like pure DOS. <br>
<br>
&gt;&gt;since I have been playing with VB a little, it sure seems to me like it produces fat & slow executables (&quot;hello world&quot; is a 65K program &lt;sheesh&gt which is a real turn-off to me.<br>
<br>
If you hate that, then stay away from MFC / OWL or anything that uses an OO interface to the Windows API. <br>
<br>
&gt;&gt;&gt;memory management (running completely in the 1st 640K of mem). It allocates and frees large chunks of memory very often.<br>
<br>
This is fairly easy to do in Windows. You will have a LOT more room to move around than you did in DOS.<br>
<br>
&gt;&gt;I don't have &quot;C++Builder&quot; or &quot;EasyWin&quot;, but I do have Visual C++ v5.0 and<br>
<br>
EasyWin won't do what you want. It's a fairly limited function. If you want multiple windows, scroll bars, drop down lists, menus, along with a small and efficient executable, then you are going to have to get into the guts of windows programming. There really is no easy way around this.<br>
<p> <br><a href=mailto:Kim_Christensen@telus.net>Kim_Christensen@telus.net</a><br><a href=

http://www3.bc.sympatico.ca/Kim_Christensen/index.html>Home

Page</a><br>