February 2010 - Wine-devel - list.winehq.org

Re: [PATCH] winedbg: gdb proxy mode: support qAttached packet
by Eric Pouech 30 Aug '10

30 Aug '10

Paul Bolle a écrit : > Add support for the qAttached packet. Main benefit is that if gdb was > attached to a debuggee and it quits it will now ask if it should detach > from the debuggee instead of asking whether the debuggee should be > killed. (It still will ask whether the debuggee should be killed if it > launched the debuggee itself). > > Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> > --- > Would it be better to add a new member to gdbctx instead of using a > separate variable (qAttached_reply)? > yes, inclusion in gdbctx is preferred (and storage should rather be an integer rather than a string pointer) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

Re: [PATCH 2/3] winex11.drv: set global key state
by Alexandre Julliard 18 Aug '10

18 Aug '10

Rafał Miłecki <zajec5(a)gmail.com> writes: > @@ -1250,6 +1250,21 @@ void X11DRV_send_keyboard_input( WORD wVk, WORD wScan, DWORD event_flags, DWORD > key_state_table[wVkStripped] = key_state_table[wVkL] | key_state_table[wVkR]; > } > > + SERVER_START_REQ( set_global_key_state ) > + { > + req->key = wVk; > + req->state = key_state_table[wVk]; > + wine_server_call( req ); > + } > + SERVER_END_REQ; > + SERVER_START_REQ( set_global_key_state ) > + { > + req->key = wVkStripped; > + req->state = key_state_table[wVkStripped]; > + wine_server_call( req ); > + } > + SERVER_END_REQ; > + You don't want to add 2 extra server calls for every key, especially since the server already receives the necessary information through the key event. -- Alexandre Julliard julliard(a)winehq.org

3 2

TRACE () documentation
by James McKenzie 04 Jul '10

04 Jul '10

All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. James McKenzie

4 8

Re: Sudden increase of Valgrind errors
by Dan Kegel 14 May '10

14 May '10

Two things: I moved to karmic (and now more modules are enabled, since it comes with new-enough libraries), and I updated valgrind. I haven't had time to dig in to the differences. The suppressions file also needs updating for karmic. On Feb 28, 2010 5:43 AM, "Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: Hi Dan, As of Feb-25 there is a sudden increase in Valgrind errors reported at http://kegel.com/wine/valgrind/logs. The errors are in loads of modules which make me believe something generic has changed (there are also errors in modules that haven't been touched in a while). Any idea? -- Cheers, Paul.

2 2

LinuxTag Berlin - call for projects
by Jan Gerrit Möltgen 06 May '10

06 May '10

