March 2014 - Wine-Devel - list.winehq.org

Re: riched20/tests: Add tests for ITextDocument::Open about dealing with rtf.

by Alexandre Julliard

Jactry Zeng <jactry92(a)gmail.com> writes: > From 4b124d86198a9ed553a5f6cfd924584769495a1f Mon Sep 17 00:00:00 2001 > From: Jactry Zeng <jactry92(a)gmail.com> > Date: Sat, 15 Mar 2014 00:39:57 +0800 > Subject: riched20/tests: Add tests for ITextDocument::Open about dealing with > rtf. > > --- > dlls/riched20/tests/richole.c | 70 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 70 insertions(+) It doesn't work: ../../../tools/runtest -q -P wine -T ../../.. -M riched20.dll -p riched20_test.exe.so richole && touch richole.ok richole.c:445: Test failed: ITextDocument_Open: Should return an ERROR_HANDLE_EOF error. make[1]: *** [richole.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

March 17, 2014

Re: how to build wine with USB support ?

by Uwe Bonnes

>>>>> "Alois" == Alois Schlögl <alois.schloegl(a)gmail.com> writes: Alois> In one case, HKLM\System\CurrentControlSet\Services\<driver name> Alois> points to system32\Driver\hidusb.sys; Can you show the exports of hidusb.sys? Maybe it is also a good candidate for a replacement dll. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

March 17, 2014

Re: FYI Re: wined3d_mutex

by Max Woodbury

On 03/17/2014 10:50 AM, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-03-17 15:30, schrieb Max TenEyck Woodbury: >> Well, at least as fine as native. Finer might be safer since there >> is little besides direct examination of the native execution stream >> (a big NONO!) that assures that all grain boundaries have been >> identified. > > An application may (inadvertently rather than knowingly) expect d3d to > block the execution of one of its threads and corrupt internal data if > we don't. Unless we don't know of any such case we don't have to copy > every stupid behavior native has, but there's also no point in being > extra clever about things when applications don't expect d3d to do that. > Yes, but it still might be 'better to err on the side of caution'... >> OK. I believe you, but exactly what kind of lock is it and how did >> you go about identifying it? The fact that 'we' hold it during the >> call backs is something that bothered me. I also noted that 'we' >> sometimes take it out twice which also makes me think its use is >> rather superficial. > > Something like this: > > event e1 = cleared, e2 = cleared; > IDirectDraw ddraw1, ddraw2; > > Thread 1: > { > Start thread 2; > Wait for event e1; > ddraw1->AddRef(); > Signal event e2; > return; > } > > Thread 2: > { > ddraw2->EnumSurfaces (callback); > callback: > { > Signal event e1; > Wait for event e2 - expect a timeout; > } > } > > The Addref call in thread 1 does not finish until the EnumSurfaces > callback finishes. Since the callback waits for e2 this pseudocode > deadlocks. The deadlock is detected by a timed out wait with a > reasonably large (e.g. 500ms) wait time. > > This deadlock even happens with two totally unrelated ddraw objects, > and functions that shouldn't need a lock like AddRef. (AddRef can just > be implemented using interlocked increment ops like in Wine.) > > Alexandre said there was no point in having such a test in the tree > unless we find an application that depends on the coarse locking > behavior. You can search wine-patches for the test, I think I > submitted it somewhen in late 2006 or 2007. > > The same can be done in d3d9, but the AddRef and Release methods of an > IUnknown * passed to SetPrivateData are the only case I know of where > those libraries call application code. I expect d3d9 to be better wrt > concurrency than ddraw. But it needs tests, not suspicions. > OK. that shows that there is such a lock, but it leaves the question of exactly what kind of lock it is open. If I remember correctly, there are three kinds: - Critical sections that can be entered multiple times by a thread without blocking but delays other threads, which is what wine uses. - Mutex locks that would block if the same thread tries to take it out a second time. - Read/write locks that can be taken out many times by many threads for reading, but only allow one writer which blocks further readers and waits for existing readers to finish. max

March 17, 2014

Re: how to build wine with USB support ?

by Uwe Bonnes

>>>>> "Alois" == Alois Schlögl <alois.schloegl(a)gmail.com> writes: ... Alois> Yes, I'd be interested in that one, too. https://github.com/UweBonnes/wine, branch ftd2xx. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

March 17, 2014

Re: how to build wine with USB support ?

