> > No, I don't need tchar.h in 'unixcalls.c'. I only needed it
> > for 'winefile.c'. The problem is, if I add 'include/msvcrt'
> > to the include path, it is added to both files at the same time.
>
> I see. What about adding a separate rule to Makefile.in just for
> unixcalls.c and omit that file from C_SRC? That way you can control
> again which parameters will be passed to gcc. As unixcalls.c is not a
> "traditional" windows source file, but a bridge to the Unix system, I
> think that approach should be OK.
Handling unixcalls.o separate in the makefile has been the approach in
my last patch version. Alexandre was not very fond of it. ;-(
> > But the biggest problem I forgot about before is wsprintf(). Wine's
> > wsprintf() implementation only handles 64 bit integer formats ("%Ld",
> > "%Lx") when using msvcrt. So I will have to use LoadLibrary() and
> > GetProcAddress() to call vswprintf() for this string formats.
>
> According to MSDN, wsprintf() does not handle INT64 et all. So Wine is
> correct when it does not either.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/w
> inui/windowsuserinterface/resources/strings/stringreference/stringfuncti
> ons/wsprintf.asp
May be it is not documented in MSDN. But using the format string
'%I64d" on Windows works pretty well with all of the following
functions:
sprintf(), swprintf(), wsprintfA(), wsprintfW()
With Winelib it seems, I have to use instead "%Ld" with sprintf()
resp. swprintf() in MSVCRT.DLL.
> So dynamically linking to msvcrt seems to be the only possible solution.
Yes - not very nice, but at least it works.
Regards,
Martin
