forums.silverfrost.com

[Anonymous]

Hi all
I am attempting to port an existing suite of programs into the .NET environment. The existing code compiles under FTN95 using WIN32 however as part of the compilation a propriatary WIN32 .lib file is used. I happen to know that this was compiled using the Salford compiler. I don't have access to the code for this library.

Anyway when I attempt to build the program in .NET I get an error from DBK_LNK Internal linker error. I presume this is because I am trying to interface win32 with .NET with out jumping through the right hoops. The libraray has its own common block any reference to any object in that common block seems to make the linker to fall over. eg if there is an integer in COMMON called lp say lp = 3
would make the linker fall over.

all the subroutines in the libary are also not recognised ie I get routiene not found errors

is I alter the code so that no common block data is manipulated.

is there a way round this

maybe make a win32 dll and link to that perhaps?



DrTip

[PaulLaidler]

Carl

Your DLL needs to be a .NET assembly. If it is standard Fortran, you can rebuild it using FTN95 in .NET mode. You can then supply the DLL as a reference to your .NET executable.

[Anonymous]

Thanks for the prompt reply Paul.

My problem is that I don't have accces to the original DLL code just the WIN32 binary files, and a common block include file, otherwise I would have done as you say,

I tried recompiling subroutines that call use this DLL in .NET but I get the linker error I mentioned above.

I think I have worked a way round this by creating c++.net in clr class that uses the interop namespace but obviously I would rather stick to just ftn95.net if I can with a shiny new C# front end. though I need to do some testing of this to see if it works, I guess I could post an example later if I have some success with this method, since I presume it must be a common type of issue.

The ultimate goal is to port antique binary data formats into something little more modern and accessible maybe SQL server. The third party DLL currently extracts ands writes to these antique formats, (It is a very bespoke format I don't really want to have to reverse engineer it if I can help it!).

Microsft c++ Express help suggests c++ is unique amongst .NET languages in allowing mixed assemblies, essentially embedding binaries in .net assemblies. If this is the case then I guess I am on the right track.