March 2009 - Wine-devel - list.winehq.org

Re: [10/10] bcrypt: Add a mostly empty bcrypt.dll.
by Alexandre Julliard 27 Mar '09

27 Mar '09

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > diff --git a/dlls/bcrypt/bcrypt.spec b/dlls/bcrypt/bcrypt.spec > new file mode 100644 > index 0000000..e69de29 Please add stubs for the exported functions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: libwine: Only partially reserve memory beyond 0x80000000 on FreeBSD.
by Francois Gouget 27 Mar '09

27 Mar '09

Tijl Coosemans a écrit : > After enabling the memory reservation code on FreeBSD last week, > several games either suffer a performance loss or simply crash, often > with GL_OUT_OF_MEMORY errors or similar out of memory errors from X > libs. (Tested with nvidia driver and opensource r300 dri driver.) Which games can be used to reproduce this issue? Is one of them freely downloadable? Even better, can this issue be reproduced with a non-game application? Also, won't this patch be obsolete once Alexandre completes his current OpenGL memory allocation work? That is, doesn't it just hide the problem rather than solving it? > It also causes other problems like: > http://bugs.winehq.org/show_bug.cgi?id=17718 This bug mentions the following error: > Fatal error 'Cannot allocate red zone for initial thread' at line 384 > in file /usr/src/lib/libthr/thread/thr_init.c (errno = 2) It would be nice to figure out how we get in init_main_thread(). Apparently there are only two possible cases: * 1) Some thread routines have detected that the library hasn't yet * been initialized (_thr_initial == NULL && curthread == NULL), or * * 2) An explicit call to reinitialize after a fork (indicated * by curthread != NULL) I don't really understand why we would reallocate the stack in the first case so my guess is this happens through a fork. > This patch only partially reserves memory, enough for the shared heap, > virtual heap and wine top-down allocations, and leaves the majority > unreserved. Isn't the memory reservation supposed to prevent Unix libraries from being mapped in this memory range? If so, won't leaving holes open us to this sort of trouble again? Also, besides FreeBSD's braindead stack allocation routines, why should this patch only be used on FreeBSD? If it's supposed to help with OpenGL memory allocation then shouldn't it be used on Linux too (which has the same issue with OpenGL)? -- Francois Gouget fgouget(a)codeweavers.com

4 11

Re: wined3d: SetDepthStencilSurface is always called when AutoDepthStencil is enabled
by Henri Verbeet 27 Mar '09

27 Mar '09

2009/3/27 David Adam <david.adam.cnrs(a)gmail.com>: > Fixes bug 16846. > Could you include the test as well?

1 0

SOC 2009: Application Test Suite
by Austin English 27 Mar '09

27 Mar '09

