[Mono-list] P/Invoke, Mono, .NET and Windows XP funny platform

[Francis Brosnan Blázquez]

First of all, thanks for your reply. It have been really productive.

Some issues about your reply:

>Your fundamental problem is that you're targeting Windows XP.
>
>Ha ha only serious.  (A colloquialism for "that's funny, but I'm serious
>too...")
>
>The slightly longer explanation is here:
>
>	http://www.mono-project.com/Interop_with_Native_Libraries#Windows_DLL_Search_Path
>
>The real explanation is that Win32 is broken when it comes to supporting
>multiple different versions of the "same" library.  Absolutely,
>fundamentally, *broken*.  More to the point, it doesn't support this AT
>ALL -- you can only have ONE version of any given library in use at any
>point in time.
>
>Win32 has three issues you're running into:
>
> 1. No built-in versioning support for libraries, as noted above.
>    Which is to say, if you load C:\Windows\System32\OLE32.dll, you 
>    can't say that you want version 1 or version 2 of that library, 
>    you get whichever version is at C:\Windows\System32\OLE32.dll.
>
> 2. This doesn't mean you can't have multiple different versions 
>    installed.  It just means that each different version needs to 
>    reside in a different directory, which leaves you the option of
>    (a) always specifying a full (or relative) directory for your
>    library, or (b) accepting the default path and placing your library
>    into an appropriate location.
>
>    So if you didn't like Microsoft's OLE32.DLL, you could place a copy
>    into your application's directory, and *that* one would get loaded.
>
>    Alas, this means you can have the scenario you're describing, where
>    both mono and your app bundle glib.  This is unfortunate, because of
>    issue (3).
>
> 3. Win32 doesn't keep track of the full path name to a library.  It 
>    only remembers the basename of the library.
>
>    Translation:  If you LoadLibrary() C:\mono\glib.dll, Win32 will know
>    that it's loaded "glib.dll".  If you then LoadLibrary() 
>    C:\yourapp\glib.dll, Win32 will hand you back a handle to 
>    C:\mono\glib.dll, because they both share the same basename 
>    (glib.dll) -- C:\yourapp\glib.dll is NOT loaded.
>
>    Win32 doesn't operate on full paths.  This is a feature (in certain 
>    contexts, anyway -- it's what allows you to provide your own version
>    of OLE32.dll, or any other system library, and have it be used).
>
>So, to answer your questions...
>
>On Thu, 2005-06-09 at 19:23 +0200, Francis Brosnan Blázquez wrote:
>  
>
>>* Any application which p/invokes libraries that are also provided by
>>mono must compile its native dll versions against the mono dll or it
>>is posible to compile these ones against, for example, a glib not
>>provided by the mono installer?
>>    
>>
>
>Is it possible?  Yes.  But to use your version of glib and not mono's
>version, you'd need to alter the library search order for mono to ensure
>it loads your version of glib and not mono's.
>
>This probably is bad, because it will effect every application started
>with mono, and your glib might not be compatible with mono's glib, which
>would (likely) kill mono instantly.
>
>So it's possible, but it's not advisable. :-)
>
>Plus, it'll use extra disk space, so it would be nicer to use mono's
>glib anyway...
>  
>
The space impact that may have including several libraries using 
different names don't
worry us. But setting a dependency against the mono libraries, such as 
libglib-2.0, force
us to run over Mono and only over it. As you pointed following, the 
library renaming
could be a solution to be able to run on top of Mono and microsoft .NET 
runtime.

>Alternatively, name your glib.dll with a different basename, e.g. af-
>arch-glib.dll, and rebuild all your libraries against this basename.
>
>  
>
About the library renaming issue.

Renaming library basename could help us to find a solution to build 
application that can run
on top of mono and .NET runtime ensuring the libraries the af-arch 
framework relies on will
allways be loaded using the dll version we have used (appending the 
"af-arch-")
on develop stage.

My question is: Could this confuse the windows dinamic library loading 
to load a library
called glib.dll and another one called af-arch-glib.dll both exporting 
the same symbols?

In other words, while running applications using .NET and doing P/Invoke 
over the
af-arch-glib.dll the LoadLibrary will find it with no problem as well the
Mono enviroment will do but, in the case of Mono, it have the glib.dll 
already loaded
exporting the same (or mostly) symbols leading to have loaded into 
memory two
version for the same entry point.

Using as follow [DllImport("af-arch-glib")] will ensure the .NET runtime 
as well as Mono to
load the af-arch-glib.dll library. But will this also guide both 
runtimes to differenciate the symbols
exported from glib.dll and those ones from af-arch-glib.dll?


>>* What happens if the mono runtime detects a P/Invoke over a library
>>A.dll which depends on B.dll and then another P/Invoke over the
>>library C.dll which depends on B'.dll knowing that B.dll and B'.dll
>>are the same library but not the same file?
>>    
>>
>
>Mono isn't in control of library loading, Win32 is.  (Mono uses GLib's
>g_module API, which in turn uses LoadLibrary().)
>
>So, what would Win32 do?  It would load A.dll (as found through the
>normal DLL search path), would look for and load B.dll (ditto), and when
>C.dll was loaded it would see that B.dll was already loaded, and not
>load a new one, so C.dll would get the *first* B.dll that was ever
>loaded.
>
>In short, don't do that. :-)
>
>(I'm not entirely sure why this works for you on Linux either, unless
>you depend on a different version of glib than mono does, in which case
>you'd bring in a different .so-name.  However, given that Linux/ELF
>doesn't require a symbol to come from a given library, and instead
>matches a symbol reference to ANY MATCHING SYMBOL within the address
>space, I fail to see how, if B.so.2 is already loaded, when C.so.1 is
>loaded and brings in B.so.3, you could ensure that C.so.1 actually uses
>the functions in B.so.3 and not B.so.2, since the dynamic linker should
>find the B.so.2 symbols first...  Madness, I say. :-)
>  
>
Well, what is happening is that we use Debian ;-). As other Linux 
distributions, the libraries dependecy
is handled by the package system avoid you lot of problems. Libraries 
dependencies are set to the
same for both mono and af-arch, but, libglib and libxml are not bundle 
as part of the mono package as
opposed to windows platform.

> - Jon
>
>  
>
Thanks Jon,

- Francis

>
>
>  
>