forums.silverfrost.com

[BILLDOWS]

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

[acw]

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.

[PaulLaidler]

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.

[Lloyd]

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

[Andrew]

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.

[BILLDOWS]

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

[Andrew]

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.

[acw]

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

[Andrew]

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.

[BILLDOWS]

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

[Andrew]

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.

[acw]

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

[acw]

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.

[Andrew]

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.

[acw]

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):