Issues with Windows XP 64 bit

Hi,

I am a rather lucky developer that was handed a bit of legacy Fortran code to support, so forgive me if my questions are a bit dumb.

Basically I have a user with an issue running a Fortran application on a Windows XP 64 bit OS. It works fine on their Windows 32 bit PC, but due to requirements at their end - they now need to upgrade all PCs to 64 bit.

The application is built & developed using Silverfrost FTN95 on a Windows XP 32 bit OS.

Im wondering if I need a specific 64 bit compiler, or a 64 bit version of salflibc.dll which is used in my application.

Can anyone point me in the direction of some help on this please.

Thanks

Paul

From looking on the forums, Im guessing that my issue is that a method is returning a different data type than expected, or a return type was not declared.

Is this a common issue with Fortran applications on a 64 bit OS, Im surprised that I wouldnt have see this issue on 32 bit OS though.

The error output from the user is does indicate a function call :

Access Violation The instruction at address 00437299 attempted to write to location 7fff1000

00437042 ALLOCATE2 [+0257]

00438e3f READ3_DYN [+0105]

00405530 TUBA_DRIVE [+0278]

1004d5fa call_function(<ptr>(func()ÄreturningÄint),<ptr>char,<ptr>void,enumÄlogical,enum [+012d]

100362a0 __yield_program_control [+0013]

100573dc __temporary_yield [+0016]

10096137 __winio [+1392]

00401000 MAIN [+006b]

eax=00000000 ebx=0051ae04 ecx=00000d70 edx=004f09bc esi=00000002 edi=7fff1000 ebp=0374f40c esp=0374f2ec IOPL=2 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00010246 [NC EP ZR SN DN NV]

00437299 rep
0043729a stosb
0043729b cmp [004ff884],0x0

any idea how I find out what function that is on my 32 bit development PC?

Thanks

Hello Paul,

I'm glad to see that you are using silverfrost. What version level are you at? I think that you may have to upgrade to the latest version.

You can check this. On a a PC without silverfrost installed, download and install the free personal edition of ftn95. Compile the code using this version and see if it runs on a XP 64bit machine.

If it runs okay then you will know that an upgrade is necessary.

Cheers, John

Hi there,

Thanks for your reply.

Im not 100% sure what version of FTN95 I am using. ifI do a 'VER' at the FTN95 command prompt then it tells me I am on version 5.1.2600, but I thought I was on version 5.40 of the compiler (which I downloaded on Friday)

Im not sure what version the of FTN95 the software that Im having the issue with was built on though as it was before my time.

I will try re-building using the sompiler I have just now.

Thanks

actually, Im not sure what version of FTN95 I am on. according to the upgrade link I have in the user area - I should be on version 6.0

I dont seem to be able to see the version number anywhere other than running the VER command

The 'FTN95 command window' is a standard Windows command prompt window, with some environmental variables set for the Salford compiler.

Therefore, the VER command will only give you the version of Windows. Conceivably, from the same command window you can run the Salford C compiler, the old Salford F77 compiler, or any other compiler. How can a single VER command anticipate which compiler you will use in the future and give you the version of that compiler?

The command FTN95 /V will give you the version of the Salford Fortran compiler. If you have trouble with the colours that are used for displaying text, use FTN95 /nocolour /V instead.

As far as your guesses about 32-bit programs on a 64-bit OS are concerned, I think that you are letting yourself be misled. Salford Fortran is a 32-bit compiler and the programs that it generates are 32-bit applications. However, if the program that you are compiling has bugs the run-time errors can be different on different versions of Windows or, for that matter, they can even be different during different runs on the same machine. That kind of behaviour is not at all uncommon; in fact, the Fortran Standard uses the phrase 'behavior is undefined' to cover that.

The Salford compiler provides very good error-detection capabilities that you can benefit from. Often, old Fortran programs contain hidden bugs that are not detected for decades.

Thank you very much for that, you are most likely very correct.

The code itself is rather old and written by one person a few years ago. it has been passed around a little over the last couple of years to people with little experience in this language (myself included). So the idea of there being sleeper bugs in there is certainly a good possibility.

We do have some test cases that we run prior to every release, and I do know that the user was able to run the same examples fine on their 32 bit OS. So my initial thoughts were that I needed a 64 bit compiler.

It could well be that I need to go back and debug it more - now all I need is a 64 bit XP OS and a bit of luck 😃

Thanks

Do you mean XP 64-bit? Vista and Windows 7 64-bit are far more common. FTN95 will run on some XP 64-bit versions, but not the '64-bit edition' http://en.wikipedia.org/wiki/Windows_XP_64-bit_Edition#Windows_XP_64-Bit_Edition because it is for an incompatible processor.

Hi there,

yeah it really is the 64 bit XP OS. I expected it to be windows 7 or vista too.

Are there issues with ALL XP 64 bit editions, or are they more specific to the '64 bit Edition' over the 'Professional x64 Edition'?

I do know that my latest version of the code, compiled using V6.0 of FTN95 will work on a 64 bit Windows 7 PC without any issues (that I have found anyway)

Thanks again

I think 'Professional x64 Edition' will work

There is the expectation that running on Win 64 will allow larger problems to be solved, but the program is still a 32-bit executable and limited to about 1.7gb (or 3.7gb with careful use of Allocate). Is the user on XP-x64 running the same problem as on XP (32) ? You may need to improve the code to check the problem is not too big for the program settings. I would be compiling with /debug or possibly /check to see if the problem you are having can be better identified. Unfortunately, selecting these compilation options will change the memory usage and so may change the problem. As I have indicated elsewhere, I am running with XP x64 Professional with no noticeable problems and finding improved performance, mainly due to the extra memory available to the OS. John

Hi John,

Thanks for your reply.

In response to your question 'Is the user on XP-x64 running the same problem as on XP (32) ? '. At present there is no problem on XP 32 bit, thats the platform we develop on and all other users use. We dont actually have a 64 bit XP pc in house - so one would need to be built before I can delve into these issues further.

As an aside, I have tested the program on a Windows 7 64 bit PC with no problems, but I know that it was based on a different version of Windows than the XP 64 bit versions.

I do know that the code does a variety of memory management, ranging from FTN77 methods through to the developers own ways of dealing with certain things.

So that was where I expected to end up looking, although I was hoping I could find another solution before going there!

Thanks for all your (and everyone elses) help on this. I will speak to the client and perform a couple more tests before I decide the next stage.

Thanks again

Paul

Paul,

My comment 'Is the user on XP-x64 running the same problem as on XP (32) ?' was refering to running the same data set. I would definately try running a /debug option to (hopefully) give a more detailed location of the error. Using /debug and SDBG can provide a lot of info, if you trust the user. You could also suggest running task manager , to report the VM Size, I/O read bytes and I/O write bytes. As this program uses F77 style, program based memory management (ALLOCATE2) and potentially ALLOCATE, there might be external settings on the available memory pool being selected (sounds a bit familiar). Make sure they don't have an expectation to choose more than about 1.7gb of available memory, as the program is still only 32-bit. If no part of the program has been compiled with /debug, then the ALLOCATE may have access to 3.7gb of memory and so behave differently to running on a win-32 OS. The stack, heap and other system bits in the user 2gb space could also be located differently on XP x64, so expected memory usage may have changed.

Again, my experience of 64-bit has been good. My software has all the memory approaches you have suggested and runs better than with win-32.

John

Thanks John - thats all very useful and kind of where we hoped the issue didnt lie.

I will see if the user is happy to do some debug testing for us and see if that throws up any pointers

Thanks again - thats been really helpful. I will post back if I find out anything or solve the issue

Hey Paul,

I'm new on the forums, but was pretty interested in this thread. What did the user say? Did you make any progress? Ever since I started my e-mail newsletter I have been trying to figure out the most effective way to interact with my customers while still speaking understandable computer language within the coding environment of my email marketing software. I have been chopping up youtube videos with some video converter and editing software. Would love to hear what happened with your project.