September 2009 - Wine-Devel

help with dwBackBufferCount in backbuffer surfaces needed

by Markus Stockhausen

Hi, currently I'm investigating bug 1660 and hopefully I found the reason for the misbehaviour. The only problem is, that I do not know what results I have to expect in windows. So it would be very helpful if someone can execute the attached testcase in a native environment so that I can fix the error condition and send in the final patch. The idea is that backbuffer surfaces have dwBackBufferCount=0 in Windows but on Wine they get the same count as the primary surface. The test will fail in Windows and Wine to get the results in both cases. The result will show like this: dsurface.c:1264: Test failed: backbuffer surface has dwBackBufferCount==2 Thanks for your help in advance. Markus

Sept. 29, 2009

Re: wininet(1/3): Only initialize SSL_CTX once

by Hans Leidekker

Hi Juan, > These patches collectively fix bug 18364, which was a crash in OpenSSL > in a multithreaded app (utorrent.exe.) The bug reporter sees long delays between torrents starting up after applying these patches, which makes we wonder if the ssl lock effectively serializes secure https requests? Would patch 1 and 3 not be sufficient to fix the utorrent crash? -Hans

Sept. 29, 2009

Re: Modifying Subsystem in Winelib executables

by Paul Vriens

On 09/29/2009 12:11 PM, Greg Geldorp wrote: > To fix one of the tests (shell32:shlexec) I'd like to copy the test executable > and change the Subsystem type from IMAGE_SUBSYSTEM_WINDOWS_CUI (console app) to > IMAGE_SUBSYSTEM_WINDOWS_GUI (GUI app) in the copy. Piece of cake for PE files, > get the IMAGE_DOS_HEADER, follow it to the IMAGE_NT_HEADERS and just patch the > OptionalHeaders.Subsystem field. > My limited understanding of the structure of Winelib executables makes doing > the same for testing on Wine quite a bit harder. I assume there's still a > IMAGE_NT_HEADERS structure in there somewhere and with some research I'll > probably be able to locate it in Linux ELF Winelib executables. What I'm > wondering about is how big the can of worms I'm trying to open is? Is the > encapsulation of PE headers in "native" executables the same for all OSes > supported by Wine? Is changing a PE header field in (a copy of) a Winelib > executable doomed to fail or is it a walk in the park? > > Ge. > > Can't we just compile shell32 tests as a GUI app? What other changes are needed to fix the errors on Vista+? (I know that we have popups now) -- Cheers, Paul.

Sept. 29, 2009

Re: Modifying Subsystem in Winelib executables

by Alexandre Julliard

Greg Geldorp <ggeldorp(a)vmware.com> writes: > My limited understanding of the structure of Winelib executables makes doing > the same for testing on Wine quite a bit harder. I assume there's still a > IMAGE_NT_HEADERS structure in there somewhere and with some research I'll > probably be able to locate it in Linux ELF Winelib executables. What I'm > wondering about is how big the can of worms I'm trying to open is? Is the > encapsulation of PE headers in "native" executables the same for all OSes > supported by Wine? Is changing a PE header field in (a copy of) a Winelib > executable doomed to fail or is it a walk in the park? It's doomed to fail, don't try that. If you need a specific format PE file generate one from scratch, don't try to modify an existing one. -- Alexandre Julliard julliard(a)winehq.org

Sept. 29, 2009

Re: [PATCH 10/10] add tests for SHOpenRegStream2A and SHCreateMemStream

by Alexandre Julliard

Peter Oberndorfer <kumbayo84(a)arcor.de> writes: > +#define test_streamsize(stream, size) \ > +{ \ > + STATSTG stat; \ > + HRESULT result; \ > + result = IStream_Stat(stream, &stat, STATFLAG_NONAME); \ > + ok(result == S_OK, "IStream::Stat failed %08x\n", result); \ > + ok(stat.cbSize.QuadPart == size, "Stat size wrong\n"); \ > +} > + > +#define test_value_type(name, wantedtype) \ > +{ \ > + LONG retval; \ > + DWORD type; \ > + retval = RegQueryValueExA(hBaseKey, name, NULL, &type, NULL, NULL); \ > + ok(retval == ERROR_SUCCESS, "RegQueryValueExA should succeed, error %d\n", retval); \ > + ok(type == wantedtype, "type of key wrong. wanted %d, got %d\n", wantedtype, type); \ > +} > + > +#define test_value_not_exist(name) \ > +{ \ > + LONG retval; \ > + retval = RegQueryValueExA(hBaseKey, name, NULL, NULL, NULL, NULL); \ > + ok(retval == ERROR_FILE_NOT_FOUND, "RegQueryValueExA returned wrong error %d\n", retval); \ > +} > + > +/* older versions (Win98) seem broken, they do not delete the key on close when it is empty */ > +#define test_value_type_broken(name, wantedtype) \ > +{ \ > + LONG retval; \ > + DWORD type; \ > + retval = RegQueryValueExA(hBaseKey, name, NULL, &type, NULL, NULL); \ > + ok(retval == ERROR_SUCCESS, "RegQueryValueExA should succeed, error %d\n", retval); \ > + ok(type == wantedtype || broken(type != wantedtype), "type of key wrong. wanted %d, got %d\n", wantedtype, type); \ > +} > + > +#define test_value_not_exist_broken(name) \ > +{ \ > + LONG retval; \ > + retval = RegQueryValueExA(hBaseKey, name, NULL, NULL, NULL, NULL); \ > + ok((retval == ERROR_FILE_NOT_FOUND) || broken(retval == ERROR_SUCCESS), \ > + "RegQueryValueExA returned wrong error %d\n", retval); \ > +} Please avoid hiding the code inside macros. When you have only a couple of lines just spell things out explicitly. For larger things write an inline function. -- Alexandre Julliard julliard(a)winehq.org

