"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.
On December 4, 2003 04:36 pm, Alexandre Julliard wrote:
> 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.
Maybe we should come up with a bit more ob
"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
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
"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
--- 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 i
> -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 Shearma
"Robert Shearman" <[EMAIL PROTECTED]> writes:
> 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
> It may add a little
"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 us
> -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 por
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 R
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]> 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
> Ahhh forget the HeapAlloc stuff. That was my fault. Someone decided in
> a very drain-bamaged way to forward all the Heap* calls to the RtlHeap
> calls in the spec file rather than in the source so anytime we try to
> port Winehq sources for kernel32 that use HeapAlloc I was running in to
> probl
--- "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 depe
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> Agreed, I see no need to make our DLLs depend on ntdll. And I don't
> understand why you guys need to change the source for such a trivial
> (and useless) 'optimization'. Even within kernel32 I'd still use
> the Heap*() functions for consistency,
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. And I don't
understand why you guys need to change
Steven Edwards <[EMAIL PROTECTED]> writes:
> Also I was looking at the HeapAlloc stuff in WINE and code we have
> ported from ReactOS such as the FormatMessage function in kernel32.
> Doesnt kernel32 HeapAlloc and friends map on top of ntdll RtlHelpAlloc?
> Can we submit patches to WINE so that ev
Steven Edwards wrote:
Hello,
We are looking at porting more code from WINE to ReactOS and I am
having trouble understanding the need for libwine_unicode as a shared
library. Some of the functions that it exports such as CompareString
are implemented in ntdll as RtlCompareString and then also used i
Hello,
We are looking at porting more code from WINE to ReactOS and I am
having trouble understanding the need for libwine_unicode as a shared
library. Some of the functions that it exports such as CompareString
are implemented in ntdll as RtlCompareString and then also used in
shlwapi as per a rec
20 matches
Mail list logo
