Windows 7 anyone?

I have recently been trying out Windows 7 (Beta as made available in January) using programs (Clearwin / FTN77 code) compiled under both XP and Vista using the current FTN95 compiler. I am pleased to report that they generally worked well. Windows 7 feels like a better / quicker version of Vista.

However in an attempt to trace a single 'glitch' in one program when running under Windows 7, I tried to compile and link (and hopefully break) under Windows 7. On a simple program it worked fine just once - in the middle of a series of attempts - in fact using FTN95 myprog.for /break ; However all other attempts using this and basic compile and link options caused an access violation near the end of the link process.

Whilst this issue may well be cured during the updates to Windows 7 I just wondered if others had made successful use of the Beta version to compile and link a program?

Many Thanks

Bill

No joy here I'm afraid. I'm trying out Win 7 x64 and can't get as far as linking - a fair few of my files compile, but I get some crashes in ftn95.exe within malloc. I can't comment on the x86 version.

Fortunately the final executables compiled on XP work fine.

malloc works differently when you use the 'new memory model' so it may be worth a try.

The 'new memory model' is described in the Forum Knowledge Base. It has been slightly modified in the impending release so you may prefer to wait for the salflibc.dll in 5.30.

Just thought I'd add to the discussion.

Using x64 build of Windows 7 RC (7100) I kept getting crashes from slink.exe when using Visual Studio 2008 (SP2)

I solved this issue by going into the silverfrost dir (in Program Files(x86) ), right clicking on slink.exe, choosing properties, clicking the compatability tab and selecting 'Windows XP (SP3)' from the dropdown

We have done some initial testing on Windows 7 RC 7100 (x86) and I have been able to reproduce a crash in slink. Setting the compatibility mode does not work for me. I have compiled a test build of slink that does now work on my Windows 7 installation. The error I was seeing was related to some of the internals of standard Windows DLLs having changed.

It is available at:

[ link removed until issues resolved ]

It is a debug build, hence the large size. If any users of Windows 7 could try this out and let us know how you get on, that would be useful. When reporting an issue could you please let us have the stack trace slink produces if it crashes.

Dear Andrew,

On my 32 bit RC 7100 with the latest FTN95 installed I replaced SLINK.EXE with the version posted. As with the std release version of SLINK, executing SLINK alone brings up a command window but absolutely nothing else - no [SLINK v**], no * prompt etc.

Using FTN95 prog.for /link used to bring up an SLINK error dialogue at the link stage but with the posted version simply produces a .OBJ but nothing else happens (no obvious attempt to run SLINK).

Happy to try out other settings etc as required.

Thanks.. Bill

Thanks and my apologies, there seems to be an issue with console output from this build and even from executables produced with it. We will have to look into this issue further with Windows 7. Incidentally, this is the first time that slink has had a problem in some time, over many different versions of Windows.

I am removing the link to the hosted version until this is resolved.

Hi all.

Is there any update on Windows 7 support (x86 & x64) and whether there is/will be a fix any time soon?

Thanks, Alan

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

I would be grateful for feedback as to whether these builds allow SLINK and Win32 programs to operate correctly. .NET should have been unaffected and should not require these files.

Dear Andrew,

I am very pleased to report that the above updated files seem to work fine with a batch of compilation / linking I have done today on a 32 bit Windows 7 test machine using the latest release Fortran / Clearwin.

Will continue to carry out tests.

Question - Could the updates also be used on a Windows XP or Windows Vista machine running the latest Fortran release without problems?

Many thanks indeed

Bill 😄

Great, good to know its looking good for you. Testing here showed no problems, but you know how it is when things get 'out there'.

These updated files are good for all versions of Windows, XP and Vista should have no issues at all.

Just tried to download using the link from a number of locations and it hangs at 992kB complaining about the server connection being reset. Alan

Break out the champers 😄 - touch wood it all seems to be working a treat in Win 7 RC x64 (! not tried it in x86 but I would expect that to be okay). Compiling, linking and debugging under a plain old domain user account with UAC enabled and it's all working. Fab.

I do have a question though - I've have to enable the new memory model otherwise the compiler crashes with memory allocation problems in some of my code. It works okay now - do I have to make sure the env var is set even when running the compiled executable, or just during compilation - it seems to work okay without it so presumably it's either just compile/link time or controls how salflib works at runtime.

It looks like there was an issue with the server host earlier today - thanks for letting us know. The link should now be working OK.

Here's a funny in Win7 RTM (x86 & x64). I'm using the updated salflib and it's generally okay but if I try to use VC to debug something that calls GET_FILTERED_FILE@ the program generates an access violation just after displaying the file open dialog. If you don't debug the program runs properly.

The really funny bit is that if I do some combination of logging out and in, or maybe logging on as an admin, then the debugger starts to work properly - for both the admin, and for the original user (standard domain user). From then on debugging works fine for everyone until I reboot. It;'s not specifically related to admin as the crash occurs if run by the administrator straight from a reboot, or if I set myself up as local admin.

It's not a show stopper as I tend to hibernate overnight, but it's darn strange. Here's a proggy that generates the problem (VC2008, Win32 debugger, updated salflib dll):

! Test GetFilteredFile - crashes VS 2008 Win32 debugger in Windows 7 (x86 & x64)
!   when running with updated salflib.dll
winapp
  include <windows.ins>
  
  character(len=260):: title, file, path
  integer, parameter:: NFILTERS = 2
  character(len=32):: filternames(NFILTERS),filterspecs(NFILTERS)
  integer:: mustexist

  title = 'Open File'
  file = ''
  path = ''
  filternames(1) = 'Fortran Source Files'
  filterspecs(1) = '*.f90;*.f95'
  filternames(2) = 'All Files'
  filterspecs(2) = '*.*'
  mustexist = 1
  call GET_FILTERED_FILE@(title, file, path, filternames, filterspecs, NFILTERS, mustexist)
end program

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

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

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?

Hi Norm

You could try this one:

http://www.ftn95.co.uk/ftn95/debugger.zip

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