wine-devel May 2008

wine-devel@winehq.org

131 participants
254 discussions

Double free in direct sound capture
by Michael Karcher 30 May '08

30 May '08

Hello developers I was running the testcases with warn+heap, and noted some warnings from dsound:capture. They are caused by double free calls, and only happen with winealsa.drv, not with wineoss.drv. The following patch happens to makes the messages disappear. Could somebody with some knowledge about wine's DirectSound implementation please look into this issue and find a proper fix? Regards, Michael Karcher

2 2

Re: mscms/tests: The presence of an ICM file in the color directory has nothing to do with the presence of a registered RGB profile.
by Paul Vriens 30 May '08

30 May '08

Francois Gouget wrote: > --- > > The tests were failing on my Windows systems because they have ICM files > in the color directory but they are not registered, i.e. they don't > even have the HKLM\Software\Microsoft\Windows > NT\CurrentVersion\ICM\RegisteredProfiles key. > > What matters for GetStandardColorSpaceProfile() is that that the > relevant value is set in HKLM\Software\Microsoft\Windows > NT\CurrentVersion\ICM\RegisteredProfiles. It may also check the presence > of the file but the presence of an 'srgb*.icm' file in the color > directory is by no means sufficient. > > > dlls/mscms/tests/profile.c | 33 ++++++++++++++++++++++----------- > 1 files changed, 22 insertions(+), 11 deletions(-) > > > ------------------------------------------------------------------------ > > This addition to the tests checks for a registry entry: + if (strcmp(szName, "RGB") == 0) + *has_space_rgb = TRUE; I see several systems (test.winehq.org) including some of mine that have "RGB " (extra space at the end). It seems that the logic that was added for has_space_rgb is also valid for "RGB ". Any idea? -- Cheers, Paul.

1 0

Re: msxml3: Fix crashes on win98
by Paul Vriens 30 May '08

30 May '08

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > msxml3: Fix crashes on win98 > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > Just a question. Why not use a goto to a cleanup session instead of having these huge indented blocks? Or is goto a bad thing by default? (I have the same 'issue' with the setupapi/devinst tests. All the tests in there have these big sets of indented code. In this setupapi case a simple return on failure would have been enough probably) -- Cheers, Paul.

2 1

Search for leftovers after running winetest
by Paul Vriens 30 May '08

30 May '08

Hi, (Sorry, first one went to the wrong list) I just had a look at some of the stuff that's still around after running winetest a few months now on my W2K3 box (some of the regkeys are linked of course): Registry ======== HKEY_CLASSES_ROOT\Applications\shell32_test.exe HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\shell32_test.exe HKEY_CLASSES_ROOT\TypeLib\{D96D8A3E-78B6-4C8D-8F27-059DB959BE8A} HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{D96D8A3E-78B6-4C8D-8F27-059DB959BE8A} (includes a reference to oleaut32_test.exe) HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.shlexec\OpenWithList (reference to shell32_test.exe) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug (contains 'Debugger' which points to kernel32_test.exe) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StillImage\Debug\mscms_test.exe HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\BOGUS HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\BOGUS HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Enum\USB\BOGUS HKEY_CURRENT_USER\Software\Wine HKEY_LOCAL_MACHINE\SOFTWARE\Wine\msitest Filesystem ========== C:\Config.Msi C:\Documents and Settings\testuser (basically a testuser for each winetest run on xp+ systems) (Any maybe more) I'm wondering how this effects tests? Any ideas? Do other see the same leftovers? I also think we should remove all leftovers after the tests if possible. Nice janitorial task or important enough to be tackled quicker? -- Cheers, Paul.

2 3

Recent change causes registry creation to fail
by Benjamin M. Schwartz 30 May '08

