Has anyone tried linking our DLLs and MS Visual Studio code?

[Richard W.M. Jones]

The question was raised today as to whether it really works.

We expect that C will work.  We (Red Hat) haven't actually tried the
combination of our DLLs and MS VC-compiled C code.

We expect / are almost certain that C++ won't work.  C++ code may link
and fail in creative ways, such as exceptions disappearing, or maybe
it just won't link at all.

Rich.

[Erik van Pienbroek]

Op donderdag 11-12-2008 om 17:45 uur [tijdzone +0000], schreef Richard
W.M. Jones:
> The question was raised today as to whether it really works.
>
> We expect that C will work.  We (Red Hat) haven't actually tried the
> combination of our DLLs and MS VC-compiled C code.
>
> We expect / are almost certain that C++ won't work.  C++ code may link
> and fail in creative ways, such as exceptions disappearing, or maybe
> it just won't link at all.
>
> Rich.

Hi,

I haven't tried cross-compiling anything with the MinGW GCC of Fedora
yet, but I do have tried to call MinGW compiled DLL's (build on a Vista
host) from Visual Studio 2005 and 2008 applications (both plain C code).

Mixing MinGW produced DLL's with Visual Studio applications works, but
there are some caveats to it. The most annoying thing is that file
pointers aren't exchangeable between MinGW and Visual Studio. Normally
this isn't a problem, but for example with GLib, there's a function to
open a file (g_open, which returns a file pointer), but there are no
functions to read/write data to it making it practically useless in a
mixed environment. A few months ago this was also discussed on the
gtk-devel mailing list [1] but unfortunately nothing happened since
then.

Regards,

Erik van Pienbroek

[1]: http://www.mail-archive.com/[e-mail]/msg08138.html

[Daniel P. Berrange]

On Thu, Dec 11, 2008 at 07:22:13PM +0100, Erik van Pienbroek wrote:
> Op donderdag 11-12-2008 om 17:45 uur [tijdzone +0000], schreef Richard
> W.M. Jones:
> > The question was raised today as to whether it really works.
> >
> > We expect that C will work.  We (Red Hat) haven't actually tried the
> > combination of our DLLs and MS VC-compiled C code.
> >
> > We expect / are almost certain that C++ won't work.  C++ code may link
> > and fail in creative ways, such as exceptions disappearing, or maybe
> > it just won't link at all.
> >
> > Rich.
>
> Hi,
>
> I haven't tried cross-compiling anything with the MinGW GCC of Fedora
> yet, but I do have tried to call MinGW compiled DLL's (build on a Vista
> host) from Visual Studio 2005 and 2008 applications (both plain C code).
>
> Mixing MinGW produced DLL's with Visual Studio applications works, but
> there are some caveats to it. The most annoying thing is that file
> pointers aren't exchangeable between MinGW and Visual Studio. Normally
> this isn't a problem, but for example with GLib, there's a function to
> open a file (g_open, which returns a file pointer), but there are no
> functions to read/write data to it making it practically useless in a
> mixed environment.

Isn't this taken care of with Microsoft's OSF conversion routines

http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx
 http://msdn.microsoft.com/en-us/library/ks2530z6.aspx

Specifically _open_osfhandle() and _get_osfhandle() which allow you to
convert between a UNIX style 'int fd' and a Win32 HANDLE in both
directions. This is what GNULIB uses to make WinSock comply with proper
POSIX api contracts.

Daniel

[Richard W.M. Jones]

On Thu, Dec 11, 2008 at 07:22:13PM +0100, Erik van Pienbroek wrote:
> Mixing MinGW produced DLL's with Visual Studio applications works, but
> there are some caveats to it. The most annoying thing is that file
> pointers aren't exchangeable between MinGW and Visual Studio. Normally
> this isn't a problem, but for example with GLib, there's a function to
> open a file (g_open, which returns a file pointer), but there are no
> functions to read/write data to it making it practically useless in a
> mixed environment. A few months ago this was also discussed on the
> gtk-devel mailing list [1] but unfortunately nothing happened since
> then.

[...]
>

Thanks - that was a really useful link and explains a bit about the
problems I was having in some unrelated code a few weeks ago.

Rich.