On 2013-05-21 18:27-0700 Austin English wrote:
On Tue, May 21, 2013 at 6:17 PM, Alan W. Irwin
wrote:
Can somebody advise me about the importance (or not) of the remaining
two missing 32-bit libraries (libdbus and gstreamer)? For example,
are they worth some extraordinary measures such as down
On Tue, May 21, 2013 at 6:17 PM, Alan W. Irwin
wrote:
> On 2013-05-21 21:22+0200 André Hentschel wrote:
>
>> To finally answer this: pure wine64 can't run 32-bit applications, you
>> need wine32 or a wow64 setup for this.
>
>
> Thanks for that important clarification. That means I always need
> 3
On 2013-05-21 21:22+0200 André Hentschel wrote:
To finally answer this: pure wine64 can't run 32-bit applications, you need
wine32 or a wow64 setup for this.
Thanks for that important clarification. That means I always need
32-bit as standalone or as part of wow64. So regardless of that
cho
As instructed, I added a few lines to the already written tests that
confirm my claim.
Part of the research of the registry merging project was to determine
where the implementation is going to be written: advapi32, ntdll or
the server itself. The server choice was dismissed since HKCR isn't
store
On May 21, 2013, at 1:34 PM, Andrew Eikum wrote:
> ---
> dlls/dinput/joystick_osx.c | 34 --
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/dinput/joystick_osx.c b/dlls/dinput/joystick_osx.c
> index 94398e7..8fb675d 100644
> --- a/dlls/din
Am 21.05.2013 10:10, schrieb Alan W. Irwin:
> On 2013-05-20 20:24-0700 Alan W. Irwin wrote:
>> So here are my questions and further comments:
>>
>> 1. Is there a way to stick with a pure 64-bit Wine system, or is that
>> normally pretty useless because downloaded applications such as the
>> Cygwin
> The idea there to install *.so symlinks manually might be a big help.
> For example, Debian wheezy does allow simultaneous install of
> libfreetype6:i386 and libfreetype6:amd64. (In fact, my system has
> those both installed now.) It is the -dev versions of those packages
> which cannot be simul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-05-21 16:03, schrieb Henri Verbeet:
> On 21 May 2013 13:18, Stefan Dösinger
> wrote:
>> +static void test_coop_level_versions(void)
> It may make more sense to move that to ddraw2.c and ddraw4.c
> instead.
The reasoning behind putting this in
Sergey Guralnik writes:
> On 2013-05-06 13:24, Sergey Guralnik wrote:
>> Alexandre Julliard writes:
>>> ...
>>> It doesn't make sense to have all these complicated tests if we are
>>> going to always repaint anyway, which is essentially what your patch
>>> does. There has to be more to it than th
Alistair Leslie-Hughes writes:
> @@ -1717,6 +1717,17 @@ BOOL WINAPI SymGetLineNext64(HANDLE hProcess,
> PIMAGEHLP_LINE64 Line)
> }
>
> /**
> + * SymGetLineNextW64 (DBGHELP.@)
> + *
> + */
> +BOOL WINAPI SymGetLineNextW
Qian Hong writes:
> @@ -5383,7 +5383,11 @@ int WINAPI WSAEventSelect(SOCKET s, WSAEVENT hEvent,
> LONG lEvent)
> ret = wine_server_call( req );
> }
> SERVER_END_REQ;
> -if (!ret) return 0;
> +if (!ret)
> +{
> +_enable_event(SOCKET2HANDLE(s), 0, FD_WINE_NONB
Jactry Zeng writes:
> diff --git a/dlls/riched20/tests/test.txt b/dlls/riched20/tests/test.txt
> new file mode 100644
> index 000..e69de29
If you need an external file you have to create a temp file in the
test. You can't rely on running from inside the source tree.
--
Alexandre Julliard
j
On Tue, May 21, 2013 at 3:45 PM, Jactry Zeng wrote:
>
>
>
>
>
If the whole purpose of storing flags names is to output readable debug
info I think it's better to have a single separate function
that takes flags combination and returns static buffer pointer with a name.
This way it will need just
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
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=25647
Your paranoid android
Christian Costa writes:
> There is one test becoming todo. This will be fixed in another patch.
> This patch also should fix bug 30897.
> ---
> dlls/d3dxof/parsing.c | 35 ++-
> dlls/d3dxof/tests/d3dxof.c | 22 +++---
> 2 files changed, 21
On 21 May 2013 13:18, Stefan Dösinger wrote:
> The new code does not deliver the resolution change messages to the
> correct window, see the todo_wine markers in the next patch. Getting
> this right isn't simply a matter of passing the correct window to
> wined3d_device_restore_fullscreen_window b
On 21 May 2013 13:18, Stefan Dösinger wrote:
> +static void test_coop_level_versions(void)
It may make more sense to move that to ddraw2.c and ddraw4.c instead.
(IIRC you can't QI a ddraw1 interface from ddraw7.)
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=25646
Your paranoid android
Hi Zhan,
On 05/17/13 16:53, Zhan Jianyu wrote:
> This patch is built based on Jaceks's newly-submitted patch:
>
> commit 48a862306288d69d3623d5ecdc0f5a5a40addafe
> ( vbscript: Round half to even in to_int)
>
> Thanks, Jacek. :-)
>
> With his patch, CInt could be implementd in a clean way,
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
On 2013-05-21 11:08+0200 Frédéric Delanoy wrote:
On Tue, May 21, 2013 at 10:10 AM, Alan W. Irwin
wrote:
Hugh McMaster's reply was already a help, but I need more comments
please.
Maybe http://wiki.winehq.org/WineOn64bit could help?
The idea there to install *.so symlinks manually might be
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();
> >
> >
On Tue, May 21, 2013 at 10:10 AM, Alan W. Irwin
wrote:
> Hugh McMaster's reply was already a help, but I need more comments
> please.
>
Maybe http://wiki.winehq.org/WineOn64bit could help?
Frédéric
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
On 2013-05-20 20:24-0700 Alan W. Irwin wrote:
[...]For example:
wine@raven> wine64
wine64: error while loading shared libraries: libwine.so.1: cannot
open shared object file: No such file or directory
I fixed this 1.5.30 issue by applying the patch at
http://source.winehq.org/git/wine.git/pa
28 matches
Mail list logo
