April 2008 - Wine-Devel - list.winehq.org

Re: Documentation updating / XML?

by Francois Gouget

On Tue, 22 Apr 2008, Austin English wrote: [...] > On Tue, Apr 22, 2008 at 5:25 AM, Alexandre Julliard <julliard(a)winehq.org> > wrote: > > > "Austin English" <austinenglish(a)gmail.com> writes: > > > > > I've been working on some of the documentation, then remembered that > > > Scott requested a move to XML: > > > http://bugs.winehq.org/show_bug.cgi?id=12217 > > > > > > There are quite a few programs to convert SGML to XML, and I've got a > > > bit of time to kill. Alexandre, would you accept a move to XML, or > > > would this be a waste of time? [...] > Web/html/PDF/XML? I would vote for DocBook XML so we can get Html and PDF documents out of it. Also now po4a works quite well with it. I could give you a hand on the po4a part. However I'd say that there are some subtle but important differences between DocBook SGML and DocBook XML, especially around the include mechanism. So I'm a bit skeptical that automated tools can really produce clean DocBook XML code. But then they can probably be a good starting point. It would also be nice if we could switch to a Git repository. Since it's not possible with SourceForge it would mean moving elsewhere. Would it be possible to have get it hosted on winehq.org? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

April 30, 2008

Re: RFC: detecting wine drivers in the audio tests

by Robert Reif

Maarten Lankhorst wrote: > Hello Robert, > > 2008/4/29 Robert Reif <reif(a)earthlink.net>: > >> The returned result of some audio functions on windows may be inconsistent >> because a driver may actually supply the returned value. >> >> This presents a problem for the wine regression tests because a buggy >> driver may return an unexpected result which causes the test to fail. One >> way around this is to accept known failures as OK but that reduces the >> usefulness of the test for wine because it may allow wine bugs to slip in. >> I'm proposing the we determine if we are running on wine by defining a wine >> manufactures id and checking for that id in the test. If a wine driver is >> found, don't accept a failure as OK. The returned result should be well >> defined and any failure is unacceptable. However, if the driver is not a >> wine driver and there are known buggy windows drivers that return specific >> errors, we can check for that and not fail the test. This should be easier >> than maintaining a database of known broken drivers and black listing them. >> >> I am concerned that requiring 100% wine regression test success on windows >> is not practical when there are broken windows drivers out there. Accepting >> the failures as success is not good for wine because it may allow buggy wine >> drivers to also pass. I think we should hold wine audio drivers to higher >> standards than the typical audio card manufacture. >> >> I am suppling a minimal patch to the alsa driver and a single wave test to >> illustrate this concept. I hope this allows valid tests to remain in spite >> of buggy windows drivers. >> > I don't know, the general idea is that whatever windows lets you do is > fine for wine, so I'm not 100% sure that testing for this is a good > idea, because it means in border cases windows programs can't rely on > those to return a correct or incorrect value either. > > The point is to not throw out a valid test because on in a million PCs has a buggy sound driver. I doubt that any programs would rely on a bug being present to work properly. Particularly ignoring a specific failure code. > By the way you also used a C++ style comment, wine doesn't allow that. > > This is just an RFC. The example code is not ready for acceptance. Doing this right will require careful auditing of the test and I want to make sure this is reasonable before proceeding > Cheers, > Maarten > > > >

April 30, 2008

