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