by Alois Schlögl

On 2014-03-17 13:43, Uwe Bonnes wrote: >>>>>> "Alois" == Alois Schlögl <alois.schloegl(a)gmail.com> writes: > Alois> Hi I'm trying to use USB devices for Data acquisition on > Alois> wine. The recording software is proprietary, but runs on > Alois> wine. (It IgorPro with some binary called FPulse, and MultiClamp > Alois> Commander 700B). The problem occurs only when trying to connect > Alois> to the recording device through USB. > > How is the device accessed? Is it offering a serial device (comX)? Is it > perhaps using the FTDI device and the ftd2xx driver? Or is it > using an own kernel mode driver? In one case, HKLM\System\CurrentControlSet\Services\<driver name> points to system32\Driver\hidusb.sys; in the other case, no driver name is specified. It most likely uses a vendor specific interface - and its not an interface for a serial protocol. > > Only when using an own kernel mode driver, [1] is needed. I'm afraid there is no way around it. > > If it is a serial device, add the device to the wine configuration. If it is > using the ftd2xx driver, I can send you a patch to add a wine dll that > translates the windows ftd2xx calls to linux ftd2xx calls. Yes, I'd be interested in that one, too. > > Perhaps run a "WINEDEBUG=+relay log" to see how the device is accessed. > > Alois> I've already found the page [1] and trying to build wine with the > Alois> recommended patch. Unfortunately, the current patches [2] do not > Alois> apply cleanly to the most recent version of wine-git. Therefore, > Alois> I'm asking what the recommended approach is ? > > Alois> Is there a more recent set up patches ? The once from [2] have > Alois> been updated last in Jun 2012 ? Or would you recommend using the > Alois> sources of wine from that date ? > > Probably using a equal old wine would be best if you need [1]. > > Bye > Cheers, Alois

March 17, 2014

Re: kernel32: improve GetNumaHighestNodeNumber

by Matteo Bruni

2014-03-17 11:56 GMT+01:00 Austin English <austinenglish(a)gmail.com>: > Fixes https://bugs.winehq.org/show_bug.cgi?id=35596 > > -- > -Austin > > diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c > index 60156aa..86055d3 100644 > --- a/dlls/kernel32/process.c > +++ b/dlls/kernel32/process.c > @@ -3911,9 +3911,9 @@ HRESULT WINAPI RegisterApplicationRecoveryCallback(APPLICATION_RECOVERY_CALLBACK */ > BOOL WINAPI GetNumaHighestNodeNumber(PULONG highestnode) > { > - FIXME("(%p): stub\n", highestnode); > - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > - return FALSE; > + *highestnode = 0; > + WARN("(%p): semi-stub\n", highestnode); > + return TRUE; Not a big deal I guess but I don't think WARN is appropriate here, it should still be a FIXME IMO.

March 17, 2014

Application for GSoC 2014 - riched20: implement ITextDocument::Range and ITextRange

by Jactry Zeng

