forums.silverfrost.com

[tbell]

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

[silverfrost]

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


------------
Administrator
Silverfrost Forums

[tbell]

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

[Anonymous]

Tom,

How curious that you should post about this just at the time when an even more acute version of the same conundrum is testing my own brain to the extreme. I can do much better (or worse ) than your situation. I have the same build of the application, calling the same versions of five runtime libraries, on two machines, both Win2k SP4, that are giving markedly different results!

My situation isn't just number-crunching (although it does that too), because the application interfaces to a scanner. But the same version of the scanner driver is installed on both machines, and it's the same scanner - not just two scanners of the same model - literally the same scanner, carted back and forth between the two machines. My measure of markedly different results is that the pixel values in images acquired by the application are consistently about 20% greater on one PC than on the other. That's a huge difference.

There is a process called negotiation where the application talks to the scanner and specifies values for various settings, the details of which are more appropriate for a different forum that I'm also going to post to. Suffice to say here that what seems to be going on, the evidence for which is also more appropriate elsewhere, is that on one machine, this negotiation process is taking place correctly on both machines, but then being ignored on one machine when the image is actually acquired.

I'm not convinced its a problem with FTN95, although I can't rule that out either. I probably wouldn't have posted if I hadn't seen this post.

One thing it definitely is not, in my case, is undefined variables. I get the problem with a debug build which checks for them.

Although both machines are Win2k SP4, they are not exactly the same. One is online, so gets all the latest hotfixes, and one is offline, and so doesn't. 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. I don't find it very convincing but I don't have a more plausible hypothesis.

Some informed speculation, please, from anybody - and wild guesswork if not

Andy

[sparge]

"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

[PaulLaidler]

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.

[JohnCampbell]

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' :INTEGER*4
C_EXTERNAL INITLIBRARYFILEINFO@ '_InitLibraryFileInfo'():INTEGER*4
C_EXTERNAL GETLIBRARYVERSIONINFO@ '_GetLibraryVersionInfo'():STRING
C_EXTERNAL GETLIBRARYPATH@ '_GetLibraryPath'():STRING
C_EXTERNAL GETLIBRARYDATEINFO@ '_GetLibraryDateInfo'():STRING
!
integer dll_version
character str_dll_version_info*256
character dos_date*9, 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)
!
integer*2 yymmdd
!
character temp*9, label(0:12)*3
integer*4 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

[sparge]

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