Re: SV: [xml] windows binary with different calling

[Daniel Veillard <veillard redhat com>]

On Wed, Jun 04, 2003 at 10:34:13AM +0200, Peter Jacobi wrote:
> Daniel, Igor, everyone on this thread,
>
> >   YOU, yes you ! Why would you "be happy" about it ? You say "This might
> > seem like" a positive change for Windows, why being so shy ? Why dou *YOU*
> > need it, dammit ? 
>
> I'll try to explain why the SOME_FUNKY_STUFF_BEFORE_EACH_FUNCTION
> thing is often called for and, if I'm not mistaken, cared for in some big 
> (and not so big) cross platforms projects, ranging from Mozilla, IBM ITU
> downto libpng and zlib.
>
> I'll do this despite the fact, that I'm fine with: "for simple cases follow 
> Igor's advice, for complicated cases compile yourself, for ugly case
> massage the headers". But I hope to clarify the case. Hopefully.
>
> The issue arises when 
> - you use Win32 (or OS/2 (or maybe some other OSses))
> - you want to use pre-compiled binaries
> - you have at least two DLLs who assume different calling conventions
> without declaring them function by function in the headers OR you prefer
> for rational or irrational reasons using a default calling convention 
> different from the one used by the libxml2 DLL
>
> The issue is caused by the sad fact, that using MSVC, you can give
> a default calling convention as compiler option and an overriding one
> function by function, but not a blockstructured or wrapper one, like the
> C++ construct:
> extern "C" { }
>
> ATTN MSVC experts: or is there such a possibility buried in a dark
> corner of the documentation? Please check.
>
> The .def file approach takes only care of the linking step, but  it cannot
> inform the compiler about the calling convention used. The link between
> the calling convention problem and the .def file non-problem is only,
> that resigning to the former and using SOME_FUNKY_STUFF, will
> allow to use it also for __declspec(dll{ex|im}port) and the .def file
> would become obsolete.

  Okay, thanks a lot for going through the work of explaining this.
The remaining questions I have are not technical anymore:
  - how many people are left out if this is not provided by default
  - how bad it is to actually let people start distributing libxml2
    DLLs using the non-standard calling conventions.

 The second point is an interop problem, if I understand correctly
the goal of that change is precisely to generate shared libs (because
libxml2 is not compiled in) and have those libs use different calling
conventions. To what extend allowing this will create new compatibility
problems ?

 I think the C parser script I have in python is good enough that it
might be able to generate those change automatically with some work
(like the protoize tool coming from the gcc source distribution).
I'm not tempted to change the distribution, but maybe provide a tool
to help the 1% (maybe more, maybe less) of the users which may need
this functionality. The idea of manually editing and maintaining this
is not something I'm ready to commit for at this point, and Igor seems
quite reluctant too...

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/