Dual Interface, Dual Code

This approach is in many ways the most obvious and straightforward. It is also the approach used most often by other programming systems: simply write different programs for the graphical and character systems. The big advantage of this approach is that you can customize the code for the characteristics of the host system as much as you want. Additionally, you incur no overhead for having to include code that is not used for a particular system. Finally, when you are programming you don't have to think about two systems at the same time. Development time for any one system is shortened and testing is easier. These are all significant advantages.

Unfortunately, there are also many significant disadvantages. You have to write two programs instead of one. And, you must maintain two programs. Because there are two programs, you are likely to encounter twice as many bugs. Also, the time required to develop the set of programs is most likely greater than required by the other approaches.

Here are some cases where this approach offers significant advantages:

1. If you are in the process of retiring or freezing a character-based application, then you can simply use that application as the starting point for its graphical incarnation and leave the character version in its original form in an archive for future maintenance. In this scenario, you do not expect to do much more work on the character version, so spending a lot of effort in maintaining a single piece of source code is probably not worth what you gain.
2. If you intend to have sizable functional differences between a character-based application and its graphical sibling, then it might not make sense to try to have a single program cover both cases. In this case, you really do have two different programs, with some overlap in their functionality. The overlapping portions could be maintained as a separate library of source that is shared by both systems.

In general, if you view the character-based application as having a limited future, then this approach generally makes the most sense. The other two approaches are more attractive if you plan on maintaining and enhancing the character-based application in the future.