RE: [xml] Win32/MSVC Facelift

["Igor Zlatkovic" <izlatkovic daenet de>]

Hi Mark, all

> I strongly agree that xmlwin32version.h should be removed.
> [...] Seems redundant.

Not anymore. It sounded redundant yesterday, but today I have read the
post from Yon Derek :-)

> [...] Why not 
> remove trio.c
> entirely from the project (.dsp) as this will never be used 
> on win32 and
> only causes confusion by having it and #define's listed for it.

I did remove it from the project file. Still, I don't know if it is
going to be used or not. Perhaps there are people who like it better
than what MS C-Runtime provides. When I have figured how to
conditionally include a file in the project (perhaps a @command-file
tweak for the linker) trio comes back. It is a nice piece of software
and I would like to keep it around, at least in order to regularily
check if it still compiles under Win32 :-)

> > You can use any combination of debug/release when
> > building the utilities, it does not matter due to the new 
> build process.
>
> Really?  I've always seem to encounter profiling/debug features in the
> utilites that would only build when some of hte debug features were
> #define'ed in that wouldn't typically be included in a release build.

Really. You can debug and profile what you see fit, just always use the
same C-Runtime, without debug or profile info. Conflicts arise from
using different C-Runtimes for debug or profile build.

I don't wish to debug MS C-runtime, neither I wish to profile it because
the results make me reboot to Solaris and remain there for about a week.
That is bad for my company's business.

> I think we need to throw in some #pragma pack(push,8) and 
> #pragma pack(pop)
> when including the libxml2 and libxslt headers.  It is unsafe 
> to assume that
> everyone uses 8 byte struct alignment.  

No, no #pragmas. Even if every compiler should silently ignore all
#pragmas it doesn't understand, many don't. MS compiler is a typical
example of these. You can change the default alignment in the project
settings in the MSVC IDE. Those who do it and know what they did are not
exactly novices; they would know what went wrong without drowning the
world's mailing lists in help-me tears. Besides, there is no reason why
libxml should fail with different alignment.

> void CALLTYPE function(arg)
>
> where on win32 CALLTYPE is defined as __cdecl.  Obviously 
> this is to be
> avoided, as it causes too much confusion/annoyance to un*x 
> programmers.  

That would confuse Win32 novices rather than programmers who work use
UNIX :-))
No, this is not a solution, and that because __cdecl is the only calling
convention we can use. __stdcall produces smaller executables because
the stack cleanup code is generated once for each function instead of
once for each call, but exactly that carries an important limitation: a
__stdcall function cannot have variable argument list. Use __cdecl.
Those few nanobytes of extra stack mrproperring are really not a big
deal.

> Do
> you know of a way to set a default call type within a given 
> header without
> having to change it for a project?  Consider using libxml2 as 
> a dynamic
> library from a program with a default call type of stdcall 
> (/Gz compile
> flag).

You can change compilation switches for each file in the project
separately. In MSVC IDE, Project->Settings, select the file in that neat
tree which you see on the left side of the dialog, change the compiler
switches on the right side, press OK and enjoy :-))

Other than that, you cannot tell your program to use __stdcall for
libxml functions if libxml is compiled with __cdecl, if that's what you
are up to. That would certainly make you an appointment with Dr. Watson.

Ciao
Igor