30 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to write a scripted wine installation in a nonstandard directory. As part of this procedure, I set $WINEPREFIX and then run wineprefixcreate. This worked perfectly in 0.9.59, but in 0.9.60+ it fails with wineserver: chdir to config dir : Not a directory wine: for some mysterious reason, the wine server failed to run "regedit" fails with the same error. Wine does run, but its registry appears to be screwy. For example, the DOS environment variables like %PROGRAMFILES% and %PATH% are not set at all. I have traced the error to a change made by Alexandre Julliard to registry.c in mid-April [1]. Why might that change have this effect? What should I do to avoid this problem? Thank you, Ben Schwartz OLPC volunteer [1] http://source.winehq.org/git/wine.git/?a=blobdiff;f=server/registry.c;h=d2c… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg/g8wACgkQUJT6e6HFtqTgdwCeM7S/HVIS8LU82qVQ5R3cs0Yt HGAAn3cQhdG4VR5H/2jbIbU7SS/uDRX4 =5Bd7 -----END PGP SIGNATURE-----

1 0

Re: advpack: don't close a handle if it wasn't opened
by James Hawkins 30 May '08

30 May '08

On Thu, May 29, 2008 at 10:34 PM, Dan Kegel <dank(a)kegel.com> wrote: > Avoids referencing an undefined variable. > The right way to fix this is to set subkey to NULL in the beginning. -- James Hawkins

1 0

Currently Git doesn't build on Linux x86_64
by Erik de Castro Lopo 29 May '08

29 May '08

Hi all, I've just pulled from git and the latest change I have is this one: commit 4c928d39ad82e576113a34bfa4d27dd0b3eaba17 Author: James Hawkins <jhawkins(a)codeweavers.com> Date: Wed May 28 19:15:15 2008 -0500 oleaut32: Disable olefont tests that fail on all platforms. When I ./configure it I get: checking for freetype-config... freetype-config checking for -lfreetype... not found configure: error: FreeType development files not found. Fonts will not be built. Dialog text may be invisible or unaligned. Use the --without-freetype option if you really want this. This is an Ubuntu Hardy system and I do have freetype installed: > dpkg -L libfreetype6-dev | grep libfreetype.so /usr/lib/libfreetype.so Is anyone else seeing this? Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Men who use terrorism as a means to power, rule by terror once they are in power." -- Helen Macinnes

3 2

Re: implemented first testcase for dxdiagn
by Vitaliy Margolen 29 May '08

29 May '08

Markus wrote: > > ------------------------------------------------------------------------ > > > + hr = IDxDiagContainer_GetNumberOfProps(pAdapterContainer, &dwPropCount); > + ok(dwPropCount == 72, "Incorrect number of properties in display adapter container. " > + "Found (%d) should be (%d).\n", dwPropCount, 72); I don't think you can relay on that being true all the time. Besides what's the point in testing the number of properties? As a general note - if you add a test that currently fails on Wine it needs todo_wine at front of it. Vitaliy.

1 0

Re: ntdll: Strengthen current tests and add new tests for asynchronous I/O.
by Zac Brown 29 May '08

29 May '08