Hello folks, I am Jactry Zeng, a junior who majoring in Electronic Science from China. And also a very fresh developer of Wine. My nickname in #winehackers is jactry. :) I would like to apply for this year's GSoC to work for Wine. I have entered Wine's GSoC last year. What I have work for is ITextDocument, I implemented some functions of it. I got some experience of Wine development and fixed some other bugs[0] of richedit during that time. I continued the work of ITextDocument after GSoC, I know there is still a lot of work worth to do. Such as ITextDocument::Range[1], which is used to get an ITextRange object of the content. And functions of ITextRange[2] are used to operate this range of text. Now in Wine, ITextRange was implemented mix with ITextSelection[3][4]. And ITextDocument::GetSelection[5] which is used to get an ITextSelection object is similar to ITextRange. In an easy way, we can implement ITextDocument::Range using some cast (I have a dirty hack in attachment). But I don't think it is a permanent solution. There are four parts in my plan: --- Part 0: Do some COM cleanup. --- Because ITextRange is implemented mix with ITextSelection now, so we should do some COM cleanup to create an ITextRange interface independently. And create a ITextSelection interface inherits from ITextRange. This is just the preparatory work for implementing ITextRange and I will begin this part before GSoC. ( So it is signed as part zore :b ) --- Part 1: Implement ITextDocument::Range. --- I will write more tests for ITextDocument::Range and ITextDocument::GetSelection first. Than try to implement ITextDocumen::Range. When this part is finished, bug 12458[6] and bug 18303[7] will benefit from it. --- Part 2: Implement functions of ITextRange --- In this part, I will try my best to implement some functions of ITextRange. I will write some tests for them first and than implement them. I think this is the hard part. And these functions will be implemented preferentially: GetText, GetDuplicate, GetStar, GetEnd, Copy, SetText. Because GetDuplicate and GetEnd were needed by bug 18303, and these functions seem was depend on the others. After these functions were implemented, I think bug 18303 will be fixed! ( Oh, this one of my pursues! ;) ) --- Part 3: Imporve all the code for being merged by upstream. --- This is the last part, I will improve all the patches for being merged by upstream, including what I did last year. After this part is finished, Wine will really has an initial implementation of ITextDocument and ITextRange. Maybe it will spend a lot of time, and I will continue this work after GSoC if I can't finish all of this part during GSoC. I think after all these are finished not only bug 18303 and bug 12458 will benefit from it, but also many other softwares. Because TOM interfaces are so important and be used frequently in real world applications. I appreciate for any comment. Thank you. :) attachments: dirty hack of ITextDocument::Range: dirty_hack.txt patch 0001: tests for ITextDocument_Range [0] http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&am…<http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&s=jactry> [1] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774097(v=vs.85).a… [2] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774058(v=vs.85).a… [3] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774060(v=vs.85).a… [4] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/riched20/richole.c#l7… [5] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774013(v=vs.85).a… [6] http://bugs.winehq.org/show_bug.cgi?id=12458 [7] http://bugs.winehq.org/show_bug.cgi?id=18303 -- Regards, Jactry Zeng

March 17, 2014

Re: FYI Re: wined3d_mutex

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-03-17 15:30, schrieb Max TenEyck Woodbury: > Well, at least as fine as native. Finer might be safer since there > is little besides direct examination of the native execution stream > (a big NONO!) that assures that all grain boundaries have been > identified. An application may (inadvertently rather than knowingly) expect d3d to block the execution of one of its threads and corrupt internal data if we don't. Unless we don't know of any such case we don't have to copy every stupid behavior native has, but there's also no point in being extra clever about things when applications don't expect d3d to do that. > OK. I believe you, but exactly what kind of lock is it and how did > you go about identifying it? The fact that 'we' hold it during the > call backs is something that bothered me. I also noted that 'we' > sometimes take it out twice which also makes me think its use is > rather superficial. Something like this: event e1 = cleared, e2 = cleared; IDirectDraw ddraw1, ddraw2; Thread 1: { Start thread 2; Wait for event e1; ddraw1->AddRef(); Signal event e2; return; } Thread 2: { ddraw2->EnumSurfaces (callback); callback: { Signal event e1; Wait for event e2 - expect a timeout; } } The Addref call in thread 1 does not finish until the EnumSurfaces callback finishes. Since the callback waits for e2 this pseudocode deadlocks. The deadlock is detected by a timed out wait with a reasonably large (e.g. 500ms) wait time. This deadlock even happens with two totally unrelated ddraw objects, and functions that shouldn't need a lock like AddRef. (AddRef can just be implemented using interlocked increment ops like in Wine.) Alexandre said there was no point in having such a test in the tree unless we find an application that depends on the coarse locking behavior. You can search wine-patches for the test, I think I submitted it somewhen in late 2006 or 2007. The same can be done in d3d9, but the AddRef and Release methods of an IUnknown * passed to SetPrivateData are the only case I know of where those libraries call application code. I expect d3d9 to be better wrt concurrency than ddraw. But it needs tests, not suspicions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTJwuxAAoJEN0/YqbEcdMw1YIP/0VbBi/A0yRV9rRSNP9nncrl sul2ChIE0161Xk3o+9rBnH2DJCyt7a1kx6/AkhZqnhid8UNWFCQxbtDdMpP8w/pQ R1Q2nofj82AaQAJGoIxC7WgwzJAmwjchCO3RWzszpipORXHro5VWMqBT8ZeHrQrT Tt4hsEdzgfj5bwcM4V/ja0Nm78aM+mLbE6WJbFHoo/u+M0gnhuDCViBMS2TeT50h I3NmAJOu6fIvYdFEpgTQBqprAAR4KZbwWxcie2IzoMoc0qygSjpWDshIlBczxfhZ x3wwbH52EZi5+Mpa6BCsm3DWZ14SjXZ9chVegYcG1svkrDzP7xaQ3COKRRyHiv5o 40Vq4RU95GnZNLP8BYZDKqCgYd1a/tOTrpgyS+QPxTJEtTaKaXjxfSK7ApTQ9cbY LsQmhrdvpBxjX/YGZOmr5LbNJJ/fHFLKlBejBS24cB11ZTzptY1z6tnVNKQ2KAM6 pMSwj3R0DhehN4y1tQOWbSYwy3pi6K/OsziuX3MU17zcx5Haom6z7amV/OfRjwlX /IxVQjJ6v9K9xjkFk2ymTxcnp/WuKiZaHvN2SshQr63xFQKgsbVUMymcW/aNXkmc E9w9fjRcwM4ch+nmT7ifvQkHsnf7nuiBa9+bZe08QrkmPeBV8aAz1ysByyMXTsxc OndGfGOhTu+utYvrLkVt =WmQv -----END PGP SIGNATURE-----

