Windows 7 anyone?

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

1. Yes, that will be no problem
2. We are reviewing some other recent changes then will release a new build.

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.

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.

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

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.

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'.

Make sure you have things in .NET configuration. Then go to 'Linker Options' - its the top option.

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.

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.