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

[Igor Zlatkovic <igor zlatkovic com>]

Gustaf Räntilä wrote:
> The primary platform is not windows, but unix yes. But your port is for
> windows right? :-)

Right. And? Explicitly cdecling all functions has nothing to do with the 
Windows port. It is a programmer's preference, nothing more.

> Daniel shouldn't do this, I couldn't agree more. It's non of his
> business and it would be more than ironic if he did.

Daniel won't do it, you can lay your head in fire on that. I don't think 
he will even allow anyone else to do it. And everything regarding libxml 
*is* his business. He is the only one who must dive straight into the 
pudding when things go wrong with libxml, all others can simply look away.

> I can do this if you want, but ain't that familiar with how to declare
> it on function pointers etc.. And would you patch it to the headers you
> ship with your binary release? If not, then I'll just cdecl the
> necessary functions I use not publishing it.

I don't know how much clearer I can get. You can do it, regardless what 
I want. If others think it's right, then you can have it in the 
mainstream source, regardlerss what I think of it. Libxml does not 
belong to me. The headers I ship with the binary release are precisely 
those found in the source, everything what appears there will be in the 
binary release. You can do it and if you do, then you are expected to 
maintain it for the years to come. I won't patch the headers later on, 
when it turns out you were just a stopby.

> Maybe I'm completely wrong here, about stdcall and cdecl, I just thought
> it was a task pretty obvious for you to do if you want many more users
> of libxml on windows. Believe me, I'd prefer libxml over any other
> non-open library since I gpl myself, and I've tried xerces-c but I
> didn't like it.

There are Windows programmers who don't use Visual Studio, who always 
use cdecl so the code remains portable across platforms without fancy 
macro jewelry which decorates each function declaration. There are 
Windows programmers who dislike the code which looks just like a sample 
in MSDN.

I don't earn money with libxml and honestly, I don't care how many use 
it. A few who I met on this mailing list, without mentioning names, are 
exactly the right gang. When I need something, I know their answer will 
be constructive and free from MSDN prestige bias. For all I care, they 
can remain the only folk who uses libxml on Windows.

> I just wanna spread libxml to a wider audience (read: I personally wanna
> use libxml in an stdcall application), so be indulgent with my rude
> irony :-)

Oh, you are welcome to give your opinion, any time :-)

As for libxml, it will remain cdecl and its functions won't carry a 
cdecl declaration. Here are the reasons:

  1. The large majority of programmers who develop libxml don't agree 
with it. The large majority does not have to care if libxml runs on 
Windows at all. This people have made libxml and maintain it day for 
day. Noone has the right to enforce something they dislike, and that 
without giving so much as an acceptable explanation.

  2. Cdecl is the compiler default. It is the default on MS and GNU 
compiler. I wager it is the default on Borland and Watcom as well. When 
you compile something and specify nothing, cdecl will be used. The fact 
that VS.NET IDE per default passes a /Gz parameter (which sets the 
default to stdcall) is of no importance. When you use stdcall, or let 
your IDE use it, you are out of default and you should declare your 
functions as stdcall. You cannot make it easy for yourself and simply 
set the compiler switch, then come and claim that our 1200 functions be 
redeclared.

Ciao,
Igor