A cautionary tale.

I have a bit of software that I used to use a lot but now use more rarely. From the change log in appears I got it working in November 1974. It survived the transition from cards to paper tape back again, it’s been on dozens of systems, and because it is graphics based it has driven all manner of plotters via all manner of graphics systems. I needed it last week, and dug it out. The last time I compiled it was in 1999, then with FTN77.

Its on-screen graphics appear in a %dw box, and back then it was safe to assume that the monitor aspect ratio was 4:3. That is no longer a sensible assumption, and the graphics were coming out distorted. So I recompiled it all with FTN95, and that was enough to stop it working. The error message related to ‘loss of precision’. I tried all manner of things including compiling with -intl and -dreal switches, and in the end (because the error arose in an extremely short subroutine) commented out the subroutine calls one by one. I’d had a look in the .INS files and couldn’t see that I’d mismanaged any types, and eventually I tracked down the problem to this statement (not that it required much searching, as the subroutine indicated by the error message contains only 3 executable statements!):

L  = MoveToEx (IHDC,IX1,IY1,0)  

I’d already tried making the zero 0L, but eventually succeeded with:

N = 0
L  = MoveToEx (IHDC,IX1,IY1,N)  

I’d also examined whether or not the issue was the default to VGA colours changing to RGB colours, but it wasn’t that.

So what is the compiler command that makes all explicitly given INTEGER constants INTEGER*4?

Eddie,

I think that /intl is the compiler option you asked for:

http://www.silverfrost.com/ftn95-help/options/_intl_and_ints.aspx

Hi Wilfried,

I tried that, but it didn't work, which confused me as I thought it should work.

I went through the 12 files and put it in an OPTIONS (INTL) directive, then when that didn't work I specified it on the compilation command line, all to no avail.

I hated using %dw, and it is only the fact that it was an early program before I realised that %gr was the way to go, that has left me with a MoveToEx in one routine in one program!

I just mentioned it out of interest.

/INTL is the default assuming that FTN95 has not been configured differently via /CONFIG. Similarly all literal integers are INTEGER*4 by default.

I don't recall what MoveToEx expects.

MoveToEx expects INTEGER*4 - I looked in the INS file.

I can't remember the settings of FTN77 after all this time, and FTN95 is configured how it set itself up on installation, so FTN77 was probably the same.

I was surprised that my efforts using OPTIONS and 0L seemed to have no effect, that's all, but it was instantly fixed by passing the 0 to N, and using that in the subroutine call. If I need that old program again I'll convert from %dw to %gr, or maybe now the aspect ratio is fixed I'll leave well alone.

It certainly isn't something that I think needs investigation, and it only worried me in the senses that (a) I doubted my understanding for a while (my understanding being what you wrote), and (b) for an equal length of time I imagined that I would be converting to %gr then and there!

Eddie

I have always used /intl and /logl in my ftn95.cfg, which makes me think that the default for F77 was /ints and /logs. I do remember that a lot of program development I did in 70's was using INTEGER2 and have some recollection that that was the default for F77, but it was a long time ago !! There were also a lot of I2 variables in the library routines.

Sure, but which FTN77 are you talking about? FTN77/386, /486 with DBOS, DBOS and Clearwin, or FTN77 with its colours nailed firmly to the Windows mast?

By 1999, FTN95 was 32-bit Windows only, if I recall. I used INTEGER2 a lot with MS Fortran, and even struggled with REAL4, which although by dint of careful coding still produced acceptable answers, but they were different - subtly - if one used the software emulation for the coprocessor or the coprocessor itself. The math libraries were subtly different.

The old stuff is archaeology, and I only mentioned it because the old EXE ran fine today using its Salflibc.dll, and equally well with an up to date Salflibc. It compiled fine with FTN95, but had a runtime error.

Dare I experiment with even older programs, unused for even longer?

The final argument for MoveToEx is a returned pointer that can be NULL so one can use CORE4(0) for 32 bit.

Paul, thanks for looking it up. I imagine that MoveToEx will never cross my path again.