The good news and the bad in your code:
The good
--Although the program is based on the OWL framework and is structured in C++ style, there are many calls to C functions like strcpy() that should mostly not require conversion. If it had used the Borland C++ string class, the newer standard equivalent is basic_string, which is sufficiently different (and lacks equivalents for some of the old Borland string:: member functions) that a conversion could involve quite a bit of code-tweaking.
--Although the program is based on OWL, there are places where Windows API functions are used instead of OWL methods. Examples include ::MessageBox, ::ShowWindow, ::RedrawWindow. This, too, should avoid the need for some conversion work.
--The code does not appear to use Borland's BIDS container classes for arrays/vectors.
That mostly summarizes the good news.
The bad
--A "conversion" from OWL to .NET is really a rewrite rather than a conversion.
This quote from one of my web pages was targeted mainly at hobbyists converting relatively small programs:
It's surprising how easy it is to convert old Borland code to Microsoft Visual C++. Text substitutions in the code are often all that's required to convert Borland's BIDS TArray classes to STL. Screen elements like menus must be built from scratch in the VCPP design interface, but it's easy. The hard part was designing the menus in the first place, and that's already done. Learning the new .NET Framework equivalents of the OWL methods can be difficult and time-consuming, but the .NET methods are incredibly powerful and the results are very good.
When scaled up beyond the hobbyist level, it can get more complicated. What is easy to do once or twice becomes a large task if you must do it dozens or hundreds of times. Easy chores in a simple program can be more complicated in a larger and more complex one. Recreating one menu in a small program is indeed easy. Recreating a menu system in which items or submenus are merged, updated, or replaced depending on which "mode" a program is in gets a lot more complicated.
Some of the basic steps of an OWL to .NET conversion are:1. Every GUI must be built completely from scratch. The entire screen interface has to be replicated using Windows Forms rather than the OWL TFrameWindow/TWindow hierarchy. Each dialog box becomes a new Windows Form rather than a TDialog, and must be designed graphically. Visual Studio does make the graphic design much easier than it was in the old IDE, so the process really is replication of the old design into a new framework, not a completely new design, but that is less comforting if there are 100 different dialog boxes that need replication.
2. Properties, such as of windows, dialogs, and other objects, are assigned within the IDE. This is usually done by examining the properties in the old OWL version, and entering the comparable values in the new IDE design interface. If you start with a copy of the code base, and delete code as you create its equivalent in the new IDE, you know that you're done when you run out of old code.
3. Event handlers are easier to assign than they were in OWL, but the methods of creating them are different. The procedure is to create the object in the IDE, click the event for which you want to create a handler. The function is created for you. Then you copy and paste the old OWL code into the new function and revise any other aspects of it that require conversion to .NET. The fact that you can copy and paste old code saves a lot of time. The fact that you must examine the code after pasting and resolve what might be significant incompatibilities makes the time savings less substantial.
Basically, the process involves creating an entirely new program framework based on Windows Forms and its Properties/Methods/Events structure, and then copying and pasting blocks of old code in the places where they belong in the new program.
What can't be avoided is that all of the lines of code have to be copied and pasted into new locations by a person. After that is done, the compiler can help find old methods that require additional conversion, but the incompatibilities found have to be resolved by a person.
In essence, the conversion to .NET is a large undertaking, even if it's a lesser magnitude problem than writing the program in the first place. The project could be compared to translating the complete works of Shakespeare into French. It's not as difficult as creating the works in the first place, but it's still a big task. Some parts of it can possibly be automated, but every bit of the translation must then be examined for idiomatic expressions that translated poorly, and corrected by someone very familiar with both languages.
-----
You didn't mention what prompted the desire to do a conversion or what other options you might have considered. Here are the possibilities:
1. No conversion, no change. This runs the risk of your current development environment (which might consist of an old computer and the Borland 4.5 IDE running on an old Windows version) becoming increasingly obsolete and dependent on the continued functioning of that one computer, which could fail.
2. Convert the project to Microsoft's Foundation Class Library. This was the competitor to OWL in the 1990's. Microsoft still supports it in Visual Studio. The reason I wouldn't take this route is that a) although there appear to be many similarities between OWL and MFC, I have seen it said that there is no direct mapping from objects in one library to similar objects in the other; thus, the conversion could be as difficult as the one to .NET, but with less of a "forward-looking" result, b) it is C++ only, not language-neutral like .NET, and c) if a conversion is to be done, .NET is more of a "library of the future" than MFC is.
3. Convert your development environment, and the project, to OWLNext (
http://owlnext.sourceforge.net/index.html). OWLNext projects can be built and worked with in Visual Studio. This might be a viable conversion option, much lower in cost than a .NET conversion while extending the lifespan of your existing code into the future.
4. .NET conversion. Very expensive, but it upgrades the codebase to a form that should be completely modern and upgradeable for many more years. The type of conversion that makes sense is "mixed mode", containing a mix of .NET managed and (non-.NET) unmanaged code. I believe the cost of converting your program to 100% .NET managed code would be astronomical. For example, it would involve converting ALL the C-style strings (char arrays using functions like strcpy()) to the managed .NET String class, and all C functions such as strcpy() and fread() to the methods of .NET classes.
-----
When I discovered that my OWL code was obsolete, I looked into OWLNext but decided that it was a poor option
for me because my primary goal was to learn newer technology than what I was already familiar with. Preserving the functionality of my old code was secondary. I tried a Java conversion but was dissatisfied with Java. I bought and tried Borland C++ Builder 6, but disliked their VCL and its roots in PASCAL, and disliked Borland for having abandoned OWL. It took more than 3 years to decide that my best path was to stick with C++, switch to Microsoft, and use .NET as the best avenue "to the future".
