views:

189

answers:

3

Like a lot of places my workplace has legacy code floating around along with more modern applications. For example we have a server application that still uses the Microsoft Fortran77 compiler. The less old parts of the application are written for the Visual Studio 6 C compiler and lately there have been runours of writing some new libraries with VS .Net 2008 C++. The programs/libraries have a number of different mechanisms to consume/communicate each other including static linking, shared memory (Windows memory mapped files), name pipes and TCP sockets.

What's to stop a C# application from being able to use any old library such as one of the Fortran77 ones written in a procedural langauge?

If my C# application understood the file format of a Fortan77 or C library and was able to locate the procedure call it wanted could it marshal the managed objects across, call the procedure and unmarshal the result?

If I copied a .so library file from Linux to Windows and my C# application understood the file format could it call functions from that library?

I think the answers are to do with the various Fortran, C etc. runtimes that are needed to initialise each library/program. If that's so then at a fundamental level are those runtimes the broadly similar to the CLR (realising they have different features such as memory management etc. etc. in the CLR's case)?

Edit:

To put my question another way. If an alien dropped in and gave me a binary library file and a file format specification could I use it from C#?

+1  A: 

I don't know about Fortan77 or .so library from Linux, but I do know that you can use PInvoike with C libraries for method calls. Also you may want to look at the unsafe keyword in C# for the shared memory applications. It allows you to drop out of memory management, which may be what you need. Named Pipes and TCP sockets can be done from the System.Net namespace.

Basically everything you have said can be done. I don't know how hard or easy it will be to accomplish, but you should be able to access all these native apps from your C# application.

Nick Berardi
+2  A: 

If the DLLs are valid DLLs and the functions exported use well-known calling conventions, then there should be no problem as long as you get the method signature in .NET right i.e: correct argument types and return type. CLR doesn't (and can't) care what language was the library written in.

As for the Linux shared libraries, if you have the sources of the libraries, it should be possible to compile them for windows using either Cygwin or MiniGW.

arul
+1  A: 

You can also create a C++/CLI DLL (/CLR option when compiling) which will allow you to write both in managed and unmanaged code. This allows you to do just about anything you could do in native C++, and also interact with .NET components. I am doing something like this to bridge an old C application with a C# DLL by having the C++/CLI dll essentially sitting between them.

AaronLS