April 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 17 Aug '10

17 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: [PATCH 4/4] wined3d: use stretch_rect_fbo for swapchainless blits
by Henri Verbeet 23 Jun '10

23 Jun '10

On 28 April 2010 14:29, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > + /* Early sort out of cases where no render target is used */ > + if (!dstSwapchain && !srcSwapchain > + && src_surface != device->render_targets[0] > + && dst_surface != device->render_targets[0]) > + { > + if (fbo_blit_supported(&device->adapter->gl_info, BLIT_OP_BLIT, > + &src_rect, src_surface->resource.usage, src_surface->resource.pool, src_surface->resource.format_desc, > + &dst_rect, dst_surface->resource.usage, dst_surface->resource.pool, dst_surface->resource.format_desc)) > + { > + stretch_rect_fbo(device, src_surface, &src_rect, dst_surface, &dst_rect, Filter); > + return WINED3D_OK; > + } > + > + TRACE("No surface is render target, not using hardware blit.\n"); > + return WINED3DERR_INVALIDCALL; > + } > + You might as well try FBO blits first, before doing most of the other checks. That's how it's eventually supposed to work anyway, and you could remove the other strecth_rect_fbo() calls in that case. That does depend on fbo_blit_supported() working properly, of course.

2 4

gcc64 float bug
by Maarten Lankhorst 27 May '10

27 May '10

Hi AJ, I isolated and fixed the gcc bug, but it will take some time before the changes make it into wine stable. Should I add a testcase to configure to detect a broken version of gcc, and refuse to build wine64 if this is the case? See this link for the fix, and the testcase: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869 gdiplus tests seem to pass now, no weird test failures any more. I put my test results at: http://test.winehq.org/data/033bb8a2f9bd57000e64d5566f1b52a1cdf3f730/index_… I have no idea why it claims to have crashed, a few of them that claimed to have crashed ran succesfully till the end, but apart from that a few more testcases succeed. A few tests crash for me, but this appears to be a side effect from running gcc-svn, since it happens with and without the patch. I'm getting a lot of fixmes about DW_CFA_remember_state/DW_CFA_restore_state not being implemented. Cheers, Maarten

4 3

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

mciseq: Prevent busy-wait while paused.
by Joerg-Cyril.Hoehle＠t-systems.com 07 May '10

07 May '10

Hi, any comment on that patch? It's currently the bottommost in source.winehq.org/patches hence may fall into the bitbucket anytime. I had noticed that the MCI MIDI player would busy loop while paused because of a while(xyz) ; statement therein. Test it using these MCI commands open c:\data\foo.mid alias m play m pause m So I simply added a Sleep() and wrote: >7 ms is arbitrary. It allows to sleep well yet be responsive enough >so the app doesn't wait too long should the next command be MCI_Stop. >For the ear, an even larger sleep would be good enough. Sleep is a sort of stop gap until someone invents a notification/setEvent/Resume patch or whatever would be TRT. Regards, Jörg Höhle

2 3

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

Winebuild b0rken on Mac OS X?
by Charles Davis 04 May '10

04 May '10

While building Wine (latest git) on Mac OS X, I noticed this: /usr/bin/nm: object: amstream_test.MDsdpi.o malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) Undefined symbols: "_GetDesktopWindow", referenced from: _func_amstream in amstream.o "_TlsGetValue", referenced from: _get_tls_data in testlist.o "_MultiByteToWideChar", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_CloseHandle", referenced from: _func_amstream in amstream.o "_TlsSetValue", referenced from: _get_tls_data in testlist.o "_DirectDrawCreate", referenced from: _func_amstream in amstream.o "_CoCreateInstance", referenced from: _create_ammultimediastream in amstream.o "_WaitForSingleObject", referenced from: _winetest_wait_child_process in testlist.o "_CoInitializeEx", referenced from: _func_amstream in amstream.o "_HeapAlloc", referenced from: _get_tls_data in testlist.o "_CoUninitialize", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_GetExitCodeProcess", referenced from: _winetest_wait_child_process in testlist.o "_GetEnvironmentVariableA", referenced from: _main in testlist.o _main in testlist.o _main in testlist.o _main in testlist.o "_ExitProcess", referenced from: _exit_process in testlist.o ___wine_spec_exe_entry in libwinecrt0.a(exe_entry.o) "_CreateFileA", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_TlsAlloc", referenced from: _run_test in testlist.o ld: symbol(s) not found collect2: ld returned 1 exit status winegcc: gcc failed make[1]: *** [amstream_test.exe.so] Error 2 make: *** [dlls/amstream/tests] Error 2 Something's gone horribly wrong. Winebuild shouldn't be generating b0rken Mach-O files. What gives?

2 3

Re: [1/2] dlls/crypt32: implement PFXImportCertStore()
by Juan Lang 03 May '10

03 May '10

Hi Phillippe, this attempt looks pretty incomplete. First off: + ret = pPKCS12_verify_mac(pkcs12, password, len); + if (ret == 0) + ERR_(crypt)("failed to verify pkcs12 {%p} with password \"%s\" using func {%p}\n", pkcs12, password, pPKCS12_verify_mac); + else + TRACE_(crypt)("verified pkcs12 {%p} with password \"%s\" using func {%p}\n", pkcs12, password, pPKCS12_verify_mac); You accept the PKCS12 file even if the password is incorrect. This is clearly wrong. + /* extract private key and certificate */ + ret = pPKCS12_parse(pkcs12, password, &pkey, &cert, NULL); You don't support more than a single certificate in the PKCS12 file. This may be fine for the majority of uses, but at least a warning indicating more certificates are present would be helpful. Also, a PKCS12 file can contain more than just certificates, and the tests ought at least to check this. For example, what about a PKCS12 file with a CRL in it? OpenSSL also supports at least a couple of attributes associated with the certificates. From the man page for PKCS12_parse: The friendlyName and localKeyID attributes (if present) on each certificate will be stored in the alias and keyid attributes of the X509 structure. The Crypto API also supports setting such attributes, and if you aren't going to support these, at least the tests should cover them (and marked todo_wine) so we know they're still not done. More questions: + const WCHAR storeName[] = {'S', 't', 'o', 'r', 'e', ' ', 'N', 'a', 'm', 'e', 0}; + store = CertOpenStore(CERT_STORE_PROV_MEMORY, 0, (HCRYPTPROV)NULL, CERT_STORE_CREATE_NEW_FLAG, storeName); What's the purpose of the store name? Does the native implementation do this? If not, it can be omitted. If so, the tests should check it. Thanks, --Juan

2 5