Prev: Intel Fortran
Next: Fortran Compiler
From: rfengineer55 on 10 Jun 2010 10:53
> The program assumes that it is writing to an ANSI/VT-100 terminal.
> Specifically, BELL (ASCII 7) and escape sequences are output in WRITE
> statements. These will need to be fixed if you do not want to slow down
> the program considerably.


Bear in mind that ANSI.SYS support no longer exists on Windows. It did
work
on XP but only for 16 bit (DOS) programs under COMMAND.COM instead of
CMD.EXE and only if CONFIG.NT (not CONFIG.SYS) was modified. 64 bit
Vista
drops 16 bit support (DOS and Win16) entirely.



Bear in mind that we are getting way ahead of ourselves here. Once
these old Fortran programs are running, then these details are
addressed later. As far as slowing the program down considerably, I
could not care less. As long as it runs.

Once my ultimate research project is done, the exe files resulting
from the compilations will not see daily use, so top flight
performance is not important.

Jeff
RFENGINEER55
From: e p chandler on 10 Jun 2010 15:51
On Jun 10, 10:53 am, rfengineer55 <rfenginee...(a)aol.com> wrote:
> > The program assumes that it is writing to an ANSI/VT-100 terminal.
> > Specifically, BELL (ASCII 7) and escape sequences are output in WRITE
> > statements. These will need to be fixed if you do not want to slow down
> > the program considerably.
>
> Bear in mind that ANSI.SYS support no longer exists on Windows. It did
> work
> on XP but only for 16 bit (DOS) programs under COMMAND.COM instead of
> CMD.EXE and only if CONFIG.NT (not CONFIG.SYS) was modified. 64 bit
> Vista
> drops 16 bit support (DOS and Win16) entirely.
>
> Bear in mind that we are getting way ahead of ourselves here. Once
> these old Fortran programs are running, then these details are
> addressed later. As far as slowing the program down considerably, I
> could not care less. As long as it runs.
>
> Once my ultimate research project is done, the exe files resulting
> from the compilations will not see daily use, so top flight
> performance is not important.
>

OK. Thanks for your note in a different thread about your research
project and what your objectives are. I did not look at the screen I/O
sections of your programs in any depth except to recognize that they
used ANSI escape sequences for *something*.
Again, I now understand that getting the program to run is your main
objective.

I wager that you will have to fix some parts of the program to get
them to run. I do suggest that you use modern Fortran's tools for this
task. You can still used fixed source format, if you like.

I did notice a routine that seems to convert a string to an integer,
or is it the other way around?. Either way, it is definitely worth the
effort to replace this with either an internal read or an internal
write (as needed).

The same thing with command line arguments, date_and_time, etc.

I see no reason why you can't split your project up into a number of
different files. Then you can use free form source in some of them.

Finally you have a number of routines in which you set up constants,
etc. It would be a minimal amount of work to create a module with
those constants, and then USE that module in your routines. If it
ain't broke, don't fix it BUT if the code you have shown is only 20%
of the total project, good luck!

Seeing that the program needs static intialization and variables set
to zero via switch makes my head hurt. You may not have to worry about
it, but somewhere down the line there is going to be a mighty train
wreck!.

--- Elliot










-- Elliot


 | 
Pages: 1
Prev: Intel Fortran
Next: Fortran Compiler