Dimitrie O. Paun [EMAIL PROTECTED] writes:
Maybe we should come up with a bit more obvious names that
are (1) easier to see are temporary and (2) easier to grep.
Maybe a wl_/wstr_/wine_ prefix of sorts?
But then you'd need to rename all the existing uses of wine/unicode.h
functions too. I
On December 2, 2003 02:25 pm, Alexandre Julliard wrote:
Yes, this is something I've been wanting to do for a long time. Not so
much because of libwine_unicode, but because a lot of places use the
lstr* functions for no reason, and this slows things down quite a
bit. The problem is that some
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Should I add this as a janitorial task?
I guess so, though I'm not sure how we should proceed. Maybe the first
step would be to get rid of the lstr* calls, and then to add them back
in a second step once every place has been checked.
--
Alexandre
-Original Message-
From: Alexandre Julliard [mailto:[EMAIL PROTECTED]
Sent: 02 December 2003 19:26
To: Robert Shearman
Cc: Steven Edwards; [EMAIL PROTECTED]
Subject: Re: Question about libwine_unicode functions and others in WINE
Robert Shearman [EMAIL PROTECTED] writes:
However
--- Robert Shearman [EMAIL PROTECTED] wrote:
Just another thought: why don't we use the wcscat, wcslen, wcscpy
functions
from ntdll? AFAIK, they are completely compatible with the msvcrt
ones with
the same names. The lstr* calls that don't need exception handling
can link
to these instead.
Robert Shearman [EMAIL PROTECTED] writes:
Just another thought: why don't we use the wcscat, wcslen, wcscpy functions
from ntdll? AFAIK, they are completely compatible with the msvcrt ones with
the same names. The lstr* calls that don't need exception handling can link
to these instead. On
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Steven Edwards
Sent: 01 December 2003 00:03
To: [EMAIL PROTECTED]
Subject: Question about libwine_unicode functions and others in WINE
Hello,
We are looking at porting more code from WINE to ReactOS and
Robert Shearman [EMAIL PROTECTED] wrote:
However, couldn't we just replace the libwine_unicode function with an
appropriate (well-documented) kernel32 string function:
strcatW - lstrcatW
strcmpW - lstrcmpW
strcpyW - lstrcpyW
strlenW - lstrlenW
...
etc
No. The above APIs use SEH
--- Dimitrie O. Paun [EMAIL PROTECTED] wrote:
On December 1, 2003 02:44 pm, Eric Pouech wrote:
That would be doable yes (at least in kernel32). In other DLLs,
it's
more arguable, especially if we want to test them on non NT
systems.
Agreed, I see no need to make our DLLs depend on ntdll.
--- Jonathan Wilson [EMAIL PROTECTED] wrote:
No, thats not brain damaged.
Thats the way Microsoft does things. (at least on XP)
HeapAlloc doesnt exist at all, all it is is a forwarder to NTDLL.
Therefore, all the code in kernel32 should just call RtlAllocateHeap.
Given that kernel32.dll is
ReactOS uses linker magic.
My point is that there is no valid reason for the WINE code in kernel32 not
to use RtlAllocateHeap since the WINE kernel32 code is only intended to run
on ReactOS (where RtlAllocateHeap is available) and WINE (where
RtlAllocateHeap is available). Therefore, re-writing
Jonathan Wilson [EMAIL PROTECTED] writes:
ReactOS uses linker magic.
My point is that there is no valid reason for the WINE code in
kernel32 not to use RtlAllocateHeap since the WINE kernel32 code is
only intended to run on ReactOS (where RtlAllocateHeap is available)
and WINE (where
12 matches
Mail list logo
