Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2651
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2649
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2650
Your paranoid andr
Hi,
On 10/06/13 00:45, morphiend wrote:
+ * _chsize_s (MSVCRT.@)
+ */
+int CDECL MSVCRT__chsize_s(int fd, __int64 size)
+{
+LARGE_INTEGER cur, pos;
+LARGE_INTEGER temp = { 0 };
This causes compilation warnings. There's also a trailing space in this
line.
+TRACE
On 6 October 2013 20:32, Frédéric Delanoy wrote:
> On Sun, Oct 6, 2013 at 12:45 AM, morphiend wrote:
>> This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s.
>> This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without
>> the implementation of _chsize_s(), ce
On Sun, Oct 6, 2013 at 12:45 AM, morphiend wrote:
> This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s.
> This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without
> the implementation of _chsize_s(), certain binaries caused an internal crash
> of IDA. This
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2349
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2346
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2217
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26809
Your paranoid android
Please ignore this patch, I'll send a better version.
Piotr Caban writes:
> ---
> dlls/msvcrt/file.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
It doesn't work:
../../../tools/runtest -q -P wine -M msvcrt.dll -T ../../.. -p
msvcrt_test.exe.so file.c && touch file.ok
file.c:2042: Test f
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26722
Your paranoid android
Kai Tietz writes:
> 2013/8/16 Alexandre Julliard :
>> Kai Tietz writes:
>>
>>> diff --git a/dlls/msvcrt/dir.c b/dlls/msvcrt/dir.c
>>> index 44802b3..3b9e3c7 100644
>>> --- a/dlls/msvcrt/dir.c
>>> +++ b/dlls/msvcrt/dir.c
>>>
2013/8/16 Alexandre Julliard :
> Kai Tietz writes:
>
>> diff --git a/dlls/msvcrt/dir.c b/dlls/msvcrt/dir.c
>> index 44802b3..3b9e3c7 100644
>> --- a/dlls/msvcrt/dir.c
>> +++ b/dlls/msvcrt/dir.c
>> @@ -365,14 +365,25 @@ int CDECL MSVCRT__chdrive(int newdri
Kai Tietz writes:
> diff --git a/dlls/msvcrt/dir.c b/dlls/msvcrt/dir.c
> index 44802b3..3b9e3c7 100644
> --- a/dlls/msvcrt/dir.c
> +++ b/dlls/msvcrt/dir.c
> @@ -365,14 +365,25 @@ int CDECL MSVCRT__chdrive(int newdrive)
> {
>WCHAR buffer[] = {'A', &#x
On 14/08/13 20:08, morphiend wrote:
-@ stub _chsize_s
+@ cdecl _chsize_s(long int64) msvcrt._chsize
+#@ stub _chsize_s
Oops..
Thank you for your feedback. I'll adjust the tests with your comments and
I'll try to use testbot.
2013/8/8 Dan Kegel
> Minor problem:
>
> +static void test_strncpy(void)
> +{
> +size_t len = 10;
> +char *ret;
> +char dst[len + 1];
>
> Hmm. That last line is a VLA, and might not co
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26639
Your paranoid android
Minor problem:
+static void test_strncpy(void)
+{
+size_t len = 10;
+char *ret;
+char dst[len + 1];
Hmm. That last line is a VLA, and might not compile in all C
compilers because it's not allowed in C89.
http://stackoverflow.com/questions/448844/variable-sized-arrays-in-c
Wine seems
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26638
Your paranoid android
On Tue, Aug 6, 2013 at 10:44 PM, Álvaro Nieto wrote:
> Remove strlen and implement some tests
You should probably add tests for when the source string is not null-terminated.
Frédéric Delanoy
On 8/6/2013 11:09, Álvaro Nieto wrote:
This patch solves [Bug 34211]. The implementation of strncpy function
doesn't compliant with C standard [1]. Also Microsoft Visual Studio
C/C++ compiler is ok with the standard [2].
Extract from msdn;
"The strncpy function copies the initial count charac
On 08/02/13 20:08, Daniel Lehman wrote:
+if(!MSVCRT_CHECK_PMT(wcDest))
+{
+*MSVCRT__errno() = MSVCRT_EINVAL;
return MSVCRT_EINVAL;
+}
The MSVCRT_CHECK_PMT macro sets the errno value. There's also
MSVCRT_CHECK_PMT_ERR macro if you need to set different error.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26413
Your paranoid android
On 06/21/13 12:24, Marvin wrote:
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26066
Your paranoid android
On 30 May 2013 07:23, Austin English wrote:
> and no modern gcc/other compiler that I can find cares.
>
It does if you add -Wunused-parameter, but then you'll get a lot of
other warnings as well. IMO the "action = action;" line is pretty
pointless and best just removed, though if people are just l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/05/13 12:56, Dmitry Timoshkov wrote:
> Christian Costa wrote:
>
>> and no modern gcc/other compiler that I can find cares.
> It was probably added because of a tool that warned of the
> unused parameter ... So it all goes in circles
Le 30/05/2013 13:56, Dmitry Timoshkov a écrit :
Christian Costa wrote:
and no modern gcc/other compiler that I can find cares.
It was probably added because of a tool that warned of the unused
parameter ... So it all goes in circles. ;)
Ciao, Marcus
So what about action = NULL instead?
Christian Costa wrote:
> and no modern gcc/other compiler that I can find cares.
> >>> It was probably added because of a tool that warned of the unused
> >>> parameter ... So it all goes in circles. ;)
> >>>
> >>> Ciao, Marcus
> >>>
> >>>
> >>>
> >> So what about action = NULL instead?
> >
Le 30/05/2013 10:59, Dmitry Timoshkov a écrit :
Christian Costa wrote:
and no modern gcc/other compiler that I can find cares.
It was probably added because of a tool that warned of the unused
parameter ... So it all goes in circles. ;)
Ciao, Marcus
So what about action = NULL instead?
Christian Costa wrote:
> >> and no modern gcc/other compiler that I can find cares.
> > It was probably added because of a tool that warned of the unused
> > parameter ... So it all goes in circles. ;)
> >
> > Ciao, Marcus
> >
> >
> >
> So what about action = NULL instead?
A checker tool should
Le 30/05/2013 09:54, Marcus Meissner a écrit :
On Wed, May 29, 2013 at 10:23:29PM -0700, Austin English wrote:
This was added 12 years ago in 1db20bfd33f9c1486a1a662c2f78f45d00caf24b
but clang doesn't like it:
clang -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_MT -D_REENTRA
On Wed, May 29, 2013 at 10:23:29PM -0700, Austin English wrote:
> This was added 12 years ago in 1db20bfd33f9c1486a1a662c2f78f45d00caf24b
>
> but clang doesn't like it:
> clang -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__
> -D_MT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasin
That's ok with me.Thanks for the explanation. So Valgrind will report these
"intentional" memory leaks in addition to the "unintentional" ones. Correct?
2013/5/21 Dmitry Timoshkov
> Christian Costa wrote:
>
> > Out of curiosity. Not freeing these memory allocations shouldn't disturb
> > Valgri
Christian Costa wrote:
> Out of curiosity. Not freeing these memory allocations shouldn't disturb
> Valgrind to report false memory leaks?
Avoiding heap access on process exit should avoid possible dead locks
in case a terminated by ExitProcess thread holds the heap lock.
--
Dmitry.
Out of curiosity. Not freeing these memory allocations shouldn't disturb
Valgrind to report false memory leaks?
2013/5/21 Alexandre Julliard
> Dmitry Timoshkov writes:
>
> > Alexandre Julliard wrote:
> >
> >> >>case DLL_PROCESS_DETACH:
> >> >> -msvcrt_free_popen_data();
> >> >> m
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> >>case DLL_PROCESS_DETACH:
>> >> -msvcrt_free_popen_data();
>> >> msvcrt_free_io();
>> >> +if (lpvReserved) break;
>> >> +msvcrt_free_popen_data();
>> >> msvcrt_free_mt_locks();
>> >> msvcrt_free_console();
Alexandre Julliard wrote:
> >>case DLL_PROCESS_DETACH:
> >> -msvcrt_free_popen_data();
> >> msvcrt_free_io();
> >> +if (lpvReserved) break;
> >> +msvcrt_free_popen_data();
> >> msvcrt_free_mt_locks();
> >> msvcrt_free_console();
> >> msvcrt_free_args();
> >
> >
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>>case DLL_PROCESS_DETACH:
>> -msvcrt_free_popen_data();
>> msvcrt_free_io();
>> +if (lpvReserved) break;
>> +msvcrt_free_popen_data();
>> msvcrt_free_mt_locks();
>> msvcrt_free_console();
>> msvcrt_free_a
Alexandre Julliard wrote:
>case DLL_PROCESS_DETACH:
> -msvcrt_free_popen_data();
> msvcrt_free_io();
> +if (lpvReserved) break;
> +msvcrt_free_popen_data();
> msvcrt_free_mt_locks();
> msvcrt_free_console();
> msvcrt_free_args();
Shouldn't msvcrt_free_io() be
On 2013/05/07 17:46, Juan Lang wrote:
> In general, I think you want to send this to wine-patches, not here.
True, I resent it to wine-patches yesterday already, when I noticed
that.
> > if(out->len < len) {
> > -memcpy(out->buf, str, out->len);
> > +memcpy(out->buf, str, ou
> <mailto:m...@duempel.org>> wrote:
>>
>> ---
>> dlls/msvcrt/printf.h |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/dlls/msvcrt/printf.h b/dlls/msvcrt/printf.h
>> index cfba4b7..8b749bc 100644
&g
On 05/07/13 17:46, Juan Lang wrote:
In general, I think you want to send this to wine-patches, not here.
This patch was also sent to wine-patches.
On Mon, May 6, 2013 at 12:26 PM, Max Kellermann mailto:m...@duempel.org>> wrote:
---
dlls/msvcrt/printf.h |2 +-
ns secrets. Therefore, one could argue that this bug
> constitutes a security vulnerability.
>
It'd be hard to make that argument convincingly. That's neither here nor
there, I suppose, but...
---
> dlls/msvcrt/printf.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion
kes applications expose internal (secret) data.
Usually, the destination buffer is on the stack, and the stack often
contains secrets. Therefore, one could argue that this bug
constitutes a security vulnerability.
---
dlls/msvcrt/printf.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
Hi Akihiro,
2013/4/19 Akihiro Sagawa
>
> According to MSDN, _mbsncoll_l receives a number of characters, but
> _mbsnbcoll_l receives a number of bytes. This is a big difference in
> multibyte code page.
> So you should properly handle this situation, or add FIXME message based
> on multibyte code
On Fri, 19 Apr 2013 14:42:50 +0800, Jactry Zeng wrote:
> +/*
> + * _mbsncoll_l(MSVCRT.@)
> + */
> +int CDECL _mbsncoll_l(const unsigned char *str1, const unsigned char *str2,
> MSVC
On 03/20/13 09:41, Akihiro Sagawa wrote:
On Mon, 18 Mar 2013 17:11:04 +0100, Piotr Caban wrote:
+char mbs[2];
This should be a constant, like MSVCRT_MB_LEN_MAX.
+int len = 0;
+ch = MSVCRT_fgetc(file);
+if(ch != MSVCRT_EOF) {
+mbs[0] = (char)ch;
+
On Mon, 18 Mar 2013 17:11:04 +0100, Piotr Caban wrote:
> +char mbs[2];
This should be a constant, like MSVCRT_MB_LEN_MAX.
> +int len = 0;
> +ch = MSVCRT_fgetc(file);
> +if(ch != MSVCRT_EOF) {
> +mbs[0] = (char)ch;
> +if(MSVCRT_isleadbyte(mbs[
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=24564
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=24548
Your paranoid android
On 02/26/13 23:57, André Hentschel wrote:
diff --git a/dlls/msvcrt/tests/time.c b/dlls/msvcrt/tests/time.c
index 30d9fa7..3d00769 100644
--- a/dlls/msvcrt/tests/time.c
+++ b/dlls/msvcrt/tests/time.c
@@ -181,8 +181,8 @@ static void test_gmtime(void)
err = p_gmtime32_s(&gmt_tm_s,
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23996
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23995
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23870
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23834
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23838
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23836
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23835
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23752
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23632
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23596
Your paranoid android
Jérôme Gardou writes:
> ---
> dlls/msvcrt/process.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
You should also fix the corresponding headers and remove the typecasts.
--
Alexandre Julliard
julli...@winehq.org
On 12/14/12 10:28, Jérôme Gardou wrote:
---
dlls/msvcrt/msvcrt.spec |2 +-
dlls/msvcrt/string.c| 26 --
2 files changed, 25 insertions(+), 3 deletions(-)
Please add parameters validation. The function also behaves differently
with native msvcrt when output
Austin English writes:
> On Wed, Dec 12, 2012 at 5:57 PM, Austin English
> wrote:
>> From the keeping Focht happy team
>>
>> This patch series fixes http://bugs.winehq.org/show_bug.cgi?id=13401
>>
>> --
>> -Austin
>
> Only export the symbol on 32-bit.
This should be properly integrated with th
) MSVCRT__ftol
> +@ cdecl -ret64 _ftol2() MSVCRT__ftol
>
> This will not work on 64-bit build or when __GNUC__ is not defined. I don't
> see _ftol function in native 64-bit msvcrt, maybe it should not be exported
> there.
Yeah, that's what ntdll was doing, I've sent an updated patch.
--
-Austin
Piotr Caban writes:
> @@ -359,6 +360,51 @@ void msvcrt_free_args(void)
>HeapFree(GetProcessHeap(), 0, MSVCRT__wenviron);
>HeapFree(GetProcessHeap(), 0, MSVCRT__pgmptr);
>HeapFree(GetProcessHeap(), 0, MSVCRT__wpgmptr);
> + HeapFree(GetProcessHeap(), 0, argv_expand);
> +}
> +
> +static
or when __GNUC__ is not defined. I
don't see _ftol function in native 64-bit msvcrt, maybe it should not be
exported there.
On 11/05/12 18:02, Alexandre Julliard wrote:
Piotr Caban writes:
---
dlls/msvcrt/string.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M msvcr90.dll -T ../../.. -p msvcr90_test.exe.so
msvcr90.c &&
Piotr Caban writes:
> ---
> dlls/msvcrt/string.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M msvcr90.dll -T ../../.. -p
msvcr90_test.exe.so msvcr90.c && touch msvcr90.ok
msvcr90.c:895:
Piotr Caban writes:
> ---
> dlls/msvcrt/cpp.c | 129
> ++--
> dlls/msvcrt/cxx.h | 114 +--
> 2 files changed, 155 insertions(+), 88 deletions(-)
It doesn't work here:
../../../.
Detlef Riekenberg writes:
> @@ -1286,6 +1288,17 @@ static int msvcrt_get_flags(const MSVCRT_wchar_t*
> mode, int *open_flags, int* st
> case '+':
> case ' ':
>break;
> +case ',':
> + if (!memcmp(mode, encoding_utf8, sizeof(encoding_utf8)) )
> + {
> +*open_
> If there's some code I'd must write natively to bind the Windows app
> to the Linux system (e.g. interacting with some low-level Linux stuff),
> can I build that library as a DLL with wineg++ / winelib and have
> the WINE-invoked app use that?
Yes. This is what I meant by a bridge between Linux
On Wed, Aug 1, 2012 at 12:34 AM, Vincent Povirk wrote:
> Visual C++ ships with headers and a compiler. Anyway, there's no
> advantage to winelib as a build environment compared to MSVC or the
> Platform SDK, assuming you are able to use one of those, except for
> the ability to port to architectur
>>> 1) provide Windows headers, to keep those DWORDs etc. defined
>>
>> Yes, but so does MSVC.
>
> MSVC as in Microsoft Visual C++? It only provides a C/C++ runtime. The
> headers come
> from the Platform SDK. In any case, here Winelib provides them,
> probably slightly altered
> so they'd built be
On Tue, Jul 31, 2012 at 11:15 PM, Vincent Povirk wrote:
>> Winelib is there to:
>> 1) provide Windows headers, to keep those DWORDs etc. defined
>
> Yes, but so does MSVC.
MSVC as in Microsoft Visual C++? It only provides a C/C++ runtime. The
headers come
from the Platform SDK. In any case, here
> Winelib is there to:
> 1) provide Windows headers, to keep those DWORDs etc. defined
Yes, but so does MSVC.
> 2) implement Windows APIs in terms of Linux as much as possible -- to keep
> those
> CreateFileWs going, to avoid changing every single 'Sleep' to 'sleep'
> "just because".
Winelib do
an't Winelib keep serving
as a rudimentary abstraction layer, as funny as that might sound?
Our use of Windows is pretty basic. I don't believe we use a single
function whose
signature you don't already know by heart. (Except, maybe, for
CryptoAPI, but I don't
rule out re-implemen
I have to wonder if you're using winelib in a way that's not appropriate.
Winelib is not a useful intermediate step in porting an existing
application to Linux, as most of the work involved in porting to
winelib will not help you with a native Linux port. At some point you
have to make a clean bre
Hey,
I apologize for the flood of "newbie" questions coming from me lately :-)
At the very least, I'll be giving Winelib a decent challenge, and
perhaps we could
improve it a bit...
Now, I've seen that Wine re-implements MSVCRT. However, this is a
drop-in MSVCRT.DLL
r
In 2004, somebody has asked a question:
http://www.winehq.org/pipermail/wine-devel/2004-October/030349.html
The reply from Alexandre was:
> > Either there should be a overriding "wine/include/msvcrt/tchar.h"
> > file with different defintions. Or the error message "Y
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://winetestbot.dolphin/JobDetails.pl?Key=110
Your paranoid android.
On Mon, Jul 23, 2012 at 8:33 AM, Alexandre Julliard wrote:
>>> You shouldn't need to put that in msvcrt.
>>
>> OK, I'll put it in msvcr90.
>
> It's not supposed to be there either.
Maybe I was grepping without the w prefix by accident, sorry.
I see now it's only in msvcr100.
- Dan
Dan Kegel writes:
> On Mon, Jul 23, 2012 at 5:56 AM, Alexandre Julliard
> wrote:
>> You shouldn't need to put that in msvcrt.
>
> OK, I'll put it in msvcr90.
It's not supposed to be there either.
>> Also please check the parameters correctly lik
On Mon, Jul 23, 2012 at 5:56 AM, Alexandre Julliard wrote:
> You shouldn't need to put that in msvcrt.
OK, I'll put it in msvcr90.
> Also please check the parameters correctly like every other _s function does.
The wmemmove_s/wmemcpy_s I posted are exact copies of th
Dan Kegel writes:
> Next patch will expose them for msvcr100.
>
> From 357c45971e1315e8f6cd1f9feac65cf96a006a41 Mon Sep 17 00:00:00 2001
> From: Dan Kegel
> Date: Fri, 20 Jul 2012 10:39:32 -0700
> Subject: [PATCH 1/2] msvcrt: add wmemcpy_s and wmemmove_s
>
> -
André Hentschel writes:
> @@ -39,10 +44,19 @@ static void init(void)
> pmemcpy_s = (void*)GetProcAddress(hmod, "memcpy_s");
> pI10_OUTPUT = (void*)GetProcAddress(hmod, "$I10_OUTPUT");
> pstrerror_s = (void *)GetProcAddress(hmod, "strerror_s");
> +pbsearch_s = (void *)GetProcAdd
On 06/14/12 11:41, Marvin wrote:
=== WINEBUILD (build) ===
Patch failed to apply
Looks like wine source was not updated on testbot yesterday.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=19045
Your paranoid android
Bruno,
On 06/14/2012 11:25 AM, Piotr Caban wrote:
> On 06/13/12 23:51, Bruno Jesus wrote:
>> Just a side note. Although I'm not sure I think portuguese is "ptg",
>> brazilian portuguese is "ptb". So the correct may be:
>>
>>> +"portuguese", "ptg",
>>
>> A Portugal user would be able to check t
On 06/13/12 23:51, Bruno Jesus wrote:
Just a side note. Although I'm not sure I think portuguese is "ptg",
brazilian portuguese is "ptb". So the correct may be:
+"portuguese", "ptg",
A Portugal user would be able to check that, or maybe it's easier to
write a testcase.
There already is a
On Wed, Jun 13, 2012 at 2:47 PM, Francois Gouget wrote:
> ...
> dlls/msvcrt/locale.c | 2 +-
> dlls/msvcrt/tests/locale.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> ...
> - "portugese", "ptb",
> + "portuguese"
On 06/13/12 05:19, Francois Gouget wrote:
Is there a reason why Portuguese is misspelt in these two places?
It's a typo. Thanks for spotting it.
Is there a reason why Portuguese is misspelt in these two places?
diff --git a/dlls/msvcrt/locale.c b/dlls/msvcrt/locale.c
index 97b82ec..b26a9c8 100644
--- a/dlls/msvcrt/locale.c
+++ b/dlls/msvcrt/locale.c
@@ -85,7 +85,7 @@ static const char * const _country_synonyms[] =
"german-
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=17893
Your paranoid android
On 04/10/12 20:04, David Laight wrote:
But see also http://www.hermetic.ch/cal_stud/cal_art.html for some
info about which years were/are actually leap years ...
This is not how msvcrt handles dates. Additionally most of the functions
are refusing to work on dates before 1900.
Piotr Caban writes:
> +|| !MSVCRT_CHECK_PMT(asctime_buf(time, mstm) != NULL)) {
You don't want to use MSVCRT_CHECK_PMT this way, the error won't make
sense.
--
Alexandre Julliard
julli...@winehq.org
1 - 100 of 710 matches
Mail list logo
