Welcome to our forums
Is FTN95, version 8.70.0.0 fully compatible with the Windows 11 operating system? If not, which later versions of FTN95, if any, are compatible with Windows 11?
I'm using FTN95 on WIN-11.
Works great!
Bill
There are no known issues with Windows 11 and FTN95 is fully supported for this operating system.
There have been several revisions of the compiler and tools that were made available and these are more recent than the version 8.70 that you have, 'dfwlms'. See the sticky thread at the top of the Support subforum, https://forums.silverfrost.com/Forum/Topic/3780 .
I have a few Windows 11 users complaining that my app causes problems - usually when opening a file. I am now using the new %cd format code rather than get_filtered_file@ and wonder whether this may be causing any of the problems.
simon, can you describe the problem they are having?
I've used both extensively. They differ only in the way that, internally, the file name is asked for. Once the file name is supplied, there isn't an issue. I will say there are nuances to using %cd that one needs to be cognizant of when developing a 'wrapper' to surround the %cd use(s).
Bill
Hi Bill, One user is getting an error message from the Fortran open command. I'm not 100% certain, but am guessing this is the error message 146 that you commented on before: https://forums.silverfrost.com/Forum/Topic/2932&highlight= I have asked them to check whether they have dropbox running. Another user simply said the app hung, but ran ok again when he restarted it. That could be anything! Anyway, I'm going to try your idea of repeated attempts at reopening of the file ... Thanks, Simon
Paul, you write, that Windows 11 and ftn95 work together without problems. What about the underflow issue for Windows 11 version 24H2 (see support, Problem with ftn95 v 9.95)? Has this issue been solved? KL
KL
Please see https://forums.silverfrost.com/Forum/Topic/4536.
The latest release of FTN95 for supported users is v9.10. In this release Win32 underflows are masked by default which means that Win32 underflows no longer cause a problem. Earlier versions of FTN95, when used with Win32 and Windows 11 24H2 require a call to mask_underflows@().
I got also some complaints from users which seem to be connected with Windows 11 and filtered_file. The program crashes not directly when a file is opened or saved but shortly after it (maybe a part of the memory is damaged and causes problems afterwards?). I don't have those problems on my machine.
However, when I compile the program with /checkmate, it crashes with the message "Exception 0xE06D7363" when I try to open a file .
Unfortunately I am not yet able to reproduce this error with a simple program.
I have had some problems with this as well.
I began using the %cd options, and surrounding it with code to accommodate how the calling routines are written. I use the same calling sequence as get_filtered_file, and includes an additional parameters, the handle to the calling programs window.
I can trim out the stuff that is unique to my situation and leave it pretty bare bones if there is a need/want.
Since starting to use this, I have had no situations where the program crashes (without indicating an error).
Bill
0xE06D7363 is an uncaught C++ exception. When you say 'open a file' do you mean show the open file dialog or try to open it afterwards?
The program crashes when I open the file dialog. %cd also crashes during a Checkmate debug session. I am currently using the drag-and-drop option %dr as a workaround.
Is anyone able to construct and post a short sample program that illustrates the failure?
Does this issue relate to Win32 or x64?
There are three ClearWin+ ways to open a file (or multiple files).
Here is an example that calls GET_MULTIPLE_FILENAMES@ and CLEARWIN_OPTION@("alt_open_save")...
USE clrwin
LOGICAL L,next
CHARACTER*256 filename,filter,defpath
filter = "Free Fortran files (*.f90)"//char(0)//"*.f90"//char(0) &
//"All files (*.*)"//char(0)//"*.*"//char(0)//char(0)
defpath = char(0)
L = .TRUE.
next = .FALSE.
CALL clearwin_option@("alt_open_save")
DO WHILE(L)
filename = char(0)
L = get_multiple_filenames@(0,"Dialog Title",filename,256,filter,defpath,next)
next = .TRUE.
IF(L) PRINT*, trim(filename)
END DO
END
The crashes during checkmate debug-sessions occur with the 32bit version, not with the 64bit version. However the crashes reported from the customers are with a 64bit Release version. So, maybe these are different problems...?
Using clearwin_option@("alt_open_save") does not change anything.
Ralf If you are not able to provide a short sample program then for the checkmate failure you could isolate the issue by using fewer checks at the point of failure.
Try using /undef which has fewer checks than /checkmate. Then /check is /undef but without the undef checking.
If it fails with /check then you can apply /check with /inhibit_check n1 n2 where n1 is the integer starting value and n2 is the integer finishing value for a range of checks from 1 to 22.
For example
/check /inhibit_check 5 6
will disable checks 5 and 6.
This will provide you with a work-around and maybe some useful feedback to us.
Using /undef still crashes. I assume, that I can use /inhibit_check n1 n2 several times in one compiler call with /check? In this case, I have to inhibit checks 4,6 and 9 to avoid crashes. Any combination, that does not inibit all of those three checks leads to an program crash when I open the file dialog.
/check /inhibit_check 4 9
avoids crashes, as well as
/check /inhibit_check 4 4 /inhibit_check 6 6 /inhibit_check 9 9
Ralf
This could imply that the failure relates to the invalid use of a POINTER. Maybe a pointer has been left "dangling". This means that the target is nolonger ALLOCATED or otherwise accessible.
Are you able to step through the code using the debugger SDBG just before the point of failure? It is even possible to single step through the assembly code by using F11 and then F7 for each instruction.
The E06D7363 exception in sdbg can be ignored: https://forums.silverfrost.com/Forum/Topic/3259#20890