March 17, 2014

Re: FYI Re: wined3d_mutex

by Max TenEyck Woodbury

On 03/17/2014 06:28 AM, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-03-15 21:17, schrieb Max TenEyck Woodbury: >> If anybody has an idea about what might be causing these delays, >> please tell me. > Sorry, no idea :-( . Maybe perf or oprofile show something. > OK. A new technique I probably need to learn. Please tell me about it. I was thinking that 'top' has some ability to monitor process wait states and I was going to start from there. >> Note that my review of the use of this mutex indicates that it is >> of very questionable value. In my opinion it should be replaced by >> a set of read/write locks built into the individual data >> structures. > > I have to give the infamous answers "it depends" and "this needs > tests". It's best to use the same lock granularity as native, > everything else is asking for trouble. > Well, at least as fine as native. Finer might be safer since there is little besides direct examination of the native execution stream (a big NONO!) that assures that all grain boundaries have been identified. > My very hacky testing suggests that native does not do any locking > unless D3DCREATE_MULTITHREADED is passed. Applications can still call > d3d from multiple threads without that flag, but then they have to do > their own locking. If they don't, the application crashes sooner > rather than later. > :-) > Ddraw has one global DLL lock. That can be demonstrated easily with > the various enum callbacks in the API. Native does not bother to > release the lock when calling the application callback. > OK. I believe you, but exactly what kind of lock is it and how did you go about identifying it? The fact that 'we' hold it during the call backs is something that bothered me. I also noted that 'we' sometimes take it out twice which also makes me think its use is rather superficial. > I suspect d3d8/9 has a per device lock, but I have not done any > testing to confirm this. IDirect3DResource9::SetPrivateData is your > ticket to finding out. It's the only way you can make native d3d8/9 > call your code (IUnknown::AddRef/Release, thanks to D3DSPD_IUNKNOWN). > Maybe Microsoft was careful enough to release the lock before calling > those methods, but I'd bet a beer that they weren't. > :-) No bet. Even good coders have a bit of trouble with that kind of thing, and while they do have some of those, they also have some of the other kind. > The other thing to consider wrt locking is the multithreaded command > stream. Some fields need synchronization. We can't use the wined3d > lock for that. My general goal is to avoid sharing resource / device / > whatever fields between the main and worker thread as much as > possible, and if I do (e.g. (sub)resource.locations) set up CS and > resource idle waits in such a way that the main thread knows no > command is scheduled or being executed while it operates on those > fields. Right now there are plenty of bugs in my preview code (e.g. > struct wined3d_buffer.flags). > I'm not sure I'm following this properly, particularly the part about the main thread knowing about commands scheduled on other threads... max

March 17, 2014

Re: Cross-regressions between wine and mesa: how to handle them?

by Henri Verbeet

On 17 March 2014 12:53, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > More than a month has passed since the bug report, and Mesa devs > haven't said anything. What should my further actions be? I suppose > some of the following: > The reality is probably that the Mesa (Intel) developers are pretty busy like everyone else, and i915 just isn't a very high priority. The correct approach to fixing these kinds of things is of course to fix the bug and send a patch, but that's often easier said than done. It may be possible to use MESA_EXTENSION_OVERRIDE="-GL_ARB_occlusion_query" as a workaround, but you'd have to test that.

March 17, 2014