forums.silverfrost.com

[niels]

Dear Silverfrost,
Until recently I have happily been using FTN95 v5.50, mainly as a result of staying well within the default of 2GB of addressable memory. A need to expand the problem size of my applications revealed a number of problems which I subsequently could verify through the FTN95 forum. During this process I observed 3 different levels of operation approaching 2GB+:
1. All good and well including OPENF for opening files
2. Available space not sufficient for OPENF to operate: The program would hang in the windows API??. Yet, sufficient space to run the application with input file as an argument.
3. The needed space less than 2GB exceeds the available space: At execution time the system response is:
C:\.................\Fred.exe is not a valid Win32 application.
(Is this error message generated by FTN95 or Windows?)
This was understandably done in Win7_32bit operation.
Exactly the same happened in Win7_64bit (x86) operation.
From the forum it appeared that upgrading to a version later than 6.30 would solve the problem - time to upgrade!
Yesterday I installed version 7.10, only to find no difference even when running Win7_64bit. It was my understanding that SLINK would plant a flag in the executable�s header breaking the 2GB available barrier.
This morning I found some encouragement from the following Microsoft link to WOW64:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384219(v=vs.85).aspx :
If the application has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set in the image header, each 32-bit application receives 4 GB of virtual address space in the WOW64 environment. If the IMAGE_FILE_LARGE_ADDRESS_AWARE flag is not set, each 32-bit application receives 2 GB of virtual address space in the WOW64 environment.
Is this the type of flag used in SLINK? � if not, would this be a worthy improvement to FTN95 which has served us so well over 25 years? It would give us at least as near as possible the full 32bit address space?
If it is: How do you enable it - /3GB wouldn't suffice?
On this note, it is encouraging to know that ClearWin+ is now available in proper 64bit mode integrating with 64bit compilers. What are the chances that Intel�s Fortran compiler could become a choice?
Best regards
Niels

[PaulLaidler]

SLINK has a the switch /3GB which is effective for certain operating systems provided that you use a similar switch in your boot.ini file.

For more information search for 3GB on this forum e.g

http://forums.silverfrost.com/viewtopic.php?t=2756&highlight=3gb

Also search for 3GB in ftn95.chm.

[JohnCampbell]

You can access more than 2gb with FTN95, although there are some restrictions:
* Any arrays above 2gb must be defined using ALLOCATE. ( similar to with 64-bit)
* Compile options /check and above turn off the /3gb options. /debug should be ok to use, although no debugging or checking options are best.
* A single array size limit is less than 2gb, so to access more than 2gb you must allocate at least 2 arrays.

You should first try a test program to confirm it works.

I question your reason for trying /3gb, as running out of memory with OPENF may be due to another problem, and looking for more memory may not be the solution.
There has been a problem with Windows 7 file opening, which "drains" memory. I have not had this problem for a while and do not know if it has been solved. It relates to the API routines for opening a file in a dialog box. I had to reduce the memory footprint of my program to below 1.6gb to overcome the problem.
If this is the basis of your problem, the solution may be to either reduce the memory requirement, or use an alternative file opening approach to the API file opening dialog box.

John

(What is OPENF ?)

[niels]

John/Paul
John: first apology for OPENF � meant to illustrate the ClearWin+ API functions: FILE_OPENR or GET_FILTERED_FILE@. Both of which at the limit of memory capability would crash the program in true Microsoft fashion of infinite loop in ntdll.dll library.

Thank you for your input. Unfortunately it does not seem to solve my problem, but raises more questions.

In Windows 7 32bit OS as long as my static link memory map does not exceed 2GB the program will start up whether 3GB system limit is used or not. If my memory map exceeds 2GB the program will terminate with the message: C:\.................\Fred.exe is not a valid Win32 application. This is despite having defined the 3GB system limit in the booting system and ensured the 3GB enabled by SLINK. Could it be possible that somewhere in the FTN95 start up process there is a check for 2GB compliance irrespective of 3GB flag set or not? From my investigations it looks very much as if that could be the case, as it is FTN95 reporting the problem.
All I need at the moment is a limit of 2.5GB, and 3GB should be enough, as 1.8GB works within 2GB user environment.

In Windows 7 64bit OS the WOW64 32bit enabler seems to provide the necessary functionality, enabling the 2GB default user memory to be expanded to 4GB if the IMAGE_FILE_LARGE_ADDRESS_AWARE flag is set. Given that FTN95/ClearWin+ support 4GB addressing it would appear that MS has enabled an improvement for 32bit programs running on a 64bit machine as opposed to running on a 32bit machine in terms of memory size.
Whereas it seems possible to check the flag from within an application it seems less clear how to set the flag � something which could be done at linking time by SLINK.
Please enlighten me if I am completely wrong.
Best regards
Niels

[JohnCampbell]

I missed this post. Your static load can not exceed about 1.8gb. However you can extend the memory usage by using allocatable arrays, as is the case with any (64bit) compiler. I think you can place these allocatable arrays in a module to use them effectively. You can not extend memory with /check, although recently you can use /debug. I have also had problems using more than 2gb with clearwin.

John