Hello together, I'm not sure, if this is the right place for my question, but I thought it's better than the user-list. The LinuxTag in Berlin makes a call for projects ( http://wiki.linuxtag.org/w/fp:Call_for_Projects ) and in my oppinion Wine should be represented there. Has somebody already submitted an application? If yes, I would like to support, otherwise I'd like to submit an application and would be happy about every helping hand. Greetings, Jan Gerrit -- Dipl.-Wirt.-Inf. Jan Gerrit Möltgen . . . . . .gerrit.moeltgen(a)itomig.de ITOMIG GmbH . . . . . . . . . . . . . . . . . . Tel.: +49 7031 389 25 06 Otto-Lilienthal-Str. 36 . . . . . . . . . . . . . . http://www.itomig.de D-71034 Böblingen . . . . . . . . . . . . . . . http://www.itomig.de/fr Geschäftsführer: David Gümbel . . . . . HRB 728519 Amtsgericht Stuttgart Sitz der Gesellschaft: Böblingen . . . . . . . . . . . . . . . . . . . .

3 5

re: Remove NoAppDBEntry keyword?
by Dan Kegel 24 Apr '10

24 Apr '10

Jerome Leclanche wrote: > Austin English <austinenglish at gmail.com> wrote: >> Anyone opposed to removing that keyword? > > +1 on removing it. > It would be nice to have a bugzilla filter to replace it, too. > > Are we keeping "tasklist" and "tasklet" keywords as well? theres > barely a dozen very old bugs for both of them. I think it'd be fine to remove noappdbentry, tasklist, and tasklet. If there are no objections by next weekend, let's go ahead and do it. - Dan

4 4

[PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
by Joerg-Cyril.Hoehle＠t-systems.com 16 Mar '10

16 Mar '10

Hi, Erich Hoover wrote: >so if we're not testing >the version we wouldn't know that it got removed. This is a very valid point. For instance, I'm currently writing a test that will read ok(1234123123==mhdr.dwOffset || broken(0==mhdr.dwOffset/*w9x,nt*/) ...) i.e. w2k+xp+Vista+7 differ from w95+98+me+nt. The Wine testsuite will not warn should MS-Windows ever revert back to w9x+nt behaviour. I've been fixing multimedia bugs in Wine, some of which were present for almost 10 years now. My point is: right *now* I'm closely looking at the exact behaviour under existing versions of MS-Windows (and having Wine mimick "modern" w2k/xp behaviour), yet the broken() mechanism prevents the tests from noticing when that behaviour will change next time. Patches these days make Wine implement the now "modern" behaviour, but remember modern is relative and tests with broken() will fail to report any future change... Until, perhaps again in ten years, somebody will look closely at the results, perhaps triggered by a bug report. Why wait for a bug report? Somehow, I feel that not noticing changes in behaviour is a waste of the test automation resources. broken() shadows broken (not valid any more) assumptions. Every now and then I wish there were a switch to disable broken() entirely and see what test.winehq reports for the various OS. E.g. $WINETEST_STRICT=1 => have broken() always yield 0/false. The goal to reach becomes WINETEST_STRICT=1 => no test failures on the system Wine purports to mimick (currently XP(?)). (Seems like a good idea, expect a patch soon ;) Regards, Jörg Höhle Well, at least the above example of broken() is much stricter than ok(!rc||broken(rc/*w9x*/)) == anything goes What does such a test tell except impose Wine's rc?

4 5

Significant performance "regression"
by Erich Hoover 08 Mar '10

08 Mar '10

I was looking into updating the AppDB with more recent results for PCB Artist* and discovered that on a fresh Wine install that the application opens and creates new files incredibly slowly (it now takes 23 minutes vs. old performance of ~5 seconds). I ran a regression test and discovered that an added feature in OLE32 is responsible for this "regression." I am, admittedly, not an expert on OLE32 - so I'm hoping that someone else has some thoughts on how to resolve this issue. ---- 226363f5dfb9caa8313e425c7f85ed9fe581f1fe is first bad commit commit 226363f5dfb9caa8313e425c7f85ed9fe581f1fe Author: Vincent Povirk <vincent(a)codeweavers.com> Date: Fri Dec 4 17:33:50 2009 -0600 ole32: Implement transacted storage. :040000 040000 79e7adf6177afe9cb8bfdea75270edb00026c5e5 abc173741982ee971ac490738917d735c6869a78 M dlls ---- Erich Hoover ehoover(a)mines.edu * Free proprietary application, direct download: http://www.4pcb.com/downloads/pcbartist/PcbArtist_1_3_2.exe

2 3

Re: [PATCH] winemp3.acm: always dynamically load libmpg123 stuff
by Chris Robinson 01 Mar '10

01 Mar '10

On Sunday 28 February 2010 1:13:44 pm Marcus Meissner wrote: > Hi, > > Copy in the mpg123.h header from the library so we do not need it for > building. (it is also LPGL) > > Dynamically link from libmpg123.so.0. > (Chances are very good that ABI stays stable.) > > This allows me providing a MP3 capable Wine build for openSUSE without > actually having libmpg123 in the openSUSE buildservice for building. > > > I was not able to test it though, anyone have a working winemp3.acm > using testcase :( This won't work, unfortunately. The mpg123.h header does some evil macro hacks to forward certain functions (eg. mpg123_seek, mpg123_feedseek) to 64-bit variants when _FILE_OFFSET_BITS is 64 due to using off_t. The functions the lib has depends on whether it was built with _FILE_OFFSET_BITS=64 or not, and the macros won't affect the strings passed to wine_dlsym. It also looks like the lib isn't unloaded with the acm.

2 2

Re: richedit: Documented paragraph border widths are in points not pixels.
by James McKenzie 28 Feb '10

28 Feb '10

Dylan Smith wrote: > The border widths documented by msdn are in points which are 72 dpi, which > is not equivalent to pixels (normally 96 dpi). I pre-converted all the > border widths to 96 dpi resolution since this avoids needed to store > fractions, and often avoids the need for convertion to the displays > resolution. > --- > dlls/riched20/editor.h | 2 +- > dlls/riched20/paint.c | 57 ++++++++++++++++++++++------------------------- > dlls/riched20/wrap.c | 2 +- > 3 files changed, 29 insertions(+), 32 deletions(-) > > ------------------------------------------------------------------------ > > Dylan: git apply complains about whitespace errors: 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:10: trailing whitespace. int ME_GetParaBorderWidth(ME_Context *c, int flags); 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:35: trailing whitespace. /* The documented widths are in points (72 dpi), but converting them to 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:36: trailing whitespace. * 96 dpi (standard display resolution) avoids dealing with fractions. */ 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:37: trailing whitespace. static const struct {unsigned width : 8, pen_style : 4, dble : 1;} border_details[] = { 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:38: trailing whitespace. /* none */ {0, PS_SOLID, FALSE}, error: patch failed: dlls/riched20/editor.h:229 error: dlls/riched20/editor.h: patch does not apply error: patch failed: dlls/riched20/paint.c:461 error: dlls/riched20/paint.c: patch does not apply error: patch failed: dlls/riched20/wrap.c:522 error: dlls/riched20/wrap.c: patch does not apply Current git as of this morning. James McKenzie

4 4