Welcome to our forums
Using the 64 bit compiler with the /windows directive I get executables which show a DOS box window on execution. With the 32 bit compiled executables the /windows directive makes an executable which runs in the background without showing the DOS box. How do I get the 64 bit compiler to behave in the same way?
/windows is basically a linker option but it should be passed on to SLINK64 by FTN95 when used with /link or /lgo on the FTN95 command line.
Alternatively you can use WINAPP in the code or the comment embedded directive !FTN95$WINAPP
The other way is to use the windows option when linking via SLINK64.
Thanks that now works for my larger programs but I came across this problem with a trivial program test64.f, which works perfectly as a 32 bit windows or console executable, however compiled
program main
do i=1,1000
write(6,*) i
enddo
end
When compiled using
ftn95 test64.f /link/windows/64
or if compiling the resultant object module using
slink64 test64.obj /file:test64.exe /windows
I get an executable which crashes with variable error messages. Without the /windows directive, the resultant console application works fine
It works OK for me. Which version of FTN95 are you using and which version of Windows?
Windows 10 Pro 64 bit
FTN95 8.00.0
Salflibc64.dll is in Windows\system but same thing happens if I place it in same directory as executable
Salflibc64.dll should not be in \Windows\system ! I expect you have modified/mangled the install process. Have you looked at fvars.bat This sets the environment variables and especially path, assuming FTN95 is installed in C:\Program Files (x86)\Silverfrost\FTN95
I use a slightly different version of fvars.bat @echo off echo. echo Setting Environment for FTN95 for Microsoft .NET and Win32 echo. SET ftn95_dir=C:\Program Files (x86)\Silverfrost\FTN95 SET PATH=C:\Windows\Microsoft.NET\Framework\v2.0.50727;%PATH% SET PATH=%ftn95_dir%;%PATH% SET F95INCLUDE=%ftn95_dir%\Include SET MOD_PATH=%ftn95_dir%\Include
I just manually placed the two salflibc dll's in windows system after installion. I used the default location for installing FTN95 which the installer program gave me.
Where should salflibc.dll & salflibc64.dll be located? I usually place a copy in the directory with all the executables.
I have now deleted salflibc64.dll from Windows\system and also from the directory where the executable is located.
The program still gives the same error, from within kernelbase.dll. How can I send you a screen shot of the message?
With a normal FTN95 install, both these files should be in: C:\Program Files (x86)\Silverfrost\FTN95 ie %ftn95_dir% in my previous post, which is included in %PATH%.
The reason I have %ftn95_dir% is that I have multiple versions of FTN95 installed in C:\Program Files (x86)\Silverfrost To select alternate versions, I just change the %ftn95_dir% environment variable and everything else is updated. It avoids changing all the other environment variables. I also do that with other packages I have installed.
John
Can anyone replicate this failure under Windows 10? I don't have easy access to Windows 10 at the moment.
I have windows 10 home on a notebook with ftn95 Ver 8.00.0 built Sat Apr 9 2016. I tried both: ftn95 test64.f /win /link ftn95 test64.f /win /link /64
They both ran, although did not stop until I closed output. No sign of an error report. both looked identical, except for (32 bit) in task manager.
I can not reproduce the problem.
John
Very strange
I just installed FTN95 on another Windows 10 machine I have. Both 32 and 64 bit executables of test64 ran without error
I then completely re-installed FTN95 on the machine causing the problem and the result is the same error with the test program.
I have a large number of very complex Salford compiled programs and this trivial one is the only one causing an issue. But I never write text out to a default window (i.e. to one which I did not explicitly create in the code)
Both machines did not come with Windows 10, but were upgraded from Win 7 after purchase.
I would suggest that in your past attempts you may have copied an old FTN95 .dll or .lib file into another part of your path and the wrong version is being used. You could modify your path variable to have the FTN95 directory as the first entry in your path. This might fix the problem. Look in C:\Program Files (x86)\Silverfrost\ftn95 and see what .dll and .lib files are listed and scan for those in the other directories listed in the PATH you currently have. saldiag.exe can help with this search, although my version is old and has not been updated for /64 files.
Let us know if this identifies the problem.
Dear John Thanks for the hint. I removed several old copies of salflibc.dll which were not in the Program File (x86)/Silverfrost directory.
The only other versions on my c: drive (only this drive is in the path) are in a Silverfrost_old directory which is definitely not in the path.
There was only a single copy of salflibc64.dll on my machine, in the 'official' place.
Still same problem with test64 though. The error message states the exception occured in kernelbase.dll which is I presume a Windows system dll
What's strange is that all the 64bit programs (admittedly not that many) that I have compiled since I got the new compiler recently seem to work fine.
Just installed FTN95 Version 8.20 and integerated it with Visual Studio 2015. I can't get rid of the console window when using the 64 bit option. I've tried using WINAPP I've tried using /WINDOWS
The buildlog.txt uses the compilation command:
FTN95.EXE 'C:\Users\Ian\Documents\VectorF90\caesarformat\caesarformat.for' /NO_BANNER /FPP /windows /64 /VS8 /DELETE_OBJ_ON_ERROR /ERROR_NUMBERS /UNLIMITED_ERRORS /BINARY 'Release\x64\caesarformat.obj'
It works with WIN32.
I'm using Windows 10.
Help Ian
I will have to check this but it is quite possible that the 32 bit object code contains a /windows flag whilst the 64 bit object code does not.
/windows is basically a linker option (the linker puts a marker in the header of the exdcutable).
/windows will work with /link and /lgo on the FTN95 command line because the flag is passed on to the spawned linker command line. Otherwise you must provide /windows as a linker option (for 64 bits).
Paul, in 64 bit mode, I have tried putting the /windows switch into the compiler 'Miscellaneous, Extra Compiler switches' section. I have put variously '/windows' and 'windows' into the 'Linker Options, Extra Linker Options'. It does not show up in the 'Linker switches' section and it is not shown in the 'link.inf' file.
However if I compile it and then manually load the object, specify 'windows' and 'file' then it works without the console box.
If I do the same in WIN32, then it works correctly. The 'link.inf' does not include 'windows'. so it must be getting this passed from the compiler to the object file as you suggested. Regards Ian
Ian
The Plato released with version 8.20 of FTN95 has 'Windows application' under 'Linker Options' in the Project Properties. Just select this option.
I don't recall if this was in earlier releases.
I'm not using Plato. I'm using Visual Studio 2015.
Regards Ian