On Monday May 20 at 22:24:58, Alan W. Irwin wrote:
>wine at raven> wine64
>wine64: error while loading shared libraries: libwine.so.1: cannot
>open shared object file: No such file or directory
Hi Alan,
This error is caused by a regression in Wine 1.5.30. It is not present in
version 1.5.29.
Th
My use case is building and testing software packages on Wine.
My 32-bit build of wine-1.5.19 on x86_64 hardware was fine for this
purpose for MinGW/MSYS builds so I stuck with it until today when
I attempted to expand my building and testing of software to the
Cygwin on Wine platform.
I immediat
My reasoning was that the order of appearance from the screen buffer struct
should be the same each time. The patch adds uniformity, but if that is not
wanted, then so be it.
Some of the formatting changes are necessary however, because some of the
server operations are performed in a specific
Hugh McMaster wrote:
> This patch modifies server/protocol.def and server/console.c to add support
> for console font size detection and console window size rendering. It also
> tidies up a few inconsistencies in the repeated usage of aspects of the
> screen buffer struct.
Your patches are full
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
Charles Davis wrote:
> You're violating COM rules here: when you QI an object for an interface
> pointer, the QI must always return the same result no matter what. Here,
> however, you're returning this interface pointer in response to a query
> for IUnknown, when the already-existing QueryInterf
On May 19, 2013, at 9:14 PM, Dmitry Timoshkov wrote:
> diff --git a/dlls/windowscodecs/bitmap.c b/dlls/windowscodecs/bitmap.c
> index f8904df..646f3a7 100644
> --- a/dlls/windowscodecs/bitmap.c
> +++ b/dlls/windowscodecs/bitmap.c
> @@ -446,6 +471,226 @@ static const IWICBitmapVtbl BitmapImpl_Vtbl
Hi George,
static void test_classesroot(void)
> {
> +static const WCHAR reg_user[] = {
> '\\','R','E','G','I','S','T','R','Y','\\','U','S','E','R' };
> +static const WCHAR reg_machine[] = {
> '\\','R','E','G','I','S','T','R','Y','\\','M','A','C','H','I','N','E' };
>
Almost, but these ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-05-20 23:03, schrieb Austin English:
> On Wed, May 15, 2013 at 3:32 AM, Henri Verbeet
> wrote:
>> On 14 May 2013 23:46, Stefan Dösinger
>> wrote:
>>> These tests have the potential to break on Windows when other
>>> applications create or re
On Wed, May 15, 2013 at 3:32 AM, Henri Verbeet wrote:
> On 14 May 2013 23:46, Stefan Dösinger wrote:
>> These tests have the potential to break on Windows when other
>> applications create or release a large number of video memory resources
>> while the test is running.
>>
> Yeah, maybe we don't
Dmitry Timoshkov writes:
> Manifest prevents loading of a native dll anyway.
Not if it's installed globally.
--
Alexandre Julliard
julli...@winehq.org
On Mon, May 20, 2013 at 7:53 PM, Dmitry Timoshkov wrote:
>
> I'd test it like the following:
>
> 1. create a socket
> 2. check that WSAIoctl works
> 3. call WSAAsyncSelect/WSAEventSelect
> 4. check that WSAIoctl fails
> 5. set the socket back to blocking mode using described technique
> 6. check t
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=25629
Your paranoid android
Qian Hong wrote:
> The above description implies two behaviors:
> A: 'The WSAAsyncSelect or WSAEventSelect routine automatically sets a
> socket to non-blocking mode'
> B: 'any attempt to use WSAIoctl to set the socket back to blocking
> mode will fail with WSAEINVAL'
>
> Currently Wine's winso
On Mon, May 20, 2013 at 7:02 PM, Dmitry Timoshkov wrote:
> Qian Hong wrote:
> MSDN page you referenced has a hint how this behaviour could be tested:
>
> "The WSAAsyncSelect or WSAEventSelect routine automatically sets a socket
> to non-blocking mode. If WSAAsyncSelect or WSAEventSelect has been
Qian Hong wrote:
> Thanks for the comment, actually I already guess you will point out it
> requires a test :)
>
> There is no win32 api to detect whether a socket is blocking or
> non-blocking, do you have any advice how to test it in our Wine test
> framework?
http://stackoverflow.com/questio
Hi Dmitry,
On Mon, May 20, 2013 at 6:13 PM, Dmitry Timoshkov wrote:
> This change requires a test case, MSDN is often wrong, so its claims
> at least need to be very carefully checked.
Thanks for the comment, actually I already guess you will point out it
requires a test :)
There is no win32 ap
Qian Hong wrote:
> Fixed http://bugs.winehq.org/show_bug.cgi?id=33076
>
> Reference:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms741621%28v=vs.85%29.aspx
>
> See also comment in WSAIoctl:
> /* AsyncSelect()'ed sockets are always nonblocking */
This change requires a test case,
18 matches
Mail list logo
