> > 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
> > I thought it would be enough just to use "--ptr" to go back one
> > character in UCS-16 strings. Only MBCS or UTF-8 encoded strings would
> > need such helper functions like CharPrevW()?
>
> IIRC there are these 'surrogate pairs' in which case just --ptr
> will not work correctly:
> http://msd
> 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_SR
On Sun, 2005-07-03 at 13:31 +0200, Martin Fuchs wrote:
> I thought it would be enough just to use "--ptr" to go back one
> character in UCS-16 strings. Only MBCS or UTF-8 encoded strings would
> need such helper functions like CharPrevW()?
IIRC there are these 'surrogate pairs' in which case just
> > > CharUpperW() is towupper().
> >
> > Well, CharUpper() works with strings instead of characters. So that's
> > what I changed in the pattern matching function.
>
> No, it also works on characters. Check MSDN. ;)
# [in/out] Pointer to a null-terminated string or specifies a single character.
On Sun, Jul 03, 2005 at 01:31:06PM +0200, Martin Fuchs wrote:
> > > I can't find a replacement for wcsrchr() in the windows API, so I have to
> > > include my own implementation in the source. There is also no equivalent
> > > of towupper(), so I have to change the pattern matching function a bit
> > I can't find a replacement for wcsrchr() in the windows API, so I have to
> > include my own implementation in the source. There is also no equivalent of
> > towupper(), so I have to change the pattern matching function a bit.
>
> wcsrchr() is problematic, but can probalby be done with CharP
> > So I see two solutions:
> > (1) make a hard break and change the whole winefile to Unicode. For
> > unixcalls.c you can rely on the Windows API for manipulating Unicode
>
> I can't find a replacement for wcsrchr() in the windows API, so I have to
> include my own implementation in the source.
Hello Ralf,
> I assume you only need include/msvcrt for unixcalls.c to be able to
> include tchar.h. I assume the reason why tchar.h only works with msvcrt
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,
Hi Martin,
> currently it's impossible to compile winefile in UNICODE mode
> with Wine without some extra rule for unixcalls.c in the
> Makefile. I tried it even without using any TCHAR functions
> or types, but inserting include/msvcrt in the include path
> conflicts with inclusion of the hea
Dmitry,
> > switch winefile to UNICODE mode
>
> Why to go through all this pain and not just make it unicode
> only?
currently it's impossible to compile winefile in UNICODE mode with
Wine without some extra rule for unixcalls.c in the Makefile. I tried
it even without using any TCHAR functions
> > Changelog:
> > switch winefile to UNICODE mode
> Why to go through all this pain and not just make it unicode
> only?
First of all: Winefile was designed to be usable both in ANSI and UNICODE
mode from the begin on, and I won't remove this functionality. So you can
build and use it also on 8
"Martin Fuchs" <[EMAIL PROTECTED]> wrote:
> Changelog:
> switch winefile to UNICODE mode
Why to go through all this pain and not just make it unicode
only?
--
Dmitry.
13 matches
Mail list logo