Woops, ignore this patch. Its got a couple things wrong with it. I'll send a fix later on. -Zac Zac Brown wrote: > Strengthen current tests and add new tests for asynchronous I/O. Missing > test for empty messages as well as thoroughly testing input and output > of read/write commands. > > -Zac Brown > > > ------------------------------------------------------------------------ > > From d2a3cbaf6d71c3b0bcfa39afcf854de7e5daa5bb Mon Sep 17 00:00:00 2001 > From: Zac Brown <zac(a)zacbrown.org> > Date: Thu, 29 May 2008 13:34:50 -0700 > Subject: [PATCH] Strengthen current tests and add new tests for asynchronous I/O. > > --- > dlls/ntdll/tests/file.c | 103 ++++++++++++++++++++++++++++++++++++----------- > 1 files changed, 79 insertions(+), 24 deletions(-) > > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index d824530..e3cbf77 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -2,6 +2,7 @@ > * > * Copyright 2007 Jeff Latimer > * Copyright 2007 Andrey Turkin > + * Copyright 2008 Google (Zac Brown) > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -65,6 +66,7 @@ static inline BOOL is_signaled( HANDLE obj ) > } > > #define PIPENAME "\\\\.\\pipe\\ntdll_tests_file.c" > +#define TEST_BUF_LEN 10 > > static BOOL create_pipe( HANDLE *read, HANDLE *write, ULONG flags, ULONG size ) > { > @@ -114,7 +116,10 @@ static BOOL get_msg(HANDLE h) > { > LARGE_INTEGER timeout = {{-10000000*3}}; > DWORD res = pNtRemoveIoCompletion( h, &completionKey, &completionValue, &ioSb, &timeout); > - ok( res == STATUS_SUCCESS, "NtRemoveIoCompletion failed: %x\n", res ); > + if (res == STATUS_TIMEOUT) > + ok( res == STATUS_TIMEOUT, "NtRemoveIoCompletion should have timed out, got: %x\n", res ); > + else > + ok( res == STATUS_SUCCESS, "NtRemoveIoCompletion failed: %x\n", res ); > if (res != STATUS_SUCCESS) > { > completionKey = completionValue = 0; > @@ -507,6 +512,7 @@ static void test_iocp_fileio(HANDLE h) > FILE_COMPLETION_INFORMATION fci = {h, CKEY_SECOND}; > HANDLE hPipeSrv, hPipeClt; > NTSTATUS res; > + BOOL rw_res; > > hPipeSrv = CreateNamedPipeA( pipe_name, PIPE_ACCESS_INBOUND, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, 4, 1024, 1024, 1000, NULL ); > ok( hPipeSrv != INVALID_HANDLE_VALUE, "Cannot create named pipe\n" ); > @@ -533,49 +539,97 @@ static void test_iocp_fileio(HANDLE h) > if (hPipeClt != INVALID_HANDLE_VALUE) > { > OVERLAPPED o = {0,}; > - BYTE buf[3]; > + BYTE buf_send[TEST_BUF_LEN]; > + BYTE buf_rcv[TEST_BUF_LEN]; > DWORD read; > long count; > + unsigned int i; > > NTSTATUS res = pNtSetInformationFile( hPipeSrv, &iosb, &fci, sizeof(fci), FileCompletionInformation ); > ok( res == STATUS_SUCCESS, "NtSetInformationFile failed: %x\n", res ); > ok( U(iosb).Status == STATUS_SUCCESS, "iosb.Status invalid: %x\n", U(iosb).Status ); > > - count = get_pending_msgs(h); > - ok( !count, "Unexpected msg count: %ld\n", count ); > - ReadFile( hPipeSrv, buf, 3, &read, &o); > - count = get_pending_msgs(h); > - ok( !count, "Unexpected msg count: %ld\n", count ); > - WriteFile( hPipeClt, buf, 3, &read, NULL ); > - > - if (get_msg(h)) > + /* Try messages of differing lengths and values, checking that they match. */ > + for( i = 1; i < 10; i++ ) > { > - ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > - ok( ioSb.Information == 3, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > - ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: %x\n", U(ioSb).Status); > - ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: %lx\n", completionValue ); > + memset( buf_send, 0, TEST_BUF_LEN ); > + memset( buf_rcv, 0, TEST_BUF_LEN ); > + memset( buf_send, i, i ); > + > + /* Try reading before writing */ > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + rw_res = ReadFile( hPipeSrv, buf_rcv, i, &read, &o ); > + ok( rw_res == FALSE, "Unexpected success of ReadFile\n" ); > + ok( GetLastError() == ERROR_IO_PENDING, "Expected error of ERROR_IO_PENDING, got %d\n", GetLastError() ); > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + rw_res = WriteFile( hPipeClt, buf_send, i, &read, NULL ); > + ok( rw_res == TRUE, "Unexpected fail of WriteFile\n" ); > + if (get_msg(h)) > + { > + ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > + ok( ioSb.Information == i, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > + ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: %x\n", U(ioSb).Status); > + ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: %lx\n", completionValue ); > + ok( !memcmp( buf_send, buf_rcv, TEST_BUF_LEN ), "Receive buffer (%x %x %x) did not match send buffer (%x %x %x)\n", > + buf_rcv[0], buf_rcv[1], buf_rcv[2], buf_send[0], buf_send[1], buf_send[2] ); > + } > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + > + /* Try writing before reading */ > + rw_res = WriteFile( hPipeClt, buf_send, i, &read, NULL ); > + ok( rw_res == TRUE, "Unexpected fail of WriteFile\n" ); > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + rw_res = ReadFile( hPipeSrv, buf_rcv, i, &read, &o ); > + ok( rw_res == TRUE, "Unexpected fail of ReadFile\n" ); > + if (get_msg(h)) > + { > + ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > + ok( ioSb.Information == i, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > + ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: %x\n", U(ioSb).Status); > + ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: %lx\n", completionValue ); > + ok( !memcmp( buf_send, buf_rcv, TEST_BUF_LEN ), "Receive buffer (%x %x %x) did not match send buffer (%x %x %x)\n", > + buf_rcv[0], buf_rcv[1], buf_rcv[2], buf_send[0], buf_send[1], buf_send[2] ); > + } > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > } > - count = get_pending_msgs(h); > - ok( !count, "Unexpected msg count: %ld\n", count ); > > - WriteFile( hPipeClt, buf, 2, &read, NULL ); > + /* Try sending a message of length zero. */ > count = get_pending_msgs(h); > ok( !count, "Unexpected msg count: %ld\n", count ); > - ReadFile( hPipeSrv, buf, 2, &read, &o); > + rw_res = WriteFile( hPipeClt, buf_send, 0, &read, NULL ); > + ok( rw_res == TRUE, "Unexpected fail of WriteFile\n" ); > count = get_pending_msgs(h); > - ok( count == 1, "Unexpected msg count: %ld\n", count ); > + ok( !count, "Unexpected msg count: %ld\n", count ); > + rw_res = ReadFile( hPipeSrv, buf_rcv, TEST_BUF_LEN, &read, &o ); > + /* This passes on XP but not in wine. */ > + todo_wine ok( rw_res == TRUE, "Unexpected fail of ReadFile\n" ); > if (get_msg(h)) > { > ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > - ok( ioSb.Information == 2, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > + ok( ioSb.Information == 0, "Invalid ioSb.Information: %ld\n", ioSb.Information ); > ok( U(ioSb).Status == STATUS_SUCCESS, "Invalid ioSb.Status: %x\n", U(ioSb).Status); > ok( completionValue == (ULONG_PTR)&o, "Invalid completion value: %lx\n", completionValue ); > } > + count = get_pending_msgs(h); > + ok( !count, "Unexpected msg count: %ld\n", count ); > > - ReadFile( hPipeSrv, buf, sizeof(buf), &read, &o); > - CloseHandle( hPipeSrv ); > + rw_res = ReadFile( hPipeSrv, buf_rcv, TEST_BUF_LEN, &read, &o); > + ok( rw_res == FALSE, "Unexpected success of ReadFile\n" ); > + ok( GetLastError() == ERROR_IO_PENDING, "Expected error of ERROR_IO_PENDING, got %d\n", GetLastError() ); > + rw_res = CloseHandle( hPipeSrv ); > + ok( rw_res == TRUE, "Unexpected fail of CloseHandle\n" ); > count = get_pending_msgs(h); > - ok( count == 1, "Unexpected msg count: %ld\n", count ); > + /* > + * Wine reports 1 extra message. This is probably due to the server > + * reporting that a message is in the queue from sending an empty message above. > + * The offending code is suspected to be in ntdll/file.c in the NtReadFile function. > + */ > + todo_wine ok( count == 1, "Unexpected msg count: %ld\n", count ); > if (get_msg(h)) > { > ok( completionKey == CKEY_SECOND, "Invalid completion key: %lx\n", completionKey ); > @@ -586,7 +640,8 @@ static void test_iocp_fileio(HANDLE h) > } > } > > - CloseHandle( hPipeClt ); > + rw_res = CloseHandle( hPipeClt ); > + ok( rw_res == TRUE, "Unexpected fail of CloseHandle\n" ); > } > > static void test_iocompletion(void) > > > ------------------------------------------------------------------------ > >