Howdy, I'm planning on applying for Google Summer of Code 2009. I'm pretty sure most people reading this list already know me, but for those that don't, I frequently triage bugs in Bugzilla, help users on the forum, and a few other things. I've also done quite a bit of work testing wine on more obscure OS's (OpenSolaris, FreeBSD, OS X, NetBSD, OpenBSD). I'd like to implement an application test suite. It's something that's been discussed for Wine for quite a while, but has never been put into place. I took a bit of time a while back and hacked couple a couple quick scripts as a test, and got a script to automatically install Firefox 3 in Wine using AutoHotKey (http://www.autohotkey.com/) I've made a couple more scripts as well, but they don't match Windows behavior because of bug (http://bugs.winehq.org/show_bug.cgi?id=10147) hint, hint (disclaimer, I haven't tested that script in a while, been busy with exams, so that bug might be fixed...I don't think it has though). My plan to implement it is to make a script, that can be used standalone, in conjunction with Patchwatcher, or any other script, to test wine against several real world applications. I make a very quick proof of concept (attached), which is based off of winetricks. It's _REALLY_ rough at the moment, (I haven't had time to mess with it lately), but demonstrates the idea. The script setups a clean WINEPREFIX, installs autohotkey, removes the Z: symlink for braindead installers that search the entire hard drive, and sets up a link to it's install cache (essentially winetrickscache). From there, it makes a copy of this prefix, so on subsequent installers/applications, we can restore the clean prefix and save a few seconds. >From there, so far, it only installs firefox3. The plan is to add several dozen different tests, for various functions of wine. Obviously, I'd like to start with platinum rated applications, to prevent regressions. From there, the current list of applications/functions to target are: 1. Firefox3 - useful for testing lots of other things, e.g., java/flash, etc. Easy to test. 2. Microsoft Office - We've broken this a few times in recent months, so adding a test in daily git for it would help catch regressions sooner. 3. World of Warcraft - I don't play, but A) It's really popular, and B) also gives us a chance to test wininet for regressions. 4. iTunes - this installers been broken a couple times. The bonjour service should allow for testing services related regressions. 5. Adobe suite - there haven't been too many regressions here that I can remember, but it's definitely an area we should watch out for. Of course, we don't want to only test the installer's keystrokes/mouse inputs, so SHA1 checksumming of installed files would verify against corrupted files/setupapi regressions/etc. Once a few installer tests are in and working well, I plan to extend the tests further to test running the application, e.g, for photoshop by opening a file, inserting a circle, and saving it. This is a bit harder to pull off in Autohotkey in a way that's portable, so I'm saving that sort of thing for later. Also interesting would be a real application's test suite. Dan suggested using Google Chrome's, since it's squeaky clean after using lots of Valgrind and Purify. That would be good, but I'd put that after getting the test suite to pass in Wine. This should be very doable using Autohotkey's scripting functionality (pretty extensive - http://www.autohotkey.com/docs/Functions.htm, http://www.autohotkey.com/docs/Variables.htm) and good old fashioned shell scripting. I'm very familiar with bourne scripting, and currently maintain winetricks while Dan's taking a Wine vacation. I'm currently working on a build script to build Wine on several OS's, as well as running and submitting the conformance tests (http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh) [I got tired of maintaining the script over several different OS's/computers]. The upside is it would be easy to add on appinstall to this daily script. I typically set it running before leaving home for work/school. It spends an hour or so building wine and running the tests in a few different configurations. Adding appinstall would allow my computer to daily test several applications for installation, running, etc. This of course isn't as useful as Patchwatcher's testing of each single patch, but I don't currently have a spare machine that it can test on. Getting a script and tests ready to do so, however, would be great for Wine. Besides, I can easily setup the script to upload the results to a webserver, so we can daily see that each test is passing. If a test is failing, the information would then be publicly available for anyone to run 'git bisect'. Wow, this turned into a really long e-mail, and I've got an exam to study for. I'd appreciate any comments, and let me know if there are any questions. -- -Austin

7 12

Re: shell32: Implement IDD_MAKENEWFOLDER.
by Juan Lang 26 Mar '09

26 Mar '09

Hi John, a few problems with this one: -{ +{ This whitespace-only change isn't needed for your patch, please omit it. + if (info->pidlRet == NULL) + return FALSE; + { This is poor style, IMHO. Surely an explicit else would be better than the implicit else block here? + MessageBoxA( info->hwndTreeView, + "You cannot create a new folder here. Choose a different location.", + "Invalid location", MB_OK ); The indentation is off, please match the surrounding code. And, these should be in resources, not in English in the source. --Juan

1 0

IOCTL_DISK_GET_DRIVE_GEOMETRY in mountmgr.sys
by Michael Ost 26 Mar '09

26 Mar '09

Hi, The ioctl handler for IOCTL_DISK_GET_DRIVE_GEOMETRY on \\\\.\\c: in mountmgr.sys doesn't work. The call returns incorrect values that change at random intervals. Since the ioctl is defined as METHOD_BUFFERED I think it should be putting DRIVE_GEOMETRY data in IRP->AssociatedIrp.SystemBuffer. Instead the handler puts the data in IRP->MdlAddress.StartVa. Then process_ioctl in ntoskrnl.exe wipes out the output data with the random stuff in the allocated SystemBuffer. I am out of my depth with windows driver handling code, but a web search (http://www.cmkrnl.com/arc-ioctlbuf.html) says that SystemBuffer should be where the data is put. Indeed, when I change to SystemBuffer the user call to DeviceIoControl gets the right values back. Am I on the right track? Thanks, Michael Ost PS: here's a proposed patch... --- wine-1.1.7/dlls/mountmgr.sys/device.c.ORIG 2009-03-23 14:04:30.000000000 -0700 +++ wine-1.1.7/dlls/mountmgr.sys/device.c 2009-03-25 17:06:24.000000000 -0700 @@ -607,7 +607,7 @@ info.TracksPerCylinder = 255; info.SectorsPerTrack = 63; info.BytesPerSector = 512; - memcpy( irp->MdlAddress->StartVa, &info, len ); + memcpy( irp->AssociatedIrp.SystemBuffer, &info, len ); irp->IoStatus.Information = len; irp->IoStatus.u.Status = STATUS_SUCCESS; break;

1 1

Re: [6/10] wined3d: Simplify remove_vbos().
by Stefan Dösinger 26 Mar '09

26 Mar '09

Am Donnerstag, 26. März 2009 10:49:17 schrieb Henri Verbeet: Doesn't that mix up named and numbered attributes?

2 1

Re: [5/10] wined3d: Remove unused attributes from WineDirect3DVertexStridedData.
by Stefan Dösinger 26 Mar '09

26 Mar '09

Am Donnerstag, 26. März 2009 10:49:13 schrieb Henri Verbeet: I think position2 and normal2 are used with fixed function tweening. Should we remove it for now and readd it if we ever implement tweening in a vertex pipeline replacement?

2 1

Re: winex11.drv: SetDIBits fails when startscan != 0
by Alexandre Julliard 26 Mar '09

26 Mar '09

Massimo Del Fedele <max(a)veneto.com> writes: > diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c > index 6df4137..42d9082 100644 > --- a/dlls/winex11.drv/dib.c > +++ b/dlls/winex11.drv/dib.c > @@ -3927,6 +3927,7 @@ INT CDECL X11DRV_SetDIBits( X11DRV_PDEVICE *physDev, HBITMAP hbitmap, UINT start > X11DRV_DIB_IMAGEBITS_DESCR descr; > DIBSECTION ds; > LONG width, height, tmpheight; > + LONG widthBytes; > INT result; > > descr.physDev = physDev; > @@ -3936,6 +3937,7 @@ INT CDECL X11DRV_SetDIBits( X11DRV_PDEVICE *physDev, HBITMAP hbitmap, UINT start > if (DIB_GetBitmapInfo( &info->bmiHeader, &width, &height, > &descr.infoBpp, &descr.compression ) == -1) > return 0; > + widthBytes = ((width * descr.infoBpp +31) &~31) / 8; > > tmpheight = height; > if (height < 0) height = -height; > @@ -3977,7 +3979,7 @@ INT CDECL X11DRV_SetDIBits( X11DRV_PDEVICE *physDev, HBITMAP hbitmap, UINT start > default: break; > } > > - descr.bits = bits; > + descr.bits = (BYTE *)bits + widthBytes * (tmpheight > 0 ? (height - startscan - lines) : startscan); You shouldn't need to change the bits address. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [try 2]winex11.drv/dib.c - fix SetDIBits() for startscan != 0
by Massimo Del Fedele 26 Mar '09

26 Mar '09

Massimo Del Fedele ha scritto: > Changes from previous one : > bits shifting displaced from X11DRV_SetDIBits() to > X11DRV_DIB_SetImageBits() > Result is identical to former, the patch looks worse to me than before, > but.... > As a note, there's no way to leave 'descr->bits' untouched without > adding at least another > parameter (ySrc) to the bunch of X11DRV_DIB_SetImageBits_xxx() functions. > > Ciao > > Max > > > ------------------------------------------------------------------------ > > Please disregard this patch.... it's not correct on every case. Previous one was. I'll investigate a bit more about it. Ciao Max

1 0