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

[Igor Zlatkovic <igor zlatkovic com>]

> Well, first of all you could add this to Your release, and when Daniel
> releases a new version that you build, you simply diff the versions
> .h-files and only CDECL the new lines. This way conservative *nix-users
> that have problems with too much characters in their .h-files (read me
> the right way here :-), wouldn't be affected. I know that they need
> libraries to look in a particular way, or else their view of the world
> is destroyed and they become mentally ill. (Woo, posting this on
> gnome.org, I don't wanna know how many fellas that'll rape my email now
> :-)

Unix users are not conservative. They don't have too much characters in 
their files. They have exactly as much as they need. None of them will 
suffer a mental illness upon extra macros in this code. They just 
rightfuly won't give up their freedom and their ease of work for your whim.

I don't feel like doing some extra work just because you think I should. 
Either pay me to do it, or do it yourself. Patch a header file, post it 
to this mailing list and ask the folk what they think about it.

> Secondly I don't think a little DLLIMPORT or CDECL or similar macro is
> very bloating to the header files, and I really don't understand how
> beauty of code could ever be more important to its use, but ok =)
> How important is it anyway, I mean who actually frames the header files
> and put it on a wall, or use it as proposal speech? I mean come on, read
> the dox instead :-)

Things have nothing to do with the beauty of the header files. The 
header files are very usable and beautiful the way they are. Noone 
frames them and puts them onto the wall, everyone is using them, and 
that successfully. You must understand, those macros, which represent no 
bloat in your eyes, are the very bloat for others. Most of the libxml 
users haven't seen Windows once in 15 years, if ever.

> Thirdly, Win32 (and you specifically release win32-binaries) is almost
> only built with stdcall. It's the default calling convention, and some
> apps might wanna use stdcall as default if they rely on several other
> libraries that uses it. I really don't see the very punch-line reason
> not to explicitly express in the headers, so that windows developers can
> use libxml2 without concerning about this. Specifically since this isn't
> forbidden by the compiler, but the opposite, it's accepted.

Who says that Windows binaries are being built with stdcall? I am 
programming on Windows for longer than I can remember, have made it all, 
from the kernel-mode device drivers, up to the web-applications. I never 
found a reason to prefer stdcall over cdecl.

Don't forget that you are facing an Unix library which has been ported 
to Windows. Windows is not the primary platform for this. Windows is 
either compatible, or it uses an alternative, many of which are 
available, even if not so good.

> I admire all of you working on this (Igor and Daniel, and whoever else
> contributing), it's just that the best isn't good enough, it can always
> be better :-)

Define "better". My vision of "better" differs to yours and if we get 
the chance to hear more, we'll see quite a few definitions for that.

Oh, don't let those words of mine disturb you. The very fact I am typing 
so much in response says that we all have an ear. I am listening and 
giving my arguments. You manage to convince me about it being the right 
way, and I'll volunteer to cdecl all 1200 functions in libxml. :-) You 
manage to convince the majority of the users about cdecling and cdecling 
it will be, regardless what I think. ;-)

Ciao,
Igor