February 2009 - Wine-Devel - list.winehq.org

Re: wine honor roll slashdotted

by Luke Benstead

2009/2/3 James Mckenzie <jjmckenzie51(a)earthlink.net>: > Dan Kegel <dank(a)kegel.com> wrote: >>Sent: Feb 3, 2009 6:48 AM >>To: Wine Devel <wine-devel(a)winehq.org> >>Subject: wine honor roll slashdotted >> >>http://tech.slashdot.org/article.pl?sid=09/02/03/0112249 >> >>One comment mentions the grade inflation on the appdb, >>i.e. platinum apps that have not been thoroughly tested >>or don't really qualify as platinum... >> > Dan: > > Sadly, I agree with the grade inflation. We need a grading interface that will generate whether or not an application is Plat/Gold/Silver/Bronze/Garbage based upon user input. This usually stops the inflation. > > James McKenzie > > > Perhaps, the grading should be separate from the test result submissions? I know a few times I've run a program under Wine and then only later looked up the entry on the appdb, by that stage I might not even be on the same PC, or have the time to submit a full test result, but I'd have a pretty good idea how I would rate it. It would be good if logged in users could just quickly say "Yes, I would give this gold status" then the final grade could be the average of the votes. Luke.

Feb. 3, 2009

Re: wine honor roll slashdotted

by James Mckenzie

Dan Kegel <dank(a)kegel.com> wrote: >Sent: Feb 3, 2009 6:48 AM >To: Wine Devel <wine-devel(a)winehq.org> >Subject: wine honor roll slashdotted > >http://tech.slashdot.org/article.pl?sid=09/02/03/0112249 > >One comment mentions the grade inflation on the appdb, >i.e. platinum apps that have not been thoroughly tested >or don't really qualify as platinum... > Dan: Sadly, I agree with the grade inflation. We need a grading interface that will generate whether or not an application is Plat/Gold/Silver/Bronze/Garbage based upon user input. This usually stops the inflation. James McKenzie

Feb. 3, 2009

Re: winedos: Improve PIT emulation.

by Alexandre Julliard

Florian Tobias Schandinat <FlorianSchandinat(a)gmx.de> writes: > + /* Convert: time counter -> PIT counter > + * GetSystemTimeAsFileTime: 10000000 Hz > + * PIT frequency: 1193182 Hz */ > + val = (DWORD)(val - delta*1193182./10000000.) % (maxval + 1); You should probably use QueryPerformanceCounter as it already uses the correct frequency. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2009

wine honor roll slashdotted

by Dan Kegel

http://tech.slashdot.org/article.pl?sid=09/02/03/0112249 One comment mentions the grade inflation on the appdb, i.e. platinum apps that have not been thoroughly tested or don't really qualify as platinum...

Feb. 3, 2009

Re: d3d9/tests : LockRect acquires the lock if D3DLOCK_NOSYSLOCK is not specified.

by Stefan Dösinger

Am Montag, 2. Februar 2009 11:08:09 schrieb Jérôme Gardou: > Forget this one please. Still an interesting test. I'll keep that one in mind if I'm hunting strange race conditions. Maybe this helps the deadlock in the Call of Duty 2 intro videos

Feb. 3, 2009

ideas and questions for implementation of MessageMode in Named Pipes

by Luke Kenneth Casson Leighton