Re: hhctrl.ocx: Fix for memory release problem in ReleaseWebBrowser (fixes bug #12767)

by Tefnet Developers

Dnia 24-04-2008, czw o godzinie 12:48 +0200, Tomasz Jezierski - Tefnet pisze: > For more information check bug report. > Hi.. what's the status of this patch? I haven't found any comments on wine-devel about it.

April 30, 2008

Re: [Resend 2] user32: Post the WM_KEY{DOWN|UP} messagewhenWM_IME_KEY{DOWN|UP} message is generated by IME.

by Dmitry Timoshkov

"ByeongSik Jeon" <bsjeon(a)hanmail.net> wrote: > + while (TRUE) > + { > + if ( PeekMessage(&msg, 0, 0, 0, PM_REMOVE) ) > + { > + struct message posted_msg; > + > + msg_count++; > + > + trace("posted message[%d]: %p, %04x, %08lx, %08lx\n", > + msg_count, msg.hwnd, msg.message, msg.wParam, msg.lParam); > + > + posted_msg.message = msg.message; > + posted_msg.flags = posted|wparam|lparam; > + posted_msg.wParam = msg.wParam; > + posted_msg.lParam = msg.lParam; > + add_message(&posted_msg); > + > + TranslateMessage(&msg); > + DispatchMessage(&msg); > + > + if ( msg.message == WM_CHAR && msg.wParam == VK_RETURN ) > + break; > + } > + } You need to fetch all available messages, not just the selected ones. In order to do that replace 'while (TRUE)' loop by the 'while (PeekMeessage())' one, and as I pointed out earlier add_message() should be done only inside of the message proc. So the whole code above should be simplified to just while (PeekMeessage(&msg)) { TranslateMessage(&msg); DispatchMessage(&msg); } -- Dmitry.

April 30, 2008

Re: Switching threads in winedbg

by Eric Pouech

Maarten Lankhorst a écrit : > Hi all, > > I was trying to switch to a different thread in winedbg, however I > don't see any command for that in the winedbg online reference at > http://www.winehq.org/site/docs/winedev-guide/dbg-commands . Does > anyone know if it's possible? > > Cheers, > Maarten. > > > > > 'bt all' may help you as you'll get the backtrace of every thread of every process 'bt <tid>' will only show the backtrace of the thread of given <tid> 'info proc' gives you all the pid:s of the running processes in the system 'info thread' gives you all the pid:s and tid:s of the running processes and threads in the system as of today, you cannot "switch" to another thread A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 30, 2008

Re: wined3d: Fix for buggy programs using ortho matrix with no z range

by Stefan Dösinger

Am Mittwoch, 30. April 2008 07:21:19 schrieb Jens Albretsen: > A quick one is Lego Island, just forget to put in the disc a there is black > screen, with this patch is shows a message to put the cdrom in the drive. > > Is it something like this? > > create (1,1) rendertarget > clear rendertarget with black > setup ortho with no range > draw something with white > check rendertarget for any pixel drawn, if black test fails > or what? Take a look at dlls/d3d9/tests/visual.c Also, instead of setting the depth range to min;min + 1 it might be better to fall back to the no-depth-range codepath that is used if the app ever drawed untransformed geomentry. That's the device->untransformed check near the glOrtho calls.

April 30, 2008

Re: widl: Add a framework for automated testing of IDL files that should succeed or fail to be parsed.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > The way I see it, we have a choice between having a framework that uses > the makefile to run individual tests of the parser without checking the > content or a framework that runs every test in one go, but is capable of > checking the output of the generated files. The only technical advantage > that I can think of for the former is that it allows the tests to be > performed in parallel, but I don't know how much of a benefit that is to > Alexandre (who will be the one doing "make test" the most). We definitely have to be able to run tests individually from make, so there can't be just a single script to run them all. Still, it seems to me that most of these tests can just as well be done in the existing framework, as part of the rpcrt4 test for instance. This way we can not only make sure that the code compiles, but also that the generated code builds, and works the way it should. The only thing that can't be tested that way is obviously the code that is expected to fail to build, and for this something like Rob's framework would work fine, even though I'm not quite convinced that we care that much about getting the failure cases exactly right. -- Alexandre Julliard julliard(a)winehq.org

April 30, 2008

Switching threads in winedbg

by Maarten Lankhorst

Hi all, I was trying to switch to a different thread in winedbg, however I don't see any command for that in the winedbg online reference at http://www.winehq.org/site/docs/winedev-guide/dbg-commands . Does anyone know if it's possible? Cheers, Maarten.

April 30, 2008

Re: [Resend] user32: Post the WM_KEY{DOWN|UP} messagewhenWM_IME_KEY{DOWN|UP} message is generated by IME.

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > In order to check posted messages, you need to do what other tests > do: run a GetMessage/TranslateMessage/DispatchMessage loop, and let > the window proc handle the messages. s/GetMessage/PeekMessage/ -- Dmitry.

April 30, 2008

Re: [Resend] user32: Post the WM_KEY{DOWN|UP} message whenWM_IME_KEY{DOWN|UP} message is generated by IME.

by Dmitry Timoshkov

"ByeongSik Jeon" <bsjeon(a)hanmail.net> wrote: > @@ -4496,6 +4551,9 @@ static void test_messages(void) > > DestroyWindow(hwnd); > flush_sequence(); > + > + /* Message sequences by WM_IME_KEYDOWN */ > + test_wm_ime_keydown(); > } test_messages() is not a proper place to add new tests. Please have a look at test_combobox_messages() how to test key down/up behaviour. In order to check posted messages, you need to do what other tests do: run a GetMessage/TranslateMessage/DispatchMessage loop, and let the window proc handle the messages. -- Dmitry.

April 30, 2008