Converting F77 file from Unix to Windows

Hi Guys,

Since fixing my last problem (thanks for all the help on that one!) I have been given another legacy code. The code was written to be run on a unix system and is coded in f77.

I was wondering if someone would know the potential problems I may face converting the code so that it can run on windows xp? The code is quite large and I haven't yet managed to fully work out it's structure.

I have a list of the source files and as far as I'm aware the only changes required will be altering the make file and compiling the file using a windows friendly compiler such as g90.

If someone could offer some advice I'd be very grateful. Bren

This is a strang posting on this forum.

Why not use FTN95 which is also Windows friendly I hope.

Sorry Paul, looking through my last post I realise that I wasn't too clear as to what my intentions were. FTN95 is very windows friendly and my compiler of choice; my problem is that while I have FTN95 on my terminal my colleagues don't neccessarily have access to it. In this preliminary work I want to alter the existing code so that it runs on a windows system. When I've worked out how to do that the code will probably be changed or even re-written in f90.

I am not really sure how this legacy code works yet; it runs in Unix but not yet in Windows. I am interested what the general method would be for changing a code designed to run in unix to one that will work in windows.

I suspect that the main changes will be to any file locations mentioned in the code, the makefile will need to be changed (although I don't yet know how) and it will need to be compiled with a windows compiler, I will be using FTN95 but I'm not sure what the guy next to me will use.

Hope this clarifies things, Bren

Assuming you have the appropriate license, your compiled code can run on anybody's PC. Quite possibly, all you have to give them is salflibc.dll, and your EXE.

If there are more files to transfer, then you (may) need an installer. You can find at least one for free on the web - Jordan Russell's InnoSetup.

Since fortran 95 (and hence FTN95) contains fortran 77 (and thus also FTN77) in its entirety, there ought to be few problems. If the legacy code is a straightforward 'console application', i.e. it is pure fortran 77 with no extensions, it might even convert unaltered.

Eddie

Thanks Litus,

I don't have a problem with the f77 side of things. It's more the migration from Unix to Windows I am concerned about. I don't actually know what this code is supposed to do so it's not even a matter of tinkering with it and checking the output - I wouldn't understand the output whether it was working or not. This is just a raw programming exercise - switch off brain and press buttons type of thing 😃

At the moment I am searching through the source code for OPEN, UNIT, and SYSTEM statements. I figure that the primary changes in migrating it will be altering filenames and system commands to something windows friendly - and compiling it of course.

If anyone could offer some advice on any pitfalls I may encounter I would be very grateful. Bren

I would suggest that you open a dos box go to the directory where all the source code is and ( assuming the suffix is .for, type

ftn95 *.for /unlimited_errors >compile.tce slink *.obj /map >>compile.tce

and see what happens

You may want to consider the use of the following compiler options /debug /do1 /error_numbers /fixed_format /implicit_none /persist /unlimited_errors

All of these are relevent to what you are doing.

'dir /l/b *.for >make.bat' will get you started in generating a list of files. this list has a lot of uses, as a list of files to compile and a list of .obj files to load into slink. I always put the program as the first file name. In slink, generate a .map and import all the routine names into excel and review what is available. The map gives routine names and the .for file that defines them. You could also turn the file list into a single .for source file, using include statements, to improve the ftn95 diagnostics.

Being a unix source, the integer4 and real4 defaults should be the same. Any record length file commands and probably all binary file formats need review, as this changed for the better from f77 to f90+. To locate all open, read, write, close, rewind and backspace file commands, use the command find /n/i 'open' *.for

Otherwise compile, link and see what happens. You do need some data input files and hopefully a past output file to see if it works.

good luck.

I would add /checkmate to the list of compiler options in John's excellent advice. Or rather, replace /debug by /checkmate.