On Mon, Jul 23, 2012 at 07:06:21PM -0700, Scott Ritchie wrote:
> Wine is the last remaining package still depending on GCC 4.5 in the
> current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port
> Wine, however 4.6 is known to not work too well.
>
> But now we have 4.7 -- have there b
Groveling around, I found a few possibilities:
backtraces broken on gcc 4.7
http://bugs.winehq.org/show_bug.cgi?id=26791
ICE when compiling:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641056
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640864
https://bugs.launchpad.net/ubuntu/+source/gc
2012/7/23 Austin English :
> Judging by similar recent commits
> (http://source.winehq.org/git/wine.git/commitdiff/f320f6cf4843eab3d22b60674808e4e3de964b5a),
> 1 seems to be the way to go.
Thanks for the answer. What makes me uneasy about this approach is
that if I want to duplicate the tests for
On 07/23/2012 07:44 PM, Austin English wrote:
> On Mon, Jul 23, 2012 at 7:06 PM, Scott Ritchie wrote:
>> Wine is the last remaining package still depending on GCC 4.5 in the
>> current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port
>> Wine, however 4.6 is known to not work too wel
On Sun, Jul 22, 2012 at 11:07 PM, Alex Henrie wrote:
> Dear Wine developers,
>
> Bug 24389 documents an application crash due to the unimplemented
> function msvcr90._wtoi_l. I have been looking into how to resolve this
> problem. I see three workable options:
>
> 1. Implement msvcr90._wtoi_l by c
On Mon, Jul 23, 2012 at 7:06 PM, Scott Ritchie wrote:
> Wine is the last remaining package still depending on GCC 4.5 in the
> current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port
> Wine, however 4.6 is known to not work too well.
>
> But now we have 4.7 -- have there been any b
Wine is the last remaining package still depending on GCC 4.5 in the
current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port
Wine, however 4.6 is known to not work too well.
But now we have 4.7 -- have there been any bugs attributed to its usage?
Thanks,
Scott Ritchie
GOUJON Alexandre writes:
> I may be mis-using it but on my (virtualized) Win7, QueryDosDevice
> with a NULL argument returns 6651 chars.
> I truncated the output to the first strings and here's the result :
>
> Z:
> Global
> D:
> ACPI#PNP0C0A#0#{72631e54-78a4-11d0-bcf7-00aa00b7b32a}
> PhysicalDri
On 07/21/2012 12:34 PM, Eduard Hasenleithner wrote:
All the code in dlls/kernel32/volume.c seems to be build around
evaluating the symlinks present in .wine/dosdevices. Is there already
a design document which describes how the interaction with mountmgr
should look like in future? Will the dosd
On 07/23/2012 09:15 PM, Alexandre Julliard wrote:
GOUJON Alexandre writes:
On 07/23/2012 03:03 PM, Alexandre Julliard wrote:
That's very inefficient. There are better way of enumerating drives,
check for instance QueryDosDevice.
I'm not sure QueryDosDevice is more efficient :
+ with NULL dev
GOUJON Alexandre writes:
> On 07/23/2012 03:03 PM, Alexandre Julliard wrote:
>> That's very inefficient. There are better way of enumerating drives,
>> check for instance QueryDosDevice.
> I'm not sure QueryDosDevice is more efficient :
> + with NULL device name, it returns every MS-DOS device wh
On 07/23/2012 03:03 PM, Alexandre Julliard wrote:
That's very inefficient. There are better way of enumerating drives,
check for instance QueryDosDevice.
I'm not sure QueryDosDevice is more efficient :
+ with NULL device name, it returns every MS-DOS device which is not
what we want
+ if we ca
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 like every other _s function does.
>
> The wmemmove
>> In cases where we need to convert a logical measurement to a device
>> measurement (maybe including in GdipTransformPoints) I think
>> units_to_pixels/pixels_to_units is appropriate, but it should really
>> take a Graphics object rather than a dpi (since the correct dpi cannot
>> be known withou
Vincent Povirk wrote:
> Oh. Then what I mean to say is that if you specify the size in logical
> units, the size in pixels depends on the dpi of the graphics object.
> The size in world coordinates depends on the size in pixels, the page
> unit, page scale, and the world transform.
>
> At least
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 the existing
non-w implementat
>> OK, this is starting to make sense to me. If I'm understanding this,
>> the point of your series is that the font has a consistent size based
>> on the unit stored in the font. If it's a physical unit like inches
>> then the font's size in world coordinates changes based on the
>> graphics page
Series looks good to me.
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=20256
Your paranoid android
Alexandre Goujon writes:
> Previous approach was patch #88280
> ---
> dlls/kernel32/volume.c | 18 +++---
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c
> index 8377e41..57453bb 100644
> --- a/dlls/kernel32/volume
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
>
> ---
> dlls/msvcrt/heap.c | 2
Daniel Jelinski writes:
> 2012/7/23, Alexandre Julliard :
>> You can't assume that the other Wine window is directly underneath the
>> transparent one, there may be some other X windows in between that
>> should receive the click instead.
>
> I just determined that in such cases Windows (at least
2012/7/23, Alexandre Julliard :
> You can't assume that the other Wine window is directly underneath the
> transparent one, there may be some other X windows in between that
> should receive the click instead.
I just determined that in such cases Windows (at least 2008) silently
eats the event - n
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=20253
Your paranoid android
Daniel Jelinski writes:
> Hello,
> When you say that this can't be fixed, do you mean that we can't
> properly route a mouse event if the window is transparent and it
> covers a window from another process? Well I'm not sure if Windows
> does that either. However, we don't need any X11 support to
infyqu...@gmail.com wrote:
> I have used the notation in the MSDN.
That can't be an excuse to not do it properly.
--
Dmitry.
Hello,
When you say that this can't be fixed, do you mean that we can't
properly route a mouse event if the window is transparent and it
covers a window from another process? Well I'm not sure if Windows
does that either. However, we don't need any X11 support to forward
the message to another wind
I have used the notation in the MSDN.
Thanks,
Vijay
On , Dmitry Timoshkov wrote:
Vijay Kiran Kamuju infyqu...@gmail.com> wrote:
> +WINAPI DWORD AtlGetVersion(void* pReserved)
That's a somewhat strange choice for the placement of a calling convention
specifier. Also it shouldn
Daniel Jelinski writes:
> Hello,
> Check out the description of HTTRANSPARENT on [1]. If MSDN is right
> here, then the code after applying my patch is still not correct, but
> at least closer to correct than it is now.
> As for a test case, do you prefer a minimalistic test case with one
> test
André Hentschel writes:
> Problem:
> On ARM the default "char" is "unsigned char" for performance reasons,
> Wine uses "char" expecting the x86 default (signed char).
In general there's no such expectation in Wine. If there are places that
expect char to be signed, they are bugs that should be f
Vincent Povirk wrote:
> OK, this is starting to make sense to me. If I'm understanding this,
> the point of your series is that the font has a consistent size based
> on the unit stored in the font. If it's a physical unit like inches
> then the font's size in world coordinates changes based on t
Vijay Kiran Kamuju wrote:
> +WINAPI DWORD AtlGetVersion(void* pReserved)
That's a somewhat strange choice for the placement of a calling convention
specifier. Also it shouldn't be too hard to avoid a hungarian style named
variable, and placing '*' properly.
--
Dmitry.
33 matches
Mail list logo