Sept. 29, 2009

Re: [PATCH 02/15] comctl32/monthcal: Make tests not depend from each other

by Nikolay Sivov

Paul Vriens wrote: > On 09/27/2009 07:51 PM, Nikolay Sivov wrote: >> Changelog: >> - Inependent tests are always better and more scalable. >> >> >> ------------------------------------------------------------------------ >> >> > Hi Nikolay, > > This one seems (there were more for monthcal.c) to have introduced 2 > test failures on a lot of boxes. The only reason I see (from the logs > on test.winehq.org) is that the failing boxes don't run the English > locale. > > Any idea? > You're right, it's about first week day set. I already have a patch for that, tested on Ge's boxes. Will submit with today bunch, thanks.

Sept. 29, 2009

Modifying Subsystem in Winelib executables

by Greg Geldorp

To fix one of the tests (shell32:shlexec) I'd like to copy the test executable and change the Subsystem type from IMAGE_SUBSYSTEM_WINDOWS_CUI (console app) to IMAGE_SUBSYSTEM_WINDOWS_GUI (GUI app) in the copy. Piece of cake for PE files, get the IMAGE_DOS_HEADER, follow it to the IMAGE_NT_HEADERS and just patch the OptionalHeaders.Subsystem field. My limited understanding of the structure of Winelib executables makes doing the same for testing on Wine quite a bit harder. I assume there's still a IMAGE_NT_HEADERS structure in there somewhere and with some research I'll probably be able to locate it in Linux ELF Winelib executables. What I'm wondering about is how big the can of worms I'm trying to open is? Is the encapsulation of PE headers in "native" executables the same for all OSes supported by Wine? Is changing a PE header field in (a copy of) a Winelib executable doomed to fail or is it a walk in the park? Ge.

Sept. 29, 2009

Re: [PATCH 02/15] comctl32/monthcal: Make tests not depend from each other

by Paul Vriens

On 09/27/2009 07:51 PM, Nikolay Sivov wrote: > Changelog: > - Inependent tests are always better and more scalable. > > > ------------------------------------------------------------------------ > > Hi Nikolay, This one seems (there were more for monthcal.c) to have introduced 2 test failures on a lot of boxes. The only reason I see (from the logs on test.winehq.org) is that the failing boxes don't run the English locale. Any idea? -- Cheers, Paul.

Sept. 29, 2009

Re: RFC: Sharing a wineprefix

by Francois Gouget

On Sat, 26 Sep 2009, Paul Chitescu wrote: [...] > What you're proposing here is essentially an overlay file system. [...] > You should also know that any such simplistic approach can fail in interesting > and hardly to debug ways unless the user's prefix is wiped (which you already > noted) which is unacceptable in most scenarios. Here's a nice reference on the traps awaiting anyone who wants to write a union filesystem: http://lwn.net/Articles/324291/ Also note that in the case of Wine a union filesystem does not solve the problem of the registry since it would not know how to merge the content of the administrator's and the user's system.reg files. So to make the unioning complete we would need a union registry too (or make each registry key and value into its own directory/file!). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

Sept. 29, 2009

Re: programs: add extrac32 tool

by Andrey Turkin

extrac32 is not a console program; on Windows it doesn't create a console and doesn't write anything to stdout or stderr regardless of command line. I agree those FIXMEs you pointed out are not FIXMEs really - some of them are errors and some should be warnings. I'll fix them. Kirill K. Smirnov wrote: > Hi, > > +int PASCAL wWinMain ( HINSTANCE hInstance, HINSTANCE prev, LPWSTR cmdline, > int show ) > +{ > extrac32 is a console application, isn't it? Why not wmain() instead? And get > rid of rather complex ParseCmdLine(). > > + if (!SetupIterateCabinetW( pszCabFile, 0, (PSP_FILE_CALLBACK) > ExtCabCallback, 0 )) > + WINE_FIXME( "Can not extract cab file:%s!!!\n", wine_dbgstr_w( > pszCabFile ) ); > This is an error, not a FIXME > > + if(!argv) > + { > + WINE_FIXME("Error!Can not get cmd line\n" ); > + return 0; > + } > not a FIXME > > + if (argc < 2) > + { > + WINE_FIXME( "No options\n" ); > + return 1; > + } > not a FIXME > > + if (fArgc != 1) > + WINE_FIXME( "Invalid usage for /C flag - two filenames > expected\n" ); > not a FIXME > > -- > Kirill > >

Sept. 29, 2009