/CHECKMATE versions run on one computer, but not the other

I have two computers that I use to develop code, both running V8.10.0 of FTN95. I use a MAKE file to compile the individual files, assemble them into a library, and link them into executables. All the files are shared via DropBox between the two computers.

Here's the issue I encountered while debugging: On the DESKTOP system, the /CHECKMATE version would not perform consistently. Specifically, using the 'FILE_OPENR', the button click would work once. Clicking on the button again would result in no action. The callback would not be executed. However, on the LAPTOP this same executable would run just fine as /CHECKMATE.

If I compiled and ran the /RELEASE version on both platforms, the program runs successfully regardless of where it was compiled/linked.

I looked at all the SilverFrost LIB and DLL files (date/time), looking for something amiss. I can see no differences based on the date/time stamp of the files as they exist on both systems. All the DLL's of the same name are the same size, and the same exists for all the LIB files.

Something to note: The executables are different, and this I cannot fully understand. For example, for the /CHECKMATE versions, the file sizes are the same, but when a binary compare is performed, the files are different. Similarly, when I look at the MAP output from the linker, the files do not match. Looking in some detail, even though the link step is identical (uses the same MAKE file) the ordering is different between the two platforms.

I am at a loss for an explanation as to why the DESKTOP system will not successfully run either /CHECKMATE version, but on the LAPTOP both /CHECKMATE executables run fine.

Any suggestions of things to try will be welcomed. Bill

Different object files/executables may arise on different machines because the processors may be different.

Try compiling/linking on* only* the machine where you have it working, and running the exe on both. This might give a clue - maybe it isn't compiling properly on one machine.

Check your code carefully, because errors may not show up on one machine but will on another.

davidb, thanks for the response.

Let me restate: I compiled both the /CHECKMATE and /RELEASE versions on BOTH platforms, then ran them all on BOTH platforms. So, 4 separate executables each run on BOTH platforms with the results as given in the previous message. The DESKTOP platform will NOT run either the DESKTOP compiled/linked executable, nor will it run the LAPTOP compiled/linked executable. The DESKTOP platform will run the RELEASE version from EITHER platform. The LAPTOP platform has no trouble running any of the 4 executables.

Check your code carefully, because errors may not show up on one machine but will on another.

By errors, I assume you mean compilation errors. That has never happened with the SilverFrost products. Also, the exact same command line is used on BOTH platforms to perform the compile. One command line to do /CHECKMATE, the other command line to do /RELEASE.

If you meant run-time errors, then we enter a grey area, because the code does run exactly as designed on one platform, but not on the other platform. But, no run-time errors. It just doesn't work the same way.

N.B.: If code compiled on one processor will run differently on a different processor, then we are all in trouble.

Some of the differences may not be significant. For example, there could be information in object code about the build time or the path to certain components.

Make sure that the compile time options are identical by generating and comparing .lis files for each build.

A compiler will usually produce different assembly code for different processors/CPUs. The operation of the program to the user should be the same though.

By errors I meant mistakes in your Fortran coding that are not picked up by the compiler. If the code is not compliant with the Fortran language specification or the extensions provided by Silverfrost, different results may be produced on different machines.

It appears your code doesn't run properly with /CHECKMATE enabled on your desktop machine. It would be useful to know what the machine/processor is.

If you are sure your Fortran is OK then it is possibly a bug in the compiler. In which case it would be helpful if a 'minimal' version could be posted here which exhibits the behaviour. If you can't do this then wait a little longer and perhaps Paul will be able to provide some insight into your use of FILE_OPENR.

Paul, I did look at the options in the .lis files.

They are identical.

I'm wondering if I should remove FTN95 and re-install. I have the DLL's for V8.10.0 as a separate ZIP file also.

I have the full V7.10 and the upgrades V7.20, 8.00, 8.05, and 8.10.0. I would assume to install in that order, then unzip the DLL's and lay them in the appropriate places.

Sound right?

Bill

Item 382 in cwplus.enh may be relevant here.

FILE_OPENR uses the Microsoft Open dialog and this may have issues relating to memory overload. Also /CHECKMATE might make heavier demands on memory. This is all very vague and unsubstantiated but the point is that using the following call may prove to provide a more stable outcome...

CALL CLEARWIN_OPTION@('alt_open_save')

You will need to note when this option became available. The date for 64 bit code was earlier than that for 32 bit code.

It may have already been covered, but using a selective build can cause a lot of problems. It is often that the date/time test for .obj and .mod files when copied may not work properly. Make sure you do a complete delete of all .obj, .mod, .dll and .lib files on either machine before rebuilding. I have a file 'rebuild_all.bat' for this purpose, including many cd and call commands. I had this problem many times when developing/testing on multiple PCs

John

Paul, that did it. It all works now.

I have documented this in the code as a requirement for the Main in each program.

Thanks a million! Bill