+1  A: 

The standard MS C compiler supports most of the POSIX interfaces including pthreads. Sometimes as separate implementations but usually as macros which convert the POSIX syntax to windows library calls.

If your C code doesn't have too many "gnuisms" you should be able to compile it using the standard Visual C compiler.

James Anderson
The POSIX subsystem is not really maintained anymore and there are some differences which may make porting a POSIX heavy code challenging.
shoosh
+1  A: 

You should be able to reference the DLL that was built against Cygwin without having to create a new DLL. The only requirement is that you need to make sure that both "cygwin.dll" and the DLL that you are trying to load are in the appropriate paths. You probably need to use SetDllDirectory prior to invoking "LoadLibrary".

Michael Aaron Safyan
+2  A: 

You should first try to get your simple hello world sample running. There is not much sense in trying with a huge legacy C/C++ codebase written for POSIX depending on Cygwin if you don't even get the former right. And please note that if you are linking Cygwin in you have to GPL-license your library.

For that have a look at the documentation (e.g. you need to specify explicitly in your hello world example if you are using Cdecl (what you currently don't do)): Consuming Unmanaged DLL Functions

On the native side you have to initialize Cygwin (see winsup/cygwin/how-cygtls-works.txt)

Use P/Invoke to your library directly. There is no sense in PInvoking into Win32 libraries like LoadLibrary to then invoke your libraries. This just adds another layer for errors and is gaining you exactly nothing.

Make sure you are getting the architecture right (.Net applications run 64bit by default on 64bit machines). So make sure your dlls match/support that or limit the .Net to 32bits.

If that works try getting your other library to work. (And you will have to have some luck if you expect to use functions that mix two entirely different threading models)

Foxfire
Thanks, that's what I'm trying to do. If I can get this really basic example working, the hard part is over. I only tried the loadlibrary method after directly p/invoking failed, hoping it would give me a more descriptive error.
Dale Halliwell
Then the next two steps are likely adding the cygwin initialization to your hello world c library and then adding the missing data to the DllImport Attribute in the hello world c# code.
Foxfire
+1  A: 

The code as written won't work, the exported function name is decorated by the C++ compiler and no longer resembles "hello". You'd normally declare the function extern "C" to suppress the decoration.

But, you haven't gotten that far yet. The LoadLibrary() call is failing with Windows error 998, ERROR_NOACCESS, "Invalid access to memory location". This most typically happens when the DllMain() entrypoint in one of the DLLs you have a dependency on bombs with an AccessViolation hardware exception. This should be visible in the debugger (Output window in Visual Studio), you should see a "First chance exception" with exception code 0xc0000005.

This is probably going to be unpleasant to diagnose, you've got several DLLs that are candidates and whose debugging symbols probably are a poor match for the debugger you use. Try to isolate this by writing a small test program in C that calls LoadLibrary. Configure the debugger to stop on the first chance exception. In Visual Studio you'd do this with Debug + Exceptions, Thrown checkbox. Good luck with it!

Hans Passant
+5  A: 

The main problem which you has is following. Before you can use your helloworld.dll a cygwin environment must be initialized (see http://cygwin.com/faq/faq.programming.html#faq.programming.msvs-mingw). So the following code in native C++ will works:

#include <windows.h>

typedef int (*PFN_HELLO)();
typedef void (*PFN_CYGWIN_DLL_INIT)();

int main()
{
    PFN_HELLO fnHello;
    HMODULE hLib, h = LoadLibrary(TEXT("cygwin1.dll")); 
    PFN_CYGWIN_DLL_INIT init = (PFN_CYGWIN_DLL_INIT) GetProcAddress(h,"cygwin_dll_init");
    init(); 

    hLib = LoadLibrary (TEXT("C:\\cygwin\\home\\Oleg\\mydll.dll"));
    fnHello = (PFN_HELLO) GetProcAddress (hLib, "hello");
    return fnHello();
}

Of cause the path to cygwin1.dll must be found. You can set C:\cygwin\bin as a current directory, use SetDllDirectory function or easy include C:\cygwin\bin in the global PATH environment variable (click on right mouse button on Computer, choose Properties then "Advanced System Settings", "Environment variables...", then choose system variable PATH and append it with ";C:\cygwin\bin").

Next if you compile you DLL, you should better to use DEF-file to define BASE address of DLL during compiling and makes all function names, which you exported more clear readable (see http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html)

You can verify results with dumpbin.exe mydll.dll /exports, if you have Visual Studio installed. (don't forget start command promt from "Visual Studio Command Prompt (2010)" to have all Visual Studio set).

UPDATED: Because you don't write about the success I think there are exist some problems. In Win32/Win64 world (unmanaged world) it works. The code which I posted I have tested. Loading of CygWin DLLs in .NET can have some problem. In http://cygwin.com/faq/faq.programming.html#faq.programming.msvs-mingw one can read "Make sure you have 4K of scratch space at the bottom of your stack". This requirement can be wrong in .NET. A stack is a part of thread and not a process. So you can try to use CygWin DLLs in the new .NET Thread. Since .NET 2.0 one can define the maximum stack size for the thread. One other way is trying to understand http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygtls-works.txt?rev=1.1&amp;content-type=text/plain&amp;cvsroot=src and the code described in http://old.nabble.com/Cygwin-dll-from-C--Application-td18616035.html#a18616996. But the really interesting I find two ways without any tricks:

  1. Compiling the DLL with respect of MinGW tools instead of CygWin tools. MinGW produce code which are much more Windows compatible. I am not using CygWin or MinGW myself, so I am not sure, that you will be able to compile all you existing code used POSIX function in MinGW. If it is do possible, this way can have more success. You can look at http://www.adp-gmbh.ch/csharp/call_dll.html for example, to see, that MinGW DLL can be called from C# exactly like a Windows DLL.
  2. Usage of CygWin DLL inside of unmanaged process or unmanaged thread. This is a standard way described in CygWin documentation and it works (see example from my first post).

P.S. Please write short in the text of your question if you have success in one of this or in another way which you choose at the end. It's interesting for me independent on reputation and bounty.

Oleg
Hi Oleg, thanks for your help. Actually I haven't had time to try any other ways yet, but I will update this thread with my results. See my edited answer for the output of dumpbin.exe, the base address seems to be ok, and the function name is there too. Thanks for your suggestions I will try them in the next few days.
Dale Halliwell