Hi,
On 04/18/11 23:53, Vincas Miliūnas wrote:
> My remark: (The method is implemented by reusing existing code) this->size+count<this->size is the same as count< 0 and throwing a "string too long" exception in that case is not semantic.
count is an unsigned variable so it cannot be smaller then 0. My
intention was to make sure there's no overflow. This check is not needed
because MSVCP_basic_string_char_npos-this->size <= count already makes
sure this->size+count has small enough value.
+basic_string_wchar* __thiscall MSVCP_basic_string_wchar_append_len_wchar(
+ basic_string_wchar *this, size_t count, wchar_t c)
+{
+ TRACE("%p %lu %lc\n", this, (unsigned long)count, c);
It's probably not allowed to use %lc format.
Cheers,
Piotr
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=10525
Your paranoid android.
=== WVISTAADM (32 bit d3dxof) ===
Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Piotr Caban <piotr(a)codeweavers.com> writes:
> ---
> dlls/msvcrt/file.c | 118
> ++++++++++------------------------------------------
> 1 files changed, 22 insertions(+), 96 deletions(-)
This one is causing console apps to output null characters. You'll have
to spend more time on this patch series, it doesn't seem quite ready.
--
Alexandre Julliard
julliard(a)winehq.org
Wolfgang Walter <wolfgang.walter(a)stwm.de> writes:
> set status field of piosb to STATUS_PENDING before calling wait_on(). If wait_on
> returns with STATUS_PENDING don't touch piosb.
>
> Reason: if wait_on returns with STATUS_PENDING it started a thread which
> itself modifies the status field.
In general the iosb is not modified until the operation completes.
--
Alexandre Julliard
julliard(a)winehq.org
Hey Guys,
On some of the bugs that i have reported to freedesktop, i have been
asked about why Wine is making calls like XDrawSegmentand not using
Cairo to handle the 2d drawing which always provides consistent behavior
regardless of drivers[1].
I have also read that cairo support "X Window System, Quartz, Win32,
image buffers, PostScript, PDF, and SVG file output. Experimental
backends includeOpenGL <http://www.cairographics.org/OpenGL/>, XCB,
BeOS, OS/2, and DirectFB"[2]. So it will also works with Wayland when
this is ready :D.
So i think this is a good way to make Wine more graphic driver agnostic
and improve the behavior on MacOS without having to write a complete new
driver just for Quartz.
So i would like to know your thoughts, if Cairo could improve some stuff
or if is not related or useless to the project
Greetings
Jaime Rave
[1] https://bugs.freedesktop.org/show_bug.cgi?id=22770#c14
[2] http://www.cairographics.org/
"Ray Hinchliffe (RH)" <ray(a)rh-software.com> writes:
> 1) When possible report DPC and Interrupt times
>
> 2) Fix _APPLE_ to return times in 100ns units and zero the unset members
>
> 3) Change the failure code to return 100ns values
>
> 4) Expunge unnecessary use of RtlAllocateHeap() etc..
Separate changes should be separate patches.
> @@ -1241,8 +1241,9 @@ typedef struct _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION {
> LARGE_INTEGER IdleTime;
> LARGE_INTEGER KernelTime;
> LARGE_INTEGER UserTime;
> - LARGE_INTEGER Reserved1[2];
> - ULONG Reserved2;
> + LARGE_INTEGER DpcTime;
> + LARGE_INTEGER IntTime;
> + ULONG IntCount;
You can't change the public definition.
--
Alexandre Julliard
julliard(a)winehq.org
Jacek Caban <jacek(a)codeweavers.com> wrote:
> +BOOL WINAPI K32EmptyWorkingSet(HANDLE hProcess)
> +{
> + return SetProcessWorkingSetSize(hProcess, (SIZE_T)-1, (SIZE_T)-1);
> +}
You need to export it from kernel32. Also using ~0 instead of casting -1
would be better IMHO.
--
Dmitry.