forums.silverfrost.com

[Lloyd]

I am in the process of converting some ftn77 code to .net so we can interact with a C# frontend without using file i/o.

I started by converting the 77 code to 95 by changing common block to modules, removing obsolescent features and set implicit none etc.

Everything compiles and runs fine as FTN95 Win32.

When I compile as .net I get the following TypeInitializationException:

"The type initializer for 'program name' threw an exception".

I have tried wrapping all the main function in a try block, but it still exceptions, which leads me to believe is must be something to do with the module blocks, or an interface rather than the code in the main program itself.

Does anyone have any suggestions for what the cause is, and how to go about resolving this?

[PaulLaidler]

First, Fortran 77 etc is included in Fortran 95 so you don't need to change standard conforming code.

This sounds like a simple coding error. Can you post a short sample that illustrates the problem?

[Lloyd]

Although 77 is a subset of 95 the code I am working with is fairly messy - it was coded loose and fast by people who weren't software people by trade.

As a result I decided that it could do with a spring clean, and so updated it to be in line with the 95 standard. I removed all obsolescent features, cleaned up the goto hell, updated common blocks to modules and defined all variables explicitly.

I cannot post a sample because the code is about 6k lines long (and my boss wouldn't be happy with me posting the full code). It isn't an issue which the compiler catches meaning I can't narrow it down to provide a sample.

The code works perfectly fine in Win32 mode, so it must be something to do with the differences between that and .net.

I've put it on strict iso mode, but it is still exception-ing on initialisation.

[Lloyd]

Posted via email.

[Lloyd]

Paul,

Apologies for not getting back sooner. I have to do other things than code (unfortunately) so haven't had much time to get back into this.

Instead of converting the 6k+ program I originally sent to you, I have been trying to convert its little brother which is slightly lighter at 2.5k lines

The problem is still occuring (for both conversions), but I think I have discovered why.

I assume that when you were trying the code out, you were using an x86 computer, not x64?

I ran the build directly from a command prompt to get the call stack, heres what it looks like:



I did a little research on the BadImageFormatException

It appears that this exception is thrown when an x64 assembly is loaded by a x86 assembly causing the 32bit runtime to bork.

In other words...

The Build which I am producing is coming out as x64.

The silverfrost dlls seem to be x86

When the silverfrost x86 stuff loads the x64 assembly, it crashes.

the suggested fix is that the compiler has to output a build targetted specifically for x86 so that it loads with the 32bit clr runtime using WOW64.

Only problem is...I cannot see any compile/link switch for forcing the output as .net for x86 only.

(PS. This explains why I couldn't distill the problem down into a small sample as some code is auto compiled as x64 and some as x86 without any user intervention)

Link to suggested fix:

http://social.msdn.microsoft.com/forums/en-US/adodotnetentityframework/thread/41623cb4-107f-4bba-8167-4c78aad16e3b/

[PaulLaidler]

I have both 64 bit and 32 bit processors. I cannot remember which I used but the key initial question is not the processor but the operating system. I only use 32bit OS at the moment. Others have used 64bit OS successfully but probably not for .NET.

Are you using a 32 bit or 64 bit operating system?

FTN95, together with DBK_LINK (or DBK_LINK2) produces a 32 bit assembly so, from what you say, you need to run it with a 32 bit version of .NET.

If you are using a 64bit OS then you might need to install the 32Bit OS as well via a dual boot.

[Lloyd]

Yeah, I was running Vista x64, and now Windows 7 RC x64

[Andrew]

The issue here appears to be not the compiled assembly, but the runtime assemblies used by FTN95 programs, ftn95lib. The compiled assembly is marked as ILONLY 32BITREQUIRED in the flags within manifest, but unfortunately the runtime DLLs are not.

It is possible for you to mark ftn95lib with a tool called 'corflags' available with the .NET framework version 2 and above to be 32BITREQUIRED, but you will not be able to resign the assembly as you dont have our key. I can let you have a build to test with the flags updated, but you will have to install this using GACUTIL, another tool available with the .NET framework. If you would like this, please PM me your email address and I will send this on to you.

On a side note, using Windows 7 at this stage may well present other problems (it certainly does compiling native Win32 programs) and is unsupported until after release.

[Andrew]

A partial solution (or at least explanation) has been found for this issue. For some reason on the machine in question, the corflags value inside the compiled .NET binary is not being set to 32BITREQUIRED, which should be the default. As the OS is a 64 bit OS then the flag is required as a 32 bit binary is loaded by the runtime which fails without the flag set.

It is unknown why this is not working on this particular machine. It has been tested on another Vista 64 bit machine and works correctly.

A workaround, if anyone comes across this, is to use the Microsoft .NET tool, corflags.exe to manually set the corflags value after compilation. This should be done by:

[Lloyd]

Thank you andrew. Your help has been much appreciated.