Programs for Programmers

Fortran and Windows

Fortran and Windows



Each of the current generation of commercial Fortran compilers (Silverfrost, Intel, Lahey and Absoft) is supplied with tools for building simple Windows applications.

The Intel compiler comes with QuickWin. This allows you to route output to the screen, and to create simple menus and dialogs. Absoft's compiler includes an application framework called MRWE, which has a similar functionality; MRWE is also available in Absoft's Mac compilers. Lahey's LF90 is supplied with a cut-down version of Winteracter, the Windows toolkit described in more detail below. Salford's ClearWin+ is an ambitious attempt to make Windows programming easy for Fortran (as well as C and C++) programmers. Unusually, the interface is specified using something rather like a FORMAT statement and is very powerful, allowing the programmer to build fully-fledged Windows applications. However, many prefer a more visual approach to interface design.
In addition all these compilers allow you to call Windows API functions, and all now provide modules which specify Windows constants, structures and prototypes.

  • To go beyond the facilities offered by the compiler, you should look at one of the third party Windows development packages.

    Winteracter provides dialog and menu editors to help you define the user interface to your application. For each control, these utilities define identifiers, which are used in a message loop to attach responses to user actions. Winteracter also includes a comprehensive graphics library which includes graphical input, output and hardcopy primitives, presentation graphics routines and contour and surface plotting routines. Versions of Winteracter are available for all these compilers. It's worth noting that if you want cross-platform support, versions of Winteracter also exist for Linux - you'd have to buy a new Winteracter license to go with your Linux compiler, but that's got to be a whole lot cheaper than the time to rewrite the interface.

     View Winteracter screen shots

     GINOMENU is on the surface very similar to Winteracter, but its drag-and-drop designer (GINOMENU Studio) is more complete as it is used for not only defining the user interface but also lets you associate the event-handling code with each control.  Its code editor includes Fortran syntax highlighting and is code-aware of all the routines available in the GINO graphics libraries providing context-sensitive help and code-assist pop-ups for all the arguments. The whole application is wrapped up into a binary project file and  instead of creating a resource file that is linked into the application, like Winteracter, GINOMENU Studio creates one big Fortran source file that contains both the user-interface code and the user-code.  This can be quite cumbersome for large projects with the default code block containing one big message loop controlling the events, but user-code can be contained in smaller subroutines and these can contain individual message loops if desired.
    Unlike Winteracter, it is only available under Windows and if you require 2D or 3D graphics functions, the full version is quite a bit more expensive.

    DISLIN is another alternative which is available for a wide range of systems and compilers, and is free for non-commercial use. It's a more traditional graphics and GUI library - there's no way to define dialogs visually.

  • Another approach is to use VB.NET, C#.NET or Delphi to create a user interface, and move your Fortran code to a computational DLL (dynamic link library). This route gives you access to a superb user interface builder, and to ALL of the facilities of Windows, including for example, databases and third party ActiveX controls. However, the learning curve can be quite steep - obviously, you have to learn another language. Depending on how your program is organized, conversion to a DLL may involve a lot of restructuring. The main problems are:-
    • The computational and user interface sections must be rigorously separated. A new VB/Delphi backbone which contains almost all user interaction must be transplanted into your program. In many real world programs, you will require a second DLL (possibly written using Delphi) which provides some modal I/O functions for the Fortran (a modal function is one which must complete before any other action is started). In effect the Fortran DLL forms the filling of a Delphi sandwich.
    • All STOP statements must be eliminated. For example, a Fortran program may have an error reporting routine which prints a message and then halts execution. In a DLL, control must be passed all the way back up the call tree to the VB/Delphi backbone. If extensive use is made of the error reporting routine, this can be a daunting exercise.
    • Initialized data is not re-initialized at each entry to the DLL. For example, if you have a counter which is initialized, using a DATA statement, to zero, and then incremented within the program, you must bear in mind that the counter will not be re-initialized when the code is invoked a second or third time.

Despite the problems, there are situations when the DLL route is best, most notably where a specialised look-and-feel is all-important and you simply can't compromise on, for instance, having oval shaped buttons. However, in some cases, you can use VB or Delphi as a front end without converting your program to a DLL; instead, the program remains as a standard Win32 command mode executable which is invoked and run invisibly from the front end. This is most appropriate when there is just one entry to the program, typically via a "Start" button. This solution avoids the problems with STOPs and data initialization, though the separation of computational and user interface code remains. There are various mechanisms for passing data and messages between the front-end and the computational program.

So, money on the table time - which method should you choose? Well, it depends very much on what you want, but here are a few suggestions...

One thing I wouldn't recommend, ever, is writing an interface using nothing but the Windows API. I'm saying this as someone who has written a complete commercial program this way, in Fortran, back in the days before Winteracter and Clearwin+, and intends to never do so again. It's highly complicated, and non-portable, not just to other operating systems, but to other Windows compilers too, because every one has a different way to specify things which are not in the Fortran standard such as passing an argument by value. Don't do it. Just - don't. Your sanity is worth more than that. And there's always an easier way.

I'm a hobby programmer who fancies having a go at Windows versions of some of my Fortran programs without spending too much money:

Two possibilities here, Silverfrost's FTN95 Personal Edition (which is free for non-commercial use) and Clearwin+, or one of the free compilers and Dislin. You can't get cheaper than free.

I need a quick way to add a few input boxes to an existing program:

FTN95 and Clearwin+ may well be what you need - with no need to add a message loop, or for a 3rd party library, or to wrap calls in initialisation routines, this is certainly the quickest way to get started. But beware, if "a few" turns into a whole menu-driven user interface with tens of complex dialog boxes, the code can rapidly get extremely complex and hard to follow.

I need a Win32 version of a DOS program controlled by data files:

This is actually one of the very easiest scenarios, especially if you don't need to be able to interact with the computational bit of the program. You can use any tool to design an interface which allows the user to enter all the data they would have put in the file, and then just have your interface program save a data file and fire off the existing non-interface-driven program. Dead easy - and backward compatible with all your users' old data files, so they don't have to use the new system of entering their data if they don't want to. What would I use for the interface, if it was me doing it? Delphi.

I need a Win32 version of a DOS program which has an old-style interface:

This would depend on the style of the interface.
    If it's a lead-them-by-the-nose style interface which asks a question, then another one based on the answer to the first, then does a bit of computation, then asks a question based on the results, then I'd strongly advise against the GUI + DLL method - it's a complete nightmare trying to separate the old interface to be discarded from the computation which is to be kept. For a large, complex program for which the development will be ongoing, I'd use Winteracter or GINOMENU.
    If it already has a menu and a message loop type structure, it's probably a good candidate for GUI + DLL. I'd still take a good long look at Winteracter, though - there's a lot to be said for the simplicity of only having to work in one language and with one compiler.
    If it already uses an interface library, the obvious thing is to use the Windows version of it (and for those with old DOS INTERACTER programs, they are relatively simple to convert to Winteracter). Assuming one doesn't exist, I'd take a look at the routines available in Dislin and GINOMENU, and see whether one of them can be easily used with a layer of dummy routine calls to fix up the different routine names and arguments. The all-Fortran nature of these libraries is an advantage over Winteracter's resource files here, especially if it's a complex interface.

Help! My program doesn't fit into any of these categories and I still don't know what to do!

Well, we're only a phonecall or an email away - get in touch and we'll try to suggest something appropriate for your situation.