1 0

uninformed musings on ddraw + bugs 2082 and 1347 + dib engine
by Vincent Povirk 29 May '08

29 May '08

I apologize if what I'm about to say is wrong and useless. I feel the need to say it just in case it is not as wrong and useless as I fear. Background: We have two very difficult (possibly unfixable) ddraw bugs: http://bugs.winehq.org/show_bug.cgi?id=2082 - DirectDraw games only showing black screen http://bugs.winehq.org/show_bug.cgi?id=1347 - Screen is wiped/blanked on usage of DirectDraw Both of these bugs are the result of the fact that Windows (probably even Windows Vista when Aero is disabled, which I believe happens temporarily when an exclusive move ddraw app is active) ddraw can give apps direct access to the screen and X cannot. Instead of drawing to the screen, Wine draws to the application's window, which it determines based on an argument the application passed to SetCooperativeLevel. In the case of 2082, this window is obscured and no drawing happens even though it would on windows. There is a hack for ddraw that uses hwnd 0 instead (so drawing operations do go to the screen), but it can also break things in situations where an application uses both ddraw and gdi. 1347 is the result of non-fullscreen applications passing hwnd 0 to SetCooperativeLevel and (so I'm told) going through this series of steps: 1. Lock the primary surface, thus mapping the image on the screen to memory. 2. Write to your window. 3. Unlock the primary surface. On Windows, as long as Aero isn't running, this works out fine. But on Wine, mapping the image on the screen to memory is impossible. Instead, Wine simply gives the app an empty buffer, which the app writes to (but only its own window). It is impossible to determine afterwards which parts of the that buffer were written. When the primary surface is unlocked, Wine draws the image in the buffer to the application's SCL window, which is often (but not always) what the application happened to be drawing. Stefan mentions the idea of grabbing a screenshot when the surface is locked and writing it back when the surface is unlocked (which he says in one case would cause framerate to drop to less than 1 fps, which I believe). He thinks 1347 is unfixable. I think that if so, 2082 is also unfixable because even in fullscreen mode we can have problems caused by interactions with ddraw and gdi (using hwnd 0 is not always the right thing even for a fullscreen app). Now, here's where we get to the crazy uninformed ideas: What if, instead of picking one hwnd to draw to, ddraw drew to every window owned by an application? I'm making some assumptions here: it has to be possible to find the space occupied by "every window owned by an application" and draw to it at a reasonable speed. I'm also assuming that no app we want to support will want to draw to windows owned by other programs, especially X programs, even though there's nothing in ddraw that would prevent it. Well, we'd still theoretically have some problems. What if a program locked/unlocked the primary surface multiple times, once for each of various widgets that it wants to draw? The widgets would flicker. And what if a program has its own window that it wants to draw to with gdi? Its gdi parts would be painted black. Alright then, what if we had a single clientside buffer per app, the size and depth (as far as the app is concerned) of the screen, that was not synced with the actual contents of the screen but was preserved between locks/unlocks? Any operation in ddraw or gdi that resulted in a draw to the screen would have to first go through this buffer. The lock/unlock sequence would overdraw all the application's windows with the last thing the application drew there. Ignoring opengl (opengl and ddraw working simultaneously in one process should be extremely rare; maybe some swing apps do it), that should work pretty much perfectly. Sadly I can't even pretend to know enough to say how this affects opengl. It would require clientside buffers, and it would probably be difficult for current gdi to support. It seems like the sort of thing that would be more reasonable if we had a dib engine. (!) Also, giving every process a clientside buffer the size of the screen would be wasteful of memory (and optimizing for a rare case; most programs won't even have a primary surface, let along be locking/unlocking it). It may be more reasonable to have one per visible window or even one per X window, which would be manipulated as needed for lock/unlock (not sure about the X window thing because they'd have to be shared between processes.. but perhaps we need that capability anyway? it would also effectively mean we CAN give apps direct access to the screen for virtual desktops and CAN allow ddraw drawing to other Wine processes' windows). -- Vincent Povirk

6 8

← Newer
1
2
3
4
5
6
7
...
26
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2008