Windows 2000 Results vs XP Results

I have written a CPU intensive program (heavy floating point number crunching) that was compiled and linked (FTN95/Win32 4.8.0) in Windows XP (Version 5.1 service pack 1). This program is distributed to my clients. The program produces different results (same executable and Salford DLL) when run on Windows 2000 Professional(Version 5.0.2195 Service Pack 4 Build 2195) and XP. What could be causing this?

This problem is reproduced on different machines with different CPUs and different versions/service packs of windows 2000 and xp.

This is a major problem as my clients are electric utilities that use my program to file rate cases with public service commissions. It is of great concern when they switch Microsoft operating systems and get different results. My understanding was that the Salford Fortran 95 compiler was Windows 2000 and XP compliant.

Any help would be greatly appreciated. Regards.

Tom Bellissimo

Usually these problems are caused by use of undefined variables. Have you tried compiling the project with /undef ?

Administrator Silverfrost Forums

Thanks.... I'll give that a try.

'So what the facts appear to be telling me is that a recent hotfix has either introduced a bug, or is tickling a bug in one of the runtime libraries.'

Whoops - as I just realised while thinking about this. I got this the wrong way round. It's the machine that is up to date with all the post SP4 hotfixes - my main machine - that is behaving 'correctly'. So actually what the facts appear to be telling me is that a recent hotfix has either fixed a bug, or stopped a bug in one of the runtime libraries from being tickled.

I still don't find it very plausible - I've been using this scanner on the main machine for approximately two years, and it has always delivered 'correct' images - but it's more plausible than the other way round, I suppose. More consistent with the second law of thermodynamics anyway 😃

If the results from two operating systems differ then (in theory) it should be possible to compare the calculations to find the point of divergence. I know that in some cases this might take days rather than hours to do but usually it can be done in the end.

Life becomes much more difficult if the algorithm used is sensitive to round-off error (or occasionally integer overflow). In round-off error cases the source of the divergence may be impossible to find. Problems of this kind become apparent if different results are obtained when greater precision is employed. In some cases using greater precision does not help and there may be no alternative to going back to the drawing board and researching a better algorithm.

Of course these are general comments that are unlikely to apply in the situations described in this thread.

Have you checked the dll version on both machines. I have not found this to be a problem, but I did notice an old version on one of my PC's had been placed in c:\windows. It may be worth checking !

The following code was supplied by Salford to get and echo the dll version. ( I use unit 98 as a trace file in all programs )

  subroutine echo_dll_version

! C_EXTERNAL SCC_LIB_VERSION@ '_scc_lib_version' :INTEGER4 C_EXTERNAL INITLIBRARYFILEINFO@ '_InitLibraryFileInfo'():INTEGER4 C_EXTERNAL GETLIBRARYVERSIONINFO@ '_GetLibraryVersionInfo'():STRING C_EXTERNAL GETLIBRARYPATH@ '_GetLibraryPath'():STRING C_EXTERNAL GETLIBRARYDATEINFO@ '_GetLibraryDateInfo'():STRING ! integer dll_version character str_dll_version_info256 character dos_date9, dll_date*9 external dos_date ! dll_version = 0 dll_version = INITLIBRARYFILEINFO@() if (dll_version > 0) then str_dll_version_info = GETLIBRARYVERSIONINFO@() write ( *,1000) ' dll_version_inf : ', trim (str_dll_version_info) write (98,1000) ' dll_version_inf : ', trim (str_dll_version_info) str_dll_version_info = GETLIBRARYPATH@() write ( *,1000) ' dll_path_inf : ', trim (str_dll_version_info) write (98,1000) ' dll_path_inf : ', trim (str_dll_version_info) str_dll_version_info = GETLIBRARYDATEINFO@() write ( *,1000) ' dll_date_inf : ', trim (str_dll_version_info) write (98,1000) ' dll_date_inf : ', trim (str_dll_version_info) else dll_version = scc_lib_version@ () dll_date = dos_date (ints(dll_version)) ! WRITE ( *,1001) dll_date, dll_version WRITE (98,1001) dll_date, dll_version end if write ( *,1000) ' ' write (98,1000) ' ' 1000 FORMAT (a,a) 1001 FORMAT (' Salford DLL code : ',a,i11) ! RETURN ! END

  character*9 function dos_date (yymmdd)

! integer2 yymmdd ! character temp9, label(0:12)3 integer4 yy,mm,dd intrinsic mod data label / '___', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', & 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec' / ! ! yyyyyyy mmmm ddddd dd = iand (yymmdd,31) ! 0-31 mm = iand (ishft(yymmdd,-5),15) ! 0-15 yy = ishft (yymmdd,-9) ! 0-127 ! yy = mod (yy+1980,100) if (mm>12 .OR. mm<0) mm = 0 ! write (temp,1001) dd,label(mm),yy 1001 format (i2.2,'-',a3,'-',i2.2) dos_date = temp return end

Hi John,

Thanks for the reminder - you're absolutely right, of course - I should have checked this. On the problem machine I knew there was only one up-to-date version, because I'd just rebuilt it from the OS up, but on my development machine there are often multiple older versions hanging around in forgotten corners, and sure enough I just found a few and got rid of them. However, they were red herrings. I never seriously thought FTN95 was responsible, and the evidence is starting to point that way too now.

It turned out that I wasn't using quite the same version of the scanner software on the two Win2k machines 😮 The version on my development machine was slightly older - I uninstalled it and installed the later version, and reproduced the problem on the other machine. Meanwhile, I had also got hold of a WinXP machine, and had installed the later version of the software on it - it showed the same problem. Then I discovered there was an XP-certified version of the scanner software, so I updated to that and the problem went away.

So now my problem looks like the non-XP software - which is supposed to be generic for Win98/ME/2k - started to do something slightly different in the most recent update, which still works for Win98 but not Win2k. Interestingly, the version number for the non-XP software is 2.6, whereas for the XP software there is a non-certified version 2.6 and a certified v2.5. Why anyone would go for a non-certified version, when the whole point of an XP driver is that it is certified, beats me - so I decided to go for the certified v2.5. I'd bet good money that if I had downloaded and installed the non-certified v2.6 I'd have seen the same problem as I'm seeing on the problem machines.

None of which is probably any help to the OP. Tom, can you tell us a bit more about your application e.g. Is it a completely self-contained FTN95 app, or does it hook into other stuff? What is your yardstick for the difference between Win2k and WinXP runs? How much time have you spent stepping through plausible candidate bits of code in debug? Have you tried running the app under control of Dependency Walker - that might give you some clues as to where the problem is arising.

Good luck!

Andy