ok, alexandre: i tried moving named_pipe_read into wineserver - it's not possible to do completely, as you cannot do blocking-reads in wineserver but you still need blocking-read characteristics in the client (kernel32, ntdll). if you start messing with the fd, setting or clearing ioctl O_NONBLOCK in one, it interferes with the other. there's a race-condition risk. so, i have some ideas and questions. 1) is it possible for wineserver to tell a thread to wait indefinitely? is there a communication channel where wineserver can tell "anyone who's interested" to go away, go to sleep, i'll tell you when to wake up"? what i want is to replace the fd blocking-read with something that still blocks, but doesn't interfere with the file descriptor. 2) would a _second_ filedescriptor fit the required criteria, as described in 1), above? in other words, if the message-lengths (4 bytes) were sent on a secondary control fd - and nothing _but_ message-lengths were sent on that fd - my intuition tells me that that could work, even without having any infrastructure in wineserver. in fact, i get the feeling that it would be _better_ - and a lot simpler - than having any infrastructure in wineserver. the reasoning goes roughly something like this: * 5 threads are waiting - blocking - on a message-mode read named pipe. all of them are blocking to read from the "control" channel, in userspace (kernel32/ntdll). * client 1 does a message-mode write, and in userspace (kernel32/ntdll) 4 bytes indicating the length of the message are sent, followed by N bytes on the unix_fd (exactly as is done at the moment). * one and ONLY one of the 5 threads, thanks to STANDARD linux kernel scheduling, happens to be awake and gets to read the 4-byte length. all the other 4 stay asleep. damnit, that's not right, is it. you want the other 4 to wake up once ONE of them has read the 4-byte length, and for ALL of them to move on to blocking on the "message" pipe - the actual content. so, i suppose what you could do is have a per-read-thread filedescriptor (!!!) which _would_ have to involve arbitration by wineserver, so that when a write is performed, ALL of the clients get notified "wake up now, start trying to read". is there _anything_ in wine which already exists that does what is required, as illustrated, above? answers and information greatly appreciated so as to be able to improve this free software project's effectiveness. l.

Feb. 3, 2009

[winetest] Make sure we can test .NET dlls on Windows (need some advice)

by Paul Vriens

Hi, Sent to wine-devel so I don't jeopardize my rating too much ;) .NET dlls cannot be found with the existing logic in winetest, mainly because they are not in the search path. If the normal loading of a dll fails we now check against a fixed set of names (fusion only for now). If it's a .NET dll we check if this one is there (according to .NET's mscoree) and get the file information. We can use to existing version checking stuff for that part as it's a normal dll. Remarks, suggestions? Changelog Make sure we can test .NET dlls on Windows -- Cheers, Paul.

Feb. 3, 2009

Re: DIB Engine - Patchset separated by original author

by Jesse Allen

On Sun, Feb 1, 2009 at 9:29 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > As asked to me, I have separated the dib engine into a patchset, trying to > keep (when possible) the original author's submissions, so Huw Davies, Jesse > Allen and me. > I had to change some of other author's commits in order to fit my engine and > to rebase it on 1.1.14, so I ask both previous authors to check if they > agree on the patches. > > I hope this will help the review, as keeping it rebased on wine tree will > become quite hard having it as a separated patchset. > > Attached here is a zipped patchset, which apply on wine 1.1.14. > > Ciao > > Max > > > > Hello, I have placed the patches unchanged onto this git page: http://repo.or.cz/w/wine/dibdrv-max.git Hope this helps. Jesse

Feb. 3, 2009

Re: ntdll: add a warning about running wine as root (try 2)

by Austin English

On Mon, Feb 2, 2009 at 8:27 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > The patch does not apply to current master. > > Vincent Povirk > > > > On Mon, Feb 2, 2009 at 8:01 PM, Austin English <austinenglish(a)gmail.com> wrote: >> Been seeing it quite a bit recently in the forums. While the patches >> to break using sudo/su have helped a bit, seems some users are >> convinced they need to run wine as root. This adds a non fatal >> message, so no functionality is lost for those that _do_ need to run >> as root. >> >> Try 2: >> Made warning a bit more verbose. Changed geteuid to getuid, since we >> already check for that function, and geteuid is a bit is superfluous, >> since sudo should already be prevented. >> >> -- >> -Austin >> >> >> >> > > > Thanks. Killed my hard drive this morning, so edited previous diff rather than making a new one. Resending a fresh one now. -- -Austin

Feb. 3, 2009

Re: ntdll: add a warning about running wine as root (try 2)

by Vincent Povirk

The patch does not apply to current master. Vincent Povirk On Mon, Feb 2, 2009 at 8:01 PM, Austin English <austinenglish(a)gmail.com> wrote: > Been seeing it quite a bit recently in the forums. While the patches > to break using sudo/su have helped a bit, seems some users are > convinced they need to run wine as root. This adds a non fatal > message, so no functionality is lost for those that _do_ need to run > as root. > > Try 2: > Made warning a bit more verbose. Changed geteuid to getuid, since we > already check for that function, and geteuid is a bit is superfluous, > since sudo should already be prevented. > > -- > -Austin > > > >

Feb. 3, 2009