View previous topic :: View next topic |
Author |
Message |
aebolzan
Joined: 06 Jul 2007 Posts: 229 Location: La Plata, Argentina
|
Posted: Thu Sep 10, 2009 4:56 pm Post subject: |
|
|
well, it seems you have the same problem I found with my programs. In fact I have little time to run a exhaustive test, but even with the updated libraries, FTN95 crashes under Windows 7, so that for the moment I am running it in XP compatible mode (and works really fine!). I am also using the get_filtered_file@ subroutine and seems that my program crashes when it founds it, but I cannot say the this is the only problem with FTN95. I am waiting for the next release of FTN95 to see if I can use it under Windows 7. By the way: I am not using Visual Studio. Just my two cents.
Agustin |
|
Back to top |
|
|
aebolzan
Joined: 06 Jul 2007 Posts: 229 Location: La Plata, Argentina
|
Posted: Mon Sep 28, 2009 12:28 am Post subject: |
|
|
I have just found that FTN95 with the new libraries works really fine under Windows 7!: I have found that the problems I had under Win7 and (reported in another forum) Vista was due to a problem with a variable that appeared undefined during the runtime of my program. I do not know why, but the presence of this undefined variable made the program to hang during running, a fact that never happened under Windows XP. Seems that the new Windows are more sensitive to this issue and for this reason I never detected the problem with that variable during the time I used XP.
Agustin |
|
Back to top |
|
|
Norm.Campbell
Joined: 31 Aug 2007 Posts: 66
|
Posted: Mon Dec 21, 2009 10:03 am Post subject: |
|
|
I had to buy a new desktop, and move to Windows 7. When I tried to compile and link a program which ran under XP, the linker crashed.
I found the post by Andrew on July 23 ("We have been looking at Windows 7 support and it looks like we have resolved the issues with it. A new build of salflibc and slink are needed to use FTN95 with Windows 7 and can be downloaded now from: http://www.ftn95.co.uk/ftn95/windows7.zip".)
As others have reported, these builds allowed SLINK and Win32 programs to operate correctly.
However, I could not get sdbg to run successfully, after compiling with /check /undefined to find a bug. Is there also a FTN95 Windows 7 fix for this, or do I need to upgrade to 5.40? |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
|
Back to top |
|
|
Andrew
Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany
|
Posted: Mon Jan 11, 2010 12:24 pm Post subject: |
|
|
Another Windows 7 issue has been resolved, which requires a new build of slink.
The issue is seen when compiling on Windows 7 and then running the compiled executable on versions of Windows below Windows 7 or Windows Server 2008. On these lower version operating systems the executables may fail due to not being able to locate certain functions in Windows system DLLs. This would only happen when making use of some (but not all - direct registry calls would exhibit the issue for example) direct calls to the Windows API.
This has now been resolved and the fix will be in the next release of the compiler. In the mean time you can download a new build of slink if you have been affected by this issue from:
http://www.ftn95.co.uk/ftn95/slink_w7.zip |
|
Back to top |
|
|
BILLDOWS
Joined: 22 Jul 2005 Posts: 86 Location: Swansea, UK
|
Posted: Tue Feb 02, 2010 12:00 pm Post subject: |
|
|
Many thanks for this update to slink - though I have not (yet?) experienced this problem.
1. As I am currently half-way between moving from Vista to W7 would it be fine to update slink on both machines? - code then running fine on any platform regardless of where it was compiled?
2. Is there any approx date for a new release?
Many Thanks
Bill |
|
Back to top |
|
|
Andrew
Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany
|
Posted: Tue Feb 02, 2010 12:07 pm Post subject: |
|
|
1) Yes, that will be no problem
2) We are reviewing some other recent changes then will release a new build. |
|
Back to top |
|
|
RS
Joined: 22 Jun 2008 Posts: 22
|
Posted: Tue Mar 09, 2010 12:38 am Post subject: Windows 7 - Visual Studio 2010 |
|
|
I have two questions, Andrew.
1) I have been suing FTN95 with VS 2008. Will integration with 2010 come in the near future?
2) I need to run an exe process compiled with VS 2008/FTN95 from within a C# application. If I could have compiled it as x86, it would run fine in Windows 7 64 bit. However, the two options available (.NET and win32) produce an exe that appears to be understood as "any CPU", and so it crashed when I do process.Start() on it. I can fix it with corflags.exe, but that is not what I need. I need that exe to work perfectly without user intervention. Any guidance?
Thanks. |
|
Back to top |
|
|
Andrew
Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany
|
Posted: Tue Mar 09, 2010 11:12 am Post subject: |
|
|
1) Support for 2010 will be looked at in the next few months. Depending on the changes that Microsoft have made (which look to be quite large) to the editor, the time taken to integrate with 2010 will be affected accordingly.
2) When compiling .NET apps with Visual Studio they should be set to 32 bit only. I have just compiled a simple exe and in ILDASM can see the following:
.module FortranApplication1.exe
// MVID: {1C977C3F-C292-4E08-8452-9CE279C74356}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x06000000
.subsystem 0x0003 // WINDOWS_CUI
.corflags 0x00000003 // ILONLY 32BITREQUIRED
// Image base: 0x003F0000
You can see the corflags are correct.
The option on the command line is:
/target:<string>
Specify target platform, choice is x86, ia64 or amd64,
default is x86
which you could try adding to the extra linker options.
UPDATE: It seems when the EXE is set to be a Windows application, the corflags are not set correctly. If you leave 'Windows application' as 'No' the corflags will be set as required.
UPDATE2: This has now been fixed and will be in the next release of FTN95. Until then, you could use corflags as a post build process. |
|
Back to top |
|
|
RS
Joined: 22 Jun 2008 Posts: 22
|
Posted: Tue Mar 09, 2010 2:15 pm Post subject: In the meantime... |
|
|
Andrew,
It was not clear to me from your reply whether there is a way to compile and produce the correct corflags tags for an x86 application or whether I have to, for now, use corflags to fix it.
Thanks,
Rod |
|
Back to top |
|
|
Andrew
Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany
|
Posted: Tue Mar 09, 2010 2:24 pm Post subject: |
|
|
There are several points:
- if you are compiling a non-Windows application ('Windows application' set to 'No' in the .NET linker options), then the flags should be correct already.
- if you are compiling a Windows application then you will have to use corflags.exe to set 32BIT+ for now. You can incorporate it into the build process as a 'Custom Build Step' so you dont have to manually execute corflags.exe each time.
The correct setting of the flags when compiling as a Windows application has now been fixed internally and will be in the next compiler release. |
|
Back to top |
|
|
RS
Joined: 22 Jun 2008 Posts: 22
|
Posted: Tue Mar 09, 2010 3:42 pm Post subject: Where can I switch from "Windows Application" |
|
|
I looked for where to make this change in Project Properties and Build Configuration in VS and could not find where I could set Windows Application to "no". |
|
Back to top |
|
|
Andrew
Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany
|
Posted: Tue Mar 09, 2010 6:53 pm Post subject: |
|
|
Make sure you have things in .NET configuration. Then go to 'Linker Options' - its the top option. |
|
Back to top |
|
|
RS
Joined: 22 Jun 2008 Posts: 22
|
Posted: Fri Mar 12, 2010 5:31 pm Post subject: Didn't work |
|
|
With the version of FTN95 that I have (my subscription expired late last year, so it is is fairly recent), doing what you suggested does not generate an X86 application with PE = PE32 and 32Bit = 1. |
|
Back to top |
|
|
RS
Joined: 22 Jun 2008 Posts: 22
|
Posted: Fri Mar 12, 2010 7:19 pm Post subject: Didn't work |
|
|
With the version of FTN95 that I have (my subscription expired late last year, so it is is fairly recent), doing what you suggested does not generate an X86 application with PE = PE32 and 32Bit = 1. |
|
Back to top |
|
|
|