There is no magical way to migrate your programs from DOS to Windows.

The environments are just too different for a simple and automatic solution. Although there are some products that help, your apps will continue to look like DOS apps until you go to the trouble of adding Windows-specific functionality.

After that fairly negative opening, don't despair! There are several possibilities.

Do Nothing

You could leave your programs as they are now, written for DOS. For many clients I continue to use CA-Clipper 5.2e and Blinker along with other libraries, and the programs work very well under Win9x and WinNT. Of course, the problem with this is they are still ugly DOS programs to many of the users, who are jaded after using Windows for a while.

Of course, DOS programs don't have to be ugly, and I have yet to see a Windows program with an interface as fast and efficient as a DOS program. Developers and users too quickly forget about the keyboard and rely only on the mouse!

Use a Windows Library - Clip4Win or FiveWin

You could use a Windows library for CA-Clipper, such as Clip4Win or FiveWin. These two products are add-on libraries for CA-Clipper that allow you to create Windows programs with CA-Clipper source code. You will require a Windows linker like Blinker version 3.1 or above, which you should be using anyway!.

Clip4Win is created in the U.K., while FiveWin is written by a Spanish company. FiveWin seems to be more actively updated, and supports Win9x technology.

You can get evaluation versions of both of these products. The Clip-4-Win web site is at http://www.clip-4-win.com/, and an evaluation version (v3.01) is available. You can find FiveWin at http://www.fivetech.com/, where they have a demo (v1.92). You should browse around the sites for more recent releases and try them out.

Use Xbase++

An interesting and popular option is to use Xbase++, which is a real compiler that creates 32-bit native code for the Windows environment. It is 100% Clipper language compatible, yet blows away some of the limitations, such as array size (unlimited) and string length (512MB). The object-oriented programming model has multiple inheritance and all data types are persistent - even objects - and can be stored externally.

You can find out more about Xbase++ at Alaska Software, and also at www.grafxsoft.com and www.zaccatalog.com where you can buy it.

Try CA-Visual Objects

CA-Visual Objects (from Computer Associates) uses basically the same language as CA-Clipper. However it is considerably enhanced, since it is a native Windows product and very object-oriented. Once your existing apps are imported, you can add features or rewrite modules. Version 2.0 of CA-VO strangely discontinued support for "character mode" (@ SAY) applications, while Xbase++ continues to allow those legacy statements. The rumour is that CA-VO 2.5 reinstates some of the character mode support.

For me, CA-VO is the most comfortable way to program for Windows in the "CA-Clipper style", because I've been a Windows programmer since around 1985. Nevertheless, the CA-VO environment is definitely the reason that 400MHz Pentium IIs were invented! Luckily, executable programs run as fast as C programs.

CA has a page at www.cai.com/products/visual_objects.htm and you might want to check out my pages. You can buy CA-VO at www.grafxsoft.com and www.zaccatalog.com.

Another Language Entirely

You could use something like Borland Delphi or Microsoft Access to create Windows programs. Clearly, you will not be able to keep any of your existing source code with this approach, but you will be able to use or import the data.

Delphi is based on the Pascal language, so that might be a problem for you. MS Access uses a version of BASIC, and doesn't have a "real" compiler. Nevertheless, these tools (or ones like them) might be an option for you.

Which One?

The best approach with any of these is to decide what is important to you: the code, the data, or both. Then create a migration strategy. You may find that you can move to the new environment in an incremental manner. For example, you might create reporting tools in Windows, while the data entry is still done with a streamlined DOS app (perhaps running in a Windows DOS box).

It is safe to say that you will have to rewrite most of your user-interface code, as is the case with any DOS-to-Windows conversion. You won't get the look and feel without work!