Welcome to our forums
Hi,
does the new 64-bit compiler produces .NET assemblies as well or is it limited to standard executables? Or in other words: can I produce a 64-bit .NET 4.0 assembly with FTN95?
Regards, Goran
FTN95 has not been adapted to produce 64 bit .NET assemblies. The work on porting to standard 64 bit Windows is still ongoing and there are other pressing issues that probably need to be addressed after that.
Any update on 64-bit .NET assemblies?
There are currently no plans to extend FTN95 in order to provide for 64 bit .NET assemblies.
What exactly is not supported? We managed to get our .Net dll work in 64-bit by removing the '32-bit Machine' file flag after the compilation. The results of the calculation performed with the 64-bit version are the same as with 32-bit. I only found out the the TRY-CATCH block causes crashes in 64-bit.
Did you do file I/O?
Quoted from gperiskic What exactly is not supported? We managed to get our .Net dll work in 64-bit hahaha...hacks!
We also for two decades were running parallel simulations using FTN77 /95 with LIB libraries created in other companies Fortran compilers despite the LIB formally were not supported....also hacks! Something was worked something not but that was enough. Only recently 100% compatible solution was found by using DLL, thanks to mecej4 for the implementation.
gperiskic
I am surprised that you have .NET FTN95 working for 64 bits.
One limitation of 32 bit .NET FTN95 is that applications normally call into salflibc.dll and this won't work for 64 bits. So your application must be unusual in this respect at least.
After that, your experience implies that the assembly code produced by FTN95 and DBK_LINKx works equally well for 64 bits. This, in one sense, is as it ought to be but never-the-less is quite remarkable.
Well, we didn't really hack anything, just removed the flag as mentioned above. We use classes from C# to define the input/output interface and pass them directly to the fortran assembly, without any i/o disk operations. The fortran assembly is performing various mathematical analysis, without any graphical work. So it makes me wonder that you claim that 64-bit is not supported in NET at all. Exactly the same is valid for my question regarding .NET Core support - even here we managed to get it work, just had to compile without salflibc...
@Paul: we compile with /NO_SALFLIBC switch and subsequently remove the 32-bit flag - this works both for 64-bit and NET Core.
gperiskic
That is encouraging. Can you provide details of how to remove the 32 bit flag.
Sure... Either use 'dnSpy' (go to FileHeader and unklick '32-Bit Machine') or use Microsoft CorFlags.exe (call 'corflags myAssembly.dll /32BIT-' from command prompt).
dbk_link explicitly puts that flag on to force the assembly to 32-bit. If it didn't then .NET could load it in 64-bit mode and any calls to salflibc would break the system. As I recall one of reasons we chose not to go down the 64-bit .Net route was that it didn't support arrays larger than 32-bits.
Robert - you mean that if a single array needs more then 4 GB memory then it doesn't work.?
Yes. The limit used to be 2GB for arrays. This looks like it has changed at .NET 4.5 but there is still a 31-bit limit on array indexes.
Ok, thanks Robert, this is good to know. We don't have such large arrays, but I'll keep this in mind. Anything else? As mentioned before, a try-catch block (for exceptions catching) works fine with 32-bit but crashes with 64-bit.
I have done a little research into this issue and I find that there is an undocumented DBK_LINK command line option /cross.
In part, this has the effect of switching off the 'Required32Bit' part of the 'corflags'.
If this option has no adverse effects then it would provide an alternative to resetting this flag manually.
That was added at 8.60 with that intention. I think it also prevents the linking of salflibc.dll.
Ok, thanks. I'll try it out.